Google Git
Sign in
webkit / WebKit / 622cae2f48887ded7f52fd4826a323449e0e0795 / . / Source / JavaScriptCore / ChangeLog
blob: 5b4da472e0ce993c154193f9b8fee4044e796e59 [file] [log] [blame]
2019-05-15 Saam Barati <sbarati@apple.com>
Bound liveness of SetArgumentMaybe nodes when maximal flush insertion phase is enabled
https://bugs.webkit.org/show_bug.cgi?id=197855
<rdar://problem/50236506>
Reviewed by Michael Saboff.
Maximal flush insertion phase assumes it can extend the live range of
variables. However, this is not true with SetArgumentMaybe nodes, because
they are not guaranteed to demarcate the birth of a variable in the way
that SetArgumentDefinitely does. This caused things to break in SSA conversion
when we wanted to use the result of a SetArgumentMaybe node. To obviate this,
when we're done inlining something with SetArgumentMaybes, we SetLocal(undefined)
to the same set of locals. This caps the live range of the SetArgumentMaybe
and makes it so that extending the live range of the SetLocal is valid.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleVarargsInlining):
2019-05-14 Keith Miller <keith_miller@apple.com>
Fix issue with byteOffset on ARM64E
https://bugs.webkit.org/show_bug.cgi?id=197884
Reviewed by Saam Barati.
We forgot to remove the tag from the ArrayBuffer's data
pointer. This corrupted data when computing the offset. We didn't
catch this because we didn't run any with a non-zero byteOffset in
the JITs.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
(JSC::FTL::DFG::LowerDFGToB3::untagArrayPtr):
(JSC::FTL::DFG::LowerDFGToB3::removeArrayPtrTag):
(JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):
* jit/IntrinsicEmitter.cpp:
(JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
2019-05-14 Tadeu Zagallo <tzagallo@apple.com>
REGRESSION (r245249): ASSERTION FAILED: !m_needExceptionCheck seen with stress/proxy-delete.js and stress/proxy-property-descriptor.js
https://bugs.webkit.org/show_bug.cgi?id=197885
<rdar://problem/50770190>
Reviewed by Yusuke Suzuki.
In r245249 we added a throw scope to JSObject::getOwnPropertyDescriptor and its
callers now need to check for exceptions.
* runtime/ProxyObject.cpp:
(JSC::performProxyGet):
(JSC::ProxyObject::performDelete):
2019-05-14 Ross Kirsling <ross.kirsling@sony.com>
Unreviewed restoration of non-unified build.
* dfg/DFGMinifiedID.h:
* runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp:
2019-05-14 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Shrink sizeof(UnlinkedFunctionExecutable) more
https://bugs.webkit.org/show_bug.cgi?id=197833
Reviewed by Darin Adler.
It turns out that Gmail creates so many JSFunctions, FunctionExecutables, and UnlinkedFunctionExecutables.
So we should shrink size of them to save memory. As a first step, this patch reduces the sizeof(UnlinkedFunctionExecutable) more by 16 bytes.
1. We reorder some fields to get 8 bytes. And we use 31 bits for xxx offset things since their maximum size should be within 31 bits due to
String's length & int32_t representation in our parser.
2. We drop m_inferredName and prefer m_ecmaName. The inferred name is used to offer better function name when the function expression lacks
the name, but now ECMAScript has a specified semantics to name those functions with intuitive names. We should use ecmaName consistently,
and should not eat 8 bytes for inferred names in UnlinkedFunctionExecutable.
We also fix generator ecma name.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::inferredName const):
* bytecode/InlineCallFrame.cpp:
(JSC::InlineCallFrame::inferredName const):
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedFunctionExecutable.h:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createAssignResolve):
(JSC::ASTBuilder::createGeneratorFunctionBody):
(JSC::ASTBuilder::createGetterOrSetterProperty):
(JSC::ASTBuilder::createProperty):
(JSC::ASTBuilder::tryInferNameInPatternWithIdentifier):
(JSC::ASTBuilder::makeAssignNode):
* parser/Nodes.cpp:
(JSC::FunctionMetadataNode::operator== const):
(JSC::FunctionMetadataNode::dump const):
* parser/Nodes.h:
* runtime/CachedTypes.cpp:
(JSC::CachedFunctionExecutable::ecmaName const):
(JSC::CachedFunctionExecutable::encode):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::CachedFunctionExecutable::inferredName const): Deleted.
* runtime/FunctionExecutable.h:
* runtime/FunctionExecutableDump.cpp:
(JSC::FunctionExecutableDump::dump const):
* runtime/JSFunction.cpp:
(JSC::JSFunction::calculatedDisplayName):
(JSC::getCalculatedDisplayName):
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::StackFrame::displayName):
(JSC::SamplingProfiler::StackFrame::displayNameForJSONTests):
2019-05-13 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Compress JIT related data more by using Packed<>
https://bugs.webkit.org/show_bug.cgi?id=197866
Reviewed by Saam Barati.
This patch leverages Packed<> more to reduce JIT related data size. When we measure memory usage on Gmail, we found that a lot of memory is
consumed in DFG data. This patch attempts to reduce that size by using Packed<> to make various data structure's alignment 1.
* dfg/DFGCommonData.cpp:
(JSC::DFG::CommonData::shrinkToFit): Add more shrinkToFit.
* dfg/DFGMinifiedID.h: Make alignment = 1.
(JSC::DFG::MinifiedID::operator! const):
(JSC::DFG::MinifiedID::operator== const):
(JSC::DFG::MinifiedID::operator!= const):
(JSC::DFG::MinifiedID::operator< const):
(JSC::DFG::MinifiedID::operator> const):
(JSC::DFG::MinifiedID::operator<= const):
(JSC::DFG::MinifiedID::operator>= const):
(JSC::DFG::MinifiedID::hash const):
(JSC::DFG::MinifiedID::dump const):
(JSC::DFG::MinifiedID::isHashTableDeletedValue const):
(JSC::DFG::MinifiedID::bits const):
* dfg/DFGMinifiedIDInlines.h:
(JSC::DFG::MinifiedID::MinifiedID):
* dfg/DFGMinifiedNode.cpp:
(JSC::DFG::MinifiedNode::fromNode): Make sizeof(MinifiedNode) from 16 to 13 with alignment = 1.
* dfg/DFGMinifiedNode.h:
(JSC::DFG::MinifiedNode::id const):
(JSC::DFG::MinifiedNode::hasConstant const):
(JSC::DFG::MinifiedNode::constant const):
(JSC::DFG::MinifiedNode::isPhantomDirectArguments const):
(JSC::DFG::MinifiedNode::isPhantomClonedArguments const):
(JSC::DFG::MinifiedNode::hasInlineCallFrame const):
(JSC::DFG::MinifiedNode::inlineCallFrame const):
(JSC::DFG::MinifiedNode::op const): Deleted.
(JSC::DFG::MinifiedNode::hasInlineCallFrame): Deleted.
* dfg/DFGVariableEvent.h: Make sizeof(VariableEvent) from 12 to 10 with alignment = 1.
(JSC::DFG::VariableEvent::fillGPR):
(JSC::DFG::VariableEvent::fillPair):
(JSC::DFG::VariableEvent::fillFPR):
(JSC::DFG::VariableEvent::birth):
(JSC::DFG::VariableEvent::spill):
(JSC::DFG::VariableEvent::death):
(JSC::DFG::VariableEvent::setLocal):
(JSC::DFG::VariableEvent::movHint):
(JSC::DFG::VariableEvent::id const):
(JSC::DFG::VariableEvent::gpr const):
(JSC::DFG::VariableEvent::tagGPR const):
(JSC::DFG::VariableEvent::payloadGPR const):
(JSC::DFG::VariableEvent::fpr const):
(JSC::DFG::VariableEvent::spillRegister const):
(JSC::DFG::VariableEvent::bytecodeRegister const):
(JSC::DFG::VariableEvent::machineRegister const):
(JSC::DFG::VariableEvent::variableRepresentation const):
* dfg/DFGVariableEventStream.cpp:
(JSC::DFG::tryToSetConstantRecovery):
2019-05-13 Yusuke Suzuki <ysuzuki@apple.com>
[WTF] Simplify GCThread and CompilationThread flags by adding them to WTF::Thread
https://bugs.webkit.org/show_bug.cgi?id=197146
Reviewed by Saam Barati.
Rename Heap::Thread to Heap::HeapThread to remove conflict between WTF::Thread.
* heap/AlignedMemoryAllocator.cpp:
(JSC::AlignedMemoryAllocator::registerDirectory):
* heap/Heap.cpp:
(JSC::Heap::HeapThread::HeapThread):
(JSC::Heap::Heap):
(JSC::Heap::runCurrentPhase):
(JSC::Heap::runBeginPhase):
(JSC::Heap::resumeThePeriphery):
(JSC::Heap::requestCollection):
(JSC::Heap::isCurrentThreadBusy):
(JSC::Heap::notifyIsSafeToCollect):
(JSC::Heap::Thread::Thread): Deleted.
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::incrementDeferralDepth):
(JSC::Heap::decrementDeferralDepth):
(JSC::Heap::decrementDeferralDepthAndGCIfNeeded):
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::prepareForAllocation):
2019-05-13 Saam Barati <sbarati@apple.com>
macro assembler code-pointer tagging has its arguments backwards
https://bugs.webkit.org/show_bug.cgi?id=197677
Reviewed by Michael Saboff.
We had the destination as the leftmost instead of the rightmost argument,
which goes against the convention of how we order arguments in macro assembler
methods.
* assembler/MacroAssemblerARM64E.h:
(JSC::MacroAssemblerARM64E::tagReturnAddress):
(JSC::MacroAssemblerARM64E::untagReturnAddress):
(JSC::MacroAssemblerARM64E::tagPtr):
(JSC::MacroAssemblerARM64E::untagPtr):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
* ftl/FTLThunks.cpp:
(JSC::FTL::genericGenerationThunkGenerator):
* jit/CCallHelpers.h:
(JSC::CCallHelpers::prepareForTailCallSlow):
* jit/CallFrameShuffler.cpp:
(JSC::CallFrameShuffler::prepareForTailCall):
* jit/ThunkGenerators.cpp:
(JSC::emitPointerValidation):
(JSC::arityFixupGenerator):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::jsCallEntrypointSlow):
2019-05-13 Tadeu Zagallo <tzagallo@apple.com>
JSObject::getOwnPropertyDescriptor is missing an exception check
https://bugs.webkit.org/show_bug.cgi?id=197693
<rdar://problem/50441784>
Reviewed by Saam Barati.
The method table call to getOwnPropertySlot might throw, and JSObject::getOwnPropertyDescriptor
must handle the exception before calling PropertySlot::getValue, which can also throw.
* runtime/JSObject.cpp:
(JSC::JSObject::getOwnPropertyDescriptor):
2019-05-13 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Compress miscelaneous JIT related data structures with Packed<>
https://bugs.webkit.org/show_bug.cgi?id=197830
Reviewed by Saam Barati.
This patch leverages Packed<> to compress miscelaneous data structures related to JIT.
1. JIT IC data structures
2. ValueRecovery
We use Packed<> for EncodedJSValue in ValueRecovery. This means that conservative GC cannot find
these values. But this is OK anyway since ValueRecovery's constant should be already registered
in DFG graph. From 16 (alignment 8) to 9 (alignment 1).
3. FTL::ExitValue
We use Packed<> for EncodedJSValue in FTL::ExitValue. This is also OK since this constant should
be already registered by DFG/FTL graph. From 16 (alignment 8) to 9 (alignment 1).
* assembler/CodeLocation.h:
* bytecode/ByValInfo.h:
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::CallLinkInfo):
(JSC::CallLinkInfo::callReturnLocation):
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::nearCallMode const):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::addJITAddIC):
(JSC::CodeBlock::addJITMulIC):
(JSC::CodeBlock::addJITSubIC):
(JSC::CodeBlock::addJITNegIC):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::addMathIC):
* bytecode/InlineCallFrame.h:
(JSC::InlineCallFrame::InlineCallFrame):
* bytecode/ValueRecovery.h:
(JSC::ValueRecovery::inGPR):
(JSC::ValueRecovery::inPair):
(JSC::ValueRecovery::inFPR):
(JSC::ValueRecovery::displacedInJSStack):
(JSC::ValueRecovery::constant):
(JSC::ValueRecovery::directArgumentsThatWereNotCreated):
(JSC::ValueRecovery::clonedArgumentsThatWereNotCreated):
(JSC::ValueRecovery::gpr const):
(JSC::ValueRecovery::tagGPR const):
(JSC::ValueRecovery::payloadGPR const):
(JSC::ValueRecovery::fpr const):
(JSC::ValueRecovery::virtualRegister const):
(JSC::ValueRecovery::withLocalsOffset const):
(JSC::ValueRecovery::constant const):
(JSC::ValueRecovery::nodeID const):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueAdd):
(JSC::DFG::SpeculativeJIT::compileValueSub):
(JSC::DFG::SpeculativeJIT::compileValueNegate):
(JSC::DFG::SpeculativeJIT::compileValueMul):
* ftl/FTLExitValue.cpp:
(JSC::FTL::ExitValue::materializeNewObject):
* ftl/FTLExitValue.h:
(JSC::FTL::ExitValue::inJSStack):
(JSC::FTL::ExitValue::inJSStackAsInt32):
(JSC::FTL::ExitValue::inJSStackAsInt52):
(JSC::FTL::ExitValue::inJSStackAsDouble):
(JSC::FTL::ExitValue::constant):
(JSC::FTL::ExitValue::exitArgument):
(JSC::FTL::ExitValue::exitArgument const):
(JSC::FTL::ExitValue::adjustStackmapLocationsIndexByOffset):
(JSC::FTL::ExitValue::constant const):
(JSC::FTL::ExitValue::virtualRegister const):
(JSC::FTL::ExitValue::objectMaterialization const):
(JSC::FTL::ExitValue::withVirtualRegister const):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
(JSC::FTL::DFG::LowerDFGToB3::compileValueSub):
(JSC::FTL::DFG::LowerDFGToB3::compileValueMul):
(JSC::FTL::DFG::LowerDFGToB3::compileUnaryMathIC):
(JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC):
(JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
(JSC::FTL::DFG::LowerDFGToB3::compileValueNegate):
* jit/CachedRecovery.h:
* jit/CallFrameShuffleData.h:
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_negate):
(JSC::JIT::emit_op_add):
(JSC::JIT::emit_op_mul):
(JSC::JIT::emit_op_sub):
* jit/JITMathIC.h:
(JSC::isProfileEmpty):
(JSC::JITBinaryMathIC::JITBinaryMathIC):
(JSC::JITUnaryMathIC::JITUnaryMathIC):
* jit/PolymorphicCallStubRoutine.h:
(JSC::PolymorphicCallNode::hasCallLinkInfo):
* jit/SnippetOperand.h:
(JSC::SnippetOperand::asRawBits const):
(JSC::SnippetOperand::asConstInt32 const):
(JSC::SnippetOperand::asConstDouble const):
(JSC::SnippetOperand::setConstInt32):
(JSC::SnippetOperand::setConstDouble):
2019-05-12 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Compress Watchpoint size by using enum type and Packed<> data structure
https://bugs.webkit.org/show_bug.cgi?id=197730
Reviewed by Filip Pizlo.
Watchpoint takes 5~ MB memory in Gmail (total memory starts with 400 - 500 MB), so 1~%. Since it is allocated massively,
reducing each size of Watchpoint reduces memory footprint significantly.
As a first step, this patch uses Packed<> and enum to reduce the size of Watchpoint.
1. Watchpoint should have enum type and should not use vtable. vtable takes one pointer, and it is too costly for such a
memory sensitive objects. We perform downcast and dispatch the method of the derived classes based on this enum. Since
the # of derived Watchpoint classes are limited (Only 8), we can list up them easily. One unfortunate thing is that
we cannot do this for destructor so long as we use "delete" for deleting objects. If we dispatch the destructor of derived
class in the destructor of the base class, we call the destructor of the base class multiple times. delete operator override
does not help since custom delete operator is called after the destructor is called. While we can fix this issue by always
using custom deleter, currently we do not since all the watchpoints do not have members which have non trivial destructor.
Once it is strongly required, we can start using custom deleter, but for now, we do not need to do this.
2. We use Packed<> to compact pointers in Watchpoint. Since Watchpoint is a node of doubly linked list, each one has two
pointers for prev and next. This is also too costly. PackedPtr reduces the size and makes alignment 1.S
3. We use PackedCellPtr<> for JSCells in Watchpoint. This leverages alignment information and makes pointers smaller in
Darwin ARM64. One important thing to note here is that since this pointer is packed, it cannot be found by conservative
GC scan. It is OK for watchpoint since they are allocated in the heap anyway.
We applied this change to Watchpoint and get the following memory reduction. The highlight is that CodeBlockJettisoningWatchpoint in
ARM64 only takes 2 pointers size.
ORIGINAL X86_64 ARM64
WatchpointSet: 40 32 28
CodeBlockJettisoningWatchpoint: 32 19 15
StructureStubClearingWatchpoint: 56 48 40
AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint: 24 13 11
AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint: 24 13 11
FunctionRareData::AllocationProfileClearingWatchpoint: 32 19 15
ObjectToStringAdaptiveStructureWatchpoint: 56 48 40
LLIntPrototypeLoadAdaptiveStructureWatchpoint: 64 48 48
DFG::AdaptiveStructureWatchpoint: 56 48 40
While we will re-architect the mechanism of Watchpoint, anyway Packed<> mechanism and enum types will be used too.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
* bytecode/CodeBlockJettisoningWatchpoint.h:
* bytecode/CodeOrigin.h:
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::fireInternal):
* bytecode/StructureStubClearingWatchpoint.h:
* bytecode/Watchpoint.cpp:
(JSC::Watchpoint::fire):
* bytecode/Watchpoint.h:
(JSC::Watchpoint::Watchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.cpp:
(JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.h:
* heap/PackedCellPtr.h: Added.
* runtime/FunctionRareData.h:
* runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp: Added.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
* runtime/ObjectToStringAdaptiveStructureWatchpoint.h: Added.
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::clearObjectToStringValue):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal): Deleted.
* runtime/StructureRareData.h:
2019-05-12 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Compact generator code's bytecode size
https://bugs.webkit.org/show_bug.cgi?id=197822
Reviewed by Michael Saboff.
op_put_to_scope's symbolTableOrScopeDepth is represented as int. This was OK for the old bytecode format since
VirtualRegister / scope depth can be represented by int anyway. But it is problematic now since only int8_t range
will be represented in narrow bytecode. When this field is used for symbol table constant index, it is always
larger than FirstConstantRegisterIndex. So it always exceeds the range of int8_t, and results in wide bytecode.
It makes all generator's op_put_to_scope wide bytecode.
In this patch, we introduce a new (logically) union type SymbolTableOrScopeDepth. It holds unsigned value, and we store the
SymbolTableConstantIndex - FirstConstantRegisterIndex in this unsigned value to make op_put_to_scope narrow bytecode.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/BytecodeGeneratorification.cpp:
(JSC::BytecodeGeneratorification::run):
* bytecode/BytecodeList.rb:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* bytecode/Fits.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitProfileType):
(JSC::BytecodeGenerator::emitPutToScope):
(JSC::BytecodeGenerator::localScopeDepth const):
* bytecompiler/BytecodeGenerator.h:
* runtime/SymbolTableOrScopeDepth.h: Added.
(JSC::SymbolTableOrScopeDepth::symbolTable):
(JSC::SymbolTableOrScopeDepth::scopeDepth):
(JSC::SymbolTableOrScopeDepth::raw):
(JSC::SymbolTableOrScopeDepth::symbolTable const):
(JSC::SymbolTableOrScopeDepth::scopeDepth const):
(JSC::SymbolTableOrScopeDepth::raw const):
(JSC::SymbolTableOrScopeDepth::dump const):
(JSC::SymbolTableOrScopeDepth::SymbolTableOrScopeDepth):
2019-05-10 Saam barati <sbarati@apple.com>
Call to JSToWasmICCallee::createStructure passes in wrong prototype value
https://bugs.webkit.org/show_bug.cgi?id=197807
<rdar://problem/50530400>
Reviewed by Yusuke Suzuki.
We were passing the empty value instead of null. However, the empty
value means the Structure is poly proto. That's definitely not the case
here.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
2019-05-10 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] String substring operation should return ropes consistently
https://bugs.webkit.org/show_bug.cgi?id=197765
<rdar://problem/37689944>
Reviewed by Michael Saboff.
Currently we have different policies per string substring operation function.
1. String#slice returns the resolved non-rope string
2. String#substring returns rope string
3. String#substr returns rope string in runtime function, non-rope string in DFG and FTL
Due to (3), we see large memory use in the tested web page[1]. Non rope substring have a problem.
First of all, that returned string seems not used immediately. It is possible that the resulted
string is used as a part of the other ropes (like, xxx.substring(...) + "Hello"). To avoid the
eager materialization of the string, we are using StringImpl::createSubstringSharingImpl for the
resulted non rope string. StringImpl::createSubstringSharingImpl is StringImpl's substring feature: the
substring is pointing the owner StringImpl. While this has memory saving benefit, it can retain owner
StringImpl so long, and it could keep very large owner StringImpl alive.
The problem we are attempting to solve with StringImpl::createSubstringSharingImpl can be solved by
the rope string simply. Rope string can share the underlying string. And good feature of the rope
string is that, when resolving rope string, the rope string always create a new StringImpl instead of
using StringImpl::createSubstringSharingImpl. So we allow the owner StringImpl to be destroyed. And this
resolving only happens when we actually want to use the content of the rope string. In addition, we recently
shrunk the sizeof(JSRopeString) from 48 to 32, so JSRopeString is cheap.
In this patch, we change (2) and (3) to (1), using rope String as a result of substring operations.
RAMification and JetStream2 are neutral. The web page[1] shows large memory footprint improvement from 776MB to 681MB.
[1]: https://beta.observablehq.com/@ldgardner/assignment-4-visualizations-and-multiple-views
* dfg/DFGOperations.cpp:
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncSlice):
* runtime/StringPrototypeInlines.h:
(JSC::stringSlice):
2019-05-10 Robin Morisset <rmorisset@apple.com>
testb3 failing with crash in JSC::B3::BasicBlock::appendNonTerminal
https://bugs.webkit.org/show_bug.cgi?id=197756
<rdar://problem/50641659>
Reviewed by Saam Barati.
When I added https://bugs.webkit.org/show_bug.cgi?id=197265 I assumed that which block is the root does not change in the middle of strength reduction.
But specializeSelect can use splitForward, which uses a new block for the first half of the given block.
So if the block being split is the root block I must update m_root and erase the m_valueInConstant cache.
Erasing the cache cannot cause wrong results: at most it can make us miss some optimization opportunities in this iteration of the fixpoint.
* b3/B3ReduceStrength.cpp:
2019-05-09 Keith Miller <keith_miller@apple.com>
Fix crashes related to pointer authentication for primitive gigacage
https://bugs.webkit.org/show_bug.cgi?id=197763
<rdar://problem/50629257>
Reviewed by Saam Barati.
This fixes two bugs related to PAC for caging. The first is that
we didn't clear the high bits of the size register going into the
patchpoint to tag the new buffer for NewArrayBuffer. The second is
that the GC needs to strip all stack pointers when considering
them as a conservative root.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
* heap/ConservativeRoots.cpp:
(JSC::ConservativeRoots::genericAddPointer):
2019-05-09 Keith Miller <keith_miller@apple.com>
parseStatementListItem needs a stack overflow check
https://bugs.webkit.org/show_bug.cgi?id=197749
<rdar://problem/50302697>
Reviewed by Saam Barati.
There currently exists a path in the parser where you can loop
arbibrarily many times without a stack overflow check. This patch
adds a check to parseStatementListItem to break that cycle.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseStatementListItem):
2019-05-09 Keith Miller <keith_miller@apple.com>
REGRESSION (r245064): ASSERTION FAILED: m_ptr seen with wasm.yaml/wasm/js-api/test_Data.js.wasm-slow-memory
https://bugs.webkit.org/show_bug.cgi?id=197740
Reviewed by Saam Barati.
If a TypedArray constructor is called with just 0 as the first argument, we don't allocate a backing vector.
This means we need to handle null when calling vector() in ConstructionContext.
* runtime/JSArrayBufferView.h:
(JSC::JSArrayBufferView::ConstructionContext::vector const):
2019-05-09 Xan López <xan@igalia.com>
[CMake] Detect SSE2 at compile time
https://bugs.webkit.org/show_bug.cgi?id=196488
Reviewed by Carlos Garcia Campos.
* assembler/MacroAssemblerX86Common.cpp: Remove unnecessary (and
incorrect) static_assert.
(JSC::MacroAssemblerX86Common::collectCPUFeatures):
* assembler/MacroAssemblerX86Common.h: Remove SSE2 flags.
2019-05-08 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, build fix after r245064
https://bugs.webkit.org/show_bug.cgi?id=197110
* runtime/GenericTypedArrayView.h:
2019-05-08 Saam barati <sbarati@apple.com>
AccessGenerationState::emitExplicitExceptionHandler can clobber an in use register
https://bugs.webkit.org/show_bug.cgi?id=197715
<rdar://problem/50399252>
Reviewed by Filip Pizlo.
AccessGenerationState::emitExplicitExceptionHandler was always clobbering
x86's r9 without considering if that register was needed to be preserved
by the IC. This leads to bad things when the DFG/FTL need that register when
OSR exitting after an exception from a GetById call.
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::Code):
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessGenerationState::emitExplicitExceptionHandler):
* runtime/Options.h:
2019-05-08 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r245068.
Caused debug layout tests to exit early due to an assertion
failure.
Reverted changeset:
"All prototypes should call didBecomePrototype()"
https://bugs.webkit.org/show_bug.cgi?id=196315
https://trac.webkit.org/changeset/245068
2019-05-08 Yusuke Suzuki <ysuzuki@apple.com>
Invalid DFG JIT genereation in high CPU usage state
https://bugs.webkit.org/show_bug.cgi?id=197453
Reviewed by Saam Barati.
We have a DFG graph like this.
a: JSConstant(rope JSString)
b: CheckStringIdent(Check:StringUse:@a)
... AI think this is unreachable ...
When executing StringUse edge filter onto @a, AbstractValue::filterValueByType clears AbstractValue and makes it None.
This is because @a constant produces SpecString (SpecStringVar | SpecStringIdent) while StringUse edge filter requires
SpecStringIdent. AbstractValue::filterValueByType has an assumption that the JS constant always produces the same
SpeculatedType. So it clears AbstractValue completely.
But this assumption is wrong. JSString can produce SpecStringIdent later if the string is resolved to AtomicStringImpl.
AI think that we always fail. But once the string is resolved to AtomicStringImpl, we pass this check. So we execute
the breakpoint emitted by DFG since DFG think this is unreachable.
In this patch, we just clear the `m_value` if AbstractValue type filter fails with the held constant, since the constant
may produce a narrower type which can meet the type filter later.
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::filterValueByType):
2019-05-08 Robin Morisset <rmorisset@apple.com>
All prototypes should call didBecomePrototype()
https://bugs.webkit.org/show_bug.cgi?id=196315
Reviewed by Saam Barati.
This changelog already landed, but the commit was missing the actual changes.
Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor.
I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't
create structures with invalid prototypes.
It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation().
Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype.
* runtime/BigIntPrototype.cpp:
(JSC::BigIntPrototype::finishCreation):
* runtime/BooleanPrototype.cpp:
(JSC::BooleanPrototype::finishCreation):
* runtime/DatePrototype.cpp:
(JSC::DatePrototype::finishCreation):
* runtime/ErrorConstructor.cpp:
(JSC::ErrorConstructor::finishCreation):
* runtime/ErrorPrototype.cpp:
(JSC::ErrorPrototype::finishCreation):
* runtime/FunctionConstructor.cpp:
(JSC::FunctionConstructor::finishCreation):
* runtime/FunctionPrototype.cpp:
(JSC::FunctionPrototype::finishCreation):
* runtime/IntlCollatorPrototype.cpp:
(JSC::IntlCollatorPrototype::finishCreation):
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::IntlDateTimeFormatPrototype::finishCreation):
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::IntlNumberFormatPrototype::finishCreation):
* runtime/IntlPluralRulesPrototype.cpp:
(JSC::IntlPluralRulesPrototype::finishCreation):
* runtime/JSArrayBufferPrototype.cpp:
(JSC::JSArrayBufferPrototype::finishCreation):
* runtime/JSDataViewPrototype.cpp:
(JSC::JSDataViewPrototype::finishCreation):
* runtime/JSGenericTypedArrayViewPrototypeInlines.h:
(JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
* runtime/JSGlobalObject.cpp:
(JSC::createConsoleProperty):
* runtime/JSPromisePrototype.cpp:
(JSC::JSPromisePrototype::finishCreation):
* runtime/JSTypedArrayViewConstructor.cpp:
(JSC::JSTypedArrayViewConstructor::finishCreation):
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::JSTypedArrayViewPrototype::finishCreation):
* runtime/NumberPrototype.cpp:
(JSC::NumberPrototype::finishCreation):
* runtime/RegExpPrototype.cpp:
(JSC::RegExpPrototype::finishCreation):
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
* runtime/Structure.cpp:
(JSC::Structure::isValidPrototype):
(JSC::Structure::changePrototypeTransition):
* runtime/Structure.h:
* runtime/SymbolPrototype.cpp:
(JSC::SymbolPrototype::finishCreation):
* wasm/js/WebAssemblyCompileErrorPrototype.cpp:
(JSC::WebAssemblyCompileErrorPrototype::finishCreation):
* wasm/js/WebAssemblyInstancePrototype.cpp:
(JSC::WebAssemblyInstancePrototype::finishCreation):
* wasm/js/WebAssemblyLinkErrorPrototype.cpp:
(JSC::WebAssemblyLinkErrorPrototype::finishCreation):
* wasm/js/WebAssemblyMemoryPrototype.cpp:
(JSC::WebAssemblyMemoryPrototype::finishCreation):
* wasm/js/WebAssemblyModulePrototype.cpp:
(JSC::WebAssemblyModulePrototype::finishCreation):
* wasm/js/WebAssemblyPrototype.cpp:
(JSC::WebAssemblyPrototype::finishCreation):
* wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
(JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
* wasm/js/WebAssemblyTablePrototype.cpp:
(JSC::WebAssemblyTablePrototype::finishCreation):
2019-05-08 Keith Miller <keith_miller@apple.com>
Remove Gigacage from arm64 and use PAC for arm64e instead
https://bugs.webkit.org/show_bug.cgi?id=197110
Reviewed by Saam Barati.
This patch makes a bunch of changes. I'll start with global changes then go over changes to each tier and finish with bug fixes.
Global Changes:
Change CagedBarrierPtr to work with PAC so constructors and accessors now expect to receive a length.
Update assembler helper methods to use do PAC when caging.
LLInt:
Add arm64e.rb backend as we missed that when originally open sourcing our arm64e code.
Add a new optional t6 temporary, which is only used currently on arm64e for GetByVal on a TypedArray.
Refactor caging into two helper macros for Primitive/JSValue cages.
Baseline/DFG:
Add authentication where needed for GetByVal and inline object construction.
FTL:
Add a new ValueRep that allows for a late register use. We want this for the authentication patchpoint since we use the length register at the same time as we are defing the authenticated pointer.
Wasm:
Use the TaggedArrayStoragePtr class for the memory base pointer. In theory we should be caging those pointers but I don't want to risk introducing a performance regression with the rest of this change. I've filed https://bugs.webkit.org/show_bug.cgi?id=197620 to do this later.
As we no longer have the Gigacage using most of our VA memory, we can enable fast memories on iOS.
Using fast memories leads to roughly a 2% JetStream2 speedup.
* assembler/MacroAssemblerARM64E.h:
(JSC::MacroAssemblerARM64E::tagArrayPtr):
(JSC::MacroAssemblerARM64E::untagArrayPtr):
(JSC::MacroAssemblerARM64E::removeArrayPtrTag):
* 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::untagArrayPtr):
(JSC::FTL::DFG::LowerDFGToB3::caged):
(JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):
* 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):
* llint/LowLevelInterpreter64.asm:
* offlineasm/arm64.rb:
* offlineasm/arm64e.rb: Added.
* offlineasm/ast.rb:
* offlineasm/instructions.rb:
* offlineasm/registers.rb:
* offlineasm/x86.rb:
* 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::byteLength const):
(JSC::ArrayBufferView::setRangeImpl):
(JSC::ArrayBufferView::getRangeImpl):
* 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::getUnsafe const):
(JSC::CagedBarrierPtr::at const):
(JSC::CagedBarrierPtr::operator== const):
(JSC::CagedBarrierPtr::operator bool const):
(JSC::CagedBarrierPtr::setWithoutBarrier):
(JSC::CagedBarrierPtr::operator* const): Deleted.
(JSC::CagedBarrierPtr::operator-> const): Deleted.
(JSC::CagedBarrierPtr::operator[] const): Deleted.
(): 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::hasVector const):
(JSC::JSArrayBufferView::vector const):
* 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-05-08 Caio Lima <ticaiolima@gmail.com>
[BigInt] Add ValueMod into DFG
https://bugs.webkit.org/show_bug.cgi?id=186174
Reviewed by Saam Barati.
This patch is introducing a new DFG node called ValueMod, that is
responsible to handle BigInt and Untyped specialization of op_mod.
With the introduction of BigInt, we think that cases with
ValueMod(Untyped, Untyped) can be more common and we introduced
support for such kind of node.
* dfg/DFGAbstractInterpreter.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::handleConstantDivOp):
We are abstracting the constant rules of division operations. It
includes ArithDiv, ValueDiv, ArithMod and ValueMod, since they perform
the same analysis.
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::makeSafe):
(JSC::DFG::ByteCodeParser::parseBlock):
Here we check if lhs and rhs have number result to emit ArithMod.
Otherwise, we need to fallback to ValueMod and let fixup replace this
operation when possible.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
ValueMod(BigIntUse) doesn't clobberize world because it only calls
`operationModBigInt`.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
ValueMod(BigIntUse) can trigger GC since it allocates intermediate
JSBigInt to perform calculation. ValueMod(UntypedUse) can trigger GC
because it can execute arbritary code from user.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupArithDivInt32):
Function created to simplify readability of ArithDiv/AirthMod fixup
operation.
(JSC::DFG::FixupPhase::fixupArithDiv):
(JSC::DFG::FixupPhase::fixupNode):
Following the same fixup rules of ArithDiv.
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
(JSC::DFG::binaryOp):
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
ValueMod follows the same prediction propagation rules of ArithMod and
the same rules for `doDoubleVoting`.
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueMod):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGValidate.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileValueMod):
2019-05-07 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] DFG_ASSERT failed in lowInt52
https://bugs.webkit.org/show_bug.cgi?id=197569
Reviewed by Saam Barati.
GetStack with FlushedInt52 should load the flushed value in Int52 form and put the result in m_int52Values / m_strictInt52Values. Previously,
we load it in JSValue / Int32 form and lowInt52 fails to get appropriate one since GetStack does not put the result in m_int52Values / m_strictInt52Values.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetStack):
2019-05-07 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] LLIntPrototypeLoadAdaptiveStructureWatchpoint does not require Bag<>
https://bugs.webkit.org/show_bug.cgi?id=197645
Reviewed by Saam Barati.
We are using HashMap<std::tuple<Structure*, const Instruction*>, Bag<LLIntPrototypeLoadAdaptiveStructureWatchpoint>> for LLIntPrototypeLoadAdaptiveStructureWatchpoint,
but this has several memory inefficiency.
1. Structure* and Instruction* are too large. We can just use StructureID and bytecodeOffset (unsigned).
2. While we are using Bag<>, we do not add a new LLIntPrototypeLoadAdaptiveStructureWatchpoint after constructing this Bag first. So we can
use Vector<LLIntPrototypeLoadAdaptiveStructureWatchpoint> instead. We ensure that new entry won't be added to this Vector by making Watchpoint
non-movable.
3. Instead of having OpGetById::Metadata&, we just hold `unsigned` bytecodeOffset, and get Metadata& from the owner CodeBlock when needed.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finalizeLLIntInlineCaches):
* bytecode/CodeBlock.h:
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* bytecode/Watchpoint.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setupGetByIdPrototypeCache):
2019-05-07 Yusuke Suzuki <ysuzuki@apple.com>
JSC: A bug in BytecodeGenerator::emitEqualityOpImpl
https://bugs.webkit.org/show_bug.cgi?id=197479
Reviewed by Saam Barati.
Our peephole optimization in BytecodeGenerator is (1) rewinding the previous instruction and (2) emit optimized instruction instead.
If we have jump target between the previous instruction and the subsequent instruction, this peephole optimization breaks the jump target.
To prevent it, we had a mechanism disabling peephole optimization, setting m_lastOpcodeID = op_end and checking m_lastOpcodeID when performing
peephole optimization. However, BytecodeGenerator::emitEqualityOpImpl checks `m_lastInstruction->is<OpTypeof>` instead of `m_lastOpcodeID == op_typeof`,
and miss `op_end` case.
This patch makes the following changes.
1. Add canDoPeepholeOptimization method to clarify the intent of `m_lastInstruction = op_end`.
2. Check canDoPeepholeOptimization status before performing peephole optimization in emitJumpIfTrue, emitJumpIfFalse, and emitEqualityOpImpl.
3. Add `ASSERT(canDoPeepholeOptimization())` in fuseCompareAndJump and fuseTestAndJmp to ensure that peephole optimization is allowed.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::fuseCompareAndJump):
(JSC::BytecodeGenerator::fuseTestAndJmp):
(JSC::BytecodeGenerator::emitJumpIfTrue):
(JSC::BytecodeGenerator::emitJumpIfFalse):
(JSC::BytecodeGenerator::emitEqualityOpImpl):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::canDoPeepholeOptimization const):
2019-05-07 Yusuke Suzuki <ysuzuki@apple.com>
TemplateObject passed to template literal tags are not always identical for the same source location.
https://bugs.webkit.org/show_bug.cgi?id=190756
Reviewed by Saam Barati.
Tagged template literal requires that the site object is allocated per source location. Previously, we create the site object
when linking CodeBlock and cache it in CodeBlock. But this is wrong because,
1. CodeBlock can be jettisoned and regenerated. So every time CodeBlock is regenerated, we get the different site object.
2. Call and Construct can have different CodeBlock. Even if the function is called in call-form or construct-form, we should return the same site object.
In this patch, we start caching these site objects in the top-level ScriptExecutable, this matches the spec's per source location since the only one top-level
ScriptExecutable is created for the given script code. Each ScriptExecutable of JSFunction can be created multiple times because CodeBlock creates it.
But the top-level one is not created by CodeBlock. This top-level ScriptExecutable is well-aligned to the Script itself. The top-level ScriptExecutable now has HashMap,
which maps source locations to cached site objects.
1. This patch threads the top-level ScriptExecutable to each FunctionExecutable creation. Each FunctionExecutable has a reference to the top-level ScriptExecutable.
2. We put TemplateObjectMap in ScriptExecutable, which manages cached template objects.
3. We move FunctionExecutable::m_cachedPolyProtoStructure to the FunctionExecutable::RareDate to keep FunctionExecutable 128 bytes.
4. TemplateObjectMap is indexed with endOffset of TaggedTemplate.
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
* Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
* Scripts/wkbuiltins/builtins_templates.py:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::setConstantRegisters):
* bytecode/CodeBlock.h:
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::link):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::addTemplateObjectConstant):
(JSC::BytecodeGenerator::emitGetTemplateObject):
* bytecompiler/BytecodeGenerator.h:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createTaggedTemplate):
* runtime/CachedTypes.cpp:
(JSC::CachedTemplateObjectDescriptor::encode):
(JSC::CachedTemplateObjectDescriptor::decode const):
(JSC::CachedJSValue::encode):
(JSC::CachedJSValue::decode const):
* runtime/EvalExecutable.cpp:
(JSC::EvalExecutable::ensureTemplateObjectMap):
(JSC::EvalExecutable::visitChildren):
* runtime/EvalExecutable.h:
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::finishCreation):
(JSC::FunctionExecutable::visitChildren):
(JSC::FunctionExecutable::fromGlobalCode):
(JSC::FunctionExecutable::ensureRareDataSlow):
(JSC::FunctionExecutable::ensureTemplateObjectMap):
* runtime/FunctionExecutable.h:
* runtime/JSModuleRecord.cpp:
(JSC::JSModuleRecord::instantiateDeclarations):
* runtime/JSTemplateObjectDescriptor.cpp:
(JSC::JSTemplateObjectDescriptor::JSTemplateObjectDescriptor):
(JSC::JSTemplateObjectDescriptor::create):
* runtime/JSTemplateObjectDescriptor.h:
* runtime/ModuleProgramExecutable.cpp:
(JSC::ModuleProgramExecutable::ensureTemplateObjectMap):
(JSC::ModuleProgramExecutable::visitChildren):
* runtime/ModuleProgramExecutable.h:
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::ensureTemplateObjectMap):
(JSC::ProgramExecutable::visitChildren):
* runtime/ProgramExecutable.h:
* runtime/ScriptExecutable.cpp:
(JSC::ScriptExecutable::topLevelExecutable):
(JSC::ScriptExecutable::createTemplateObject):
(JSC::ScriptExecutable::ensureTemplateObjectMapImpl):
(JSC::ScriptExecutable::ensureTemplateObjectMap):
* runtime/ScriptExecutable.h:
* tools/JSDollarVM.cpp:
(JSC::functionCreateBuiltin):
(JSC::functionDeleteAllCodeWhenIdle):
(JSC::JSDollarVM::finishCreation):
2019-05-07 Robin Morisset <rmorisset@apple.com>
[B3] Constants should be hoisted to the root block until moveConstants
https://bugs.webkit.org/show_bug.cgi?id=197265
Reviewed by Saam Barati.
This patch does the following:
- B3ReduceStrength now hoists all constants to the root BB, and de-duplicates them along the way
- B3PureCSE no longer bothers with constants, since they are already de-duplicated by the time it gets to see them
- We now run eliminateDeadCode just after moveConstants, so that the Nops that moveConstants generates are freed instead of staying live throughout Air compilation, reducing memory pressure.
- I also took the opportunity to fix typos in comments in various parts of the code base.
Here are a few numbers to justify this patch:
- In JetStream2, about 27% of values at the beginning of B3 are constants
- In JetStream2, about 11% of values at the end of B3 are Nops
- In JetStream2, this patch increases the number of times that tail duplication happens from a bit less than 24k to a bit more than 25k (hoisting constants makes blocks smaller).
When I tried measuring the total effect on JetStream2 I got a tiny and almost certainly non-significant progression.
* b3/B3Generate.cpp:
(JSC::B3::generateToAir):
* b3/B3MoveConstants.cpp:
* b3/B3PureCSE.cpp:
(JSC::B3::PureCSE::process):
* b3/B3PureCSE.h:
* b3/B3ReduceStrength.cpp:
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
* dfg/DFGCSEPhase.cpp:
* dfg/DFGOSRAvailabilityAnalysisPhase.h:
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::executeOSRExit):
2019-05-07 Robin Morisset <rmorisset@apple.com>
All prototypes should call didBecomePrototype()
https://bugs.webkit.org/show_bug.cgi?id=196315
Reviewed by Saam Barati.
Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor.
I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't
create structures with invalid prototypes.
It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation().
Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype.
* runtime/BigIntPrototype.cpp:
(JSC::BigIntPrototype::finishCreation):
* runtime/BooleanPrototype.cpp:
(JSC::BooleanPrototype::finishCreation):
* runtime/DatePrototype.cpp:
(JSC::DatePrototype::finishCreation):
* runtime/ErrorConstructor.cpp:
(JSC::ErrorConstructor::finishCreation):
* runtime/ErrorPrototype.cpp:
(JSC::ErrorPrototype::finishCreation):
* runtime/FunctionConstructor.cpp:
(JSC::FunctionConstructor::finishCreation):
* runtime/FunctionPrototype.cpp:
(JSC::FunctionPrototype::finishCreation):
* runtime/IntlCollatorPrototype.cpp:
(JSC::IntlCollatorPrototype::finishCreation):
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::IntlDateTimeFormatPrototype::finishCreation):
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::IntlNumberFormatPrototype::finishCreation):
* runtime/IntlPluralRulesPrototype.cpp:
(JSC::IntlPluralRulesPrototype::finishCreation):
* runtime/JSArrayBufferPrototype.cpp:
(JSC::JSArrayBufferPrototype::finishCreation):
* runtime/JSDataViewPrototype.cpp:
(JSC::JSDataViewPrototype::finishCreation):
* runtime/JSGenericTypedArrayViewPrototypeInlines.h:
(JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
* runtime/JSGlobalObject.cpp:
(JSC::createConsoleProperty):
* runtime/JSPromisePrototype.cpp:
(JSC::JSPromisePrototype::finishCreation):
* runtime/JSTypedArrayViewConstructor.cpp:
(JSC::JSTypedArrayViewConstructor::finishCreation):
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::JSTypedArrayViewPrototype::finishCreation):
* runtime/NumberPrototype.cpp:
(JSC::NumberPrototype::finishCreation):
* runtime/RegExpPrototype.cpp:
(JSC::RegExpPrototype::finishCreation):
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
* runtime/Structure.cpp:
(JSC::Structure::isValidPrototype):
(JSC::Structure::changePrototypeTransition):
* runtime/Structure.h:
* runtime/SymbolPrototype.cpp:
(JSC::SymbolPrototype::finishCreation):
* wasm/js/WebAssemblyCompileErrorPrototype.cpp:
(JSC::WebAssemblyCompileErrorPrototype::finishCreation):
* wasm/js/WebAssemblyInstancePrototype.cpp:
(JSC::WebAssemblyInstancePrototype::finishCreation):
* wasm/js/WebAssemblyLinkErrorPrototype.cpp:
(JSC::WebAssemblyLinkErrorPrototype::finishCreation):
* wasm/js/WebAssemblyMemoryPrototype.cpp:
(JSC::WebAssemblyMemoryPrototype::finishCreation):
* wasm/js/WebAssemblyModulePrototype.cpp:
(JSC::WebAssemblyModulePrototype::finishCreation):
* wasm/js/WebAssemblyPrototype.cpp:
(JSC::WebAssemblyPrototype::finishCreation):
* wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
(JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
* wasm/js/WebAssemblyTablePrototype.cpp:
(JSC::WebAssemblyTablePrototype::finishCreation):
2019-05-07 Robin Morisset <rmorisset@apple.com>
WTF::BitVector should have an isEmpty() method
https://bugs.webkit.org/show_bug.cgi?id=197637
Reviewed by Keith Miller.
Just replaces some comparison of bitCount() to 0 by calls to isEmpty()
* b3/air/AirAllocateRegistersByGraphColoring.cpp:
2019-05-07 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r244978.
https://bugs.webkit.org/show_bug.cgi?id=197671
TemplateObject map should use start/end offsets (Requested by
yusukesuzuki on #webkit).
Reverted changeset:
"TemplateObject passed to template literal tags are not always
identical for the same source location."
https://bugs.webkit.org/show_bug.cgi?id=190756
https://trac.webkit.org/changeset/244978
2019-05-07 Tadeu Zagallo <tzagallo@apple.com>
tryCachePutByID should not crash if target offset changes
https://bugs.webkit.org/show_bug.cgi?id=197311
<rdar://problem/48033612>
Reviewed by Filip Pizlo.
When tryCachePutID is called with a cacheable setter, if the target object where the setter was
found is still in the prototype chain and there's no poly protos in the chain, we use
generateConditionsForPrototypePropertyHit to validate that the target object remains the same.
It checks for the absence of the property in every object in the prototype chain from the base
down to the target object and checks that the property is still present in the target object. It
also bails if there are any uncacheable objects, proxies or dictionary objects in the prototype
chain. However, it does not consider two edge cases:
- It asserts that the property should still be at the same offset in the target object, but this
assertion does not hold if the setter deletes properties of the object and causes the structure
to be flattened after the deletion. Instead of asserting, we just use the updated offset.
- It does not check whether the new slot is also a setter, which leads to a crash in case it's not.
* jit/Repatch.cpp:
(JSC::tryCachePutByID):
2019-05-07 Saam Barati <sbarati@apple.com>
Don't OSR enter into an FTL CodeBlock that has been jettisoned
https://bugs.webkit.org/show_bug.cgi?id=197531
<rdar://problem/50162379>
Reviewed by Yusuke Suzuki.
Sometimes we make silly mistakes. This is one of those times. It's invalid to OSR
enter into an FTL OSR entry code block that has been jettisoned already.
* dfg/DFGJITCode.cpp:
(JSC::DFG::JITCode::clearOSREntryBlockAndResetThresholds):
* dfg/DFGJITCode.h:
(JSC::DFG::JITCode::clearOSREntryBlock): Deleted.
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareOSREntry):
(JSC::DFG::prepareCatchOSREntry):
* dfg/DFGOperations.cpp:
* ftl/FTLOSREntry.cpp:
(JSC::FTL::prepareOSREntry):
2019-05-06 Keith Miller <keith_miller@apple.com>
JSWrapperMap should check if existing prototype properties are wrappers when copying exported methods.
https://bugs.webkit.org/show_bug.cgi?id=197324
<rdar://problem/50253144>
Reviewed by Saam Barati.
The current implementation prevents using JSExport to shadow a
method from a super class. This was because we would only add a
method if the prototype didn't already claim to have the
property. Normally this would only happen if an Objective-C super
class already exported a ObjCCallbackFunction for the method,
however, if the user exports a property that is already on
Object.prototype the overriden method won't be exported.
This patch fixes the object prototype issue by checking if the
property on the prototype chain is an ObjCCallbackFunction, if
it's not then it adds an override.
* API/JSWrapperMap.mm:
(copyMethodsToObject):
* API/tests/testapi.mm:
(-[ToStringClass toString]):
(-[ToStringClass other]):
(-[ToStringSubclass toString]):
(-[ToStringSubclassNoProtocol toString]):
(testToString):
(testObjectiveCAPI):
2019-05-06 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] We should check OOM for description string of Symbol
https://bugs.webkit.org/show_bug.cgi?id=197634
Reviewed by Keith Miller.
When resoling JSString for description of Symbol, we should check OOM error.
We also change JSValueMakeSymbol(..., nullptr) to returning a symbol value
without description, (1) to simplify the code and (2) give a way for JSC API
to create a symbol value without description.
* API/JSValueRef.cpp:
(JSValueMakeSymbol):
* API/tests/testapi.cpp:
(TestAPI::symbolsTypeof):
(TestAPI::symbolsDescription):
(testCAPIViaCpp):
* dfg/DFGOperations.cpp:
* runtime/Symbol.cpp:
(JSC::Symbol::createWithDescription):
* runtime/Symbol.h:
* runtime/SymbolConstructor.cpp:
(JSC::callSymbol):
2019-05-06 Keith Rollin <krollin@apple.com>
Temporarily disable generate-xcfilelists
https://bugs.webkit.org/show_bug.cgi?id=197619
<rdar://problem/50507392>
Reviewed by Alex Christensen.
We need to perform a significant update to the generate-xcfilelist
scripts. This work involves coordinated work with another facility. If
the work does not occur in tandem, the build will be broken. To avoid
this, disable the invoking of the scripts during the transition. The
checking will be restored once the new scripts are in place.
* Scripts/check-xcfilelists.sh:
2019-05-06 Basuke Suzuki <Basuke.Suzuki@sony.com>
[PlayStation] Fix build break since r244919
https://bugs.webkit.org/show_bug.cgi?id=197627
Reviewed by Ross Kirsling.
Bugfix for POSIX socket implementation and suppress warnings.
* inspector/remote/socket/RemoteInspectorConnectionClient.h:
(Inspector::RemoteInspectorConnectionClient::didAccept):
* inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp:
(Inspector::Socket::getPort):
2019-05-06 Yusuke Suzuki <ysuzuki@apple.com>
TemplateObject passed to template literal tags are not always identical for the same source location.
https://bugs.webkit.org/show_bug.cgi?id=190756
Reviewed by Saam Barati.
Tagged template literal requires that the site object is allocated per source location. Previously, we create the site object
when linking CodeBlock and cache it in CodeBlock. But this is wrong because,
1. CodeBlock can be jettisoned and regenerated. So every time CodeBlock is regenerated, we get the different site object.
2. Call and Construct can have different CodeBlock. Even if the function is called in call-form or construct-form, we should return the same site object.
In this patch, we start caching these site objects in the top-level ScriptExecutable, this matches the spec's per source location since the only one top-level
ScriptExecutable is created for the given script code. Each ScriptExecutable of JSFunction can be created multiple times because CodeBlock creates it.
But the top-level one is not created by CodeBlock. This top-level ScriptExecutable is well-aligned to the Script itself. The top-level ScriptExecutable now has HashMap,
which maps source locations to cached site objects.
1. This patch threads the top-level ScriptExecutable to each FunctionExecutable creation. Each FunctionExecutable has a reference to the top-level ScriptExecutable.
2. We put TemplateObjectMap in ScriptExecutable, which manages cached template objects.
3. We move FunctionExecutable::m_cachedPolyProtoStructure to the FunctionExecutable::RareDate to keep FunctionExecutable 128 bytes.
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
* Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
* Scripts/wkbuiltins/builtins_templates.py:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::setConstantRegisters):
* bytecode/CodeBlock.h:
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::link):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::addTemplateObjectConstant):
(JSC::BytecodeGenerator::emitGetTemplateObject):
* bytecompiler/BytecodeGenerator.h:
* runtime/CachedTypes.cpp:
(JSC::CachedTemplateObjectDescriptor::encode):
(JSC::CachedTemplateObjectDescriptor::decode const):
(JSC::CachedJSValue::encode):
(JSC::CachedJSValue::decode const):
* runtime/EvalExecutable.cpp:
(JSC::EvalExecutable::ensureTemplateObjectMap):
(JSC::EvalExecutable::visitChildren):
* runtime/EvalExecutable.h:
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::finishCreation):
(JSC::FunctionExecutable::visitChildren):
(JSC::FunctionExecutable::fromGlobalCode):
(JSC::FunctionExecutable::ensureRareDataSlow):
(JSC::FunctionExecutable::ensureTemplateObjectMap):
* runtime/FunctionExecutable.h:
* runtime/JSModuleRecord.cpp:
(JSC::JSModuleRecord::instantiateDeclarations):
* runtime/JSTemplateObjectDescriptor.cpp:
(JSC::JSTemplateObjectDescriptor::JSTemplateObjectDescriptor):
(JSC::JSTemplateObjectDescriptor::create):
* runtime/JSTemplateObjectDescriptor.h:
* runtime/ModuleProgramExecutable.cpp:
(JSC::ModuleProgramExecutable::ensureTemplateObjectMap):
(JSC::ModuleProgramExecutable::visitChildren):
* runtime/ModuleProgramExecutable.h:
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::ensureTemplateObjectMap):
(JSC::ProgramExecutable::visitChildren):
* runtime/ProgramExecutable.h:
* runtime/ScriptExecutable.cpp:
(JSC::ScriptExecutable::topLevelExecutable):
(JSC::ScriptExecutable::createTemplateObject):
(JSC::ScriptExecutable::ensureTemplateObjectMap):
* runtime/ScriptExecutable.h:
* tools/JSDollarVM.cpp:
(JSC::functionCreateBuiltin):
(JSC::functionDeleteAllCodeWhenIdle):
(JSC::JSDollarVM::finishCreation):
2019-05-04 Tadeu Zagallo <tzagallo@apple.com>
TypedArrays should not store properties that are canonical numeric indices
https://bugs.webkit.org/show_bug.cgi?id=197228
<rdar://problem/49557381>
Reviewed by Saam Barati.
According to the spec[1]:
- TypedArrays should not perform an ordinary GetOwnProperty/SetOwnProperty if the index is a
CanonicalNumericIndexString, but invalid according to IntegerIndexedElementGet and similar
functions. I.e., there are a few properties that should not be set in a TypedArray, like NaN,
Infinity and -0.
- On DefineOwnProperty, the out-of-bounds check should be performed before validating the property
descriptor.
- On GetOwnProperty, the returned descriptor for numeric properties should have writable set to true.
[1]: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-integer-indexed-exotic-objects-defineownproperty-p-desc
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
(JSC::JSGenericTypedArrayView<Adaptor>::put):
(JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
(JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
(JSC::JSGenericTypedArrayView<Adaptor>::putByIndex):
* runtime/PropertyName.h:
(JSC::isCanonicalNumericIndexString):
2019-05-03 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Need to emit SetLocal if we emit MovHint in DFGByteCodeParser
https://bugs.webkit.org/show_bug.cgi?id=197584
Reviewed by Saam Barati.
In r244864, we emit MovHint for adhocly created GetterCall/SetterCall frame locals in the callee side to make OSR availability analysis's pruning correct.
However, we just emit MovHint, and we do not emit SetLocal since we ensured that these locals are already flushed in the same place before. However, MovHint
and SetLocal are needed to be a pair in DFGByteCodeParser because we rely on this assumption in SSA conversion phase. SSA conversion phase always emit KillStack
just before MovHint's target location even if the MovHint's target is the same to the previously emitted MovHint and SetLocal.
This patch emits SetLocal too when emitting MovHint for GetterCall/SetterCall frame locals.
The example is like this.
a: SomeValueNode
: MovHint(@a, loc10)
b: SetLocal(@a, loc10)
...
c: MovHint(@a, loc10)
Then, this will be converted to the style in SSA conversion.
a: SomeValueNode
: KillStack(loc10)
b: PutStack(@a, loc10)
...
c: KillStack(loc10)
Then, @b will be removed later since @c kills it.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::inlineCall):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::MarkedBlock):
(JSC::MarkedBlock::Handle::stopAllocating):
(JSC::MarkedBlock::Handle::resumeAllocating):
(JSC::MarkedBlock::aboutToMarkSlow):
(JSC::MarkedBlock::Handle::didConsumeFreeList):
2019-05-03 Devin Rousso <drousso@apple.com>
Web Inspector: DOM: rename "low power" to "display composited"
https://bugs.webkit.org/show_bug.cgi?id=197296
Reviewed by Joseph Pecoraro.
Removed specific ChangeLog entries since it is almost entirely mechanical changes.
* inspector/protocol/DOM.json:
2019-05-03 Basuke Suzuki <Basuke.Suzuki@sony.com>
[WinCairo] Implement and enable RemoteInspector Server.
https://bugs.webkit.org/show_bug.cgi?id=197432
Reviewed by Ross Kirsling.
Implement Windows implementation for Socket Backend of RemoteInspector and enable it on WinCairo
for experimental feature.
Also add listener interface for connection between RemoteInspector and RemoteInspectorServer
for flexible configuration.
* PlatformWin.cmake:
* inspector/remote/RemoteInspector.h:
* inspector/remote/socket/RemoteInspectorConnectionClient.h:
(Inspector::RemoteInspectorConnectionClient::didAccept):
* inspector/remote/socket/RemoteInspectorServer.cpp:
(Inspector::RemoteInspectorServer::connect):
(Inspector::RemoteInspectorServer::listenForTargets):
(Inspector::RemoteInspectorServer::didAccept):
(Inspector::RemoteInspectorServer::dispatchMap):
(Inspector::RemoteInspectorServer::start):
(Inspector::RemoteInspectorServer::addServerConnection): Deleted.
* inspector/remote/socket/RemoteInspectorServer.h:
(Inspector::RemoteInspectorServer::RemoteInspectorServer):
* inspector/remote/socket/RemoteInspectorSocket.cpp:
(Inspector::RemoteInspector::RemoteInspector):
(Inspector::RemoteInspector::dispatchMap):
(Inspector::RemoteInspector::start):
(Inspector::RemoteInspector::stopInternal):
(Inspector::RemoteInspector::setServerPort):
* inspector/remote/socket/RemoteInspectorSocket.h:
* inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp:
(Inspector::RemoteInspectorSocketEndpoint::listenInet):
(Inspector::RemoteInspectorSocketEndpoint::getPort const):
(Inspector::RemoteInspectorSocketEndpoint::acceptInetSocketIfEnabled):
* inspector/remote/socket/RemoteInspectorSocketEndpoint.h:
* inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp:
(Inspector::Socket::init): Added.
(Inspector::Socket::listen): Signature changed.
(Inspector::Socket::getPort): Added.
* inspector/remote/socket/win/RemoteInspectorSocketWin.cpp: Added.
(Inspector::Socket::init):
(Inspector::Socket::Socket::Socket):
(Inspector::Socket::Socket::~Socket):
(Inspector::Socket::Socket::close):
(Inspector::Socket::Socket::operator PlatformSocketType const):
(Inspector::Socket::Socket::operator bool const):
(Inspector::Socket::Socket::leak):
(Inspector::Socket::Socket::create):
(Inspector::Socket::setOpt):
(Inspector::Socket::setOptEnabled):
(Inspector::Socket::enableOpt):
(Inspector::Socket::connectTo):
(Inspector::Socket::bindAndListen):
(Inspector::Socket::connect):
(Inspector::Socket::listen):
(Inspector::Socket::accept):
(Inspector::Socket::createPair):
(Inspector::Socket::setup):
(Inspector::Socket::isValid):
(Inspector::Socket::isListening):
(Inspector::Socket::getPort):
(Inspector::Socket::read):
(Inspector::Socket::write):
(Inspector::Socket::close):
(Inspector::Socket::preparePolling):
(Inspector::Socket::poll):
(Inspector::Socket::isReadable):
(Inspector::Socket::isWritable):
(Inspector::Socket::markWaitingWritable):
(Inspector::Socket::clearWaitingWritable):
2019-05-03 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Generator CodeBlock generation should be idempotent
https://bugs.webkit.org/show_bug.cgi?id=197552
Reviewed by Keith Miller.
ES6 Generator saves and resumes the current execution state. Since ES6 generator can save the execution state at expression
granularity (not statement granularity), the saved state involves locals. But if the underlying CodeBlock is jettisoned and
recompiled with different code generation option (like, debugger, type profiler etc.), the generated instructions can be largely
different and it does not have the same state previously used. If we resume the previously created generator with the newly
generator function, resuming is messed up.
function* gen () { ... }
var g = gen();
g.next();
// CodeBlock is destroyed & Debugger is enabled.
g.next();
In this patch,
1. In generatorification, we use index Identifier (localN => Identifier("N")) instead of private symbols to generate the same
instructions every time we regenerate the CodeBlock.
2. We decouple the options which can affect on the generated code (Debugger, TypeProfiler, ControlFlowProfiler) from the BytecodeGenerator,
and pass them as a parameter, OptionSet<CodeGeneratorMode>.
3. Generator ScriptExecutable remembers the previous CodeGeneratorMode and reuses this parameter to regenerate CodeBlock. It means that,
even if the debugger is enabled, previously created generators are not debuggable. But newly created generators are debuggable.
* bytecode/BytecodeGeneratorification.cpp:
(JSC::BytecodeGeneratorification::storageForGeneratorLocal):
(JSC::BytecodeGeneratorification::run):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::setConstantRegisters):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::wasCompiledWithDebuggingOpcodes const):
(JSC::UnlinkedCodeBlock::wasCompiledWithTypeProfilerOpcodes const):
(JSC::UnlinkedCodeBlock::wasCompiledWithControlFlowProfilerOpcodes const):
(JSC::UnlinkedCodeBlock::codeGenerationMode const):
* bytecode/UnlinkedEvalCodeBlock.h:
* bytecode/UnlinkedFunctionCodeBlock.h:
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::generateUnlinkedFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecode/UnlinkedGlobalCodeBlock.h:
(JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock):
* bytecode/UnlinkedModuleProgramCodeBlock.h:
* bytecode/UnlinkedProgramCodeBlock.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitTypeProfilerExpressionInfo):
(JSC::BytecodeGenerator::emitProfileType):
(JSC::BytecodeGenerator::emitProfileControlFlow):
(JSC::BytecodeGenerator::pushLexicalScopeInternal):
(JSC::BytecodeGenerator::popLexicalScopeInternal):
(JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
(JSC::BytecodeGenerator::emitCall):
(JSC::BytecodeGenerator::emitCallVarargs):
(JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary):
(JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary):
(JSC::BytecodeGenerator::emitDebugHook):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::shouldEmitDebugHooks const):
(JSC::BytecodeGenerator::shouldEmitTypeProfilerHooks const):
(JSC::BytecodeGenerator::shouldEmitControlFlowProfilerHooks const):
* bytecompiler/NodesCodegen.cpp:
(JSC::PrefixNode::emitResolve):
(JSC::EmptyVarExpression::emitBytecode):
(JSC::ReturnNode::emitBytecode):
(JSC::FunctionNode::emitBytecode):
* parser/ParserModes.h:
(): Deleted.
* parser/SourceCodeKey.h:
(JSC::SourceCodeFlags::SourceCodeFlags):
(JSC::SourceCodeKey::SourceCodeKey):
* runtime/CachedTypes.cpp:
(JSC::CachedCodeBlock::isClassContext const):
(JSC::CachedCodeBlock::codeGenerationMode const):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
(JSC::CachedCodeBlock<CodeBlockType>::encode):
(JSC::CachedCodeBlock::wasCompiledWithDebuggingOpcodes const): Deleted.
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::getUnlinkedProgramCodeBlock):
(JSC::CodeCache::getUnlinkedEvalCodeBlock):
(JSC::CodeCache::getUnlinkedModuleProgramCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
(JSC::generateUnlinkedCodeBlockForFunctions):
(JSC::sourceCodeKeyForSerializedBytecode):
(JSC::sourceCodeKeyForSerializedProgram):
(JSC::sourceCodeKeyForSerializedModule):
(JSC::serializeBytecode):
* runtime/CodeCache.h:
(JSC::generateUnlinkedCodeBlockImpl):
(JSC::generateUnlinkedCodeBlock):
* runtime/Completion.cpp:
(JSC::generateProgramBytecode):
(JSC::generateModuleBytecode):
* runtime/DirectEvalExecutable.cpp:
(JSC::DirectEvalExecutable::create):
* runtime/IndirectEvalExecutable.cpp:
(JSC::IndirectEvalExecutable::create):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::defaultCodeGenerationMode const):
* runtime/ModuleProgramExecutable.cpp:
(JSC::ModuleProgramExecutable::create):
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties):
* runtime/ScriptExecutable.cpp:
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::newCodeBlockFor):
* runtime/ScriptExecutable.h:
* tools/JSDollarVM.cpp:
(JSC::changeDebuggerModeWhenIdle):
(JSC::functionEnableDebuggerModeWhenIdle):
(JSC::functionDisableDebuggerModeWhenIdle):
2019-05-03 Devin Rousso <drousso@apple.com>
Web Inspector: Record actions performed on WebGL2RenderingContext
https://bugs.webkit.org/show_bug.cgi?id=176008
<rdar://problem/34213884>
Reviewed by Joseph Pecoraro.
* inspector/protocol/Recording.json:
* inspector/scripts/codegen/generator.py:
Add `canvas-webgl2` as a `Type`.
2019-05-03 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r244881.
https://bugs.webkit.org/show_bug.cgi?id=197559
Breaks compilation of jsconly on linux, breaking compilation
for jsc-i386-ews, jsc-mips-ews and jsc-armv7-ews (Requested by
guijemont on #webkit).
Reverted changeset:
"[CMake] Refactor WEBKIT_MAKE_FORWARDING_HEADERS into
WEBKIT_COPY_FILES"
https://bugs.webkit.org/show_bug.cgi?id=197174
https://trac.webkit.org/changeset/244881
2019-05-02 Don Olmstead <don.olmstead@sony.com>
[CMake] Refactor WEBKIT_MAKE_FORWARDING_HEADERS into WEBKIT_COPY_FILES
https://bugs.webkit.org/show_bug.cgi?id=197174
Reviewed by Alex Christensen.
Replace WEBKIT_MAKE_FORWARDING_HEADERS with WEBKIT_COPY_FILES and make dependencies
for framework headers explicit.
* CMakeLists.txt:
2019-05-02 Michael Saboff <msaboff@apple.com>
Unreviewed rollout of r244862.
* runtime/JSObject.cpp:
(JSC::JSObject::getOwnPropertyDescriptor):
2019-05-01 Saam barati <sbarati@apple.com>
Baseline JIT should do argument value profiling after checking for stack overflow
https://bugs.webkit.org/show_bug.cgi?id=197052
<rdar://problem/50009602>
Reviewed by Yusuke Suzuki.
Otherwise, we may do value profiling without running a write barrier, which
is against the rules of how we do value profiling.
* jit/JIT.cpp:
(JSC::JIT::compileWithoutLinking):
2019-05-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Inlining Getter/Setter should care availability of ad-hocly constructed frame
https://bugs.webkit.org/show_bug.cgi?id=197405
Reviewed by Saam Barati.
When inlining getter and setter calls, we setup a stack frame which does not appear in the bytecode.
Because Inlining can switch on executable, we could have a graph like this.
BB#0
...
30: GetSetter
31: MovHint(loc10)
32: SetLocal(loc10)
33: MovHint(loc9)
34: SetLocal(loc9)
...
37: GetExecutable(@30)
...
41: Switch(@37)
BB#2
42: GetLocal(loc12, bc#7 of caller)
...
--> callee: loc9 and loc10 are arguments of callee.
...
<HERE, exit to callee, loc9 and loc10 are required in the bytecode>
When we prune OSR availability at the beginning of BB#2 (bc#7 in the caller), we prune loc9 and loc10's liveness because the caller does not actually have loc9 and loc10.
However, when we begin executing the callee, we need OSR exit to be aware of where it can recover the arguments to the setter, loc9 and loc10.
This patch inserts MovHint at the beginning of callee for a getter / setter stack frame to make arguments (loc9 and loc10 in the above example) recoverable from OSR exit.
We also move arity fixup DFG nodes from the caller to the callee, since moved arguments are not live in the caller too.
Interestingly, this fix also reveals the existing issue in LiveCatchVariablePreservationPhase. We emitted Flush for |this| of InlineCallFrame blindly if we saw InlineCallFrame
inside a block which is covered by catch handler. But this is wrong because inlined function can finish its execution within the block, and |this| is completely unrelated to
the catch handler if the catch handler is in the outer callee. We already collect all the live locals at the catch handler. And this locals must include arguments too if the
catch handler is in inlined function. So, we should not emit Flush for each |this| of seen InlineCallFrame. This emitted Flush may connect unrelated locals in the catch handler
to the locals that is only defined and used in the inlined function, and it leads to the results like DFG says the local is live while the bytecode says the local is dead.
This results in reading and using garbage in OSR entry because DFG OSR entry needs to fill live DFG values from the stack.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::inlineCall):
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::handlePutById):
* dfg/DFGLiveCatchVariablePreservationPhase.cpp:
(JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
2019-05-01 Michael Saboff <msaboff@apple.com>
ASSERTION FAILED: !m_needExceptionCheck with --validateExceptionChecks=1; ProxyObject.getOwnPropertySlotCommon/JSFunction.callerGetter
https://bugs.webkit.org/show_bug.cgi?id=197485
Reviewed by Saam Barati.
Added an EXCEPTION_ASSERT after call to getOwnPropertySlot().
* runtime/JSObject.cpp:
(JSC::JSObject::getOwnPropertyDescriptor):
2019-05-01 Ross Kirsling <ross.kirsling@sony.com>
RemoteInspector::updateAutomaticInspectionCandidate should have a default implementation.
https://bugs.webkit.org/show_bug.cgi?id=197439
Reviewed by Devin Rousso.
On non-Cocoa platforms, automatic inspection is not currently implemented,
so updateAutomaticInspectionCandidate falls back to the logic of updateTarget.
This logic already existed in three places, so refactor it into a common private method
and allow our websocket-based RWI implementation to make use of it too.
* inspector/remote/RemoteInspector.cpp:
(Inspector::RemoteInspector::updateTarget):
(Inspector::RemoteInspector::updateTargetMap):
(Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
* inspector/remote/RemoteInspector.h:
* inspector/remote/cocoa/RemoteInspectorCocoa.mm:
(Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
* inspector/remote/glib/RemoteInspectorGlib.cpp:
(Inspector::RemoteInspector::updateAutomaticInspectionCandidate): Deleted.
* inspector/remote/socket/RemoteInspectorSocket.cpp:
(Inspector::RemoteInspector::updateAutomaticInspectionCandidate): Deleted.
2019-05-01 Darin Adler <darin@apple.com>
WebKit has too much of its own UTF-8 code and should rely more on ICU's UTF-8 support
https://bugs.webkit.org/show_bug.cgi?id=195535
Reviewed by Alexey Proskuryakov.
* API/JSClassRef.cpp: Removed uneeded include of UTF8Conversion.h.
* API/JSStringRef.cpp:
(JSStringCreateWithUTF8CString): Updated for changes to convertUTF8ToUTF16.
(JSStringGetUTF8CString): Updated for changes to convertLatin1ToUTF8.
Removed unneeded "true" to get the strict version of convertUTF16ToUTF8,
since that is the default. Also updated for changes to CompletionResult.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::decode): Stop using UTF8SequenceLength, and instead use U8_COUNT_TRAIL_BYTES
and U8_MAX_LENGTH. Instead of decodeUTF8Sequence, use U8_NEXT. Also use U_IS_BMP,
U_IS_SUPPLEMENTARY, U16_LEAD, U16_TRAIL, and U_IS_SURROGATE instead of our own
equivalents, since these macros from ICU are correct and efficient.
* wasm/WasmParser.h:
(JSC::Wasm::Parser<SuccessType>::consumeUTF8String): Updated for changes to
convertUTF8ToUTF16.
2019-05-01 Shawn Roberts <sroberts@apple.com>
Unreviewed, rolling out r244821.
Causing
Reverted changeset:
"WebKit has too much of its own UTF-8 code and should rely
more on ICU's UTF-8 support"
https://bugs.webkit.org/show_bug.cgi?id=195535
https://trac.webkit.org/changeset/244821
2019-04-29 Darin Adler <darin@apple.com>
WebKit has too much of its own UTF-8 code and should rely more on ICU's UTF-8 support
https://bugs.webkit.org/show_bug.cgi?id=195535
Reviewed by Alexey Proskuryakov.
* API/JSClassRef.cpp: Removed uneeded include of UTF8Conversion.h.
* API/JSStringRef.cpp:
(JSStringCreateWithUTF8CString): Updated for changes to convertUTF8ToUTF16.
(JSStringGetUTF8CString): Updated for changes to convertLatin1ToUTF8.
Removed unneeded "true" to get the strict version of convertUTF16ToUTF8,
since that is the default. Also updated for changes to CompletionResult.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::decode): Stop using UTF8SequenceLength, and instead use U8_COUNT_TRAIL_BYTES
and U8_MAX_LENGTH. Instead of decodeUTF8Sequence, use U8_NEXT. Also use U_IS_BMP,
U_IS_SUPPLEMENTARY, U16_LEAD, U16_TRAIL, and U_IS_SURROGATE instead of our own
equivalents, since these macros from ICU are correct and efficient.
* wasm/WasmParser.h:
(JSC::Wasm::Parser<SuccessType>::consumeUTF8String): Updated for changes to
convertUTF8ToUTF16.
2019-04-30 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r244806.
https://bugs.webkit.org/show_bug.cgi?id=197446
Causing Test262 and JSC test failures on multiple builds
(Requested by ShawnRoberts on #webkit).
Reverted changeset:
"TypeArrays should not store properties that are canonical
numeric indices"
https://bugs.webkit.org/show_bug.cgi?id=197228
https://trac.webkit.org/changeset/244806
2019-04-30 Saam barati <sbarati@apple.com>
CodeBlock::m_instructionCount is wrong
https://bugs.webkit.org/show_bug.cgi?id=197304
Reviewed by Yusuke Suzuki.
What we were calling instructionCount() was wrong, as evidenced by
us using it incorrectly both in the sampling profiler and when we
dumped bytecode for a given CodeBlock. Prior to the bytecode rewrite,
instructionCount() was probably valid to do bounds checks against.
However, this is no longer the case. This patch renames what we called
instructionCount() to bytecodeCost(). It is now only used to make decisions
about inlining and tier up heuristics. I've also named options related to
this appropriately.
This patch also introduces instructionsSize(). The result of this method
is valid to do bounds checks against.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpAssumingJITType const):
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::optimizationThresholdScalingFactor):
(JSC::CodeBlock::predictedMachineCodeSize):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::instructionsSize const):
(JSC::CodeBlock::bytecodeCost const):
(JSC::CodeBlock::instructionCount const): Deleted.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::inliningCost):
(JSC::DFG::ByteCodeParser::getInliningBalance):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::mightCompileEval):
(JSC::DFG::mightCompileProgram):
(JSC::DFG::mightCompileFunctionForCall):
(JSC::DFG::mightCompileFunctionForConstruct):
(JSC::DFG::mightInlineFunctionForCall):
(JSC::DFG::mightInlineFunctionForClosureCall):
(JSC::DFG::mightInlineFunctionForConstruct):
* dfg/DFGCapabilities.h:
(JSC::DFG::isSmallEnoughToInlineCodeInto):
* dfg/DFGDisassembler.cpp:
(JSC::DFG::Disassembler::dumpHeader):
* dfg/DFGDriver.cpp:
(JSC::DFG::compileImpl):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThread):
* dfg/DFGTierUpCheckInjectionPhase.cpp:
(JSC::DFG::TierUpCheckInjectionPhase::run):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* jit/JIT.cpp:
(JSC::JIT::link):
* jit/JITDisassembler.cpp:
(JSC::JITDisassembler::dumpHeader):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::shouldJIT):
* profiler/ProfilerBytecodes.cpp:
(JSC::Profiler::Bytecodes::Bytecodes):
* runtime/Options.h:
* runtime/SamplingProfiler.cpp:
(JSC::tryGetBytecodeIndex):
(JSC::SamplingProfiler::processUnverifiedStackTraces):
2019-04-30 Tadeu Zagallo <tzagallo@apple.com>
TypeArrays should not store properties that are canonical numeric indices
https://bugs.webkit.org/show_bug.cgi?id=197228
<rdar://problem/49557381>
Reviewed by Darin Adler.
According to the spec[1], TypedArrays should not perform an ordinary GetOwnProperty/SetOwnProperty
if the index is a CanonicalNumericIndexString, but invalid according toIntegerIndexedElementGet
and similar functions. I.e., there are a few properties that should not be set in a TypedArray,
like NaN, Infinity and -0.
[1]: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-integer-indexed-exotic-objects-defineownproperty-p-desc
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
(JSC::JSGenericTypedArrayView<Adaptor>::put):
(JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
(JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
(JSC::JSGenericTypedArrayView<Adaptor>::putByIndex):
* runtime/JSTypedArrays.cpp:
* runtime/PropertyName.h:
(JSC::canonicalNumericIndexString):
2019-04-30 Brian Burg <bburg@apple.com>
Web Automation: use a more informative key to indicate automation availability
https://bugs.webkit.org/show_bug.cgi?id=197377
<rdar://problem/50258069>
Reviewed by Devin Rousso.
The existing WIRAutomationEnabledKey does not encode uncertainty.
Add a new key that provides an 'Unknown' state, and prefer to use it.
Since an application's initial listing is sent from a background dispatch queue
on Cocoa platforms, this can race with main thread initialization that sets up
RemoteInspector::Client. Therefore, the initial listing may not properly represent
the client's capabilites because the client is not yet available. Allowing for
an "Unknown" state that is later upgraded to Available or Not Available makes it
possible to work around this potential race.
* inspector/remote/RemoteInspectorConstants.h:
* inspector/remote/cocoa/RemoteInspectorCocoa.mm:
(Inspector::RemoteInspector::pushListingsNow):
2019-04-30 Keith Miller <keith_miller@apple.com>
Fix failing ARM64E wasm tests
https://bugs.webkit.org/show_bug.cgi?id=197420
Reviewed by Saam Barati.
This patch fixes a bug in the slow path of our JS->Wasm IC bridge
where we wouldn't untag the link register before tail calling.
Additionally, this patch fixes a broken assert when using setting
Options::useTailCalls=false.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::jsCallEntrypointSlow):
2019-04-29 Saam Barati <sbarati@apple.com>
Make JITType an enum class
https://bugs.webkit.org/show_bug.cgi?id=197394
Reviewed by Yusuke Suzuki.
This makes the code more easily searchable.
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFor):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpAssumingJITType const):
(JSC::CodeBlock::specialOSREntryBlockOrNull):
(JSC::timeToLive):
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::baselineAlternative):
(JSC::CodeBlock::baselineVersion):
(JSC::CodeBlock::hasOptimizedReplacement):
(JSC::CodeBlock::noticeIncomingCall):
(JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult):
(JSC::CodeBlock::tallyFrequentExitSites):
(JSC::CodeBlock::frameRegisterCount):
(JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::jitType const):
(JSC::CodeBlock::hasBaselineJITProfiling const):
* bytecode/CodeBlockWithJITType.h:
(JSC::CodeBlockWithJITType::CodeBlockWithJITType):
* bytecode/DeferredSourceDump.cpp:
(JSC::DeferredSourceDump::DeferredSourceDump):
* bytecode/DeferredSourceDump.h:
* bytecode/ExitingJITType.h:
(JSC::exitingJITTypeFor):
* bytecode/InlineCallFrame.h:
(JSC::baselineCodeBlockForOriginAndBaselineCodeBlock):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseCodeBlock):
* dfg/DFGDisassembler.cpp:
(JSC::DFG::Disassembler::dumpHeader):
* dfg/DFGDriver.cpp:
(JSC::DFG::compileImpl):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
* dfg/DFGJITCode.cpp:
(JSC::DFG::JITCode::JITCode):
(JSC::DFG::JITCode::checkIfOptimizationThresholdReached):
(JSC::DFG::JITCode::optimizeNextInvocation):
(JSC::DFG::JITCode::dontOptimizeAnytimeSoon):
(JSC::DFG::JITCode::optimizeAfterWarmUp):
(JSC::DFG::JITCode::optimizeSoon):
(JSC::DFG::JITCode::forceOptimizationSlowPathConcurrently):
(JSC::DFG::JITCode::setOptimizationThresholdBasedOnCompilationResult):
* dfg/DFGJITFinalizer.cpp:
(JSC::DFG::JITFinalizer::finalize):
(JSC::DFG::JITFinalizer::finalizeFunction):
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareOSREntry):
(JSC::DFG::prepareCatchOSREntry):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::executeOSRExit):
(JSC::DFG::reifyInlinedCallFrames):
(JSC::DFG::OSRExit::compileOSRExit):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::handleExitCounts):
(JSC::DFG::reifyInlinedCallFrames):
(JSC::DFG::adjustAndJumpToTarget):
* dfg/DFGOSRExitCompilerCommon.h:
(JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
* dfg/DFGOperations.cpp:
* dfg/DFGThunks.cpp:
(JSC::DFG::osrExitGenerationThunkGenerator):
* dfg/DFGVariableEventStream.cpp:
(JSC::DFG::VariableEventStream::reconstruct const):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::JITCode):
* ftl/FTLJITFinalizer.cpp:
(JSC::FTL::JITFinalizer::finalizeCommon):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileFTLOSRExit):
* ftl/FTLThunks.cpp:
(JSC::FTL::genericGenerationThunkGenerator):
* interpreter/CallFrame.cpp:
(JSC::CallFrame::callSiteBitsAreBytecodeOffset const):
(JSC::CallFrame::callSiteBitsAreCodeOriginIndex const):
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::dump const):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::AssemblyHelpers):
* jit/JIT.cpp:
(JSC::JIT::link):
* jit/JITCode.cpp:
(JSC::JITCode::typeName):
(WTF::printInternal):
* jit/JITCode.h:
(JSC::JITCode::bottomTierJIT):
(JSC::JITCode::topTierJIT):
(JSC::JITCode::nextTierJIT):
(JSC::JITCode::isExecutableScript):
(JSC::JITCode::couldBeInterpreted):
(JSC::JITCode::isJIT):
(JSC::JITCode::isOptimizingJIT):
(JSC::JITCode::isBaselineCode):
(JSC::JITCode::jitTypeFor):
* jit/JITDisassembler.cpp:
(JSC::JITDisassembler::dumpHeader):
* jit/JITOperations.cpp:
* jit/JITThunks.cpp:
(JSC::JITThunks::hostFunctionStub):
* jit/JITToDFGDeferredCompilationCallback.cpp:
(JSC::JITToDFGDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
(JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
* jit/JITWorklist.cpp:
(JSC::JITWorklist::compileLater):
(JSC::JITWorklist::compileNow):
* jit/Repatch.cpp:
(JSC::readPutICCallTarget):
(JSC::ftlThunkAwareRepatchCall):
* llint/LLIntEntrypoint.cpp:
(JSC::LLInt::setFunctionEntrypoint):
(JSC::LLInt::setEvalEntrypoint):
(JSC::LLInt::setProgramEntrypoint):
(JSC::LLInt::setModuleProgramEntrypoint):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::jitCompileAndSetHeuristics):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::processUnverifiedStackTraces):
* runtime/SamplingProfiler.h:
* runtime/VM.cpp:
(JSC::jitCodeForCallTrampoline):
(JSC::jitCodeForConstructTrampoline):
* tools/CodeProfile.cpp:
(JSC::CodeProfile::sample):
* tools/JSDollarVM.cpp:
(JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
(JSC::CallerFrameJITTypeFunctor::jitType):
(JSC::functionLLintTrue):
(JSC::functionJITTrue):
2019-04-29 Yusuke Suzuki <ysuzuki@apple.com>
Unreivewed, fix FTL implementation of r244760
https://bugs.webkit.org/show_bug.cgi?id=197362
Reviewed by Saam Barati.
Looked with Saam. ValueFromBlock from double case block was overridden by NaN thing now.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNormalizeMapKey):
2019-04-29 Yusuke Suzuki <ysuzuki@apple.com>
normalizeMapKey should normalize NaN to one PureNaN bit pattern to make MapHash same
https://bugs.webkit.org/show_bug.cgi?id=197362
Reviewed by Saam Barati.
Our Map/Set's hash algorithm relies on the bit pattern of JSValue. So our Map/Set has
normalization of the key, which normalizes Int32 / Double etc. But we did not normalize
pure NaNs into one canonicalized pure NaN. So we end up having multiple different pure NaNs
in one Map/Set. This patch normalizes NaN into one jsNaN(), which uses PNaN for the representation.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNormalizeMapKey):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNormalizeMapKey):
* runtime/HashMapImpl.h:
(JSC::normalizeMapKey):
2019-04-29 Alex Christensen <achristensen@webkit.org>
<rdar://problem/50299396> Fix internal High Sierra build
https://bugs.webkit.org/show_bug.cgi?id=197388
* Configurations/Base.xcconfig:
2019-04-29 Yusuke Suzuki <ysuzuki@apple.com>
JITStubRoutineSet wastes 180KB of HashTable capacity on can.com
https://bugs.webkit.org/show_bug.cgi?id=186732
Reviewed by Saam Barati.
Our current mechanism of JITStubRoutineSet consumes more memory than needed. Basically we have HashMap<uintptr_t, StubRoutine*> and register
each executable address by 16 byte to this entry. So if your StubRoutine has 128bytes, it just adds 8 entries to this hash table.
In Gmail, we see a ~2MB table size.
Instead, this patch uses Vector<pair<uintptr_t, StubRoutine*>> and performs binary search onto this sorted vector. Before conservative
scanning, we sort this vector. And doing binary search with the sorted vector to find executing stub routines from the conservative roots.
This vector includes uintptr_t startAddress to make binary searching fast.
Large amount of conservative scan should be filtered by range check, so I think binary search here is OK, but we can decide based on what the
performance bots say.
* heap/Heap.cpp:
(JSC::Heap::addCoreConstraints):
* heap/JITStubRoutineSet.cpp:
(JSC::JITStubRoutineSet::~JITStubRoutineSet):
(JSC::JITStubRoutineSet::add):
(JSC::JITStubRoutineSet::prepareForConservativeScan):
(JSC::JITStubRoutineSet::clearMarks):
(JSC::JITStubRoutineSet::markSlow):
(JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines):
(JSC::JITStubRoutineSet::traceMarkedStubRoutines):
* heap/JITStubRoutineSet.h:
(JSC::JITStubRoutineSet::mark):
(JSC::JITStubRoutineSet::prepareForConservativeScan):
(JSC::JITStubRoutineSet::size const): Deleted.
(JSC::JITStubRoutineSet::at const): Deleted.
2019-04-29 Basuke Suzuki <Basuke.Suzuki@sony.com>
[Win] Add flag to enable version information stamping and disable by default.
https://bugs.webkit.org/show_bug.cgi?id=197249
<rdar://problem/50224412>
Reviewed by Ross Kirsling.
This feature is only used in AppleWin port. Add flag for this task and make it OFF by default.
Then enable it by default on AppleWin.
* CMakeLists.txt:
2019-04-26 Keith Rollin <krollin@apple.com>
Enable new build rule for post-processing headers when using XCBuild
https://bugs.webkit.org/show_bug.cgi?id=197340
<rdar://problem/50226685>
Reviewed by Brent Fulgham.
In Bug 197116, we conditionally disabled the old method for
post-processing header files when we are using the new XCBuild build
system. This check-in conditionally enables the new post-processing
facility. Note that the old system is disabled and the new system
enabled only when the USE_NEW_BUILD_SYSTEM environment variable is set
to YES.
* Configurations/JavaScriptCore.xcconfig:
2019-04-26 Jessie Berlin <jberlin@webkit.org>
Add new mac target numbers
https://bugs.webkit.org/show_bug.cgi?id=197313
Reviewed by Alex Christensen.
* Configurations/Version.xcconfig:
* Configurations/WebKitTargetConditionals.xcconfig:
2019-04-26 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r244708.
https://bugs.webkit.org/show_bug.cgi?id=197334
"Broke the debug build" (Requested by rmorisset on #webkit).
Reverted changeset:
"All prototypes should call didBecomePrototype()"
https://bugs.webkit.org/show_bug.cgi?id=196315
https://trac.webkit.org/changeset/244708
2019-04-26 Don Olmstead <don.olmstead@sony.com>
[CMake] Add WEBKIT_EXECUTABLE macro
https://bugs.webkit.org/show_bug.cgi?id=197206
Reviewed by Konstantin Tokarev.
Migrate to WEBKIT_EXECUTABLE for the jsc and test targets.
* b3/air/testair.cpp:
* b3/testb3.cpp:
* dfg/testdfg.cpp:
* shell/CMakeLists.txt:
* shell/PlatformGTK.cmake:
* shell/PlatformJSCOnly.cmake: Removed.
* shell/PlatformMac.cmake:
* shell/PlatformPlayStation.cmake:
* shell/PlatformWPE.cmake:
* shell/PlatformWin.cmake:
2019-04-25 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] linkPolymorphicCall now does GC
https://bugs.webkit.org/show_bug.cgi?id=197306
Reviewed by Saam Barati.
Previously, we assumed that linkPolymorphicCall does not perform allocations. So we put CallVariant into a Vector<>.
But now, WebAssemblyFunction's entrypoint generation can allocate JSToWasmICCallee and cause GC. Since CallLinkInfo
does not hold these cells, they can be collected, and we will see dead cells in the middle of linkPolymorphicCall.
We should defer GC for a while in linkPolymorphicCall. We use DeferGCForAWhile instead of DeferGC because the
caller "operationLinkPolymorphicCall" assumes that this function does not cause GC.
* jit/Repatch.cpp:
(JSC::linkPolymorphicCall):
2019-04-26 Robin Morisset <rmorisset@apple.com>
All prototypes should call didBecomePrototype()
https://bugs.webkit.org/show_bug.cgi?id=196315
Reviewed by Saam Barati.
Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor.
I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't
create structures with invalid prototypes.
It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation().
Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype.
* runtime/BigIntPrototype.cpp:
(JSC::BigIntPrototype::finishCreation):
* runtime/BooleanPrototype.cpp:
(JSC::BooleanPrototype::finishCreation):
* runtime/DatePrototype.cpp:
(JSC::DatePrototype::finishCreation):
* runtime/ErrorConstructor.cpp:
(JSC::ErrorConstructor::finishCreation):
* runtime/ErrorPrototype.cpp:
(JSC::ErrorPrototype::finishCreation):
* runtime/FunctionConstructor.cpp:
(JSC::FunctionConstructor::finishCreation):
* runtime/FunctionPrototype.cpp:
(JSC::FunctionPrototype::finishCreation):
* runtime/IntlCollatorPrototype.cpp:
(JSC::IntlCollatorPrototype::finishCreation):
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::IntlDateTimeFormatPrototype::finishCreation):
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::IntlNumberFormatPrototype::finishCreation):
* runtime/IntlPluralRulesPrototype.cpp:
(JSC::IntlPluralRulesPrototype::finishCreation):
* runtime/JSArrayBufferPrototype.cpp:
(JSC::JSArrayBufferPrototype::finishCreation):
* runtime/JSDataViewPrototype.cpp:
(JSC::JSDataViewPrototype::finishCreation):
* runtime/JSGenericTypedArrayViewPrototypeInlines.h:
(JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
* runtime/JSGlobalObject.cpp:
(JSC::createConsoleProperty):
* runtime/JSPromisePrototype.cpp:
(JSC::JSPromisePrototype::finishCreation):
* runtime/JSTypedArrayViewConstructor.cpp:
(JSC::JSTypedArrayViewConstructor::finishCreation):
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::JSTypedArrayViewPrototype::finishCreation):
* runtime/NumberPrototype.cpp:
(JSC::NumberPrototype::finishCreation):
* runtime/RegExpPrototype.cpp:
(JSC::RegExpPrototype::finishCreation):
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
* runtime/Structure.cpp:
(JSC::Structure::isValidPrototype):
(JSC::Structure::changePrototypeTransition):
* runtime/Structure.h:
* runtime/SymbolPrototype.cpp:
(JSC::SymbolPrototype::finishCreation):
* wasm/js/WebAssemblyCompileErrorPrototype.cpp:
(JSC::WebAssemblyCompileErrorPrototype::finishCreation):
* wasm/js/WebAssemblyInstancePrototype.cpp:
(JSC::WebAssemblyInstancePrototype::finishCreation):
* wasm/js/WebAssemblyLinkErrorPrototype.cpp:
(JSC::WebAssemblyLinkErrorPrototype::finishCreation):
* wasm/js/WebAssemblyMemoryPrototype.cpp:
(JSC::WebAssemblyMemoryPrototype::finishCreation):
* wasm/js/WebAssemblyModulePrototype.cpp:
(JSC::WebAssemblyModulePrototype::finishCreation):
* wasm/js/WebAssemblyPrototype.cpp:
(JSC::WebAssemblyPrototype::finishCreation):
* wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
(JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
* wasm/js/WebAssemblyTablePrototype.cpp:
(JSC::WebAssemblyTablePrototype::finishCreation):
2019-04-26 Don Olmstead <don.olmstead@sony.com>
Add WTF::findIgnoringASCIICaseWithoutLength to replace strcasestr
https://bugs.webkit.org/show_bug.cgi?id=197291
Reviewed by Konstantin Tokarev.
Replace uses of strcasestr with WTF::findIgnoringASCIICaseWithoutLength.
* API/tests/testapi.cpp:
* assembler/testmasm.cpp:
* b3/air/testair.cpp:
* b3/testb3.cpp:
* dfg/testdfg.cpp:
* dynbench.cpp:
2019-04-25 Fujii Hironori <Hironori.Fujii@sony.com>
Unreviewed, rolling out r244669.
Windows ports can't clean build.
Reverted changeset:
"[Win] Add flag to enable version information stamping and
disable by default."
https://bugs.webkit.org/show_bug.cgi?id=197249
https://trac.webkit.org/changeset/244669
2019-04-25 Basuke Suzuki <Basuke.Suzuki@sony.com>
[Win] Add flag to enable version information stamping and disable by default.
https://bugs.webkit.org/show_bug.cgi?id=197249
Reviewed by Ross Kirsling.
This feature is only used in AppleWin port. Add flag for this task and make it OFF by default.
Then enable it by default on AppleWin.
* CMakeLists.txt:
2019-04-25 Timothy Hatcher <timothy@apple.com>
Disable date and time inputs on iOSMac.
https://bugs.webkit.org/show_bug.cgi?id=197287
rdar://problem/46794376
Reviewed by Wenson Hsieh.
* Configurations/FeatureDefines.xcconfig:
2019-04-25 Alex Christensen <achristensen@webkit.org>
Fix more builds after r244653
https://bugs.webkit.org/show_bug.cgi?id=197131
* b3/B3Value.h:
There is an older system with libc++ headers that don't have std::conjunction. Just use constexpr and && instead for the one use of it in WebKit.
2019-04-25 Basuke Suzuki <Basuke.Suzuki@sony.com>
[RemoteInspector] Fix connection and target identifier types.
https://bugs.webkit.org/show_bug.cgi?id=197243
Reviewed by Ross Kirsling.
Give dedicated type for RemoteControllableTarget's identifier as Inspector::TargetID.
Also rename ClientID type used in Socket backend to ConnectionID because this is the identifier
socket endpoint assign to the newly created connection. The size was changed to uint32_t.
Enough size for managing connections.
* inspector/remote/RemoteConnectionToTarget.cpp:
(Inspector::RemoteConnectionToTarget::setup):
(Inspector::RemoteConnectionToTarget::close):
(Inspector::RemoteConnectionToTarget::targetIdentifier const):
* inspector/remote/RemoteConnectionToTarget.h:
* inspector/remote/RemoteControllableTarget.h:
* inspector/remote/RemoteInspector.cpp:
(Inspector::RemoteInspector::nextAvailableTargetIdentifier):
(Inspector::RemoteInspector::registerTarget):
(Inspector::RemoteInspector::unregisterTarget):
(Inspector::RemoteInspector::updateTarget):
(Inspector::RemoteInspector::setupFailed):
(Inspector::RemoteInspector::setupCompleted):
(Inspector::RemoteInspector::waitingForAutomaticInspection):
(Inspector::RemoteInspector::updateTargetListing):
* inspector/remote/RemoteInspector.h:
* inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
(Inspector::RemoteConnectionToTarget::targetIdentifier const):
(Inspector::RemoteConnectionToTarget::setup):
(Inspector::RemoteConnectionToTarget::close):
* inspector/remote/cocoa/RemoteInspectorCocoa.mm:
(Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
(Inspector::RemoteInspector::sendMessageToRemote):
(Inspector::RemoteInspector::receivedSetupMessage):
(Inspector::RemoteInspector::receivedDataMessage):
(Inspector::RemoteInspector::receivedDidCloseMessage):
(Inspector::RemoteInspector::receivedIndicateMessage):
(Inspector::RemoteInspector::receivedAutomaticInspectionRejectMessage):
* inspector/remote/glib/RemoteInspectorGlib.cpp:
(Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
(Inspector::RemoteInspector::sendMessageToRemote):
(Inspector::RemoteInspector::receivedSetupMessage):
(Inspector::RemoteInspector::receivedDataMessage):
(Inspector::RemoteInspector::receivedCloseMessage):
(Inspector::RemoteInspector::setup):
(Inspector::RemoteInspector::sendMessageToTarget):
* inspector/remote/socket/RemoteInspectorConnectionClient.cpp:
(Inspector::RemoteInspectorConnectionClient::didReceiveWebInspectorEvent):
* inspector/remote/socket/RemoteInspectorConnectionClient.h:
(Inspector::RemoteInspectorConnectionClient::didAccept):
* inspector/remote/socket/RemoteInspectorMessageParser.cpp:
(Inspector::MessageParser::MessageParser):
(Inspector::MessageParser::parse):
* inspector/remote/socket/RemoteInspectorMessageParser.h:
(Inspector::MessageParser::setDidParseMessageListener):
* inspector/remote/socket/RemoteInspectorServer.cpp:
(Inspector::RemoteInspectorServer::didAccept):
(Inspector::RemoteInspectorServer::didClose):
(Inspector::RemoteInspectorServer::dispatchMap):
(Inspector::RemoteInspectorServer::sendWebInspectorEvent):
(Inspector::RemoteInspectorServer::sendCloseEvent):
(Inspector::RemoteInspectorServer::connectionClosed):
* inspector/remote/socket/RemoteInspectorServer.h:
* inspector/remote/socket/RemoteInspectorSocket.cpp:
(Inspector::RemoteInspector::didClose):
(Inspector::RemoteInspector::sendMessageToRemote):
(Inspector::RemoteInspector::setup):
(Inspector::RemoteInspector::sendMessageToTarget):
* inspector/remote/socket/RemoteInspectorSocket.h:
* inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp:
(Inspector::RemoteInspectorSocketEndpoint::connectInet):
(Inspector::RemoteInspectorSocketEndpoint::isListening):
(Inspector::RemoteInspectorSocketEndpoint::workerThread):
(Inspector::RemoteInspectorSocketEndpoint::createClient):
(Inspector::RemoteInspectorSocketEndpoint::recvIfEnabled):
(Inspector::RemoteInspectorSocketEndpoint::sendIfEnabled):
(Inspector::RemoteInspectorSocketEndpoint::send):
(Inspector::RemoteInspectorSocketEndpoint::acceptInetSocketIfEnabled):
* inspector/remote/socket/RemoteInspectorSocketEndpoint.h:
2019-04-25 Alex Christensen <achristensen@webkit.org>
Start using C++17
https://bugs.webkit.org/show_bug.cgi?id=197131
Reviewed by Darin Alder.
* Configurations/Base.xcconfig:
2019-04-25 Alex Christensen <achristensen@webkit.org>
Remove DeprecatedOptional
https://bugs.webkit.org/show_bug.cgi?id=197161
Reviewed by Darin Adler.
We need to keep a symbol exported from JavaScriptCore for binary compatibility with iOS12.
We need this symbol to be in a file that doesn't include anything because libcxx's implementation of
std::optional is actually std::__1::optional, which has a different mangled name. This change will
prevent protocol errors from being reported if you are running the iOS12 simulator with a custom build of WebKit
and using the web inspector with it, but it's necessary to allow us to start using C++17 in WebKit.
* JavaScriptCore.xcodeproj/project.pbxproj:
* inspector/InspectorBackendDispatcher.cpp:
* inspector/InspectorBackendDispatcher.h:
* inspector/InspectorBackendDispatcherCompatibility.cpp: Added.
(Inspector::BackendDispatcher::reportProtocolError):
* inspector/InspectorBackendDispatcherCompatibility.h: Added.
2019-04-24 Saam Barati <sbarati@apple.com>
Add SPI callbacks for before and after module execution
https://bugs.webkit.org/show_bug.cgi?id=197244
<rdar://problem/50180511>
Reviewed by Yusuke Suzuki.
This is helpful for clients that want to profile execution of modules
in some way. E.g, if they want to time module execution time.
* API/JSAPIGlobalObject.h:
* API/JSAPIGlobalObject.mm:
(JSC::JSAPIGlobalObject::moduleLoaderEvaluate):
* API/JSContextPrivate.h:
* API/tests/testapi.mm:
(+[JSContextFetchDelegate contextWithBlockForFetch:]):
(-[JSContextFetchDelegate willEvaluateModule:]):
(-[JSContextFetchDelegate didEvaluateModule:]):
(testFetch):
(testFetchWithTwoCycle):
(testFetchWithThreeCycle):
(testLoaderResolvesAbsoluteScriptURL):
(testLoaderRejectsNilScriptURL):
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::evaluate):
(JSC::JSModuleLoader::evaluateNonVirtual):
* runtime/JSModuleLoader.h:
2019-04-23 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Shrink DFG::MinifiedNode
https://bugs.webkit.org/show_bug.cgi?id=197224
Reviewed by Filip Pizlo.
Since it is kept alive with compiled DFG code, we should shrink it to save memory.
If it is effective, we should consider minimizing these OSR exit data more aggressively.
* dfg/DFGMinifiedNode.h:
2019-04-23 Saam Barati <sbarati@apple.com>
LICM incorrectly assumes it'll never insert a node which provably OSR exits
https://bugs.webkit.org/show_bug.cgi?id=196721
<rdar://problem/49556479>
Reviewed by Filip Pizlo.
Previously, we assumed LICM could never hoist code that caused us
to provably OSR exit. This is a bad assumption, as we may very well
hoist such code. Obviously hoisting such code is not ideal. We shouldn't
hoist something we provably know will OSR exit. However, this is super rare,
and the phase is written in such a way where it's easier to gracefully
handle this case than to prevent us from hoisting such code.
If we wanted to ensure we never hoisted code that would provably exit, we'd
have to teach the phase to know when it inserted code that provably exits. I
saw two ways to do that:
1: Save and restore the AI state before actually hoisting.
2: Write an analysis that can determine if such a node would exit.
(1) is bad because it costs in memory and compile time. (2) will inevitably
have bugs as running into this condition is rare.
So instead of (1) or (2), I opted to have LICM gracefully handle when
it causes a provable exit. When we encounter this, we mark all blocks
in the loop as !cfaHasVisited and !cfaDidFinish.
* dfg/DFGLICMPhase.cpp:
(JSC::DFG::LICMPhase::attemptHoist):
2019-04-23 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use node index as DFG::MinifiedID
https://bugs.webkit.org/show_bug.cgi?id=197186
Reviewed by Saam Barati.
DFG Nodes can be identified with index if the graph is given. We should use unsigned index as a DFG::MinifiedID's underlying
source instead of Node* to reduce the size of VariableEvent from 16 to 12. Vector<VariableEvent> is the main data in DFG's OSR
tracking. It is kept after DFG compilation is done to make OSR work. We saw that this is allocated with large size in GMail.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/DataFormat.h:
* bytecode/ValueRecovery.h:
* dfg/DFGGenerationInfo.h:
* dfg/DFGMinifiedID.h:
(JSC::DFG::MinifiedID::MinifiedID):
(JSC::DFG::MinifiedID::operator! const):
(JSC::DFG::MinifiedID::operator== const):
(JSC::DFG::MinifiedID::operator!= const):
(JSC::DFG::MinifiedID::operator< const):
(JSC::DFG::MinifiedID::operator> const):
(JSC::DFG::MinifiedID::operator<= const):
(JSC::DFG::MinifiedID::operator>= const):
(JSC::DFG::MinifiedID::hash const):
(JSC::DFG::MinifiedID::dump const):
(JSC::DFG::MinifiedID::isHashTableDeletedValue const):
(JSC::DFG::MinifiedID::fromBits):
(JSC::DFG::MinifiedID::bits const):
(JSC::DFG::MinifiedID::invalidIndex):
(JSC::DFG::MinifiedID::otherInvalidIndex):
(JSC::DFG::MinifiedID::node const): Deleted.
(JSC::DFG::MinifiedID::invalidID): Deleted.
(JSC::DFG::MinifiedID::otherInvalidID): Deleted.
* dfg/DFGMinifiedIDInlines.h: Copied from Source/JavaScriptCore/dfg/DFGMinifiedNode.cpp.
(JSC::DFG::MinifiedID::MinifiedID):
* dfg/DFGMinifiedNode.cpp:
* dfg/DFGValueSource.h:
(JSC::DFG::ValueSource::ValueSource):
* dfg/DFGVariableEvent.h:
(JSC::DFG::VariableEvent::dataFormat const):
2019-04-23 Keith Rollin <krollin@apple.com>
Add Xcode version check for Header post-processing scripts
https://bugs.webkit.org/show_bug.cgi?id=197116
<rdar://problem/50058968>
Reviewed by Brent Fulgham.
There are several places in our Xcode projects that post-process
header files after they've been exported. Because of XCBuild, we're
moving to a model where the post-processing is performed at the same
time the header files are exported, rather than as a distinct
post-processing step. This patch disables the distinct step when the
inline processing is available.
In practice, this means prefixing appropriate post-processing Custom
Build phases with:
if [ "${XCODE_VERSION_MAJOR}" -ge "1100" -a "${USE_NEW_BUILD_SYSTEM}" = "YES" ]; then
# In this configuration, post-processing is performed at the same time as copying in the postprocess-header-rule script, so there's no need for this separate step.
exit 0
fi
* JavaScriptCore.xcodeproj/project.pbxproj:
2019-04-23 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r244558.
https://bugs.webkit.org/show_bug.cgi?id=197219
Causing crashes on iOS Sim Release and Debug (Requested by
ShawnRoberts on #webkit).
Reverted changeset:
"Remove DeprecatedOptional"
https://bugs.webkit.org/show_bug.cgi?id=197161
https://trac.webkit.org/changeset/244558
2019-04-23 Devin Rousso <drousso@apple.com>
Web Inspector: Uncaught Exception: null is not an object (evaluating 'this.ownerDocument.frameIdentifier')
https://bugs.webkit.org/show_bug.cgi?id=196420
<rdar://problem/49444205>
Reviewed by Timothy Hatcher.
* inspector/protocol/DOM.json:
Modify the existing `frameId` to represent the owner frame of the node, rather than the
frame it holds (in the case of an `<iframe>`).
2019-04-23 Alex Christensen <achristensen@webkit.org>
Remove DeprecatedOptional
https://bugs.webkit.org/show_bug.cgi?id=197161
Reviewed by Darin Adler.
* inspector/InspectorBackendDispatcher.cpp:
* inspector/InspectorBackendDispatcher.h:
2019-04-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use volatile load to populate backing page in MarkedBlock::Footer instead of using holdLock
https://bugs.webkit.org/show_bug.cgi?id=197152
Reviewed by Saam Barati.
Emit volatile load instead of using holdLock to populate backing page in MarkedBlock::Footer.
* heap/BlockDirectory.cpp:
(JSC::BlockDirectory::isPagedOut):
* heap/MarkedBlock.h:
(JSC::MarkedBlock::populatePage const):
2019-04-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] useJIT should subsume useRegExpJIT
https://bugs.webkit.org/show_bug.cgi?id=197153
Reviewed by Alex Christensen.
useJIT should subsume useRegExpJIT. We should immediately disable JIT feature if useJIT = false,
even if useRegExpJIT is true.
* dfg/DFGCapabilities.cpp:
(JSC::DFG::isSupported):
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/RegExp.cpp:
(JSC::RegExp::compile):
(JSC::RegExp::compileMatchOnly):
* runtime/VM.cpp:
(JSC::enableAssembler):
(JSC::VM::canUseRegExpJIT): Deleted.
* runtime/VM.h:
2019-04-22 Basuke Suzuki <basuke.suzuki@sony.com>
[PlayStation] Restructuring Remote Inspector classes to support multiple platform.
https://bugs.webkit.org/show_bug.cgi?id=197030
Reviewed by Don Olmstead.
Restructuring the PlayStation's RemoteInspector backend which uses native socket for the communication to be ready for WinCairo.
What we did is basically:
- Renamed `remote/playstation/` to `remote/socket/`. This directory is now platform independent implementation of socket backend.
- Renamed `RemoteInspectorSocket` class to `RemoteInspectorSocketEndpoint`. This class is platform independent and core of the backend.
- Merged `RemoteInspectorSocket{Client|Server}` classes into `RemoteInspectorSocketEndpoint` class because the differences are little.
- Defined a new interface functions in `Inspector::Socket` (new) namespace.
- Moved POSIX socket implementation into `posix\RemoteInspectorSocketPOSIX.{h|cpp}`.
* PlatformPlayStation.cmake:
* inspector/remote/RemoteInspector.h:
* inspector/remote/playstation/RemoteInspectorSocketClient.h: Merged into RemoteInspectorSocketEndpoint.
* inspector/remote/playstation/RemoteInspectorSocketClientPlayStation.cpp: Merged into RemoteInspectorSocketEndpoint.
* inspector/remote/playstation/RemoteInspectorSocketPlayStation.cpp: Removed.
* inspector/remote/playstation/RemoteInspectorSocketServer.h: Merged into RemoteInspectorSocketEndpoint.
* inspector/remote/playstation/RemoteInspectorSocketServerPlayStation.cpp: Merged into RemoteInspectorSocketEndpoint.
* inspector/remote/socket/RemoteInspectorConnectionClient.cpp: Renamed from inspector\remote\playstation\RemoteInspectorConnectionClientPlayStation.cpp.
* inspector/remote/socket/RemoteInspectorConnectionClient.h: Renamed from inspector\remote\playstation\RemoteInspectorConnectionClient.h.
(Inspector::RemoteInspectorConnectionClient::didAccept):
* inspector/remote/socket/RemoteInspectorMessageParser.cpp: Renamed from inspector\remote\playstation\RemoteInspectorMessageParserPlayStation.cpp.
* inspector/remote/socket/RemoteInspectorMessageParser.h: Renamed from inspector\remote\playstation\RemoteInspectorMessageParser.h.
* inspector/remote/socket/RemoteInspectorServer.cpp: Renamed from inspector\remote\playstation\RemoteInspectorServerPlayStation.cpp.
(Inspector::RemoteInspectorServer::didAccept):
(Inspector::RemoteInspectorServer::start):
* inspector/remote/socket/RemoteInspectorServer.h: Renamed from inspector\remote\playstation\RemoteInspectorServer.h.
* inspector/remote/socket/RemoteInspectorSocket.cpp: Renamed from inspector\remote\playstation\RemoteInspectorPlayStation.cpp.
(Inspector::RemoteInspector::start):
* inspector/remote/socket/RemoteInspectorSocket.h: Copied from inspector\remote\playstation\RemoteInspectorSocket.h.
* inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp: Added.
(Inspector::RemoteInspectorSocketEndpoint::RemoteInspectorSocketEndpoint):
(Inspector::RemoteInspectorSocketEndpoint::~RemoteInspectorSocketEndpoint):
(Inspector::RemoteInspectorSocketEndpoint::wakeupWorkerThread):
(Inspector::RemoteInspectorSocketEndpoint::connectInet):
(Inspector::RemoteInspectorSocketEndpoint::listenInet):
(Inspector::RemoteInspectorSocketEndpoint::isListening):
(Inspector::RemoteInspectorSocketEndpoint::workerThread):
(Inspector::RemoteInspectorSocketEndpoint::createClient):
(Inspector::RemoteInspectorSocketEndpoint::recvIfEnabled):
(Inspector::RemoteInspectorSocketEndpoint::sendIfEnabled):
(Inspector::RemoteInspectorSocketEndpoint::send):
(Inspector::RemoteInspectorSocketEndpoint::acceptInetSocketIfEnabled):
* inspector/remote/socket/RemoteInspectorSocketEndpoint.h: Renamed from inspector\remote\playstation\RemoteInspectorSocket.h.
* inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp: Added.
(Inspector::Socket::connect):
(Inspector::Socket::listen):
(Inspector::Socket::accept):
(Inspector::Socket::createPair):
(Inspector::Socket::setup):
(Inspector::Socket::isValid):
(Inspector::Socket::isListening):
(Inspector::Socket::read):
(Inspector::Socket::write):
(Inspector::Socket::close):
(Inspector::Socket::preparePolling):
(Inspector::Socket::poll):
(Inspector::Socket::isReadable):
(Inspector::Socket::isWritable):
(Inspector::Socket::markWaitingWritable):
(Inspector::Socket::clearWaitingWritable):
2019-04-20 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, suppress warnings in non Darwin environments
* jit/ExecutableAllocator.cpp:
(JSC::dumpJITMemory):
2019-04-19 Saam Barati <sbarati@apple.com>
AbstractValue can represent more than int52
https://bugs.webkit.org/show_bug.cgi?id=197118
<rdar://problem/49969960>
Reviewed by Michael Saboff.
Let's analyze this control flow diamond:
#0
branch #1, #2
#1:
PutStack(JSValue, loc42)
Jump #3
#2:
PutStack(Int52, loc42)
Jump #3
#3:
...
Our abstract value for loc42 at the head of #3 will contain an abstract
value that us the union of Int52 with other things. Obviously in the
above program, a GetStack for loc42 would be inavlid, since it might
be loading either JSValue or Int52. However, the abstract interpreter
just tracks what the value could be, and it could be Int52 or JSValue.
When I did the Int52 refactoring, I expected such things to never happen,
but it turns out it does. We should just allow for this instead of asserting
against it since it's valid IR to do the above.
* bytecode/SpeculatedType.cpp:
(JSC::dumpSpeculation):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::checkConsistency const):
* dfg/DFGAbstractValue.h:
(JSC::DFG::AbstractValue::validateTypeAcceptingBoxedInt52 const):
2019-04-19 Tadeu Zagallo <tzagallo@apple.com>
Add option to dump JIT memory
https://bugs.webkit.org/show_bug.cgi?id=197062
<rdar://problem/49744332>
Reviewed by Saam Barati.
Dump all writes into JIT memory to the specified file. The format is:
- 64-bit destination address for the write
- 64-bit size of the content written
- Copy of the data that was written to JIT memory
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::copyCompactAndLinkCode):
* jit/ExecutableAllocator.cpp:
(JSC::dumpJITMemory):
* jit/ExecutableAllocator.h:
(JSC::performJITMemcpy):
* runtime/Options.h:
2019-04-19 Keith Rollin <krollin@apple.com>
Add postprocess-header-rule scripts
https://bugs.webkit.org/show_bug.cgi?id=197072
<rdar://problem/50027299>
Reviewed by Brent Fulgham.
Several projects have post-processing build phases where exported
headers are tweaked after they've been copied. This post-processing is
performed via scripts called postprocess-headers.sh. For reasons
related to XCBuild, we are now transitioning to a build process where
the post-processing is performed at the same time as the
exporting/copying. To support this process, add similar scripts named
postprocess-header-rule, which are geared towards processing a single
file at a time rather than all exported files at once. Also add a
build rule that makes use of these scripts. These scripts and build
rules are not used at the moment; they will come into use in an
imminent patch.
Note that I've named these postprocess-header-rule rather than
postprocess-header-rule.sh. Scripts in Tools/Scripts do not have
suffixes indicating how the tool is implemented. Scripts in
per-project Scripts folders appear to be mixed regarding the use of
suffixes. I'm opting here to follow the Tools/Scripts convention, with
the expectation that over time we completely standardize on that.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Scripts/postprocess-header-rule: Added.
2019-04-18 Saam barati <sbarati@apple.com>
Remove useConcurrentBarriers option
https://bugs.webkit.org/show_bug.cgi?id=197066
Reviewed by Michael Saboff.
This isn't a helpful option as it will lead us to crash when using the
concurrent GC.
* dfg/DFGStoreBarrierClusteringPhase.cpp:
* dfg/DFGStoreBarrierInsertionPhase.cpp:
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::barrierStoreLoadFence):
* runtime/Options.h:
2019-04-17 Saam Barati <sbarati@apple.com>
Remove deprecated JSScript SPI
https://bugs.webkit.org/show_bug.cgi?id=194909
<rdar://problem/48283499>
Reviewed by Keith Miller.
* API/JSAPIGlobalObject.mm:
(JSC::JSAPIGlobalObject::moduleLoaderFetch):
* API/JSScript.h:
* API/JSScript.mm:
(+[JSScript scriptWithSource:inVirtualMachine:]): Deleted.
(fillBufferWithContentsOfFile): Deleted.
(+[JSScript scriptFromASCIIFile:inVirtualMachine:withCodeSigning:andBytecodeCache:]): Deleted.
(+[JSScript scriptFromUTF8File:inVirtualMachine:withCodeSigning:andBytecodeCache:]): Deleted.
(-[JSScript setSourceURL:]): Deleted.
* API/JSScriptInternal.h:
* API/tests/testapi.mm:
(testFetch):
(testFetchWithTwoCycle):
(testFetchWithThreeCycle):
(testLoaderResolvesAbsoluteScriptURL):
(testImportModuleTwice):
(-[JSContextFileLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
2019-04-17 Keith Rollin <krollin@apple.com>
Remove JSCBuiltins.cpp from Copy Headers phase
https://bugs.webkit.org/show_bug.cgi?id=196981
<rdar://problem/49952133>
Reviewed by Alex Christensen.
JSCBuiltins.cpp is not a header and so doesn't need to be in the Copy
Headers phase. Checking its history, it seems to have been added
accidentally at the same time that JSCBuiltins.h was added.
* JavaScriptCore.xcodeproj/project.pbxproj:
2019-04-16 Stephan Szabo <stephan.szabo@sony.com>
[PlayStation] Update port for system library changes
https://bugs.webkit.org/show_bug.cgi?id=196978
Reviewed by Ross Kirsling.
* shell/playstation/Initializer.cpp:
Add reference to new posix compatibility library.
2019-04-16 Robin Morisset <rmorisset@apple.com>
[WTF] holdLock should be marked WARN_UNUSED_RETURN
https://bugs.webkit.org/show_bug.cgi?id=196922
Reviewed by Keith Miller.
There was one case where holdLock was used and the result ignored.
From a comment that was deleted in https://bugs.webkit.org/attachment.cgi?id=328438&action=prettypatch, I believe that it is on purpose.
So I brought back a variant of the comment, and made the ignoring of the return explicit.
* heap/BlockDirectory.cpp:
(JSC::BlockDirectory::isPagedOut):
2019-04-16 Caitlin Potter <caitp@igalia.com>
[JSC] Filter DontEnum properties in ProxyObject::getOwnPropertyNames()
https://bugs.webkit.org/show_bug.cgi?id=176810
Reviewed by Saam Barati.
This adds conditional logic following the invariant checks, to perform
filtering in common uses of getOwnPropertyNames.
While this would ideally only be done in JSPropertyNameEnumerator, adding
the filtering to ProxyObject::performGetOwnPropertyNames maintains the
invariant that the EnumerationMode is properly followed.
This was originally rolled out in r244020, as DontEnum filtering code
in ObjectConstructor.cpp's ownPropertyKeys() had not been removed. It's
now redundant due to being handled in ProxyObject::getOwnPropertyNames().
* runtime/PropertyNameArray.h:
(JSC::PropertyNameArray::reset):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::performGetOwnPropertyNames):
2019-04-15 Saam barati <sbarati@apple.com>
Modify how we do SetArgument when we inline varargs calls
https://bugs.webkit.org/show_bug.cgi?id=196712
<rdar://problem/49605012>
Reviewed by Michael Saboff.
When we inline varargs calls, we guarantee that the number of arguments that
go on the stack are somewhere between the "mandatoryMinimum" and the "limit - 1".
However, we can't statically guarantee that the arguments between these two
ranges was filled out by Load/ForwardVarargs. This is because in the general
case we don't know the argument count statically.
However, we used to always emit SetArgumentDefinitely up to "limit - 1" for
all arguments, even when some arguments aren't guaranteed to be in a valid
state. Emitting these SetArgumentDefinitely were helpful because they let us
handle variable liveness and OSR exit metadata. However, when we converted
to SSA, we ended up emitting a GetStack for each such SetArgumentDefinitely.
This is wrong, as we can't guarantee such SetArgumentDefinitely nodes are
actually looking at a range of the stack that are guaranteed to be initialized.
This patch introduces a new form of SetArgument node: SetArgumentMaybe. In terms
of OSR exit metadata and variable liveness tracking, it behaves like SetArgumentDefinitely.
However, it differs in a couple key ways:
1. In ThreadedCPS, GetLocal(@SetArgumentMaybe) is invalid IR, as this implies
you might be loading uninitialized stack. (This same rule applies when you do
the full data flow reachability analysis over CPS Phis.) If someone logically
wanted to emit code like this, the correct node to emit would be GetArgument,
not GetLocal. For similar reasons, PhantomLocal(@SetArgumentMaybe) is also
invalid IR.
2. To track liveness, Flush(@SetArgumentMaybe) is valid, and is the main user
of SetArgumentMaybe.
3. In SSA conversion, we don't lower SetArgumentMaybe to GetStack, as there
should be no data flow user of SetArgumentMaybe.
SetArgumentDefinitely guarantees that the stack slot is initialized.
SetArgumentMaybe makes no such guarantee.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleVarargsInlining):
* dfg/DFGCPSRethreadingPhase.cpp:
(JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
(JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
(JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
(JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
(JSC::DFG::CPSRethreadingPhase::propagatePhis):
(JSC::DFG::CPSRethreadingPhase::computeIsFlushed):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGCommon.h:
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGInPlaceAbstractState.cpp:
(JSC::DFG::InPlaceAbstractState::endBasicBlock):
* dfg/DFGLiveCatchVariablePreservationPhase.cpp:
(JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
* dfg/DFGMaximalFlushInsertionPhase.cpp:
(JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
(JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
* dfg/DFGMayExit.cpp:
* dfg/DFGNode.cpp:
(JSC::DFG::Node::hasVariableAccessData):
* dfg/DFGNodeType.h:
* dfg/DFGPhantomInsertionPhase.cpp:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSSAConversionPhase.cpp:
(JSC::DFG::SSAConversionPhase::run):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGValidate.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
2019-04-15 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r243672.
https://bugs.webkit.org/show_bug.cgi?id=196952
[JSValue release] should be thread-safe (Requested by
yusukesuzuki on #webkit).
Reverted changeset:
"[JSC] JSWrapperMap should not use Objective-C Weak map
(NSMapTable with NSPointerFunctionsWeakMemory) for
m_cachedObjCWrappers"
https://bugs.webkit.org/show_bug.cgi?id=196392
https://trac.webkit.org/changeset/243672
2019-04-15 Saam barati <sbarati@apple.com>
SafeToExecute for GetByOffset/GetGetterByOffset/PutByOffset is using the wrong child for the base
https://bugs.webkit.org/show_bug.cgi?id=196945
<rdar://problem/49802750>
Reviewed by Filip Pizlo.
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
2019-04-15 Robin Morisset <rmorisset@apple.com>
DFG should be able to constant fold Object.create() with a constant prototype operand
https://bugs.webkit.org/show_bug.cgi?id=196886
Reviewed by Yusuke Suzuki.
It is a fairly simple and limited patch, as it only works when the DFG can prove the exact object used as prototype.
But when it applies it can be a significant win:
Baseline Optim
object-create-constant-prototype 3.6082+-0.0979 ^ 1.6947+-0.0756 ^ definitely 2.1292x faster
object-create-null 11.4492+-0.2510 ? 11.5030+-0.2402 ?
object-create-unknown-object-prototype 15.6067+-0.1851 ? 15.7500+-0.2322 ?
object-create-untyped-prototype 8.8873+-0.1240 ? 8.9806+-0.1202 ? might be 1.0105x slower
<geometric> 8.6967+-0.1208 ^ 7.2408+-0.1367 ^ definitely 1.2011x faster
The only subtlety is that we need to to access the StructureCache concurrently from the compiler thread (see https://bugs.webkit.org/show_bug.cgi?id=186199)
I solved this with a simple lock, taken when the compiler thread tries to read it, and when the main thread tries to modify it.
I expect it to be extremely low contention, but will watch the bots just in case.
The lock is taken neither when the main thread is only reading the cache (it has no-one to race with), nor when the GC purges it of dead entries (it does not free anything while a compiler thread is in the middle of a phase).
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* runtime/StructureCache.cpp:
(JSC::StructureCache::createEmptyStructure):
(JSC::StructureCache::tryEmptyObjectStructureForPrototypeFromCompilerThread):
* runtime/StructureCache.h:
2019-04-15 Devin Rousso <drousso@apple.com>
Web Inspector: fake value descriptors for promises add a catch handler, preventing "rejectionhandled" events from being fired
https://bugs.webkit.org/show_bug.cgi?id=196484
<rdar://problem/49114725>
Reviewed by Joseph Pecoraro.
Only add a catch handler when the promise is reachable via a native getter and is known to
have rejected. A non-rejected promise doesn't need a catch handler, and any promise that
isn't reachable via a getter won't actually be reached, as `InjectedScript` doesn't call any
functions, instead only getting the function object itself.
* inspector/InjectedScriptSource.js:
(InjectedScript.prototype._propertyDescriptors.createFakeValueDescriptor):
* inspector/JSInjectedScriptHost.h:
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::isPromiseRejectedWithNativeGetterTypeError): Added.
* inspector/JSInjectedScriptHostPrototype.cpp:
(Inspector::JSInjectedScriptHostPrototype::finishCreation):
(Inspector::jsInjectedScriptHostPrototypeFunctionIsPromiseRejectedWithNativeGetterTypeError): Added.
* runtime/ErrorInstance.h:
(JSC::ErrorInstance::setNativeGetterTypeError): Added.
(JSC::ErrorInstance::isNativeGetterTypeError const): Added.
* runtime/Error.h:
(JSC::throwVMGetterTypeError): Added.
* runtime/Error.cpp:
(JSC::createGetterTypeError): Added.
(JSC::throwGetterTypeError): Added.
(JSC::throwDOMAttributeGetterTypeError):
2019-04-15 Robin Morisset <rmorisset@apple.com>
B3::Value should have different kinds of adjacency lists
https://bugs.webkit.org/show_bug.cgi?id=196091
Reviewed by Filip Pizlo.
The key idea of this optimization is to replace the Vector<Value*, 3> m_children in B3::Value (40 bytes on 64-bits platform) by one of the following:
- Nothing (0 bytes)
- 1 Value* (8 bytes)
- 2 Value* (16 bytes)
- 3 Value* (24 bytes)
- A Vector<Value*, 3>
after the end of the Value object, depending on the kind of the Value.
So for example, when allocating an Add, we would allocate an extra 16 bytes into which to store 2 Values.
This would halve the memory consumption of Const64/Const32/Nop/Identity and a bunch more kinds of values, and reduce by a more moderate amount the memory consumption of the rest of non-varargs values (e.g. Add would go from 72 to 48 bytes).
A few implementation points:
- Even if there is no children, we must remember to allocate at least enough space for replaceWithIdentity to work later. It needs sizeof(Value) (for the object itself) + sizeof(Value*) (for the pointer to its child)
- We must make sure to destroy the vector whenever we destroy a Value which is VarArgs
- We must remember how many elements there are in the case where we did not allocate a Vector. We cannot do it purely by relying on the kind, both for speed reasons and because Return can have either 0 or 1 argument in B3
Thankfully, we have an extra byte of padding to use in the middle of B3::Value
- In order to support clone(), we must have a separate version of allocate, which extracts the opcode from the to-be-cloned object instead of from the call to the constructor
- Speaking of which, we need a special templated function opcodeFromConstructor, because some of the constructors of subclasses of Value don't take an explicit Opcode as argument, typically because they match a single one.
- To maximize performance, we provide specialized versions of child/lastChild/numChildren/children in the subclasses of Value, skipping checks when the actual type of the Value is already known.
This is done through the B3_SPECIALIZE_VALUE_FOR_... defined at the bottom of B3Value.h
- In the constructors of Value, we convert all extra children arguments to Value* eagerly. It is not required for correctness (they will be converted when put into a Vector<Value*> or a Value* in the end), but it helps limit an explosion in the number of template instantiations.
- I moved DeepValueDump::dump from the .h to the .cpp, as there is no good reason to inline it, and recompiling JSC is already slow enough
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3ArgumentRegValue.cpp:
(JSC::B3::ArgumentRegValue::cloneImpl const): Deleted.
* b3/B3ArgumentRegValue.h:
* b3/B3AtomicValue.cpp:
(JSC::B3::AtomicValue::AtomicValue):
(JSC::B3::AtomicValue::cloneImpl const): Deleted.
* b3/B3AtomicValue.h:
* b3/B3BasicBlock.h:
* b3/B3BasicBlockInlines.h:
(JSC::B3::BasicBlock::appendNewNonTerminal): Deleted.
* b3/B3CCallValue.cpp:
(JSC::B3::CCallValue::appendArgs):
(JSC::B3::CCallValue::cloneImpl const): Deleted.
* b3/B3CCallValue.h:
* b3/B3CheckValue.cpp:
(JSC::B3::CheckValue::cloneImpl const): Deleted.
* b3/B3CheckValue.h:
* b3/B3Const32Value.cpp:
(JSC::B3::Const32Value::cloneImpl const): Deleted.
* b3/B3Const32Value.h:
* b3/B3Const64Value.cpp:
(JSC::B3::Const64Value::cloneImpl const): Deleted.
* b3/B3Const64Value.h:
* b3/B3ConstDoubleValue.cpp:
(JSC::B3::ConstDoubleValue::cloneImpl const): Deleted.
* b3/B3ConstDoubleValue.h:
* b3/B3ConstFloatValue.cpp:
(JSC::B3::ConstFloatValue::cloneImpl const): Deleted.
* b3/B3ConstFloatValue.h:
* b3/B3ConstPtrValue.h:
(JSC::B3::ConstPtrValue::opcodeFromConstructor):
* b3/B3FenceValue.cpp:
(JSC::B3::FenceValue::FenceValue):
(JSC::B3::FenceValue::cloneImpl const): Deleted.
* b3/B3FenceValue.h:
* b3/B3MemoryValue.cpp:
(JSC::B3::MemoryValue::MemoryValue):
(JSC::B3::MemoryValue::cloneImpl const): Deleted.
* b3/B3MemoryValue.h:
* b3/B3MoveConstants.cpp:
* b3/B3PatchpointValue.cpp:
(JSC::B3::PatchpointValue::cloneImpl const): Deleted.
* b3/B3PatchpointValue.h:
(JSC::B3::PatchpointValue::opcodeFromConstructor):
* b3/B3Procedure.cpp:
* b3/B3Procedure.h:
* b3/B3ProcedureInlines.h:
(JSC::B3::Procedure::add):
* b3/B3SlotBaseValue.cpp:
(JSC::B3::SlotBaseValue::cloneImpl const): Deleted.
* b3/B3SlotBaseValue.h:
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::forEachArgImpl):
(JSC::B3::StackmapSpecial::isValidImpl):
* b3/B3StackmapValue.cpp:
(JSC::B3::StackmapValue::append):
(JSC::B3::StackmapValue::StackmapValue):
* b3/B3StackmapValue.h:
* b3/B3SwitchValue.cpp:
(JSC::B3::SwitchValue::SwitchValue):
(JSC::B3::SwitchValue::cloneImpl const): Deleted.
* b3/B3SwitchValue.h:
(JSC::B3::SwitchValue::opcodeFromConstructor):
* b3/B3UpsilonValue.cpp:
(JSC::B3::UpsilonValue::cloneImpl const): Deleted.
* b3/B3UpsilonValue.h:
* b3/B3Value.cpp:
(JSC::B3::DeepValueDump::dump const):
(JSC::B3::Value::~Value):
(JSC::B3::Value::replaceWithIdentity):
(JSC::B3::Value::replaceWithNopIgnoringType):
(JSC::B3::Value::replaceWithPhi):
(JSC::B3::Value::replaceWithJump):
(JSC::B3::Value::replaceWithOops):
(JSC::B3::Value::replaceWith):
(JSC::B3::Value::invertedCompare const):
(JSC::B3::Value::returnsBool const):
(JSC::B3::Value::cloneImpl const): Deleted.
* b3/B3Value.h:
(JSC::B3::DeepValueDump::dump const): Deleted.
* b3/B3ValueInlines.h:
(JSC::B3::Value::adjacencyListOffset const):
(JSC::B3::Value::cloneImpl const):
* b3/B3VariableValue.cpp:
(JSC::B3::VariableValue::VariableValue):
(JSC::B3::VariableValue::cloneImpl const): Deleted.
* b3/B3VariableValue.h:
* b3/B3WasmAddressValue.cpp:
(JSC::B3::WasmAddressValue::WasmAddressValue):
(JSC::B3::WasmAddressValue::cloneImpl const): Deleted.
* b3/B3WasmAddressValue.h:
* b3/B3WasmBoundsCheckValue.cpp:
(JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
(JSC::B3::WasmBoundsCheckValue::cloneImpl const): Deleted.
* b3/B3WasmBoundsCheckValue.h:
(JSC::B3::WasmBoundsCheckValue::accepts):
(JSC::B3::WasmBoundsCheckValue::opcodeFromConstructor):
* b3/testb3.cpp:
(JSC::B3::testCallFunctionWithHellaArguments):
(JSC::B3::testCallFunctionWithHellaArguments2):
(JSC::B3::testCallFunctionWithHellaArguments3):
(JSC::B3::testCallFunctionWithHellaDoubleArguments):
(JSC::B3::testCallFunctionWithHellaFloatArguments):
* ftl/FTLOutput.h:
(JSC::FTL::Output::call):
2019-04-15 Tadeu Zagallo <tzagallo@apple.com>
Bytecode cache should not encode the SourceProvider for UnlinkedFunctionExecutable's classSource
https://bugs.webkit.org/show_bug.cgi?id=196878
Reviewed by Saam Barati.
Every time we encode an (Unlinked)SourceCode, we encode its SourceProvider,
including the full source if it's a StringSourceProvider. This wasn't an issue,
since the SourceCode contains a RefPtr to the SourceProvider, and the Encoder
would avoid encoding the provider multiple times. With the addition of the
incremental cache, each UnlinkedFunctionCodeBlock is encoded in isolation, which
means we can no longer deduplicate it and the full program text was being encoded
multiple times in the cache.
As a work around, this patch adds a custom cached type for encoding the SourceCode
without its provider, and later injects the SourceProvider through the Decoder.
* parser/SourceCode.h:
* parser/UnlinkedSourceCode.h:
(JSC::UnlinkedSourceCode::provider const):
* runtime/CachedTypes.cpp:
(JSC::Decoder::Decoder):
(JSC::Decoder::create):
(JSC::Decoder::provider const):
(JSC::CachedSourceCodeWithoutProvider::encode):
(JSC::CachedSourceCodeWithoutProvider::decode const):
(JSC::decodeCodeBlockImpl):
* runtime/CachedTypes.h:
2019-04-15 Robin Morisset <rmorisset@apple.com>
MarkedSpace.cpp is not in the Xcode workspace
https://bugs.webkit.org/show_bug.cgi?id=196928
Reviewed by Saam Barati.
* JavaScriptCore.xcodeproj/project.pbxproj:
2019-04-15 Tadeu Zagallo <tzagallo@apple.com>
Incremental bytecode cache should not append function updates when loaded from memory
https://bugs.webkit.org/show_bug.cgi?id=196865
Reviewed by Filip Pizlo.
Function updates hold the assumption that a function can only be executed/cached
after its containing code block has already been cached. This assumptions does
not hold if the UnlinkedCodeBlock is loaded from memory by the CodeCache, since
we might have two independent SourceProviders executing different paths of the
code and causing the same UnlinkedCodeBlock to be modified in memory.
Use a RefPtr instead of Ref for m_cachedBytecode in ShellSourceProvider to distinguish
between a new, empty cache and a cache that was not loaded and therefore cannot be updated.
* jsc.cpp:
(ShellSourceProvider::ShellSourceProvider):
2019-04-15 Saam barati <sbarati@apple.com>
mergeOSREntryValue is wrong when the incoming value does not match up with the flush format
https://bugs.webkit.org/show_bug.cgi?id=196918
Reviewed by Yusuke Suzuki.
r244238 lead to some debug failures because we were calling checkConsistency()
before doing fixTypeForRepresentation when merging in must handle values in
CFA. This patch fixes that.
However, as I was reading over mergeOSREntryValue, I realized it was wrong. It
was possible it could merge in a value/type outside of the variable's flushed type.
Once the flush format types are locked in, we can't introduce a type out of
that range. This probably never lead to any crashes as our profiling injection
and speculation decision code is solid. However, what we were doing is clearly
wrong, and something a fuzzer could have found if we fuzzed the must handle
values inside prediction injection. We should do that fuzzing:
https://bugs.webkit.org/show_bug.cgi?id=196924
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::mergeOSREntryValue):
* dfg/DFGAbstractValue.h:
* dfg/DFGCFAPhase.cpp:
(JSC::DFG::CFAPhase::injectOSR):
2019-04-15 Robin Morisset <rmorisset@apple.com>
Several structures and enums in the Yarr interpreter can be shrunk
https://bugs.webkit.org/show_bug.cgi?id=196923
Reviewed by Saam Barati.
YarrOp: 88 -> 80
RegularExpression: 40 -> 32
ByteTerm: 56 -> 48
PatternTerm: 56 -> 48
* yarr/RegularExpression.cpp:
* yarr/YarrInterpreter.h:
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::YarrOp::YarrOp):
* yarr/YarrParser.h:
* yarr/YarrPattern.h:
2019-04-15 Devin Rousso <drousso@apple.com>
Web Inspector: REGRESSION(r244172): crash when trying to add extra domain while inspecting JSContext
https://bugs.webkit.org/show_bug.cgi?id=196925
<rdar://problem/49873994>
Reviewed by Joseph Pecoraro.
Move the logic for creating the `InspectorAgent` and `InspectorDebuggerAgent` into separate
functions so that callers can be guaranteed to have a valid instance of the agent.
* inspector/JSGlobalObjectInspectorController.h:
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::connectFrontend):
(Inspector::JSGlobalObjectInspectorController::frontendInitialized):
(Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
(Inspector::JSGlobalObjectInspectorController::ensureInspectorAgent): Added.
(Inspector::JSGlobalObjectInspectorController::ensureDebuggerAgent): Added.
(Inspector::JSGlobalObjectInspectorController::createLazyAgents):
2019-04-14 Don Olmstead <don.olmstead@sony.com>
[CMake] JavaScriptCore derived sources should only be referenced inside JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=196742
Reviewed by Konstantin Tokarev.
Migrate to using JavaScriptCore_DERIVED_SOURCES_DIR instead of DERIVED_SOURCES_JAVASCRIPTCORE_DIR
to support moving the JavaScriptCore derived sources outside of a shared directory.
Also use JavaScriptCore_DERIVED_SOURCES_DIR instead of DERIVED_SOUCES_DIR.
* CMakeLists.txt:
2019-04-13 Tadeu Zagallo <tzagallo@apple.com>
CodeCache should check that the UnlinkedCodeBlock was successfully created before caching it
https://bugs.webkit.org/show_bug.cgi?id=196880
Reviewed by Yusuke Suzuki.
CodeCache should not tell the SourceProvider to cache the bytecode if it failed
to create the UnlinkedCodeBlock.
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
2019-04-12 Saam barati <sbarati@apple.com>
r244079 logically broke shouldSpeculateInt52
https://bugs.webkit.org/show_bug.cgi?id=196884
Reviewed by Yusuke Suzuki.
In r244079, I changed shouldSpeculateInt52 to only return true
when the prediction is isAnyInt52Speculation(). However, it was
wrong to not to include SpecInt32 in this for two reasons:
1. We diligently write code that first checks if we should speculate Int32.
For example:
if (shouldSpeculateInt32()) ...
else if (shouldSpeculateInt52()) ...
It would be wrong not to fall back to Int52 if we're dealing with the union of
Int32 and Int52.
It would be a performance mistake to not include Int32 here because
data flow can easily tell us that we have variables that are the union
of Int32 and Int52 values. It's better to speculate Int52 than Double
in that situation.
2. We also write code where we ask if the inputs can be Int52, e.g, if
we know via profiling that an Add overflows, we may not emit an Int32 add.
However, we only emit such an add if both inputs can be Int52, and Int32
can trivially become Int52.
This patch recovers the 0.5-1% regression r244079 caused on JetStream 2.
* bytecode/SpeculatedType.h:
(JSC::isInt32SpeculationForArithmetic):
(JSC::isInt32OrBooleanSpeculationForArithmetic):
(JSC::isInt32OrInt52Speculation):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::observeUseKindOnNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::shouldSpeculateInt52):
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGVariableAccessData.cpp:
(JSC::DFG::VariableAccessData::couldRepresentInt52Impl):
2019-04-12 Saam barati <sbarati@apple.com>
Unreviewed. Build fix after r244233.
* assembler/CPU.cpp:
2019-04-12 Saam barati <sbarati@apple.com>
Sometimes we need to user fewer CPUs in our threading calculations
https://bugs.webkit.org/show_bug.cgi?id=196794
<rdar://problem/49389497>
Reviewed by Yusuke Suzuki.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* assembler/CPU.cpp: Added.
(JSC::isKernTCSMAvailable):
(JSC::enableKernTCSM):
(JSC::kernTCSMAwareNumberOfProcessorCores):
* assembler/CPU.h:
(JSC::isKernTCSMAvailable):
(JSC::enableKernTCSM):
(JSC::kernTCSMAwareNumberOfProcessorCores):
* heap/MachineStackMarker.h:
(JSC::MachineThreads::addCurrentThread):
* runtime/JSLock.cpp:
(JSC::JSLock::didAcquireLock):
* runtime/Options.cpp:
(JSC::computeNumberOfWorkerThreads):
(JSC::computePriorityDeltaOfWorkerThreads):
* wasm/WasmWorklist.cpp:
(JSC::Wasm::Worklist::Worklist):
2019-04-12 Robin Morisset <rmorisset@apple.com>
Use padding at end of ArrayBuffer
https://bugs.webkit.org/show_bug.cgi?id=196823
Reviewed by Filip Pizlo.
* runtime/ArrayBuffer.h:
2019-04-11 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] op_has_indexed_property should not assume subscript part is Uint32
https://bugs.webkit.org/show_bug.cgi?id=196850
Reviewed by Saam Barati.
op_has_indexed_property assumed that subscript part is always Uint32. However, this is just a load from non-constant RegisterID,
DFG can store it in double format and can perform OSR exit. op_has_indexed_property should not assume that.
In this patch, instead, we check it with isAnyInt and get uint32_t from AnyInt.
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_has_indexed_property):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_has_indexed_property):
* jit/JITOperations.cpp:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
2019-04-11 Saam barati <sbarati@apple.com>
Remove invalid assertion in operationInstanceOfCustom
https://bugs.webkit.org/show_bug.cgi?id=196842
<rdar://problem/49725493>
Reviewed by Michael Saboff.
In the generated JIT code, we go to the slow path when the incoming function
isn't the Node's CodeOrigin's functionProtoHasInstanceSymbolFunction. However,
in the JIT operation, we were asserting against exec->lexicalGlobalObject()'s
functionProtoHasInstanceSymbolFunction. That assertion might be wrong when
inlining across global objects as exec->lexicalGlobalObject() uses the machine
frame for procuring the global object. There is no harm when this assertion fails
as we just execute the slow path. This patch removes the assertion. (However, this
does shed light on the deficiency in our exec->lexicalGlobalObject() function with
respect to inlining. However, this isn't new -- we've known about this for a while.)
* jit/JITOperations.cpp:
2019-04-11 Michael Saboff <msaboff@apple.com>
Improve the Inline Cache Stats code
https://bugs.webkit.org/show_bug.cgi?id=196836
Reviewed by Saam Barati.
Needed to handle the case where the Identifier could be null, for example with InstanceOfAddAccessCase
and InstanceOfReplaceWithJump.
Added the ability to log the location of a GetBy and PutBy property as either on self or up the
protocol chain.
* jit/ICStats.cpp:
(JSC::ICEvent::operator< const):
(JSC::ICEvent::dump const):
* jit/ICStats.h:
(JSC::ICEvent::ICEvent):
(JSC::ICEvent::hash const):
* jit/JITOperations.cpp:
* jit/Repatch.cpp:
(JSC::tryCacheGetByID):
(JSC::tryCachePutByID):
(JSC::tryCacheInByID):
2019-04-11 Devin Rousso <drousso@apple.com>
Web Inspector: Timelines: can't reliably stop/start a recording
https://bugs.webkit.org/show_bug.cgi?id=196778
<rdar://problem/47606798>
Reviewed by Timothy Hatcher.
* inspector/protocol/ScriptProfiler.json:
* inspector/protocol/Timeline.json:
It is possible to determine when programmatic capturing starts/stops in the frontend based
on the state when the backend causes the state to change, such as if the state is "inactive"
when the frontend is told that the backend has started capturing.
* inspector/protocol/CPUProfiler.json:
* inspector/protocol/Memory.json:
Send an end timestamp to match other instruments.
* inspector/JSGlobalObjectConsoleClient.cpp:
(Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
(Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
* inspector/agents/InspectorScriptProfilerAgent.h:
* inspector/agents/InspectorScriptProfilerAgent.cpp:
(Inspector::InspectorScriptProfilerAgent::trackingComplete):
(Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted): Deleted.
(Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped): Deleted.
2019-04-11 Saam barati <sbarati@apple.com>
Rename SetArgument to SetArgumentDefinitely
https://bugs.webkit.org/show_bug.cgi?id=196828
Reviewed by Yusuke Suzuki.
This is in preparation for https://bugs.webkit.org/show_bug.cgi?id=196712
where we will introduce a node named SetArgumentMaybe. Doing this refactoring
first will make reviewing that other patch easier.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleVarargsInlining):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCPSRethreadingPhase.cpp:
(JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
(JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
(JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
(JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
(JSC::DFG::CPSRethreadingPhase::specialCaseArguments):
(JSC::DFG::CPSRethreadingPhase::propagatePhis):
(JSC::DFG::CPSRethreadingPhase::computeIsFlushed):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGCommon.h:
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::methodOfGettingAValueProfileFor):
* dfg/DFGGraph.h:
* dfg/DFGInPlaceAbstractState.cpp:
(JSC::DFG::InPlaceAbstractState::initialize):
(JSC::DFG::InPlaceAbstractState::endBasicBlock):
* dfg/DFGLiveCatchVariablePreservationPhase.cpp:
(JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
* dfg/DFGMaximalFlushInsertionPhase.cpp:
(JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
(JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
* dfg/DFGMayExit.cpp:
* dfg/DFGNode.cpp:
(JSC::DFG::Node::hasVariableAccessData):
* dfg/DFGNode.h:
(JSC::DFG::Node::convertPhantomToPhantomLocal):
* dfg/DFGNodeType.h:
* dfg/DFGOSREntrypointCreationPhase.cpp:
(JSC::DFG::OSREntrypointCreationPhase::run):
* dfg/DFGPhantomInsertionPhase.cpp:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSSAConversionPhase.cpp:
(JSC::DFG::SSAConversionPhase::run):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::checkArgumentTypes):
* 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):
2019-04-11 Truitt Savell <tsavell@apple.com>
Unreviewed, rolling out r244158.
Casued 8 inspector/timeline/ test failures.
Reverted changeset:
"Web Inspector: Timelines: can't reliably stop/start a
recording"
https://bugs.webkit.org/show_bug.cgi?id=196778
https://trac.webkit.org/changeset/244158
2019-04-10 Saam Barati <sbarati@apple.com>
AbstractValue::validateOSREntryValue is wrong for Int52 constants
https://bugs.webkit.org/show_bug.cgi?id=196801
<rdar://problem/49771122>
Reviewed by Yusuke Suzuki.
validateOSREntryValue should not care about the format of the incoming
value for Int52s. This patch normalizes the format of m_value and
the incoming value when comparing them.
* dfg/DFGAbstractValue.h:
(JSC::DFG::AbstractValue::validateOSREntryValue const):
2019-04-10 Saam Barati <sbarati@apple.com>
ArithSub over Int52 has shouldCheckOverflow as always true
https://bugs.webkit.org/show_bug.cgi?id=196796
Reviewed by Yusuke Suzuki.
AI was checking for ArithSub over Int52 if !shouldCheckOverflow. However,
shouldCheckOverflow is always true, so !shouldCheckOverflow is always
false. We shouldn't check something we assert against.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2019-04-10 Basuke Suzuki <basuke.suzuki@sony.com>
[PlayStation] Specify byte order clearly on Remote Inspector Protocol
https://bugs.webkit.org/show_bug.cgi?id=196790
Reviewed by Ross Kirsling.
Original implementation lacks byte order specification. Network byte order is the
good candidate if there's no strong reason to choose other.
Currently no client exists for PlayStation remote inspector protocol, so we can
change the byte order without care.
* inspector/remote/playstation/RemoteInspectorMessageParserPlayStation.cpp:
(Inspector::MessageParser::createMessage):
(Inspector::MessageParser::parse):
2019-04-10 Devin Rousso <drousso@apple.com>
Web Inspector: Inspector: lazily create the agent
https://bugs.webkit.org/show_bug.cgi?id=195971
<rdar://problem/49039645>
Reviewed by Joseph Pecoraro.
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
(Inspector::JSGlobalObjectInspectorController::connectFrontend):
(Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
(Inspector::JSGlobalObjectInspectorController::createLazyAgents):
* inspector/agents/InspectorAgent.h:
* inspector/agents/InspectorAgent.cpp:
2019-04-10 Saam Barati <sbarati@apple.com>
Work around an arm64_32 LLVM miscompile bug
https://bugs.webkit.org/show_bug.cgi?id=196788
Reviewed by Yusuke Suzuki.
* runtime/CachedTypes.cpp:
2019-04-10 Devin Rousso <drousso@apple.com>
Web Inspector: Timelines: can't reliably stop/start a recording
https://bugs.webkit.org/show_bug.cgi?id=196778
<rdar://problem/47606798>
Reviewed by Timothy Hatcher.
* inspector/protocol/ScriptProfiler.json:
* inspector/protocol/Timeline.json:
It is possible to determine when programmatic capturing starts/stops in the frontend based
on the state when the backend causes the state to change, such as if the state is "inactive"
when the frontend is told that the backend has started capturing.
* inspector/protocol/CPUProfiler.json:
* inspector/protocol/Memory.json:
Send an end timestamp to match other instruments.
* inspector/JSGlobalObjectConsoleClient.cpp:
(Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
(Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
* inspector/agents/InspectorScriptProfilerAgent.h:
* inspector/agents/InspectorScriptProfilerAgent.cpp:
(Inspector::InspectorScriptProfilerAgent::trackingComplete):
(Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted): Deleted.
(Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped): Deleted.
2019-04-10 Tadeu Zagallo <tzagallo@apple.com>
Unreviewed, fix watch build after r244143
https://bugs.webkit.org/show_bug.cgi?id=195000
The result of `lseek` should be `off_t` rather than `int`.
* jsc.cpp:
2019-04-10 Tadeu Zagallo <tzagallo@apple.com>
Add support for incremental bytecode cache updates
https://bugs.webkit.org/show_bug.cgi?id=195000
Reviewed by Filip Pizlo.
Add support for incremental updates to the bytecode cache. The cache
is constructed as follows:
- When the cache is empty, the initial payload can be added to the BytecodeCache
by calling BytecodeCache::addGlobalUpdate. This represents the encoded
top-level UnlinkedCodeBlock.
- Afterwards, updates can be added by calling BytecodeCache::addFunctionUpdate.
The update is applied by appending the encoded UnlinkedFunctionCodeBlock
to the existing cache and updating the CachedFunctionExecutableMetadata
and the offset of the new CachedFunctionCodeBlock in the owner CachedFunctionExecutable.
* API/JSScript.mm:
(-[JSScript readCache]):
(-[JSScript isUsingBytecodeCache]):
(-[JSScript init]):
(-[JSScript cachedBytecode]):
(-[JSScript writeCache:]):
* API/JSScriptInternal.h:
* API/JSScriptSourceProvider.h:
* API/JSScriptSourceProvider.mm:
(JSScriptSourceProvider::cachedBytecode const):
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::generateUnlinkedFunctionCodeBlock):
* jsc.cpp:
(ShellSourceProvider::~ShellSourceProvider):
(ShellSourceProvider::cachePath const):
(ShellSourceProvider::loadBytecode const):
(ShellSourceProvider::ShellSourceProvider):
(ShellSourceProvider::cacheEnabled):
* parser/SourceProvider.h:
(JSC::SourceProvider::cachedBytecode const):
(JSC::SourceProvider::updateCache const):
(JSC::SourceProvider::commitCachedBytecode const):
* runtime/CachePayload.cpp: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
(JSC::CachePayload::makeMappedPayload):
(JSC::CachePayload::makeMallocPayload):
(JSC::CachePayload::makeEmptyPayload):
(JSC::CachePayload::CachePayload):
(JSC::CachePayload::~CachePayload):
(JSC::CachePayload::operator=):
(JSC::CachePayload::freeData):
* runtime/CachePayload.h: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
(JSC::CachePayload::data const):
(JSC::CachePayload::size const):
(JSC::CachePayload::CachePayload):
* runtime/CacheUpdate.cpp: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
(JSC::CacheUpdate::CacheUpdate):
(JSC::CacheUpdate::operator=):
(JSC::CacheUpdate::isGlobal const):
(JSC::CacheUpdate::asGlobal const):
(JSC::CacheUpdate::asFunction const):
* runtime/CacheUpdate.h: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
* runtime/CachedBytecode.cpp: Added.
(JSC::CachedBytecode::addGlobalUpdate):
(JSC::CachedBytecode::addFunctionUpdate):
(JSC::CachedBytecode::copyLeafExecutables):
(JSC::CachedBytecode::commitUpdates const):
* runtime/CachedBytecode.h: Added.
(JSC::CachedBytecode::create):
(JSC::CachedBytecode::leafExecutables):
(JSC::CachedBytecode::data const):
(JSC::CachedBytecode::size const):
(JSC::CachedBytecode::hasUpdates const):
(JSC::CachedBytecode::sizeForUpdate const):
(JSC::CachedBytecode::CachedBytecode):
* runtime/CachedTypes.cpp:
(JSC::Encoder::addLeafExecutable):
(JSC::Encoder::release):
(JSC::Decoder::Decoder):
(JSC::Decoder::create):
(JSC::Decoder::size const):
(JSC::Decoder::offsetOf):
(JSC::Decoder::ptrForOffsetFromBase):
(JSC::Decoder::addLeafExecutable):
(JSC::VariableLengthObject::VariableLengthObject):
(JSC::VariableLengthObject::buffer const):
(JSC::CachedPtrOffsets::offsetOffset):
(JSC::CachedWriteBarrierOffsets::ptrOffset):
(JSC::CachedFunctionExecutable::features const):
(JSC::CachedFunctionExecutable::hasCapturedVariables const):
(JSC::CachedFunctionExecutableOffsets::codeBlockForCallOffset):
(JSC::CachedFunctionExecutableOffsets::codeBlockForConstructOffset):
(JSC::CachedFunctionExecutableOffsets::metadataOffset):
(JSC::CachedFunctionExecutable::encode):
(JSC::CachedFunctionExecutable::decode const):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::encodeCodeBlock):
(JSC::encodeFunctionCodeBlock):
(JSC::decodeCodeBlockImpl):
(JSC::isCachedBytecodeStillValid):
* runtime/CachedTypes.h:
(JSC::VariableLengthObjectBase::VariableLengthObjectBase):
(JSC::decodeCodeBlock):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::updateCache):
(JSC::CodeCache::write):
(JSC::writeCodeBlock):
(JSC::serializeBytecode):
* runtime/CodeCache.h:
(JSC::SourceCodeValue::SourceCodeValue):
(JSC::CodeCacheMap::findCacheAndUpdateAge):
(JSC::CodeCacheMap::fetchFromDiskImpl):
* runtime/Completion.cpp:
(JSC::generateProgramBytecode):
(JSC::generateModuleBytecode):
* runtime/Completion.h:
* runtime/LeafExecutable.cpp: Copied from Source/JavaScriptCore/API/JSScriptSourceProvider.mm.
(JSC::LeafExecutable::operator+ const):
* runtime/LeafExecutable.h: Copied from Source/JavaScriptCore/API/JSScriptSourceProvider.mm.
(JSC::LeafExecutable::LeafExecutable):
(JSC::LeafExecutable::base const):
2019-04-10 Michael Catanzaro <mcatanzaro@igalia.com>
Unreviewed, rolling out r243989.
Broke i686 builds
Reverted changeset:
"[CMake] Detect SSE2 at compile time"
https://bugs.webkit.org/show_bug.cgi?id=196488
https://trac.webkit.org/changeset/243989
2019-04-10 Robin Morisset <rmorisset@apple.com>
We should clear m_needsOverflowCheck when hitting an exception in defineProperties in ObjectConstructor.cpp
https://bugs.webkit.org/show_bug.cgi?id=196746
Reviewed by Yusuke Suzuki..
It should be safe as in that case we are not completing the operation, and so not going to have any buffer overflow.
* runtime/ObjectConstructor.cpp:
(JSC::defineProperties):
2019-04-10 Antoine Quint <graouts@apple.com>
Enable Pointer Events on watchOS
https://bugs.webkit.org/show_bug.cgi?id=196771
<rdar://problem/49040909>
Reviewed by Dean Jackson.
* Configurations/FeatureDefines.xcconfig:
2019-04-09 Keith Rollin <krollin@apple.com>
Unreviewed build maintenance -- update .xcfilelists.
* DerivedSources-input.xcfilelist:
2019-04-09 Ross Kirsling <ross.kirsling@sony.com>
JSC should build successfully even with -DENABLE_UNIFIED_BUILDS=OFF
https://bugs.webkit.org/show_bug.cgi?id=193073
Reviewed by Keith Miller.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitEqualityOpImpl):
(JSC::BytecodeGenerator::emitEqualityOp): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::emitEqualityOp):
Factor out the logic that uses the template parameter and keep it in the header.
* jit/JITPropertyAccess.cpp:
List off the template specializations needed by JITOperations.cpp.
This is unfortunate but at least there are only two (x2) by definition?
Trying to do away with this incurs a severe domino effect...
* API/JSValueRef.cpp:
* b3/B3OptimizeAssociativeExpressionTrees.cpp:
* b3/air/AirHandleCalleeSaves.cpp:
* builtins/BuiltinNames.cpp:
* bytecode/AccessCase.cpp:
* bytecode/BytecodeIntrinsicRegistry.cpp:
* bytecode/BytecodeIntrinsicRegistry.h:
* bytecode/BytecodeRewriter.cpp:
* bytecode/BytecodeUseDef.h:
* bytecode/CodeBlock.cpp:
* bytecode/InstanceOfAccessCase.cpp:
* bytecode/MetadataTable.cpp:
* bytecode/PolyProtoAccessChain.cpp:
* bytecode/StructureSet.cpp:
* bytecompiler/NodesCodegen.cpp:
* dfg/DFGCFAPhase.cpp:
* dfg/DFGPureValue.cpp:
* heap/GCSegmentedArray.h:
* heap/HeapInlines.h:
* heap/IsoSubspace.cpp:
* heap/LocalAllocator.cpp:
* heap/LocalAllocator.h:
* heap/LocalAllocatorInlines.h:
* heap/MarkingConstraintSolver.cpp:
* inspector/ScriptArguments.cpp:
(Inspector::ScriptArguments::isEqual const):
* inspector/ScriptCallStackFactory.cpp:
* interpreter/CallFrame.h:
* interpreter/Interpreter.cpp:
* interpreter/StackVisitor.cpp:
* llint/LLIntEntrypoint.cpp:
* runtime/ArrayIteratorPrototype.cpp:
* runtime/BigIntPrototype.cpp:
* runtime/CachedTypes.cpp:
* runtime/ErrorType.cpp:
* runtime/IndexingType.cpp:
* runtime/JSCellInlines.h:
* runtime/JSImmutableButterfly.h:
* runtime/Operations.h:
* runtime/RegExpCachedResult.cpp:
* runtime/RegExpConstructor.cpp:
* runtime/RegExpGlobalData.cpp:
* runtime/StackFrame.h:
* wasm/WasmSignature.cpp:
* wasm/js/JSToWasm.cpp:
* wasm/js/JSToWasmICCallee.cpp:
* wasm/js/WebAssemblyFunction.h:
Fix includes / forward declarations (and a couple of nearby clang warnings).
2019-04-09 Don Olmstead <don.olmstead@sony.com>
[CMake] Apple builds should use ICU_INCLUDE_DIRS
https://bugs.webkit.org/show_bug.cgi?id=196720
Reviewed by Konstantin Tokarev.
* PlatformMac.cmake:
2019-04-09 Saam barati <sbarati@apple.com>
Clean up Int52 code and some bugs in it
https://bugs.webkit.org/show_bug.cgi?id=196639
<rdar://problem/49515757>
Reviewed by Yusuke Suzuki.
This patch fixes bugs in our Int52 code. The primary change in this patch is
adopting a segregated type lattice for Int52. Previously, for Int52 values,
we represented them with SpecInt32Only and SpecInt52Only. For an Int52,
SpecInt32Only meant that the value is in int32 range. And SpecInt52Only meant
that the is outside of the int32 range.
However, this got confusing because we reused SpecInt32Only both for JSValue
representations and Int52 representations. This actually lead to some bugs.
1. It's possible that roundtripping through Int52 representation would say
it produces the wrong type. For example, consider this program and how we
used to annotate types in AI:
a: JSConstant(10.0) => m_type is SpecAnyIntAsDouble
b: Int52Rep(@a) => m_type is SpecInt52Only
c: ValueRep(@b) => m_type is SpecAnyIntAsDouble
In AI, for the above program, we'd say that @c produces SpecAnyIntAsDouble.
However, the execution semantics are such that it'd actually produce a boxed
Int32. This patch fixes the bug where we'd say that Int52Rep over SpecAnyIntAsDouble
would produce SpecInt52Only. This is clearly wrong, as SpecAnyIntAsDouble can
mean an int value in either int32 or int52 range.
2. AsbstractValue::validateTypeAcceptingBoxedInt52 was wrong in how it
accepted Int52 values. It was wrong in two different ways:
a: If the AbstractValue's type was SpecInt52Only, and the incoming value
was a boxed double, but represented a value in int32 range, the incoming
value would incorrectly validate as being acceptable. However, we should
have rejected this value.
b: If the AbstractValue's type was SpecInt32Only, and the incoming value
was an Int32 boxed in a double, this would not validate, even though
it should have validated.
Solving 2 was easiest if we segregated out the Int52 type into its own
lattice. This patch makes a new Int52 lattice, which is composed of
SpecInt32AsInt52 and SpecNonInt32AsInt52.
The conversion rules are now really simple.
Int52 rep => JSValue rep
SpecInt32AsInt52 => SpecInt32Only
SpecNonInt32AsInt52 => SpecAnyIntAsDouble
JSValue rep => Int52 rep
SpecInt32Only => SpecInt32AsInt52
SpecAnyIntAsDouble => SpecInt52Any
With these rules, the program in (1) will now correctly report that @c
returns SpecInt32Only | SpecAnyIntAsDouble.
* bytecode/SpeculatedType.cpp:
(JSC::dumpSpeculation):
(JSC::speculationToAbbreviatedString):
(JSC::int52AwareSpeculationFromValue):
(JSC::leastUpperBoundOfStrictlyEquivalentSpeculations):
(JSC::speculationFromString):
* bytecode/SpeculatedType.h:
(JSC::isInt32SpeculationForArithmetic):
(JSC::isInt32OrBooleanSpeculationForArithmetic):
(JSC::isAnyInt52Speculation):
(JSC::isIntAnyFormat):
(JSC::isInt52Speculation): Deleted.
(JSC::isAnyIntSpeculation): Deleted.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::fixTypeForRepresentation):
(JSC::DFG::AbstractValue::checkConsistency const):
* dfg/DFGAbstractValue.h:
(JSC::DFG::AbstractValue::isInt52Any const):
(JSC::DFG::AbstractValue::validateTypeAcceptingBoxedInt52 const):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupArithMul):
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::fixupGetPrototypeOf):
(JSC::DFG::FixupPhase::fixupToThis):
(JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor):
(JSC::DFG::FixupPhase::observeUseKindOnNode):
(JSC::DFG::FixupPhase::fixIntConvertingEdge):
(JSC::DFG::FixupPhase::attemptToMakeIntegerAdd):
(JSC::DFG::FixupPhase::fixupCompareStrictEqAndSameValue):
(JSC::DFG::FixupPhase::fixupChecksInBlock):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::addShouldSpeculateInt52):
(JSC::DFG::Graph::binaryArithShouldSpeculateInt52):
(JSC::DFG::Graph::unaryArithShouldSpeculateInt52):
(JSC::DFG::Graph::addShouldSpeculateAnyInt): Deleted.
(JSC::DFG::Graph::binaryArithShouldSpeculateAnyInt): Deleted.
(JSC::DFG::Graph::unaryArithShouldSpeculateAnyInt): Deleted.
* dfg/DFGNode.h:
(JSC::DFG::Node::shouldSpeculateInt52):
(JSC::DFG::Node::shouldSpeculateAnyInt): Deleted.
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::setIntTypedArrayLoadResult):
(JSC::DFG::SpeculativeJIT::compileArithAdd):
(JSC::DFG::SpeculativeJIT::compileArithSub):
(JSC::DFG::SpeculativeJIT::compileArithNegate):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
(JSC::DFG::SpeculativeJIT::fillSpeculateInt52):
* dfg/DFGUseKind.h:
(JSC::DFG::typeFilterFor):
* dfg/DFGVariableAccessData.cpp:
(JSC::DFG::VariableAccessData::makePredictionForDoubleFormat):
(JSC::DFG::VariableAccessData::couldRepresentInt52Impl):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
(JSC::FTL::DFG::LowerDFGToB3::compileArithNegate):
(JSC::FTL::DFG::LowerDFGToB3::setIntTypedArrayLoadResult):
2019-04-09 Tadeu Zagallo <tzagallo@apple.com>
ASSERTION FAILED: !scope.exception() || !hasProperty in JSObject::get
https://bugs.webkit.org/show_bug.cgi?id=196708
<rdar://problem/49556803>
Reviewed by Yusuke Suzuki.
`operationPutToScope` needs to return early if an exception is thrown while
checking if `hasProperty`.
* jit/JITOperations.cpp:
2019-04-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] DFG should respect node's strict flag
https://bugs.webkit.org/show_bug.cgi?id=196617
Reviewed by Saam Barati.
We accidentally use codeBlock->isStrictMode() directly in DFG and FTL. But this is wrong since this CodeBlock is the top level DFG/FTL CodeBlock,
and this code does not respect the isStrictMode flag for the inlined CodeBlocks. In this patch, we start using isStrictModeFor(CodeOrigin) consistently
in DFG and FTL to get the right isStrictMode flag for the DFG node.
And we also split compilePutDynamicVar into compilePutDynamicVarStrict and compilePutDynamicVarNonStrict since (1) it is cleaner than accessing inlined
callframe in the operation function, and (2) it is aligned to the other functions like operationPutByValDirectNonStrict etc.
This bug is discovered by RandomizingFuzzerAgent by expanding the DFG coverage.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupToThis):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
(JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
(JSC::DFG::SpeculativeJIT::compilePutDynamicVar):
(JSC::DFG::SpeculativeJIT::compileToThis):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compileContiguousPutByVal):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
(JSC::FTL::DFG::LowerDFGToB3::compilePutDynamicVar):
2019-04-08 Don Olmstead <don.olmstead@sony.com>
[CMake][WinCairo] Separate copied headers into different directories
https://bugs.webkit.org/show_bug.cgi?id=196655
Reviewed by Michael Catanzaro.
* CMakeLists.txt:
* shell/PlatformWin.cmake:
2019-04-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] isRope jump in StringSlice should not jump over register allocations
https://bugs.webkit.org/show_bug.cgi?id=196716
Reviewed by Saam Barati.
Jumping over the register allocation code in DFG (like the following) is wrong.
auto jump = m_jit.branchXXX();
{
GPRTemporary reg(this);
GPRReg regGPR = reg.gpr();
...
}
jump.link(&m_jit);
When GPRTemporary::gpr allocates a new register, it can flush the previous register value into the stack and make the register usable.
Jumping over this register allocation code skips the flushing code, and makes the DFG's stack and register content tracking inconsistent:
DFG thinks that the content is flushed and stored in particular stack slot even while this flushing code is skipped.
In this patch, we perform register allocations before jumping to the slow path based on `isRope` condition in StringSlice.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileStringSlice):
2019-04-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] to_index_string should not assume incoming value is Uint32
https://bugs.webkit.org/show_bug.cgi?id=196713
Reviewed by Saam Barati.
The slow path of to_index_string assumes that incoming value is Uint32. But we should not have
this assumption since DFG may decide we should have it double format. This patch removes this
assumption, and instead, we should assume that incoming value is AnyInt and the range of this
is within Uint32.
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
2019-04-08 Justin Fan <justin_fan@apple.com>
[Web GPU] Fix Web GPU experimental feature on iOS
https://bugs.webkit.org/show_bug.cgi?id=196632
Reviewed by Myles C. Maxfield.
Properly make Web GPU available on iOS 11+.
* Configurations/FeatureDefines.xcconfig:
* Configurations/WebKitTargetConditionals.xcconfig:
2019-04-08 Ross Kirsling <ross.kirsling@sony.com>
-f[no-]var-tracking-assignments is GCC-only
https://bugs.webkit.org/show_bug.cgi?id=196699
Reviewed by Don Olmstead.
* CMakeLists.txt:
Just remove the build flag altogether -- it supposedly doesn't solve the problem it was meant to
and said problem evidently no longer occurs as of GCC 9.
2019-04-08 Saam Barati <sbarati@apple.com>
WebAssembly.RuntimeError missing exception check
https://bugs.webkit.org/show_bug.cgi?id=196700
<rdar://problem/49693932>
Reviewed by Yusuke Suzuki.
* wasm/js/JSWebAssemblyRuntimeError.h:
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
(JSC::constructJSWebAssemblyRuntimeError):
2019-04-08 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, rolling in r243948 with test fix
https://bugs.webkit.org/show_bug.cgi?id=196486
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createString):
* parser/Lexer.cpp:
(JSC::Lexer<T>::parseMultilineComment):
(JSC::Lexer<T>::lexWithoutClearingLineTerminator):
(JSC::Lexer<T>::lex): Deleted.
* parser/Lexer.h:
(JSC::Lexer::hasLineTerminatorBeforeToken const):
(JSC::Lexer::setHasLineTerminatorBeforeToken):
(JSC::Lexer<T>::lex):
(JSC::Lexer::prevTerminator const): Deleted.
(JSC::Lexer::setTerminator): Deleted.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::allowAutomaticSemicolon):
(JSC::Parser<LexerType>::parseSingleFunction):
(JSC::Parser<LexerType>::parseStatementListItem):
(JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseExportDeclaration):
(JSC::Parser<LexerType>::parseAssignmentExpression):
(JSC::Parser<LexerType>::parseYieldExpression):
(JSC::Parser<LexerType>::parseProperty):
(JSC::Parser<LexerType>::parsePrimaryExpression):
(JSC::Parser<LexerType>::parseMemberExpression):
* parser/Parser.h:
(JSC::Parser::nextWithoutClearingLineTerminator):
(JSC::Parser::lexCurrentTokenAgainUnderCurrentContext):
(JSC::Parser::internalSaveLexerState):
(JSC::Parser::restoreLexerState):
2019-04-08 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r243948.
Caused inspector/runtime/parse.html to fail
Reverted changeset:
"SIGSEGV in JSC::BytecodeGenerator::addStringConstant"
https://bugs.webkit.org/show_bug.cgi?id=196486
https://trac.webkit.org/changeset/243948
2019-04-08 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r243943.
Caused test262 failures.
Reverted changeset:
"[JSC] Filter DontEnum properties in
ProxyObject::getOwnPropertyNames()"
https://bugs.webkit.org/show_bug.cgi?id=176810
https://trac.webkit.org/changeset/243943
2019-04-08 Claudio Saavedra <csaavedra@igalia.com>
[JSC] Partially fix the build with unified builds disabled
https://bugs.webkit.org/show_bug.cgi?id=196647
Reviewed by Konstantin Tokarev.
If you disable unified builds you find all kind of build
errors. This partially tries to fix them but there's a lot
more.
* API/JSBaseInternal.h:
* b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp:
* b3/air/AirHandleCalleeSaves.h:
* bytecode/ExecutableToCodeBlockEdge.cpp:
* bytecode/ExitFlag.h:
* bytecode/ICStatusUtils.h:
* bytecode/UnlinkedMetadataTable.h:
* dfg/DFGPureValue.h:
* heap/IsoAlignedMemoryAllocator.cpp:
* heap/IsoAlignedMemoryAllocator.h:
2019-04-08 Guillaume Emont <guijemont@igalia.com>
Enable DFG on MIPS
https://bugs.webkit.org/show_bug.cgi?id=196689
Reviewed by Žan Doberšek.
Since the bytecode change, we enabled the baseline JIT on mips in
r240432, but DFG is still missing. With this change, all tests are
passing on a ci20 board.
* jit/RegisterSet.cpp:
(JSC::RegisterSet::calleeSaveRegisters):
Added s0, which is used in llint.
2019-04-08 Xan Lopez <xan@igalia.com>
[CMake] Detect SSE2 at compile time
https://bugs.webkit.org/show_bug.cgi?id=196488
Reviewed by Carlos Garcia Campos.
* assembler/MacroAssemblerX86Common.cpp: Remove unnecessary (and
incorrect) static_assert.
2019-04-07 Michael Saboff <msaboff@apple.com>
REGRESSION (r243642): Crash in reddit.com page
https://bugs.webkit.org/show_bug.cgi?id=196684
Reviewed by Geoffrey Garen.
In r243642, the code that saves and restores the count for non-greedy character classes
was inadvertently put inside an if statement. This code should be generated for all
non-greedy character classes.
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::generateCharacterClassNonGreedy):
(JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):
2019-04-07 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] CallLinkInfo should clear Callee or CodeBlock even if it is unlinked by jettison
https://bugs.webkit.org/show_bug.cgi?id=196683
Reviewed by Saam Barati.
In r243626, we stop repatching CallLinkInfo when the CallLinkInfo is held by jettisoned CodeBlock.
But we still need to clear the Callee or CodeBlock since they are now dead. Otherwise, CodeBlock's
visitWeak eventually accesses this dead cells and crashes because the owner CodeBlock of CallLinkInfo
can be still live.
We also move all repatching operations from CallLinkInfo.cpp to Repatch.cpp for consistency because the
other repatching operations in CallLinkInfo are implemented in Repatch.cpp side.
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::setCallee):
(JSC::CallLinkInfo::clearCallee):
* jit/Repatch.cpp:
(JSC::linkFor):
(JSC::revertCall):
2019-04-05 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] OSRExit recovery for SpeculativeAdd does not consier "A = A + A" pattern
https://bugs.webkit.org/show_bug.cgi?id=196582
Reviewed by Saam Barati.
In DFG, our ArithAdd with overflow is executed speculatively, and we recover the value when overflow flag is set.
The recovery is subtracting the operand from the destination to get the original two operands. Our recovery code
handles A + B = A, A + B = B cases. But it misses A + A = A case (here, A and B are GPRReg). Our recovery code
attempts to produce the original operand by performing A - A, and it always produces zero accidentally.
This patch adds the recovery code for A + A = A case. Because we know that this ArithAdd overflows, and operands were
same values, we can calculate the original operand from the destination value by `((int32_t)value >> 1) ^ 0x80000000`.
We also found that FTL recovery code is dead. We remove them in this patch.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::executeOSRExit):
(JSC::DFG::OSRExit::compileExit):
* dfg/DFGOSRExit.h:
(JSC::DFG::SpeculationRecovery::SpeculationRecovery):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithAdd):
* ftl/FTLExitValue.cpp:
(JSC::FTL::ExitValue::dataFormat const):
(JSC::FTL::ExitValue::dumpInContext const):
* ftl/FTLExitValue.h:
(JSC::FTL::ExitValue::isArgument const):
(JSC::FTL::ExitValue::hasIndexInStackmapLocations const):
(JSC::FTL::ExitValue::adjustStackmapLocationsIndexByOffset):
(JSC::FTL::ExitValue::recovery): Deleted.
(JSC::FTL::ExitValue::isRecovery const): Deleted.
(JSC::FTL::ExitValue::leftRecoveryArgument const): Deleted.
(JSC::FTL::ExitValue::rightRecoveryArgument const): Deleted.
(JSC::FTL::ExitValue::recoveryFormat const): Deleted.
(JSC::FTL::ExitValue::recoveryOpcode const): Deleted.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::preparePatchpointForExceptions):
(JSC::FTL::DFG::LowerDFGToB3::appendOSRExit):
(JSC::FTL::DFG::LowerDFGToB3::exitValueForNode):
(JSC::FTL::DFG::LowerDFGToB3::addAvailableRecovery): Deleted.
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileRecovery):
2019-04-05 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r243665.
Caused iOS JSC tests to exit with an exception.
Reverted changeset:
"Assertion failed in JSC::createError"
https://bugs.webkit.org/show_bug.cgi?id=196305
https://trac.webkit.org/changeset/243665
2019-04-05 Yusuke Suzuki <ysuzuki@apple.com>
SIGSEGV in JSC::BytecodeGenerator::addStringConstant
https://bugs.webkit.org/show_bug.cgi?id=196486
Reviewed by Saam Barati.
When parsing a FunctionExpression / FunctionDeclaration etc., we use SyntaxChecker for the body of the function because we do not have any interest on the nodes of the body at that time.
The nodes will be parsed with the ASTBuilder when the function itself is parsed for code generation. This works well previously because all the function ends with "}" previously.
SyntaxChecker lexes this "}" token, and parser restores the context back to ASTBuilder and continues parsing.
But now, we have ArrowFunctionExpression without braces `arrow => expr`. Let's consider the following code.
arrow => expr
"string!"
We parse arrow function's body with SyntaxChecker. At that time, we lex "string!" token under the SyntaxChecker context. But this means that we may not build string content for this token
since SyntaxChecker may not have interest on string content itself in certain case. After the parser is back to ASTBuilder, we parse "string!" as ExpressionStatement with string constant,
generate StringNode with non-built identifier (nullptr), and we accidentally create StringNode with nullptr.
This patch fixes this problem. The root cause of this problem is that the last token lexed in the previous context is used. We add lexCurrentTokenAgainUnderCurrentContext which will re-lex
the current token under the current context (may be ASTBuilder). This should be done only when the caller's context is different from SyntaxChecker, which avoids unnecessary lexing.
We leverage existing SavePoint mechanism to implement lexCurrentTokenAgainUnderCurrentContext cleanly.
And we also fix the bug in the existing SavePoint mechanism, which is shown in the attached test script. When we save LexerState, we do not save line terminator status. This patch also introduces
lexWithoutClearingLineTerminator, which lex the token without clearing line terminator status.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createString):
* parser/Lexer.cpp:
(JSC::Lexer<T>::parseMultilineComment):
(JSC::Lexer<T>::lexWithoutClearingLineTerminator): EOF token also should record offset information. This offset information is correctly handled in Lexer::setOffset too.
(JSC::Lexer<T>::lex): Deleted.
* parser/Lexer.h:
(JSC::Lexer::hasLineTerminatorBeforeToken const):
(JSC::Lexer::setHasLineTerminatorBeforeToken):
(JSC::Lexer<T>::lex):
(JSC::Lexer::prevTerminator const): Deleted.
(JSC::Lexer::setTerminator): Deleted.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::allowAutomaticSemicolon):
(JSC::Parser<LexerType>::parseSingleFunction):
(JSC::Parser<LexerType>::parseStatementListItem):
(JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseExportDeclaration):
(JSC::Parser<LexerType>::parseAssignmentExpression):
(JSC::Parser<LexerType>::parseYieldExpression):
(JSC::Parser<LexerType>::parseProperty):
(JSC::Parser<LexerType>::parsePrimaryExpression):
(JSC::Parser<LexerType>::parseMemberExpression):
* parser/Parser.h:
(JSC::Parser::nextWithoutClearingLineTerminator):
(JSC::Parser::lexCurrentTokenAgainUnderCurrentContext):
(JSC::Parser::internalSaveLexerState):
(JSC::Parser::restoreLexerState):
2019-04-05 Caitlin Potter <caitp@igalia.com>
[JSC] Filter DontEnum properties in ProxyObject::getOwnPropertyNames()
https://bugs.webkit.org/show_bug.cgi?id=176810
Reviewed by Saam Barati.
This adds conditional logic following the invariant checks, to perform
filtering in common uses of getOwnPropertyNames.
While this would ideally only be done in JSPropertyNameEnumerator, adding
the filtering to ProxyObject::performGetOwnPropertyNames maintains the
invariant that the EnumerationMode is properly followed.
* runtime/PropertyNameArray.h:
(JSC::PropertyNameArray::reset):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::performGetOwnPropertyNames):
2019-04-05 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r243833.
https://bugs.webkit.org/show_bug.cgi?id=196645
This change breaks build of WPE and GTK ports (Requested by
annulen on #webkit).
Reverted changeset:
"[CMake][WTF] Mirror XCode header directories"
https://bugs.webkit.org/show_bug.cgi?id=191662
https://trac.webkit.org/changeset/243833
2019-04-05 Caitlin Potter <caitp@igalia.com>
[JSC] throw if ownKeys Proxy trap result contains duplicate keys
https://bugs.webkit.org/show_bug.cgi?id=185211
Reviewed by Saam Barati.
Implements the normative spec change in https://github.com/tc39/ecma262/pull/833
This involves tracking duplicate keys returned from the ownKeys trap in yet
another HashTable, and may incur a minor performance penalty in some cases. This
is not expected to significantly affect web performance.
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::performGetOwnPropertyNames):
2019-04-04 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] makeBoundFunction should not assume incoming "length" value is Int32 because it performs some calculation in bytecode
https://bugs.webkit.org/show_bug.cgi?id=196631
Reviewed by Saam Barati.
makeBoundFunction assumes that "length" argument is always Int32. But this should not be done since this "length" value is calculated in builtin JS code.
DFG may store this value in Double format so that we should not rely on that this value is Int32. This patch fixes makeBoundFunction function to perform
toInt32 operation. We also insert a missing exception check for `JSString::value(ExecState*)` in makeBoundFunction.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* interpreter/CallFrameInlines.h:
* runtime/DoublePredictionFuzzerAgent.cpp: Copied from Source/JavaScriptCore/interpreter/CallFrameInlines.h.
(JSC::DoublePredictionFuzzerAgent::DoublePredictionFuzzerAgent):
(JSC::DoublePredictionFuzzerAgent::getPrediction):
* runtime/DoublePredictionFuzzerAgent.h: Copied from Source/JavaScriptCore/interpreter/CallFrameInlines.h.
* runtime/JSGlobalObject.cpp:
(JSC::makeBoundFunction):
* runtime/Options.h:
* runtime/VM.cpp:
(JSC::VM::VM):
2019-04-04 Robin Morisset <rmorisset@apple.com>
B3ReduceStrength should know that Mul distributes over Add and Sub
https://bugs.webkit.org/show_bug.cgi?id=196325
<rdar://problem/49441650>
Reviewed by Saam Barati.
Fix some obviously wrong code that was due to an accidental copy-paste.
It made the entire optimization dead code that never ran.
* b3/B3ReduceStrength.cpp:
2019-04-04 Saam Barati <sbarati@apple.com>
Unreviewed, build fix for CLoop after r243886
* interpreter/Interpreter.cpp:
(JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::calleeSaveRegistersForUnwinding):
* interpreter/StackVisitor.h:
2019-04-04 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r243898.
https://bugs.webkit.org/show_bug.cgi?id=196624
`#if !ENABLE(C_LOOP) && NUMBER_OF_CALLEE_SAVES_REGISTERS > 0`
does not work well (Requested by yusukesuzuki on #webkit).
Reverted changeset:
"Unreviewed, build fix for CLoop and Windows after r243886"
https://bugs.webkit.org/show_bug.cgi?id=196387
https://trac.webkit.org/changeset/243898
2019-04-04 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, build fix for CLoop and Windows after r243886
https://bugs.webkit.org/show_bug.cgi?id=196387
RegisterAtOffsetList does not exist if ENABLE(ASSEMBLER) is false.
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::calleeSaveRegistersForUnwinding):
* interpreter/StackVisitor.h:
2019-04-04 Saam barati <sbarati@apple.com>
Teach Call ICs how to call Wasm
https://bugs.webkit.org/show_bug.cgi?id=196387
Reviewed by Filip Pizlo.
This patch teaches JS to call Wasm without going through the native thunk.
Currently, we emit a JIT "JS" callee stub which marshals arguments from
JS to Wasm. Like the native version of this, this thunk is responsible
for saving and restoring the VM's current Wasm context. Instead of emitting
an exception handler, we also teach the unwinder how to read the previous
wasm context to restore it as it unwindws past this frame.
This patch is straight forward, and leaves some areas for perf improvement:
- We can teach the DFG/FTL to directly use the Wasm calling convention when
it knows it's calling a single Wasm function. This way we don't shuffle
registers to the stack and then back into registers.
- We bail out to the slow path for mismatched arity. I opened a bug to fix
optimize arity check failures: https://bugs.webkit.org/show_bug.cgi?id=196564
- We bail out to the slow path Double JSValues flowing into i32 arguments.
We should teach this thunk how to do that conversion directly.
This patch also refactors the code to explicitly have a single pinned size register.
We used pretend in some places that we could have more than one pinned size register.
However, there was other code that just asserted the size was one. This patch just rips
out this code since we never moved to having more than one pinned size register. Doing
this refactoring cleans up the various places where we set up the size register.
This patch is a 50-60% progression on JetStream 2's richards-wasm.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* assembler/MacroAssemblerCodeRef.h:
(JSC::MacroAssemblerCodeRef::operator=):
(JSC::MacroAssemblerCodeRef::MacroAssemblerCodeRef):
* interpreter/Interpreter.cpp:
(JSC::UnwindFunctor::operator() const):
(JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::calleeSaveRegistersForUnwinding):
(JSC::StackVisitor::Frame::calleeSaveRegisters): Deleted.
* interpreter/StackVisitor.h:
* jit/JITOperations.cpp:
* jit/RegisterSet.cpp:
(JSC::RegisterSet::runtimeTagRegisters):
(JSC::RegisterSet::specialRegisters):
(JSC::RegisterSet::runtimeRegisters): Deleted.
* jit/RegisterSet.h:
* jit/Repatch.cpp:
(JSC::linkPolymorphicCall):
* runtime/JSFunction.cpp:
(JSC::getCalculatedDisplayName):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::jsToWasmICCalleeStructure const):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::AirIRGenerator):
(JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
(JSC::Wasm::AirIRGenerator::addCallIndirect):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
(JSC::Wasm::B3IRGenerator::addCallIndirect):
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToWasm):
* wasm/WasmContext.h:
(JSC::Wasm::Context::pointerToInstance):
* wasm/WasmContextInlines.h:
(JSC::Wasm::Context::store):
* wasm/WasmMemoryInformation.cpp:
(JSC::Wasm::getPinnedRegisters):
(JSC::Wasm::PinnedRegisterInfo::get):
(JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
* wasm/WasmMemoryInformation.h:
(JSC::Wasm::PinnedRegisterInfo::toSave const):
* wasm/WasmOMGPlan.cpp:
(JSC::Wasm::OMGPlan::work):
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::createJSToWasmWrapper):
* wasm/js/JSToWasmICCallee.cpp: Added.
(JSC::JSToWasmICCallee::create):
(JSC::JSToWasmICCallee::createStructure):
(JSC::JSToWasmICCallee::visitChildren):
* wasm/js/JSToWasmICCallee.h: Added.
(JSC::JSToWasmICCallee::function):
(JSC::JSToWasmICCallee::JSToWasmICCallee):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::useTagRegisters const):
(JSC::WebAssemblyFunction::calleeSaves const):
(JSC::WebAssemblyFunction::usedCalleeSaveRegisters const):
(JSC::WebAssemblyFunction::previousInstanceOffset const):
(JSC::WebAssemblyFunction::previousInstance):
(JSC::WebAssemblyFunction::jsCallEntrypointSlow):
(JSC::WebAssemblyFunction::visitChildren):
(JSC::WebAssemblyFunction::destroy):
* wasm/js/WebAssemblyFunction.h:
* wasm/js/WebAssemblyFunctionHeapCellType.cpp: Added.
(JSC::WebAssemblyFunctionDestroyFunc::operator() const):
(JSC::WebAssemblyFunctionHeapCellType::WebAssemblyFunctionHeapCellType):
(JSC::WebAssemblyFunctionHeapCellType::~WebAssemblyFunctionHeapCellType):
(JSC::WebAssemblyFunctionHeapCellType::finishSweep):
(JSC::WebAssemblyFunctionHeapCellType::destroy):
* wasm/js/WebAssemblyFunctionHeapCellType.h: Added.
* wasm/js/WebAssemblyPrototype.h:
2019-04-04 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Pass CodeOrigin to FuzzerAgent
https://bugs.webkit.org/show_bug.cgi?id=196590
Reviewed by Saam Barati.
Pass CodeOrigin instead of bytecodeIndex. CodeOrigin includes richer information (InlineCallFrame*).
We also mask prediction with SpecBytecodeTop in DFGByteCodeParser. The fuzzer can produce any SpeculatedTypes,
but DFGByteCodeParser should only see predictions that can be actually produced from the bytecode execution.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
* runtime/FuzzerAgent.cpp:
(JSC::FuzzerAgent::getPrediction):
* runtime/FuzzerAgent.h:
* runtime/RandomizingFuzzerAgent.cpp:
(JSC::RandomizingFuzzerAgent::getPrediction):
* runtime/RandomizingFuzzerAgent.h:
2019-04-04 Caio Lima <ticaiolima@gmail.com>
[JSC] We should consider moving UnlinkedFunctionExecutable::m_parentScopeTDZVariables to RareData
https://bugs.webkit.org/show_bug.cgi?id=194944
Reviewed by Keith Miller.
Based on profile data collected on JetStream2, Speedometer 2 and
other benchmarks, it is very rare having non-empty
UnlinkedFunctionExecutable::m_parentScopeTDZVariables.
- Data collected from Speedometer2
Total number of UnlinkedFunctionExecutable: 39463
Total number of non-empty parentScopeTDZVars: 428 (~1%)
- Data collected from JetStream2
Total number of UnlinkedFunctionExecutable: 83715
Total number of non-empty parentScopeTDZVars: 5285 (~6%)
We also collected numbers on 6 of top 10 Alexia sites.
- Data collected from youtube.com
Total number of UnlinkedFunctionExecutable: 29599
Total number of non-empty parentScopeTDZVars: 97 (~0.3%)
- Data collected from twitter.com
Total number of UnlinkedFunctionExecutable: 23774
Total number of non-empty parentScopeTDZVars: 172 (~0.7%)
- Data collected from google.com
Total number of UnlinkedFunctionExecutable: 33209
Total number of non-empty parentScopeTDZVars: 174 (~0.5%)
- Data collected from amazon.com:
Total number of UnlinkedFunctionExecutable: 15182
Total number of non-empty parentScopeTDZVars: 166 (~1%)
- Data collected from facebook.com:
Total number of UnlinkedFunctionExecutable: 54443
Total number of non-empty parentScopeTDZVars: 269 (~0.4%)
- Data collected from netflix.com:
Total number of UnlinkedFunctionExecutable: 39266
Total number of non-empty parentScopeTDZVars: 97 (~0.2%)
Considering such numbers, this patch is moving `m_parentScopeTDZVariables`
to RareData. This decreases sizeof(UnlinkedFunctionExecutable) by
16 bytes. With this change, now UnlinkedFunctionExecutable constructors
receives an `Optional<VariableEnvironmentMap::Handle>` and only stores
it when `value != WTF::nullopt`. We also changed
UnlinkedFunctionExecutable::parentScopeTDZVariables() and it returns
`VariableEnvironment()` whenever the Executable doesn't have RareData,
or VariableEnvironmentMap::Handle is unitialized. This is required
because RareData is instantiated when any of its field is stored and
we can have an unitialized `Handle` even on cases when parentScopeTDZVariables
is `WTF::nullopt`.
Results on memory usage on JetStrem2 is neutral.
Mean of memory peak on ToT: 4258633728 bytes (confidence interval: 249720072.95)
Mean of memory peak on Changes: 4367325184 bytes (confidence interval: 321285583.61)
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createExecutable):
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::getVariablesUnderTDZ):
BytecodeGenerator::getVariablesUnderTDZ now also caches if m_cachedVariablesUnderTDZ
is empty, so we can properly return `WTF::nullopt` without the
reconstruction of a VariableEnvironment to check if it is empty.
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::makeFunction):
* parser/VariableEnvironment.h:
(JSC::VariableEnvironment::isEmpty const):
* runtime/CachedTypes.cpp:
(JSC::CachedCompactVariableMapHandle::decode const):
It returns an unitialized Handle when there is no
CompactVariableEnvironment. This can happen when RareData is ensured
because of another field.
(JSC::CachedFunctionExecutableRareData::encode):
(JSC::CachedFunctionExecutableRareData::decode const):
(JSC::CachedFunctionExecutable::encode):
(JSC::CachedFunctionExecutable::decode const):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* runtime/CodeCache.cpp:
Instead of creating a dummyVariablesUnderTDZ, we simply pass
WTF::nullopt.
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
2019-04-04 Tadeu Zagallo <tzagallo@apple.com>
Cache bytecode for jsc.cpp helpers and fix CachedStringImpl
https://bugs.webkit.org/show_bug.cgi?id=196409
Reviewed by Saam Barati.
Some of the helpers in jsc.cpp, such as `functionRunString`, were stll using
using `makeSource` instead of `jscSource`, which does not use the ShellSourceProvider
and therefore does not write the bytecode cache to disk.
Changing that revealed a bug in bytecode cache. The Encoder keeps a mapping
of pointers to offsets of already cached objects, in order to avoid caching
the same object twice. Similarly, the Decoder keeps a mapping from offsets
to pointers, in order to avoid creating multiple objects in memory for the
same cached object. The following was happening:
1) A StringImpl* S was cached as CachedPtr<CachedStringImpl> at offset O. We add
an entry in the Encoder mapping that S has already been encoded at O.
2) We cache StringImpl* S again, but now as CachedPtr<CachedUniquedStringImpl>.
We find an entry in the Encoder mapping for S, and return the offset O. However,
the object cached at O is a CachedPtr<CachedStringImpl> (i.e. not Uniqued).
3) When decoding, there are 2 possibilities:
3.1) We find S for the first time through a CachedPtr<CachedStringImpl>. In
this case, everything works as expected since we add an entry in the decoder
mapping from the offset O to the decoded StringImpl* S. The next time we find
S through the uniqued version, we'll return the already decoded S.
3.2) We find S through a CachedPtr<CachedUniquedStringImpl>. Now we have a
problem, since the CachedPtr has the offset of a CachedStringImpl (not uniqued),
which has a different shape and we crash.
We fix this by making CachedStringImpl and CachedUniquedStringImpl share the
same implementation. Since it doesn't matter whether a string is uniqued for
encoding, and we always decode strings as uniqued either way, they can be used
interchangeably.
* jsc.cpp:
(functionRunString):
(functionLoadString):
(functionDollarAgentStart):
(functionCheckModuleSyntax):
(runInteractive):
* runtime/CachedTypes.cpp:
(JSC::CachedUniquedStringImplBase::decode const):
(JSC::CachedFunctionExecutable::rareData const):
(JSC::CachedCodeBlock::rareData const):
(JSC::CachedFunctionExecutable::encode):
(JSC::CachedCodeBlock<CodeBlockType>::encode):
(JSC::CachedUniquedStringImpl::encode): Deleted.
(JSC::CachedUniquedStringImpl::decode const): Deleted.
(JSC::CachedStringImpl::encode): Deleted.
(JSC::CachedStringImpl::decode const): Deleted.
2019-04-04 Tadeu Zagallo <tzagallo@apple.com>
UnlinkedCodeBlock constructor from cache should initialize m_didOptimize
https://bugs.webkit.org/show_bug.cgi?id=196396
Reviewed by Saam Barati.
The UnlinkedCodeBlock constructor in CachedTypes was missing the initialization
for m_didOptimize, which leads to crashes in CodeBlock::thresholdForJIT.
* runtime/CachedTypes.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
2019-04-03 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, rolling in r243843 with the build fix
https://bugs.webkit.org/show_bug.cgi?id=196586
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/Options.h:
* runtime/RandomizingFuzzerAgent.cpp:
(JSC::RandomizingFuzzerAgent::getPrediction):
2019-04-03 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r243843.
Broke CLoop and Windows builds.
Reverted changeset:
"[JSC] Add dump feature for RandomizingFuzzerAgent"
https://bugs.webkit.org/show_bug.cgi?id=196586
https://trac.webkit.org/changeset/243843
2019-04-03 Robin Morisset <rmorisset@apple.com>
B3 should use associativity to optimize expression trees
https://bugs.webkit.org/show_bug.cgi?id=194081
Reviewed by Filip Pizlo.
This patch adds a new B3 pass, that tries to find and optimize expression trees made purely of any one associative and commutative operator (Add/Mul/BitOr/BitAnd/BitXor).
The pass only runs in O2, and runs once, after lowerMacros and just before a run of B3ReduceStrength (which helps clean up the dead code it tends to leave behind).
I had to separate killDeadCode out of B3ReduceStrength (as a new B3EliminateDeadCode pass) to run it before B3OptimizeAssociativeExpressionTrees, as otherwise it is stopped by high use counts
inherited from CSE.
This extra run of DCE is by itself a win, most notably on microbenchmarks/instanceof-always-hit-two (1.5x faster), and on microbenchmarks/licm-dragons(-out-of-bounds) (both get 1.16x speedup).
I suspect it is because it runs between CSE and tail-dedup, and as a result allows a lot more tail-dedup to occur.
The pass is currently extremely conservative, not trying anything if it would cause _any_ code duplication.
For this purpose, it starts by computing use counts for the potentially interesting nodes (those with the right opcodes), and segregate them into expression trees.
The root of an expression tree is a node that is either used in multiple places, or is used by a value with a different opcode.
The leaves of an expression tree are nodes that are either used in multiple places, or have a different opcode.
All constant leaves of a tree are combined, as well as all leaves that are identical. What remains is then laid out into a balanced binary tree, hopefully maximizing ILP.
This optimization was implemented as a stand-alone pass and not as part of B3ReduceStrength mostly because it needs use counts to avoid code duplication.
It also benefits from finding all tree roots first, and not trying to repeatedly optimize subtrees.
I added several tests to testB3 with varying patterns of trees. It is also tested in a less focused way by lots of older tests.
In the future this pass could be expanded to allow some bounded amount of code duplication, and merging more leaves (e.g. Mul(a, 3) and a in an Add tree, into Mul(a, 4))
The latter will need exposing the peephole optimizations out of B3ReduceStrength to avoid duplicating code.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* b3/B3Common.cpp:
(JSC::B3::shouldDumpIR):
(JSC::B3::shouldDumpIRAtEachPhase):
* b3/B3Common.h:
* b3/B3EliminateDeadCode.cpp: Added.
(JSC::B3::EliminateDeadCode::run):
(JSC::B3::eliminateDeadCode):
* b3/B3EliminateDeadCode.h: Added.
(JSC::B3::EliminateDeadCode::EliminateDeadCode):
* b3/B3Generate.cpp:
(JSC::B3::generateToAir):
* b3/B3OptimizeAssociativeExpressionTrees.cpp: Added.
(JSC::B3::OptimizeAssociativeExpressionTrees::OptimizeAssociativeExpressionTrees):
(JSC::B3::OptimizeAssociativeExpressionTrees::neutralElement):
(JSC::B3::OptimizeAssociativeExpressionTrees::isAbsorbingElement):
(JSC::B3::OptimizeAssociativeExpressionTrees::combineConstants):
(JSC::B3::OptimizeAssociativeExpressionTrees::emitValue):
(JSC::B3::OptimizeAssociativeExpressionTrees::optimizeRootedTree):
(JSC::B3::OptimizeAssociativeExpressionTrees::run):
(JSC::B3::optimizeAssociativeExpressionTrees):
* b3/B3OptimizeAssociativeExpressionTrees.h: Added.
* b3/B3ReduceStrength.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::replaceWithIdentity):
* b3/testb3.cpp:
(JSC::B3::testBitXorTreeArgs):
(JSC::B3::testBitXorTreeArgsEven):
(JSC::B3::testBitXorTreeArgImm):
(JSC::B3::testAddTreeArg32):
(JSC::B3::testMulTreeArg32):
(JSC::B3::testBitAndTreeArg32):
(JSC::B3::testBitOrTreeArg32):
(JSC::B3::run):
2019-04-03 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add dump feature for RandomizingFuzzerAgent
https://bugs.webkit.org/show_bug.cgi?id=196586
Reviewed by Saam Barati.
Towards deterministic tests for the results from randomizing fuzzer agent, this patch adds Options::dumpRandomizingFuzzerAgentPredictions, which dumps the generated types.
The results is like this.
getPrediction name:(#C2q9xD),bytecodeIndex:(22),original:(Array),generated:(OtherObj|Array|Float64Array|BigInt|NonIntAsDouble)
getPrediction name:(makeUnwriteableUnconfigurableObject#AiEJv1),bytecodeIndex:(14),original:(OtherObj),generated:(Final|Uint8Array|Float64Array|SetObject|WeakSetObject|BigInt|NonIntAsDouble)
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/Options.h:
* runtime/RandomizingFuzzerAgent.cpp:
(JSC::RandomizingFuzzerAgent::getPrediction):
2019-04-03 Myles C. Maxfield <mmaxfield@apple.com>
-apple-trailing-word is needed for browser detection
https://bugs.webkit.org/show_bug.cgi?id=196575
Unreviewed.
* Configurations/FeatureDefines.xcconfig:
2019-04-03 Michael Saboff <msaboff@apple.com>
REGRESSION (r243642): com.apple.JavaScriptCore crash in JSC::RegExpObject::execInline
https://bugs.webkit.org/show_bug.cgi?id=196477
Reviewed by Keith Miller.
The problem here is that when we advance the index by 2 for a character class that only
has non-BMP characters, we might go past the end of the string. This can happen for
greedy counted character classes that are part of a alternative where there is one
character to match after the greedy non-BMP character class.
The "do we have string left to match" check at the top of the JIT loop for the counted
character class checks to see if index is not equal to the string length. For non-BMP
character classes, we need to check to see if there are at least 2 characters left.
Therefore we now temporarily add 1 to the current index before comparing. This checks
to see if there are iat least 2 characters left to match, instead of 1.
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::generateCharacterClassGreedy):
(JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):
2019-04-03 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Exception verification crash on operationArrayIndexOfValueInt32OrContiguous
https://bugs.webkit.org/show_bug.cgi?id=196574
Reviewed by Saam Barati.
This patch adds missing exception check in operationArrayIndexOfValueInt32OrContiguous.
* dfg/DFGOperations.cpp:
2019-04-03 Don Olmstead <don.olmstead@sony.com>
[CMake][WTF] Mirror XCode header directories
https://bugs.webkit.org/show_bug.cgi?id=191662
Reviewed by Konstantin Tokarev.
Use WTFFramework as a dependency and include frameworks/WTF.cmake for AppleWin internal
builds.
* CMakeLists.txt:
* shell/CMakeLists.txt:
2019-04-03 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add FuzzerAgent, which has a hooks to get feedback & inject fuzz data into JSC
https://bugs.webkit.org/show_bug.cgi?id=196530
Reviewed by Saam Barati.
This patch adds FuzzerAgent interface and simple RandomizingFuzzerAgent to JSC.
This RandomizingFuzzerAgent returns random SpeculatedType for value profiling to find
the issues in JSC. The seed for randomization can be specified by seedOfRandomizingFuzzerAgent.
I ran this with seedOfRandomizingFuzzerAgent=1 last night and it finds 3 failures in the current JSC tests,
they should be fixed in subsequent patches.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
* runtime/FuzzerAgent.cpp: Added.
(JSC::FuzzerAgent::~FuzzerAgent):
(JSC::FuzzerAgent::getPrediction):
* runtime/FuzzerAgent.h: Added.
* runtime/JSGlobalObjectFunctions.cpp:
* runtime/Options.h:
* runtime/RandomizingFuzzerAgent.cpp: Added.
(JSC::RandomizingFuzzerAgent::RandomizingFuzzerAgent):
(JSC::RandomizingFuzzerAgent::getPrediction):
* runtime/RandomizingFuzzerAgent.h: Added.
* runtime/RegExpCachedResult.h:
* runtime/RegExpGlobalData.cpp:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
(JSC::VM::fuzzerAgent const):
(JSC::VM::setFuzzerAgent):
2019-04-03 Myles C. Maxfield <mmaxfield@apple.com>
Remove support for -apple-trailing-word
https://bugs.webkit.org/show_bug.cgi?id=196525
Reviewed by Zalan Bujtas.
This CSS property is nonstandard and not used.
* Configurations/FeatureDefines.xcconfig:
2019-04-03 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Remote Inspector indicate callback should always happen on the main thread
https://bugs.webkit.org/show_bug.cgi?id=196513
<rdar://problem/49498284>
Reviewed by Devin Rousso.
* inspector/remote/cocoa/RemoteInspectorCocoa.mm:
(Inspector::RemoteInspector::receivedIndicateMessage):
When we have a WebThread, don't just run on the WebThread,
run on the MainThread with the WebThreadLock.
2019-04-02 Michael Saboff <msaboff@apple.com>
Crash in Options::setOptions() using --configFile option and libgmalloc
https://bugs.webkit.org/show_bug.cgi?id=196506
Reviewed by Keith Miller.
Changed to call CString::data() while making the call to Options::setOptions(). This keeps
the implicit CString temporary alive until after setOptions() returns.
* runtime/ConfigFile.cpp:
(JSC::ConfigFile::parse):
2019-04-02 Fujii Hironori <Hironori.Fujii@sony.com>
[CMake] WEBKIT_MAKE_FORWARDING_HEADERS shouldn't use POST_BUILD to copy generated headers
https://bugs.webkit.org/show_bug.cgi?id=182757
Reviewed by Don Olmstead.
* CMakeLists.txt: Do not use DERIVED_SOURCE_DIRECTORIES parameter
of WEBKIT_MAKE_FORWARDING_HEADERS. Added generated headers to
JavaScriptCore_PRIVATE_FRAMEWORK_HEADERS.
2019-04-02 Saam barati <sbarati@apple.com>
Add a ValueRepReduction phase
https://bugs.webkit.org/show_bug.cgi?id=196234
Reviewed by Filip Pizlo.
This patch adds a ValueRepReduction phase. The main idea here is
to try to reduce DoubleRep(RealNumberUse:ValueRep(DoubleRepUse:@x))
to just be @x. This patch handles such above strengh reduction rules
as long as we prove that all users of the ValueRep can be converted
to using the incoming double value. That way we prevent introducing
a parallel live range for the double value.
This patch tracks the uses of the ValueRep through Phi variables,
so we can convert entire Phi variables to being Double instead
of JSValue if the Phi also has only double uses.
This is implemented through a simple escape analysis. DoubleRep(RealNumberUse:)
and OSR exit hints are not counted as escapes. All other uses are counted
as escapes. Connected Phi graphs are converted to being Double only if the
entire graph is ok with the result being Double.
Some ways we could extend this phase in the future:
- There are a lot of DoubleRep(NumberUse:@ValueRep(@x)) uses. This ensures
that the result of the DoubleRep of @x is not impure NaN. We could
handle this case if we introduced a PurifyNaN node and replace the DoubleRep
with PurifyNaN(@x). Alternatively, we could see if certain users of this
DoubleRep are okay with impure NaN flowing into them and we'd need to ensure
their output type is always treated as if the input is impure NaN.
- We could do sinking of ValueRep where we think it's profitable. So instead
of an escape making it so we never represent the variable as a Double, we
could make the escape reconstruct the JSValueRep where profitable.
- We can extend this phase to handle Int52Rep if it's profitable.
- We can opt other nodes into accepting incoming Doubles so we no longer
treat them as escapes.
This patch is somewhere between neutral and a 1% progression on JetStream 2.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGValueRepReductionPhase.cpp: Added.
(JSC::DFG::ValueRepReductionPhase::ValueRepReductionPhase):
(JSC::DFG::ValueRepReductionPhase::run):
(JSC::DFG::ValueRepReductionPhase::convertValueRepsToDouble):
(JSC::DFG::performValueRepReduction):
* dfg/DFGValueRepReductionPhase.h: Added.
* runtime/Options.h:
2019-04-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] JSRunLoopTimer::Manager should be small
https://bugs.webkit.org/show_bug.cgi?id=196425
Reviewed by Darin Adler.
Using very large Key or Value in HashMap potentially bloats memory since HashMap pre-allocates large size of
memory ((sizeof(Key) + sizeof(Value)) * N) for its backing storage's array. Using std::unique_ptr<> for JSRunLoopTimer's
PerVMData to keep HashMap's backing store size small.
* runtime/JSRunLoopTimer.cpp:
(JSC::JSRunLoopTimer::Manager::timerDidFire):
(JSC::JSRunLoopTimer::Manager::registerVM):
(JSC::JSRunLoopTimer::Manager::scheduleTimer):
(JSC::JSRunLoopTimer::Manager::cancelTimer):
(JSC::JSRunLoopTimer::Manager::timeUntilFire):
(JSC::JSRunLoopTimer::Manager::didChangeRunLoop):
* runtime/JSRunLoopTimer.h:
2019-04-01 Stephan Szabo <stephan.szabo@sony.com>
[PlayStation] Add initialization for JSC shell for PlayStation port
https://bugs.webkit.org/show_bug.cgi?id=195411
Reviewed by Ross Kirsling.
Add ps options
* shell/PlatformPlayStation.cmake: Added.
* shell/playstation/Initializer.cpp: Added.
(initializer):
2019-04-01 Michael Catanzaro <mcatanzaro@igalia.com>
Stop trying to support building JSC with clang 3.8
https://bugs.webkit.org/show_bug.cgi?id=195947
<rdar://problem/49069219>
Reviewed by Darin Adler.
It seems WebKit hasn't built with clang 3.8 in a while, no devs are using this compiler, we
don't know how much effort it would be to make JSC work again, and it's making the code
worse. Remove my hacks to support clang 3.8 from JSC.
* bindings/ScriptValue.cpp:
(Inspector::jsToInspectorValue):
* bytecode/GetterSetterAccessCase.cpp:
(JSC::GetterSetterAccessCase::create):
(JSC::GetterSetterAccessCase::clone const):
* bytecode/InstanceOfAccessCase.cpp:
(JSC::InstanceOfAccessCase::clone const):
* bytecode/IntrinsicGetterAccessCase.cpp:
(JSC::IntrinsicGetterAccessCase::clone const):
* bytecode/ModuleNamespaceAccessCase.cpp:
(JSC::ModuleNamespaceAccessCase::clone const):
* bytecode/ProxyableAccessCase.cpp:
(JSC::ProxyableAccessCase::clone const):
2019-03-31 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Butterfly allocation from LargeAllocation should try "realloc" behavior if collector thread is not active
https://bugs.webkit.org/show_bug.cgi?id=196160
Reviewed by Saam Barati.
"realloc" can be effective in terms of peak/current memory footprint when realloc succeeds because,
1. It does not allocate additional memory while expanding a vector
2. It does not deallocate an old memory, just reusing the current memory by expanding, so that memory footprint is tight even before scavenging
We found that we can "realloc" large butterflies in certain conditions are met because,
1. If it goes to LargeAllocation, this memory region is never reused until GC sweeps it.
2. Butterflies are owned by owner JSObjects, so we know the lifetime of Butterflies.
This patch attempts to use "realloc" onto butterflies if,
1. Butterflies are allocated in LargeAllocation kind
2. Concurrent collector is not active
3. Butterflies do not have property storage
The condition (2) is required to avoid deallocating butterflies while the concurrent collector looks into it. The condition (3) is
also required to avoid deallocating butterflies while the concurrent compiler looks into it.
We also change LargeAllocation mechanism to using "malloc" and "free" instead of "posix_memalign". This allows us to use "realloc"
safely in all the platforms. Since LargeAllocation uses alignment to distinguish LargeAllocation and MarkedBlock, we manually adjust
16B alignment by allocating 8B more memory in "malloc".
Speedometer2 and JetStream2 are neutral. RAMification shows about 1% progression (even in some of JIT tests).
* heap/AlignedMemoryAllocator.h:
* heap/CompleteSubspace.cpp:
(JSC::CompleteSubspace::tryAllocateSlow):
(JSC::CompleteSubspace::reallocateLargeAllocationNonVirtual):
* heap/CompleteSubspace.h:
* heap/FastMallocAlignedMemoryAllocator.cpp:
(JSC::FastMallocAlignedMemoryAllocator::tryAllocateMemory):
(JSC::FastMallocAlignedMemoryAllocator::freeMemory):
(JSC::FastMallocAlignedMemoryAllocator::tryReallocateMemory):
* heap/FastMallocAlignedMemoryAllocator.h:
* heap/GigacageAlignedMemoryAllocator.cpp:
(JSC::GigacageAlignedMemoryAllocator::tryAllocateMemory):
(JSC::GigacageAlignedMemoryAllocator::freeMemory):
(JSC::GigacageAlignedMemoryAllocator::tryReallocateMemory):
* heap/GigacageAlignedMemoryAllocator.h:
* heap/IsoAlignedMemoryAllocator.cpp:
(JSC::IsoAlignedMemoryAllocator::tryAllocateMemory):
(JSC::IsoAlignedMemoryAllocator::freeMemory):
(JSC::IsoAlignedMemoryAllocator::tryReallocateMemory):
* heap/IsoAlignedMemoryAllocator.h:
* heap/LargeAllocation.cpp:
(JSC::isAlignedForLargeAllocation):
(JSC::LargeAllocation::tryCreate):
(JSC::LargeAllocation::tryReallocate):
(JSC::LargeAllocation::LargeAllocation):
(JSC::LargeAllocation::destroy):
* heap/LargeAllocation.h:
(JSC::LargeAllocation::indexInSpace):
(JSC::LargeAllocation::setIndexInSpace):
(JSC::LargeAllocation::basePointer const):
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::sweepLargeAllocations):
(JSC::MarkedSpace::prepareForConservativeScan):
* heap/WeakSet.h:
(JSC::WeakSet::isTriviallyDestructible const):
* runtime/Butterfly.h:
* runtime/ButterflyInlines.h:
(JSC::Butterfly::reallocArrayRightIfPossible):
* runtime/JSObject.cpp:
(JSC::JSObject::ensureLengthSlow):
2019-03-31 Sam Weinig <weinig@apple.com>
Remove more i386 specific configurations
https://bugs.webkit.org/show_bug.cgi?id=196430
Reviewed by Alexey Proskuryakov.
* Configurations/FeatureDefines.xcconfig:
ENABLE_WEB_AUTHN_macosx can now be enabled unconditionally on macOS.
* Configurations/ToolExecutable.xcconfig:
ARC can be enabled unconditionally now.
2019-03-29 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] JSWrapperMap should not use Objective-C Weak map (NSMapTable with NSPointerFunctionsWeakMemory) for m_cachedObjCWrappers
https://bugs.webkit.org/show_bug.cgi?id=196392
Reviewed by Saam Barati.
Weak representation in Objective-C is surprisingly costly in terms of memory. We can see that very easy program shows 10KB memory consumption due to
this weak wrapper map in JavaScriptCore.framework. But we do not need this weak map since Objective-C JSValue has a dealloc. We can unregister itself
from the map when it is deallocated without using Objective-C weak mechanism. And since Objective-C JSValue is tightly coupled to a specific JSContext,
and wrapper map is created per JSContext, JSValue wrapper and actual JavaScriptCore value is one-on-one, and [JSValue dealloc] knows which JSContext's
wrapper map holds itself.
1. We do not use Objective-C weak mechanism. We use WTF::HashSet instead. When JSValue is allocated, we register it to JSWrapperMap's HashSet. And unregister
JSValue from this map when JSValue is deallocated.
2. We use HashSet<JSValue> (logically) instead of HashMap<JSValueRef, JSValue> to keep JSValueRef and JSValue relationship. We can achieve it because JSValue
holds JSValueRef inside it.
* API/JSContext.mm:
(-[JSContext removeWrapper:]):
* API/JSContextInternal.h:
* API/JSValue.mm:
(-[JSValue dealloc]):
(-[JSValue initWithValue:inContext:]):
* API/JSWrapperMap.h:
* API/JSWrapperMap.mm:
(WrapperKey::hashTableDeletedValue):
(WrapperKey::WrapperKey):
(WrapperKey::isHashTableDeletedValue const):
(WrapperKey::Hash::hash):
(WrapperKey::Hash::equal):
(WrapperKey::Traits::isEmptyValue):
(WrapperKey::Translator::hash):
(WrapperKey::Translator::equal):
(WrapperKey::Translator::translate):
(-[JSWrapperMap initWithGlobalContextRef:]):
(-[JSWrapperMap dealloc]):
(-[JSWrapperMap objcWrapperForJSValueRef:inContext:]):
(-[JSWrapperMap removeWrapper:]):
* API/tests/testapi.mm:
(testObjectiveCAPIMain):
2019-03-29 Robin Morisset <rmorisset@apple.com>
B3ReduceStrength should know that Mul distributes over Add and Sub
https://bugs.webkit.org/show_bug.cgi?id=196325
Reviewed by Michael Saboff.
In this patch I add the following patterns to B3ReduceStrength:
- Turn this: Integer Neg(Mul(value, c))
Into this: Mul(value, -c), as long as -c does not overflow
- Turn these: Integer Mul(value, Neg(otherValue)) and Integer Mul(Neg(value), otherValue)
Into this: Neg(Mul(value, otherValue))
- For Op==Add or Sub, turn any of these:
Op(Mul(x1, x2), Mul(x1, x3))
Op(Mul(x2, x1), Mul(x1, x3))
Op(Mul(x1, x2), Mul(x3, x1))
Op(Mul(x2, x1), Mul(x3, x1))
Into this: Mul(x1, Op(x2, x3))
Also includes a trivial change: a similar reduction for the distributivity of BitAnd over BitOr/BitXor now
emits the arguments to BitAnd in the other order, to minimize the probability that we'll spend a full fixpoint step just to flip them.
* b3/B3ReduceStrength.cpp:
* b3/testb3.cpp:
(JSC::B3::testAddMulMulArgs):
(JSC::B3::testMulArgNegArg):
(JSC::B3::testMulNegArgArg):
(JSC::B3::testNegMulArgImm):
(JSC::B3::testSubMulMulArgs):
(JSC::B3::run):
2019-03-29 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Remove distancing for LargeAllocation
https://bugs.webkit.org/show_bug.cgi?id=196335
Reviewed by Saam Barati.
In r230226, we removed distancing feature from our GC. This patch removes remaining distancing thing in LargeAllocation.
* heap/HeapCell.h:
* heap/LargeAllocation.cpp:
(JSC::LargeAllocation::tryCreate):
* heap/MarkedBlock.h:
2019-03-29 Myles C. Maxfield <mmaxfield@apple.com>
Delete WebMetal implementation in favor of WebGPU
https://bugs.webkit.org/show_bug.cgi?id=195418
Reviewed by Dean Jackson.
* Configurations/FeatureDefines.xcconfig:
* inspector/protocol/Canvas.json:
* inspector/scripts/codegen/generator.py:
2019-03-29 Tadeu Zagallo <tzagallo@apple.com>
Assertion failed in JSC::createError
https://bugs.webkit.org/show_bug.cgi?id=196305
<rdar://problem/49387382>
Reviewed by Saam Barati.
JSC::createError assumes that `errorDescriptionForValue` will either
throw an exception or return a valid description string. However, that
is not true if the value is a rope string and we successfully resolve it,
but later fail to wrap the string in quotes with `tryMakeString`.
* runtime/ExceptionHelpers.cpp:
(JSC::createError):
2019-03-29 Devin Rousso <drousso@apple.com>
Web Inspector: add fast returns for instrumentation hooks that have no affect before a frontend is connected
https://bugs.webkit.org/show_bug.cgi?id=196382
<rdar://problem/49403417>
Reviewed by Joseph Pecoraro.
Ensure that all instrumentation hooks use `FAST_RETURN_IF_NO_FRONTENDS` or check that
`developerExtrasEnabled`. There should be no activity to/from any inspector objects until
developer extras are enabled.
* inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::startTiming):
(Inspector::InspectorConsoleAgent::stopTiming):
(Inspector::InspectorConsoleAgent::count):
(Inspector::InspectorConsoleAgent::addConsoleMessage):
2019-03-29 Cathie Chen <cathiechen@igalia.com>
Implement ResizeObserver.
https://bugs.webkit.org/show_bug.cgi?id=157743
Reviewed by Simon Fraser.
Add ENABLE_RESIZE_OBSERVER.
* Configurations/FeatureDefines.xcconfig:
2019-03-28 Michael Saboff <msaboff@apple.com>
[YARR] Precompute BMP / non-BMP status when constructing character classes
https://bugs.webkit.org/show_bug.cgi?id=196296
Reviewed by Keith Miller.
Changed CharacterClass::m_hasNonBMPCharacters into a character width bit field which
indicateis if the class includes characters from either BMP, non-BMP or both ranges.
This allows the recognizing code to eliminate checks for the width of a matched
characters when the class has only one width. The character width is needed to
determine if we advance 1 or 2 character. Also, the pre-computed width of character
classes that contains either all BMP or all non-BMP characters allows the parser to
use fixed widths for terms using those character classes. Changed both the code gen
scripts and Yarr compiler to compute this bit field during the construction of
character classes.
For JIT'ed code of character classes that contain either all BMP or all non-BMP
characters, we can eliminate the generic check we were doing do compute how much
to advance after sucessfully matching a character in the class.
Generic isBMP check BMP only non-BMP only
-------------- -------------- --------------
inc %r9d inc %r9d add $0x2, %r9d
cmp $0x10000, %eax
jl isBMP
cmp %edx, %esi
jz atEndOfString
inc %r9d
inc %esi
isBMP:
For character classes that contained non-BMP characters, we were always generating
the code in the left column. The middle column is the code we generate for character
classes that contain only BMP characters. The right column is the code we now
generate if the character class has only non-BMP characters. In the fix width cases,
we can eliminate both the isBMP check as well as the atEndOfString check. The
atEndOfstring check is eliminated since we know how many characters this character
class requires and that check can be factored out to the beginning of the current
alternative. For character classes that contain both BMP and non-BMP characters,
we still generate the generic left column.
This change is a ~8% perf progression on UniPoker and a ~2% improvement on RexBench
as a whole.
* runtime/RegExp.cpp:
(JSC::RegExp::matchCompareWithInterpreter):
* runtime/RegExpInlines.h:
(JSC::RegExp::matchInline):
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::Interpreter::checkCharacterClassDontAdvanceInputForNonBMP):
(JSC::Yarr::Interpreter::matchCharacterClass):
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::optimizeAlternative):
(JSC::Yarr::YarrGenerator::matchCharacterClass):
(JSC::Yarr::YarrGenerator::advanceIndexAfterCharacterClassTermMatch):
(JSC::Yarr::YarrGenerator::tryReadUnicodeCharImpl):
(JSC::Yarr::YarrGenerator::generateCharacterClassOnce):
(JSC::Yarr::YarrGenerator::generateCharacterClassFixed):
(JSC::Yarr::YarrGenerator::generateCharacterClassGreedy):
(JSC::Yarr::YarrGenerator::backtrackCharacterClassGreedy):
(JSC::Yarr::YarrGenerator::generateCharacterClassNonGreedy):
(JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):
(JSC::Yarr::YarrGenerator::generateEnter):
(JSC::Yarr::YarrGenerator::YarrGenerator):
(JSC::Yarr::YarrGenerator::compile):
* yarr/YarrPattern.cpp:
(JSC::Yarr::CharacterClassConstructor::CharacterClassConstructor):
(JSC::Yarr::CharacterClassConstructor::reset):
(JSC::Yarr::CharacterClassConstructor::charClass):
(JSC::Yarr::CharacterClassConstructor::addSorted):
(JSC::Yarr::CharacterClassConstructor::addSortedRange):
(JSC::Yarr::CharacterClassConstructor::hasNonBMPCharacters):
(JSC::Yarr::CharacterClassConstructor::characterWidths):
(JSC::Yarr::PatternTerm::dump):
(JSC::Yarr::anycharCreate):
* yarr/YarrPattern.h:
(JSC::Yarr::operator|):
(JSC::Yarr::operator&):
(JSC::Yarr::operator|=):
(JSC::Yarr::CharacterClass::CharacterClass):
(JSC::Yarr::CharacterClass::hasNonBMPCharacters):
(JSC::Yarr::CharacterClass::hasOneCharacterSize):
(JSC::Yarr::CharacterClass::hasOnlyNonBMPCharacters):
(JSC::Yarr::PatternTerm::invert const):
(JSC::Yarr::PatternTerm::invert): Deleted.
* yarr/create_regex_tables:
* yarr/generateYarrUnicodePropertyTables.py:
2019-03-28 Saam Barati <sbarati@apple.com>
BackwardsGraph needs to consider back edges as the backward's root successor
https://bugs.webkit.org/show_bug.cgi?id=195991
Reviewed by Filip Pizlo.
* b3/testb3.cpp:
(JSC::B3::testInfiniteLoopDoesntCauseBadHoisting):
(JSC::B3::run):
2019-03-28 Fujii Hironori <Hironori.Fujii@sony.com>
Opcode.h(159,27): warning: adding 'unsigned int' to a string does not append to the string [-Wstring-plus-int]
https://bugs.webkit.org/show_bug.cgi?id=196343
Reviewed by Saam Barati.
Clang reports a compilation warning and recommend '&PADDING_STRING[PADDING_STRING_LENGTH]'
instead of 'PADDING_STRING + PADDING_STRING_LENGTH'.
* bytecode/Opcode.cpp:
(JSC::padOpcodeName): Moved padOpcodeName from Opcode.h because
this function is used only in Opcode.cpp. Changed macros
PADDING_STRING and PADDING_STRING_LENGTH to simple variables.
(JSC::compareOpcodePairIndices): Replaced pair with std::pair.
* bytecode/Opcode.h:
(JSC::padOpcodeName): Moved.
2019-03-28 Tadeu Zagallo <tzagallo@apple.com>
CodeBlock::jettison() should disallow repatching its own calls
https://bugs.webkit.org/show_bug.cgi?id=196359
<rdar://problem/48973663>
Reviewed by Saam Barati.
CodeBlock::jettison() calls CommonData::invalidate, which replaces the `hlt`
instruction with the jump to OSR exit. However, if the `hlt` was immediately
followed by a call to the CodeBlock being jettisoned, we would write over the
OSR exit address while unlinking all the incoming CallLinkInfos later in
CodeBlock::jettison().
Change it so that we set a flag, `clearedByJettison`, in all the CallLinkInfos
owned by the CodeBlock being jettisoned. If the flag is set, we will avoid
repatching the call during unlinking. This is safe because this call will never
be reachable again after the CodeBlock is jettisoned.
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::CallLinkInfo):
(JSC::CallLinkInfo::setCallee):
(JSC::CallLinkInfo::clearCallee):
(JSC::CallLinkInfo::setCodeBlock):
(JSC::CallLinkInfo::clearCodeBlock):
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::clearedByJettison):
(JSC::CallLinkInfo::setClearedByJettison):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::jettison):
* jit/Repatch.cpp:
(JSC::revertCall):
2019-03-27 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Drop VM and Context cache map in JavaScriptCore.framework
https://bugs.webkit.org/show_bug.cgi?id=196341
Reviewed by Saam Barati.
Previously, we created Objective-C weak map to maintain JSVirtualMachine and JSContext wrappers corresponding to VM and JSGlobalObject.
But Objective-C weak map is really memory costly. Even if the entry is only one, it consumes 2.5KB per weak map. Since we can modify
JSC intrusively for JavaScriptCore.framework (and we already did it, like, holding JSWrapperMap in JSGlobalObject), we can just hold
a pointer to a wrapper in VM and JSGlobalObject.
This patch adds void* members to VM and JSGlobalObject, which holds a non-strong reference to a wrapper. When a wrapper is gone, we
clear this pointer too. This removes unnecessary two Objective-C weak maps, and save 5KB.
* API/JSContext.mm:
(-[JSContext initWithVirtualMachine:]):
(-[JSContext dealloc]):
(-[JSContext initWithGlobalContextRef:]):
(-[JSContext wrapperMap]):
(+[JSContext contextWithJSGlobalContextRef:]):
* API/JSVirtualMachine.mm:
(-[JSVirtualMachine initWithContextGroupRef:]):
(-[JSVirtualMachine dealloc]):
(+[JSVirtualMachine virtualMachineWithContextGroupRef:]):
(scanExternalObjectGraph):
(scanExternalRememberedSet):
(initWrapperCache): Deleted.
(wrapperCache): Deleted.
(+[JSVMWrapperCache addWrapper:forJSContextGroupRef:]): Deleted.
(+[JSVMWrapperCache wrapperForJSContextGroupRef:]): Deleted.
(-[JSVirtualMachine contextForGlobalContextRef:]): Deleted.
(-[JSVirtualMachine addContext:forGlobalContextRef:]): Deleted.
* API/JSVirtualMachineInternal.h:
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::setAPIWrapper):
(JSC::JSGlobalObject::apiWrapper const):
* runtime/VM.h:
2019-03-28 Tadeu Zagallo <tzagallo@apple.com>
In-memory code cache should not share bytecode across domains
https://bugs.webkit.org/show_bug.cgi?id=196321
Reviewed by Geoffrey Garen.
Use the SourceProvider's URL to make sure that the hosts match for the
two SourceCodeKeys in operator==.
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::host const):
(JSC::SourceCodeKey::operator== const):
2019-03-28 Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
Silence lot of warnings when compiling with clang
https://bugs.webkit.org/show_bug.cgi?id=196310
Reviewed by Michael Catanzaro.
Initialize variable with default constructor.
* API/glib/JSCOptions.cpp:
(jsc_options_foreach):
2019-03-27 Saam Barati <sbarati@apple.com>
validateOSREntryValue with Int52 should box the value being checked into double format
https://bugs.webkit.org/show_bug.cgi?id=196313
<rdar://problem/49306703>
Reviewed by Yusuke Suzuki.
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareOSREntry):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::validateAIState):
2019-03-27 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Owner of watchpoints should validate at GC finalizing phase
https://bugs.webkit.org/show_bug.cgi?id=195827
Reviewed by Filip Pizlo.
This patch fixes JSC's watchpoint liveness issue by the following two policies.
1. Watchpoint should have owner cell, and "fire" operation should be gaurded with owner cell's isLive check.
Watchpoints should hold its owner cell, and fire procedure should be guarded by `owner->isLive()`.
When the owner cell is destroyed, these watchpoints are destroyed too. But this destruction can
be delayed due to incremental sweeper. So the following condition can happen.
When we have a watchpoint like the following.
class XXXWatchpoint {
ObjectPropertyCondition m_key;
JSCell* m_owner;
};
Both m_key's cell and m_owner is now unreachable from the root. So eventually, m_owner cell's destructor
is called and this watchpoint will be destroyed. But before that, m_key's cell can be destroyed. And this
watchpoint's fire procedure can be called since m_owner's destructor is not called yet. In this situation,
we encounter the destroyed cell held in m_key. This problem can be avoided if we guard fire procedure with
`m_owner->isLive()`. Until the owner cell is destroyed, this guard avoids "fire" procedure execution. And
once the destructor of m_owner is called, this watchpoint will be destroyed too.
2. Watchpoint liveness should be maintained by owner cell's unconditional finalizer
Watchpoints often hold weak references to the other cell (like, m_key in the above example). If we do not
delete watchpoints with dead cells when these weak cells become dead, these watchpoints continue holding dead cells,
and watchpoint's fire operation can use these dead cells accidentally. isLive / isStillLive check for these weak cells
in fire operation is not useful. Because these dead cells can be reused to the other live cells eventually, and this
isLive / isStillLive checks fail to see these cells are live if they are reused. Appropriate way is deleting watchpoints
with dead cells when finalizing GC. In this patch, we do this in unconditional finalizers in owner cells of watchpoints.
We already did this in CodeBlock etc. We add the same thing to StructureRareData which owns watchpoints for toString operations.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
(JSC::AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint::StructureWatchpoint): Deleted.
(JSC::AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint::PropertyWatchpoint): Deleted.
* bytecode/CodeBlockJettisoningWatchpoint.h:
(JSC::CodeBlockJettisoningWatchpoint::CodeBlockJettisoningWatchpoint): Deleted.
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::key const): Deleted.
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::fireInternal):
(JSC::WatchpointsOnStructureStubInfo::isValid const):
* bytecode/StructureStubClearingWatchpoint.h:
(JSC::StructureStubClearingWatchpoint::StructureStubClearingWatchpoint): Deleted.
* dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::isValid const):
* dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h:
* dfg/DFGAdaptiveStructureWatchpoint.cpp:
(JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
* dfg/DFGAdaptiveStructureWatchpoint.h:
(JSC::DFG::AdaptiveStructureWatchpoint::key const): Deleted.
* dfg/DFGDesiredWatchpoints.cpp:
(JSC::DFG::ArrayBufferViewWatchpointAdaptor::add):
* heap/Heap.cpp:
(JSC::Heap::finalizeUnconditionalFinalizers):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setupGetByIdPrototypeCache):
* runtime/ArrayBuffer.cpp:
(JSC::ArrayBuffer::notifyIncommingReferencesOfTransfer):
* runtime/ArrayBufferNeuteringWatchpointSet.cpp: Renamed from Source/JavaScriptCore/runtime/ArrayBufferNeuteringWatchpoint.cpp.
(JSC::ArrayBufferNeuteringWatchpointSet::ArrayBufferNeuteringWatchpointSet):
(JSC::ArrayBufferNeuteringWatchpointSet::destroy):
(JSC::ArrayBufferNeuteringWatchpointSet::create):
(JSC::ArrayBufferNeuteringWatchpointSet::createStructure):
(JSC::ArrayBufferNeuteringWatchpointSet::fireAll):
* runtime/ArrayBufferNeuteringWatchpointSet.h: Renamed from Source/JavaScriptCore/runtime/ArrayBufferNeuteringWatchpoint.h.
* runtime/FunctionRareData.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::tryInstallArraySpeciesWatchpoint):
* runtime/ObjectPropertyChangeAdaptiveWatchpoint.h:
(JSC::ObjectPropertyChangeAdaptiveWatchpoint::ObjectPropertyChangeAdaptiveWatchpoint): Deleted.
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::finalizeUnconditionally):
* runtime/StructureRareData.h:
* runtime/VM.cpp:
(JSC::VM::VM):
2019-03-26 Saam Barati <sbarati@apple.com>
FTL: Emit code to validate AI's state when running the compiled code
https://bugs.webkit.org/show_bug.cgi?id=195924
<rdar://problem/49003422>
Reviewed by Filip Pizlo.
This patch adds code that between the execution of each node that validates
the types that AI proves. This option is too expensive to turn on for our
regression testing, but we think it will be valuable in other types of running
modes, such as when running with a fuzzer.
This patch also adds options to only probabilistically run this validation
after the execution of each node. As the probability is lowered, there is
less of a perf hit.
This patch just adds this validation in the FTL. A follow-up patch will land
it in the DFG too: https://bugs.webkit.org/show_bug.cgi?id=196219
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::LowerDFGToB3):
(JSC::FTL::DFG::LowerDFGToB3::compileBlock):
(JSC::FTL::DFG::LowerDFGToB3::validateAIState):
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::lowJSValue):
* runtime/Options.h:
2019-03-26 Tadeu Zagallo <tzagallo@apple.com>
WebAssembly: Fix f32.min, f64.min and f64.max operations on NaN
https://bugs.webkit.org/show_bug.cgi?id=196217
Reviewed by Saam Barati.
Generalize the fix for f32.max to properly handle NaN by doing an extra GreatherThan
comparison in r243446 to all min and max float operations.
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Min>):
(JSC::Wasm::AirIRGenerator::addFloatingPointMinOrMax):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Max>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Min>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Max>):
* wasm/wasm.json:
2019-03-26 Andy VanWagoner <andy@vanwagoner.family>
Intl.DateTimeFormat should obey 2-digit hour
https://bugs.webkit.org/show_bug.cgi?id=195974
Reviewed by Keith Miller.
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
2019-03-25 Yusuke Suzuki <ysuzuki@apple.com>
Heap::isMarked and friends should be instance methods
https://bugs.webkit.org/show_bug.cgi?id=179988
Reviewed by Saam Barati.
Almost all the callers of Heap::isMarked have VM& reference. We should make Heap::isMarked instance function instead of static function
so that we do not need to look up Heap from the cell.
* API/JSAPIWrapperObject.mm:
(JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots):
* API/JSMarkingConstraintPrivate.cpp:
(JSC::isMarked):
* API/glib/JSAPIWrapperObjectGLib.cpp:
(JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots):
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::finalizeUnconditionally):
* bytecode/AccessCase.cpp:
(JSC::AccessCase::visitWeak const):
(JSC::AccessCase::propagateTransitions const):
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::visitWeak):
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::finalize):
* bytecode/CallLinkStatus.h:
* bytecode/CallVariant.cpp:
(JSC::CallVariant::finalize):
* bytecode/CallVariant.h:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::shouldJettisonDueToWeakReference):
(JSC::CodeBlock::shouldJettisonDueToOldAge):
(JSC::shouldMarkTransition):
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::determineLiveness):
(JSC::CodeBlock::finalizeLLIntInlineCaches):
(JSC::CodeBlock::finalizeUnconditionally):
(JSC::CodeBlock::jettison):
* bytecode/CodeBlock.h:
* bytecode/ExecutableToCodeBlockEdge.cpp:
(JSC::ExecutableToCodeBlockEdge::visitChildren):
(JSC::ExecutableToCodeBlockEdge::finalizeUnconditionally):
(JSC::ExecutableToCodeBlockEdge::runConstraint):
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::finalize):
* bytecode/GetByIdStatus.h:
* bytecode/GetByIdVariant.cpp:
(JSC::GetByIdVariant::finalize):
* bytecode/GetByIdVariant.h:
* bytecode/InByIdStatus.cpp:
(JSC::InByIdStatus::finalize):
* bytecode/InByIdStatus.h:
* bytecode/InByIdVariant.cpp:
(JSC::InByIdVariant::finalize):
* bytecode/InByIdVariant.h:
* bytecode/ObjectPropertyCondition.cpp:
(JSC::ObjectPropertyCondition::isStillLive const):
* bytecode/ObjectPropertyCondition.h:
* bytecode/ObjectPropertyConditionSet.cpp:
(JSC::ObjectPropertyConditionSet::areStillLive const):
* bytecode/ObjectPropertyConditionSet.h:
* bytecode/PolymorphicAccess.cpp:
(JSC::PolymorphicAccess::visitWeak const):
* bytecode/PropertyCondition.cpp:
(JSC::PropertyCondition::isStillLive const):
* bytecode/PropertyCondition.h:
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::finalize):
* bytecode/PutByIdStatus.h:
* bytecode/PutByIdVariant.cpp:
(JSC::PutByIdVariant::finalize):
* bytecode/PutByIdVariant.h:
* bytecode/RecordedStatuses.cpp:
(JSC::RecordedStatuses::finalizeWithoutDeleting):
(JSC::RecordedStatuses::finalize):
* bytecode/RecordedStatuses.h:
* bytecode/StructureSet.cpp:
(JSC::StructureSet::isStillAlive const):
* bytecode/StructureSet.h:
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::visitWeakReferences):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::finalizeInGC):
(JSC::DFG::Plan::isKnownToBeLiveDuringGC):
* heap/GCIncomingRefCounted.h:
* heap/GCIncomingRefCountedInlines.h:
(JSC::GCIncomingRefCounted<T>::filterIncomingReferences):
* heap/GCIncomingRefCountedSet.h:
* heap/GCIncomingRefCountedSetInlines.h:
(JSC::GCIncomingRefCountedSet<T>::lastChanceToFinalize):
(JSC::GCIncomingRefCountedSet<T>::sweep):
(JSC::GCIncomingRefCountedSet<T>::removeAll): Deleted.
(JSC::GCIncomingRefCountedSet<T>::removeDead): Deleted.
* heap/Heap.cpp:
(JSC::Heap::addToRememberedSet):
(JSC::Heap::runEndPhase):
(JSC::Heap::sweepArrayBuffers):
(JSC::Heap::addCoreConstraints):
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::isMarked):
* heap/HeapSnapshotBuilder.cpp:
(JSC::HeapSnapshotBuilder::appendNode):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::appendToMarkStack):
(JSC::SlotVisitor::visitChildren):
* jit/PolymorphicCallStubRoutine.cpp:
(JSC::PolymorphicCallStubRoutine::visitWeak):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::finalizeUnconditionally):
* runtime/InferredValueInlines.h:
(JSC::InferredValue::finalizeUnconditionally):
* runtime/StackFrame.h:
(JSC::StackFrame::isMarked const):
* runtime/Structure.cpp:
(JSC::Structure::isCheapDuringGC):
(JSC::Structure::markIfCheap):
* runtime/Structure.h:
* runtime/TypeProfiler.cpp:
(JSC::TypeProfiler::invalidateTypeSetCache):
* runtime/TypeProfiler.h:
* runtime/TypeSet.cpp:
(JSC::TypeSet::invalidateCache):
* runtime/TypeSet.h:
* runtime/WeakMapImpl.cpp:
(JSC::WeakMapImpl<WeakMapBucket<WeakMapBucketDataKeyValue>>::visitOutputConstraints):
* runtime/WeakMapImplInlines.h:
(JSC::WeakMapImpl<WeakMapBucket>::finalizeUnconditionally):
2019-03-25 Keith Miller <keith_miller@apple.com>
ASSERTION FAILED: m_op == CompareStrictEq in JSC::DFG::Node::convertToCompareEqPtr(JSC::DFG::FrozenValue *, JSC::DFG::Edge)
https://bugs.webkit.org/show_bug.cgi?id=196176
Reviewed by Saam Barati.
convertToCompareEqPtr should allow for either CompareStrictEq or
the SameValue DFG node. This fixes the old assertion that only
allowed CompareStrictEq.
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToCompareEqPtr):
2019-03-25 Tadeu Zagallo <tzagallo@apple.com>
WebAssembly: f32.max with NaN generates incorrect result
https://bugs.webkit.org/show_bug.cgi?id=175691
<rdar://problem/33952228>
Reviewed by Saam Barati.
Fix the B3 and Air compilation for f32.max. In order to handle the NaN
case, we need an extra GreaterThan comparison on top of the existing
Equal and LessThan ones.
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Max>):
* wasm/wasm.json:
2019-03-25 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, speculative fix for CLoop build on CPU(UNKNOWN)
https://bugs.webkit.org/show_bug.cgi?id=195982
* jit/ExecutableAllocator.h:
(JSC::ExecutableAllocator::initializeUnderlyingAllocator):
2019-03-25 Gyuyoung Kim <gyuyoung.kim@webkit.org>
Remove NavigatorContentUtils in WebCore/Modules
https://bugs.webkit.org/show_bug.cgi?id=196070
Reviewed by Alex Christensen.
NavigatorContentUtils was to support the custom scheme spec [1].
However, in WebKit side, no port has supported the feature in
WebKit layer after EFL port was removed. So there has been the
only IDL implementation of the NavigatorContentUtils in WebCore.
So we don't need to keep the implementation in WebCore anymore.
[1] https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers
* Configurations/FeatureDefines.xcconfig:
2019-03-23 Mark Lam <mark.lam@apple.com>
Rolling out r243032 and r243071 because the fix is incorrect.
https://bugs.webkit.org/show_bug.cgi?id=195892
<rdar://problem/48981239>
Not reviewed.
The fix is incorrect: it relies on being able to determine liveness of an object
in an ObjectPropertyCondition based on the state of the object's MarkedBit.
However, there's no guarantee that GC has run and that the MarkedBit is already
set even if the object is live. As a result, we may not re-install adaptive
watchpoints based on presumed dead objects which are actually live.
I'm rolling this out, and will implement a more comprehensive fix to handle
watchpoint liveness later.
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
(JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
* bytecode/ObjectPropertyCondition.cpp:
(JSC::ObjectPropertyCondition::dumpInContext const):
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::fireInternal):
* dfg/DFGAdaptiveStructureWatchpoint.cpp:
(JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
* runtime/StructureRareData.cpp:
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
2019-03-23 Keith Miller <keith_miller@apple.com>
Refactor clz/ctz and fix getLSBSet.
https://bugs.webkit.org/show_bug.cgi?id=196162
Reviewed by Saam Barati.
Refactor references of clz32/64 and ctz32 to use clz and ctz,
respectively.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGOperations.cpp:
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::digitDiv):
(JSC::JSBigInt::absoluteDivWithBigIntDivisor):
(JSC::JSBigInt::calculateMaximumCharactersRequired):
(JSC::JSBigInt::toStringBasePowerOfTwo):
(JSC::JSBigInt::compareToDouble):
* runtime/MathObject.cpp:
(JSC::mathProtoFuncClz32):
2019-03-23 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Shrink sizeof(RegExp)
https://bugs.webkit.org/show_bug.cgi?id=196133
Reviewed by Mark Lam.
Some applications have many RegExp cells. But RegExp cells are very large (144B).
This patch reduces the size from 144B to 48B by,
1. Allocate Yarr::YarrCodeBlock in non-GC heap. We can avoid this allocation if JIT is disabled.
2. m_captureGroupNames and m_namedGroupToParenIndex are moved to RareData. They are only used when RegExp has named capture groups.
* runtime/RegExp.cpp:
(JSC::RegExp::finishCreation):
(JSC::RegExp::estimatedSize):
(JSC::RegExp::compile):
(JSC::RegExp::matchConcurrently):
(JSC::RegExp::compileMatchOnly):
(JSC::RegExp::deleteCode):
(JSC::RegExp::printTraceData):
* runtime/RegExp.h:
* runtime/RegExpInlines.h:
(JSC::RegExp::hasCodeFor):
(JSC::RegExp::matchInline):
(JSC::RegExp::hasMatchOnlyCodeFor):
2019-03-22 Keith Rollin <krollin@apple.com>
Enable ThinLTO support in Production builds
https://bugs.webkit.org/show_bug.cgi?id=190758
<rdar://problem/45413233>
Reviewed by Daniel Bates.
Tweak JavaScriptCore's Base.xcconfig to be more in-line with other
.xcconfig files with regards to LTO settings. However, don't actually
enable LTO for JavaScriptCore. LTO is not enabled for JavaScriptCore
due to <rdar://problem/24543547>.
* Configurations/Base.xcconfig:
2019-03-22 Mark Lam <mark.lam@apple.com>
Placate exception check validation in genericTypedArrayViewProtoFuncLastIndexOf().
https://bugs.webkit.org/show_bug.cgi?id=196154
<rdar://problem/49145307>
Reviewed by Filip Pizlo.
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewProtoFuncLastIndexOf):
2019-03-22 Mark Lam <mark.lam@apple.com>
Placate exception check validation in constructJSWebAssemblyLinkError().
https://bugs.webkit.org/show_bug.cgi?id=196152
<rdar://problem/49145257>
Reviewed by Michael Saboff.
* wasm/js/WebAssemblyLinkErrorConstructor.cpp:
(JSC::constructJSWebAssemblyLinkError):
2019-03-22 Timothy Hatcher <timothy@apple.com>
Change macosx() to macos() in WK_API... and JSC_API... macros.
https://bugs.webkit.org/show_bug.cgi?id=196106
Reviewed by Brian Burg.
* API/JSBasePrivate.h:
* API/JSContext.h:
* API/JSContextPrivate.h:
* API/JSContextRef.h:
* API/JSContextRefInternal.h:
* API/JSContextRefPrivate.h:
* API/JSManagedValue.h:
* API/JSObjectRef.h:
* API/JSObjectRefPrivate.h:
* API/JSRemoteInspector.h:
* API/JSScript.h:
* API/JSTypedArray.h:
* API/JSValue.h:
* API/JSValuePrivate.h:
* API/JSValueRef.h:
* API/JSVirtualMachinePrivate.h:
2019-03-22 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, build fix for Windows
https://bugs.webkit.org/show_bug.cgi?id=196122
* runtime/FunctionExecutable.cpp:
2019-03-21 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Shrink sizeof(FunctionExecutable) by 16bytes
https://bugs.webkit.org/show_bug.cgi?id=196122
Reviewed by Saam Barati.
This patch reduces sizeof(FunctionExecutable) by 16 bytes.
1. ScriptExecutable::m_numParametersForCall and ScriptExecutable::m_numParametersForConstruct are not used in a meaningful way. Removed them.
2. ScriptExecutable::m_lastLine and ScriptExecutable::m_endColumn can be calculated from UnlinkedFunctionExecutable. So FunctionExecutable does not need to hold it.
This patch adds GlobalExecutable, which are non-function ScriptExecutables, and move m_lastLine and m_endColumn to this class.
3. FunctionExecutable still needs to have the feature overriding m_lastLine and m_endColumn. We move overridden data in FunctionExecutable::RareData.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::link):
* runtime/EvalExecutable.cpp:
(JSC::EvalExecutable::EvalExecutable):
* runtime/EvalExecutable.h:
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::FunctionExecutable::ensureRareDataSlow):
(JSC::FunctionExecutable::overrideInfo):
* runtime/FunctionExecutable.h:
* runtime/GlobalExecutable.cpp: Copied from Source/JavaScriptCore/tools/FunctionOverrides.h.
* runtime/GlobalExecutable.h: Copied from Source/JavaScriptCore/tools/FunctionOverrides.h.
(JSC::GlobalExecutable::lastLine const):
(JSC::GlobalExecutable::endColumn const):
(JSC::GlobalExecutable::recordParse):
(JSC::GlobalExecutable::GlobalExecutable):
* runtime/ModuleProgramExecutable.cpp:
(JSC::ModuleProgramExecutable::ModuleProgramExecutable):
* runtime/ModuleProgramExecutable.h:
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::ProgramExecutable):
* runtime/ProgramExecutable.h:
* runtime/ScriptExecutable.cpp:
(JSC::ScriptExecutable::clearCode):
(JSC::ScriptExecutable::installCode):
(JSC::ScriptExecutable::hasClearableCode const):
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::ScriptExecutable::typeProfilingEndOffset const):
(JSC::ScriptExecutable::recordParse):
(JSC::ScriptExecutable::lastLine const):
(JSC::ScriptExecutable::endColumn const):
* runtime/ScriptExecutable.h:
(JSC::ScriptExecutable::hasJITCodeForCall const):
(JSC::ScriptExecutable::hasJITCodeForConstruct const):
(JSC::ScriptExecutable::recordParse):
(JSC::ScriptExecutable::lastLine const): Deleted.
(JSC::ScriptExecutable::endColumn const): Deleted.
* tools/FunctionOverrides.h:
2019-03-21 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Shrink sizeof(RegExpObject)
https://bugs.webkit.org/show_bug.cgi?id=196130
Reviewed by Saam Barati.
sizeof(RegExpObject) is 48B due to one bool flag. We should compress this flag into lower bit of RegExp* field so that we can make RegExpObject 32B.
It saves memory footprint 1.3% in RAMification's regexp.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewRegexp):
(JSC::DFG::SpeculativeJIT::compileSetRegExpObjectLastIndex):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
(JSC::FTL::DFG::LowerDFGToB3::compileSetRegExpObjectLastIndex):
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::RegExpObject):
(JSC::RegExpObject::visitChildren):
(JSC::RegExpObject::getOwnPropertySlot):
(JSC::RegExpObject::defineOwnProperty):
* runtime/RegExpObject.h:
2019-03-21 Tomas Popela <tpopela@redhat.com>
[JSC] Fix build after r243232 on unsupported 64bit architectures
https://bugs.webkit.org/show_bug.cgi?id=196072
Reviewed by Keith Miller.
As Keith suggested we already expect 16 free bits at the top of any
pointer for JSValue even for the unsupported 64 bit arches.
* bytecode/CodeOrigin.h:
2019-03-21 Mark Lam <mark.lam@apple.com>
Remove an invalid assertion in DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined().
https://bugs.webkit.org/show_bug.cgi?id=196116
<rdar://problem/48976951>
Reviewed by Filip Pizlo.
The DFG backend should not make assumptions about what optimizations the front end
will or will not do. The assertion asserts that the operand cannot be known to be
a cell. However, it is not guaranteed that the front end will fold away this case.
Also, the DFG backend is perfectly capable of generating code to handle the case
where the operand is a cell.
The attached test case demonstrates a case where the operand can be a known cell.
The test needs to be run with the concurrent JIT and GC, and is racy. It used to
trip up this assertion about once every 10 runs or so.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined):
2019-03-21 Tadeu Zagallo <tzagallo@apple.com>
JSC::createError should clear exception thrown by errorDescriptionForValue
https://bugs.webkit.org/show_bug.cgi?id=196089
Reviewed by Mark Lam.
errorDescriptionForValue returns a nullString in case of failure, but it
might also throw an OOM exception when resolving a rope string. We need
to clear any potential exceptions thrown by errorDescriptionForValue
before returning the OOM from JSC::createError.
* runtime/ExceptionHelpers.cpp:
(JSC::createError):
2019-03-21 Robin Morisset <rmorisset@apple.com>
B3::Opcode can fit in a single byte, shrinking B3Value by 8 bytes
https://bugs.webkit.org/show_bug.cgi?id=196014
Reviewed by Keith Miller.
B3::Opcode has less than one hundred cases, so it can easily fit in one byte (from two currently)
This shrinks B3::Kind from 4 bytes to 2 (by removing the byte of padding at the end).
This in turns eliminate padding from B3::Value, shrinking it by 8 bytes (out of 80).
* b3/B3Opcode.h:
2019-03-21 Michael Catanzaro <mcatanzaro@igalia.com>
Unreviewed, more clang 3.8 build fixes
https://bugs.webkit.org/show_bug.cgi?id=195947
<rdar://problem/49069219>
In the spirit of making our code worse to please old compilers....
* bindings/ScriptValue.cpp:
(Inspector::jsToInspectorValue):
* bytecode/GetterSetterAccessCase.cpp:
(JSC::GetterSetterAccessCase::create):
(JSC::GetterSetterAccessCase::clone const):
* bytecode/InstanceOfAccessCase.cpp:
(JSC::InstanceOfAccessCase::clone const):
* bytecode/IntrinsicGetterAccessCase.cpp:
(JSC::IntrinsicGetterAccessCase::clone const):
* bytecode/ModuleNamespaceAccessCase.cpp:
(JSC::ModuleNamespaceAccessCase::clone const):
* bytecode/ProxyableAccessCase.cpp:
(JSC::ProxyableAccessCase::clone const):
2019-03-21 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Do not create JIT related data under non-JIT mode
https://bugs.webkit.org/show_bug.cgi?id=195982
Reviewed by Mark Lam.
We avoid creations of JIT related data structures under non-JIT mode.
This patch removes the following allocations.
1. JITThunks
2. FTLThunks
3. FixedVMPoolExecutableAllocator
4. noJITValueProfileSingleton since it is no longer used
5. ARM disassembler should be initialized when it is used
6. Wasm related data structures are accidentally allocated if VM::canUseJIT() == false &&
Options::useWebAssembly() == true. Add Wasm::isSupported() function to check the both conditions.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/Heap.cpp:
(JSC::Heap::runEndPhase):
* jit/ExecutableAllocator.cpp:
(JSC::FixedVMPoolExecutableAllocator::~FixedVMPoolExecutableAllocator):
(JSC::ExecutableAllocator::initializeUnderlyingAllocator):
(JSC::ExecutableAllocator::isValid const):
(JSC::ExecutableAllocator::underMemoryPressure):
(JSC::ExecutableAllocator::memoryPressureMultiplier):
(JSC::ExecutableAllocator::allocate):
(JSC::ExecutableAllocator::isValidExecutableMemory):
(JSC::ExecutableAllocator::getLock const):
(JSC::ExecutableAllocator::committedByteCount):
(JSC::ExecutableAllocator::dumpProfile):
(JSC::startOfFixedExecutableMemoryPoolImpl):
(JSC::endOfFixedExecutableMemoryPoolImpl):
(JSC::ExecutableAllocator::initialize):
(JSC::ExecutableAllocator::initializeAllocator): Deleted.
(JSC::ExecutableAllocator::ExecutableAllocator): Deleted.
(JSC::ExecutableAllocator::~ExecutableAllocator): Deleted.
* jit/ExecutableAllocator.h:
(JSC::ExecutableAllocatorBase::isValid const):
(JSC::ExecutableAllocatorBase::underMemoryPressure):
(JSC::ExecutableAllocatorBase::memoryPressureMultiplier):
(JSC::ExecutableAllocatorBase::dumpProfile):
(JSC::ExecutableAllocatorBase::allocate):
(JSC::ExecutableAllocatorBase::setJITEnabled):
(JSC::ExecutableAllocatorBase::isValidExecutableMemory):
(JSC::ExecutableAllocatorBase::committedByteCount):
(JSC::ExecutableAllocatorBase::getLock const):
(JSC::ExecutableAllocator::isValid const): Deleted.
(JSC::ExecutableAllocator::underMemoryPressure): Deleted.
(JSC::ExecutableAllocator::memoryPressureMultiplier): Deleted.
(JSC::ExecutableAllocator::allocate): Deleted.
(JSC::ExecutableAllocator::setJITEnabled): Deleted.
(JSC::ExecutableAllocator::isValidExecutableMemory): Deleted.
(JSC::ExecutableAllocator::committedByteCount): Deleted.
(JSC::ExecutableAllocator::getLock const): Deleted.
* jsc.cpp:
(functionWebAssemblyMemoryMode):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSLock.cpp:
(JSC::JSLock::didAcquireLock):
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/VM.cpp:
(JSC::enableAssembler):
(JSC::VM::canUseAssembler):
(JSC::VM::VM):
* runtime/VM.h:
* wasm/WasmCapabilities.h: Added.
(JSC::Wasm::isSupported):
* wasm/WasmFaultSignalHandler.cpp:
(JSC::Wasm::enableFastMemory):
2019-03-21 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Fix JSC build with newer ICU
https://bugs.webkit.org/show_bug.cgi?id=196098
Reviewed by Keith Miller.
IntlDateTimeFormat and IntlNumberFormat have switch statement over ICU's enums. However it lacks "default" clause so that
the compile error occurs when a new enum value is added in ICU side. We should have "default" clause which just fallbacks
"unknown"_s case. The behavior is not changed since we already have `return "unknown"_s;` statement anyway after the
switch statement. This patch just suppresses a compile error.
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::partTypeString):
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::partTypeString):
2019-03-21 Tadeu Zagallo <tzagallo@apple.com>
JSObject::putDirectIndexSlowOrBeyondVectorLength should check if indexIsSufficientlyBeyondLengthForSparseMap
https://bugs.webkit.org/show_bug.cgi?id=196078
<rdar://problem/35925380>
Reviewed by Mark Lam.
Unlike the other variations of putByIndex, it only checked if the index
was larger than MIN_SPARSE_ARRAY_INDEX when the indexingType was
ALL_BLANK_INDEXING_TYPES. This resulted in a huge butterfly being
allocated for object literals (e.g. `{[9e4]: ...}`) and objects parsed
from JSON.
* runtime/JSObject.cpp:
(JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):
2019-03-21 Tadeu Zagallo <tzagallo@apple.com>
CachedUnlinkedSourceCodeShape::m_provider should be a CachedRefPtr
https://bugs.webkit.org/show_bug.cgi?id=196079
Reviewed by Saam Barati.
It was mistakenly cached as CachedPtr, which was leaking the decoded SourceProvider.
* runtime/CachedTypes.cpp:
(JSC::CachedUnlinkedSourceCodeShape::encode):
2019-03-21 Mark Lam <mark.lam@apple.com>
Placate exception check validation in operationArrayIndexOfString().
https://bugs.webkit.org/show_bug.cgi?id=196067
<rdar://problem/49056572>
Reviewed by Michael Saboff.
* dfg/DFGOperations.cpp:
2019-03-21 Xan Lopez <xan@igalia.com>
[JSC][x86] Drop support for x87 floating point
https://bugs.webkit.org/show_bug.cgi?id=194853
Reviewed by Don Olmstead.
Require SSE2 throughout the codebase, and remove x87 support where
it was optionally available. SSE2 detection happens at compile
time through a static_assert.
* assembler/MacroAssemblerX86.h:
(JSC::MacroAssemblerX86::storeDouble):
(JSC::MacroAssemblerX86::moveDoubleToInts):
(JSC::MacroAssemblerX86::supportsFloatingPoint):
(JSC::MacroAssemblerX86::supportsFloatingPointTruncate):
(JSC::MacroAssemblerX86::supportsFloatingPointSqrt):
(JSC::MacroAssemblerX86::supportsFloatingPointAbs):
* assembler/MacroAssemblerX86Common.cpp:
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::moveDouble):
(JSC::MacroAssemblerX86Common::loadDouble):
(JSC::MacroAssemblerX86Common::loadFloat):
(JSC::MacroAssemblerX86Common::storeDouble):
(JSC::MacroAssemblerX86Common::storeFloat):
(JSC::MacroAssemblerX86Common::convertDoubleToFloat):
(JSC::MacroAssemblerX86Common::convertFloatToDouble):
(JSC::MacroAssemblerX86Common::addDouble):
(JSC::MacroAssemblerX86Common::addFloat):
(JSC::MacroAssemblerX86Common::divDouble):
(JSC::MacroAssemblerX86Common::divFloat):
(JSC::MacroAssemblerX86Common::subDouble):
(JSC::MacroAssemblerX86Common::subFloat):
(JSC::MacroAssemblerX86Common::mulDouble):
(JSC::MacroAssemblerX86Common::mulFloat):
(JSC::MacroAssemblerX86Common::convertInt32ToDouble):
(JSC::MacroAssemblerX86Common::convertInt32ToFloat):
(JSC::MacroAssemblerX86Common::branchDouble):
(JSC::MacroAssemblerX86Common::branchFloat):
(JSC::MacroAssemblerX86Common::compareDouble):
(JSC::MacroAssemblerX86Common::compareFloat):
(JSC::MacroAssemblerX86Common::branchTruncateDoubleToInt32):
(JSC::MacroAssemblerX86Common::truncateDoubleToInt32):
(JSC::MacroAssemblerX86Common::truncateFloatToInt32):
(JSC::MacroAssemblerX86Common::branchConvertDoubleToInt32):
(JSC::MacroAssemblerX86Common::branchDoubleNonZero):
(JSC::MacroAssemblerX86Common::branchDoubleZeroOrNaN):
(JSC::MacroAssemblerX86Common::lshiftPacked):
(JSC::MacroAssemblerX86Common::rshiftPacked):
(JSC::MacroAssemblerX86Common::orPacked):
(JSC::MacroAssemblerX86Common::move32ToFloat):
(JSC::MacroAssemblerX86Common::moveFloatTo32):
(JSC::MacroAssemblerX86Common::moveConditionallyDouble):
(JSC::MacroAssemblerX86Common::moveConditionallyFloat):
* offlineasm/x86.rb:
* runtime/MathCommon.cpp:
(JSC::operationMathPow):
2019-03-21 Carlos Garcia Campos <cgarcia@igalia.com>
[GLIB] User data not correctly passed to callback of functions and constructors with no parameters
https://bugs.webkit.org/show_bug.cgi?id=196073
Reviewed by Michael Catanzaro.
This is because GClosure always expects a first parameter as instance. In case of functions or constructors with
no parameters we insert a fake instance which is just a null pointer that is ignored by the callback. But
if the function/constructor has user data the callback will expect one parameter for the user data. In that case
we can simply swap instance/user data so that the fake instance will be the second argument and user data the
first one.
* API/glib/JSCClass.cpp:
(jscClassCreateConstructor): Use g_cclosure_new_swap() if parameters is empty and user data was provided.
* API/glib/JSCValue.cpp:
(jscValueFunctionCreate): Ditto.
2019-03-21 Pablo Saavedra <psaavedra@igalia.com>
[JSC][32-bit] Build failure after r243232
https://bugs.webkit.org/show_bug.cgi?id=196068
Reviewed by Mark Lam.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::reifyInlinedCallFrames):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
2019-03-21 Carlos Garcia Campos <cgarcia@igalia.com>
[GLib] Returning G_TYPE_OBJECT from a method does not work
https://bugs.webkit.org/show_bug.cgi?id=195574
Reviewed by Michael Catanzaro.
Add more documentation to clarify the ownership of wrapped objects when created and when returned by functions.
* API/glib/JSCCallbackFunction.cpp:
(JSC::JSCCallbackFunction::construct): Also allow to return boxed types from a constructor.
* API/glib/JSCClass.cpp:
* API/glib/JSCValue.cpp:
2019-03-21 Mark Lam <mark.lam@apple.com>
Cap length of an array with spread to MIN_ARRAY_STORAGE_CONSTRUCTION_LENGTH.
https://bugs.webkit.org/show_bug.cgi?id=196055
<rdar://problem/49067448>
Reviewed by Yusuke Suzuki.
We are doing this because:
1. We expect the array to be densely packed.
2. SpeculativeJIT::compileAllocateNewArrayWithSize() (and the FTL equivalent)
expects the array length to be less than MIN_ARRAY_STORAGE_CONSTRUCTION_LENGTH
if we don't want to use an ArrayStorage shape.
3. There's no reason why an array with spread needs to be that large anyway.
MIN_ARRAY_STORAGE_CONSTRUCTION_LENGTH is plenty.
In this patch, we also add a debug assert in compileAllocateNewArrayWithSize() and
emitAllocateButterfly() to check for overflows.
* assembler/AbortReason.h:
* dfg/DFGOperations.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCreateRest):
(JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread):
(JSC::DFG::SpeculativeJIT::emitAllocateButterfly):
(JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
* runtime/ArrayConventions.h:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
2019-03-20 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use finalizer in JSGlobalLexicalEnvironment and JSGlobalObject
https://bugs.webkit.org/show_bug.cgi?id=195992
Reviewed by Keith Miller and Mark Lam.
JSGlobalLexicalEnvironment and JSGlobalObject have their own CompleteSubspace to call destructors while they are not inheriting JSDestructibleObject.
But it is too costly since (1) it requires CompleteSubspace in VM, (2) both objects allocate MarkedBlocks while # of them are really small.
Instead of using CompleteSubspace, we just set finalizers for them. Since these objects are rarely allocated, setting finalizers does not show
memory / performance problems (actually, previously we used finalizer for ArrayPrototype due to the same reason, and it does not show any problems).
And we also add following two changes to JSSegmentedVariableObject.
1. Remove one boolean used for debugging in Release build. It enlarges sizeof(JSSegmentedVariableObject) and allocates one more MarkedBlock.
2. Use cellLock() instead.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* runtime/JSSegmentedVariableObject.cpp:
(JSC::JSSegmentedVariableObject::findVariableIndex):
(JSC::JSSegmentedVariableObject::addVariables):
(JSC::JSSegmentedVariableObject::visitChildren):
(JSC::JSSegmentedVariableObject::~JSSegmentedVariableObject):
(JSC::JSSegmentedVariableObject::finishCreation):
* runtime/JSSegmentedVariableObject.h:
(JSC::JSSegmentedVariableObject::subspaceFor): Deleted.
* runtime/JSSegmentedVariableObjectHeapCellType.cpp: Removed.
* runtime/JSSegmentedVariableObjectHeapCellType.h: Removed.
* runtime/StringIteratorPrototype.cpp:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2019-03-20 Saam Barati <sbarati@apple.com>
DFG::AbstractValue::validateOSREntry is wrong when isHeapTop and the incoming value is Empty
https://bugs.webkit.org/show_bug.cgi?id=195721
Reviewed by Filip Pizlo.
There was a check in AbstractValue::validateOSREntry where it checked
if isHeapTop(), and if so, just returned true. However, this is wrong
if the value we're checking against is the empty value, since HeapTop
does not include the Empty value. Instead, this check should be
isBytecodeTop(), which does account for the empty value.
This patch also does a couple of other things:
- For our OSR entry AbstractValues, we were using HeapTop to mark
a dead value. That is now changed to BytecodeTop. (The idea here
is just to have validateOSREntry return early.)
- It wasn't obvious to me how I could make this fail in JS code.
The symptom we'd end up seeing is something like a nullptr derefernece
from forgetting to do a TDZ check. Instead, I've added a unit test.
This unit test lives in a new test file: testdfg. testdfg is similar
to testb3/testair/testapi.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/SpeculatedType.h:
* dfg/DFGAbstractValue.h:
(JSC::DFG::AbstractValue::isBytecodeTop const):
(JSC::DFG::AbstractValue::validateOSREntryValue const):
* dfg/testdfg.cpp: Added.
(hiddenTruthBecauseNoReturnIsStupid):
(usage):
(JSC::DFG::testEmptyValueDoesNotValidateWithHeapTop):
(JSC::DFG::run):
(run):
(main):
* shell/CMakeLists.txt:
2019-03-20 Saam Barati <sbarati@apple.com>
typeOfDoubleSum is wrong for when NaN can be produced
https://bugs.webkit.org/show_bug.cgi?id=196030
Reviewed by Filip Pizlo.
We were using typeOfDoubleSum(SpeculatedType, SpeculatedType) for add/sub/mul.
It assumed that the only way the resulting type could be NaN is if one of
the inputs were NaN. However, this is wrong. NaN can be produced in at least
these cases:
Infinity - Infinity
Infinity + (-Infinity)
Infinity * 0
* bytecode/SpeculatedType.cpp:
(JSC::typeOfDoubleSumOrDifferenceOrProduct):
(JSC::typeOfDoubleSum):
(JSC::typeOfDoubleDifference):
(JSC::typeOfDoubleProduct):
2019-03-20 Simon Fraser <simon.fraser@apple.com>
Rename ENABLE_ACCELERATED_OVERFLOW_SCROLLING macro to ENABLE_OVERFLOW_SCROLLING_TOUCH
https://bugs.webkit.org/show_bug.cgi?id=196049
Reviewed by Tim Horton.
This macro is about the -webkit-overflow-scrolling CSS property, not accelerated
overflow scrolling in general, so rename it.
* Configurations/FeatureDefines.xcconfig:
2019-03-20 Saam Barati <sbarati@apple.com>
GetCallee does not report the correct type in AI
https://bugs.webkit.org/show_bug.cgi?id=195981
Reviewed by Yusuke Suzuki.
I found this as part of my work in:
https://bugs.webkit.org/show_bug.cgi?id=195924
I'm not sure how to write a test for it.
GetCallee was always reporting that the result is SpecFunction. However,
for eval, it may result in just a JSCallee object, which is not a JSFunction.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2019-03-20 Mark Lam <mark.lam@apple.com>
Open source arm64e code.
https://bugs.webkit.org/show_bug.cgi?id=196012
<rdar://problem/49066237>
Reviewed by Keith Miller.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* assembler/ARM64EAssembler.h: Added.
(JSC::ARM64EAssembler::encodeGroup1):
(JSC::ARM64EAssembler::encodeGroup2):
(JSC::ARM64EAssembler::encodeGroup4):
(JSC::ARM64EAssembler::pacia1716):
(JSC::ARM64EAssembler::pacib1716):
(JSC::ARM64EAssembler::autia1716):
(JSC::ARM64EAssembler::autib1716):
(JSC::ARM64EAssembler::paciaz):
(JSC::ARM64EAssembler::paciasp):
(JSC::ARM64EAssembler::pacibz):
(JSC::ARM64EAssembler::pacibsp):
(JSC::ARM64EAssembler::autiaz):
(JSC::ARM64EAssembler::autiasp):
(JSC::ARM64EAssembler::autibz):
(JSC::ARM64EAssembler::autibsp):
(JSC::ARM64EAssembler::xpaclri):
(JSC::ARM64EAssembler::pacia):
(JSC::ARM64EAssembler::pacib):
(JSC::ARM64EAssembler::pacda):
(JSC::ARM64EAssembler::pacdb):
(JSC::ARM64EAssembler::autia):
(JSC::ARM64EAssembler::autib):
(JSC::ARM64EAssembler::autda):
(JSC::ARM64EAssembler::autdb):
(JSC::ARM64EAssembler::paciza):
(JSC::ARM64EAssembler::pacizb):
(JSC::ARM64EAssembler::pacdza):
(JSC::ARM64EAssembler::pacdzb):
(JSC::ARM64EAssembler::autiza):
(JSC::ARM64EAssembler::autizb):
(JSC::ARM64EAssembler::autdza):
(JSC::ARM64EAssembler::autdzb):
(JSC::ARM64EAssembler::xpaci):
(JSC::ARM64EAssembler::xpacd):
(JSC::ARM64EAssembler::pacga):
(JSC::ARM64EAssembler::braa):
(JSC::ARM64EAssembler::brab):
(JSC::ARM64EAssembler::blraa):
(JSC::ARM64EAssembler::blrab):
(JSC::ARM64EAssembler::braaz):
(JSC::ARM64EAssembler::brabz):
(JSC::ARM64EAssembler::blraaz):
(JSC::ARM64EAssembler::blrabz):
(JSC::ARM64EAssembler::retaa):
(JSC::ARM64EAssembler::retab):
(JSC::ARM64EAssembler::eretaa):
(JSC::ARM64EAssembler::eretab):
(JSC::ARM64EAssembler::linkPointer):
(JSC::ARM64EAssembler::repatchPointer):
(JSC::ARM64EAssembler::setPointer):
(JSC::ARM64EAssembler::readPointer):
(JSC::ARM64EAssembler::readCallTarget):
(JSC::ARM64EAssembler::ret):
* assembler/MacroAssembler.cpp:
* assembler/MacroAssembler.h:
* assembler/MacroAssemblerARM64.cpp:
* assembler/MacroAssemblerARM64E.h: Added.
(JSC::MacroAssemblerARM64E::tagReturnAddress):
(JSC::MacroAssemblerARM64E::untagReturnAddress):
(JSC::MacroAssemblerARM64E::tagPtr):
(JSC::MacroAssemblerARM64E::untagPtr):
(JSC::MacroAssemblerARM64E::removePtrTag):
(JSC::MacroAssemblerARM64E::callTrustedPtr):
(JSC::MacroAssemblerARM64E::call):
(JSC::MacroAssemblerARM64E::callRegister):
(JSC::MacroAssemblerARM64E::jump):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::reifyInlinedCallFrames):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
* ftl/FTLThunks.cpp:
(JSC::FTL::genericGenerationThunkGenerator):
* jit/CCallHelpers.h:
(JSC::CCallHelpers::prepareForTailCallSlow):
* jit/CallFrameShuffler.cpp:
(JSC::CallFrameShuffler::prepareForTailCall):
* jit/ExecutableAllocator.cpp:
(JSC::ExecutableAllocator::allocate):
* jit/ThunkGenerators.cpp:
(JSC::arityFixupGenerator):
* llint/LLIntOfflineAsmConfig.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/ClassInfo.h:
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSCPtrTag.cpp: Added.
(JSC::tagForPtr):
(JSC::ptrTagName):
(JSC::initializePtrTagLookup):
* runtime/JSCPtrTag.h:
(JSC::initializePtrTagLookup):
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
2019-03-20 Tadeu Zagallo <tzagallo@apple.com>
JSC::createError needs to check for OOM in errorDescriptionForValue
https://bugs.webkit.org/show_bug.cgi?id=196032
<rdar://problem/46842740>
Reviewed by Mark Lam.
We were missing exceptions checks at two levels:
- In errorDescriptionForValue, when the value is a string, we should
check that JSString::value returns a valid string, since we might run
out of memory if it is a rope and we need to resolve it.
- In createError, we should check for the result of errorDescriptionForValue
before concatenating it with the message provided by the caller.
* runtime/ExceptionHelpers.cpp:
(JSC::errorDescriptionForValue):
(JSC::createError):
* runtime/ExceptionHelpers.h:
2019-03-20 Devin Rousso <drousso@apple.com>
Web Inspector: DOM: include window as part of any event listener chain
https://bugs.webkit.org/show_bug.cgi?id=195730
<rdar://problem/48916872>
Reviewed by Timothy Hatcher.
* inspector/protocol/DOM.json:
Modify `DOM.getEventListenersForNode` to not save the handler object, as that was never
used by the frontend. Add an `onWindow` optional property to `DOM.EventListener` that is set
when the event listener was retrieved from the `window` object.
2019-03-20 Devin Rousso <drousso@apple.com>
Web Inspector: Runtime: lazily create the agent
https://bugs.webkit.org/show_bug.cgi?id=195972
<rdar://problem/49039655>
Reviewed by Timothy Hatcher.
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
(Inspector::JSGlobalObjectInspectorController::createLazyAgents):
* inspector/agents/InspectorRuntimeAgent.h:
(Inspector::InspectorRuntimeAgent::enabled): Deleted.
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::didCreateFrontendAndBackend): Added.
(Inspector::InspectorRuntimeAgent::willDestroyFrontendAndBackend):
* inspector/agents/JSGlobalObjectRuntimeAgent.h:
* inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
(Inspector::JSGlobalObjectRuntimeAgent::didCreateFrontendAndBackend): Deleted.
2019-03-20 Michael Saboff <msaboff@apple.com>
JSC test crash: stress/dont-strength-reduce-regexp-with-compile-error.js.default
https://bugs.webkit.org/show_bug.cgi?id=195906
Reviewed by Mark Lam.
The problem here as that we may successfully parsed a RegExp without running out of stack,
but later run out of stack when trying to JIT compile the same expression.
Added a check for available stack space when we call into one of the parenthesis compilation
functions that recurse. When we don't have enough stack space to recurse, we fail the JIT
compilation and let the interpreter handle the expression.
From code inspection of the YARR interpreter it has the same issue, but I couldn't cause a failure.
Filed a new bug and added a FIXME comment for the Interpreter to have similar checks.
Given that we can reproduce a failure, this is sufficient for now.
This change is covered by the previously added failing test,
JSTests/stress/dont-strength-reduce-regexp-with-compile-error.js.
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::Interpreter::interpret):
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::opCompileParenthesesSubpattern):
(JSC::Yarr::YarrGenerator::opCompileParentheticalAssertion):
(JSC::Yarr::YarrGenerator::opCompileBody):
(JSC::Yarr::dumpCompileFailure):
* yarr/YarrJIT.h:
2019-03-20 Robin Morisset <rmorisset@apple.com>
DFGNodeAllocator.h is dead code
https://bugs.webkit.org/show_bug.cgi?id=196019
Reviewed by Yusuke Suzuki.
As explained by Yusuke on IRC, the comment on DFG::Node saying that it cannot have a destructor is obsolete since https://trac.webkit.org/changeset/216815/webkit.
This patch removes both the comment and DFGNodeAllocator.h that that patch forgot to remove.
* dfg/DFGNode.h:
(JSC::DFG::Node::dumpChildren):
* dfg/DFGNodeAllocator.h: Removed.
2019-03-20 Robin Morisset <rmorisset@apple.com>
Compress CodeOrigin into a single word in the common case
https://bugs.webkit.org/show_bug.cgi?id=195928
Reviewed by Saam Barati.
The trick is that pointers only take 48 bits on x86_64 in practice (and we can even use the bottom three bits of that thanks to alignment), and even less on ARM64.
So we can shove the bytecode index in the top bits almost all the time.
If the bytecodeIndex is too ginormous (1<<16 in practice on x86_64), we just set one bit at the bottom and store a pointer to some out-of-line storage instead.
Finally we represent an invalid bytecodeIndex (which used to be represented by UINT_MAX) by setting the second least signifcant bit.
The patch looks very long, but most of it is just replacing direct accesses to inlineCallFrame and bytecodeIndex by the relevant getters.
End result: CodeOrigin in the common case moves from 16 bytes (8 for InlineCallFrame*, 4 for unsigned bytecodeIndex, 4 of padding) to 8.
As a reference, during running JetStream2 we allocate more than 35M CodeOrigins. While they won't all be alive at the same time, it is still quite a lot of objects, so I am hoping for some small
improvement to RAMification from this work.
The one slightly tricky part is that we must implement copy and move assignment operators and constructors to make sure that any out-of-line storage belongs to a single CodeOrigin and is destroyed exactly once.
* bytecode/ByValInfo.h:
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFor):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::globalObjectFor):
(JSC::CodeBlock::updateOSRExitCounterAndCheckIfNeedToReoptimize):
(JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex):
* bytecode/CodeOrigin.cpp:
(JSC::CodeOrigin::inlineDepth const):
(JSC::CodeOrigin::isApproximatelyEqualTo const):
(JSC::CodeOrigin::approximateHash const):
(JSC::CodeOrigin::inlineStack const):
(JSC::CodeOrigin::codeOriginOwner const):
(JSC::CodeOrigin::stackOffset const):
(JSC::CodeOrigin::dump const):
(JSC::CodeOrigin::inlineDepthForCallFrame): Deleted.
* bytecode/CodeOrigin.h:
(JSC::OutOfLineCodeOrigin::OutOfLineCodeOrigin):
(JSC::CodeOrigin::CodeOrigin):
(JSC::CodeOrigin::~CodeOrigin):
(JSC::CodeOrigin::isSet const):
(JSC::CodeOrigin::isHashTableDeletedValue const):
(JSC::CodeOrigin::bytecodeIndex const):
(JSC::CodeOrigin::inlineCallFrame const):
(JSC::CodeOrigin::buildCompositeValue):
(JSC::CodeOrigin::hash const):
(JSC::CodeOrigin::operator== const):
(JSC::CodeOrigin::exitingInlineKind const): Deleted.
* bytecode/DeferredSourceDump.h:
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeForStubInfo):
(JSC::GetByIdStatus::computeFor):
* bytecode/ICStatusMap.cpp:
(JSC::ICStatusContext::isInlined const):
* bytecode/InByIdStatus.cpp:
(JSC::InByIdStatus::computeFor):
(JSC::InByIdStatus::computeForStubInfo):
* bytecode/InlineCallFrame.cpp:
(JSC::InlineCallFrame::dumpInContext const):
* bytecode/InlineCallFrame.h:
(JSC::InlineCallFrame::computeCallerSkippingTailCalls):
(JSC::InlineCallFrame::getCallerInlineFrameSkippingTailCalls):
(JSC::baselineCodeBlockForOriginAndBaselineCodeBlock):
(JSC::CodeOrigin::walkUpInlineStack):
* bytecode/InstanceOfStatus.h:
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeForStubInfo):
(JSC::PutByIdStatus::computeFor):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGArgumentsUtilities.cpp:
(JSC::DFG::argumentsInvolveStackSlot):
(JSC::DFG::emitCodeToGetArgumentsArrayLength):
* dfg/DFGArrayMode.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation):
(JSC::DFG::ByteCodeParser::setLocal):
(JSC::DFG::ByteCodeParser::setArgument):
(JSC::DFG::ByteCodeParser::flushForTerminalImpl):
(JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::parseCodeBlock):
(JSC::DFG::ByteCodeParser::handlePutByVal):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::attemptToMakeGetArrayLength):
* dfg/DFGForAllKills.h:
(JSC::DFG::forAllKilledOperands):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dumpCodeOrigin):
(JSC::DFG::Graph::dump):
(JSC::DFG::Graph::isLiveInBytecode):
(JSC::DFG::Graph::methodOfGettingAValueProfileFor):
(JSC::DFG::Graph::willCatchExceptionInMachineFrame):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::executableFor):
(JSC::DFG::Graph::isStrictModeFor):
(JSC::DFG::Graph::hasExitSite):
(JSC::DFG::Graph::forAllLocalsLiveInBytecode):
* dfg/DFGLiveCatchVariablePreservationPhase.cpp:
(JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
* dfg/DFGMinifiedNode.cpp:
(JSC::DFG::MinifiedNode::fromNode):
* dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
(JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::executeOSRExit):
(JSC::DFG::reifyInlinedCallFrames):
(JSC::DFG::adjustAndJumpToTarget):
(JSC::DFG::printOSRExit):
(JSC::DFG::OSRExit::compileExit):
* dfg/DFGOSRExitBase.cpp:
(JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::handleExitCounts):
(JSC::DFG::reifyInlinedCallFrames):
(JSC::DFG::adjustAndJumpToTarget):
* dfg/DFGOSRExitPreparation.cpp:
(JSC::DFG::prepareCodeOriginForOSRExit):
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* dfg/DFGOperations.cpp:
* dfg/DFGPreciseLocalClobberize.h:
(JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitGetLength):
(JSC::DFG::SpeculativeJIT::emitGetCallee):
(JSC::DFG::SpeculativeJIT::compileCurrentBlock):
(JSC::DFG::SpeculativeJIT::compileValueAdd):
(JSC::DFG::SpeculativeJIT::compileValueSub):
(JSC::DFG::SpeculativeJIT::compileValueNegate):
(JSC::DFG::SpeculativeJIT::compileValueMul):
(JSC::DFG::SpeculativeJIT::compileForwardVarargs):
(JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGTierUpCheckInjectionPhase.cpp:
(JSC::DFG::TierUpCheckInjectionPhase::run):
(JSC::DFG::TierUpCheckInjectionPhase::canOSREnterAtLoopHint):
(JSC::DFG::TierUpCheckInjectionPhase::buildNaturalLoopToLoopHintMap):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::run):
* dfg/DFGVariableEventStream.cpp:
(JSC::DFG::VariableEventStream::reconstruct const):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
(JSC::FTL::DFG::LowerDFGToB3::compileValueSub):
(JSC::FTL::DFG::LowerDFGToB3::compileValueMul):
(JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
(JSC::FTL::DFG::LowerDFGToB3::compileValueNegate):
(JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
(JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
(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):
(JSC::FTL::DFG::LowerDFGToB3::getArgumentsLength):
(JSC::FTL::DFG::LowerDFGToB3::getCurrentCallee):
(JSC::FTL::DFG::LowerDFGToB3::getArgumentsStart):
(JSC::FTL::DFG::LowerDFGToB3::codeOriginDescriptionOfCallSite const):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
* interpreter/CallFrame.cpp:
(JSC::CallFrame::bytecodeOffset):
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::unwindToMachineCodeBlockFrame):
(JSC::StackVisitor::readFrame):
(JSC::StackVisitor::readNonInlinedFrame):
(JSC::inlinedFrameOffset):
(JSC::StackVisitor::readInlinedFrame):
* interpreter/StackVisitor.h:
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::executableFor):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::isStrictModeFor):
(JSC::AssemblyHelpers::argumentsStart):
(JSC::AssemblyHelpers::argumentCount):
* jit/PCToCodeOriginMap.cpp:
(JSC::PCToCodeOriginMap::PCToCodeOriginMap):
(JSC::PCToCodeOriginMap::findPC const):
* profiler/ProfilerOriginStack.cpp:
(JSC::Profiler::OriginStack::OriginStack):
* profiler/ProfilerOriginStack.h:
* runtime/ErrorInstance.cpp:
(JSC::appendSourceToError):
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::processUnverifiedStackTraces):
2019-03-20 Devin Rousso <drousso@apple.com>
Web Inspector: Search: allow DOM searches to be case sensitive
https://bugs.webkit.org/show_bug.cgi?id=194673
<rdar://problem/48087577>
Reviewed by Timothy Hatcher.
Since `DOM.performSearch` also searches by selector and XPath, some results may appear
as unexpected. As an example, searching for "BoDy" will still return the <body> as a result,
as although the literal node name ("BODY") didn't match, it did match via selector/XPath.
* inspector/protocol/DOM.json:
Allow `DOM.performSearch` to be case sensitive.
2019-03-20 Saam Barati <sbarati@apple.com>
AI rule for ValueBitNot/ValueBitXor/ValueBitAnd/ValueBitOr is wrong
https://bugs.webkit.org/show_bug.cgi?id=195980
Reviewed by Yusuke Suzuki.
They were all saying they could be type: (SpecBoolInt32, SpecBigInt)
However, they should have been type: (SpecInt32Only, SpecBigInt)
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2019-03-20 Michael Catanzaro <mcatanzaro@igalia.com>
Remove copyRef() calls added in r243163
https://bugs.webkit.org/show_bug.cgi?id=195962
Reviewed by Chris Dumez.
As best I can tell, may be a GCC 9 bug. It shouldn't warn about this case because the return
value is noncopyable and the WTFMove() is absolutely required. We can avoid the warning
without refcount churn by introducing an intermediate variable.
* inspector/scripts/codegen/cpp_generator_templates.py:
2019-03-20 Carlos Garcia Campos <cgarcia@igalia.com>
[GLIB] Optimize jsc_value_object_define_property_data|accessor
https://bugs.webkit.org/show_bug.cgi?id=195679
Reviewed by Saam Barati.
Use direct C++ call instead of using the JSC GLib API to create the descriptor object and invoke Object.defineProperty().
* API/glib/JSCValue.cpp:
(jsc_value_object_define_property_data):
(jsc_value_object_define_property_accessor):
2019-03-19 Devin Rousso <drousso@apple.com>
Web Inspector: Debugger: lazily create the agent
https://bugs.webkit.org/show_bug.cgi?id=195973
<rdar://problem/49039674>
Reviewed by Joseph Pecoraro.
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
(Inspector::JSGlobalObjectInspectorController::frontendInitialized):
(Inspector::JSGlobalObjectInspectorController::createLazyAgents):
* inspector/JSGlobalObjectConsoleClient.h:
(Inspector::JSGlobalObjectConsoleClient::setInspectorDebuggerAgent): Added.
* inspector/JSGlobalObjectConsoleClient.cpp:
(Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
(Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
(Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
* inspector/agents/InspectorDebuggerAgent.h:
(Inspector::InspectorDebuggerAgent::addListener): Added.
(Inspector::InspectorDebuggerAgent::removeListener): Added.
(Inspector::InspectorDebuggerAgent::setListener): Deleted.
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::InspectorDebuggerAgent):
(Inspector::InspectorDebuggerAgent::enable):
(Inspector::InspectorDebuggerAgent::disable):
(Inspector::InspectorDebuggerAgent::getScriptSource):
(Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement):
(Inspector::InspectorDebuggerAgent::didPause):
(Inspector::InspectorDebuggerAgent::breakProgram):
(Inspector::InspectorDebuggerAgent::clearBreakDetails):
Drive-by: reorder some member variables for better sizing.
Drive-by: rename some member variables for clarity.
2019-03-19 Saam barati <sbarati@apple.com>
Prune code after ForceOSRExit
https://bugs.webkit.org/show_bug.cgi?id=195913
Reviewed by Keith Miller.
I removed our original implementation of this in r242989 because
it was not sound. It broke backwards propagation because it removed
uses of a node that backwards propagation relied on to be sound.
Essentially, backwards propagation relies on being able to see uses
that would exist in bytecode to be sound.
The rollout in r242989 was a 1% Speedometer2 regression. This patch
rolls back in the optimization in a sound way.
This patch augments the code we had prior to r242989 to be sound. In
addition to preserving liveness, we now also convert all uses after
the ForceOSRExit to be Phantom. This may pessimize the optimizations
we do in backwards propagation, but it will prevent that phase from
making unsound optimizations.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addToGraph):
(JSC::DFG::ByteCodeParser::parse):
2019-03-19 Michael Catanzaro <mcatanzaro@igalia.com>
Build cleanly with GCC 9
https://bugs.webkit.org/show_bug.cgi?id=195920
Reviewed by Chris Dumez.
WebKit triggers three new GCC 9 warnings:
"""
-Wdeprecated-copy, implied by -Wextra, warns about the C++11 deprecation of implicitly
declared copy constructor and assignment operator if one of them is user-provided.
"""
Solution is to either add a copy constructor or copy assignment operator, if required, or
else remove one if it is redundant.
"""
-Wredundant-move, implied by -Wextra, warns about redundant calls to std::move.
-Wpessimizing-move, implied by -Wall, warns when a call to std::move prevents copy elision.
"""
These account for most of this patch. Solution is to just remove the bad WTFMove().
Additionally, -Wclass-memaccess has been enhanced to catch a few cases that GCC 8 didn't.
These are solved by casting nontrivial types to void* before using memcpy. (Of course, it
would be safer to not use memcpy on nontrivial types, but that's too complex for this
patch. Searching for memcpy used with static_cast<void*> will reveal other cases to fix.)
* b3/B3ValueRep.h:
* bindings/ScriptValue.cpp:
(Inspector::jsToInspectorValue):
* bytecode/GetterSetterAccessCase.cpp:
(JSC::GetterSetterAccessCase::create):
(JSC::GetterSetterAccessCase::clone const):
* bytecode/InstanceOfAccessCase.cpp:
(JSC::InstanceOfAccessCase::clone const):
* bytecode/IntrinsicGetterAccessCase.cpp:
(JSC::IntrinsicGetterAccessCase::clone const):
* bytecode/ModuleNamespaceAccessCase.cpp:
(JSC::ModuleNamespaceAccessCase::clone const):
* bytecode/ProxyableAccessCase.cpp:
(JSC::ProxyableAccessCase::clone const):
* bytecode/StructureSet.h:
* debugger/Breakpoint.h:
* dfg/DFGRegisteredStructureSet.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::buildDebuggerLocation):
* inspector/scripts/codegen/cpp_generator_templates.py:
* parser/UnlinkedSourceCode.h:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::parseAndCompileAir):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::parseAndCompile):
* wasm/WasmNameSectionParser.cpp:
(JSC::Wasm::NameSectionParser::parse):
* wasm/WasmStreamingParser.cpp:
(JSC::Wasm::StreamingParser::consume):
2019-03-19 Saam Barati <sbarati@apple.com>
Style fix: remove C style cast in Instruction.h
https://bugs.webkit.org/show_bug.cgi?id=195917
Reviewed by Filip Pizlo.
* bytecode/Instruction.h:
(JSC::Instruction::wide const):
2019-03-19 Devin Rousso <drousso@apple.com>
Web Inspector: Provide $event in the console when paused on an event listener
https://bugs.webkit.org/show_bug.cgi?id=188672
Reviewed by Timothy Hatcher.
* inspector/InjectedScript.h:
* inspector/InjectedScript.cpp:
(Inspector::InjectedScript::setEventValue): Added.
(Inspector::InjectedScript::clearEventValue): Added.
* inspector/InjectedScriptManager.h:
* inspector/InjectedScriptManager.cpp:
(Inspector::InjectedScriptManager::clearEventValue): Added.
* inspector/InjectedScriptSource.js:
(WI.InjectedScript.prototype.setEventValue): Added.
(WI.InjectedScript.prototype.clearEventValue): Added.
(BasicCommandLineAPI):
2019-03-19 Devin Rousso <drousso@apple.com>
Web Inspector: ScriptProfiler: lazily create the agent
https://bugs.webkit.org/show_bug.cgi?id=195591
<rdar://problem/48791756>
Reviewed by Joseph Pecoraro.
* inspector/JSGlobalObjectConsoleClient.h:
(Inspector::JSGlobalObjectConsoleClient::setInspectorScriptProfilerAgent): Added.
* inspector/JSGlobalObjectConsoleClient.cpp:
(Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
(Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
(Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
(Inspector::JSGlobalObjectInspectorController::createLazyAgents):
2019-03-19 Devin Rousso <drousso@apple.com>
Web Inspector: Heap: lazily create the agent
https://bugs.webkit.org/show_bug.cgi?id=195590
<rdar://problem/48791750>
Reviewed by Joseph Pecoraro.
* inspector/agents/InspectorHeapAgent.h:
* inspector/agents/InspectorHeapAgent.cpp:
(Inspector::InspectorHeapAgent::~InspectorHeapAgent): Deleted.
* inspector/agents/InspectorConsoleAgent.h:
(Inspector::InspectorConsoleAgent::setInspectorHeapAgent): Added.
* inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::InspectorConsoleAgent):
(Inspector::InspectorConsoleAgent::takeHeapSnapshot):
(Inspector::InspectorConsoleAgent::~InspectorConsoleAgent): Deleted.
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
(Inspector::JSGlobalObjectInspectorController::createLazyAgents):
2019-03-19 Caio Lima <ticaiolima@gmail.com>
[JSC] LLIntEntryPoint creates same DirectJITCode for all functions
https://bugs.webkit.org/show_bug.cgi?id=194648
Reviewed by Keith Miller.
1. Making LLIntThunks singleton.
Motivation: Former implementation has one LLIntThunk per type per VM.
However, the generated code for every kind of thunk is essentially the
same and we end up wasting memory (right now jitAllocationGranule = 32 bytes)
when we have 2 or more VM instantiated. Turn these thunks into
singleton will avoid such wasting.
Tradeoff: This change comes with a price, because we will keep thunks
allocated even when there is no VM instantiated. Considering WebCore use case,
the situation of having no VM instantiated is uncommon, since once a
VM is created through `commomVM()`, it will never be destroyed. Given
that, this change does not impact the overall memory comsumption of
WebCore/JSC. It also doesn't impact memory footprint, since thunks are
generated lazily (see results below).
Since we are keeping a static `MacroAssemblerCodeRef<JITThunkPtrTag>`,
we have the assurance that JITed code will never be deallocated,
given it is being pointed by `RefPtr<ExecutableMemoryHandle> m_executableMemory`.
To understand why we decided to make LLIntThunks singleton instead of
removing them, please see the comment on `llint/LLIntThunks.cpp`.
2. Making all LLIntEntrypoints singleton
Motivation: With singleton LLIntThunks, we also can have singleton
DirectJITCodes and NativeJITCodes for each LLIntEntrypoint type and
avoid multiple allocations of objects with the same content.
Tradeoff: As explained before, once we allocate an entrypoint, it
will be alive until the program exits. However, the gains we can
achieve in some use cases justifies such allocations.
As DirectJITCode and NativeJITCode are ThreadSafeRefCounted and we are using
`codeBlock->setJITCode(makeRef(*jitCode))`, their reference counter
will never be less than 1.
3. Memory usage analysis
This change reduces memory usage on stress/generate-multiple-llint-entrypoints.js
by 2% and is neutral on JetStream 2. Following results were generated
running each benchmark 6 times and using 95% Student's t distribution
confidence interval.
microbenchmarks/generate-multiple-llint-entrypoints.js (Changes uses less memory):
Mean of memory peak on ToT: 122576896 bytes (confidence interval: 67747.2316)
Mean of memory peak on Changes: 119248213.33 bytes (confidence interval: 50251.2718)
JetStream2 (Neutral):
Mean of memory peak on ToT: 5442742272 bytes (confidence interval: 134381565.9117)
Mean of memory peak on Changes: 5384949760 bytes (confidence interval: 158413904.8352)
4. Performance Analysis
This change is performance neutral on JetStream 2 and Speedometer 2.
See results below.:
JetStream 2 (Neutral):
Mean of score on ToT: 139.58 (confidence interval: 2.44)
Mean of score on Changes: 141.46 (confidence interval: 4.24)
Speedometer run #1
ToT: 110 +- 2.9
Changes: 110 +- 1.8
Speedometer run #2
ToT: 110 +- 1.6
Changes: 108 +- 2.3
Speedometer run #3
ToT: 110 +- 3.0
Changes: 110 +- 1.4
* jit/JSInterfaceJIT.h:
(JSC::JSInterfaceJIT::JSInterfaceJIT):
* llint/LLIntEntrypoint.cpp:
Here we are changing the usage or DirectJITCode by NativeJITCode on cases
where there is no difference from address of calls with and without
ArithCheck.
(JSC::LLInt::setFunctionEntrypoint):
(JSC::LLInt::setEvalEntrypoint):
(JSC::LLInt::setProgramEntrypoint):
(JSC::LLInt::setModuleProgramEntrypoint):
(JSC::LLInt::setEntrypoint):
* llint/LLIntEntrypoint.h:
* llint/LLIntThunks.cpp:
(JSC::LLInt::generateThunkWithJumpTo):
(JSC::LLInt::functionForCallEntryThunk):
(JSC::LLInt::functionForConstructEntryThunk):
(JSC::LLInt::functionForCallArityCheckThunk):
(JSC::LLInt::functionForConstructArityCheckThunk):
(JSC::LLInt::evalEntryThunk):
(JSC::LLInt::programEntryThunk):
(JSC::LLInt::moduleProgramEntryThunk):
(JSC::LLInt::functionForCallEntryThunkGenerator): Deleted.
(JSC::LLInt::functionForConstructEntryThunkGenerator): Deleted.
(JSC::LLInt::functionForCallArityCheckThunkGenerator): Deleted.
(JSC::LLInt::functionForConstructArityCheckThunkGenerator): Deleted.
(JSC::LLInt::evalEntryThunkGenerator): Deleted.
(JSC::LLInt::programEntryThunkGenerator): Deleted.
(JSC::LLInt::moduleProgramEntryThunkGenerator): Deleted.
* llint/LLIntThunks.h:
* runtime/ScriptExecutable.cpp:
(JSC::setupLLInt):
(JSC::ScriptExecutable::prepareForExecutionImpl):
2019-03-18 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add missing exception checks revealed by newly added exception checks, follow-up after r243081
https://bugs.webkit.org/show_bug.cgi?id=195927
Reviewed by Mark Lam.
r243081 adds more exception checks which are previously missing, and it reveals missing exception checks in the caller.
This patch is a follow-up patch after r243081, adding missing exception checks more to fix debug test failures.
* runtime/RegExpConstructor.cpp:
(JSC::setRegExpConstructorInput):
(JSC::setRegExpConstructorMultiline):
* runtime/RegExpGlobalData.cpp:
(JSC::RegExpGlobalData::getBackref):
(JSC::RegExpGlobalData::getLastParen):
2019-03-18 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Generator should not create JSLexicalEnvironment if it is not necessary
https://bugs.webkit.org/show_bug.cgi?id=195901
Reviewed by Saam Barati.
It is not rare that generators do not need to have any registers to be suspended and resumed.
Since currently we always emit op_create_lexical_environment for generator code, we sometimes
create empty JSLexicalEnvironment while it is not required. We can see that a lot of empty JSLexicalEnvironment
are allocated in RAMification's Basic test.
This patch removes this unnecessary allocation. We introduce op_create_generator_frame_environment, which is
a marker, similar to op_yield. And generatorification phase decides whether we should actually emit op_create_lexical_environment,
based on the result of the analysis in generatorification. This can remove unnecessary JSLexicalEnvironment allocations.
We run RAMification in 6 times, use average of them.
RAMification's Basic in JIT mode shows 1.4% improvement.
ToT
Current: 55076864.00, Peak: 55080960.00
Patched
Current: 54325930.67, Peak: 54329344.00
RAMification's Basic in non-JIT mode shows 5.0% improvement.
ToT
Current: 12485290.67, Peak: 12485290.67
Patched
Current: 11894101.33, Peak: 11894101.33
* bytecode/BytecodeGeneratorification.cpp:
(JSC::BytecodeGeneratorification::BytecodeGeneratorification):
(JSC::BytecodeGeneratorification::generatorFrameData const):
(JSC::BytecodeGeneratorification::run):
* bytecode/BytecodeList.rb:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* llint/LowLevelInterpreter.asm:
2019-03-18 Robin Morisset <rmorisset@apple.com>
Remove the inline capacity of Operands
https://bugs.webkit.org/show_bug.cgi?id=195898
Reviewed by Yusuke Suzuki.
Operands currently has a vector with an inline capacity of 24.
I tested on JetStream2, and only 4776 functions out of 12035 (that reach the DFG tier) have 24 or fewer elements in it.
This is a major problem, because we have 5 Operands in every DFG::BasicBlock, resulting in 2688 bytes of inline capacity per basic block.
Still on JetStream 2, functions have an average of 18 BB, but those functions whose operands overflow have an average of 27 BB (so we are wasting 72kB on average when compiling them), and the largest function has 1241 BB (!), for a total of 3.3MB being wasted while it is compiled.
So I removed the inline capacity of the vector in Operands, and here are the results:
Baseline Jetstream2:
159.741
159.746
159.989
Baseline RAMification on grouped and jit tests: (end/peak/score)
89.288/89.763/89.526
90.166/90.761/90.418
89.560/90.014/89.787
After optimization Jetstream2:
159.342
161.812
162.037
After optimization RAMification:
89.147/89.644/89.395
89.102.89.585/89.343
88.953/89.536/89.2444
So it looks like a roughly 1% improvement on RAMification (at least the tests where the JIT is enabled), and more surprisingly also a 1% progression on Jetstream2 (although I have more doubts about this one considering the variability in my numbers).
I hope to land this, and get more accurate results from the bots.
* bytecode/Operands.h:
2019-03-18 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add --destroy-vm shell option and dumpHeapStatisticsAtVMDestruction option
https://bugs.webkit.org/show_bug.cgi?id=195897
Reviewed by Keith Miller.
It is useful if we have an option logging the status of all the existing MarkedBlocks and their objects at VM destruction.
I used this feature to find wasting memory, and successfully removed many wasted MarkedBlocks and JS cells like r243081.
This patch adds,
1. --destroy-vm option to JSC shell to destroy main thread JSC::VM
2. dumpHeapStatisticsAtVMDestruction to dump MarkedBlocks at VM destruction
While the current option name is "dumpHeapStatisticsAtVMDestruction", we just dump the status of MarkedBlocks and cells. But eventually,
we would like to collect heap statistics and dump them to investigate Heap status more.
This patch also removes logHeapStatisticsAtExit option since it is no longer used in JSC.
* heap/Heap.cpp:
(JSC::Heap::dumpHeapStatisticsAtVMDestruction):
(JSC::Heap::lastChanceToFinalize):
* heap/Heap.h:
* jsc.cpp:
(printUsageStatement):
(CommandLine::parseArguments):
(runJSC):
* runtime/Options.h:
2019-03-18 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] jsSubstring should resolve rope before calling JSRopeString::create
https://bugs.webkit.org/show_bug.cgi?id=195840
Reviewed by Geoffrey Garen.
jsSubstring always ends up resolving rope of the base string because substring JSRopeString only accepts non-rope JSString
as its base. Instead of resolving ropes in finishCreationSubstring, we should resolve before passing it to JSRopeString.
So that, we can access string data before creating JSRopeString, and we can introduce optimizations like avoiding creation
of single character substrings.
We can find that a lot of substrings for length = 1 are allocated in RAMification regexp tests. This patch avoids creation of these
strings to save memory.
This patch also strengthen error checks caused by rope resolution for base of substrings. Previously we sometimes miss this checks.
* dfg/DFGOperations.cpp:
* runtime/JSString.cpp:
(JSC::JSString::dumpToStream):
* runtime/JSString.h:
(JSC::jsSubstring):
(JSC::jsSubstringOfResolved):
(JSC::jsSingleCharacterString):
* runtime/RegExpCachedResult.cpp:
(JSC::RegExpCachedResult::lastResult): We no longer need to have length = 0 path since jsSubstring returns an empty string if length == 0.
(JSC::RegExpCachedResult::leftContext):
(JSC::RegExpCachedResult::rightContext):
(JSC::RegExpCachedResult::setInput):
* runtime/RegExpGlobalData.cpp:
(JSC::RegExpGlobalData::getBackref):
(JSC::RegExpGlobalData::getLastParen):
* runtime/StringObject.h:
(JSC::jsStringWithReuse):
(JSC::jsSubstring):
* runtime/StringPrototype.cpp:
(JSC::replaceUsingRegExpSearch):
(JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
(JSC::replaceUsingStringSearch):
(JSC::stringProtoFuncSlice):
(JSC::splitStringByOneCharacterImpl):
(JSC::stringProtoFuncSplitFast):
(JSC::stringProtoFuncSubstr):
(JSC::stringProtoFuncSubstring):
(JSC::stringProtoFuncToLowerCase):
(JSC::stringProtoFuncToUpperCase):
Some `const String& value = string->value(exec)` is dangerous if GC happens later. Changed to getting `String` instead of `const String&` here.
* runtime/StringPrototypeInlines.h:
(JSC::stringSlice):
2019-03-18 Mark Lam <mark.lam@apple.com>
Missing a ThrowScope release in JSObject::toString().
https://bugs.webkit.org/show_bug.cgi?id=195893
<rdar://problem/48970986>
Reviewed by Michael Saboff.
Placate the validator with a RELEASE_AND_RETURN().
* runtime/JSObject.cpp:
(JSC::JSObject::toString const):
2019-03-18 Mark Lam <mark.lam@apple.com>
Structure::flattenDictionary() should clear unused property slots.
https://bugs.webkit.org/show_bug.cgi?id=195871
<rdar://problem/48959497>
Reviewed by Michael Saboff.
It currently attempts to do this but fails because it's actually clearing up the
preCapacity region instead. The fix is simply to account for the preCapacity
when computing the start address of the property slots.
* runtime/Structure.cpp:
(JSC::Structure::flattenDictionaryStructure):
2019-03-18 Robin Morisset <rmorisset@apple.com>
B3 should reduce Shl(<S|Z>Shr(@x, @const), @const) to BitAnd(@x, -(1<<@const))
https://bugs.webkit.org/show_bug.cgi?id=152164
Reviewed by Filip Pizlo.
Turn this: Shl(<S|Z>Shr(@x, @const), @const)
Into this: BitAnd(@x, -(1<<@const))
I added two tests: one for ZShr/32 bits, and one for SShr/64 bits, I think it is enough coverage (no reason for any interaction between the signedness of the shift and the bitwidth).
I also modified a few adjacent tests to remove undefined behaviours.
* b3/B3ReduceStrength.cpp:
* b3/testb3.cpp:
(JSC::B3::testShlImms):
(JSC::B3::testShlArgImm):
(JSC::B3::testShlSShrArgImm):
(JSC::B3::testShlImms32):
(JSC::B3::testShlArgImm32):
(JSC::B3::testShlZShrArgImm32):
(JSC::B3::run):
2019-03-17 Robin Morisset <rmorisset@apple.com>
ParserError can be shrunk by 8 bytes
https://bugs.webkit.org/show_bug.cgi?id=195496
Reviewed by Mark Lam.
* parser/ParserError.h:
2019-03-17 Diego Pino Garcia <dpino@igalia.com>
Fix WPE and GTK Debug builds after r243049
https://bugs.webkit.org/show_bug.cgi?id=195860
Unreviewed, build fix after r243049.
* runtime/StringPrototype.cpp:
(JSC::normalizationAffects8Bit):
2019-03-17 Yusuke Suzuki <ysuzuki@apple.com>
REGRESSION: !vm.isInitializingObject() void* JSC::tryAllocateCellHelper<JSC::Structure> JSC::Structure::create
https://bugs.webkit.org/show_bug.cgi?id=195858
Reviewed by Mark Lam.
r243011 changed WebAssembly related structures lazily-allocated. It means that this lazy allocation must not be done in the middle of
the other object allocations. This patch changes the signature of wasm related objects' ::create functions to taking Structure*.
This prevents us from materializing lazily-allocated structures while allocating wasm related objects, and this style is used in the
other places to fix the same problem. This bug is caught by existing debug tests for wasm.
* runtime/JSGlobalObject.h:
* wasm/js/JSWebAssemblyCompileError.cpp:
(JSC::createJSWebAssemblyCompileError):
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::finalizeCreation):
(JSC::JSWebAssemblyInstance::create):
* wasm/js/JSWebAssemblyLinkError.cpp:
(JSC::createJSWebAssemblyLinkError):
* wasm/js/JSWebAssemblyModule.cpp:
(JSC::JSWebAssemblyModule::createStub):
(JSC::JSWebAssemblyModule::finishCreation):
* wasm/js/WasmToJS.cpp:
(JSC::Wasm::wasmToJSException):
* wasm/js/WebAssemblyCompileErrorConstructor.cpp:
(JSC::constructJSWebAssemblyCompileError):
(JSC::callJSWebAssemblyCompileError):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::create):
* wasm/js/WebAssemblyFunction.h:
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance):
* wasm/js/WebAssemblyLinkErrorConstructor.cpp:
(JSC::constructJSWebAssemblyLinkError):
(JSC::callJSWebAssemblyLinkError):
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::constructJSWebAssemblyMemory):
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::WebAssemblyModuleConstructor::createModule):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
(JSC::WebAssemblyModuleRecord::evaluate):
* wasm/js/WebAssemblyPrototype.cpp:
(JSC::webAssemblyModuleValidateAsyncInternal):
(JSC::instantiate):
(JSC::compileAndInstantiate):
(JSC::webAssemblyModuleInstantinateAsyncInternal):
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
(JSC::constructJSWebAssemblyRuntimeError):
(JSC::callJSWebAssemblyRuntimeError):
* wasm/js/WebAssemblyTableConstructor.cpp:
(JSC::constructJSWebAssemblyTable):
* wasm/js/WebAssemblyToJSCallee.cpp:
(JSC::WebAssemblyToJSCallee::create):
* wasm/js/WebAssemblyToJSCallee.h:
* wasm/js/WebAssemblyWrapperFunction.cpp:
(JSC::WebAssemblyWrapperFunction::create):
* wasm/js/WebAssemblyWrapperFunction.h:
2019-03-16 Darin Adler <darin@apple.com>
Improve normalization code, including moving from unorm.h to unorm2.h
https://bugs.webkit.org/show_bug.cgi?id=195330
Reviewed by Michael Catanzaro.
* runtime/JSString.h: Move StringViewWithUnderlyingString to StringView.h.
* runtime/StringPrototype.cpp: Include unorm2.h instead of unorm.h.
(JSC::normalizer): Added. Function to create normalizer object given
enumeration value indicating which is selected. Simplified because we
know the function will not fail and so we don't need error handling code.
(JSC::normalize): Changed this function to take a JSString* so we can
optimize the case where no normalization is needed. Added an early exit
if the string is stored as 8-bit and another if the string is already
normalized, using unorm2_isNormalized. Changed error handling to only
check cases that can actually fail in practice. Also did other small
optimizations like passing VM rather than ExecState.
(JSC::stringProtoFuncNormalize): Used smaller enumeration names that are
identical to the names used in the API and normalization parlance rather
than longer ones that expand the acronyms. Updated to pass JSString* to
the normalize function, so we can optimize 8-bit and already-normalized
cases, rather than callling the expensive String::upconvertedCharacters
function. Use throwVMRangeError.
2019-03-15 Mark Lam <mark.lam@apple.com>
Need to check ObjectPropertyCondition liveness before accessing it when firing watchpoints.
https://bugs.webkit.org/show_bug.cgi?id=195827
<rdar://problem/48845513>
Reviewed by Filip Pizlo.
m_object in ObjectPropertyCondition may no longer be live by the time the watchpoint fires.
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
(JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
* bytecode/ObjectPropertyCondition.cpp:
(JSC::ObjectPropertyCondition::dumpInContext const):
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::fireInternal):
* dfg/DFGAdaptiveStructureWatchpoint.cpp:
(JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
* runtime/StructureRareData.cpp:
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
2019-03-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Make more properties lazily-allocated in JSGlobalObject, including properties only used in JIT mode
https://bugs.webkit.org/show_bug.cgi?id=195816
Reviewed by Michael Saboff.
This patch makes more properties lazily-allocated in JSGlobalObject. This patch makes the following lazily-allocated.
1. iteratorResultObjectStructure
2. WebAssembly related objects except for JSWebAssembly top-level object.
* CMakeLists.txt:
* DerivedSources-input.xcfilelist:
* DerivedSources-output.xcfilelist:
* DerivedSources.make:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::iteratorResultObjectStructure const):
(JSC::JSGlobalObject::webAssemblyModuleRecordStructure const):
(JSC::JSGlobalObject::webAssemblyFunctionStructure const):
(JSC::JSGlobalObject::webAssemblyWrapperFunctionStructure const):
(JSC::JSGlobalObject::webAssemblyToJSCalleeStructure const):
* wasm/js/JSWebAssembly.cpp:
* wasm/js/JSWebAssembly.h:
2019-03-15 Dominik Infuehr <dinfuehr@igalia.com>
[CMake] Move test .js files into testapiScripts
https://bugs.webkit.org/show_bug.cgi?id=195565
Reviewed by Yusuke Suzuki.
testapi expect .js file in the testapiScripts-directory.
* shell/CMakeLists.txt:
2019-03-15 Mark Lam <mark.lam@apple.com>
Gardening: add a missing exception check after r242991.
https://bugs.webkit.org/show_bug.cgi?id=195791
Unreviewed.
* tools/JSDollarVM.cpp:
(JSC::functionGetGetterSetter):
2019-03-15 Devin Rousso <drousso@apple.com>
Web Inspector: provide a way to capture a screenshot of a node from within the page
https://bugs.webkit.org/show_bug.cgi?id=194279
<rdar://problem/10731573>
Reviewed by Joseph Pecoraro.
Add `console.screenshot` functionality, which displays a screenshot of a given object (if
able) within Web Inspector's Console tab. From there, it can be viewed and saved.
Currently, `console.screenshot` will
- capture an image of a `Node` (if provided)
- capture an image of the viewport if nothing is provided
* inspector/protocol/Console.json:
Add `Image` enum value to `ConsoleMessage` type.
* runtime/ConsoleTypes.h:
* inspector/ConsoleMessage.h:
* inspector/ConsoleMessage.cpp:
(Inspector::messageTypeValue):
* runtime/ConsoleClient.h:
* runtime/ConsoleObject.cpp:
(JSC::ConsoleObject::finishCreation):
(JSC::consoleProtoFuncScreenshot): Added.
* inspector/JSGlobalObjectConsoleClient.h:
* inspector/JSGlobalObjectConsoleClient.cpp:
(Inspector::JSGlobalObjectConsoleClient::screenshot): Added.
2019-03-14 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Retain PrivateName of Symbol before passing it to operations potentially incurring GC
https://bugs.webkit.org/show_bug.cgi?id=195791
<rdar://problem/48806130>
Reviewed by Mark Lam.
Consider the following example:
void putByVal(JSObject*, PropertyName propertyName, ...);
putByVal(object, symbol->privateName(), ...);
PropertyName does not retain the passed UniquedStringImpl*. It just holds the pointer to UniquedStringImpl*.
It means that since `Symbol::privateName()` returns `const PrivateName&` instead of `PrivateName`, putByVal
and its caller does not retain UniquedStringImpl* held in PropertyName. The problem happens when the putByVal
incurs GC, and when the `symbol` is missing in the conservative GC scan. The underlying UniquedStringImpl* of
PropertyName can be accidentally destroyed in the middle of the putByVal operation. We should retain PrivateName
before passing it to operations which takes it as PropertyName.
1. We use the code pattern like this.
auto propertyName = symbol->privateName();
someOperation(..., propertyName);
This pattern is well aligned to existing `JSValue::toPropertyKey(exec)` and `JSString::toIdentifier(exec)` code patterns.
auto propertyName = value.toPropertyKey(exec);
RETURN_IF_EXCEPTION(scope, { });
someOperation(..., propertyName);
2. We change `Symbol::privateName()` to returning `PrivateName` instead of `const PrivateName&` to avoid
potential dangerous use cases. This is OK because the code using `Symbol::privateName()` is not a critical path,
and they typically need to retain PrivateName.
3. We audit similar functions `toPropertyKey(exec)` and `toIdentifier(exec)` for needed but missing exception checks.
BTW, these functions are safe to the problem fixed in this patch since they return `Identifier` instead
of `const Identifier&`.
Mark and Robin investigated and offered important data to understand what went wrong. And figured out the reason behind
the mysterious behavior shown in the data, and now, we confirm that this is the right fix for this bug.
* dfg/DFGOperations.cpp:
* jit/JITOperations.cpp:
(JSC::tryGetByValOptimize):
* runtime/JSFunction.cpp:
(JSC::JSFunction::setFunctionName):
* runtime/JSModuleLoader.cpp:
(JSC::printableModuleKey):
* runtime/JSONObject.cpp:
(JSC::Stringifier::Stringifier):
* runtime/Symbol.cpp:
(JSC::Symbol::descriptiveString const):
(JSC::Symbol::description const):
* runtime/Symbol.h:
* runtime/SymbolConstructor.cpp:
(JSC::symbolConstructorKeyFor):
* tools/JSDollarVM.cpp:
(JSC::functionGetGetterSetter):
2019-03-14 Yusuke Suzuki <ysuzuki@apple.com>
REGRESSION(r242841): Fix conservative DFG OSR entry validation to accept values which will be stored in AnyInt / Double flush formats
https://bugs.webkit.org/show_bug.cgi?id=195752
Reviewed by Saam Barati.
We fixed the bug skipping AbstractValue validations when the flush format is Double or AnyInt. But it
was too conservative. While validating inputs with AbstractValue is mandatory (without it, whole CFA
falls into wrong condition), our validation does not care AnyInt and Double representations in lower
tiers. For example, if a value is stored in Double flush format in DFG, its AbstractValue becomes
SpecFullDouble. However, it does not include Int32 and OSR entry is rejected if Int32 comes for DoubleRep
OSR entry value. This is wrong since we later convert these numbers into DoubleRep representation
before entering DFG code.
This patch performs AbstractValue validation onto the correctly converted value with flush format hint.
And it still does not fix OSR entry failures in navier-stokes. This is because AbstractValue representation
in navier-stokes's lin_solve was too strict. Then, this patch reverts r242627. Instead of removing must handle
value handling in CFA, DFG OSR entry now correctly validates inputs with AbstractValues even if the flush format
is Double or AnyInt. As long as DFG OSR entry validates inputs, merging must handle values as proven constants is OK.
We can see that # of OSR entry failures in navier-stokes.js becomes the same to the previous count. And we can see
AnyInt OSR entry actually works in microbenchmarks/large-int.js. However, AnyInt effect is hard to observe because this
is super rare. Since we inject type prediction based on must handle value, the flush format tends to be SpecAnyIntAsDouble
and it accepts JSValues simply.
* bytecode/SpeculatedType.cpp:
(JSC::dumpSpeculation):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::filterValueByType):
* dfg/DFGAbstractValue.h:
(JSC::DFG::AbstractValue::validateOSREntryValue const):
(JSC::DFG::AbstractValue::validateTypeAcceptingBoxedInt52 const):
(JSC::DFG::AbstractValue::validate const): Deleted.
(JSC::DFG::AbstractValue::validateType const): Deleted.
* dfg/DFGCFAPhase.cpp:
(JSC::DFG::CFAPhase::run):
(JSC::DFG::CFAPhase::injectOSR):
(JSC::DFG::CFAPhase::performBlockCFA):
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareOSREntry):
2019-03-14 Saam barati <sbarati@apple.com>
We can't remove code after ForceOSRExit until after FixupPhase
https://bugs.webkit.org/show_bug.cgi?id=186916
<rdar://problem/41396612>
Reviewed by Yusuke Suzuki.
There was an optimization in the bytecode parser I added in r232742 that converted blocks
with ForceOSRExit in them to remove all IR after the ForceOSRExit. However,
this is incorrect because it breaks backwards propagation. For example, it
could incorrectly lead us to think it's safe to not check for overflow in
an Add because such Add has no non-int uses. Backwards propagation relies on
having a view over bytecode uses, and this optimization broke that. This patch
rolls out that optimization, as initial perf data shows it may no longer be
needed.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addToGraph):
(JSC::DFG::ByteCodeParser::parse):
2019-03-14 Saam barati <sbarati@apple.com>
JSScript should have an accessor saying if it's cached or not
https://bugs.webkit.org/show_bug.cgi?id=195783
Reviewed by Michael Saboff.
* API/JSScript.h:
* API/JSScript.mm:
(-[JSScript isUsingBytecodeCache]):
* API/tests/testapi.mm:
(testIsUsingBytecodeCacheAccessor):
(testObjectiveCAPI):
2019-03-14 Saam barati <sbarati@apple.com>
Remove retain cycle from JSScript and also don't keep the cache file descriptor open so many JSScripts can be cached in a loop
https://bugs.webkit.org/show_bug.cgi?id=195782
<rdar://problem/48880625>
Reviewed by Michael Saboff.
This patch fixes two issues with JSScript API:
1. There was a retain cycle causing us to never destroy a JSScript once it
created a JSSourceCode. The reason for this is that JSScript had a
Strong<JSSourceCode> field. And JSSourceCode transitively had RetainPtr<JSScript>.
This patch fixes this issue by making the "jsSourceCode" accessor return a transient object.
2. r242585 made it so that JSScript would keep the cache file descriptor open
(and locked) for the duration of the lifetime of the JSScript itself. Our
anticipation here is that it would make implementing iterative cache updates
easier. However, this made using the API super limiting in other ways. For
example, if a program had a loop that cached 3000 different JSScripts, it's
likely that such a program would exhaust the open file count limit. This patch
reverts to the behavior prior to r242585 where we just keep open the file descriptor
while we read or write it.
* API/JSAPIGlobalObject.mm:
(JSC::JSAPIGlobalObject::moduleLoaderFetch):
* API/JSContext.mm:
(-[JSContext evaluateJSScript:]):
* API/JSScript.mm:
(-[JSScript dealloc]):
(-[JSScript readCache]):
(-[JSScript init]):
(-[JSScript sourceCode]):
(-[JSScript jsSourceCode]):
(-[JSScript writeCache:]):
(-[JSScript forceRecreateJSSourceCode]): Deleted.
* API/JSScriptInternal.h:
* API/tests/testapi.mm:
(testCanCacheManyFilesWithTheSameVM):
(testObjectiveCAPI):
(testCacheFileIsExclusive): Deleted.
2019-03-14 Michael Saboff <msaboff@apple.com>
ASSERTION FAILED: regexp->isValid() or ASSERTION FAILED: !isCompilationThread()
https://bugs.webkit.org/show_bug.cgi?id=195735
Reviewed by Mark Lam.
There are two bug fixes here.
The first bug happens due to a race condition when we are compiling on a separate thread while the
main thread is compiling the RegExp at a place where it can run out of stack. When that happens,
the RegExp becomes invalid due to the out of stack error. If we check the ASSERT condition in the DFG
compilation thread, we crash. After the main thread throws an exception, it resets the RegExp as
it might compile successfully the next time we try to execute it on a shallower stack.
The main thread will see the regular expression as valid when it executes the JIT'ed code we are compiling
or any slow path we call out to. Therefore ASSERTs like this in compilation code can be eliminated.
The second bug is due to incorrect logic when we go to run the regexp in the Strength Reduction phase.
The current check for "do we have code to run the RegExp?" only checks that the RegExp's state
is != NotCompiled. We also can't run the RegExp if there the state is ParseError.
Changing hasCode() to take this into account fixes the second issue.
(JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
* runtime/RegExp.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewRegexp):
* runtime/RegExp.h:
2019-03-14 Saam barati <sbarati@apple.com>
Fixup uses KnownInt32 incorrectly in some nodes
https://bugs.webkit.org/show_bug.cgi?id=195279
<rdar://problem/47915654>
Reviewed by Yusuke Suzuki.
Fixup was sometimes using KnownInt32 edges when it knew some
incoming value is an Int32 based on what the bytecode would return.
However, because bytecode may result in Int32 for some node does
not mean we'll pick Int32 as the value format for that local. For example,
we may choose for a value to be represented as a double. This patch
corrects such uses of KnownInt32.
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArrayPush):
(JSC::DFG::SpeculativeJIT::compileGetDirectPname):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileArrayPush):
2019-03-14 Keith Miller <keith_miller@apple.com>
DFG liveness can't skip tail caller inline frames
https://bugs.webkit.org/show_bug.cgi?id=195715
<rdar://problem/46221598>
Reviewed by Saam Barati.
In order to simplify OSR exit/DFG bytecode parsing our bytecode
generator always emits an op_ret after any tail call. However, the
DFG when computing the liveness of locals, would skip any tail
caller inline frames. This mean that if we ended up inserting a
Check that would OSR to the op_ret we wouldn't have kept
availability data around for it.
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::isLiveInBytecode):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::forAllLocalsLiveInBytecode):
2019-03-14 Robin Morisset <rmorisset@apple.com>
DFG::Worklist can be shrunk by 16 bytes
https://bugs.webkit.org/show_bug.cgi?id=195490
Reviewed by Darin Adler.
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::Worklist):
* dfg/DFGWorklist.h:
2019-03-14 Devin Rousso <drousso@apple.com>
Web Inspector: Audit: provide a way to get the contents of resources
https://bugs.webkit.org/show_bug.cgi?id=195266
<rdar://problem/48550911>
Reviewed by Joseph Pecoraro.
* inspector/InjectedScriptBase.cpp:
(Inspector::InjectedScriptBase::makeAsyncCall):
Drive-by: fix missing `else`.
2019-03-14 Devin Rousso <drousso@apple.com>
Web Inspector: Styles: `::-webkit-scrollbar*` rules aren't shown
https://bugs.webkit.org/show_bug.cgi?id=195123
<rdar://problem/48450148>
Reviewed by Joseph Pecoraro.
* inspector/protocol/CSS.json:
Add `CSS.PseudoId` enum, rather than send a number, so that we have more knowledge about
which pseudo type the rule corresponds to (e.g. a string is more descriptive than a number).
2019-03-13 Caio Lima <ticaiolima@gmail.com>
[JSC] CodeBlock::visitChildren is reporting extra memory even when its JITCode is singleton
https://bugs.webkit.org/show_bug.cgi?id=195638
Reviewed by Mark Lam.
This patch introduces a m_isShared flag to track whether the
JITCode is shared between many CodeBlocks. This flag is used in
`CodeBlock::setJITCode` and `CodeBlock::visitChildren` to avoid
reporting duplicated extra memory for singleton JITCodes.
With those changes, we now stop counting singleton LLIntEntrypoints
as extra memory, since they are declared as static variables. This
change can potentially avoid unecessary GC pressure, because
extra memory is used by Heap::updateAllocationLimits() to update Heap
limits.
Even though it is hard to show performance difference for this change
(see results below), it is important to keep extra memory usage
correct. Otherwise, it can be a source of a complicated bug on
GC in the future.
Results from last run of Speedometer 2 comparing ToT and changes. We
collected those numbers running Minibrowser on a MacBook Pro 15-inch
with 2,6 GHz Intel Core i7. Both versions are with JIT disabled,
since these singleton JITCode are only used by this configuration:
Speedometer2 Run #1
ToT: 58.2 +- 1.1
changes: 57.9 +- 0.99
Speedometer2 Run #2
ToT: 58.5 +- 1.7
changes: 58.0 +- 1.5
Speedometer2 Run #2
ToT: 58.5 +- 0.99
changes: 57.1 +- 1.5
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::estimatedSize):
(JSC::CodeBlock::visitChildren):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::setJITCode):
* jit/JITCode.cpp:
(JSC::JITCode::JITCode):
(JSC::JITCodeWithCodeRef::JITCodeWithCodeRef):
(JSC::DirectJITCode::DirectJITCode):
(JSC::NativeJITCode::NativeJITCode):
* jit/JITCode.h:
(JSC::JITCode::isShared const):
* llint/LLIntEntrypoint.cpp:
(JSC::LLInt::setFunctionEntrypoint):
(JSC::LLInt::setEvalEntrypoint):
(JSC::LLInt::setProgramEntrypoint):
(JSC::LLInt::setModuleProgramEntrypoint):
2019-03-13 Keith Rollin <krollin@apple.com>
Add support for new StagedFrameworks layout
https://bugs.webkit.org/show_bug.cgi?id=195543
Reviewed by Alexey Proskuryakov.
When creating the WebKit layout for out-of-band Safari/WebKit updates,
use an optional path prefix when called for.
* Configurations/Base.xcconfig:
2019-03-13 Mark Lam <mark.lam@apple.com>
Remove unneeded --tradeDestructorBlocks option.
https://bugs.webkit.org/show_bug.cgi?id=195698
<rdar://problem/39681388>
Reviewed by Yusuke Suzuki.
There's no reason why we would ever want --tradeDestructorBlocks to be false.
Also, there was an assertion in BlockDirectory::endMarking() for when
(!Options::tradeDestructorBlocks() && needsDestruction()). This assertion is
outdated because the BlockDirectory's m_empty set used to mean the set of all
blocks that have no live (as in not reachable by GC) objects and dead objects
also do not require destructors to be called on them. The current meaning of
m_empty is that it is the set of all blocks that have no live objects,
independent of whether they needs destructors to be called on them or not.
The assertion is no longer valid for the new meaning of m_empty as m_empty may
now contain destructible blocks. This assertion is now removed as part of this
patch.
* heap/BlockDirectory.cpp:
(JSC::BlockDirectory::endMarking):
* heap/LocalAllocator.cpp:
(JSC::LocalAllocator::tryAllocateWithoutCollecting):
* runtime/Options.h:
2019-03-13 Dominik Infuehr <dinfuehr@igalia.com>
String overflow when using StringBuilder in JSC::createError
https://bugs.webkit.org/show_bug.cgi?id=194957
Reviewed by Mark Lam.
StringBuilder in notAFunctionSourceAppender didn't check
for overflows but just failed.
* runtime/ExceptionHelpers.cpp:
(JSC::notAFunctionSourceAppender):
2019-03-11 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Move species watchpoint installation from ArrayPrototype to JSGlobalObject
https://bugs.webkit.org/show_bug.cgi?id=195593
Reviewed by Keith Miller.
This patch moves watchpoints installation and watchpoints themselves from ArrayPrototype to JSGlobalObject because of the following two reasons.
1. ArrayPrototype configures finalizer because of std::unique_ptr<> for watchpoints. If we move them from ArrayPrototype to JSGlobalObject, we do
not need to set finalizer. And we can avoid unnecessary WeakBlock allocation.
2. This code lazily configures watchpoints instead of setting watchpoints eagerly in JSGlobalObject::init. We would like to expand this mechanism
to other watchpoints which are eagerly configured in JSGlobalObject::init. Putting these code in JSGlobalObject instead of scattering them in
each XXXPrototype / XXXConstructor can encourage the reuse of the code.
* runtime/ArrayPrototype.cpp:
(JSC::ArrayPrototype::create):
(JSC::speciesWatchpointIsValid):
(JSC::ArrayPrototype::destroy): Deleted.
(JSC::ArrayPrototype::tryInitializeSpeciesWatchpoint): Deleted.
(JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::ArrayPrototypeAdaptiveInferredPropertyWatchpoint): Deleted.
(JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire): Deleted.
* runtime/ArrayPrototype.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::tryInstallArraySpeciesWatchpoint): Instead of using ArrayPrototypeAdaptiveInferredPropertyWatchpoint,
we use ObjectPropertyChangeAdaptiveWatchpoint. We create watchpoints after touching WatchpointSet since ObjectPropertyChangeAdaptiveWatchpoint
requires WatchpointSet is IsWatched state.
* runtime/JSGlobalObject.h:
2019-03-12 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] OSR entry should respect abstract values in addition to flush formats
https://bugs.webkit.org/show_bug.cgi?id=195653
Reviewed by Mark Lam.
Let's consider the following graph.
Block #0
...
27:< 2:loc13> JSConstant(JS|UseAsOther, StringIdent, Strong:String (atomic) (identifier): , StructureID: 42679, bc#10, ExitValid)
...
28:< 2:loc13> ArithPow(DoubleRep:@437<Double>, Int32:@27, Double|UseAsOther, BytecodeDouble, Exits, bc#10, ExitValid)
29:<!0:-> MovHint(DoubleRep:@28<Double>, MustGen, loc7, W:SideState, ClobbersExit, bc#10, ExitValid)
30:< 1:-> SetLocal(DoubleRep:@28<Double>, loc7(M<Double>/FlushedDouble), machine:loc6, W:Stack(-8), bc#10, exit: bc#14, ExitValid) predicting BytecodeDouble
...
73:<!0:-> Jump(MustGen, T:#1, W:SideState, bc#71, ExitValid)
Block #1 (bc#71): (OSR target) pred, #0
...
102:<!2:loc15> GetLocal(Check:Untyped:@400, Double|MustGen|PureInt, BytecodeDouble, loc7(M<Double>/FlushedDouble), machine:loc6, R:Stack(-8), bc#120, ExitValid) predicting BytecodeDouble
...
CFA at @28 says it is invalid since there are type contradiction (Int32:@27 v.s. StringIdent). So, of course, we do not propagate #0's type information to #1 since we become invalid state.
However, #1 is still reachable since it is an OSR target. Since #0 was only the predecessor of #1, loc7's type information becomes None at the head of #1.
Since loc7's AbstractValue is None, @102 GetLocal emits breakpoint. It is OK as long as OSR entry fails because AbstractValue validation requires the given value is None type.
The issue here is that we skipped AbstractValue validation when we have FlushFormat information. Since loc7 has FlushedDouble format, DFG OSR entry code does not validate it against AbstractValue,
which is None. Then, we hit the breakpoint emitted by @102.
This patch performs AbstractValue validation against values even if we have FlushFormat. We should correctly configure AbstractValue for OSR entry's locals too to avoid unnecessary OSR entry
failures in the future but anyway validating locals with AbstractValue is correct behavior here since DFGSpeculativeJIT relies on that.
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareOSREntry):
2019-03-12 Michael Saboff <msaboff@apple.com>
REGRESSION (iOS 12.2): Webpage using CoffeeScript crashes
https://bugs.webkit.org/show_bug.cgi?id=195613
Reviewed by Mark Lam.
The bug here is in Yarr JIT backreference matching code. We are incorrectly
using a checkedOffset / inputPosition correction when checking for the available
length left in a string. It is improper to do these corrections as a backreference's
match length is based on what was matched in the referenced capture group and not
part of the checkedOffset and inputPosition computed when we compiled the RegExp.
In some cases, the resulting incorrect calculation would allow us to go past
the subject string's length. Removed these adjustments.
After writing tests for the first bug, found another bug where the non-greedy
backreference backtracking code didn't do an "are we at the end of the input?" check.
This caused an infinite loop as we'd jump from the backtracking code back to
try matching one more backreference, fail and then backtrack.
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::generateBackReference):
(JSC::Yarr::YarrGenerator::backtrackBackReference):
2019-03-12 Robin Morisset <rmorisset@apple.com>
A lot more classes have padding that can be reduced by reordering their fields
https://bugs.webkit.org/show_bug.cgi?id=195579
Reviewed by Mark Lam.
* assembler/LinkBuffer.h:
* dfg/DFGArrayifySlowPathGenerator.h:
(JSC::DFG::ArrayifySlowPathGenerator::ArrayifySlowPathGenerator):
* dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
(JSC::DFG::CallArrayAllocatorSlowPathGenerator::CallArrayAllocatorSlowPathGenerator):
(JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableSizeSlowPathGenerator):
* dfg/DFGGraph.h:
* dfg/DFGNode.h:
(JSC::DFG::SwitchData::SwitchData):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::Plan):
* dfg/DFGPlan.h:
* dfg/DFGSlowPathGenerator.h:
(JSC::DFG::CallSlowPathGenerator::CallSlowPathGenerator):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::SpeculativeJIT):
* dfg/DFGSpeculativeJIT.h:
* domjit/DOMJITSignature.h:
(JSC::DOMJIT::Signature::Signature):
(JSC::DOMJIT::Signature::effect):
(JSC::DOMJIT::Signature::argumentCount): Deleted.
* heap/MarkingConstraintSolver.h:
* heap/SlotVisitor.h:
* jit/CallFrameShuffleData.h:
* jit/JITDivGenerator.h:
* jit/SpillRegistersMode.h:
* parser/Nodes.h:
* profiler/ProfilerOSRExit.cpp:
(JSC::Profiler::OSRExit::OSRExit):
* profiler/ProfilerOSRExit.h:
* runtime/ArrayBufferView.h:
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::SamplingProfiler):
* runtime/SamplingProfiler.h:
* runtime/TypeSet.cpp:
(JSC::StructureShape::StructureShape):
* runtime/TypeSet.h:
* runtime/Watchdog.h:
2019-03-12 Mark Lam <mark.lam@apple.com>
The HasIndexedProperty node does GC.
https://bugs.webkit.org/show_bug.cgi?id=195559
<rdar://problem/48767923>
Reviewed by Yusuke Suzuki.
HasIndexedProperty can call the slow path operationHasIndexedPropertyByInt(),
which can eventually call JSString::getIndex(), which can resolve a rope.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
2019-03-12 Devin Rousso <drousso@apple.com>
Web Inspector: Audit: there should be a centralized place for reusable code
https://bugs.webkit.org/show_bug.cgi?id=195265
<rdar://problem/47040673>
Reviewed by Joseph Pecoraro.
* inspector/protocol/Audit.json:
Increment version.
2019-03-12 Robin Morisset <rmorisset@apple.com>
blocksInPreOrder and blocksInPostOrder should reserve the right capacity for their result vector
https://bugs.webkit.org/show_bug.cgi?id=195595
Reviewed by Saam Barati.
Also change BlockList from being Vector<BasicBlock*, 5> to Vector<BasicBlock*>
* dfg/DFGBasicBlock.h:
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::blocksInPreOrder):
(JSC::DFG::Graph::blocksInPostOrder):
2019-03-11 Ross Kirsling <ross.kirsling@sony.com>
Add Optional to Forward.h.
https://bugs.webkit.org/show_bug.cgi?id=195586
Reviewed by Darin Adler.
* b3/B3Common.cpp:
* b3/B3Common.h:
* debugger/DebuggerParseData.cpp:
* debugger/DebuggerParseData.h:
* heap/HeapSnapshot.cpp:
* heap/HeapSnapshot.h:
* jit/PCToCodeOriginMap.cpp:
* jit/PCToCodeOriginMap.h:
* runtime/AbstractModuleRecord.cpp:
* runtime/AbstractModuleRecord.h:
* wasm/WasmInstance.h:
* wasm/WasmModuleParser.h:
* wasm/WasmSectionParser.cpp:
* wasm/WasmSectionParser.h:
* wasm/WasmStreamingParser.cpp:
* wasm/WasmStreamingParser.h:
* yarr/YarrFlags.cpp:
* yarr/YarrFlags.h:
* yarr/YarrUnicodeProperties.cpp:
* yarr/YarrUnicodeProperties.h:
Remove unnecessary includes from headers.
2019-03-11 Justin Fan <justin_fan@apple.com>
[Web GPU] Update GPUSwapChainDescriptor, GPUSwapChain and implement GPUCanvasContext
https://bugs.webkit.org/show_bug.cgi?id=194406
<rdar://problem/47892466>
Reviewed by Myles C. Maxfield.
Added WebGPU to inspector context types.
* inspector/protocol/Canvas.json:
* inspector/scripts/codegen/generator.py:
2019-03-11 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Reduce # of structures in JSGlobalObject initialization
https://bugs.webkit.org/show_bug.cgi?id=195498
Reviewed by Darin Adler.
This patch reduces # of structure allocations in JSGlobalObject initialization. Now it becomes 141, it fits in one
MarkedBlock and this patch drops one MarkedBlock used for Structure previously.
* CMakeLists.txt:
* DerivedSources-output.xcfilelist:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/ArrayIteratorPrototype.cpp:
(JSC::ArrayIteratorPrototype::finishCreation): ArrayIteratorPrototype, MapIteratorPrototype, and StringIteratorPrototype's
"next" properties are referenced by JSGlobalObject::init, and it causes reification of the lazy "next" property and structure
transition anyway. So we should put it eagerly "without-transition" configuration to avoid one structure transition.
* runtime/ArrayPrototype.cpp:
(JSC::ArrayPrototype::finishCreation): @@unscopable object's structure should be dictionary because (1) it is used as a dictionary
in with-scope-resolution and (2) since with-scope-resolution is C++ runtime function anyway, non-dictionary structure does not add
any performance benefit. This change saves several structures that are not useful.
* runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::createStructure): Bake CloneArguments's structure with 'without-transition' manner.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init): Previously we are always call resetProtoype at the end of JSGlobalObject::init. But it is not necessary
since we do not change [[Prototype]] of JSGlobalObject. All we want is (1) fixupPrototypeChainWithObjectPrototype's operation and (2) setGlobalThis
operation. Since setGlobalThis part is done in JSGlobalObject::finishCreation, fixupPrototypeChainWithObjectPrototype is only the thing
we should do here.
(JSC::JSGlobalObject::fixupPrototypeChainWithObjectPrototype):
(JSC::JSGlobalObject::resetPrototype): If the [[Prototype]] is the same to the current [[Prototype]], we can skip the operation.
* runtime/JSGlobalObject.h:
* runtime/MapIteratorPrototype.cpp:
(JSC::MapIteratorPrototype::finishCreation):
* runtime/NullGetterFunction.h:
* runtime/NullSetterFunction.h: Since structures of them are allocated per JSGlobalObject and they are per-JSGlobalObject,
we can use without-transition property addition.
* runtime/StringIteratorPrototype.cpp:
(JSC::StringIteratorPrototype::finishCreation):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::setIteratorStructureSlow):
(JSC::VM::mapIteratorStructureSlow): These structures are only used in WebCore's main thread.
* runtime/VM.h:
(JSC::VM::setIteratorStructure):
(JSC::VM::mapIteratorStructure):
2019-03-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] BuiltinExecutables should behave like a WeakSet instead of generic WeakHandleOwner for memory footprint
https://bugs.webkit.org/show_bug.cgi?id=195508
Reviewed by Darin Adler.
Weak<> is not cheap in terms of memory footprint. We allocate WeakBlock (256 bytes) for book-keeping Weak<>.
Currently BuiltinExecutables has 203 Weak<> members and many WeakBlocks are actually allocated because
many UnlinkedFunctionExecutables in BuiltinExecutables are allocated during JSGlobalObject initialization process.
This patch changes two things in BuiltinExecutables.
1. Previously we have m_xxxSourceCode fields too. But we do not need to keep it since we know how to produce it when it is required.
We generate SourceCode in xxxSourceCode() method instead of just returning m_xxxSourceCode. This reduces sizeof(BuiltinExecutables) 24 x 203 = 4KB.
2. Instead of using Weak<>, BuiltinExecutables holds raw array of UnlinkedFunctionExecutable*. And Heap::finalizeUnconditionalFinalizers() correctly clears dead executables.
This is similar to JSWeakSet implementation. And it saves WeakBlock allocations.
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::BuiltinExecutables):
(JSC::BuiltinExecutables::finalizeUnconditionally):
(JSC::JSC_FOREACH_BUILTIN_CODE): Deleted.
(JSC::BuiltinExecutables::finalize): Deleted.
* builtins/BuiltinExecutables.h:
(JSC::BuiltinExecutables::static_cast<unsigned>):
(): Deleted.
* heap/Heap.cpp:
(JSC::Heap::finalizeUnconditionalFinalizers):
2019-03-11 Robin Morisset <rmorisset@apple.com>
IntlDateTimeFormat can be shrunk by 32 bytes
https://bugs.webkit.org/show_bug.cgi?id=195504
Reviewed by Darin Adler.
* runtime/IntlDateTimeFormat.h:
2019-03-11 Robin Morisset <rmorisset@apple.com>
IntlCollator can be shrunk by 16 bytes
https://bugs.webkit.org/show_bug.cgi?id=195503
Reviewed by Darin Adler.
* runtime/IntlCollator.h:
2019-03-11 Robin Morisset <rmorisset@apple.com>
IntlNumberFormat can be shrunk by 16 bytes
https://bugs.webkit.org/show_bug.cgi?id=195505
Reviewed by Darin Adler.
* runtime/IntlNumberFormat.h:
2019-03-11 Caio Lima <ticaiolima@gmail.com>
[ESNext][BigInt] Implement "~" unary operation
https://bugs.webkit.org/show_bug.cgi?id=182216
Reviewed by Keith Miller.
This patch is adding support of BigInt into op_bitnot operations. In
addition, we are changing ArithBitNot to handle only Number operands,
while introducing a new node named ValueBitNot to handle Untyped and
BigInt. This node follows the same approach we are doing into other
arithimetic operations into DFG.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
It is possible that fixup and prediction propagation don't convert a
ValueBitNot(ConstInt32) into ArithBitNot(ConstInt32) because these
analysis are conservative. In such case, we are adding constant
folding rules to ValueBitNot AI.
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
ValueBitNot has same rules as ArithBitNot on backwards propagation.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
We can emit ArithBitNot if we know that operand of op_bitnot is a
Number or any int. Otherwise we fallback to ValueBitNot and rely on
fixup to convert the node to ArithBitNot when it is possible.
ValueBitNot uses heap prediction on prediction propagation and we
collect its type from op_bitnot's value profiler.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
When we have the case with ValueBitNot(BigInt), we don't clobberize
world.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
ValueBitNot can GC on BigIntUse because, right now, all bitNot
operation allocates temporary BigInts to perform calculations and it
can potentially trigger GC.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
ValueBitNot is responsible do handle BigIntUse and UntypedUse. To all
other uses, we fallback to ArithBitNot.
* dfg/DFGNode.h:
(JSC::DFG::Node::hasHeapPrediction):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
(JSC::DFG::bitwiseBinaryOp):
This template function is abstracting the new semantics of numeric
values operations on bitwise operations. These operations usually
folow these steps:
1. rhsNumeric = GetInt32OrBigInt(rhs)
2. lhsNumeric = GetInt32OrBigInt(lhs)
3. trhow error if TypeOf(rhsNumeric) != TypeOf(lhsNumeric)
4. return BigInt::bitwiseOp(bitOp, rhs, lhs) if TypeOf(lhsNumeric) == BigInt
5. return rhs <int32BitOp> lhs
Since we have almost the same code for every bitwise op,
we use such template to avoid code duplication. The template receives
Int32 and BigInt operations as parameter. Error message is received as
`const char*` instead of `String&` to avoid String allocation even when
there is no error to throw.
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueBitNot):
ValueBitNot generates speculative code for BigIntUse and this code is a
call to `operationBitNotBigInt`. This operation is faster than
`operationValueBitNot` because there is no need to check types of
operands and execute properly operation. We still need to check
exceptions after `operationBitNotBigInt` because it can throw OOM.
(JSC::DFG::SpeculativeJIT::compileBitwiseNot):
* 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::compileValueBitNot):
(JSC::FTL::DFG::LowerDFGToB3::compileArithBitNot):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::bitwiseNot):
* runtime/JSBigInt.h:
2019-03-11 Darin Adler <darin@apple.com>
Specify fixed precision explicitly to prepare to change String::number and StringBuilder::appendNumber floating point behavior
https://bugs.webkit.org/show_bug.cgi?id=195533
Reviewed by Brent Fulgham.
* API/tests/ExecutionTimeLimitTest.cpp:
(testExecutionTimeLimit): Use appendFixedPrecisionNumber.
* runtime/NumberPrototype.cpp:
(JSC::numberProtoFuncToPrecision): Use numberToStringFixedPrecision.
* runtime/Options.cpp:
(JSC::Option::dump const): Use appendFixedPrecisionNumber.
2019-03-10 Ross Kirsling <ross.kirsling@sony.com>
Invalid flags in a RegExp literal should be an early SyntaxError
https://bugs.webkit.org/show_bug.cgi?id=195514
Reviewed by Darin Adler.
Currently we're throwing a *runtime* SyntaxError; this should occur at parse time.
12.2.8.1 Static Semantics: Early Errors
PrimaryExpression : RegularExpressionLiteral
- It is a Syntax Error if BodyText of RegularExpressionLiteral cannot be recognized
using the goal symbol Pattern of the ECMAScript RegExp grammar specified in 21.2.1.
- It is a Syntax Error if FlagText of RegularExpressionLiteral contains any code points
other than "g", "i", "m", "s", "u", or "y", or if it contains the same code point more than once.
In fixing this, let's also move flag handling from runtime/ to yarr/.
* yarr/YarrSyntaxChecker.cpp:
(JSC::Yarr::checkSyntax):
Check flags before checking pattern.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecompiler/NodesCodegen.cpp:
(JSC::RegExpNode::emitBytecode):
* inspector/ContentSearchUtilities.cpp:
(Inspector::ContentSearchUtilities::findMagicComment):
* runtime/CachedTypes.cpp:
* runtime/RegExp.cpp:
(JSC::RegExp::RegExp):
(JSC::RegExp::createWithoutCaching):
(JSC::RegExp::create):
(JSC::regExpFlags): Deleted.
* runtime/RegExp.h:
* runtime/RegExpCache.cpp:
(JSC::RegExpCache::lookupOrCreate):
(JSC::RegExpCache::ensureEmptyRegExpSlow):
* runtime/RegExpCache.h:
* runtime/RegExpConstructor.cpp:
(JSC::toFlags):
(JSC::regExpCreate):
(JSC::constructRegExp):
* runtime/RegExpKey.h:
(JSC::RegExpKey::RegExpKey):
(WTF::HashTraits<JSC::RegExpKey>::constructDeletedValue):
(WTF::HashTraits<JSC::RegExpKey>::isDeletedValue):
(): Deleted.
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoFuncCompile):
* testRegExp.cpp:
(parseRegExpLine):
* yarr/RegularExpression.cpp:
(JSC::Yarr::RegularExpression::Private::compile):
* yarr/YarrFlags.cpp: Added.
(JSC::Yarr::parseFlags):
* yarr/YarrFlags.h: Added.
* yarr/YarrInterpreter.h:
(JSC::Yarr::BytecodePattern::ignoreCase const):
(JSC::Yarr::BytecodePattern::multiline const):
(JSC::Yarr::BytecodePattern::sticky const):
(JSC::Yarr::BytecodePattern::unicode const):
(JSC::Yarr::BytecodePattern::dotAll const):
* yarr/YarrPattern.cpp:
(JSC::Yarr::YarrPattern::compile):
(JSC::Yarr::YarrPattern::YarrPattern):
(JSC::Yarr::YarrPattern::dumpPattern):
* yarr/YarrPattern.h:
(JSC::Yarr::YarrPattern::global const):
(JSC::Yarr::YarrPattern::ignoreCase const):
(JSC::Yarr::YarrPattern::multiline const):
(JSC::Yarr::YarrPattern::sticky const):
(JSC::Yarr::YarrPattern::unicode const):
(JSC::Yarr::YarrPattern::dotAll const):
Move flag handling to Yarr and modernize API.
2019-03-09 Robin Morisset <rmorisset@apple.com>
Compilation can be shrunk by 8 bytes
https://bugs.webkit.org/show_bug.cgi?id=195500
Reviewed by Mark Lam.
* profiler/ProfilerCompilation.cpp:
(JSC::Profiler::Compilation::Compilation):
* profiler/ProfilerCompilation.h:
2019-03-09 Robin Morisset <rmorisset@apple.com>
BinarySwitch can be shrunk by 8 bytes
https://bugs.webkit.org/show_bug.cgi?id=195493
Reviewed by Mark Lam.
* jit/BinarySwitch.cpp:
(JSC::BinarySwitch::BinarySwitch):
* jit/BinarySwitch.h:
2019-03-09 Robin Morisset <rmorisset@apple.com>
AsyncStackTrace can be shrunk by 8 bytes
https://bugs.webkit.org/show_bug.cgi?id=195491
Reviewed by Mark Lam.
* inspector/AsyncStackTrace.h:
2019-03-08 Mark Lam <mark.lam@apple.com>
Stack overflow crash in JSC::JSObject::hasInstance.
https://bugs.webkit.org/show_bug.cgi?id=195458
<rdar://problem/48710195>
Reviewed by Yusuke Suzuki.
* runtime/JSObject.cpp:
(JSC::JSObject::hasInstance):
2019-03-08 Robin Morisset <rmorisset@apple.com>
IntegerCheckCombiningPhase::Range can be shrunk by 8 bytes
https://bugs.webkit.org/show_bug.cgi?id=195487
Reviewed by Saam Barati.
* dfg/DFGIntegerCheckCombiningPhase.cpp:
2019-03-08 Robin Morisset <rmorisset@apple.com>
TypeLocation can be shrunk by 8 bytes
https://bugs.webkit.org/show_bug.cgi?id=195483
Reviewed by Mark Lam.
* bytecode/TypeLocation.h:
(JSC::TypeLocation::TypeLocation):
2019-03-08 Robin Morisset <rmorisset@apple.com>
GetByIdStatus can be shrunk by 16 bytes
https://bugs.webkit.org/show_bug.cgi?id=195480
Reviewed by Saam Barati.
8 bytes from reordering fields
8 more bytes by making the enum State only use 1 byte.
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::GetByIdStatus):
* bytecode/GetByIdStatus.h:
2019-03-08 Robin Morisset <rmorisset@apple.com>
PutByIdVariant can be shrunk by 8 bytes
https://bugs.webkit.org/show_bug.cgi?id=195482
Reviewed by Mark Lam.
* bytecode/PutByIdVariant.h:
(JSC::PutByIdVariant::PutByIdVariant):
2019-03-08 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, follow-up after r242568
Robin pointed that calculation of `numberOfChildren` and `nonEmptyIndex` is unnecessary.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2019-03-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] We should have more WithoutTransition functions which are usable for JSGlobalObject initialization
https://bugs.webkit.org/show_bug.cgi?id=195447
Reviewed by Filip Pizlo.
This patch reduces # of unnecessary structure transitions in JSGlobalObject initialization to avoid unnecessary allocations
caused by Structure transition. One example is WeakBlock allocation for StructureTransitionTable.
To achieve this, we (1) add putDirectNonIndexAccessorWithoutTransition and putDirectNativeIntrinsicGetterWithoutTransition
to add accessor properties without transition, and (2) add NameAdditionMode::WithoutStructureTransition mode to InternalFunction::finishCreation
to use `putDirectWithoutTransition` instead of `putDirect`.
* inspector/JSInjectedScriptHostPrototype.cpp:
(Inspector::JSInjectedScriptHostPrototype::finishCreation):
* inspector/JSJavaScriptCallFramePrototype.cpp:
(Inspector::JSJavaScriptCallFramePrototype::finishCreation):
* runtime/ArrayConstructor.cpp:
(JSC::ArrayConstructor::finishCreation):
* runtime/AsyncFunctionConstructor.cpp:
(JSC::AsyncFunctionConstructor::finishCreation):
* runtime/AsyncGeneratorFunctionConstructor.cpp:
(JSC::AsyncGeneratorFunctionConstructor::finishCreation):
* runtime/BigIntConstructor.cpp:
(JSC::BigIntConstructor::finishCreation):
* runtime/BooleanConstructor.cpp:
(JSC::BooleanConstructor::finishCreation):
* runtime/DateConstructor.cpp:
(JSC::DateConstructor::finishCreation):
* runtime/ErrorConstructor.cpp:
(JSC::ErrorConstructor::finishCreation):
* runtime/FunctionConstructor.cpp:
(JSC::FunctionConstructor::finishCreation):
* runtime/FunctionPrototype.cpp:
(JSC::FunctionPrototype::finishCreation):
(JSC::FunctionPrototype::addFunctionProperties):
(JSC::FunctionPrototype::initRestrictedProperties):
* runtime/FunctionPrototype.h:
* runtime/GeneratorFunctionConstructor.cpp:
(JSC::GeneratorFunctionConstructor::finishCreation):
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::finishCreation):
* runtime/InternalFunction.h:
* runtime/IntlCollatorConstructor.cpp:
(JSC::IntlCollatorConstructor::finishCreation):
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::IntlDateTimeFormatConstructor::finishCreation):
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::IntlNumberFormatConstructor::finishCreation):
* runtime/IntlPluralRulesConstructor.cpp:
(JSC::IntlPluralRulesConstructor::finishCreation):
* runtime/JSArrayBufferConstructor.cpp:
(JSC::JSGenericArrayBufferConstructor<sharingMode>::finishCreation):
* runtime/JSArrayBufferPrototype.cpp:
(JSC::JSArrayBufferPrototype::finishCreation):
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSObject.cpp:
(JSC::JSObject::putDirectNonIndexAccessorWithoutTransition):
(JSC::JSObject::putDirectNativeIntrinsicGetterWithoutTransition):
* runtime/JSObject.h:
* runtime/JSPromiseConstructor.cpp:
(JSC::JSPromiseConstructor::finishCreation):
* runtime/JSTypedArrayViewConstructor.cpp:
(JSC::JSTypedArrayViewConstructor::finishCreation):
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::JSTypedArrayViewPrototype::finishCreation):
* runtime/MapConstructor.cpp:
(JSC::MapConstructor::finishCreation):
* runtime/MapPrototype.cpp:
(JSC::MapPrototype::finishCreation):
* runtime/NativeErrorConstructor.cpp:
(JSC::NativeErrorConstructorBase::finishCreation):
* runtime/NullGetterFunction.h:
* runtime/NullSetterFunction.h:
* runtime/NumberConstructor.cpp:
(JSC::NumberConstructor::finishCreation):
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructor::finishCreation):
* runtime/ProxyConstructor.cpp:
(JSC::ProxyConstructor::finishCreation):
* runtime/RegExpConstructor.cpp:
(JSC::RegExpConstructor::finishCreation):
* runtime/RegExpPrototype.cpp:
(JSC::RegExpPrototype::finishCreation):
* runtime/SetConstructor.cpp:
(JSC::SetConstructor::finishCreation):
* runtime/SetPrototype.cpp:
(JSC::SetPrototype::finishCreation):
* runtime/StringConstructor.cpp:
(JSC::StringConstructor::finishCreation):
* runtime/SymbolConstructor.cpp:
(JSC::SymbolConstructor::finishCreation):
* runtime/WeakMapConstructor.cpp:
(JSC::WeakMapConstructor::finishCreation):
* runtime/WeakSetConstructor.cpp:
(JSC::WeakSetConstructor::finishCreation):
* wasm/js/WebAssemblyCompileErrorConstructor.cpp:
(JSC::WebAssemblyCompileErrorConstructor::finishCreation):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::WebAssemblyInstanceConstructor::finishCreation):
* wasm/js/WebAssemblyLinkErrorConstructor.cpp:
(JSC::WebAssemblyLinkErrorConstructor::finishCreation):
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::WebAssemblyMemoryConstructor::finishCreation):
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::WebAssemblyModuleConstructor::finishCreation):
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
(JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):
* wasm/js/WebAssemblyTableConstructor.cpp:
(JSC::WebAssemblyTableConstructor::finishCreation):
2019-03-08 Tadeu Zagallo <tzagallo@apple.com>
op_check_tdz does not def its argument
https://bugs.webkit.org/show_bug.cgi?id=192880
<rdar://problem/46221598>
Reviewed by Saam Barati.
This prevented the for-in loop optimization in the bytecode generator, since
the analysis sees a redefinition of the loop variable.
* bytecode/BytecodeUseDef.h:
(JSC::computeDefsForBytecodeOffset):
2019-03-07 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Make more fields lazy in JSGlobalObject
https://bugs.webkit.org/show_bug.cgi?id=195449
Reviewed by Mark Lam.
This patch makes more fields lazy-allocated in JSGlobalObject to save memory.
1. Some minor structures like moduleRecordStructure.
2. Some functions like parseInt / parseFloat. While they are eagerly created in JIT mode anyway to materialize NumberConstructor, we can lazily allocate them in non JIT mode.
3. ArrayBuffer constructor. While it is eagerly allocated in WebCore, we can make lazily allocated in JSC.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
* runtime/JSArrayBufferPrototype.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::parseIntFunction const):
(JSC::JSGlobalObject::parseFloatFunction const):
(JSC::JSGlobalObject::evalFunction const):
(JSC::JSGlobalObject::strictEvalActivationStructure const):
(JSC::JSGlobalObject::moduleRecordStructure const):
(JSC::JSGlobalObject::moduleNamespaceObjectStructure const):
(JSC::JSGlobalObject::proxyObjectStructure const):
(JSC::JSGlobalObject::callableProxyObjectStructure const):
(JSC::JSGlobalObject::proxyRevokeStructure const):
(JSC::JSGlobalObject::arrayBufferConstructor const):
(JSC::JSGlobalObject::arrayBufferPrototype const):
(JSC::JSGlobalObject::arrayBufferStructure const):
* runtime/ProxyObject.h:
* runtime/StrictEvalActivation.cpp:
(JSC::StrictEvalActivation::StrictEvalActivation):
* runtime/StrictEvalActivation.h:
* wasm/js/JSWebAssemblyMemory.cpp:
(JSC::JSWebAssemblyMemory::buffer):
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::webAssemblyModuleCustomSections):
2019-03-07 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Remove merging must handle values into proven types in CFA
https://bugs.webkit.org/show_bug.cgi?id=195444
Reviewed by Saam Barati.
Previously, we are merging must handle values as a proven constant in CFA. This is OK as long as this proven AbstractValue is blurred by merging the other legit AbstractValues
from the successors. But let's consider the following code, this is actually generated DFG graph from the attached test in r242626.
Block #2 (loop header) succ #3, #4
...
1: ForceOSRExit
...
2: JSConstant(0)
3: SetLocal(@2, loc6)
...
4: Branch(#3, #4)
Block #3 (This is OSR entry target) pred #2, #3, must handle value for loc6 => JSConstant(Int32, 31)
...
5: GetLocal(loc6)
6: StringFromCharCode(@5)
...
Block #3 is OSR entry target. So we have must handle value for loc6 and it is Int32 constant 31. Then we merge this constant as a proven value in #3's loc6 AbstractValue.
If the value from #2 blurs the value, it is OK. However, #2 has ForceOSRExit. So must handle value suddenly becomes the only source of loc6 in #3. Then we use this constant
as a proven value. But this is not expected behavior since must handle value is just a snapshot of the locals when we kick off the concurrent compilation. In the above example,
we assume that loop index is an constant 31, but it is wrong, and OSR entry fails. Because there is no strong assumption that the must handle value is the proven type or value,
we should not merge it in CFA.
Since (1) this is just an optimization, (2) type information is already propagated in prediction injection phase, and (3) the must handle value does not show the performance
progression in r211461 and we no longer see type misprediction in marsaglia-osr-entry.js, this patch simply removes must handle value type widening in CFA.
* dfg/DFGCFAPhase.cpp:
(JSC::DFG::CFAPhase::run):
(JSC::DFG::CFAPhase::performBlockCFA):
(JSC::DFG::CFAPhase::injectOSR): Deleted.
2019-03-07 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] StringFromCharCode fast path should accept 0xff in DFG and FTL
https://bugs.webkit.org/show_bug.cgi?id=195429
Reviewed by Saam Barati.
We can create single characters without allocation up to 0xff character code. But currently, DFGSpeculativeJIT and FTLLowerDFGToB3 go to the slow path
for 0xff case. On the other hand, DFG DoesGC phase says GC won't happen if the child is int32 constant and it is <= 0xff. So, if you have `String.fromCharCode(0xff)`,
this breaks the assumption in DFG DoesGC. The correct fix is changing the check in DFGSpeculativeJIT and FTLLowerDFGToB3 from AboveOrEqual to Above.
Note that ThunkGenerators's StringFromCharCode thunk was correct.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileFromCharCode):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):
2019-03-07 Mark Lam <mark.lam@apple.com>
Follow up refactoring in try-finally code after r242591.
https://bugs.webkit.org/show_bug.cgi?id=195428
Reviewed by Saam Barati.
1. Added some comments in emitFinallyCompletion() to describe each completion case.
2. Converted CatchEntry into a struct.
3. Renamed variable hasBreaksOrContinuesNotCoveredByJumps to hasBreaksOrContinuesThatEscapeCurrentFinally
to be more clear about its purpose.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::emitOutOfLineExceptionHandler):
(JSC::BytecodeGenerator::emitFinallyCompletion):
* bytecompiler/BytecodeGenerator.h:
2019-03-07 Saam Barati <sbarati@apple.com>
CompactVariableMap::Handle's copy operator= leaks the previous data
https://bugs.webkit.org/show_bug.cgi?id=195398
Reviewed by Yusuke Suzuki.
The copy constructor was just assigning |this| to the new value,
forgetting to decrement the ref count of the thing pointed to by
the |this| handle. Based on Yusuke's suggestion, this patch refactors
the move constructor, move operator=, and copy operator= to use the
swap() primitive and the copy constructor primitive.
* parser/VariableEnvironment.cpp:
(JSC::CompactVariableMap::Handle::Handle):
(JSC::CompactVariableMap::Handle::swap):
(JSC::CompactVariableMap::Handle::operator=): Deleted.
* parser/VariableEnvironment.h:
(JSC::CompactVariableMap::Handle::Handle):
(JSC::CompactVariableMap::Handle::operator=):
2019-03-07 Tadeu Zagallo <tzagallo@apple.com>
Lazily decode cached bytecode
https://bugs.webkit.org/show_bug.cgi?id=194810
Reviewed by Saam Barati.
Like lazy parsing, we should pause at code block boundaries. Instead
of always eagerly decoding UnlinkedFunctionExecutable's UnlinkedCodeBlocks,
we store their offsets in the executable and lazily decode them on the next
call to `unlinkedCodeBlockFor`.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::UnlinkedFunctionExecutable::~UnlinkedFunctionExecutable):
(JSC::UnlinkedFunctionExecutable::visitChildren):
(JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
(JSC::UnlinkedFunctionExecutable::decodeCachedCodeBlocks):
* bytecode/UnlinkedFunctionExecutable.h:
* runtime/CachedTypes.cpp:
(JSC::Decoder::Decoder):
(JSC::Decoder::~Decoder):
(JSC::Decoder::create):
(JSC::Decoder::offsetOf):
(JSC::Decoder::cacheOffset):
(JSC::Decoder::ptrForOffsetFromBase):
(JSC::Decoder::handleForEnvironment const):
(JSC::Decoder::setHandleForEnvironment):
(JSC::Decoder::addFinalizer):
(JSC::VariableLengthObject::isEmpty const):
(JSC::CachedWriteBarrier::isEmpty const):
(JSC::CachedFunctionExecutable::unlinkedCodeBlockForCall const):
(JSC::CachedFunctionExecutable::unlinkedCodeBlockForConstruct const):
(JSC::CachedFunctionExecutable::decode const):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::decodeCodeBlockImpl):
(JSC::isCachedBytecodeStillValid):
(JSC::decodeFunctionCodeBlock):
* runtime/CachedTypes.h:
(JSC::Decoder::vm):
2019-03-06 Mark Lam <mark.lam@apple.com>
Exception is a JSCell, not a JSObject.
https://bugs.webkit.org/show_bug.cgi?id=195392
Reviewed by Saam Barati.
Exception is a VM implementation construct to carry a stack trace for the point
where it is thrown from. As a reminder, an Exception is needed because:
1. JS code can throw primitives as well that are non-cells.
2. Error objects capture the stack trace at the point where they are constructed,
which is not always the same as the point where they are thrown (if they are
thrown).
Hence, Exception should not be visible to JS code, and therefore should not be a
JSObject. Hence, it should not inherit from JSDestructibleObject.
This patch changes the following:
1. Exception now inherits directly from JSCell instead.
2. Places where we return an Exception masquerading as a JSObject* are now
updated to return a nullptr when we encounter an exception.
3. We still return Exception* as JSValue or EncodedJSValue when we encounter an
exception in functions that return JSValue or EncodedJSValue. This is because
the number that implements the following pattern is too numerous:
return throw<Some Error>(...)
We'll leave these as is for now.
* bytecode/CodeBlock.h:
(JSC::ScriptExecutable::prepareForExecution):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::executeProgram):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
(JSC::Interpreter::prepareForRepeatCall):
(JSC::Interpreter::execute):
(JSC::Interpreter::executeModuleProgram):
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setUpCall):
* runtime/ConstructData.cpp:
(JSC::construct):
* runtime/Error.cpp:
(JSC::throwConstructorCannotBeCalledAsFunctionTypeError):
(JSC::throwTypeError):
(JSC::throwSyntaxError):
* runtime/Error.h:
(JSC::throwRangeError):
* runtime/Exception.cpp:
(JSC::Exception::createStructure):
* runtime/Exception.h:
* runtime/ExceptionHelpers.cpp:
(JSC::throwOutOfMemoryError):
(JSC::throwStackOverflowError):
(JSC::throwTerminatedExecutionException):
* runtime/ExceptionHelpers.h:
* runtime/FunctionConstructor.cpp:
(JSC::constructFunction):
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/IntlPluralRules.cpp:
(JSC::IntlPluralRules::resolvedOptions):
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayViewWithArguments):
* runtime/JSObject.h:
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorSeal):
(JSC::objectConstructorFreeze):
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties):
* runtime/RegExpConstructor.cpp:
(JSC::regExpCreate):
(JSC::constructRegExp):
* runtime/ScriptExecutable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::ScriptExecutable::prepareForExecutionImpl):
* runtime/ScriptExecutable.h:
* runtime/ThrowScope.cpp:
(JSC::ThrowScope::throwException):
* runtime/ThrowScope.h:
(JSC::ThrowScope::throwException):
(JSC::throwException):
* runtime/VM.cpp:
(JSC::VM::throwException):
* runtime/VM.h:
2019-03-06 Ross Kirsling <ross.kirsling@sony.com>
[Win] Remove -DUCHAR_TYPE=wchar_t stopgap and learn to live with char16_t.
https://bugs.webkit.org/show_bug.cgi?id=195346
Reviewed by Fujii Hironori.
* jsc.cpp:
(currentWorkingDirectory):
(fetchModuleFromLocalFileSystem):
* runtime/DateConversion.cpp:
(JSC::formatDateTime):
Use wchar helpers as needed.
2019-03-06 Mark Lam <mark.lam@apple.com>
Fix incorrect handling of try-finally completion values.
https://bugs.webkit.org/show_bug.cgi?id=195131
<rdar://problem/46222079>
Reviewed by Saam Barati and Yusuke Suzuki.
Consider the following:
function foo() { // line 1
try {
return 42; // line 3
} finally {
for (var j = 0; j < 1; j++) { // line 5
try {
throw ''; // line 7
} finally {
continue; // line 9
}
}
} // line 11
}
var result = foo();
With the current (before fix) code base, result will be the exception object thrown
at line 7. The expected result should be 42, returned at line 3.
The bug is that we were previously only using one set of completion type and
value registers for the entire function. This is inadequate because the outer
try-finally needs to preserve its own completion type and value ({ Return, 42 }
in this case) in order to be able to complete correctly.
One might be deceived into thinking that the above example should complete with
the exception thrown at line 7. However, according to Section 13.15.8 of the
ECMAScript spec, the 'continue' in the finally at line 9 counts as an abrupt
completion. As a result, it overrides the throw from line 7. After the continue,
execution resumes at the top of the loop at line 5, followed by a normal completion
at line 11.
Also according to Section 13.15.8, given that the completion type of the outer
finally is normal, the resultant completion of the outer try-finally should be
the completion of the outer try block i.e. { Return, 42 }.
This patch makes the following changes:
1. Fix handling of finally completion to use a unique set of completion
type and value registers for each FinallyContext.
2. Move the setting of Throw completion type to the out of line exception handler.
This makes the mainline code slightly less branchy.
3. Introduce emitOutOfLineCatchHandler(), emitOutOfLineFinallyHandler(), and
emitOutOfLineExceptionHandler() to make it clearer that these are not emitting
bytecode inline. Also, these make it clearer when we're emitting a handler
for a catch vs a finally.
4. Allocate the FinallyContext on the stack instead of as a member of the
heap allocated ControlFlowScope. This simplifies its life-cycle management
and reduces the amount of needed copying.
5. Update emitFinallyCompletion() to propagate the completion type and value to
the outer FinallyContext when needed.
6. Fix emitJumpIf() to use the right order of operands. Previously, we were
only using it to do op_stricteq and op_nstricteq comparisons. So, the order
wasn't important. We now use it to also do op_beloweq comparisons. Hence,
the order needs to be corrected.
7. Remove the unused CompletionType::Break and Continue. These are encoded with
the jumpIDs of the jump targets instead.
Relevant specifications:
Section 13.15.8: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-try-statement-runtime-semantics-evaluation
Section 6.3.2.4: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-updateempty
* bytecompiler/BytecodeGenerator.cpp:
(JSC::FinallyContext::FinallyContext):
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::pushFinallyControlFlowScope):
(JSC::BytecodeGenerator::popFinallyControlFlowScope):
(JSC::BytecodeGenerator::emitOutOfLineCatchHandler):
(JSC::BytecodeGenerator::emitOutOfLineFinallyHandler):
(JSC::BytecodeGenerator::emitOutOfLineExceptionHandler):
(JSC::BytecodeGenerator::emitEnumeration):
(JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
(JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
(JSC::BytecodeGenerator::emitFinallyCompletion):
(JSC::BytecodeGenerator::emitJumpIf):
(JSC::BytecodeGenerator::emitCatch): Deleted.
(JSC::BytecodeGenerator::allocateCompletionRecordRegisters): Deleted.
(JSC::BytecodeGenerator::releaseCompletionRecordRegisters): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::FinallyContext::completionTypeRegister const):
(JSC::FinallyContext::completionValueRegister const):
(JSC::ControlFlowScope::ControlFlowScope):
(JSC::BytecodeGenerator::emitLoad):
(JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope): Deleted.
(JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope): Deleted.
(JSC::BytecodeGenerator::completionTypeRegister const): Deleted.
(JSC::BytecodeGenerator::completionValueRegister const): Deleted.
(JSC::BytecodeGenerator::emitSetCompletionType): Deleted.
(JSC::BytecodeGenerator::emitSetCompletionValue): Deleted.
* bytecompiler/NodesCodegen.cpp:
(JSC::TryNode::emitBytecode):
2019-03-06 Saam Barati <sbarati@apple.com>
JSScript should keep the cache file locked for the duration of its existence and should truncate the cache when it is out of date
https://bugs.webkit.org/show_bug.cgi?id=195186
Reviewed by Keith Miller.
This patch makes it so that JSScript will keep its bytecode cache file
locked as long as the JSScript is alive. This makes it obvious that it's
safe to update that file, as it will only be used in a single VM, across
all processes, at a single time. We may be able to extend this in the future
if we can atomically update it across VMs/processes. However, we're choosing
more restricted semantics now as it's always easier to extend these semantics
in the future opposed to having to support the more flexible behavior
up front.
This patch also:
- Adds error messages if writing the cache fails. We don't expect this to
fail, but previously we would say we cached it even if write() fails.
- Removes the unused m_moduleKey field.
- Makes calling cacheBytecodeWithError with an already non-empty cache file fail.
In the future, we should extend this to just fill in the parts of the cache
that are not present. But we don't have the ability to do that yet, so we
just result in an error for now.
* API/JSScript.mm:
(-[JSScript dealloc]):
(-[JSScript readCache]):
(-[JSScript init]):
(-[JSScript writeCache:]):
* API/JSScriptInternal.h:
* API/tests/testapi.mm:
(testCacheFileIsExclusive):
(testCacheFileFailsWhenItsAlreadyCached):
(testObjectiveCAPI):
2019-03-06 Christopher Reid <chris.reid@sony.com>
Followups to (r242306): Use LockHolder instead of std::lock_guard on Remote Inspector Locks
https://bugs.webkit.org/show_bug.cgi?id=195381
Reviewed by Mark Lam.
Replacing std::lock_guard uses in Remote Inspector with WTF::LockHolder.
Also using `= { }` for struct initialization instead of memeset.
* inspector/remote/RemoteConnectionToTarget.cpp:
* inspector/remote/RemoteInspector.cpp:
* inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
* inspector/remote/cocoa/RemoteInspectorCocoa.mm:
* inspector/remote/cocoa/RemoteInspectorXPCConnection.mm:
* inspector/remote/glib/RemoteInspectorGlib.cpp:
* inspector/remote/playstation/RemoteInspectorPlayStation.cpp:
* inspector/remote/playstation/RemoteInspectorSocketClientPlayStation.cpp:
* inspector/remote/playstation/RemoteInspectorSocketPlayStation.cpp:
* inspector/remote/playstation/RemoteInspectorSocketServerPlayStation.cpp:
2019-03-06 Saam Barati <sbarati@apple.com>
Air::reportUsedRegisters must padInterference
https://bugs.webkit.org/show_bug.cgi?id=195303
<rdar://problem/48270343>
Reviewed by Keith Miller.
reportUsedRegisters uses reg liveness to eliminate loads/moves into dead
registers. However, liveness can report incorrect results in certain
scenarios when considering liveness at instruction boundaries. For example,
it can go wrong when an Inst has a LateUse of a register and the following
Inst has an EarlyDef of that same register. Such a scenario could lead us
to incorrectly say the register is not live-in to the first Inst. Pad
interference inserts Nops between such instruction boundaries that cause
this issue.
The test with this patch fixes the issue in reportUsedRegisters. This patch
also conservatively makes it so that lowerAfterRegAlloc calls padInterference
since it also reasons about liveness.
* b3/air/AirLowerAfterRegAlloc.cpp:
(JSC::B3::Air::lowerAfterRegAlloc):
* b3/air/AirPadInterference.h:
* b3/air/AirReportUsedRegisters.cpp:
(JSC::B3::Air::reportUsedRegisters):
* b3/testb3.cpp:
(JSC::B3::testReportUsedRegistersLateUseNotDead):
(JSC::B3::run):
2019-03-06 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] AI should not propagate AbstractValue relying on constant folding phase
https://bugs.webkit.org/show_bug.cgi?id=195375
Reviewed by Saam Barati.
MakeRope rule in AI attempts to propagate the node, which will be produced after constant folding phase runs.
This is wrong since we do not guarantee that constant folding phase runs after AI runs (e.g. DFGSpeculativeJIT
and FTLLowerDFGToB3 run AI). This results in the bug that the value produced at runtime is different from the
proven constant value in AI. In the attached test, AI says the value is SpecStringIdent while the resulted value
at runtime is SpecStringVar, resulting in wrong MakeRope code. This patch removes the path propagating the node
relying on constant folding phase.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2019-03-05 Saam barati <sbarati@apple.com>
op_switch_char broken for rope strings after JSRopeString layout rewrite
https://bugs.webkit.org/show_bug.cgi?id=195339
<rdar://problem/48592545>
Reviewed by Yusuke Suzuki.
When we did the JSString rewrite, we accidentally broke LLInt's switch_char
for rope strings. That change made it so that we always go to the slow path
for ropes. That's wrong. The slow path should only be taken when the rope
is of length 1. For lengths other than 1, we need to fall through to the
default case. This patch fixes this.
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/JSString.h:
2019-03-05 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Should check exception for JSString::toExistingAtomicString
https://bugs.webkit.org/show_bug.cgi?id=195337
Reviewed by Keith Miller, Saam Barati, and Mark Lam.
We missed the exception check for JSString::toExistingAtomicString while it can resolve
a rope and throw an OOM exception. This patch adds necessary exception checks. This patch
fixes test failures in debug build, reported in https://bugs.webkit.org/show_bug.cgi?id=194375#c93.
* dfg/DFGOperations.cpp:
* jit/JITOperations.cpp:
(JSC::getByVal):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::getByVal):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
2019-03-04 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, build fix for debug builds after r242397
* runtime/JSString.h:
2019-03-04 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Store bits for JSRopeString in 3 stores
https://bugs.webkit.org/show_bug.cgi?id=195234
Reviewed by Saam Barati.
This patch cleans up the initialization of JSRopeString fields in DFG and FTL.
Previously, we store some part of data separately. Instead, this patch calculates
the data first by bit operations and store calculated data with fewer stores.
This patch also cleans up is8Bit and isSubstring flags. We put them in lower bits
of the first fiber instead of the upper 16 bits. Since we only have 3 bit flags, (isRope, is8Bit, isSubstring),
we can put them into the lower 3 bits, they are always empty due to alignment.
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateImpl): A bit clean up of StringLength IC to give a chance of unnecessary mov removal.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::canBeRope):
(JSC::DFG::SpeculativeJIT::compileGetArrayLength):
(JSC::DFG::SpeculativeJIT::compileMakeRope):
* dfg/DFGSpeculativeJIT.h:
* ftl/FTLAbstractHeapRepository.cpp:
(JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
(JSC::FTL::DFG::LowerDFGToB3::isRopeString):
(JSC::FTL::DFG::LowerDFGToB3::isNotRopeString):
* runtime/JSString.cpp:
(JSC::JSString::visitChildren):
* runtime/JSString.h:
(JSC::JSString::is8Bit const):
(JSC::JSString::isSubstring const):
* tools/JSDollarVM.cpp:
(JSC::functionCreateNullRopeString):
(JSC::JSDollarVM::finishCreation):
2019-03-04 Joseph Pecoraro <pecoraro@apple.com>
ITMLKit Inspector: Data Bindings / Associated Data for nodes
https://bugs.webkit.org/show_bug.cgi?id=195290
<rdar://problem/48304019>
Reviewed by Devin Rousso.
* inspector/protocol/DOM.json:
2019-03-04 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Make Reflect lazily-allocated by dropping @Reflect references from builtin JS
https://bugs.webkit.org/show_bug.cgi?id=195250
Reviewed by Saam Barati.
By removing @Reflect from builtin JS, we can make Reflect object allocation lazy.
We move @ownKeys function from @Reflect to @Object to remove @Reflect reference.
We also remove m_intlObject field from JSGlobalObject since we no longer use it.
* builtins/BuiltinNames.h:
* builtins/GlobalOperations.js:
(globalPrivate.copyDataProperties):
(globalPrivate.copyDataPropertiesNoExclusions):
* runtime/JSGlobalObject.cpp:
(JSC::createReflectProperty):
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructor::finishCreation):
(JSC::objectConstructorOwnKeys):
* runtime/ReflectObject.cpp:
(JSC::ReflectObject::finishCreation):
2019-03-04 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Offer @makeTypeError instead of exposing @TypeError
https://bugs.webkit.org/show_bug.cgi?id=193858
Reviewed by Mark Lam.
Instead of exposing @TypeError, we expose @makeTypeError function.
And we make TypeError and Error lazily-allocated objects in non JIT environment.
In JIT environment, only TypeError becomes lazily-allocated since WebAssembly errors
touch Error prototype anyway. But we can make them lazy in a subsequent patch.
* builtins/AsyncFromSyncIteratorPrototype.js:
* builtins/AsyncGeneratorPrototype.js:
(globalPrivate.asyncGeneratorEnqueue):
* builtins/BuiltinNames.h:
* builtins/PromiseOperations.js:
(globalPrivate.createResolvingFunctions.resolve):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::initializeErrorConstructor):
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::errorPrototype const):
(JSC::JSGlobalObject::errorStructure const):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncMakeTypeError):
* runtime/JSGlobalObjectFunctions.h:
2019-03-04 Carlos Garcia Campos <cgarcia@igalia.com>
[GLib] Returning G_TYPE_OBJECT from a constructor does not work
https://bugs.webkit.org/show_bug.cgi?id=195206
Reviewed by Žan Doberšek.
We are freeing the newly created object before returning from the constructor.
* API/glib/JSCCallbackFunction.cpp:
(JSC::JSCCallbackFunction::construct):
2019-03-02 Darin Adler <darin@apple.com>
Retire legacy dtoa function and DecimalNumber class
https://bugs.webkit.org/show_bug.cgi?id=195253
Reviewed by Daniel Bates.
* runtime/NumberPrototype.cpp:
(JSC::numberProtoFuncToExponential): Removed dependency on NumberToStringBufferLength,
using NumberToStringBuffer instead. Also tweaked style of implementation a bit.
2019-03-01 Darin Adler <darin@apple.com>
Finish removing String::format
https://bugs.webkit.org/show_bug.cgi?id=194893
Reviewed by Daniel Bates.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::nameForRegister): Use makeString instead of String::format,
using the new "pad" function.
2019-03-01 Christopher Reid <chris.reid@sony.com>
[PlayStation] Upstream playstation's remote inspector server
https://bugs.webkit.org/show_bug.cgi?id=193806
Reviewed by Joseph Pecoraro.
Upstreaming PlayStation's Remote Inspector implementation.
It is using a JSON RPC protocol over TCP sockets.
This inspector implementation is planned to also support running on a WinCairo Client and Server.
* PlatformPlayStation.cmake:
* SourcesGTK.txt:
* SourcesWPE.txt:
* inspector/remote/RemoteConnectionToTarget.cpp: Renamed from Source/JavaScriptCore/inspector/remote/glib/RemoteConnectionToTargetGlib.cpp.
* inspector/remote/RemoteInspector.h:
* inspector/remote/playstation/RemoteInspectorConnectionClient.h: Added.
* inspector/remote/playstation/RemoteInspectorConnectionClientPlayStation.cpp: Added.
* inspector/remote/playstation/RemoteInspectorMessageParser.h: Added.
* inspector/remote/playstation/RemoteInspectorMessageParserPlayStation.cpp: Added.
* inspector/remote/playstation/RemoteInspectorPlayStation.cpp: Added.
* inspector/remote/playstation/RemoteInspectorServer.h: Added.
* inspector/remote/playstation/RemoteInspectorServerPlayStation.cpp: Added.
* inspector/remote/playstation/RemoteInspectorSocket.h: Added.
* inspector/remote/playstation/RemoteInspectorSocketClient.h: Added.
* inspector/remote/playstation/RemoteInspectorSocketClientPlayStation.cpp: Added.
* inspector/remote/playstation/RemoteInspectorSocketPlayStation.cpp: Added.
* inspector/remote/playstation/RemoteInspectorSocketServer.h: Added.
* inspector/remote/playstation/RemoteInspectorSocketServerPlayStation.cpp: Added.
2019-03-01 Saam Barati <sbarati@apple.com>
Create SPI to crash if a JSC VM is created
https://bugs.webkit.org/show_bug.cgi?id=195231
<rdar://problem/47717990>
Reviewed by Mark Lam.
* API/JSVirtualMachine.mm:
(+[JSVirtualMachine setCrashOnVMCreation:]):
* API/JSVirtualMachinePrivate.h:
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::setCrashOnVMCreation):
* runtime/VM.h:
2019-03-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Fix FTL build on ARM32_64 by adding stubs for JSRopeString::offsetOfXXX
https://bugs.webkit.org/show_bug.cgi?id=195235
Reviewed by Saam Barati.
This is a workaround until https://bugs.webkit.org/show_bug.cgi?id=195234 is done.
* runtime/JSString.h:
2019-03-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use runtime calls for DFG MakeRope if !CPU(ADDRESS64)
https://bugs.webkit.org/show_bug.cgi?id=195221
Reviewed by Mark Lam.
ARM32_64 builds DFG 64bit, but the size of address is 32bit. Make DFG MakeRope a runtime call not only for DFG 32_64,
but also DFG 64 with !CPU(ADDRESS64). This patch unifies compileMakeRope again, and use a runtime call for !CPU(ADDRESS64).
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileMakeRope):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compileMakeRope): Deleted.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compileMakeRope): Deleted.
2019-03-01 Justin Fan <justin_fan@apple.com>
[Web GPU] 32-bit builds broken by attempt to disable WebGPU on 32-bit
https://bugs.webkit.org/show_bug.cgi?id=195191
Rubber-stamped by Dean Jackson.
Dropping support for 32-bit entirely, so I'm intentionally leaving 32-bit broken.
* Configurations/FeatureDefines.xcconfig:
2019-03-01 Dominik Infuehr <dinfuehr@igalia.com>
Fix debug builds with GCC
https://bugs.webkit.org/show_bug.cgi?id=195205
Unreviewed. Fix debug builds in GCC by removing
the constexpr-keyword for this function.
* runtime/CachedTypes.cpp:
(JSC::tagFromSourceCodeType):
2019-03-01 Dominik Infuehr <dinfuehr@igalia.com>
[ARM] Fix assembler warnings in ctiMasmProbeTrampoline
https://bugs.webkit.org/show_bug.cgi?id=195164
Reviewed by Mark Lam.
Short branches in IT blocks are deprecated in AArch32. In addition the
the conditional branch was the only instruction in the IT block. Short
branches are able to encode the condition code themselves, the additional
IT instruction is not needed.
The assembler was also warning that writing into APSR without a bitmask
was deprecated. Therefore use APSR_nzcvq instead, this generates the same
instruction encoding.
* assembler/MacroAssemblerARMv7.cpp:
2019-02-28 Tadeu Zagallo <tzagallo@apple.com>
Remove CachedPtr::m_isEmpty and CachedOptional::m_isEmpty fields
https://bugs.webkit.org/show_bug.cgi?id=194999
Reviewed by Saam Barati.
These fields are unnecessary, since we can just check that m_offset
has not been initialized (I added VariableLengthObject::isEmpty for
that). They also add 7-byte padding to these classes, which is pretty
bad given how frequently CachedPtr is used.
* runtime/CachedTypes.cpp:
(JSC::CachedObject::operator new[]):
(JSC::VariableLengthObject::allocate):
(JSC::VariableLengthObject::isEmpty const):
(JSC::CachedPtr::encode):
(JSC::CachedPtr::decode const):
(JSC::CachedPtr::get const):
(JSC::CachedOptional::encode):
(JSC::CachedOptional::decode const):
(JSC::CachedOptional::decodeAsPtr const):
2019-02-28 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] sizeof(JSString) should be 16
https://bugs.webkit.org/show_bug.cgi?id=194375
Reviewed by Saam Barati.
This patch reduces sizeof(JSString) from 24 to 16 to fit it into GC heap cell atom. And it also reduces sizeof(JSRopeString) from 48 to 32.
Both classes cut 16 bytes per instance in GC allocation. This new layout is used in 64bit architectures which has little endianess.
JSString no longer has length and flags directly. JSString has String, and we query information to this String instead of holding duplicate
information in JSString. We embed isRope bit into this String's pointer so that we can convert JSRopeString to JSString in an atomic manner.
We emit store-store fence before we put String pointer. This should exist even before this patch, so this patch also fixes one concurrency issue.
The old JSRopeString separately had JSString* fibers along with String. In this patch, we merge the first JSString* fiber and String pointer
storage into one to reduce the size of JSRopeString. JSRopeString has three pointer width storage. We pick 48bit effective address of JSString*
fibers to compress three fibers + length + flags into three pointer width storage.
In 64bit architecture, JSString and JSRopeString have the following memory layout to make sizeof(JSString) == 16 and sizeof(JSRopeString) == 32.
JSString has only one pointer. We use it for String. length() and is8Bit() queries go to StringImpl. In JSRopeString, we reuse the above pointer
place for the 1st fiber. JSRopeString has three fibers so its size is 48. To keep length and is8Bit flag information in JSRopeString, JSRopeString
encodes these information into the fiber pointers. is8Bit flag is encoded in the 1st fiber pointer. length is embedded directly, and two fibers
are compressed into 12bytes. isRope information is encoded in the first fiber's LSB.
Since length of JSRopeString should be frequently accessed compared to each fiber, we put length in contiguous 32byte field, and compress 2nd
and 3rd fibers into the following 80byte fields. One problem is that now 2nd and 3rd fibers are split. Storing and loading 2nd and 3rd fibers
are not one pointer load operation. To make concurrent collector work correctly, we must initialize 2nd and 3rd fibers at JSRopeString creation
and we must not modify these part later.
0 8 10 16 32 48
JSString [ ID ][ header ][ String pointer 0]
JSRopeString [ ID ][ header ][ flags ][ 1st fiber 1][ length ][2nd lower32][2nd upper16][3rd lower16][3rd upper32]
^
isRope bit
Since fibers in JSRopeString are not initialized in atomic pointer store manner, we must initialize all the fiber fields at JSRopeString creation.
To achieve this, we modify our JSRopeString::RopeBuilder implementation not to create half-baked JSRopeString.
This patch also makes an empty JSString singleton per VM. This makes evaluation of JSString in boolean context one pointer comparison. This is
critical in this change since this patch enlarges the code necessary to get length from JSString in JIT. Without this guarantee, our code of boolean
context evaluation is bloated. This patch hides all the JSString::create and JSRopeString::create in the private permission. JSString and JSRopeString
creation is only allowed from jsString and related helper functions and they return a singleton empty JSString if the length is zero. We also change
JSRopeString::RopeBuilder not to construct an empty JSRopeString.
This patch is performance neutral in Speedometer2 and JetStream2. And it improves RAMification by 2.7%.
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::storeZero16):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::storeZero16):
(JSC::MacroAssemblerX86Common::store16):
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateImpl):
* bytecode/InlineAccess.cpp:
(JSC::InlineAccess::dumpCacheSizesAndCrash):
(JSC::linkCodeInline):
(JSC::InlineAccess::isCacheableStringLength):
(JSC::InlineAccess::generateStringLength):
* bytecode/InlineAccess.h:
(JSC::InlineAccess::sizeForPropertyAccess):
(JSC::InlineAccess::sizeForPropertyReplace):
(JSC::InlineAccess::sizeForLengthAccess):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileStringSlice):
(JSC::DFG::SpeculativeJIT::compileToLowerCase):
(JSC::DFG::SpeculativeJIT::compileGetCharCodeAt):
(JSC::DFG::SpeculativeJIT::compileGetByValOnString):
(JSC::DFG::SpeculativeJIT::compileStringEquality):
(JSC::DFG::SpeculativeJIT::compileStringZeroLength):
(JSC::DFG::SpeculativeJIT::compileLogicalNotStringOrOther):
(JSC::DFG::SpeculativeJIT::emitStringBranch):
(JSC::DFG::SpeculativeJIT::emitStringOrOtherBranch):
(JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
(JSC::DFG::SpeculativeJIT::compileGetArrayLength):
(JSC::DFG::SpeculativeJIT::emitPopulateSliceIndex):
(JSC::DFG::SpeculativeJIT::compileArraySlice):
(JSC::DFG::SpeculativeJIT::compileArrayIndexOf):
(JSC::DFG::SpeculativeJIT::speculateStringIdentAndLoadStorage):
(JSC::DFG::SpeculativeJIT::emitSwitchCharStringJump):
(JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):
(JSC::DFG::SpeculativeJIT::compileMakeRope): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::compileMakeRope):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::compileMakeRope):
* ftl/FTLAbstractHeapRepository.cpp:
(JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
(JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
(JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt):
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
(JSC::FTL::DFG::LowerDFGToB3::compileStringToUntypedStrictEquality):
(JSC::FTL::DFG::LowerDFGToB3::compileSwitch):
(JSC::FTL::DFG::LowerDFGToB3::mapHashString):
(JSC::FTL::DFG::LowerDFGToB3::compileMapHash):
(JSC::FTL::DFG::LowerDFGToB3::compileHasOwnProperty):
(JSC::FTL::DFG::LowerDFGToB3::compileStringSlice):
(JSC::FTL::DFG::LowerDFGToB3::compileToLowerCase):
(JSC::FTL::DFG::LowerDFGToB3::stringsEqual):
(JSC::FTL::DFG::LowerDFGToB3::boolify):
(JSC::FTL::DFG::LowerDFGToB3::switchString):
(JSC::FTL::DFG::LowerDFGToB3::isRopeString):
(JSC::FTL::DFG::LowerDFGToB3::isNotRopeString):
(JSC::FTL::DFG::LowerDFGToB3::speculateStringIdent):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitConvertValueToBoolean):
(JSC::AssemblyHelpers::branchIfValue):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::branchIfRopeStringImpl):
(JSC::AssemblyHelpers::branchIfNotRopeStringImpl):
* jit/JITInlines.h:
(JSC::JIT::emitLoadCharacterString):
* jit/Repatch.cpp:
(JSC::tryCacheGetByID):
* jit/ThunkGenerators.cpp:
(JSC::stringGetByValGenerator):
(JSC::stringCharLoad):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/JSString.cpp:
(JSC::JSString::createEmptyString):
(JSC::JSRopeString::RopeBuilder<RecordOverflow>::expand):
(JSC::JSString::dumpToStream):
(JSC::JSString::estimatedSize):
(JSC::JSString::visitChildren):
(JSC::JSRopeString::resolveRopeInternal8 const):
(JSC::JSRopeString::resolveRopeInternal8NoSubstring const):
(JSC::JSRopeString::resolveRopeInternal16 const):
(JSC::JSRopeString::resolveRopeInternal16NoSubstring const):
(JSC::JSRopeString::resolveRopeToAtomicString const):
(JSC::JSRopeString::convertToNonRope const):
(JSC::JSRopeString::resolveRopeToExistingAtomicString const):
(JSC::JSRopeString::resolveRopeWithFunction const):
(JSC::JSRopeString::resolveRope const):
(JSC::JSRopeString::resolveRopeSlowCase8 const):
(JSC::JSRopeString::resolveRopeSlowCase const):
(JSC::JSRopeString::outOfMemory const):
(JSC::JSRopeString::visitFibers): Deleted.
(JSC::JSRopeString::clearFibers const): Deleted.
* runtime/JSString.h:
(JSC::JSString::uninitializedValueInternal const):
(JSC::JSString::valueInternal const):
(JSC::JSString::JSString):
(JSC::JSString::finishCreation):
(JSC::JSString::create):
(JSC::JSString::offsetOfValue):
(JSC::JSString::isRope const):
(JSC::JSString::is8Bit const):
(JSC::JSString::length const):
(JSC::JSString::tryGetValueImpl const):
(JSC::JSString::toAtomicString const):
(JSC::JSString::toExistingAtomicString const):
(JSC::JSString::value const):
(JSC::JSString::tryGetValue const):
(JSC::JSRopeString::unsafeView const):
(JSC::JSRopeString::viewWithUnderlyingString const):
(JSC::JSString::unsafeView const):
(JSC::JSString::viewWithUnderlyingString const):
(JSC::JSString::offsetOfLength): Deleted.
(JSC::JSString::offsetOfFlags): Deleted.
(JSC::JSString::setIs8Bit const): Deleted.
(JSC::JSString::setLength): Deleted.
(JSC::JSString::string): Deleted.
(JSC::jsStringBuilder): Deleted.
* runtime/JSStringInlines.h:
(JSC::JSString::~JSString):
(JSC::JSString::equal const):
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncToString):
* runtime/RegExpMatchesArray.h:
(JSC::createRegExpMatchesArray):
* runtime/RegExpObjectInlines.h:
(JSC::collectMatches):
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoFuncSplitFast):
* runtime/SmallStrings.cpp:
(JSC::SmallStrings::initializeCommonStrings):
(JSC::SmallStrings::createEmptyString): Deleted.
* runtime/SmallStrings.h:
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncSlice):
* runtime/StringPrototypeInlines.h: Added.
(JSC::stringSlice):
2019-02-28 Saam barati <sbarati@apple.com>
Unreviewed. Attempt windows build fix after r242239.
* runtime/CachedTypes.cpp:
(JSC::tagFromSourceCodeType):
2019-02-28 Mark Lam <mark.lam@apple.com>
In cloop.rb, rename :int and :uint to :intptr and :uintptr.
https://bugs.webkit.org/show_bug.cgi?id=195183
Reviewed by Yusuke Suzuki.
Also changed intMemRef and uintMemRef to intptrMemRef and uintptrMemRef respectively.
* offlineasm/cloop.rb:
2019-02-28 Saam barati <sbarati@apple.com>
Make JSScript:cacheBytecodeWithError update the cache when the script changes
https://bugs.webkit.org/show_bug.cgi?id=194912
Reviewed by Mark Lam.
Prior to this patch, the JSScript SPI would never check if its cached
bytecode were still valid. This would lead the cacheBytecodeWithError
succeeding even if the underlying cache were stale. This patch fixes
that by making JSScript check if the cache is still valid. If it's not,
we will cache bytecode when cacheBytecodeWithError is invoked.
* API/JSScript.mm:
(-[JSScript readCache]):
(-[JSScript writeCache:]):
* API/tests/testapi.mm:
(testBytecodeCacheWithSameCacheFileAndDifferentScript):
(testObjectiveCAPI):
* runtime/CachedTypes.cpp:
(JSC::Decoder::Decoder):
(JSC::VariableLengthObject::buffer const):
(JSC::CachedPtr::decode const):
(JSC::tagFromSourceCodeType):
(JSC::GenericCacheEntry::isUpToDate const):
(JSC::CacheEntry::isStillValid const):
(JSC::GenericCacheEntry::decode const):
(JSC::GenericCacheEntry::isStillValid const):
(JSC::encodeCodeBlock):
(JSC::decodeCodeBlockImpl):
(JSC::isCachedBytecodeStillValid):
* runtime/CachedTypes.h:
* runtime/CodeCache.cpp:
(JSC::sourceCodeKeyForSerializedBytecode):
(JSC::sourceCodeKeyForSerializedProgram):
(JSC::sourceCodeKeyForSerializedModule):
(JSC::serializeBytecode):
* runtime/CodeCache.h:
(JSC::CodeCacheMap::fetchFromDiskImpl):
* runtime/Completion.cpp:
(JSC::generateProgramBytecode):
(JSC::generateBytecode): Deleted.
* runtime/Completion.h:
2019-02-28 Mark Lam <mark.lam@apple.com>
cloop.rb shift mask should depend on the word size being shifted.
https://bugs.webkit.org/show_bug.cgi?id=195181
<rdar://problem/48484164>
Reviewed by Yusuke Suzuki.
Previously, we're always masking the shift amount with 0x1f. This is only correct
for 32-bit words. For 64-bit words, the mask should be 0x3f. For pointer sized
shifts, the mask depends on sizeof(uintptr_t).
* offlineasm/cloop.rb:
2019-02-28 Justin Fan <justin_fan@apple.com>
[Web GPU] Enable Web GPU only on 64-bit
https://bugs.webkit.org/show_bug.cgi?id=195139
Because Metal is only supported on 64 bit apps.
Unreviewed build fix.
* Configurations/FeatureDefines.xcconfig:
2019-02-27 Mark Lam <mark.lam@apple.com>
The parser is failing to record the token location of new in new.target.
https://bugs.webkit.org/show_bug.cgi?id=195127
<rdar://problem/39645578>
Reviewed by Yusuke Suzuki.
Also adjust the token location for the following to be as shown:
new.target
^
super
^
import.meta
^
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseMemberExpression):
2019-02-27 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] mustHandleValues for dead bytecode locals should be ignored in DFG phases
https://bugs.webkit.org/show_bug.cgi?id=195144
<rdar://problem/47595961>
Reviewed by Mark Lam.
DFGMaximalFlushInsertionPhase inserts Flush for all the locals at the end of basic blocks. This enlarges the live ranges of
locals in DFG, and it sometimes makes DFG value live while it is dead in bytecode. The issue happens when we use mustHandleValues
to widen AbstractValue in CFAPhase. At that time, DFG tells "this value is live in DFG", but it may be dead in the bytecode level.
At that time, we attempt to merge AbstractValue with dead mustHandleValue, which is cleared as jsUndefined() in
DFG::Plan::cleanMustHandleValuesIfNecessary before start compilation, and crash because jsUndefined() may be irrelevant to the FlushFormat
in VariableAccessData.
This patch makes the type of mustHandleValues Operands<Optional<JSValue>>. We clear dead JSValues in DFG::Plan::cleanMustHandleValuesIfNecessary.
And we skip handling dead mustHandleValue in DFG phases.
* bytecode/Operands.h:
(JSC::Operands::isLocal const):
(JSC::Operands::isVariable const): Deleted.
* dfg/DFGCFAPhase.cpp:
(JSC::DFG::CFAPhase::injectOSR):
* dfg/DFGDriver.cpp:
(JSC::DFG::compileImpl):
(JSC::DFG::compile):
* dfg/DFGDriver.h:
* dfg/DFGJITCode.cpp:
(JSC::DFG::JITCode::reconstruct):
* dfg/DFGJITCode.h:
* dfg/DFGOperations.cpp:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::Plan):
(JSC::DFG::Plan::checkLivenessAndVisitChildren):
(JSC::DFG::Plan::cleanMustHandleValuesIfNecessary):
* dfg/DFGPlan.h:
(JSC::DFG::Plan::mustHandleValues const):
* dfg/DFGPredictionInjectionPhase.cpp:
(JSC::DFG::PredictionInjectionPhase::run):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::disableHoistingAcrossOSREntries):
* ftl/FTLOSREntry.cpp:
(JSC::FTL::prepareOSREntry):
* jit/JITOperations.cpp:
2019-02-27 Simon Fraser <simon.fraser@apple.com>
Roll out r242014; it caused crashes in compositing logging (webkit.org/b/195141)
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::nameForRegister):
2019-02-27 Robin Morisset <rmorisset@apple.com>
DFG: Loop-invariant code motion (LICM) should not hoist dead code
https://bugs.webkit.org/show_bug.cgi?id=194945
<rdar://problem/48311657>
Reviewed by Saam Barati.
* dfg/DFGLICMPhase.cpp:
(JSC::DFG::LICMPhase::run):
2019-02-27 Antoine Quint <graouts@apple.com>
Support Pointer Events on macOS
https://bugs.webkit.org/show_bug.cgi?id=195008
<rdar://problem/47454419>
Reviewed by Dean Jackson.
* Configurations/FeatureDefines.xcconfig:
2019-02-26 Mark Lam <mark.lam@apple.com>
Remove poisons in JSCPoison and uses of them.
https://bugs.webkit.org/show_bug.cgi?id=195082
Reviewed by Yusuke Suzuki.
Also removed unused poisoning code in WriteBarrier, AssemblyHelpers,
DFG::SpeculativeJIT, FTLLowerDFGToB3, and FTL::Output.
* API/JSAPIWrapperObject.h:
(JSC::JSAPIWrapperObject::wrappedObject):
* API/JSCallbackFunction.h:
* API/JSCallbackObject.h:
* API/glib/JSAPIWrapperGlobalObject.h:
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateWithGuard):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
(JSC::DFG::SpeculativeJIT::compileGetArrayLength):
(JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
(JSC::DFG::SpeculativeJIT::compileGetExecutable):
(JSC::DFG::SpeculativeJIT::compileCreateThis):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::TrustedImmPtr::weakPoisonedPointer): Deleted.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetExecutable):
(JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
(JSC::FTL::DFG::LowerDFGToB3::weakPointer):
(JSC::FTL::DFG::LowerDFGToB3::dynamicPoison): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::dynamicPoisonOnLoadedType): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::dynamicPoisonOnType): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::weakPoisonedPointer): Deleted.
* ftl/FTLOutput.h:
(JSC::FTL::Output::weakPoisonedPointer): Deleted.
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitDynamicPoison): Deleted.
(JSC::AssemblyHelpers::emitDynamicPoisonOnLoadedType): Deleted.
(JSC::AssemblyHelpers::emitDynamicPoisonOnType): Deleted.
* jit/AssemblyHelpers.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_create_this):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitScopedArgumentsGetByVal):
* jit/Repatch.cpp:
(JSC::linkPolymorphicCall):
* jit/ThunkGenerators.cpp:
(JSC::virtualThunkFor):
(JSC::nativeForGenerator):
(JSC::boundThisNoArgsFunctionCallGenerator):
* parser/UnlinkedSourceCode.h:
* runtime/ArrayPrototype.h:
* runtime/CustomGetterSetter.h:
(JSC::CustomGetterSetter::getter const):
(JSC::CustomGetterSetter::setter const):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::getCallData):
(JSC::InternalFunction::getConstructData):
* runtime/InternalFunction.h:
(JSC::InternalFunction::nativeFunctionFor):
* runtime/JSArrayBuffer.h:
* runtime/JSBoundFunction.h:
* runtime/JSCPoison.cpp: Removed.
* runtime/JSCPoison.h: Removed.
* runtime/JSFunction.h:
* runtime/JSGlobalObject.h:
* runtime/JSScriptFetchParameters.h:
* runtime/JSScriptFetcher.h:
* runtime/JSString.h:
* runtime/NativeExecutable.cpp:
(JSC::NativeExecutable::hashFor const):
* runtime/NativeExecutable.h:
* runtime/Options.h:
* runtime/ScopedArguments.h:
* runtime/Structure.cpp:
(JSC::StructureTransitionTable::setSingleTransition):
* runtime/StructureTransitionTable.h:
(JSC::StructureTransitionTable::map const):
(JSC::StructureTransitionTable::weakImpl const):
(JSC::StructureTransitionTable::setMap):
* runtime/WriteBarrier.h:
* wasm/WasmB3IRGenerator.cpp:
* wasm/WasmInstance.h:
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::createJSToWasmWrapper):
* wasm/js/JSWebAssemblyCodeBlock.h:
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
(JSC::JSWebAssemblyInstance::visitChildren):
* wasm/js/JSWebAssemblyInstance.h:
* wasm/js/JSWebAssemblyMemory.h:
* wasm/js/JSWebAssemblyModule.h:
* wasm/js/JSWebAssemblyTable.cpp:
(JSC::JSWebAssemblyTable::JSWebAssemblyTable):
(JSC::JSWebAssemblyTable::grow):
(JSC::JSWebAssemblyTable::clearFunction):
* wasm/js/JSWebAssemblyTable.h:
* wasm/js/WasmToJS.cpp:
(JSC::Wasm::materializeImportJSCell):
(JSC::Wasm::handleBadI64Use):
(JSC::Wasm::wasmToJS):
* wasm/js/WebAssemblyFunctionBase.h:
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
(JSC::WebAssemblyModuleRecord::evaluate):
* wasm/js/WebAssemblyModuleRecord.h:
* wasm/js/WebAssemblyToJSCallee.h:
* wasm/js/WebAssemblyWrapperFunction.h:
2019-02-26 Mark Lam <mark.lam@apple.com>
wasmToJS() should purify incoming NaNs.
https://bugs.webkit.org/show_bug.cgi?id=194807
<rdar://problem/48189132>
Reviewed by Saam Barati.
* runtime/JSCJSValue.h:
(JSC::jsNumber):
* runtime/TypedArrayAdaptors.h:
(JSC::IntegralTypedArrayAdaptor::toJSValue):
* wasm/js/WasmToJS.cpp:
(JSC::Wasm::wasmToJS):
2019-02-26 Dominik Infuehr <dinfuehr@igalia.com>
Fix warnings on ARM and MIPS
https://bugs.webkit.org/show_bug.cgi?id=195049
Reviewed by Mark Lam.
Fix all warnings on ARM and MIPS.
* assembler/MacroAssemblerPrinter.cpp:
(JSC::Printer::printMemory):
* assembler/testmasm.cpp:
(JSC::testProbeModifiesStackValues):
* bytecode/InByIdStatus.cpp:
(JSC::InByIdStatus::computeFor):
* runtime/CachedTypes.cpp:
(JSC::VariableLengthObject::buffer const):
* runtime/JSBigInt.h:
* tools/JSDollarVM.cpp:
(JSC::codeBlockFromArg):
2019-02-26 Mark Lam <mark.lam@apple.com>
Misc cleanup in StructureIDTable after r242096.
https://bugs.webkit.org/show_bug.cgi?id=195063
Reviewed by Saam Barati.
* runtime/StructureIDTable.cpp:
(JSC::StructureIDTable::allocateID):
- RELEASE_ASSERT that the StructureID allocation will succeed.
* runtime/StructureIDTable.h:
(JSC::StructureIDTable::decode):
(JSC::StructureIDTable::encode):
- Add back a comment that Yusuke requested but was lost when the patch was rolled
out and relanded.
- Applied bitwise_casts that Saam requested.
2019-02-26 Mark Lam <mark.lam@apple.com>
Gardening: 32-bit build fix after r242096.
https://bugs.webkit.org/show_bug.cgi?id=194989
Not reviewed.
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitLoadStructure):
2019-02-26 Mark Lam <mark.lam@apple.com>
Unpoison MacroAssemblerCodePtr, ClassInfo pointers, and a few other things.
https://bugs.webkit.org/show_bug.cgi?id=195039
Reviewed by Saam Barati.
1. Unpoison MacroAssemblerCodePtrs, ReturnAddressPtr.
2. Replace PoisonedClassInfoPtr with ClassInfo*.
3. Replace PoisonedMasmPtr with const void*.
4. Remove all references to CodeBlockPoison, JITCodePoison, and GlobalDataPoison.
* API/JSCallbackObject.h:
* API/JSObjectRef.cpp:
(classInfoPrivate):
* assembler/MacroAssemblerCodeRef.h:
(JSC::FunctionPtr::FunctionPtr):
(JSC::FunctionPtr::executableAddress const):
(JSC::FunctionPtr::retaggedExecutableAddress const):
(JSC::ReturnAddressPtr::ReturnAddressPtr):
(JSC::ReturnAddressPtr::value const):
(JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr):
(JSC::MacroAssemblerCodePtr::createFromExecutableAddress):
(JSC::MacroAssemblerCodePtr:: const):
(JSC::MacroAssemblerCodePtr::operator! const):
(JSC::MacroAssemblerCodePtr::operator== const):
(JSC::MacroAssemblerCodePtr::hash const):
(JSC::MacroAssemblerCodePtr::emptyValue):
(JSC::MacroAssemblerCodePtr::deletedValue):
(JSC::FunctionPtr<tag>::FunctionPtr):
(JSC::MacroAssemblerCodePtr::poisonedPtr const): Deleted.
* b3/B3LowerMacros.cpp:
* b3/testb3.cpp:
(JSC::B3::testInterpreter):
* dfg/DFGOSRExitCompilerCommon.h:
(JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCheckSubClass):
(JSC::DFG::SpeculativeJIT::compileNewStringObject):
(JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
(JSC::DFG::SpeculativeJIT::emitSwitchImm):
(JSC::DFG::SpeculativeJIT::emitSwitchCharStringJump):
(JSC::DFG::SpeculativeJIT::emitSwitchChar):
* dfg/DFGSpeculativeJIT.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNewStringObject):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitAllocateDestructibleObject):
* jit/ThunkGenerators.cpp:
(JSC::virtualThunkFor):
(JSC::boundThisNoArgsFunctionCallGenerator):
* runtime/JSCPoison.h:
* runtime/JSDestructibleObject.h:
(JSC::JSDestructibleObject::classInfo const):
* runtime/JSSegmentedVariableObject.h:
(JSC::JSSegmentedVariableObject::classInfo const):
* runtime/Structure.h:
* runtime/VM.h:
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addCall):
(JSC::Wasm::B3IRGenerator::addCallIndirect):
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToWasm):
2019-02-26 Mark Lam <mark.lam@apple.com>
[Re-landing] Add some randomness into the StructureID.
https://bugs.webkit.org/show_bug.cgi?id=194989
<rdar://problem/47975563>
Reviewed by Yusuke Suzuki.
1. On 64-bit, the StructureID will now be encoded as:
----------------------------------------------------------------
| 1 Nuke Bit | 24 StructureIDTable index bits | 7 entropy bits |
----------------------------------------------------------------
The entropy bits are chosen at random and assigned when a StructureID is
allocated.
2. Instead of Structure pointers, the StructureIDTable will now contain
encodedStructureBits, which is encoded as such:
----------------------------------------------------------------
| 7 entropy bits | 57 structure pointer bits |
----------------------------------------------------------------
The entropy bits here are the same 7 bits used in the encoding of the
StructureID for this structure entry in the StructureIDTable.
3. Retrieval of the structure pointer given a StructureID is now computed as
follows:
index = structureID >> 7; // with arithmetic shift.
encodedStructureBits = structureIDTable[index];
structure = encodedStructureBits ^ (structureID << 57);
We use an arithmetic shift for the right shift because that will preserve
the nuke bit in the high bit of the index if the StructureID was not
decontaminated before use as expected.
4. Remove unused function loadArgumentWithSpecificClass() in SpecializedThunkJIT.
5. Define StructureIDTable::m_size to be the number of allocated StructureIDs
instead of always being the same as m_capacity.
6. Change StructureIDTable::s_unusedID's value to 0.
Its previous value of unusedPointer i.e. 0xd1e7beef, does not make sense for
StructureID on 64-bit. Also, there was never any code that initializes unused
IDs to the s_unusedID. The only meaningful value for s_unusedID is 0, which
is the ID we'll get when the freelist is empty, prompting a resize of the
structureIDTable.
This patch appears to be perf neutral on JetStream 2 run via the cli on a
11" MacBook Air, 13" MacBook Pro, iPhone 6S, and iPhone XR.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::loadStructure):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::appendJSCellOrAuxiliary):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitLoadStructure):
* jit/AssemblyHelpers.h:
* jit/SpecializedThunkJIT.h:
(JSC::SpecializedThunkJIT::loadArgumentWithSpecificClass): Deleted.
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/StructureIDTable.cpp:
(JSC::StructureIDTable::StructureIDTable):
(JSC::StructureIDTable::makeFreeListFromRange):
(JSC::StructureIDTable::resize):
(JSC::StructureIDTable::allocateID):
(JSC::StructureIDTable::deallocateID):
* runtime/StructureIDTable.h:
(JSC::StructureIDTable::decode):
(JSC::StructureIDTable::encode):
(JSC::StructureIDTable::get):
(JSC::StructureIDTable::isValid):
2019-02-26 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r242071.
Breaks internal builds.
Reverted changeset:
"Add some randomness into the StructureID."
https://bugs.webkit.org/show_bug.cgi?id=194989
https://trac.webkit.org/changeset/242071
2019-02-26 Guillaume Emont <guijemont@igalia.com>
[JSC] Fix compilation on 32-bit platforms after r242071
https://bugs.webkit.org/show_bug.cgi?id=195042
Reviewed by Carlos Garcia Campos.
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitLoadStructure):
2019-02-26 Guillaume Emont <guijemont@igalia.com>
[JSC] Repeat string created from Array.prototype.join() take too much memory
https://bugs.webkit.org/show_bug.cgi?id=193912
Reviewed by Saam Barati.
Added a fast case in Array.prototype.join when the array is
uninitialized.
* runtime/ArrayPrototype.cpp:
(JSC::canUseFastJoin):
(JSC::fastJoin):
* runtime/JSStringInlines.h:
(JSC::repeatCharacter): moved from StringPrototype.cpp
* runtime/StringPrototype.cpp:
2019-02-25 Mark Lam <mark.lam@apple.com>
Add some randomness into the StructureID.
https://bugs.webkit.org/show_bug.cgi?id=194989
<rdar://problem/47975563>
Reviewed by Yusuke Suzuki.
1. On 64-bit, the StructureID will now be encoded as:
----------------------------------------------------------------
| 1 Nuke Bit | 24 StructureIDTable index bits | 7 entropy bits |
----------------------------------------------------------------
The entropy bits are chosen at random and assigned when a StructureID is
allocated.
2. Instead of Structure pointers, the StructureIDTable will now contain
encodedStructureBits, which is encoded as such:
----------------------------------------------------------------
| 7 entropy bits | 57 structure pointer bits |
----------------------------------------------------------------
The entropy bits here are the same 7 bits used in the encoding of the
StructureID for this structure entry in the StructureIDTable.
3. Retrieval of the structure pointer given a StructureID is now computed as
follows:
index = structureID >> 7; // with arithmetic shift.
encodedStructureBits = structureIDTable[index];
structure = encodedStructureBits ^ (structureID << 57);
We use an arithmetic shift for the right shift because that will preserve
the nuke bit in the high bit of the index if the StructureID was not
decontaminated before use as expected.
4. Remove unused function loadArgumentWithSpecificClass() in SpecializedThunkJIT.
5. Define StructureIDTable::m_size to be the number of allocated StructureIDs
instead of always being the same as m_capacity.
6. Change StructureIDTable::s_unusedID's value to 0.
Its previous value of unusedPointer i.e. 0xd1e7beef, does not make sense for
StructureID on 64-bit. Also, there was never any code that initializes unused
IDs to the s_unusedID. The only meaningful value for s_unusedID is 0, which
is the ID we'll get when the freelist is empty, prompting a resize of the
structureIDTable.
This patch appears to be perf neutral on JetStream 2 run via the cli on a
11" MacBook Air, 13" MacBook Pro, iPhone 6S, and iPhone XR.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::loadStructure):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::appendJSCellOrAuxiliary):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitLoadStructure):
* jit/AssemblyHelpers.h:
* jit/SpecializedThunkJIT.h:
(JSC::SpecializedThunkJIT::loadArgumentWithSpecificClass): Deleted.
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/StructureIDTable.cpp:
(JSC::StructureIDTable::StructureIDTable):
(JSC::StructureIDTable::makeFreeListFromRange):
(JSC::StructureIDTable::resize):
(JSC::StructureIDTable::allocateID):
(JSC::StructureIDTable::deallocateID):
* runtime/StructureIDTable.h:
(JSC::StructureIDTable::decode):
(JSC::StructureIDTable::encode):
(JSC::StructureIDTable::get):
(JSC::StructureIDTable::isValid):
2019-02-25 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Revert r226885 to make SlotVisitor creation lazy
https://bugs.webkit.org/show_bug.cgi?id=195013
Reviewed by Saam Barati.
We once changed SlotVisitor creation apriori to drop the lock. Also, it turns out that SlotVisitor is memory-consuming.
We should defer SlotVisitor creation until it is actually required. This patch reverts r226885. Even with this patch,
we still hold many SlotVisitors after we execute many parallel markers at least once. But recovering the feature of
dynamically allocating SlotVisitors helps further memory optimizations in this area.
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::runBeginPhase):
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::forEachSlotVisitor):
(JSC::Heap::numberOfSlotVisitors):
* heap/MarkingConstraintSolver.cpp:
(JSC::MarkingConstraintSolver::didVisitSomething const):
* heap/SlotVisitor.h:
2019-02-25 Saam Barati <sbarati@apple.com>
testb3 and testair should test O0/O1/O2
https://bugs.webkit.org/show_bug.cgi?id=194637
Reviewed by Mark Lam.
This patch makes it so that we run all tests in testair and testb3
in O0, O1, and O2. However, some tests are invalid for O0 and O1.
This patch makes it so we only run those tests in O2. These are
often tests that assert certain optimizations have occurred. There
are also a class of tests that rely on using patchpoints to stress
the register allocator into only a single valid allocation. The
O0, and sometimes O1, register allocators are not always good enough
to allocate such programs. To make these valid allocators to use, we rely
on the FTL and Wasm to not emit such patchpoints.
* b3/air/testair.cpp:
(main):
* b3/testb3.cpp:
(JSC::B3::compileProc):
(JSC::B3::testAddLoadTwice):
(JSC::B3::testMulLoadTwice):
(JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs):
(JSC::B3::testSimplePatchpointWithOuputClobbersFPArgs):
(JSC::B3::testPatchpointWithEarlyClobber):
(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::testLinearScanWithCalleeOnStack):
(JSC::B3::testCheckSelect):
(JSC::B3::testCheckSelectCheckSelect):
(JSC::B3::testCheckSelectAndCSE):
(JSC::B3::testLateRegister):
(JSC::B3::testReduceStrengthCheckBottomUseInAnotherBlock):
(JSC::B3::testSomeEarlyRegister):
(JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2):
(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::testLoadBaseIndexShift2):
(JSC::B3::testOptimizeMaterialization):
(JSC::B3::testLICMPure):
(JSC::B3::testLICMPureSideExits):
(JSC::B3::testLICMPureWritesPinned):
(JSC::B3::testLICMPureWrites):
(JSC::B3::testLICMReadsPinned):
(JSC::B3::testLICMReads):
(JSC::B3::testLICMPureNotBackwardsDominant):
(JSC::B3::testLICMPureNotBackwardsDominantFoiledByChild):
(JSC::B3::testLICMControlDependent):
(JSC::B3::testLICMControlDependentNotBackwardsDominant):
(JSC::B3::testLICMReadsWritesDifferentHeaps):
(JSC::B3::testWasmBoundsCheck):
(JSC::B3::run):
(main):
2019-02-25 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] stress/function-constructor-reading-from-global-lexical-environment.js fails in 32bit arch
https://bugs.webkit.org/show_bug.cgi?id=195030
<rdar://problem/48385088>
Reviewed by Saam Barati.
While LLInt64 has checkTDZInGlobalPutToScopeIfNecessary for op_put_to_scope GlobalLexicalVar to check the value in the variable slot is not empty,
this check is missing in LLInt32_64. Previously, this check was subsumed accidentally by the WatchpointSet check in GlobalLexicalVar in `notifyWrite`:
because no "put" attempt succeeds here, the status WatchpointSet was ClearWatchpoint, we always go to the slow path, and we always throw the TDZ error
before configuring the WatchpointSet in the slow path. But after r241862, WatchpointSet is not used under non-JIT configuration. This skips WatchpointSet
check and LLInt32_64 starts failing tests because of lack of checkTDZInGlobalPutToScopeIfNecessary. This patch adds checkTDZInGlobalPutToScopeIfNecessary
in LLInt32_64 too. This patch fixes the following four failing tests.
stress/function-constructor-reading-from-global-lexical-environment.js.bytecode-cache
stress/function-constructor-reading-from-global-lexical-environment.js.default
stress/global-lexical-variable-tdz.js.bytecode-cache
stress/global-lexical-variable-tdz.js.default
* llint/LowLevelInterpreter32_64.asm:
2019-02-25 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Make Intl fields lazily-allocated
https://bugs.webkit.org/show_bug.cgi?id=195022
Reviewed by Mark Lam.
This patch makes the following memory footprint optimization in IntlObject.
1. Make IntlObject fields including Intl.Collator lazily-allocated because we already removed direct references from JS builtins to these constructors (@Collator etc.).
2. Move LazyProperty<IntlObject, Structure> structures from IntlObject to JSGlobalObject. This makes sizeof(IntlObject) the same to the other ones of usual runtime Objects,
and drop one MarkedBlock.
* runtime/IntlCollatorConstructor.h:
* runtime/IntlDateTimeFormatConstructor.h:
* runtime/IntlNumberFormatConstructor.h:
* runtime/IntlObject.cpp:
(JSC::createCollatorConstructor):
(JSC::createNumberFormatConstructor):
(JSC::createDateTimeFormatConstructor):
(JSC::createPluralRulesConstructor):
(JSC::IntlObject::finishCreation):
(JSC::IntlObject::visitChildren): Deleted.
* runtime/IntlObject.h:
* runtime/IntlPluralRulesConstructor.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
(JSC::JSGlobalObject::defaultCollator):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::collatorStructure):
(JSC::JSGlobalObject::numberFormatStructure):
(JSC::JSGlobalObject::dateTimeFormatStructure):
(JSC::JSGlobalObject::pluralRulesStructure):
(JSC::JSGlobalObject::intlObject const): Deleted.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncDateTimeFormat):
* runtime/NumberPrototype.cpp:
(JSC::numberProtoFuncToLocaleString):
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncLocaleCompare):
2019-02-25 Tadeu Zagallo <tzagallo@apple.com>
Avoid hashing CompactVariableEnvironment when decoding CompactVariableMap::Handle
https://bugs.webkit.org/show_bug.cgi?id=194937
Reviewed by Saam Barati.
Hashing the CompactVariableEnvironment is expensive and we could avoid it
when decoding multiple handles to the same environment. This is sound because
a pointer to the same CompactVariableEnvironment will hash the same.
* runtime/CachedTypes.cpp:
(JSC::Decoder::handleForEnvironment const):
(JSC::Decoder::setHandleForEnvironment):
(JSC::CachedCompactVariableMapHandle::decode const):
2019-02-25 Tadeu Zagallo <tzagallo@apple.com>
Remove unnecessary WTF:: prefixes in CachedTypes
https://bugs.webkit.org/show_bug.cgi?id=194936
Reviewed by Saam Barati.
Cleanup unnecessary prefixes from Optional, roundUpToMultipleOf and
pageSize.
* runtime/CachedTypes.cpp:
(JSC::Encoder::cachedOffsetForPtr):
(JSC::Encoder::Page::malloc):
(JSC::Encoder::allocateNewPage):
(JSC::CachedPtr::encode):
(JSC::CachedPtr::decode const):
(JSC::CachedOptional::encode):
(JSC::CachedOptional::decode const):
2019-02-25 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Drop direct references to Intl constructors by rewriting Intl JS builtins in C++
https://bugs.webkit.org/show_bug.cgi?id=194976
Reviewed by Michael Saboff.
This patch paves the way to making IntlObject allocation lazy by removing direct references
to Intl constructors (Intl.Collator etc.) from builtin JS. To achieve that,
1. We implement String.prototype.toLocaleCompare and Number.prototype.toLocaleString in C++
instead of JS builtins. Since these functions end up calling ICU C++ runtime, writing them in
JS does not offer performance improvement.
2. We remove @DateTimeFormat constructor reference, and instead, exposing @dateTimeFormat function,
which returns formatted string directly. We still have JS builtins for DateTimeFormat things
because the initialization of its "options" JSObject involves many get_by_id / put_by_id things,
which are efficient in JS. But we avoid exposing @DateTimeFormat directly, so that Intl constructors
can be lazily allocated.
* CMakeLists.txt:
* DerivedSources-input.xcfilelist:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/BuiltinNames.h:
* builtins/DatePrototype.js:
(toLocaleString):
(toLocaleDateString):
(toLocaleTimeString):
* builtins/NumberPrototype.js: Removed.
* builtins/StringPrototype.js:
(intrinsic.StringPrototypeReplaceIntrinsic.replace):
(globalPrivate.getDefaultCollator): Deleted.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
(JSC::JSGlobalObject::defaultCollator):
* runtime/JSGlobalObject.h:
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncDateTimeFormat):
* runtime/JSGlobalObjectFunctions.h:
* runtime/NumberPrototype.cpp:
(JSC::NumberPrototype::finishCreation):
(JSC::throwVMToThisNumberError):
(JSC::numberProtoFuncToExponential):
(JSC::numberProtoFuncToFixed):
(JSC::numberProtoFuncToPrecision):
(JSC::numberProtoFuncToString):
(JSC::numberProtoFuncToLocaleString):
(JSC::numberProtoFuncValueOf):
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
(JSC::stringProtoFuncLocaleCompare):
2019-02-24 Devin Rousso <drousso@apple.com>
Web Inspector: Change the InspectorOverlay to use native rather than canvas
https://bugs.webkit.org/show_bug.cgi?id=105023
<rdar://problem/13443692>
Reviewed by Brian Burg.
* inspector/protocol/OverlayTypes.json: Removed.
Now that the overlay is entirely generated in C++, we no longer need the special prototol
types for transferring data to a JavaScript context.
* inspector/protocol/Debugger.json:
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::setOverlayMessage): Deleted.
Remove `Debugger.setOverlayMessage` command as it hasn't been used and is no longer supported.
* CMakeLists.txt:
* DerivedSources-input.xcfilelist:
* DerivedSources.make:
2019-02-24 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Lazily create sentinel Map and Set buckets
https://bugs.webkit.org/show_bug.cgi?id=194975
Reviewed by Saam Barati.
If VM::canUseJIT() returns false, we can lazily initialize sentinel Map and Set buckets.
This patch adds getters to VM which lazily allocate these buckets. We eagerly initialize
them if VM::canUseJIT() returns true since they can be touched from DFG and FTL.
* bytecode/BytecodeIntrinsicRegistry.cpp:
(JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
(JSC::BytecodeIntrinsicRegistry::sentinelMapBucketValue):
(JSC::BytecodeIntrinsicRegistry::sentinelSetBucketValue):
* bytecode/BytecodeIntrinsicRegistry.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGOperations.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetMapBucketNext):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket):
(JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucketNext):
* runtime/MapConstructor.cpp:
(JSC::mapPrivateFuncMapBucketNext):
* runtime/SetConstructor.cpp:
(JSC::setPrivateFuncSetBucketNext):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::sentinelSetBucketSlow):
(JSC::VM::sentinelMapBucketSlow):
* runtime/VM.h:
(JSC::VM::sentinelSetBucket):
(JSC::VM::sentinelMapBucket):
2019-02-20 Darin Adler <darin@apple.com>
Finish removing String::format
https://bugs.webkit.org/show_bug.cgi?id=194893
Reviewed by Daniel Bates.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::nameForRegister): Use makeString instead of String::format,
using the new "pad" function.
2019-02-23 Robin Morisset <rmorisset@apple.com>
Remove dead code: AdjacencyList::justOneChild()
https://bugs.webkit.org/show_bug.cgi?id=194965
Reviewed by Sam Weinig.
* dfg/DFGAdjacencyList.h:
(JSC::DFG::AdjacencyList::justOneChild const): Deleted.
2019-02-23 Michael Catanzaro <mcatanzaro@igalia.com>
Unreviewed, fix -Wunused-param warning
* jsc.cpp:
2019-02-23 Mark Lam <mark.lam@apple.com>
Add an exception check and some assertions in StringPrototype.cpp.
https://bugs.webkit.org/show_bug.cgi?id=194962
<rdar://problem/48013416>
Reviewed by Yusuke Suzuki and Saam Barati.
* runtime/StringPrototype.cpp:
(JSC::jsSpliceSubstrings):
(JSC::jsSpliceSubstringsWithSeparators):
(JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
2019-02-23 Keith Miller <keith_miller@apple.com>
Add new mac target numbers
https://bugs.webkit.org/show_bug.cgi?id=194955
Reviewed by Tim Horton.
* Configurations/Base.xcconfig:
* Configurations/DebugRelease.xcconfig:
2019-02-22 Robin Morisset <rmorisset@apple.com>
DFGBytecodeParser should not declare that a node won't clobberExit if DFGFixupPhase can later declare it does clobberExit
https://bugs.webkit.org/show_bug.cgi?id=194953
<rdar://problem/47595253>
Reviewed by Saam Barati.
For each node that
(a) may or may not clobberExit depending on their arrayMode
(b) and get their arrayMode from profiling information in DFGBytecodeParser
(c) and can have their arrayMode refined by DFGFixupPhase,
We must make sure to be conservative in the DFGBytecodeParser and treat it as if it unconditionnally clobbered the exit.
Otherwise we will hit a validation failure after fixup if the next node was marked ExitValid and exits to the same semantic origin.
The list of nodes that fit (a) is:
- StringCharAt
- HasIndexProperty
- GetByVal
- PutByValDirect
- PutByVal
- PutByValAlias
- GetIndexedPropertyStorage
Out of these, the following also fit (b) and (c):
- HasIndexedProperty
- GetByVal
- PutByValDirect
- PutByVal
GetByVal already had "m_exitOK = false; // GetByVal must be treated as if it clobbers exit state, since FixupPhase may make it generic."
So we just have to fix the other three the same way.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::handlePutByVal):
2019-02-22 Robin Morisset <rmorisset@apple.com>
B3ReduceStrength: missing peephole optimizations for binary operations
https://bugs.webkit.org/show_bug.cgi?id=194252
Reviewed by Saam Barati.
Adds several sets of optimizations for BitAnd, BitOr and BitXor.
Using BitAnd distributivity over BitOr and BitXor:
Turn any of these (for Op == BitOr || Op == BitXor):
Op(BitAnd(x1, x2), BitAnd(x1, x3))
Op(BitAnd(x2, x1), BitAnd(x1, x3))
Op(BitAnd(x1, x2), BitAnd(x3, x1))
Op(BitAnd(x2, x1), BitAnd(x3, x1))
Into this: BitAnd(Op(x2, x3), x1)
And any of these:
Op(BitAnd(x1, x2), x1)
Op(BitAnd(x2, x1), x1)
Op(x1, BitAnd(x1, x2))
Op(x1, BitAnd(x2, x1))
Into this: BitAnd(Op(x2, x1), x1)
This second set is equivalent to doing x1 => BitAnd(x1, x1), and then applying the first set.
Using de Morgan laws (we represent not as BitXor with allOnes):
BitAnd(BitXor(x1, allOnes), BitXor(x2, allOnes)) => BitXor(BitOr(x1, x2), allOnes)
BitOr(BitXor(x1, allOnes), BitXor(x2, allOnes) => BitXor(BitAnd(x1, x2), allOnes)
BitOr(BitXor(x, allOnes), c) => BitXor(BitAnd(x, ~c), allOnes)
BitAnd(BitXor(x, allOnes), c) => BitXor(BitOr(x, ~c), allOnes)
The latter two are equivalent to doing c => BitXor(~c, allOnes), and then applying the former two.
All of these transformations either reduce the number of operations (which we always do when possible), or bring the expression closer to having:
- BitXor with all ones at the outermost
- then BitAnd
- then other BitXor
- then BitOr at the innermost.
These transformations that don't directly reduce the number of operations are still useful for normalization (helping things like CSE), and also can enable
more optimizations (for example BitXor with all ones can easily cancel each other once they are all at the outermost level).
* b3/B3ReduceStrength.cpp:
* b3/testb3.cpp:
(JSC::B3::testBitAndNotNot):
(JSC::B3::testBitAndNotImm):
(JSC::B3::testBitOrAndAndArgs):
(JSC::B3::testBitOrAndSameArgs):
(JSC::B3::testBitOrNotNot):
(JSC::B3::testBitOrNotImm):
(JSC::B3::testBitXorAndAndArgs):
(JSC::B3::testBitXorAndSameArgs):
(JSC::B3::run):
2019-02-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] putNonEnumerable in JSWrapperMap is too costly
https://bugs.webkit.org/show_bug.cgi?id=194935
Reviewed by Mark Lam.
When we convert Objective-C blocks to JS objects, we need to set up a corresponding function object correctly.
During this allocation, we call [JSValue defineProperty:descriptor] to connect a "prototype" object and "constructor" object.
The problem is that this API has a particularly costly implementation:
[[_context globalObject][@"Object"] invokeMethod:@"defineProperty" withArguments:@[ self, key, descriptor ]];
This wraps each JS objects appear in this code with Objective-C wrapper. And we convert a NSDictionary to JSObject, which
has "writable", "enumerable", "configurable", "value" fields, and call the "defineProperty" JS function through Objective-C wrapper.
This allocates many Objective-C wrappers and JS objects for descriptors. Since JSC has a direct C++ API "defineOwnProperty", we should
bypass these Objective-C APIs and call JSC's code directly.
This patch changes `putNonEnumerable` implementation, from calling [JSValue defineProperty:descriptor] to calling JSC C++ code directly.
We do not change [JSValue defineProperty:descriptor] implementation for now because of two reasons. (1) This is not used in our benchmarks
except for this (converting an Objective-C block to a JS object) one path. And (2) even if we were to re-write [JSValue defineProperty:descriptor]
to be more optimized, we would still want to call the JSC C++ version of defineProperty directly here to avoid NSDictionary allocation for a descriptor.
* API/APIUtils.h:
(setException):
* API/JSWrapperMap.mm:
(putNonEnumerable):
(copyMethodsToObject):
(-[JSObjCClassInfo allocateConstructorAndPrototypeInContext:]):
(-[JSObjCClassInfo wrapperForObject:inContext:]):
2019-02-22 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, build fix after r241954
https://bugs.webkit.org/show_bug.cgi?id=194939
Renaming setCanAccessHeap was incomplete.
* runtime/SmallStrings.cpp:
(JSC::SmallStrings::initializeCommonStrings):
* runtime/VM.cpp:
(JSC::VM::~VM):
2019-02-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] SmallStringsStorage is unnecessary
https://bugs.webkit.org/show_bug.cgi?id=194939
Reviewed by Mark Lam.
SmallStrings hold common small JSStrings. Their underlying StringImpl is also held by SmallStringsStorage.
But it is duplicate since we can get StringImpl from small JSStrings. This patch removes SmallStringsStorage,
and get StringImpls from JSStrings if necessary.
We also add m_canAccessHeap flag to SmallStrings. At the time of VM destruction, JSStrings are destroyed when
VM's Heap is finalized. We must not touch JSStrings before VM's heap (and JSStrings in SmallStrings) is initialized,
and after VM's Heap is destroyed. We add this m_canAccessHeap flag to allow users to get StringImpl during the
this sensitive period. If m_canAccessHeap is false, we get StringImpl from AtomicStringImpl::add.
* runtime/SmallStrings.cpp:
(JSC::SmallStrings::initializeCommonStrings):
(JSC::SmallStrings::singleCharacterStringRep):
(JSC::SmallStringsStorage::rep): Deleted.
(JSC::SmallStringsStorage::SmallStringsStorage): Deleted.
(JSC::SmallStrings::createSingleCharacterString): Deleted.
* runtime/SmallStrings.h:
(JSC::SmallStrings::setCanAccessHeap):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::~VM):
2019-02-22 Tadeu Zagallo <tzagallo@apple.com>
Cache CompactVariableMap::Handle instead of VariableEnvironment for UnlinkedFunctionExecutable
https://bugs.webkit.org/show_bug.cgi?id=194706
Reviewed by Saam Barati.
In https://bugs.webkit.org/show_bug.cgi?id=194583 we started using a
CompactVariableMap::Handle instead of VariableEnvironment for
UnlinkedFunctionExecutables, but we were creating the full environment
to encode the executable in the bytecode cache. This patch changes it so
that we cache the handle instead of the environment. This avoids duplicating
the VariableEnvironment whenever we have to cache two handles that point
to the environment.
* bytecode/UnlinkedFunctionExecutable.h:
* parser/VariableEnvironment.cpp:
(JSC::CompactVariableMap::get):
* parser/VariableEnvironment.h:
* runtime/CachedTypes.cpp:
(JSC::CachedCompactVariableEnvironment::encode):
(JSC::CachedCompactVariableEnvironment::decode const):
(JSC::CachedCompactVariableMapHandle::encode):
(JSC::CachedCompactVariableMapHandle::decode const):
(JSC::CachedFunctionExecutable::encode):
(JSC::CachedFunctionExecutable::decode const):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
2019-02-21 Saam Barati <sbarati@apple.com>
Update JSScript SPI based on feedback
https://bugs.webkit.org/show_bug.cgi?id=194517
Reviewed by Keith Miller.
This patch updates the JSScript SPI in the following ways:
- JSScript can now represent both modules and programs. This is a property
of the script determined during creation.
- JSScript now takes a sourceURL during construction. For modules, this acts
as the module identifier.
- JSScript now has SPI for writing the cache out to disk. We don't do this
automatically.
- JSScript will load the bytecode cache on creation if it exists.
- We retrofit these new requirements on the prior JSScript SPI that
we're going to remove as soon as we can: https://bugs.webkit.org/show_bug.cgi?id=194909.
Previous SPI assumes all JSScripts are modules. Previous SPI also assigns
a sourceURL to the JSScript based on what the module loader decided the
identifier should be. We'll remove this once we remove the old SPI.
This patch also adds SPI to JSContext to evaluate a JSScript. For modules,
this is like returning the result of doing dynamic import. For programs,
this does normal program evaluation.
This patch also fixes a bug in generateBytecode/generateModuleBytecode where
we would try to cache the bytecode even if recursivelyGenerateUnlinkedCodeBlock
returned null. E.g, if the script had a syntax error.
When writing tests, I also discovered that someone previously broke
testapi. This patch also fixes those failures. They were broken when
we switched to using a testapiScripts directory to hold our test .js
scripts.
* API/JSAPIGlobalObject.h:
* API/JSAPIGlobalObject.mm:
(JSC::JSAPIGlobalObject::moduleLoaderResolve):
(JSC::JSAPIGlobalObject::moduleLoaderFetch):
(JSC::JSAPIGlobalObject::loadAndEvaluateJSScriptModule):
* API/JSBase.cpp:
(JSEvaluateScriptInternal):
(JSEvaluateScript):
* API/JSBaseInternal.h: Added.
* API/JSContext.mm:
(-[JSContext evaluateScript:withSourceURL:]):
(-[JSContext evaluateJSScript:]):
* API/JSContextPrivate.h:
* API/JSScript.h:
* API/JSScript.mm:
(+[JSScript scriptWithSource:inVirtualMachine:]):
(+[JSScript scriptFromASCIIFile:inVirtualMachine:withCodeSigning:andBytecodeCache:]):
(createError):
(+[JSScript scriptOfType:inVirtualMachine:withSourceURL:andSource:andBytecodeCache:error:]):
(+[JSScript scriptOfType:inVirtualMachine:memoryMappedFromASCIIFile:withSourceURL:andBytecodeCache:error:]):
(-[JSScript cacheBytecodeWithError:]):
(-[JSScript sourceURL]):
(-[JSScript type]):
(-[JSScript jsSourceCode]):
(-[JSScript writeCache:]):
(-[JSScript setSourceURL:]):
(-[JSScript forceRecreateJSSourceCode]):
(-[JSScript writeCache]): Deleted.
(-[JSScript jsSourceCode:]): Deleted.
* API/JSScriptInternal.h:
* API/tests/FunctionOverridesTest.cpp:
(testFunctionOverrides):
* API/tests/testapi.c:
(main):
* API/tests/testapi.mm:
(tempFile):
(testModuleBytecodeCache):
(testProgramBytecodeCache):
(testBytecodeCacheWithSyntaxError):
(testProgramJSScriptException):
(testLoadBasicFileLegacySPI):
(+[JSContextMemoryMappedLoaderDelegate newContext]):
(-[JSContextMemoryMappedLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
(testLoadBasicFile):
(+[JSContextAugmentedLoaderDelegate newContext]):
(-[JSContextAugmentedLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
(testJSScriptURL):
(testObjectiveCAPI):
(testBytecodeCache): Deleted.
* API/tests/testapiScripts/foo.js: Added.
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/Completion.cpp:
(JSC::generateBytecode):
(JSC::generateModuleBytecode):
2019-02-21 Mark Lam <mark.lam@apple.com>
Add more doesGC() assertions.
https://bugs.webkit.org/show_bug.cgi?id=194911
<rdar://problem/48285723>
Reviewed by Saam Barati and Yusuke Suzuki.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::compileOSRExit):
- Set expectDoesGC here because we no longer have to worry about missing store
barriers in optimized code after this point. This will prevent false positive
assertion failures arising from functions called beneath compileOSRExit().
(JSC::DFG::OSRExit::compileExit):
- Add a comment to explain why the generated ramp needs to set expectDoesGC even
though compileOSRExit() also sets it. Reason: compileOSRExit() is only called
for the first OSR from this code origin, the generated ramp is called for many
subsequents OSR exits from this code origin.
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
- Added a comment for the equivalent reason to the one above.
(JSC::FTL::compileFTLOSRExit):
- Set expectDoesGC here because we no longer have to worry about missing store
barriers in optimized code after this point. This will prevent false positive
assertion failures arising from functions called beneath compileFTLOSRExit().
* heap/CompleteSubspace.cpp:
(JSC::CompleteSubspace::tryAllocateSlow):
* heap/CompleteSubspaceInlines.h:
(JSC::CompleteSubspace::allocateNonVirtual):
- assert expectDoesGC.
* heap/DeferGC.h:
(JSC::DeferGC::~DeferGC):
- assert expectDoesGC.
- Also added WTF_FORBID_HEAP_ALLOCATION to DeferGC, DeferGCForAWhile, and DisallowGC
because all 3 should be stack allocated RAII objects.
* heap/GCDeferralContext.h:
* heap/GCDeferralContextInlines.h:
(JSC::GCDeferralContext::~GCDeferralContext):
- Added WTF_FORBID_HEAP_ALLOCATION.
- assert expectDoesGC.
* heap/Heap.cpp:
(JSC::Heap::collectNow):
(JSC::Heap::collectAsync):
(JSC::Heap::collectSync):
(JSC::Heap::stopIfNecessarySlow):
(JSC::Heap::collectIfNecessaryOrDefer):
* heap/HeapInlines.h:
(JSC::Heap::acquireAccess):
(JSC::Heap::stopIfNecessary):
* heap/LargeAllocation.cpp:
(JSC::LargeAllocation::tryCreate):
* heap/LocalAllocatorInlines.h:
(JSC::LocalAllocator::allocate):
- conservatively assert expectDoesGC on these functions that may trigger a GC
though they don't always do.
* runtime/DisallowScope.h:
- DisallowScope should be stack allocated because it's an RAII object.
* runtime/JSCellInlines.h:
(JSC::tryAllocateCellHelper):
- Remove the expectDoesGC assertion because it is now covered by assertions in
CompleteSubspace, LargeAllocation, and LocalAllocator.
* runtime/RegExpMatchesArray.h:
(JSC::createRegExpMatchesArray):
- assert expectDoesGC.
2019-02-21 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use Fast Malloc as much as possible
https://bugs.webkit.org/show_bug.cgi?id=194316
Reviewed by Mark Lam.
We should use Fast Malloc as much as possible to offer the whole memory view to bmalloc.
* inspector/scripts/codegen/cpp_generator_templates.py:
* inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/generic/expected/enum-values.json-result:
* inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result:
* jit/ExecutableAllocator.h:
* jsc.cpp:
* runtime/JSRunLoopTimer.h:
* tools/VMInspector.h:
* wasm/WasmThunks.h:
2019-02-20 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Remove WatchpointSet creation for SymbolTable entries if VM::canUseJIT() returns false
https://bugs.webkit.org/show_bug.cgi?id=194891
Reviewed by Geoffrey Garen.
WatchpointSet in SymbolTable is used to fold the value into a constant in JIT tiers. And it is
not useful under the non-JIT mode. This patch avoids creation of WatchpointSet in SymbolTable
if VM::canUseJIT() returns false.
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/SymbolTable.cpp:
(JSC::SymbolTableEntry::addWatchpoint): Deleted.
* runtime/SymbolTable.h:
(JSC::SymbolTableEntry::isWatchable const):
(JSC::SymbolTableEntry::watchpointSet):
2019-02-20 Mark Lam <mark.lam@apple.com>
Add code to validate expected GC activity modelled by doesGC() against what the runtime encounters.
https://bugs.webkit.org/show_bug.cgi?id=193938
<rdar://problem/47616277>
Reviewed by Michael Saboff, Saam Barati, and Robin Morisset.
In DFG::SpeculativeJIT::compile() and FTL::LowerDFGToB3::compileNode(), before
emitting code / B3IR for each DFG node, we emit a write to set Heap::m_expectDoesGC
to the value returned by doesGC() for that node. In the runtime (i.e. in allocateCell()
and functions that can resolve a rope), we assert that Heap::m_expectDoesGC is
true.
This validation code is currently only enabled for debug builds. It is disabled
for release builds by default, but it can easily be made to run on release builds
as well by forcing ENABLE_DFG_DOES_GC_VALIDATION to 1 in Heap.h.
To allow this validation code to run on release builds as well, the validation uses
RELEASE_ASSERT instead of ASSERT.
To ensure that Heap.h is #include'd for all files that needs to do this validation
(so that the validation code is accidentally disabled), we guard the validation
code with an if conditional on constexpr bool validateDFGDoesGC (instead of using
a #if ENABLE(DFG_DOES_GC_VALIDATION)). This way, if Heap.h isn't #include'd, the
validation code will fail to build (no silent failures).
Currently, all JSC tests and Layout tests should pass with this validation enabled
in debug builds. We'll only see new failures if there's a regression or if new
tests reveal a previously untested code path that has an undetected issue.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::executeOSRExit):
(JSC::DFG::OSRExit::compileExit):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* heap/Heap.h:
(JSC::Heap::expectDoesGC const):
(JSC::Heap::setExpectDoesGC):
(JSC::Heap::addressOfExpectDoesGC):
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_compareAndJump):
* runtime/JSCellInlines.h:
(JSC::tryAllocateCellHelper):
* runtime/JSString.h:
(JSC::jsSingleCharacterString):
(JSC::JSString::toAtomicString const):
(JSC::JSString::toExistingAtomicString const):
(JSC::JSString::value const):
(JSC::JSString::tryGetValue const):
(JSC::JSRopeString::unsafeView const):
(JSC::JSRopeString::viewWithUnderlyingString const):
(JSC::JSString::unsafeView const):
2019-02-20 Andy Estes <aestes@apple.com>
[Xcode] Add SDKVariant.xcconfig to various Xcode projects
https://bugs.webkit.org/show_bug.cgi?id=194869
Rubber-stamped by Jer Noble.
* JavaScriptCore.xcodeproj/project.pbxproj:
2019-02-19 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 Mark Lam.
* 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 or an object which doesn't
have a default getPrototype. Try to make the code a little clearer.
2019-02-19 Truitt Savell <tsavell@apple.com>
Unreviewed, rolling out r241784.
Broke all OpenSource builds.
Reverted changeset:
"Web Inspector: Improve ES6 Class instances in Heap Snapshot
instances view"
https://bugs.webkit.org/show_bug.cgi?id=172848
https://trac.webkit.org/changeset/241784
2019-02-19 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 Mark Lam.
* 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 or an object which doesn't
have a default getPrototype. Try to make the code a little clearer.
2019-02-19 Robin Morisset <rmorisset@apple.com>
B3-O2 incorrectly optimizes this subtest
https://bugs.webkit.org/show_bug.cgi?id=194625
Reviewed by Saam Barati.
Trivial fix. Instead of doing
if (!cond) foo else bar => if (cond) bar else foo
B3LowerToAir was doing
if (x^C) foo else bar => if (cond) bar else foo whenever C&1, even if C was for example 3.
* b3/B3LowerToAir.cpp:
* b3/testb3.cpp:
(JSC::B3::testBitNotOnBooleanAndBranch32):
(JSC::B3::testNotOnBooleanAndBranch32): Added.
2019-02-19 Robin Morisset <rmorisset@apple.com>
CachedCall should not consider it UNLIKELY that it will not stack overflow
https://bugs.webkit.org/show_bug.cgi?id=194831
Reviewed by Mark Lam.
* interpreter/CachedCall.h:
(JSC::CachedCall::CachedCall):
2019-02-19 Mark Lam <mark.lam@apple.com>
Fix DFG doesGC() for TryGetById and ProfileType nodes.
https://bugs.webkit.org/show_bug.cgi?id=194821
<rdar://problem/48206690>
Reviewed by Saam Barati.
Fix doesGC() for the following nodes:
ProfileType:
calls operationProcessTypeProfilerLogDFG(), which can calculatedClassName(),
which can call JSString::tryGetValue(), which can resolve a rope.
TryGetById:
calls operationTryGetByIdOptimize(), which can startWatchingPropertyForReplacements()
on a structure, which can allocate StructureRareData.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
2019-02-18 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Introduce JSNonDestructibleProxy for JavaScriptCore.framework's GlobalThis
https://bugs.webkit.org/show_bug.cgi?id=194799
Reviewed by Saam Barati.
JSProxy is destructible one because we have JSWindowProxy which has ref counted object.
However, JavaScriptCore.framework's JSProxy for GlobalThis does not need to be destructible.
This is important since we need to separate Heap subspaces between destructible and non-destructible objects.
If we can put more and more objects in non-destructible status, we can get rid of low-usage MarkedBlock.
This patch adds JSNonDestructibleProxy, which is not destructible JSProxy. While it inherits JSDestructibleObject,
we can make the subclass still non-destructible thanks to Subspace mechanism. This drops one more low-usage MarkedBlock.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::resetPrototype):
(JSC::JSGlobalObject::finishCreation):
* runtime/JSNonDestructibleProxy.cpp: Added.
* runtime/JSNonDestructibleProxy.h: Added.
(JSC::JSNonDestructibleProxy::subspaceFor):
(JSC::JSNonDestructibleProxy::create):
(JSC::JSNonDestructibleProxy::createStructure):
(JSC::JSNonDestructibleProxy::JSNonDestructibleProxy):
* runtime/JSProxy.h:
(JSC::JSProxy::JSProxy):
2019-02-19 Robin Morisset <rmorisset@apple.com>
B3ReduceStrength::simplifyCFG() could do a lot more on each iteration
https://bugs.webkit.org/show_bug.cgi?id=194475
Reviewed by Saam Barati.
B3ReduceStrength::simplifyCFG() does three optimizations (which I will call A, B and C):
- A makes any terminal that points to a block that is empty except for a jump point to that jump's target instead.
- B transforms any branch or switch that points to a single block into a jump
- C finds blocks ending with jumps, whose successor has a single predecessor, and inline that successor block in place of the jump
It currently is limited in the following way:
- A and C can only fire once per block per iteration
- B can create jumps that would trigger A, but they may not be seen until the next iteration
Both problems are mitigated by going through the blocks in post-order, so that when a block is optimized most of its successors have already been optimized.
In a sense it is the symmetric of the peephole optimizer that goes in pre-order so that when an instruction is optimized most of its children have already been optimized.
On JetStream2 it reduces the average number of iterations from 3.35 to 3.24.
* b3/B3ReduceStrength.cpp:
2019-02-19 Tadeu Zagallo <tzagallo@apple.com>
Move bytecode cache-related filesystem code out of CodeCache
https://bugs.webkit.org/show_bug.cgi?id=194675
Reviewed by Saam Barati.
The code is only used for the bytecode-cache tests, so it should live in
jsc.cpp rather than in the CodeCache. The logic now lives in ShellSourceProvider,
which overrides the a virtual method in SourceProvider, `cacheBytecode`,
in order to write the cache to disk.
* jsc.cpp:
(ShellSourceProvider::create):
(ShellSourceProvider::~ShellSourceProvider):
(ShellSourceProvider::cachePath const):
(ShellSourceProvider::loadBytecode):
(ShellSourceProvider::ShellSourceProvider):
(jscSource):
(GlobalObject::moduleLoaderFetch):
(functionDollarEvalScript):
(runWithOptions):
* parser/SourceProvider.h:
(JSC::SourceProvider::cacheBytecode const):
* runtime/CodeCache.cpp:
(JSC::writeCodeBlock):
* runtime/CodeCache.h:
(JSC::CodeCacheMap::fetchFromDiskImpl):
2019-02-18 Dominik Infuehr <dinfuehr@igalia.com>
[ARM] Fix crash with sampling profiler
https://bugs.webkit.org/show_bug.cgi?id=194772
Reviewed by Mark Lam.
sampling-profiler-richards.js was crashing with an enabled sampling profiler. add32
did not update the stack pointer in a single instruction. The src register was first
moved into the stack pointer, the immediate imm was added in a subsequent instruction.
This was problematic when a signal handler was invoked before applying the immediate,
when the stack pointer is still set to the temporary value. Avoid this by calculating src+imm in
a temporary register and then move it in one go into the stack pointer.
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::add32):
2019-02-18 Mark Lam <mark.lam@apple.com>
Fix DFG doesGC() for CompareEq/Less/LessEq/Greater/GreaterEq and CompareStrictEq nodes.
https://bugs.webkit.org/show_bug.cgi?id=194800
<rdar://problem/48183773>
Reviewed by Yusuke Suzuki.
Fix doesGC() for the following nodes:
CompareEq:
CompareLess:
CompareLessEq:
CompareGreater:
CompareGreaterEq:
CompareStrictEq:
Only return false (i.e. does not GC) for child node use kinds that have
been vetted to not do anything that can GC. For all other use kinds
(including StringUse and BigIntUse), we return true (i.e. does GC).
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
2019-02-16 Darin Adler <darin@apple.com>
Continue reducing use of String::format, now focusing on hex: "%p", "%x", etc.
https://bugs.webkit.org/show_bug.cgi?id=194752
Reviewed by Daniel Bates.
* heap/HeapSnapshotBuilder.cpp:
(JSC::HeapSnapshotBuilder::json): Added back the "0x" that was removed when changing
this file to use appendUnsignedAsHex instead of "%p". The intent at that time was to
keep behavior the same, so let's do that.
* parser/Lexer.cpp:
(JSC::Lexer<T>::invalidCharacterMessage const): Use makeString and hex instead of
String::format and "%04x".
2019-02-18 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add LazyClassStructure::getInitializedOnMainThread
https://bugs.webkit.org/show_bug.cgi?id=194784
<rdar://problem/48154820>
Reviewed by Mark Lam.
LazyClassStructure::get and LazyProperty::get functions do not allow compiler threads to call them. But for booleanPrototype, numberPrototype and symbolPrototype cases,
we would like to call them from compiler threads. We eagerly initialize them if VM::canUseJIT() is true, so that compiler threads can safely call LazyClassStructure::get
and LazyProperty::get for booleanPrototype, numberPrototype and symbolPrototype. But still assertion hits because the assertion requires that these functions need to be
called in non compiler threads. Calling `getConcurrently()` is not possible since symbolPrototype() function is called from both the main thread and compiler threads,
and we would like to lazily initialize SymbolPrototype object if it is called from the main thread, which can happen with non-JIT configuration.
This patch adds `getInitializedOnMainThread()`. Compiler threads can call it only when we know that the value is already initialized on the main thread. The main thread
can call it at anytime and this function lazily initializes the value. This is useful to make some of prototypes lazy with non-JIT configuration: With non-JIT configuration,
this function is always called from the main thread and it initializes the value lazily. Non-JIT configuration does not care about compiler threads since they do not exist.
With JIT configuration, we eagerly initialize them in JSGlobalObject::init so that `getInitializedOnMainThread()` always succeeds.
Basically, `getInitializedOnMainThread()` is `get` with different assertion location: While `get` always crashes if it is called from compiler threads, `getInitializedOnMainThread()`
crashes only when actual initialization happens on compiler threads. We do not merge them since `get` is still useful to find accidental initialization from compiler threads.
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::booleanPrototype const):
(JSC::JSGlobalObject::numberPrototype const):
(JSC::JSGlobalObject::symbolPrototype const):
* runtime/LazyClassStructure.h:
(JSC::LazyClassStructure::getInitializedOnMainThread const):
(JSC::LazyClassStructure::prototypeInitializedOnMainThread const):
(JSC::LazyClassStructure::constructorInitializedOnMainThread const):
* runtime/LazyProperty.h:
(JSC::LazyProperty::get const):
(JSC::LazyProperty::getInitializedOnMainThread const):
2019-02-18 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Better categorize CPU usage per-thread / worker
https://bugs.webkit.org/show_bug.cgi?id=194564
Reviewed by Devin Rousso.
* inspector/protocol/CPUProfiler.json:
Add additional properties per-Event, and new per-Thread object info.
2019-02-18 Tadeu Zagallo <tzagallo@apple.com>
Bytecode cache should a have a boot-specific validation
https://bugs.webkit.org/show_bug.cgi?id=194769
<rdar://problem/48149509>
Reviewed by Keith Miller.
Add the boot UUID to the cached bytecode to enforce that it is not reused
across reboots.
* runtime/CachedTypes.cpp:
(JSC::Encoder::malloc):
(JSC::GenericCacheEntry::GenericCacheEntry):
(JSC::GenericCacheEntry::tag const):
(JSC::CacheEntry::CacheEntry):
(JSC::CacheEntry::decode const):
(JSC::GenericCacheEntry::decode const):
(JSC::encodeCodeBlock):
2019-02-18 Eric Carlson <eric.carlson@apple.com>
Add MSE logging configuration
https://bugs.webkit.org/show_bug.cgi?id=194719
<rdar://problem/48122151>
Reviewed by Joseph Pecoraro.
* inspector/ConsoleMessage.cpp:
(Inspector::messageSourceValue):
* inspector/protocol/Console.json:
* inspector/scripts/codegen/generator.py:
* runtime/ConsoleTypes.h:
2019-02-18 Tadeu Zagallo <tzagallo@apple.com>
Add version number to cached bytecode
https://bugs.webkit.org/show_bug.cgi?id=194768
<rdar://problem/48147968>
Reviewed by Saam Barati.
Add a version number to the bytecode cache that should be unique per build.
* CMakeLists.txt:
* DerivedSources-output.xcfilelist:
* DerivedSources.make:
* runtime/CachedTypes.cpp:
(JSC::Encoder::malloc):
(JSC::GenericCacheEntry::GenericCacheEntry):
(JSC::CacheEntry::CacheEntry):
(JSC::CacheEntry::encode):
(JSC::CacheEntry::decode const):
(JSC::GenericCacheEntry::decode const):
(JSC::decodeCodeBlockImpl):
* runtime/CodeCache.h:
(JSC::CodeCacheMap::fetchFromDiskImpl):
2019-02-17 Saam Barati <sbarati@apple.com>
WasmB3IRGenerator models some effects incorrectly
https://bugs.webkit.org/show_bug.cgi?id=194038
Reviewed by Keith Miller.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::restoreWasmContextInstance):
(JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
These two functions were using global state instead of the
arguments passed into the function.
(JSC::Wasm::B3IRGenerator::addOp<F64ConvertUI64>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::F32ConvertUI64>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::I64TruncUF64>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::I64TruncUF32>):
Any patchpoint that allows scratch register usage must
also say that it clobbers the scratch registers.
2019-02-17 Saam Barati <sbarati@apple.com>
Deadlock when adding a Structure property transition and then doing incremental marking
https://bugs.webkit.org/show_bug.cgi?id=194767
Reviewed by Mark Lam.
This can happen in the following scenario:
You have a Structure S. S is on the mark stack. Then:
1. S grabs its lock
2. S adds a new property transition
3. We find out we need to do some incremental marking
4. We mark S
5. visitChildren on S will try to grab its lock
6. We are now in a deadlock
* heap/Heap.cpp:
(JSC::Heap::performIncrement):
* runtime/Structure.cpp:
(JSC::Structure::addNewPropertyTransition):
2019-02-17 David Kilzer <ddkilzer@apple.com>
Unreviewed, rolling out r241620.
"Causes use-after-free crashes running layout tests with ASan and GuardMalloc."
(Requested by ddkilzer on #webkit.)
Reverted changeset:
"[WTF] Add environment variable helpers"
https://bugs.webkit.org/show_bug.cgi?id=192405
https://trac.webkit.org/changeset/241620
2019-02-17 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r241612.
https://bugs.webkit.org/show_bug.cgi?id=194762
"It regressed JetStream2 parsing tests by ~40%" (Requested by
saamyjoon on #webkit).
Reverted changeset:
"Move bytecode cache-related filesystem code out of CodeCache"
https://bugs.webkit.org/show_bug.cgi?id=194675
https://trac.webkit.org/changeset/241612
2019-02-16 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] JSWrapperObject should not be destructible
https://bugs.webkit.org/show_bug.cgi?id=194743
Reviewed by Saam Barati.
JSWrapperObject should be just a wrapper object for JSValue, thus, it should not be a JSDestructibleObject.
Currently it is destructible object because DateInstance uses it. This patch changes Base of DateInstance from
JSWrapperObject to JSDestructibleObject, and makes JSWrapperObject non-destructible.
* runtime/BigIntObject.cpp:
(JSC::BigIntObject::BigIntObject):
* runtime/BooleanConstructor.cpp:
(JSC::BooleanConstructor::finishCreation):
* runtime/BooleanObject.cpp:
(JSC::BooleanObject::BooleanObject):
* runtime/BooleanObject.h:
* runtime/DateInstance.cpp:
(JSC::DateInstance::DateInstance):
(JSC::DateInstance::finishCreation):
* runtime/DateInstance.h:
* runtime/DatePrototype.cpp:
(JSC::dateProtoFuncGetTime):
(JSC::dateProtoFuncSetTime):
(JSC::setNewValueFromTimeArgs):
(JSC::setNewValueFromDateArgs):
(JSC::dateProtoFuncSetYear):
* runtime/JSCPoison.h:
* runtime/JSWrapperObject.h:
(JSC::JSWrapperObject::JSWrapperObject):
* runtime/NumberObject.cpp:
(JSC::NumberObject::NumberObject):
* runtime/NumberObject.h:
* runtime/StringConstructor.cpp:
(JSC::StringConstructor::finishCreation):
* runtime/StringObject.cpp:
(JSC::StringObject::StringObject):
* runtime/StringObject.h:
(JSC::StringObject::internalValue const):
* runtime/SymbolObject.cpp:
(JSC::SymbolObject::SymbolObject):
* runtime/SymbolObject.h:
2019-02-16 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Shrink UnlinkedFunctionExecutable
https://bugs.webkit.org/show_bug.cgi?id=194733
Reviewed by Mark Lam.
UnlinkedFunctionExecutable has sourceURLDirective and sourceMappingURLDirective. These
directives can be found in the comment of non typical function's source code (Program,
Eval code, and Global function from function constructor etc.), and tricky thing is that
SourceProvider's directives are updated by Parser. The reason why we have these fields in
UnlinkedFunctionExecutable is that we need to update the SourceProvider's directives even
if we skip parsing by using CodeCache. These fields are effective only if (1)
UnlinkedFunctionExecutable is for non typical function things, and (2) it has sourceURLDirective
or sourceMappingURLDirective. This is rare enough to purge them to a separated
UnlinkedFunctionExecutable::RareData to make UnlinkedFunctionExecutable small.
sizeof(UnlinkedFunctionExecutable) is very important since it is super frequently allocated
cell. Furthermore, the current JSC allocates two MarkedBlocks for UnlinkedFunctionExecutable
in JSGlobalObject initialization, but the usage of the second MarkedBlock is quite low (8%).
If we can reduce the size of UnlinkedFunctionExecutable, we can make them one MarkedBlock.
Since UnlinkedFunctionExecutable is allocated from IsoSubspace, we do not need to fit it to
one of size class.
This patch adds RareData to UnlinkedFunctionExecutable and move some rare datas into RareData.
And kill one MarkedBlock allocation in JSC initialization phase.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::UnlinkedFunctionExecutable::ensureRareDataSlow):
* bytecode/UnlinkedFunctionExecutable.h:
* debugger/DebuggerLocation.cpp:
(JSC::DebuggerLocation::DebuggerLocation):
* inspector/ScriptDebugServer.cpp:
(Inspector::ScriptDebugServer::dispatchDidParseSource):
* parser/Lexer.h:
(JSC::Lexer::sourceURLDirective const):
(JSC::Lexer::sourceMappingURLDirective const):
(JSC::Lexer::sourceURL const): Deleted.
(JSC::Lexer::sourceMappingURL const): Deleted.
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
* parser/SourceProvider.h:
(JSC::SourceProvider::sourceURLDirective const):
(JSC::SourceProvider::sourceMappingURLDirective const):
(JSC::SourceProvider::setSourceURLDirective):
(JSC::SourceProvider::setSourceMappingURLDirective):
(JSC::SourceProvider::sourceURL const): Deleted. We rename it from sourceURL to sourceURLDirective
since it is the correct name.
(JSC::SourceProvider::sourceMappingURL const): Deleted. We rename it from sourceMappingURL to
sourceMappingURLDirective since it is the correct name.
* runtime/CachedTypes.cpp:
(JSC::CachedSourceProviderShape::encode):
(JSC::CachedFunctionExecutableRareData::encode):
(JSC::CachedFunctionExecutableRareData::decode const): CachedFunctionExecutable did not have
sourceMappingURL to sourceMappingURLDirective. So this patch keeps the same logic.
(JSC::CachedFunctionExecutable::rareData const):
(JSC::CachedFunctionExecutable::encode):
(JSC::CachedFunctionExecutable::decode const):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
* runtime/CodeCache.h:
(JSC::generateUnlinkedCodeBlockImpl):
* runtime/FunctionExecutable.h:
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::StackFrame::url):
2019-02-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Remove unused global private variables
https://bugs.webkit.org/show_bug.cgi?id=194741
Reviewed by Joseph Pecoraro.
There are some private functions and constants that are no longer referenced from builtin JS code.
This patch cleans up them.
* builtins/BuiltinNames.h:
* builtins/ObjectConstructor.js:
(entries):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
2019-02-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Lazily create empty RegExp
https://bugs.webkit.org/show_bug.cgi?id=194735
Reviewed by Keith Miller.
Some scripts do not have any RegExp. In that case, allocating MarkedBlock for RegExp is costly.
Previously, there was always one RegExp, "empty RegExp". This patch lazily creates it and drop
one MarkedBlock.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/RegExpCache.cpp:
(JSC::RegExpCache::ensureEmptyRegExpSlow):
(JSC::RegExpCache::initialize): Deleted.
* runtime/RegExpCache.h:
(JSC::RegExpCache::ensureEmptyRegExp):
(JSC::RegExpCache::emptyRegExp const): Deleted.
* runtime/RegExpCachedResult.cpp:
(JSC::RegExpCachedResult::lastResult):
* runtime/RegExpCachedResult.h:
* runtime/VM.cpp:
(JSC::VM::VM):
2019-02-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Make builtin objects more lazily initialized under non-JIT mode
https://bugs.webkit.org/show_bug.cgi?id=194727
Reviewed by Saam Barati.
Boolean, Symbol, and Number constructors and prototypes are initialized eagerly, but this is largely
because concurrent compiler can touch NumberPrototype etc. when traversing object's prototypes. This
means that eager initialization is not necessary under non-JIT mode. While we can investigate all the
accesses to these prototypes from the concurrent compiler threads, this "lazily initialize under non-JIT"
is safe and beneficial to non-JIT mode. This patch lazily initializes them under non-JIT mode, and
drop some @Number references to avoid eager initialization. This removes some object allocations and 1
MarkedBlock allocation just for Symbols.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::numberToStringWatchpoint):
(JSC::JSGlobalObject::booleanPrototype const):
(JSC::JSGlobalObject::numberPrototype const):
(JSC::JSGlobalObject::symbolPrototype const):
(JSC::JSGlobalObject::booleanObjectStructure const):
(JSC::JSGlobalObject::symbolObjectStructure const):
(JSC::JSGlobalObject::numberObjectStructure const):
(JSC::JSGlobalObject::stringObjectStructure const):
2019-02-15 Michael Saboff <msaboff@apple.com>
RELEASE_ASSERT at com.apple.JavaScriptCore: JSC::jsSubstringOfResolved
https://bugs.webkit.org/show_bug.cgi?id=194558
Reviewed by Saam Barati.
Added an in bounds check before the read of the next character for Unicode regular expressions
for pattern generation that didn't already have such checks.
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::generatePatternCharacterOnce):
(JSC::Yarr::YarrGenerator::generatePatternCharacterFixed):
(JSC::Yarr::YarrGenerator::generateCharacterClassOnce):
(JSC::Yarr::YarrGenerator::generateCharacterClassFixed):
2019-02-15 Dean Jackson <dino@apple.com>
Allow emulation of user gestures from Web Inspector console
https://bugs.webkit.org/show_bug.cgi?id=194725
<rdar://problem/48126604>
Reviewed by Joseph Pecoraro and Devin Rousso.
* inspector/agents/InspectorRuntimeAgent.cpp: Add a new optional parameter, emulateUserGesture,
to the evaluate function, and mark the function as override so that PageRuntimeAgent
can change the behaviour.
(Inspector::InspectorRuntimeAgent::evaluate):
* inspector/agents/InspectorRuntimeAgent.h:
* inspector/protocol/Runtime.json:
2019-02-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Do not initialize Wasm related data if Wasm is not enabled
https://bugs.webkit.org/show_bug.cgi?id=194728
Reviewed by Mark Lam.
Under non-JIT mode, these data structures are unnecessary. Should not allocate extra memory for that.
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSLock.cpp:
(JSC::JSLock::didAcquireLock):
2019-02-15 Ross Kirsling <ross.kirsling@sony.com>
[WTF] Add environment variable helpers
https://bugs.webkit.org/show_bug.cgi?id=192405
Reviewed by Michael Catanzaro.
* inspector/remote/glib/RemoteInspectorGlib.cpp:
(Inspector::RemoteInspector::RemoteInspector):
(Inspector::RemoteInspector::start):
* jsc.cpp:
(startTimeoutThreadIfNeeded):
* runtime/Options.cpp:
(JSC::overrideOptionWithHeuristic):
(JSC::Options::overrideAliasedOptionWithHeuristic):
(JSC::Options::initialize):
* runtime/VM.cpp:
(JSC::enableAssembler):
(JSC::VM::VM):
* tools/CodeProfiling.cpp:
(JSC::CodeProfiling::notifyAllocator):
Utilize WTF::Environment where possible.
2019-02-15 Mark Lam <mark.lam@apple.com>
SamplingProfiler::stackTracesAsJSON() should escape strings.
https://bugs.webkit.org/show_bug.cgi?id=194649
<rdar://problem/48072386>
Reviewed by Saam Barati.
Ditto for TypeSet::toJSONString() and TypeSet::toJSONString().
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::stackTracesAsJSON):
* runtime/TypeSet.cpp:
(JSC::TypeSet::toJSONString const):
(JSC::StructureShape::toJSONString const):
2019-02-15 Robin Morisset <rmorisset@apple.com>
CodeBlock::jettison should clear related watchpoints
https://bugs.webkit.org/show_bug.cgi?id=194544
Reviewed by Mark Lam.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::jettison):
* dfg/DFGCommonData.h:
(JSC::DFG::CommonData::clearWatchpoints): Added.
* dfg/CommonData.cpp:
(JSC::DFG::CommonData::clearWatchpoints): Added.
2019-02-15 Tadeu Zagallo <tzagallo@apple.com>
Move bytecode cache-related filesystem code out of CodeCache
https://bugs.webkit.org/show_bug.cgi?id=194675
Reviewed by Saam Barati.
That code is only used for the bytecode-cache tests, so it should live in
jsc.cpp rather than in the CodeCache.
* jsc.cpp:
(CliSourceProvider::create):
(CliSourceProvider::~CliSourceProvider):
(CliSourceProvider::cachePath const):
(CliSourceProvider::loadBytecode):
(CliSourceProvider::CliSourceProvider):
(jscSource):
(GlobalObject::moduleLoaderFetch):
(functionDollarEvalScript):
(runWithOptions):
* parser/SourceProvider.h:
(JSC::SourceProvider::cacheBytecode const):
* runtime/CodeCache.cpp:
(JSC::writeCodeBlock):
* runtime/CodeCache.h:
(JSC::CodeCacheMap::fetchFromDiskImpl):
2019-02-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] DFG, FTL, and Wasm worklist creation should be fenced
https://bugs.webkit.org/show_bug.cgi?id=194714
Reviewed by Mark Lam.
Let's consider about the following extreme case.
1. VM (A) is created.
2. Another VM (B) is created on a different thread.
3. (A) is being destroyed. It calls DFG::existingWorklistForIndexOrNull in a destructor.
4. At the same time, (B) starts using DFG Worklist and it is instantiated in call_once.
5. But (A) reads the pointer directly through DFG::existingWorklistForIndexOrNull.
6. (A) sees the half-baked worklist, which may be in the middle of creation.
This patch puts store-store fence just before putting a pointer to a global variable.
This fence is executed only three times at most, for DFG, FTL, and Wasm worklist initializations.
* dfg/DFGWorklist.cpp:
(JSC::DFG::ensureGlobalDFGWorklist):
(JSC::DFG::ensureGlobalFTLWorklist):
* wasm/WasmWorklist.cpp:
(JSC::Wasm::ensureWorklist):
2019-02-15 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r241559 and r241566.
https://bugs.webkit.org/show_bug.cgi?id=194710
Causes layout test crashes under GuardMalloc (Requested by
ryanhaddad on #webkit).
Reverted changesets:
"[WTF] Add environment variable helpers"
https://bugs.webkit.org/show_bug.cgi?id=192405
https://trac.webkit.org/changeset/241559
"Unreviewed build fix for WinCairo Debug after r241559."
https://trac.webkit.org/changeset/241566
2019-02-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Do not even allocate JIT worklists in non-JIT mode
https://bugs.webkit.org/show_bug.cgi?id=194693
Reviewed by Mark Lam.
Heap always allocates JIT worklists for Baseline, DFG, and FTL. While they do not have actual threads, Worklist itself already allocates some memory.
And we do not perform any GC operations that are only meaningful in JIT environment.
1. We add VM::canUseJIT() check in Heap's ensureXXXWorklist things to prevent them from being allocated.
2. We remove DFG marking constraint in non-JIT mode.
3. We do not gather conservative roots from scratch buffers under the non-JIT mode (BTW, # of scratch buffers are always zero in non-JIT mode)
4. We do not visit JITStubRoutineSet.
5. Align JITWorklist function names to the other worklists.
* dfg/DFGOSRExitPreparation.cpp:
(JSC::DFG::prepareCodeOriginForOSRExit):
* dfg/DFGPlan.h:
* dfg/DFGWorklist.cpp:
(JSC::DFG::markCodeBlocks): Deleted.
* dfg/DFGWorklist.h:
* heap/Heap.cpp:
(JSC::Heap::completeAllJITPlans):
(JSC::Heap::iterateExecutingAndCompilingCodeBlocks):
(JSC::Heap::gatherScratchBufferRoots):
(JSC::Heap::removeDeadCompilerWorklistEntries):
(JSC::Heap::stopThePeriphery):
(JSC::Heap::suspendCompilerThreads):
(JSC::Heap::resumeCompilerThreads):
(JSC::Heap::addCoreConstraints):
* jit/JITWorklist.cpp:
(JSC::JITWorklist::existingGlobalWorklistOrNull):
(JSC::JITWorklist::ensureGlobalWorklist):
(JSC::JITWorklist::instance): Deleted.
* jit/JITWorklist.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::jitCompileAndSetHeuristics):
* runtime/VM.cpp:
(JSC::VM::~VM):
(JSC::VM::gatherScratchBufferRoots):
(JSC::VM::gatherConservativeRoots): Deleted.
* runtime/VM.h:
2019-02-15 Saam barati <sbarati@apple.com>
[WebAssembly] Write a new register allocator for Air O0 and make BBQ use it
https://bugs.webkit.org/show_bug.cgi?id=194036
Reviewed by Yusuke Suzuki.
This patch adds a new Air-O0 backend. Air-O0 runs fewer passes and doesn't
use linear scan for register allocation. Instead of linear scan, Air-O0 does
mostly block-local register allocation, and it does this as it's emitting
code directly. The register allocator uses liveness analysis to reduce
the number of spills. Doing register allocation as we're emitting code
allows us to skip editing the IR to insert spills, which saves a non trivial
amount of compile time. For stack allocation, we give each Tmp its own slot.
This is less than ideal. We probably want to do some trivial live range analysis
in the future. The reason this isn't a deal breaker for Wasm is that this patch
makes it so that we reuse Tmps as we're generating Air IR in the AirIRGenerator.
Because Wasm is a stack machine, we trivially know when we kill a stack value (its last use).
This patch is another 25% Wasm startup time speedup. It seems to be worth
another 1% on JetStream2.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp: Added.
(JSC::B3::Air::GenerateAndAllocateRegisters::GenerateAndAllocateRegisters):
(JSC::B3::Air::GenerateAndAllocateRegisters::buildLiveRanges):
(JSC::B3::Air::GenerateAndAllocateRegisters::insertBlocksForFlushAfterTerminalPatchpoints):
(JSC::B3::Air::callFrameAddr):
(JSC::B3::Air::GenerateAndAllocateRegisters::flush):
(JSC::B3::Air::GenerateAndAllocateRegisters::spill):
(JSC::B3::Air::GenerateAndAllocateRegisters::alloc):
(JSC::B3::Air::GenerateAndAllocateRegisters::freeDeadTmpsIfNeeded):
(JSC::B3::Air::GenerateAndAllocateRegisters::assignTmp):
(JSC::B3::Air::GenerateAndAllocateRegisters::isDisallowedRegister):
(JSC::B3::Air::GenerateAndAllocateRegisters::prepareForGeneration):
(JSC::B3::Air::GenerateAndAllocateRegisters::generate):
* b3/air/AirAllocateRegistersAndStackAndGenerateCode.h: Added.
* b3/air/AirCode.cpp:
* b3/air/AirCode.h:
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::prepareForGeneration):
(JSC::B3::Air::generateWithAlreadyAllocatedRegisters):
(JSC::B3::Air::generate):
* b3/air/AirHandleCalleeSaves.cpp:
(JSC::B3::Air::handleCalleeSaves):
* b3/air/AirHandleCalleeSaves.h:
* b3/air/AirTmpMap.h:
* runtime/Options.h:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::didKill):
(JSC::Wasm::AirIRGenerator::newTmp):
(JSC::Wasm::AirIRGenerator::AirIRGenerator):
(JSC::Wasm::parseAndCompileAir):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64TruncUF64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64TruncUF32>):
* wasm/WasmAirIRGenerator.h:
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::didKill):
* wasm/WasmBBQPlan.cpp:
(JSC::Wasm::BBQPlan::compileFunctions):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseBody):
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/WasmValidate.cpp:
(JSC::Wasm::Validate::didKill):
2019-02-14 Saam barati <sbarati@apple.com>
lowerStackArgs should lower Lea32/64 on ARM64 to Add
https://bugs.webkit.org/show_bug.cgi?id=194656
Reviewed by Yusuke Suzuki.
On arm64, Lea is just implemented as an add. However, Air treats it as an
address with a given width. Because of this width, we were incorrectly
computing whether or not this immediate could fit into the instruction itself
or it needed to be explicitly put into a register. This patch makes
AirLowerStackArgs lower Lea to Add on arm64.
* b3/air/AirLowerStackArgs.cpp:
(JSC::B3::Air::lowerStackArgs):
* b3/air/AirOpcode.opcodes:
* b3/air/testair.cpp:
2019-02-14 Saam Barati <sbarati@apple.com>
Cache the results of BytecodeGenerator::getVariablesUnderTDZ
https://bugs.webkit.org/show_bug.cgi?id=194583
<rdar://problem/48028140>
Reviewed by Yusuke Suzuki.
This patch makes it so that getVariablesUnderTDZ caches a result of
CompactVariableMap::Handle. getVariablesUnderTDZ is costly when
it's called in an environment where there are a lot of variables.
This patch makes it so we cache its results. This is profitable when
getVariablesUnderTDZ is called repeatedly with the same environment
state. This is common since we call this every time we encounter a
function definition/expression node.
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createExecutable):
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::popLexicalScopeInternal):
(JSC::BytecodeGenerator::liftTDZCheckIfPossible):
(JSC::BytecodeGenerator::pushTDZVariables):
(JSC::BytecodeGenerator::getVariablesUnderTDZ):
(JSC::BytecodeGenerator::restoreTDZStack):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::makeFunction):
* parser/VariableEnvironment.cpp:
(JSC::CompactVariableMap::Handle::Handle):
(JSC::CompactVariableMap::Handle::operator=):
* parser/VariableEnvironment.h:
(JSC::CompactVariableMap::Handle::operator bool const):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
2019-02-14 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Non-JIT entrypoints should share NativeJITCode per entrypoint type
https://bugs.webkit.org/show_bug.cgi?id=194659
Reviewed by Mark Lam.
Non-JIT entrypoints create NativeJITCode every time it is called. But it is meaningless since these entry point code are identical.
We should create one per entrypoint type (for function, we should have CodeForCall and CodeForConstruct) and continue to use them.
And we use NativeJITCode instead of DirectJITCode if it does not have difference between usual entrypoint and arity check entrypoint.
* dfg/DFGJITCode.h:
* dfg/DFGJITFinalizer.cpp:
(JSC::DFG::JITFinalizer::finalize):
(JSC::DFG::JITFinalizer::finalizeFunction):
* jit/JITCode.cpp:
(JSC::DirectJITCode::initializeCodeRefForDFG):
(JSC::DirectJITCode::initializeCodeRef): Deleted.
(JSC::NativeJITCode::initializeCodeRef): Deleted.
* jit/JITCode.h:
* llint/LLIntEntrypoint.cpp:
(JSC::LLInt::setFunctionEntrypoint):
(JSC::LLInt::setEvalEntrypoint):
(JSC::LLInt::setProgramEntrypoint):
(JSC::LLInt::setModuleProgramEntrypoint): Retagged is removed since the tag is the same.
2019-02-14 Ross Kirsling <ross.kirsling@sony.com>
[WTF] Add environment variable helpers
https://bugs.webkit.org/show_bug.cgi?id=192405
Reviewed by Michael Catanzaro.
* inspector/remote/glib/RemoteInspectorGlib.cpp:
(Inspector::RemoteInspector::RemoteInspector):
(Inspector::RemoteInspector::start):
* jsc.cpp:
(startTimeoutThreadIfNeeded):
* runtime/Options.cpp:
(JSC::overrideOptionWithHeuristic):
(JSC::Options::overrideAliasedOptionWithHeuristic):
(JSC::Options::initialize):
* runtime/VM.cpp:
(JSC::enableAssembler):
(JSC::VM::VM):
* tools/CodeProfiling.cpp:
(JSC::CodeProfiling::notifyAllocator):
Utilize WTF::Environment where possible.
2019-02-14 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Should have default NativeJITCode
https://bugs.webkit.org/show_bug.cgi?id=194634
Reviewed by Mark Lam.
In JSC_useJIT=false mode, we always create identical NativeJITCode for call and construct when we create NativeExecutable.
This is meaningless since we do not modify NativeJITCode after the creation. This patch adds singleton used as a default one.
Since NativeJITCode (& JITCode) is ThreadSafeRefCounted, we can just share it in a whole process level. This removes 446 NativeJITCode
allocations, which takes 14KB.
* runtime/VM.cpp:
(JSC::jitCodeForCallTrampoline):
(JSC::jitCodeForConstructTrampoline):
(JSC::VM::getHostFunction):
2019-02-14 Tadeu Zagallo <tzagallo@apple.com>
generateUnlinkedCodeBlockForFunctions shouldn't need to create a FunctionExecutable just to get its source code
https://bugs.webkit.org/show_bug.cgi?id=194576
Reviewed by Saam Barati.
Extract a new function, `linkedSourceCode` from UnlinkedFunctionExecutable::link
and use it in `generateUnlinkedCodeBlockForFunctions` instead.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::linkedSourceCode const):
(JSC::UnlinkedFunctionExecutable::link):
* bytecode/UnlinkedFunctionExecutable.h:
* runtime/CodeCache.cpp:
(JSC::generateUnlinkedCodeBlockForFunctions):
2019-02-14 Tadeu Zagallo <tzagallo@apple.com>
CachedBitVector's size must be converted from bits to bytes
https://bugs.webkit.org/show_bug.cgi?id=194441
Reviewed by Saam Barati.
CachedBitVector used its size in bits for memcpy. That didn't cause any
issues when encoding, since the size in bits was also used in the allocation,
but would overflow the actual BitVector buffer when decoding.
* runtime/CachedTypes.cpp:
(JSC::CachedBitVector::encode):
(JSC::CachedBitVector::decode const):
2019-02-13 Brian Burg <bburg@apple.com>
Web Inspector: don't include accessibility role in DOM.Node object payloads
https://bugs.webkit.org/show_bug.cgi?id=194623
<rdar://problem/36384037>
Reviewed by Devin Rousso.
Remove property of DOM.Node that is no longer being sent.
* inspector/protocol/DOM.json:
2019-02-13 Keith Miller <keith_miller@apple.com> and Yusuke Suzuki <ysuzuki@apple.com>
We should only make rope strings when concatenating strings long enough.
https://bugs.webkit.org/show_bug.cgi?id=194465
Reviewed by Mark Lam.
This patch stops us from allocating a rope string if the resulting
rope would be smaller than the size of the JSRopeString object we
would need to allocate.
This patch also adds paths so that we don't unnecessarily allocate
JSString cells for primitives we are going to concatenate with a
string anyway.
The important change from the previous one is that we do not apply
the above rule to JSRopeStrings generated by JSStrings. If we convert
it to JSString, comparison of memory consumption becomes the following,
because JSRopeString does not have StringImpl until it is resolved.
sizeof(JSRopeString) v.s. sizeof(JSString) + sizeof(StringImpl) + content
Since sizeof(JSString) + sizeof(StringImpl) is larger than sizeof(JSRopeString),
resolving eagerly increases memory footprint. The point is that we need to
account newly created JSString and JSRopeString from the operands. This is the
reason why this patch adds different thresholds for each jsString functions.
This patch also avoids concatenation for ropes conservatively. Many ropes are
temporary cells. So we do not resolve eagerly if one of operands is already a
rope.
In CLI execution, this change is performance neutral in JetStream2 (run 6 times, 1 for warming up and average in latter 5.).
Before: 159.3778
After: 160.72340000000003
* dfg/DFGOperations.cpp:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSString.h:
(JSC::JSString::isRope const):
* runtime/Operations.cpp:
(JSC::jsAddSlowCase):
* runtime/Operations.h:
(JSC::jsString):
(JSC::jsAddNonNumber):
(JSC::jsAdd):
2019-02-13 Saam Barati <sbarati@apple.com>
AirIRGenerator::addSwitch switch patchpoint needs to model clobbering the scratch register
https://bugs.webkit.org/show_bug.cgi?id=194610
Reviewed by Michael Saboff.
BinarySwitch might use the scratch register. We must model the
effects of that properly. This is already caught by our br-table
tests on arm64.
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::addSwitch):
2019-02-13 Mark Lam <mark.lam@apple.com>
Create a randomized free list for new StructureIDs on StructureIDTable resize.
https://bugs.webkit.org/show_bug.cgi?id=194566
<rdar://problem/47975502>
Reviewed by Michael Saboff.
Also isolate 32-bit implementation of StructureIDTable out more so the 64-bit
implementation is a little easier to read.
This patch appears to be perf neutral on JetStream2 (as run from the command line).
* runtime/StructureIDTable.cpp:
(JSC::StructureIDTable::StructureIDTable):
(JSC::StructureIDTable::makeFreeListFromRange):
(JSC::StructureIDTable::resize):
(JSC::StructureIDTable::allocateID):
(JSC::StructureIDTable::deallocateID):
* runtime/StructureIDTable.h:
(JSC::StructureIDTable::get):
(JSC::StructureIDTable::deallocateID):
(JSC::StructureIDTable::allocateID):
(JSC::StructureIDTable::flushOldTables):
2019-02-13 Tadeu Zagallo <tzagallo@apple.com>
VariableLengthObject::allocate<T> should initialize objects
https://bugs.webkit.org/show_bug.cgi?id=194534
Reviewed by Michael Saboff.
`buffer()` should not be called for empty VariableLengthObjects, but
these cases were not being caught due to the objects not being properly
initialized. Fix it so that allocate calls the constructor and fix the
assertion failues.
* runtime/CachedTypes.cpp:
(JSC::CachedObject::operator new):
(JSC::VariableLengthObject::allocate):
(JSC::CachedVector::encode):
(JSC::CachedVector::decode const):
(JSC::CachedUniquedStringImpl::decode const):
(JSC::CachedBitVector::encode):
(JSC::CachedBitVector::decode const):
(JSC::CachedArray::encode):
(JSC::CachedArray::decode const):
(JSC::CachedImmutableButterfly::CachedImmutableButterfly):
(JSC::CachedBigInt::decode const):
2019-02-13 Tadeu Zagallo <tzagallo@apple.com>
CodeBlocks read from disk should not be re-written
https://bugs.webkit.org/show_bug.cgi?id=194535
Reviewed by Michael Saboff.
Keep track of which CodeBlocks have been read from disk or have already
been serialized in CodeCache.
* runtime/CodeCache.cpp:
(JSC::CodeCache::write):
* runtime/CodeCache.h:
(JSC::SourceCodeValue::SourceCodeValue):
(JSC::CodeCacheMap::fetchFromDiskImpl):
2019-02-13 Tadeu Zagallo <tzagallo@apple.com>
SourceCode should be copied when generating bytecode for functions
https://bugs.webkit.org/show_bug.cgi?id=194536
Reviewed by Saam Barati.
The FunctionExecutable might be collected while generating the bytecode
for nested functions, in which case the SourceCode reference would no
longer be valid.
* runtime/CodeCache.cpp:
(JSC::generateUnlinkedCodeBlockForFunctions):
2019-02-12 Saam barati <sbarati@apple.com>
JSScript needs to retain its cache path NSURL*
https://bugs.webkit.org/show_bug.cgi?id=194577
Reviewed by Tim Horton.
* API/JSScript.mm:
(+[JSScript scriptFromASCIIFile:inVirtualMachine:withCodeSigning:andBytecodeCache:]):
(-[JSScript dealloc]):
2019-02-12 Robin Morisset <rmorisset@apple.com>
Make B3Value::returnsBool() more precise
https://bugs.webkit.org/show_bug.cgi?id=194457
Reviewed by Saam Barati.
It is currently used repeatedly in B3ReduceStrength, as well as once in B3LowerToAir.
It has a needlessly complex rule for BitAnd, and has no rule for other easy cases such as BitOr or Select.
No new tests added as this should be indirectly tested by the already existing tests.
* b3/B3Value.cpp:
(JSC::B3::Value::returnsBool const):
2019-02-12 Michael Catanzaro <mcatanzaro@igalia.com>
Unreviewed, fix -Wimplicit-fallthrough warning after r241140
https://bugs.webkit.org/show_bug.cgi?id=194399
<rdar://problem/47889777>
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
2019-02-12 Michael Catanzaro <mcatanzaro@igalia.com>
[WPE][GTK] Unsafe g_unsetenv() use in WebProcessPool::platformInitialize
https://bugs.webkit.org/show_bug.cgi?id=194370
Reviewed by Darin Adler.
Change a couple WTFLogAlways to use g_warning, for good measure. Of course this isn't
necessary, but it will make errors more visible.
* inspector/remote/glib/RemoteInspectorGlib.cpp:
(Inspector::RemoteInspector::start):
(Inspector::dbusConnectionCallAsyncReadyCallback):
* inspector/remote/glib/RemoteInspectorServer.cpp:
(Inspector::RemoteInspectorServer::start):
2019-02-12 Andy Estes <aestes@apple.com>
[iOSMac] Enable Parental Controls Content Filtering
https://bugs.webkit.org/show_bug.cgi?id=194521
<rdar://39732376>
Reviewed by Tim Horton.
* Configurations/FeatureDefines.xcconfig:
2019-02-11 Mark Lam <mark.lam@apple.com>
Randomize insertion of deallocated StructureIDs into the StructureIDTable's free list.
https://bugs.webkit.org/show_bug.cgi?id=194512
<rdar://problem/47975465>
Reviewed by Yusuke Suzuki.
* runtime/StructureIDTable.cpp:
(JSC::StructureIDTable::StructureIDTable):
(JSC::StructureIDTable::allocateID):
(JSC::StructureIDTable::deallocateID):
* runtime/StructureIDTable.h:
2019-02-10 Mark Lam <mark.lam@apple.com>
Remove the RELEASE_ASSERT check for duplicate cases in the BinarySwitch constructor.
https://bugs.webkit.org/show_bug.cgi?id=194493
<rdar://problem/36380852>
Reviewed by Yusuke Suzuki.
Having duplicate cases in the BinarySwitch is not a correctness issue. It is
however not good for performance and memory usage. As such, a debug ASSERT will
do. We'll also do an audit of the clients of BinarySwitch to see if it's
possible to be instantiated with duplicate cases in
https://bugs.webkit.org/show_bug.cgi?id=194492 later.
Also added some value dumps to the RELEASE_ASSERT to help debug the issue when we
see duplicate cases.
* jit/BinarySwitch.cpp:
(JSC::BinarySwitch::BinarySwitch):
2019-02-10 Darin Adler <darin@apple.com>
Switch uses of StringBuilder with String::format for hex numbers to use HexNumber.h instead
https://bugs.webkit.org/show_bug.cgi?id=194485
Reviewed by Daniel Bates.
* heap/HeapSnapshotBuilder.cpp:
(JSC::HeapSnapshotBuilder::json): Use appendUnsignedAsHex along with
reinterpret_cast<uintptr_t> to replace uses of String::format with "%p".
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::encode): Removed some unneeded casts in StringBuilder code,
including one in a call to appendByteAsHex.
(JSC::globalFuncEscape): Ditto.
2019-02-10 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r241230.
https://bugs.webkit.org/show_bug.cgi?id=194488
"It regressed JetStream2 by ~6%" (Requested by saamyjoon on
#webkit).
Reverted changeset:
"We should only make rope strings when concatenating strings
long enough."
https://bugs.webkit.org/show_bug.cgi?id=194465
https://trac.webkit.org/changeset/241230
2019-02-10 Saam barati <sbarati@apple.com>
BBQ-Air: Emit better code for switch
https://bugs.webkit.org/show_bug.cgi?id=194053
Reviewed by Yusuke Suzuki.
Instead of emitting a linear set of jumps for Switch, this patch
makes the BBQ-Air backend emit a binary switch.
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::addSwitch):
2019-02-09 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, Lexer should use isLatin1 implementation in WTF
https://bugs.webkit.org/show_bug.cgi?id=194466
Follow-up after r241233 pointed by Darin.
* parser/Lexer.cpp:
(JSC::isLatin1): Deleted.
2019-02-09 Darin Adler <darin@apple.com>
Eliminate unnecessary String temporaries by using StringConcatenateNumbers
https://bugs.webkit.org/show_bug.cgi?id=194021
Reviewed by Geoffrey Garen.
* inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::count): Remove String::number and let
makeString do the conversion without allocating/destroying a String.
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::objectGroupForBreakpointAction): Ditto.
(Inspector::InspectorDebuggerAgent::setBreakpointByUrl): Ditto.
(Inspector::InspectorDebuggerAgent::setBreakpoint): Ditto.
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty): Ditto.
* runtime/NumberPrototype.cpp:
(JSC::numberProtoFuncToFixed): Use String::numberToStringFixedWidth instead
of calling numberToFixedWidthString to do the same thing.
(JSC::numberProtoFuncToPrecision): Use String::number instead of calling
numberToFixedPrecisionString to do the same thing.
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::reportTopFunctions): Ditto.
2019-02-09 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, rolling in r241237 again
https://bugs.webkit.org/show_bug.cgi?id=194469
* runtime/JSString.h:
(JSC::jsSubstring):
2019-02-09 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r241237.
https://bugs.webkit.org/show_bug.cgi?id=194474
Shows significant memory increase in WSL (Requested by
yusukesuzuki on #webkit).
Reverted changeset:
"[WTF] Use BufferInternal StringImpl if substring StringImpl
takes more memory"
https://bugs.webkit.org/show_bug.cgi?id=194469
https://trac.webkit.org/changeset/241237
2019-02-08 Yusuke Suzuki <ysuzuki@apple.com>
[WTF] Use BufferInternal StringImpl if substring StringImpl takes more memory
https://bugs.webkit.org/show_bug.cgi?id=194469
Reviewed by Geoffrey Garen.
* runtime/JSString.h:
(JSC::jsSubstring):
2019-02-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] CachedTypes should use jsString instead of JSString::create
https://bugs.webkit.org/show_bug.cgi?id=194471
Reviewed by Mark Lam.
Use jsString() here because JSString::create is a bit low-level API and it requires some invariant like "length is not zero".
* runtime/CachedTypes.cpp:
(JSC::CachedJSValue::decode const):
2019-02-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Increase StructureIDTable initial capacity
https://bugs.webkit.org/show_bug.cgi?id=194468
Reviewed by Mark Lam.
Currently, # of structures just after initializing JSGlobalObject (precisely, initializing GlobalObject in
JSC shell), 281, already exceeds the current initial value 256. We should increase the capacity since
unnecessary resizing requires more operations, keeps old StructureID array until GC happens, and makes
more memory dirty. We also remove some structures that are no longer used.
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::callbackObjectStructure const):
(JSC::JSGlobalObject::propertyNameIteratorStructure const): Deleted.
* runtime/StructureIDTable.h:
* runtime/VM.h:
2019-02-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] String.fromCharCode's slow path always generates 16bit string
https://bugs.webkit.org/show_bug.cgi?id=194466
Reviewed by Keith Miller.
String.fromCharCode(a1) has a fast path and the most frequently used. And String.fromCharCode(a1, a2, ...)
goes to the slow path. However, in the slow path, we always create 16bit string. 16bit string takes 2x memory,
and even worse, taints ropes 16bit if 16bit string is included in the given rope. We find that acorn-wtb
creates very large strings multiple times with String.fromCharCode, and String.fromCharCode always produces
16bit string. However, only few strings are actually 16bit strings. This patch attempts to make 8bit string
as much as possible.
It improves non JIT acorn-wtb's peak and current memory footprint by 6% and 3% respectively.
* runtime/StringConstructor.cpp:
(JSC::stringFromCharCode):
2019-02-08 Keith Miller <keith_miller@apple.com>
We should only make rope strings when concatenating strings long enough.
https://bugs.webkit.org/show_bug.cgi?id=194465
Reviewed by Saam Barati.
This patch stops us from allocating a rope string if the resulting
rope would be smaller than the size of the JSRopeString object we
would need to allocate.
This patch also adds paths so that we don't unnecessarily allocate
JSString cells for primitives we are going to concatenate with a
string anyway.
* dfg/DFGOperations.cpp:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSString.h:
* runtime/Operations.cpp:
(JSC::jsAddSlowCase):
* runtime/Operations.h:
(JSC::jsString):
(JSC::jsAdd):
2019-02-08 Saam barati <sbarati@apple.com>
Nodes that rely on being dominated by CheckInBounds should have a child edge to it
https://bugs.webkit.org/show_bug.cgi?id=194334
<rdar://problem/47844327>
Reviewed by Mark Lam.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::convertToHasIndexedProperty):
* dfg/DFGIntegerCheckCombiningPhase.cpp:
(JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
* dfg/DFGNodeType.h:
* dfg/DFGSSALoweringPhase.cpp:
(JSC::DFG::SSALoweringPhase::lowerBoundsCheck):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileHasIndexedProperty):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCheckInBounds):
(JSC::FTL::DFG::LowerDFGToB3::compileHasIndexedProperty):
2019-02-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Shrink sizeof(CodeBlock) more
https://bugs.webkit.org/show_bug.cgi?id=194419
Reviewed by Mark Lam.
This patch further shrinks the size of CodeBlock, from 352 to 296 (304).
1. CodeBlock copies so many data from ScriptExecutable even if ScriptExecutable
has the same information. These data is not touched in CodeBlock::~CodeBlock,
so we can just use the data in ScriptExecutable instead of holding it in CodeBlock.
2. We remove m_instructions pointer since the ownership is managed by UnlinkedCodeBlock.
And we do not touch it in CodeBlock::~CodeBlock.
3. We move m_calleeSaveRegisters from CodeBlock to CodeBlock::JITData. For baseline and LLInt
cases, this patch offers RegisterAtOffsetList::llintBaselineCalleeSaveRegisters() which returns
singleton to `const RegisterAtOffsetList*` usable for LLInt and Baseline JIT CodeBlocks.
4. Move m_catchProfiles to RareData and materialize only when op_catch's slow path is called.
5. Drop ownerScriptExecutable. ownerExecutable() returns ScriptExecutable*.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::hash const):
(JSC::CodeBlock::sourceCodeForTools const):
(JSC::CodeBlock::dumpAssumingJITType const):
(JSC::CodeBlock::dumpSource):
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::finalizeLLIntInlineCaches):
(JSC::CodeBlock::setCalleeSaveRegisters):
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffset):
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
(JSC::CodeBlock::lineNumberForBytecodeOffset):
(JSC::CodeBlock::expressionRangeForBytecodeOffset const):
(JSC::CodeBlock::hasOpDebugForLineAndColumn):
(JSC::CodeBlock::newReplacement):
(JSC::CodeBlock::replacement):
(JSC::CodeBlock::computeCapabilityLevel):
(JSC::CodeBlock::jettison):
(JSC::CodeBlock::calleeSaveRegisters const):
(JSC::CodeBlock::calleeSaveSpaceAsVirtualRegisters):
(JSC::CodeBlock::updateOSRExitCounterAndCheckIfNeedToReoptimize):
(JSC::CodeBlock::getArrayProfile):
(JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
(JSC::CodeBlock::notifyLexicalBindingUpdate):
(JSC::CodeBlock::tryGetValueProfileForBytecodeOffset):
(JSC::CodeBlock::validate):
(JSC::CodeBlock::outOfLineJumpTarget):
(JSC::CodeBlock::arithProfileForBytecodeOffset):
(JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::specializationKind const):
(JSC::CodeBlock::isStrictMode const):
(JSC::CodeBlock::isConstructor const):
(JSC::CodeBlock::codeType const):
(JSC::CodeBlock::isKnownNotImmediate):
(JSC::CodeBlock::instructions const):
(JSC::CodeBlock::ownerExecutable const):
(JSC::CodeBlock::thisRegister const):
(JSC::CodeBlock::source const):
(JSC::CodeBlock::sourceOffset const):
(JSC::CodeBlock::firstLineColumnOffset const):
(JSC::CodeBlock::createRareDataIfNecessary):
(JSC::CodeBlock::ownerScriptExecutable const): Deleted.
(JSC::CodeBlock::setThisRegister): Deleted.
(JSC::CodeBlock::calleeSaveRegisters const): Deleted.
* bytecode/EvalCodeBlock.h:
* bytecode/FunctionCodeBlock.h:
* bytecode/GlobalCodeBlock.h:
(JSC::GlobalCodeBlock::GlobalCodeBlock):
* bytecode/ModuleProgramCodeBlock.h:
* bytecode/ProgramCodeBlock.h:
* debugger/Debugger.cpp:
(JSC::Debugger::toggleBreakpoint):
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::sourceID const):
(JSC::DebuggerCallFrame::sourceIDForCallFrame):
* debugger/DebuggerScope.cpp:
(JSC::DebuggerScope::location const):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::InlineStackEntry::executable):
(JSC::DFG::ByteCodeParser::inliningCost):
(JSC::DFG::ByteCodeParser::parseCodeBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::isSupportedForInlining):
(JSC::DFG::mightCompileEval):
(JSC::DFG::mightCompileProgram):
(JSC::DFG::mightCompileFunctionForCall):
(JSC::DFG::mightCompileFunctionForConstruct):
(JSC::DFG::canUseOSRExitFuzzing):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::executableFor):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compileFunction):
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareOSREntry):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::restoreCalleeSavesFor):
(JSC::DFG::saveCalleeSavesFor):
(JSC::DFG::saveOrCopyCalleeSavesFor):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::handleExitCounts):
* dfg/DFGOperations.cpp:
* dfg/DFGToFTLDeferredCompilationCallback.cpp:
(JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidComplete):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* interpreter/CallFrame.cpp:
(JSC::CallFrame::callerSourceOrigin):
* interpreter/Interpreter.cpp:
(JSC::eval):
(JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::calleeSaveRegisters):
(JSC::StackVisitor::Frame::sourceURL const):
(JSC::StackVisitor::Frame::sourceID):
(JSC::StackVisitor::Frame::computeLineAndColumn const):
* interpreter/StackVisitor.h:
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitSaveCalleeSavesFor):
(JSC::AssemblyHelpers::emitSaveOrCopyCalleeSavesFor):
(JSC::AssemblyHelpers::emitRestoreCalleeSavesFor):
* jit/CallFrameShuffleData.cpp:
(JSC::CallFrameShuffleData::setupCalleeSaveRegisters):
* jit/JIT.cpp:
(JSC::JIT::compileWithoutLinking):
* jit/JITToDFGDeferredCompilationCallback.cpp:
(JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
* jit/JITWorklist.cpp:
(JSC::JITWorklist::Plan::finalize):
(JSC::JITWorklist::compileNow):
* jit/RegisterAtOffsetList.cpp:
(JSC::RegisterAtOffsetList::llintBaselineCalleeSaveRegisters):
* jit/RegisterAtOffsetList.h:
(JSC::RegisterAtOffsetList::at const):
* runtime/ErrorInstance.cpp:
(JSC::appendSourceToError):
* runtime/ScriptExecutable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
* runtime/StackFrame.cpp:
(JSC::StackFrame::sourceID const):
(JSC::StackFrame::sourceURL const):
(JSC::StackFrame::computeLineAndColumn const):
2019-02-08 Robin Morisset <rmorisset@apple.com>
B3LowerMacros wrongly sets m_changed to true in the case of AtomicWeakCAS on x86
https://bugs.webkit.org/show_bug.cgi?id=194460
Reviewed by Mark Lam.
Trivial fix, should already be covered by testAtomicWeakCAS in testb3.cpp.
* b3/B3LowerMacros.cpp:
2019-02-08 Mark Lam <mark.lam@apple.com>
Use maxSingleCharacterString in comparisons instead of literal constants.
https://bugs.webkit.org/show_bug.cgi?id=194452
Reviewed by Yusuke Suzuki.
This way, if we ever change maxSingleCharacterString, it won't break all this code
that relies on it being 0xff implicitly.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileStringSlice):
(JSC::DFG::SpeculativeJIT::compileGetByValOnString):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
(JSC::FTL::DFG::LowerDFGToB3::compileStringSlice):
* jit/ThunkGenerators.cpp:
(JSC::stringGetByValGenerator):
(JSC::charToString):
2019-02-08 Mark Lam <mark.lam@apple.com>
Fix DFG's doesGC() for CheckTierUp*, GetByVal, PutByVal*, and StringCharAt nodes.
https://bugs.webkit.org/show_bug.cgi?id=194446
<rdar://problem/47926792>
Reviewed by Saam Barati.
Fix doesGC() for the following nodes:
CheckTierUpAtReturn:
Calls triggerTierUpNow(), which calls triggerFTLReplacementCompile(),
which calls Worklist::completeAllReadyPlansForVM(), which uses DeferGC.
CheckTierUpInLoop:
Calls triggerTierUpNowInLoop(), which calls tierUpCommon(), which calls
Worklist::completeAllReadyPlansForVM(), which uses DeferGC.
CheckTierUpAndOSREnter:
Calls triggerOSREntryNow(), which calls tierUpCommon(), which calls
Worklist::completeAllReadyPlansForVM(), which uses DeferGC.
GetByVal:
case Array::String calls operationSingleCharacterString(), which calls
jsSingleCharacterString(), which can allocate a string.
PutByValDirect:
PutByVal:
PutByValAlias:
For the DFG only, the integer TypeArrays calls compilePutByValForIntTypedArray(),
which may call slow paths operationPutByValDirectStrict(), operationPutByValDirectNonStrict(),
operationPutByValStrict(), or operationPutByValNonStrict(). All of these
slow paths call putByValInternal(), which may create exception objects, or
call the generic JSValue::put() which may execute arbitrary code.
StringCharAt:
Can call operationSingleCharacterString(), which calls jsSingleCharacterString(),
which can allocate a string.
Also fix DFG::SpeculativeJIT::compileGetByValOnString() and FTL's compileStringCharAt()
to use the maxSingleCharacterString constant instead of a literal constant.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByValOnString):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
2019-02-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] SourceProviderCacheItem should be small
https://bugs.webkit.org/show_bug.cgi?id=194432
Reviewed by Saam Barati.
Some JetStream2 tests stress the JS parser. At that time, so many SourceProviderCacheItems are created.
While they are removed when full-GC happens, it significantly increases the peak memory usage.
This patch reduces the size of SourceProviderCacheItem from 56 to 32.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionInfo):
* parser/ParserModes.h:
* parser/ParserTokens.h:
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::endFunctionToken const):
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
2019-02-07 Robin Morisset <rmorisset@apple.com>
Fix Abs(Neg(x)) -> Abs(x) optimization in B3ReduceStrength
https://bugs.webkit.org/show_bug.cgi?id=194420
Reviewed by Saam Barati.
In https://bugs.webkit.org/show_bug.cgi?id=194250, I added an optimization: Abs(Neg(x)) -> Abs(x).
But I introduced two bugs, one is that I actually implemented Abs(Neg(x)) -> x, and the other is that the test is looking at Abs(Abs(x)) instead (both were stupid copy-paste mistakes).
This trivial patch fixes both.
* b3/B3ReduceStrength.cpp:
* b3/testb3.cpp:
(JSC::B3::testAbsNegArg):
2019-02-07 Keith Miller <keith_miller@apple.com>
Better error messages for module loader SPI
https://bugs.webkit.org/show_bug.cgi?id=194421
Reviewed by Saam Barati.
* API/JSAPIGlobalObject.mm:
(JSC::JSAPIGlobalObject::moduleLoaderImportModule):
2019-02-07 Mark Lam <mark.lam@apple.com>
Fix more doesGC() for CheckTraps, GetMapBucket, and Switch nodes.
https://bugs.webkit.org/show_bug.cgi?id=194399
<rdar://problem/47889777>
Reviewed by Yusuke Suzuki.
Fix doesGC() for the following nodes:
CheckTraps:
We normally will not emit this node because Options::usePollingTraps() is
false by default. However, as it is implemented now, CheckTraps can GC
because it can allocate a TerminatedExecutionException. If we make the
TerminatedExecutionException a singleton allocated at initialization time,
doesGC() can return false for CheckTraps.
https://bugs.webkit.org/show_bug.cgi?id=194323
GetMapBucket:
Can call operationJSMapFindBucket() or operationJSSetFindBucket(),
which calls HashMapImpl::findBucket(), which calls jsMapHash(), which
can resolve a rope.
Switch:
If switchData kind is SwitchChar, can call operationResolveRope() .
If switchData kind is SwitchString and the child use kind is not StringIdentUse,
can call operationSwitchString() which resolves ropes.
DirectTailCall:
ForceOSRExit:
Return:
TailCallForwardVarargs:
TailCallVarargs:
Throw:
These are terminal nodes. It shouldn't really matter what doesGC() returns
for them, but following our conservative practice, unless we have a good
reason for doesGC() to return false, we should just return true.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
2019-02-07 Robin Morisset <rmorisset@apple.com>
B3ReduceStrength: missing peephole optimizations for Neg and Sub
https://bugs.webkit.org/show_bug.cgi?id=194250
Reviewed by Saam Barati.
Adds the following optimizations for integers:
- Sub(x, x) => 0
Already covered by the test testSubArg
- Sub(x1, Neg(x2)) => Add (x1, x2)
Added test: testSubNeg
- Neg(Sub(x1, x2)) => Sub(x2, x1)
Added test: testNegSub
- Add(Neg(x1), x2) => Sub(x2, x1)
Added test: testAddNeg1
- Add(x1, Neg(x2)) => Sub(x1, x2)
Added test: testAddNeg2
Adds the following optimization for floating point values:
- Abs(Neg(x)) => Abs(x)
Added test: testAbsNegArg
Adds the following optimization:
Also did some trivial refactoring, using m_value->isInteger() everywhere instead of isInt(m_value->type()), and using replaceWithNew<Value> instead of replaceWithNewValue(m_proc.add<Value(..))
* b3/B3ReduceStrength.cpp:
* b3/testb3.cpp:
(JSC::B3::testAddNeg1):
(JSC::B3::testAddNeg2):
(JSC::B3::testSubNeg):
(JSC::B3::testNegSub):
(JSC::B3::testAbsAbsArg):
(JSC::B3::testAbsNegArg):
(JSC::B3::run):
2019-02-06 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use BufferInternal single character StringImpl for SmallStrings
https://bugs.webkit.org/show_bug.cgi?id=194374
Reviewed by Geoffrey Garen.
Currently, we first create a large StringImpl, and create bunch of substrings with length = 1.
But pointer is larger than single character. BufferInternal StringImpl with single character
is more memory efficient.
* runtime/SmallStrings.cpp:
(JSC::SmallStringsStorage::SmallStringsStorage):
(JSC::SmallStrings::SmallStrings):
* runtime/SmallStrings.h:
2019-02-06 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] InitializeEntrypointArguments should produce SpecCellCheck if FlushFormat is FlushedCell
https://bugs.webkit.org/show_bug.cgi?id=194369
<rdar://problem/47813087>
Reviewed by Saam Barati.
InitializeEntrypointArguments says SpecCell if the FlushFormat is FlushedCell. But this actually has
JSEmpty if it is TDZ. This incorrectly proved type information removes necessary CheckNotEmpty in
constant folding phase.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2019-02-06 Devin Rousso <drousso@apple.com>
Web Inspector: DOM: don't send the entire function string with each event listener
https://bugs.webkit.org/show_bug.cgi?id=194293
<rdar://problem/47822809>
Reviewed by Joseph Pecoraro.
* inspector/protocol/DOM.json:
* runtime/JSFunction.h:
Export `calculatedDisplayName`.
2019-02-06 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] PrivateName to PublicName hash table is wasteful
https://bugs.webkit.org/show_bug.cgi?id=194277
Reviewed by Michael Saboff.
PrivateNames account for a lot of memory in the initial JSC footprint. BuiltinNames have Identifier fields corresponding to these PrivateNames
which makes the sizeof(BuiltinNames) about 6KB. It also maintains hash tables for "PublicName to PrivateName" and "PrivateName to PublicName",
each of which takes 16KB memory. While "PublicName to PrivateName" functionality is used in builtin JS (parsing "@xxx" and get a private
name for "xxx"), "PrivateName to PublicName" is rarely used. Holding 16KB hash table for rarely used feature is costly.
In this patch, we add some rules to remove "PrivateName to PublicName" hash table.
1. PrivateName's content should be the same to PublicName.
2. If PrivateName is not actually a private name (we introduced hacky mapping like "@iteratorSymbol" => Symbol.iterator),
the public name should be easily crafted from the given PrivateName.
We modify the content of private names to ensure (1). And for (2), we can meet this requirement by ensuring that the "@xxxSymbol"
is converted to "Symbol.xxx". (1) and (2) allow us to convert a private name to a public name without a large hash table.
We also remove unused identifiers in CommonIdentifiers. And we also move some of them to WebCore's WebCoreBuiltinNames if it is only used in
WebCore.
* builtins/BuiltinNames.cpp:
(JSC::BuiltinNames::BuiltinNames):
* builtins/BuiltinNames.h:
(JSC::BuiltinNames::lookUpPrivateName const):
(JSC::BuiltinNames::getPublicName const):
(JSC::BuiltinNames::checkPublicToPrivateMapConsistency):
(JSC::BuiltinNames::appendExternalName):
(JSC::BuiltinNames::lookUpPublicName const): Deleted.
* builtins/BuiltinUtils.h:
* bytecode/BytecodeDumper.cpp:
(JSC::BytecodeDumper<Block>::dumpIdentifiers):
* bytecompiler/NodesCodegen.cpp:
(JSC::BytecodeIntrinsicNode::emit_intrinsic_getByIdDirectPrivate):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_putByIdDirectPrivate):
* parser/Lexer.cpp:
(JSC::Lexer<LChar>::parseIdentifier):
(JSC::Lexer<UChar>::parseIdentifier):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::createGeneratorParameters):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
(JSC::Parser<LexerType>::parseClassDeclaration):
(JSC::Parser<LexerType>::parseExportDeclaration):
(JSC::Parser<LexerType>::parseMemberExpression):
* parser/ParserArena.h:
(JSC::IdentifierArena::makeIdentifier):
* runtime/CachedTypes.cpp:
(JSC::CachedUniquedStringImpl::encode):
(JSC::CachedUniquedStringImpl::decode const):
* runtime/CommonIdentifiers.cpp:
(JSC::CommonIdentifiers::CommonIdentifiers):
(JSC::CommonIdentifiers::lookUpPrivateName const):
(JSC::CommonIdentifiers::getPublicName const):
(JSC::CommonIdentifiers::lookUpPublicName const): Deleted.
* runtime/CommonIdentifiers.h:
* runtime/ExceptionHelpers.cpp:
(JSC::createUndefinedVariableError):
* runtime/Identifier.cpp:
(JSC::Identifier::dump const):
* runtime/Identifier.h:
* runtime/IdentifierInlines.h:
(JSC::Identifier::fromUid):
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::JSTypedArrayViewPrototype::finishCreation):
* tools/JSDollarVM.cpp:
(JSC::functionGetPrivateProperty):
2019-02-06 Keith Rollin <krollin@apple.com>
Really enable the automatic checking and regenerations of .xcfilelists during builds
https://bugs.webkit.org/show_bug.cgi?id=194357
<rdar://problem/47861231>
Reviewed by Chris Dumez.
Bug 194124 was supposed to enable the automatic checking and
regenerating of .xcfilelist files during the build. While related
changes were included in that patch, the change to actually enable the
operation somehow was omitted. This patch actually enables the
operation. The check-xcfilelist.sh scripts now check
WK_DISABLE_CHECK_XCFILELISTS, and if it's "1", opts-out the developer
from the checking.
* Scripts/check-xcfilelists.sh:
2019-02-06 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Unify indirectEvalExecutableSpace and directEvalExecutableSpace
https://bugs.webkit.org/show_bug.cgi?id=194339
Reviewed by Michael Saboff.
DirectEvalExecutable and IndirectEvalExecutable have completely same memory layout.
They have even the same structure. This patch unifies the subspaces for them.
* runtime/DirectEvalExecutable.h:
* runtime/EvalExecutable.h:
(JSC::EvalExecutable::subspaceFor):
* runtime/IndirectEvalExecutable.h:
* runtime/VM.cpp:
* runtime/VM.h:
(JSC::VM::forEachScriptExecutableSpace):
2019-02-06 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] NativeExecutable should be smaller
https://bugs.webkit.org/show_bug.cgi?id=194331
Reviewed by Michael Saboff.
NativeExecutable takes 88 bytes now. Since our GC rounds the size with 16, it actually takes 96 bytes in IsoSubspaces.
Since a lot of NativeExecutable are allocated, we already has two MarkedBlocks even just after JSGlobalObject initialization.
This patch makes sizeof(NativeExecutable) 64 bytes, which is 32 bytes smaller than 96 bytes. Now our JSGlobalObject initialization
only takes one MarkedBlock for NativeExecutable.
To make NativeExecutable smaller,
1. m_numParametersForCall and m_numParametersForConstruct in ExecutableBase are only meaningful in ScriptExecutable subclasses. Since
they are not touched from JIT, we can remove them from ExecutableBase and move them to ScriptExecutable.
2. DOMJIT::Signature* is rarely used. Rather than having it in NativeExecutable, we should put it in NativeJITCode. Since NativeExecutable
always has JITCode, we can safely query the value from NativeExecutable. This patch creates NativeDOMJITCode, which is a subclass of
NativeJITCode, and instantiated only when DOMJIT::Signature* is given.
3. Move Intrinsic to a member of ScriptExecutable or JITCode. Since JITCode has some paddings to put things, we can leverage this to put
Intrinsic for NativeExecutable.
We also move "clearCode" code from ExecutableBase to ScriptExecutable since it is only valid for ScriptExecutable subclasses.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CallVariant.h:
* interpreter/Interpreter.cpp:
* jit/JITCode.cpp:
(JSC::DirectJITCode::DirectJITCode):
(JSC::NativeJITCode::NativeJITCode):
(JSC::NativeDOMJITCode::NativeDOMJITCode):
* jit/JITCode.h:
(JSC::JITCode::signature const):
(JSC::JITCode::intrinsic):
* jit/JITOperations.cpp:
* jit/JITThunks.cpp:
(JSC::JITThunks::hostFunctionStub):
* jit/Repatch.cpp:
* llint/LLIntSlowPaths.cpp:
* runtime/ExecutableBase.cpp:
(JSC::ExecutableBase::dump const):
(JSC::ExecutableBase::hashFor const):
(JSC::ExecutableBase::hasClearableCode const): Deleted.
(JSC::ExecutableBase::clearCode): Deleted.
* runtime/ExecutableBase.h:
(JSC::ExecutableBase::ExecutableBase):
(JSC::ExecutableBase::isModuleProgramExecutable):
(JSC::ExecutableBase::isHostFunction const):
(JSC::ExecutableBase::generatedJITCodeForCall const):
(JSC::ExecutableBase::generatedJITCodeForConstruct const):
(JSC::ExecutableBase::generatedJITCodeFor const):
(JSC::ExecutableBase::generatedJITCodeForCall): Deleted.
(JSC::ExecutableBase::generatedJITCodeForConstruct): Deleted.
(JSC::ExecutableBase::generatedJITCodeFor): Deleted.
(JSC::ExecutableBase::offsetOfNumParametersFor): Deleted.
(JSC::ExecutableBase::hasJITCodeForCall const): Deleted.
(JSC::ExecutableBase::hasJITCodeForConstruct const): Deleted.
(JSC::ExecutableBase::intrinsic const): Deleted.
* runtime/ExecutableBaseInlines.h: Added.
(JSC::ExecutableBase::intrinsic const):
(JSC::ExecutableBase::hasJITCodeForCall const):
(JSC::ExecutableBase::hasJITCodeForConstruct const):
* runtime/JSBoundFunction.cpp:
* runtime/JSType.cpp:
(WTF::printInternal):
* runtime/JSType.h:
* runtime/NativeExecutable.cpp:
(JSC::NativeExecutable::create):
(JSC::NativeExecutable::createStructure):
(JSC::NativeExecutable::NativeExecutable):
(JSC::NativeExecutable::signatureFor const):
(JSC::NativeExecutable::intrinsic const):
* runtime/NativeExecutable.h:
* runtime/ScriptExecutable.cpp:
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::clearCode):
(JSC::ScriptExecutable::installCode):
(JSC::ScriptExecutable::hasClearableCode const):
* runtime/ScriptExecutable.h:
(JSC::ScriptExecutable::intrinsic const):
(JSC::ScriptExecutable::hasJITCodeForCall const):
(JSC::ScriptExecutable::hasJITCodeForConstruct const):
* runtime/VM.cpp:
(JSC::VM::getHostFunction):
2019-02-06 Pablo Saavedra <psaavedra@igalia.com>
Build failure after r240431
https://bugs.webkit.org/show_bug.cgi?id=194330
Reviewed by Žan Doberšek.
* API/glib/JSCOptions.cpp:
2019-02-05 Mark Lam <mark.lam@apple.com>
Fix DFG's doesGC() for a few more nodes.
https://bugs.webkit.org/show_bug.cgi?id=194307
<rdar://problem/47832956>
Reviewed by Yusuke Suzuki.
Fix doesGC() for the following nodes:
NumberToStringWithValidRadixConstant:
Calls operationInt32ToStringWithValidRadix(), which calls int32ToString(),
which can allocate a string.
Calls operationInt52ToStringWithValidRadix(), which calls int52ToString(),
which can allocate a string.
Calls operationDoubleToStringWithValidRadix(), which calls numberToString(),
which can allocate a string.
RegExpExecNonGlobalOrSticky: calls createRegExpMatchesArray() which allocates
memory for all kinds of objects.
RegExpMatchFast: calls operationRegExpMatchFastString(), which calls
RegExpObject::execInline() and RegExpObject::matchGlobal(). Both of
these allocates memory for the match result.
RegExpMatchFastGlobal: calls operationRegExpMatchFastGlobalString(), which
calls RegExpObject's collectMatches(), which allocates an array amongst
other objects.
StringFromCharCode:
If the uint32 code to convert is greater than maxSingleCharacterString,
we'll call operationStringFromCharCode(), which calls jsSingleCharacterString(),
which allocates a new string if the code is greater than maxSingleCharacterString.
Also fix SpeculativeJIT::compileFromCharCode() and FTL's compileStringFromCharCode()
to use maxSingleCharacterString instead of a literal constant.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileFromCharCode):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):
2019-02-05 Keith Rollin <krollin@apple.com>
Enable the automatic checking and regenerations of .xcfilelists during builds
https://bugs.webkit.org/show_bug.cgi?id=194124
<rdar://problem/47721277>
Reviewed by Tim Horton.
Bug 193790 add a facility for checking -- during build time -- that
any needed .xcfilelist files are up-to-date and for updating them if
they are not. This facility was initially opt-in by setting
WK_ENABLE_CHECK_XCFILELISTS until other pieces were in place and until
the process seemed robust. Its now time to enable this facility and
make it opt-out. If there is a need to disable this facility, set and
export WK_DISABLE_CHECK_XCFILELISTS=1 in your environment before
running `make` or `build-webkit`, or before running Xcode from the
command line.
Additionally, remove the step that generates a list of source files
going into the UnifiedSources build step. It's only necessarily to
specify Sources.txt and SourcesCocoa.txt as inputs.
* JavaScriptCore.xcodeproj/project.pbxproj:
* UnifiedSources-input.xcfilelist: Removed.
2019-02-05 Keith Rollin <krollin@apple.com>
Update .xcfilelist files
https://bugs.webkit.org/show_bug.cgi?id=194121
<rdar://problem/47720863>
Reviewed by Tim Horton.
Preparatory to enabling the facility for automatically updating the
.xcfilelist files, check in a freshly-updated set so that not everyone
runs up against having to regenerate them themselves.
* DerivedSources-input.xcfilelist:
* DerivedSources-output.xcfilelist:
2019-02-05 Andy VanWagoner <andy@vanwagoner.family>
[INTL] improve efficiency of Intl.NumberFormat formatToParts
https://bugs.webkit.org/show_bug.cgi?id=185557
Reviewed by Mark Lam.
Since field nesting depth is minimal, this algorithm should be effectively O(n),
where n is the number of characters in the formatted string.
It may be less memory efficient than the previous impl, since the intermediate Vector
is the length of the string, instead of the count of the fields.
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::formatToParts):
* runtime/IntlNumberFormat.h:
2019-02-05 Mark Lam <mark.lam@apple.com>
Move DFG nodes that clobberize() says will write(Heap) to the doesGC() list that returns true.
https://bugs.webkit.org/show_bug.cgi?id=194298
<rdar://problem/47827555>
Reviewed by Saam Barati.
We do this for 3 reasons:
1. It's clearer when reading doesGC()'s code that these nodes will return true.
2. If things change in the future where clobberize() no longer reports these nodes
as write(Heap), each node should be vetted first to make sure that it can never
GC before being moved back to the doesGC() list that returns false.
3. This reduces the list of nodes that we need to audit to make sure doesGC() is
correct in its claims about the nodes' GCing possibility.
The list of nodes moved are:
ArrayPush
ArrayPop
Call
CallEval
CallForwardVarargs
CallVarargs
Construct
ConstructForwardVarargs
ConstructVarargs
DefineDataProperty
DefineAccessorProperty
DeleteById
DeleteByVal
DirectCall
DirectConstruct
DirectTailCallInlinedCaller
GetById
GetByIdDirect
GetByIdDirectFlush
GetByIdFlush
GetByIdWithThis
GetByValWithThis
GetDirectPname
GetDynamicVar
HasGenericProperty
HasOwnProperty
HasStructureProperty
InById
InByVal
InstanceOf
InstanceOfCustom
LoadVarargs
NumberToStringWithRadix
PutById
PutByIdDirect
PutByIdFlush
PutByIdWithThis
PutByOffset
PutByValWithThis
PutDynamicVar
PutGetterById
PutGetterByVal
PutGetterSetterById
PutSetterById
PutSetterByVal
PutStack
PutToArguments
RegExpExec
RegExpTest
ResolveScope
ResolveScopeForHoistingFuncDeclInEval
TailCall
TailCallForwardVarargsInlinedCaller
TailCallInlinedCaller
TailCallVarargsInlinedCaller
ToNumber
ToPrimitive
ValueNegate
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
2019-02-05 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Shrink sizeof(UnlinkedCodeBlock)
https://bugs.webkit.org/show_bug.cgi?id=194281
Reviewed by Michael Saboff.
This patch first attempts to reduce the size of UnlinkedCodeBlock in a relatively simpler way. Reordering members, remove unused member, and
move rarely used members to RareData. This changes sizeof(UnlinkedCodeBlock) from 312 to 256.
Still we have several chances to reduce sizeof(UnlinkedCodeBlock). Making more Vectors to RefCountedArrays can be done with some restructuring
of generatorification phase. It would be possible to remove m_sourceURLDirective and m_sourceMappingURLDirective from UnlinkedCodeBlock since
they should be in SourceProvider and that should be enough. These changes require some intrusive modifications and we make them as a future work.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::bitVectors const): Deleted.
* bytecode/CodeType.h:
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
(JSC::UnlinkedCodeBlock::shrinkToFit):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::bitVector):
(JSC::UnlinkedCodeBlock::addBitVector):
(JSC::UnlinkedCodeBlock::addSetConstant):
(JSC::UnlinkedCodeBlock::constantRegisters):
(JSC::UnlinkedCodeBlock::numberOfConstantIdentifierSets const):
(JSC::UnlinkedCodeBlock::constantIdentifierSets):
(JSC::UnlinkedCodeBlock::codeType const):
(JSC::UnlinkedCodeBlock::didOptimize const):
(JSC::UnlinkedCodeBlock::setDidOptimize):
(JSC::UnlinkedCodeBlock::usesGlobalObject const): Deleted.
(JSC::UnlinkedCodeBlock::setGlobalObjectRegister): Deleted.
(JSC::UnlinkedCodeBlock::globalObjectRegister const): Deleted.
(JSC::UnlinkedCodeBlock::bitVectors const): Deleted.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitLoad):
(JSC::BytecodeGenerator::emitLoadGlobalObject): Deleted.
* bytecompiler/BytecodeGenerator.h:
* runtime/CachedTypes.cpp:
(JSC::CachedCodeBlockRareData::encode):
(JSC::CachedCodeBlockRareData::decode const):
(JSC::CachedCodeBlock::scopeRegister const):
(JSC::CachedCodeBlock::codeType const):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
(JSC::CachedCodeBlock<CodeBlockType>::decode const):
(JSC::CachedCodeBlock<CodeBlockType>::encode):
(JSC::CachedCodeBlock::globalObjectRegister const): Deleted.
2019-02-04 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, add missing exception checks after r240637
https://bugs.webkit.org/show_bug.cgi?id=193546
* tools/JSDollarVM.cpp:
(JSC::functionShadowChickenFunctionsOnStack):
2019-02-04 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Shrink size of VM by lazily allocating IsoSubspaces for non-common types
https://bugs.webkit.org/show_bug.cgi?id=193993
Reviewed by Keith Miller.
JSC::VM has a lot of IsoSubspaces, and each takes 504B. This unnecessarily makes VM so large.
And some of them are rarely used. We should allocate it lazily.
In this patch, we make some `IsoSubspaces` `std::unique_ptr<IsoSubspace>`. And we add ensureXXXSpace
functions which allocate IsoSubspaces lazily. This function is used by subspaceFor<> in each class.
And we also add subspaceForConcurrently<> function, which is called from concurrent JIT tiers. This
returns nullptr if the subspace is not allocated yet. JSCell::subspaceFor now takes second template
parameter which tells the function whether subspaceFor is concurrently done. If the IsoSubspace is
lazily created, we may return nullptr for the concurrent access. We ensure the space's initialization
by using WTF::storeStoreFence when lazily allocating it.
In GC's constraint solving, we may touch these lazily allocated spaces. At that time, we check the
existence of the space before touching this. This is not racy because the main thread is stopped when
the constraint solving is working.
This changes sizeof(VM) from 64736 to 56472.
Another interesting thing is that we removed `PreventCollectionScope preventCollectionScope(heap);` in
`Subspace::initialize`. This is really dangerous API since it easily causes dead-lock between the
collector and the mutator if IsoSubspace is dynamically created. We do want to make IsoSubspaces
dynamically-created ones since the requirement of the pre-allocation poses a scalability problem
of IsoSubspace adoption because IsoSubspace is large. Registered Subspace is only touched in the
EndPhase, and the peripheries should be stopped when running EndPhase. Thus, as long as the main thread
can run this IsoSubspace code, the collector is never EndPhase. So this is safe.
* API/JSCallbackFunction.h:
* API/ObjCCallbackFunction.h:
(JSC::ObjCCallbackFunction::subspaceFor):
* API/glib/JSCCallbackFunction.h:
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::visitChildren):
(JSC::CodeBlock::finalizeUnconditionally):
* bytecode/CodeBlock.h:
* bytecode/EvalCodeBlock.h:
* bytecode/ExecutableToCodeBlockEdge.h:
* bytecode/FunctionCodeBlock.h:
* bytecode/ModuleProgramCodeBlock.h:
* bytecode/ProgramCodeBlock.h:
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
* bytecode/UnlinkedFunctionExecutable.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
(JSC::DFG::SpeculativeJIT::compileMakeRope):
(JSC::DFG::SpeculativeJIT::compileNewObject):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
(JSC::FTL::DFG::LowerDFGToB3::allocateObject):
(JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject):
(JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedCell):
* heap/Heap.cpp:
(JSC::Heap::finalizeUnconditionalFinalizers):
(JSC::Heap::deleteAllCodeBlocks):
(JSC::Heap::deleteAllUnlinkedCodeBlocks):
(JSC::Heap::addCoreConstraints):
* heap/Subspace.cpp:
(JSC::Subspace::initialize):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize):
(JSC::AssemblyHelpers::emitAllocateVariableSizedCell):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_new_object):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_new_object):
* runtime/DirectArguments.h:
* runtime/DirectEvalExecutable.h:
* runtime/ErrorInstance.h:
(JSC::ErrorInstance::subspaceFor):
* runtime/ExecutableBase.h:
* runtime/FunctionExecutable.h:
* runtime/IndirectEvalExecutable.h:
* runtime/InferredValue.cpp:
(JSC::InferredValue::visitChildren):
* runtime/InferredValue.h:
* runtime/InferredValueInlines.h:
(JSC::InferredValue::finalizeUnconditionally):
* runtime/InternalFunction.h:
* runtime/JSAsyncFunction.h:
* runtime/JSAsyncGeneratorFunction.h:
* runtime/JSBoundFunction.h:
* runtime/JSCell.h:
(JSC::subspaceFor):
(JSC::subspaceForConcurrently):
* runtime/JSCellInlines.h:
(JSC::allocatorForNonVirtualConcurrently):
* runtime/JSCustomGetterSetterFunction.h:
* runtime/JSDestructibleObject.h:
* runtime/JSFunction.h:
* runtime/JSGeneratorFunction.h:
* runtime/JSImmutableButterfly.h:
* runtime/JSLexicalEnvironment.h:
(JSC::JSLexicalEnvironment::subspaceFor):
* runtime/JSNativeStdFunction.h:
* runtime/JSSegmentedVariableObject.h:
* runtime/JSString.h:
* runtime/ModuleProgramExecutable.h:
* runtime/NativeExecutable.h:
* runtime/ProgramExecutable.h:
* runtime/PropertyMapHashTable.h:
* runtime/ProxyRevoke.h:
* runtime/ScopedArguments.h:
* runtime/ScriptExecutable.cpp:
(JSC::ScriptExecutable::clearCode):
(JSC::ScriptExecutable::installCode):
* runtime/Structure.h:
* runtime/StructureRareData.h:
* runtime/SubspaceAccess.h: Copied from Source/JavaScriptCore/runtime/InferredValueInlines.h.
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
(JSC::VM::SpaceAndSet::SpaceAndSet):
(JSC::VM::SpaceAndSet::setFor):
(JSC::VM::forEachScriptExecutableSpace):
(JSC::VM::SpaceAndFinalizerSet::SpaceAndFinalizerSet): Deleted.
(JSC::VM::SpaceAndFinalizerSet::finalizerSetFor): Deleted.
(JSC::VM::ScriptExecutableSpaceAndSet::ScriptExecutableSpaceAndSet): Deleted.
(JSC::VM::ScriptExecutableSpaceAndSet::clearableCodeSetFor): Deleted.
(JSC::VM::UnlinkedFunctionExecutableSpaceAndSet::UnlinkedFunctionExecutableSpaceAndSet): Deleted.
(JSC::VM::UnlinkedFunctionExecutableSpaceAndSet::clearableCodeSetFor): Deleted.
* runtime/WeakMapImpl.h:
(JSC::WeakMapImpl::subspaceFor):
* wasm/js/JSWebAssemblyCodeBlock.h:
* wasm/js/JSWebAssemblyMemory.h:
* wasm/js/WebAssemblyFunction.h:
* wasm/js/WebAssemblyWrapperFunction.h:
2019-02-04 Keith Miller <keith_miller@apple.com>
Change llint operand macros to inline functions
https://bugs.webkit.org/show_bug.cgi?id=194248
Reviewed by Mark Lam.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::getNonConstantOperand):
(JSC::LLInt::getOperand):
(JSC::LLInt::llint_trace_value):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::getByVal):
(JSC::LLInt::genericCall):
(JSC::LLInt::varargsSetup):
(JSC::LLInt::commonCallEval):
2019-02-04 Robin Morisset <rmorisset@apple.com>
when lowering AssertNotEmpty, create the value before creating the patchpoint
https://bugs.webkit.org/show_bug.cgi?id=194231
Reviewed by Saam Barati.
This is a very simple change: we should never generate B3 IR where an instruction depends on a value that comes later in the instruction stream.
AssertNotEmpty was generating some such IR, it probably slipped through until now because it is a rather rare and tricky instruction to generate.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileAssertNotEmpty):
2019-02-04 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] ExecutableToCodeBlockEdge should be smaller
https://bugs.webkit.org/show_bug.cgi?id=194244
Reviewed by Michael Saboff.
ExecutableToCodeBlockEdge is allocated so many times. However its memory layout is not efficient.
sizeof(ExecutableToCodeBlockEdge) is 24bytes, but it discards 7bytes due to one bool m_isActive flag.
Because our size classes are rounded by 16bytes, ExecutableToCodeBlockEdge takes 32bytes. So, half of
it is wasted. We should fit it into 16bytes so that we can efficiently allocate it.
In this patch, we leverages TypeInfoMayBePrototype bit in JSTypeInfo. It is a bit special TypeInfo bit
since this is per-cell bit. We rename this to TypeInfoPerCellBit, and use it as a `m_isActive` mark in
ExecutableToCodeBlockEdge. In JSObject subclasses, we use it as MayBePrototype flag.
Since this flag is not changed in CAS style, we must not change this in concurrent threads. This is OK
for ExecutableToCodeBlockEdge's m_isActive flag since this is touched on the main thread (ScriptExecutable::installCode
does not touch it if it is called in non-main threads).
* bytecode/ExecutableToCodeBlockEdge.cpp:
(JSC::ExecutableToCodeBlockEdge::finishCreation):
(JSC::ExecutableToCodeBlockEdge::visitChildren):
(JSC::ExecutableToCodeBlockEdge::activate):
(JSC::ExecutableToCodeBlockEdge::deactivate):
(JSC::ExecutableToCodeBlockEdge::isActive const):
* bytecode/ExecutableToCodeBlockEdge.h:
* runtime/JSCell.h:
* runtime/JSCellInlines.h:
(JSC::JSCell::perCellBit const):
(JSC::JSCell::setPerCellBit):
(JSC::JSCell::mayBePrototype const): Deleted.
(JSC::JSCell::didBecomePrototype): Deleted.
* runtime/JSObject.cpp:
(JSC::JSObject::setPrototypeDirect):
* runtime/JSObject.h:
* runtime/JSObjectInlines.h:
(JSC::JSObject::mayBePrototype const):
(JSC::JSObject::didBecomePrototype):
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::perCellBit):
(JSC::TypeInfo::mergeInlineTypeFlags):
(JSC::TypeInfo::mayBePrototype): Deleted.
2019-02-04 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Shrink size of FunctionExecutable
https://bugs.webkit.org/show_bug.cgi?id=194191
Reviewed by Michael Saboff.
This patch reduces the size of FunctionExecutable. Since it is allocated in IsoSubspace, reducing the size directly
improves the allocation efficiency.
1. ScriptExecutable (base class of FunctionExecutable) has several members, but it is meaningful only in FunctionExecutable.
We remove this from ScriptExecutable, and move it to FunctionExecutable.
2. FunctionExecutable has several data which are rarely used. One for FunctionOverrides functionality, which is typically
used for JSC debugging purpose, and another is TypeSet and offsets for type profiler. We move them to RareData and reduce
the size of FunctionExecutable in the common case.
This patch changes the size of FunctionExecutable from 176 to 144.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpSource):
(JSC::CodeBlock::finishCreation):
* dfg/DFGNode.h:
(JSC::DFG::Node::OpInfoWrapper::as const):
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::computeLineAndColumn const):
* runtime/ExecutableBase.h:
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::FunctionExecutable::ensureRareDataSlow):
* runtime/FunctionExecutable.h:
* runtime/Intrinsic.h:
* runtime/ModuleProgramExecutable.cpp:
(JSC::ModuleProgramExecutable::ModuleProgramExecutable):
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::ProgramExecutable):
* runtime/ScriptExecutable.cpp:
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::overrideLineNumber const):
(JSC::ScriptExecutable::typeProfilingStartOffset const):
(JSC::ScriptExecutable::typeProfilingEndOffset const):
* runtime/ScriptExecutable.h:
(JSC::ScriptExecutable::firstLine const):
(JSC::ScriptExecutable::setOverrideLineNumber): Deleted.
(JSC::ScriptExecutable::hasOverrideLineNumber const): Deleted.
(JSC::ScriptExecutable::overrideLineNumber const): Deleted.
(JSC::ScriptExecutable::typeProfilingStartOffset const): Deleted.
(JSC::ScriptExecutable::typeProfilingEndOffset const): Deleted.
* runtime/StackFrame.cpp:
(JSC::StackFrame::computeLineAndColumn const):
* tools/JSDollarVM.cpp:
(JSC::functionReturnTypeFor):
2019-02-04 Mark Lam <mark.lam@apple.com>
DFG's doesGC() is incorrect about the SameValue node's behavior.
https://bugs.webkit.org/show_bug.cgi?id=194211
<rdar://problem/47608913>
Reviewed by Saam Barati.
Only the DoubleRepUse case is guaranteed to not GC. The other case may GC because
it calls operationSameValue() which may allocate memory for resolving ropes.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
2019-02-03 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] UnlinkedMetadataTable assumes that MetadataTable is destroyed before it is destructed, but order of destruction of JS heap cells are not guaranteed
https://bugs.webkit.org/show_bug.cgi?id=194031
Reviewed by Saam Barati.
UnlinkedMetadataTable assumes that MetadataTable linked against this UnlinkedMetadataTable is already destroyed when UnlinkedMetadataTable is destroyed.
This means that UnlinkedCodeBlock is destroyed after all the linked CodeBlocks are destroyed. But this assumption is not valid since GC's finalizer
sweeps objects without considering the dependencies among swept objects. UnlinkedMetadataTable can be destroyed even before linked MetadataTable is
destroyed if UnlinkedCodeBlock is destroyed before linked CodeBlock is destroyed.
To make the above assumption valid, we make UnlinkedMetadataTable RefCounted object, and make MetadataTable hold the strong ref to UnlinkedMetadataTable.
This ensures that UnlinkedMetadataTable is destroyed after all the linked MetadataTables are destroyed.
* bytecode/MetadataTable.cpp:
(JSC::MetadataTable::MetadataTable):
(JSC::MetadataTable::~MetadataTable):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
(JSC::UnlinkedCodeBlock::visitChildren):
(JSC::UnlinkedCodeBlock::estimatedSize):
(JSC::UnlinkedCodeBlock::setInstructions):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::metadata):
(JSC::UnlinkedCodeBlock::metadataSizeInBytes):
* bytecode/UnlinkedMetadataTable.h:
(JSC::UnlinkedMetadataTable::create):
* bytecode/UnlinkedMetadataTableInlines.h:
(JSC::UnlinkedMetadataTable::UnlinkedMetadataTable):
* runtime/CachedTypes.cpp:
(JSC::CachedMetadataTable::decode const):
(JSC::CachedCodeBlock::metadata const):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
(JSC::CachedCodeBlock<CodeBlockType>::decode const):
(JSC::CachedCodeBlock<CodeBlockType>::encode):
2019-02-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Decouple JIT related data from CodeBlock
https://bugs.webkit.org/show_bug.cgi?id=194187
Reviewed by Saam Barati.
CodeBlock holds bunch of data which is only used after JIT starts compiling it.
We have three types of data in CodeBlock.
1. The data which is always used. CodeBlock needs to hold it.
2. The data which is touched even in LLInt, but it is only meaningful in JIT tiers. The example is profiling.
3. The data which is used after the JIT compiler starts running for the given CodeBlock.
This patch decouples (3) from CodeBlock as CodeBlock::JITData. Even if we have bunch of CodeBlocks, only small
number of them gets JIT compilation. Always allocating (3) data enlarges the size of CodeBlock, leading to the
memory waste. Potentially we can decouple (2) in another data structure, but we first do (3) since (3) is beneficial
in both non-JIT and *JIT* modes.
JITData is created only when JIT compiler wants to use it. So it can be concurrently created and used, so it is guarded
by the lock of CodeBlock.
The size of CodeBlock is reduced from 512 to 352.
This patch improves memory footprint and gets 1.1% improvement in RAMification.
Footprint geomean: 36696503 (34.997 MB)
Peak Footprint geomean: 38595988 (36.808 MB)
Score: 37634263 (35.891 MB)
Footprint geomean: 37172768 (35.451 MB)
Peak Footprint geomean: 38978288 (37.173 MB)
Score: 38064824 (36.301 MB)
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::~CodeBlock):
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::ensureJITDataSlow):
(JSC::CodeBlock::finalizeBaselineJITInlineCaches):
(JSC::CodeBlock::getICStatusMap):
(JSC::CodeBlock::addStubInfo):
(JSC::CodeBlock::addJITAddIC):
(JSC::CodeBlock::addJITMulIC):
(JSC::CodeBlock::addJITSubIC):
(JSC::CodeBlock::addJITNegIC):
(JSC::CodeBlock::findStubInfo):
(JSC::CodeBlock::addByValInfo):
(JSC::CodeBlock::addCallLinkInfo):
(JSC::CodeBlock::getCallLinkInfoForBytecodeIndex):
(JSC::CodeBlock::addRareCaseProfile):
(JSC::CodeBlock::rareCaseProfileForBytecodeOffset):
(JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset):
(JSC::CodeBlock::resetJITData):
(JSC::CodeBlock::stronglyVisitStrongReferences):
(JSC::CodeBlock::shrinkToFit):
(JSC::CodeBlock::linkIncomingCall):
(JSC::CodeBlock::linkIncomingPolymorphicCall):
(JSC::CodeBlock::unlinkIncomingCalls):
(JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
(JSC::CodeBlock::dumpValueProfiles):
(JSC::CodeBlock::setPCToCodeOriginMap):
(JSC::CodeBlock::findPC):
(JSC::CodeBlock::dumpMathICStats):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::ensureJITData):
(JSC::CodeBlock::setJITCodeMap):
(JSC::CodeBlock::jitCodeMap):
(JSC::CodeBlock::likelyToTakeSlowCase):
(JSC::CodeBlock::couldTakeSlowCase):
(JSC::CodeBlock::lazyOperandValueProfiles):
(JSC::CodeBlock::stubInfoBegin): Deleted.
(JSC::CodeBlock::stubInfoEnd): Deleted.
(JSC::CodeBlock::callLinkInfosBegin): Deleted.
(JSC::CodeBlock::callLinkInfosEnd): Deleted.
(JSC::CodeBlock::jitCodeMap const): Deleted.
(JSC::CodeBlock::numberOfRareCaseProfiles): Deleted.
* bytecode/MethodOfGettingAValueProfile.cpp:
(JSC::MethodOfGettingAValueProfile::emitReportValue const):
(JSC::MethodOfGettingAValueProfile::reportValue):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* jit/JIT.h:
* jit/JITOperations.cpp:
(JSC::tryGetByValOptimize):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::privateCompileGetByVal):
(JSC::JIT::privateCompilePutByVal):
2018-12-16 Darin Adler <darin@apple.com>
Convert additional String::format clients to alternative approaches
https://bugs.webkit.org/show_bug.cgi?id=192746
Reviewed by Alexey Proskuryakov.
* inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::stopTiming): Use makeString
and FormattedNumber::fixedWidth.
2019-02-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Remove some of IsoSubspaces for JSFunction subclasses
https://bugs.webkit.org/show_bug.cgi?id=194177
Reviewed by Saam Barati.
JSGeneratorFunction, JSAsyncFunction, and JSAsyncGeneratorFunction do not add any fields / classInfo methods.
We can share the IsoSubspace for JSFunction.
* runtime/JSAsyncFunction.h:
* runtime/JSAsyncGeneratorFunction.h:
* runtime/JSGeneratorFunction.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2019-02-01 Mark Lam <mark.lam@apple.com>
Remove invalid assertion in DFG's compileDoubleRep().
https://bugs.webkit.org/show_bug.cgi?id=194130
<rdar://problem/47699474>
Reviewed by Saam Barati.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileDoubleRep):
2019-02-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Unify CodeBlock IsoSubspaces
https://bugs.webkit.org/show_bug.cgi?id=194167
Reviewed by Saam Barati.
When we move CodeBlock into its IsoSubspace, we create IsoSubspaces for each subclass of CodeBlock.
But this is not necessary since,
1. They do not override the classInfo methods.
2. sizeof(ProgramCodeBlock etc.) == sizeof(CodeBlock) since subclasses adds no additional fields.
Creating IsoSubspace for each subclass is costly in terms of memory. Especially, IsoSubspace for
ProgramCodeBlock is. We typically create only one ProgramCodeBlock, and it means the rest of the
MarkedBlock (16KB - sizeof(footer) - sizeof(ProgramCodeBlock)) is just wasted.
This patch unifies these IsoSubspaces into one.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::destroy):
* bytecode/CodeBlock.h:
* bytecode/EvalCodeBlock.cpp:
(JSC::EvalCodeBlock::destroy): Deleted.
* bytecode/EvalCodeBlock.h: We drop some utility functions in EvalCodeBlock and use UnlinkedEvalCodeBlock's one directly.
* bytecode/FunctionCodeBlock.cpp:
(JSC::FunctionCodeBlock::destroy): Deleted.
* bytecode/FunctionCodeBlock.h:
* bytecode/GlobalCodeBlock.h:
* bytecode/ModuleProgramCodeBlock.cpp:
(JSC::ModuleProgramCodeBlock::destroy): Deleted.
* bytecode/ModuleProgramCodeBlock.h:
* bytecode/ProgramCodeBlock.cpp:
(JSC::ProgramCodeBlock::destroy): Deleted.
* bytecode/ProgramCodeBlock.h:
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
(JSC::VM::forEachCodeBlockSpace):
2019-02-01 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, follow-up after r240859
https://bugs.webkit.org/show_bug.cgi?id=194145
Replace OOB HeapCellType with cellHeapCellType since they are completely the same.
And rename cellDangerousBitsSpace back to cellSpace.
* runtime/JSCellInlines.h:
(JSC::JSCell::subspaceFor):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2019-02-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Remove cellJSValueOOBSpace
https://bugs.webkit.org/show_bug.cgi?id=194145
Reviewed by Mark Lam.
* runtime/JSObject.h:
(JSC::JSObject::subspaceFor): Deleted.
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2019-01-31 Mark Lam <mark.lam@apple.com>
Remove poisoning from CodeBlock and LLInt code.
https://bugs.webkit.org/show_bug.cgi?id=194113
Reviewed by Yusuke Suzuki.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::~CodeBlock):
(JSC::CodeBlock::setConstantRegisters):
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::finalizeLLIntInlineCaches):
(JSC::CodeBlock::jettison):
(JSC::CodeBlock::predictedMachineCodeSize):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::vm const):
(JSC::CodeBlock::addConstant):
(JSC::CodeBlock::heap const):
(JSC::CodeBlock::replaceConstant):
* llint/LLIntOfflineAsmConfig.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::handleHostCall):
(JSC::LLInt::setUpCall):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2019-01-31 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Remove finalizer in AsyncFromSyncIteratorPrototype
https://bugs.webkit.org/show_bug.cgi?id=194107
Reviewed by Saam Barati.
AsyncFromSyncIteratorPrototype uses the finalizer, but it is not necessary since it does not hold any objects which require destruction.
We drop this finalizer. And we also make methods of AsyncFromSyncIteratorPrototype lazily allocated.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/AsyncFromSyncIteratorPrototype.cpp:
(JSC::AsyncFromSyncIteratorPrototype::AsyncFromSyncIteratorPrototype):
(JSC::AsyncFromSyncIteratorPrototype::finishCreation):
(JSC::AsyncFromSyncIteratorPrototype::create):
* runtime/AsyncFromSyncIteratorPrototype.h:
2019-01-31 Tadeu Zagallo <tzagallo@apple.com>
Fix `runJITThreadLimitTests` in testapi
https://bugs.webkit.org/show_bug.cgi?id=194064
<rdar://problem/46139147>
Reviewed by Mark Lam.
Fix typo where `targetNumberOfThreads` was not being used.
* API/tests/testapi.mm:
(runJITThreadLimitTests):
2019-01-31 Tadeu Zagallo <tzagallo@apple.com>
testapi fails RELEASE_ASSERT(codeBlock) in fetchFromDisk() of CodeCache.h
https://bugs.webkit.org/show_bug.cgi?id=194112
Reviewed by Mark Lam.
`testBytecodeCache` does not populate the bytecode cache for the global
CodeBlock, so it should only enable `forceDiskCache` after its execution.
* API/tests/testapi.mm:
(testBytecodeCache):
2019-01-31 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, follow-up after r240796
Initialize WriteBarrier<InferredValue> in the constructor. Otherwise, GC can see the broken one
when allocating InferredValue in FunctionExecutable::finishCreation.
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::FunctionExecutable::finishCreation):
2019-01-31 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Do not use InferredValue in non-JIT configuration
https://bugs.webkit.org/show_bug.cgi?id=194084
Reviewed by Saam Barati.
InferredValue is not meaningful if our VM is non-JIT configuration. InferredValue is used to watch the instantiation of the FunctionExecutable's
JSFunction and SymbolTable's JSScope to explore the chance of folding them into constants in DFG and FTL. If it is instantiated only once, we can
put a watchpoint and fold it into this constant. But if JIT is disabled, we do not need to care it.
Even in non-JIT configuration, we still use InferredValue for FunctionExecutable to determine whether the given FunctionExecutable is preferable
target for poly proto. If JSFunction for the FunctionExecutable is used as a constructor and instantiated more than once, poly proto Structure
seems appropriate for objects created by this JSFunction. But at that time, only thing we would like to know is that whether JSFunction for this
FunctionExecutable is instantiated multiple times. This does not require the full feature of InferredValue, WatchpointState is enough.
To summarize, since nobody uses InferredValue feature in non-JIT configuration, we should not create it.
* bytecode/ObjectAllocationProfileInlines.h:
(JSC::ObjectAllocationProfile::initializeProfile):
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::finishCreation):
(JSC::FunctionExecutable::visitChildren):
* runtime/FunctionExecutable.h:
* runtime/InferredValue.cpp:
(JSC::InferredValue::create):
* runtime/JSAsyncFunction.cpp:
(JSC::JSAsyncFunction::create):
* runtime/JSAsyncGeneratorFunction.cpp:
(JSC::JSAsyncGeneratorFunction::create):
* runtime/JSFunction.cpp:
(JSC::JSFunction::create):
* runtime/JSFunctionInlines.h:
(JSC::JSFunction::createWithInvalidatedReallocationWatchpoint):
* runtime/JSGeneratorFunction.cpp:
(JSC::JSGeneratorFunction::create):
* runtime/JSSymbolTableObject.h:
(JSC::JSSymbolTableObject::setSymbolTable):
* runtime/SymbolTable.cpp:
(JSC::SymbolTable::finishCreation):
* runtime/VM.cpp:
(JSC::VM::VM):
2019-01-31 Fujii Hironori <Hironori.Fujii@sony.com>
[CMake][JSC] Changing ud_opcode.py should trigger invoking ud_opcode.py
https://bugs.webkit.org/show_bug.cgi?id=194085
Reviewed by Yusuke Suzuki.
r240730 changed ud_itab.py and caused incremental build failures
for Ninja builds.
* CMakeLists.txt: Added ud_itab.py and optable.xml to UDIS_GEN_DEP.
2019-01-30 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Symbol should be in destructibleCellSpace
https://bugs.webkit.org/show_bug.cgi?id=194082
Reviewed by Saam Barati.
Because Symbol's member was not poisoned, we changed the subspace for Symbol from destructibleCellSpace
to cellJSValueOOBSpace. But the problem is cellJSValueOOBSpace is a space for cells which are not
destructible. As a result, Symbol::destroy is never called, and SymbolImpl is leaked. This patch makes
Symbol's space destructibleCellSpace to appropriately call the destructor.
* runtime/Symbol.h:
2019-01-30 Michael Catanzaro <mcatanzaro@igalia.com>
Unreviewed, rolling out r240755.
This was not correct
Reverted changeset:
"Unreviewed, fix GCC build after r240730"
https://bugs.webkit.org/show_bug.cgi?id=194041
https://trac.webkit.org/changeset/240755
2019-01-30 Michael Catanzaro <mcatanzaro@igalia.com>
Unreviewed, fix GCC build after r240730
https://bugs.webkit.org/show_bug.cgi?id=194041
<rdar://problem/47680981>
* disassembler/udis86/ud_itab.py:
(UdItabGenerator.genOpcodeTablesLookupIndex):
2019-01-30 Tadeu Zagallo <tzagallo@apple.com>
testapi's `testBytecodeCache` does not need to run the code twice
https://bugs.webkit.org/show_bug.cgi?id=194046
Reviewed by Mark Lam.
Since we populate the cache eagerly (unlike the stress tests) we don't
need to run the code twice.
* API/tests/testapi.mm:
(testBytecodeCache):
2019-01-30 Saam barati <sbarati@apple.com>
[WebAssembly] Change BBQ to generate Air IR
https://bugs.webkit.org/show_bug.cgi?id=191802
<rdar://problem/47651718>
Reviewed by Keith Miller.
This patch adds a new Wasm compiler for the BBQ tier. Instead
of compiling using B3-01, we now generate Air code directly.
The goal of doing this was to speed up compile times for Wasm
programs.
This patch provides us with a 20-30% compile time speedup. However, I
have ideas on how to improve compile times even further. For example,
we should probably implement a faster running register allocator:
https://bugs.webkit.org/show_bug.cgi?id=194036
We can also improve on the code we generate.
We should emit better code for Switch: https://bugs.webkit.org/show_bug.cgi?id=194053
And we should do better instruction selection in various
areas: https://bugs.webkit.org/show_bug.cgi?id=193999
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* b3/B3LowerToAir.cpp:
* b3/B3StackmapSpecial.h:
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::emitDefaultPrologue):
* b3/air/AirCode.h:
* b3/air/AirTmp.h:
(JSC::B3::Air::Tmp::Tmp):
* runtime/Options.h:
* wasm/WasmAirIRGenerator.cpp: Added.
(JSC::Wasm::ConstrainedTmp::ConstrainedTmp):
(JSC::Wasm::TypedTmp::TypedTmp):
(JSC::Wasm::TypedTmp::operator== const):
(JSC::Wasm::TypedTmp::operator!= const):
(JSC::Wasm::TypedTmp::operator bool const):
(JSC::Wasm::TypedTmp::operator Tmp const):
(JSC::Wasm::TypedTmp::operator Arg const):
(JSC::Wasm::TypedTmp::tmp const):
(JSC::Wasm::TypedTmp::type const):
(JSC::Wasm::AirIRGenerator::ControlData::ControlData):
(JSC::Wasm::AirIRGenerator::ControlData::dump const):
(JSC::Wasm::AirIRGenerator::ControlData::type const):
(JSC::Wasm::AirIRGenerator::ControlData::signature const):
(JSC::Wasm::AirIRGenerator::ControlData::hasNonVoidSignature const):
(JSC::Wasm::AirIRGenerator::ControlData::targetBlockForBranch):
(JSC::Wasm::AirIRGenerator::ControlData::convertIfToBlock):
(JSC::Wasm::AirIRGenerator::ControlData::resultForBranch const):
(JSC::Wasm::AirIRGenerator::emptyExpression):
(JSC::Wasm::AirIRGenerator::fail const):
(JSC::Wasm::AirIRGenerator::setParser):
(JSC::Wasm::AirIRGenerator::toTmpVector):
(JSC::Wasm::AirIRGenerator::validateInst):
(JSC::Wasm::AirIRGenerator::extractArg):
(JSC::Wasm::AirIRGenerator::append):
(JSC::Wasm::AirIRGenerator::appendEffectful):
(JSC::Wasm::AirIRGenerator::newTmp):
(JSC::Wasm::AirIRGenerator::g32):
(JSC::Wasm::AirIRGenerator::g64):
(JSC::Wasm::AirIRGenerator::f32):
(JSC::Wasm::AirIRGenerator::f64):
(JSC::Wasm::AirIRGenerator::tmpForType):
(JSC::Wasm::AirIRGenerator::addPatchpoint):
(JSC::Wasm::AirIRGenerator::emitPatchpoint):
(JSC::Wasm::AirIRGenerator::emitCheck):
(JSC::Wasm::AirIRGenerator::emitCCall):
(JSC::Wasm::AirIRGenerator::moveOpForValueType):
(JSC::Wasm::AirIRGenerator::instanceValue):
(JSC::Wasm::AirIRGenerator::fixupPointerPlusOffset):
(JSC::Wasm::AirIRGenerator::restoreWasmContextInstance):
(JSC::Wasm::AirIRGenerator::AirIRGenerator):
(JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
(JSC::Wasm::AirIRGenerator::emitThrowException):
(JSC::Wasm::AirIRGenerator::addLocal):
(JSC::Wasm::AirIRGenerator::addConstant):
(JSC::Wasm::AirIRGenerator::addArguments):
(JSC::Wasm::AirIRGenerator::getLocal):
(JSC::Wasm::AirIRGenerator::addUnreachable):
(JSC::Wasm::AirIRGenerator::addGrowMemory):
(JSC::Wasm::AirIRGenerator::addCurrentMemory):
(JSC::Wasm::AirIRGenerator::setLocal):
(JSC::Wasm::AirIRGenerator::getGlobal):
(JSC::Wasm::AirIRGenerator::setGlobal):
(JSC::Wasm::AirIRGenerator::emitCheckAndPreparePointer):
(JSC::Wasm::sizeOfLoadOp):
(JSC::Wasm::AirIRGenerator::emitLoadOp):
(JSC::Wasm::AirIRGenerator::load):
(JSC::Wasm::sizeOfStoreOp):
(JSC::Wasm::AirIRGenerator::emitStoreOp):
(JSC::Wasm::AirIRGenerator::store):
(JSC::Wasm::AirIRGenerator::addSelect):
(JSC::Wasm::AirIRGenerator::emitTierUpCheck):
(JSC::Wasm::AirIRGenerator::addLoop):
(JSC::Wasm::AirIRGenerator::addTopLevel):
(JSC::Wasm::AirIRGenerator::addBlock):
(JSC::Wasm::AirIRGenerator::addIf):
(JSC::Wasm::AirIRGenerator::addElse):
(JSC::Wasm::AirIRGenerator::addElseToUnreachable):
(JSC::Wasm::AirIRGenerator::addReturn):
(JSC::Wasm::AirIRGenerator::addBranch):
(JSC::Wasm::AirIRGenerator::addSwitch):
(JSC::Wasm::AirIRGenerator::endBlock):
(JSC::Wasm::AirIRGenerator::addEndToUnreachable):
(JSC::Wasm::AirIRGenerator::addCall):
(JSC::Wasm::AirIRGenerator::addCallIndirect):
(JSC::Wasm::AirIRGenerator::unify):
(JSC::Wasm::AirIRGenerator::unifyValuesWithBlock):
(JSC::Wasm::AirIRGenerator::dump):
(JSC::Wasm::AirIRGenerator::origin):
(JSC::Wasm::parseAndCompileAir):
(JSC::Wasm::AirIRGenerator::emitChecksForModOrDiv):
(JSC::Wasm::AirIRGenerator::emitModOrDiv):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32DivS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32RemS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32DivU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32RemU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64DivS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64RemS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64DivU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64RemU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Ctz>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Ctz>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Popcnt>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Popcnt>):
(JSC::Wasm::AirIRGenerator::addOp<F64ConvertUI64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32ConvertUI64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Nearest>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Nearest>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Trunc>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Trunc>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32TruncSF64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32TruncSF32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32TruncUF64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32TruncUF32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64TruncSF64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64TruncUF64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64TruncSF32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64TruncUF32>):
(JSC::Wasm::AirIRGenerator::addShift):
(JSC::Wasm::AirIRGenerator::addIntegerSub):
(JSC::Wasm::AirIRGenerator::addFloatingPointAbs):
(JSC::Wasm::AirIRGenerator::addFloatingPointBinOp):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Ceil>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Mul>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Sub>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Le>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32DemoteF64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Min>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Ne>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Lt>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Max>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Mul>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Div>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Clz>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Copysign>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64ConvertUI32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32ReinterpretI32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64And>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Ne>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Gt>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Sqrt>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Ge>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64GtS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64GtU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Eqz>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Div>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Add>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Or>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32LeU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32LeS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Ne>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Clz>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Neg>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32And>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32LtU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Rotr>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Abs>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32LtS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Eq>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Copysign>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32ConvertSI64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Rotl>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Lt>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64ConvertSI32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Eq>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Le>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Ge>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32ShrU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32ConvertUI32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32ShrS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32GeU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Ceil>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32GeS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Shl>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Floor>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Xor>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Abs>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Min>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Mul>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Sub>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32ReinterpretF32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Add>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Sub>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Or>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64LtU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64LtS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64ConvertSI64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Xor>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64GeU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Mul>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Sub>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64PromoteF32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Add>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64GeS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64ExtendUI32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Ne>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64ReinterpretI64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Eq>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Eq>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Floor>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32ConvertSI32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Eqz>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64ReinterpretF64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64ShrS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64ShrU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Sqrt>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Shl>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Gt>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32WrapI64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Rotl>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Rotr>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32GtU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64ExtendSI32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32GtS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Neg>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Max>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64LeU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64LeS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Add>):
* wasm/WasmAirIRGenerator.h: Added.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::emptyExpression):
* wasm/WasmBBQPlan.cpp:
(JSC::Wasm::BBQPlan::compileFunctions):
* wasm/WasmCallingConvention.cpp:
(JSC::Wasm::jscCallingConventionAir):
(JSC::Wasm::wasmCallingConventionAir):
* wasm/WasmCallingConvention.h:
(JSC::Wasm::CallingConvention::CallingConvention):
(JSC::Wasm::CallingConvention::marshallArgumentImpl const):
(JSC::Wasm::CallingConvention::marshallArgument const):
(JSC::Wasm::CallingConventionAir::CallingConventionAir):
(JSC::Wasm::CallingConventionAir::prologueScratch const):
(JSC::Wasm::CallingConventionAir::marshallArgumentImpl const):
(JSC::Wasm::CallingConventionAir::marshallArgument const):
(JSC::Wasm::CallingConventionAir::headerSizeInBytes):
(JSC::Wasm::CallingConventionAir::loadArguments const):
(JSC::Wasm::CallingConventionAir::setupCall const):
(JSC::Wasm::nextJSCOffset):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/WasmValidate.cpp:
(JSC::Wasm::Validate::emptyExpression):
2019-01-30 Robin Morisset <rmorisset@apple.com>
Object.keys can now lead to a PhantomNewArrayBuffer, OSR exit from the FTL should know how to materialize a NewArrayBuffer in that case
https://bugs.webkit.org/show_bug.cgi?id=194050
<rdar://problem/47595592>
Following https://bugs.webkit.org/show_bug.cgi?id=190047, PhantomNewArrayBuffer is no longer guaranteed to originate from a NewArrayBuffer in the baseline jit.
It can now come from Object.keys, which is a function call. We must teach the FTL how to OSR exit in that case.
Reviewed by Yusuke Suzuki.
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
2019-01-30 Tadeu Zagallo <tzagallo@apple.com>
Remove assertion that CachedSymbolTables should have no RareData
https://bugs.webkit.org/show_bug.cgi?id=194037
Reviewed by Mark Lam.
It turns out that we don't need to cache the SymbolTableRareData and
we should not assert that it's empty.
* runtime/CachedTypes.cpp:
(JSC::CachedSymbolTable::encode):
2019-01-30 Tadeu Zagallo <tzagallo@apple.com>
CachedBytecode's move constructor should not call `freeDataIfOwned`
https://bugs.webkit.org/show_bug.cgi?id=194045
Reviewed by Mark Lam.
That might result in freeing a garbage value
* parser/SourceProvider.h:
(JSC::CachedBytecode::CachedBytecode):
2019-01-30 Keith Miller <keith_miller@apple.com>
mul32 should convert powers of 2 to an lshift
https://bugs.webkit.org/show_bug.cgi?id=193957
Reviewed by Yusuke Suzuki.
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::mul32):
* assembler/testmasm.cpp:
(JSC::int32Operands):
(JSC::testMul32WithImmediates):
(JSC::run):
2019-01-30 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Make disassembler data structures constant read-only data
https://bugs.webkit.org/show_bug.cgi?id=194041
Reviewed by Mark Lam.
Bunch of disassembler data structures are not marked "const", which prevents the loader to put them in read-only region.
This patch makes them "const".
* disassembler/ARM64/A64DOpcode.cpp:
* disassembler/udis86/ud_itab.py:
(UdItabGenerator.genOpcodeTablesLookupIndex):
(UdItabGenerator.genInsnTable):
(UdItabGenerator.genMnemonicsList):
(genItabH):
* disassembler/udis86/udis86_decode.h:
* disassembler/udis86/udis86_syn.c:
* disassembler/udis86/udis86_syn.h:
* disassembler/udis86/udis86_types.h:
2019-01-30 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, update the builtin test results
https://bugs.webkit.org/show_bug.cgi?id=194015
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
* Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
2019-01-30 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Make global static variables "const" as much as possible
https://bugs.webkit.org/show_bug.cgi?id=194015
Reviewed by Mark Lam.
Some of global static variables are not "const". For example, `static const char* name = ...`
is not constant variable. We should make it `static const char* const name = ...`.
* Scripts/wkbuiltins/builtins_generate_combined_header.py:
(generate_externs_for_object):
* Scripts/wkbuiltins/builtins_generate_separate_header.py:
(generate_externs_for_object):
* Scripts/wkbuiltins/builtins_generator.py:
(BuiltinsGenerator.generate_embedded_code_string_section_for_data):
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::additionBlindedConstant):
* b3/air/AirFormTable.h:
* b3/air/opcode_generator.rb:
* runtime/JSObject.cpp:
(JSC::JSObject::visitButterfly):
* tools/CodeProfile.cpp:
* tools/CodeProfile.h:
2019-01-29 Keith Miller <keith_miller@apple.com>
Remove default constructor from LLIntPrototypeLoadAdaptiveStructureWatchpoint
https://bugs.webkit.org/show_bug.cgi?id=194000
<rdar://problem/47642894>
Reviewed by Mark Lam.
default constructor is unused and
LLIntPrototypeLoadAdaptiveStructureWatchpoint has a reference
data member which causes sadness.
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
2019-01-29 Ross Kirsling <ross.kirsling@sony.com>
Remove FIXME for Annex B.3.5's "for-of var" subcase.
Rubber-stamped by Yusuke Suzuki.
This subcase is removed from the spec in https://github.com/tc39/ecma262/pull/1393.
* parser/Parser.h:
(JSC::Parser::declareHoistedVariable):
2019-01-29 Mark Lam <mark.lam@apple.com>
Remove unneeded CPU(BIG_ENDIAN) handling in LLInt after new bytecode format.
https://bugs.webkit.org/show_bug.cgi?id=132333
Reviewed by Yusuke Suzuki.
* bytecode/InstructionStream.h:
(JSC::InstructionStreamWriter::write):
- The 32-bit write() function need not invert the order of the bytes written to
the bytecode stream for CPU(BUG_ENDIAN) because the incoming uint32_t value to
be written is already in big endian order for CPU(BUG_ENDIAN) platforms.
* llint/LLIntOfflineAsmConfig.h:
- OFFLINE_ASM_BIG_ENDIAN is no longer needed nor used after the new bytecode format.
2019-01-29 Mark Lam <mark.lam@apple.com>
ValueRecovery::recover() should purify NaN values it recovers.
https://bugs.webkit.org/show_bug.cgi?id=193978
<rdar://problem/47625488>
Reviewed by Saam Barati.
According to DFG::OSRExit::executeOSRExit() and DFG::OSRExit::compileExit(),
recovered DoubleDisplacedInJSStack values need to be purified.
ValueRecovery::recover() should do the same.
* bytecode/ValueRecovery.cpp:
(JSC::ValueRecovery::recover const):
2019-01-29 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] FTL should handle LocalAllocator*
https://bugs.webkit.org/show_bug.cgi?id=193980
Reviewed by Saam Barati.
At some point, Allocator holds LocalAllocator* instead of 32bit integer. In FTL allocation path, we fail to use this constant LocalAllocator*
because the FTL still use the incoming value as 32bit integer there.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::allocateHeapCell):
2019-01-29 Keith Rollin <krollin@apple.com>
Add .xcfilelists to Run Script build phases
https://bugs.webkit.org/show_bug.cgi?id=193792
<rdar://problem/47201785>
Reviewed by Alex Christensen.
As part of supporting XCBuild, update the necessary Run Script build
phases in their Xcode projects to refer to their associated
.xcfilelist files.
Note that the addition of these files bumps the Xcode project version
number to something that's Xcode 10 compatible. This change means that
older versions of the Xcode IDE can't read these projects. Nor can it
fully load workspaces that refer to these projects (the updated
projects are shown as non-expandable placeholders). `xcodebuild` can
still build these projects; it's just that the IDE can't open them.
* JavaScriptCore.xcodeproj/project.pbxproj:
2019-01-29 Dominik Infuehr <dinfuehr@igalia.com>
[ARM] Check for negative zero instead of just zero
https://bugs.webkit.org/show_bug.cgi?id=193689
Reviewed by Mark Lam.
ARM now performs a negative zero check in branchConvertDoubleToInt32 instead
of just bailing out for zero.
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::branchConvertDoubleToInt32):
2019-01-28 Devin Rousso <drousso@apple.com>
Web Inspector: provide a way to edit page WebRTC settings on a remote target
https://bugs.webkit.org/show_bug.cgi?id=193863
<rdar://problem/47572764>
Reviewed by Joseph Pecoraro.
* inspector/protocol/Page.json:
Add more values to the `Setting` enum type:
- `ICECandidateFilteringEnabled`
- `MediaCaptureRequiresSecureConnection`
- `MockCaptureDevicesEnabled`
2019-01-28 Ross Kirsling <ross.kirsling@sony.com>
Remove unnecessary `using namespace WTF`s (or at least restrict their scope).
https://bugs.webkit.org/show_bug.cgi?id=193941
Reviewed by Alex Christensen.
* API/JSWeakObjectMapRefPrivate.cpp:
* bytecompiler/NodesCodegen.cpp:
* heap/MachineStackMarker.cpp:
* jit/ExecutableAllocator.cpp:
* jsc.cpp:
* parser/Nodes.cpp:
* runtime/DateConstructor.cpp:
* runtime/DateConversion.cpp:
* runtime/DateInstance.cpp:
* runtime/DatePrototype.cpp:
* runtime/InitializeThreading.cpp:
* runtime/IteratorOperations.cpp:
* runtime/JSDateMath.cpp:
* runtime/JSGlobalObjectFunctions.cpp:
* runtime/StringPrototype.cpp:
* runtime/VM.cpp:
* testRegExp.cpp:
* tools/JSDollarVM.cpp:
* yarr/YarrInterpreter.cpp:
* yarr/YarrJIT.cpp:
* yarr/YarrPattern.cpp:
* yarr/YarrUnicodeProperties.cpp:
2019-01-28 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Reduce size of memory used for ShadowChicken
https://bugs.webkit.org/show_bug.cgi?id=193546
Reviewed by Mark Lam.
This patch lazily instantiate ShadowChicken. We do not need this until we start logging ShadowChicken packets.
The removal of ShadowChicken saves 55KB memory.
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::create):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::ensureShadowChickenPacket):
* heap/Heap.cpp:
(JSC::Heap::stopThePeriphery):
(JSC::Heap::addCoreConstraints):
* jit/CCallHelpers.cpp:
(JSC::CCallHelpers::ensureShadowChickenPacket):
* jit/JITExceptions.cpp:
(JSC::genericUnwind):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_log_shadow_chicken_prologue):
(JSC::JIT::emit_op_log_shadow_chicken_tail):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_log_shadow_chicken_prologue):
(JSC::JIT::emit_op_log_shadow_chicken_tail):
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::setDebugger):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::setDebugger): Deleted.
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::ensureShadowChicken):
* runtime/VM.h:
(JSC::VM::shadowChicken):
* tools/JSDollarVM.cpp:
(JSC::functionShadowChickenFunctionsOnStack):
(JSC::changeDebuggerModeWhenIdle):
2019-01-28 Andy Estes <aestes@apple.com>
[watchOS] Enable Parental Controls content filtering
https://bugs.webkit.org/show_bug.cgi?id=193939
<rdar://problem/46641912>
Reviewed by Ryosuke Niwa.
* Configurations/FeatureDefines.xcconfig:
2019-01-28 Mark Lam <mark.lam@apple.com>
ToString node actually does GC.
https://bugs.webkit.org/show_bug.cgi?id=193920
<rdar://problem/46695900>
Reviewed by Yusuke Suzuki.
Other than for StringObjectUse and StringOrStringObjectUse, ToString and
CallStringConstructor can allocate new JSStrings, and hence, can GC.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
2019-01-28 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] RegExpConstructor should not have own IsoSubspace
https://bugs.webkit.org/show_bug.cgi?id=193801
Reviewed by Mark Lam.
This patch finally removes RegExpConstructor's cached data to JSGlobalObject and remove IsoSubspace for RegExpConstructor.
sizeof(RegExpConstructor) != sizeof(InternalFunction), so that we have 16KB memory just for RegExpConstructor. But cached
regexp matching data (e.g. `RegExp.$1`) is per-JSGlobalObject one, and we can move this data to JSGlobalObject and remove
it from RegExpConstructor members.
We introduce RegExpGlobalData, which holds the per-global RegExp matching data. And we perform `performMatch` etc. with
JSGlobalObject instead of RegExpConstructor. This change requires small changes in DFG / FTL's RecordRegExpCachedResult
node since its 1st argument is changed from RegExpConstructor to JSGlobalObject.
We also move emptyRegExp from RegExpPrototype to VM's RegExpCache because it is more natural place to put it.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* dfg/DFGOperations.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileRecordRegExpCachedResult):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* ftl/FTLAbstractHeapRepository.cpp:
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileRecordRegExpCachedResult):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::regExpGlobalData):
(JSC::JSGlobalObject::regExpGlobalDataOffset):
(JSC::JSGlobalObject::regExpConstructor const): Deleted.
* runtime/RegExpCache.cpp:
(JSC::RegExpCache::initialize):
* runtime/RegExpCache.h:
(JSC::RegExpCache::emptyRegExp const):
* runtime/RegExpCachedResult.cpp:
(JSC::RegExpCachedResult::visitAggregate):
(JSC::RegExpCachedResult::visitChildren): Deleted.
* runtime/RegExpCachedResult.h:
(JSC::RegExpCachedResult::RegExpCachedResult): Deleted.
* runtime/RegExpConstructor.cpp:
(JSC::RegExpConstructor::RegExpConstructor):
(JSC::regExpConstructorDollar):
(JSC::regExpConstructorInput):
(JSC::regExpConstructorMultiline):
(JSC::regExpConstructorLastMatch):
(JSC::regExpConstructorLastParen):
(JSC::regExpConstructorLeftContext):
(JSC::regExpConstructorRightContext):
(JSC::setRegExpConstructorInput):
(JSC::setRegExpConstructorMultiline):
(JSC::RegExpConstructor::destroy): Deleted.
(JSC::RegExpConstructor::visitChildren): Deleted.
(JSC::RegExpConstructor::getBackref): Deleted.
(JSC::RegExpConstructor::getLastParen): Deleted.
(JSC::RegExpConstructor::getLeftContext): Deleted.
(JSC::RegExpConstructor::getRightContext): Deleted.
* runtime/RegExpConstructor.h:
(JSC::RegExpConstructor::performMatch): Deleted.
(JSC::RegExpConstructor::recordMatch): Deleted.
* runtime/RegExpGlobalData.cpp: Added.
(JSC::RegExpGlobalData::visitAggregate):
(JSC::RegExpGlobalData::getBackref):
(JSC::RegExpGlobalData::getLastParen):
(JSC::RegExpGlobalData::getLeftContext):
(JSC::RegExpGlobalData::getRightContext):
* runtime/RegExpGlobalData.h: Added.
(JSC::RegExpGlobalData::cachedResult):
(JSC::RegExpGlobalData::setMultiline):
(JSC::RegExpGlobalData::multiline const):
(JSC::RegExpGlobalData::input):
(JSC::RegExpGlobalData::offsetOfCachedResult):
* runtime/RegExpGlobalDataInlines.h: Added.
(JSC::RegExpGlobalData::setInput):
(JSC::RegExpGlobalData::performMatch):
(JSC::RegExpGlobalData::recordMatch):
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::matchGlobal):
* runtime/RegExpObjectInlines.h:
(JSC::RegExpObject::execInline):
(JSC::RegExpObject::matchInline):
(JSC::collectMatches):
* runtime/RegExpPrototype.cpp:
(JSC::RegExpPrototype::finishCreation):
(JSC::regExpProtoFuncSearchFast):
(JSC::RegExpPrototype::visitChildren): Deleted.
* runtime/RegExpPrototype.h:
* runtime/StringPrototype.cpp:
(JSC::removeUsingRegExpSearch):
(JSC::replaceUsingRegExpSearch):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2018-12-15 Darin Adler <darin@apple.com>
Replace many uses of String::format with more type-safe alternatives
https://bugs.webkit.org/show_bug.cgi?id=192742
Reviewed by Mark Lam.
* inspector/InjectedScriptBase.cpp:
(Inspector::InjectedScriptBase::makeCall): Use makeString.
(Inspector::InjectedScriptBase::makeAsyncCall): Ditto.
* inspector/InspectorBackendDispatcher.cpp:
(Inspector::BackendDispatcher::getPropertyValue): Ditto.
* inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::enable): Ditto.
* jsc.cpp:
(FunctionJSCStackFunctor::operator() const): Ditto.
* runtime/CodeCache.cpp:
(JSC::writeCodeBlock): Use makeString's numeric capabilities instead of
using String::number.
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::initializeDateTimeFormat): Use string concatenation.
* runtime/IntlObject.cpp:
(JSC::canonicalizeLocaleList): Ditto.
2019-01-27 Chris Fleizach <cfleizach@apple.com>
AX: Introduce a static accessibility tree
https://bugs.webkit.org/show_bug.cgi?id=193348
<rdar://problem/47203295>
Reviewed by Ryosuke Niwa.
* Configurations/FeatureDefines.xcconfig:
2019-01-26 Devin Rousso <drousso@apple.com>
Web Inspector: provide a way to edit the user agent of a remote target
https://bugs.webkit.org/show_bug.cgi?id=193862
<rdar://problem/47359292>
Reviewed by Joseph Pecoraro.
* inspector/protocol/Page.json:
Add `overrideUserAgent` command.
2019-01-25 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] NativeErrorConstructor should not have own IsoSubspace
https://bugs.webkit.org/show_bug.cgi?id=193713
Reviewed by Saam Barati.
This removes an additional member in NativeErrorConstructor, and make sizeof(NativeErrorConstructor) == sizeof(InternalFunction).
We also make error constructors lazily allocated by using LazyClassStructure. Since error structures are not accessed from DFG / FTL
threads, this is OK. While TypeError constructor is eagerly allocated because it is touched from our builtin JS as @TypeError, we should
offer some function instead of exposing TypeError constructor in the future, and remove this @TypeError reference. This change removes
IsoSubspace for NativeErrorConstructor in VM. We also remove @Error and @RangeError references for builtins since they are no longer
referenced.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* builtins/BuiltinNames.h:
* interpreter/Interpreter.h:
* runtime/Error.cpp:
(JSC::createEvalError):
(JSC::createRangeError):
(JSC::createReferenceError):
(JSC::createSyntaxError):
(JSC::createTypeError):
(JSC::createURIError):
(WTF::printInternal): Deleted.
* runtime/Error.h:
* runtime/ErrorPrototype.cpp:
(JSC::ErrorPrototype::create):
(JSC::ErrorPrototype::finishCreation):
* runtime/ErrorPrototype.h:
(JSC::ErrorPrototype::create): Deleted.
* runtime/ErrorType.cpp: Added.
(JSC::errorTypeName):
(WTF::printInternal):
* runtime/ErrorType.h: Added.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::initializeErrorConstructor):
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::internalPromiseConstructor const):
(JSC::JSGlobalObject::errorStructure const):
(JSC::JSGlobalObject::evalErrorConstructor const): Deleted.
(JSC::JSGlobalObject::rangeErrorConstructor const): Deleted.
(JSC::JSGlobalObject::referenceErrorConstructor const): Deleted.
(JSC::JSGlobalObject::syntaxErrorConstructor const): Deleted.
(JSC::JSGlobalObject::typeErrorConstructor const): Deleted.
(JSC::JSGlobalObject::URIErrorConstructor const): Deleted.
* runtime/NativeErrorConstructor.cpp:
(JSC::NativeErrorConstructor<errorType>::NativeErrorConstructor):
(JSC::NativeErrorConstructorBase::finishCreation):
(JSC::NativeErrorConstructor<errorType>::constructNativeErrorConstructor):
(JSC::NativeErrorConstructor<errorType>::callNativeErrorConstructor):
(JSC::NativeErrorConstructor::NativeErrorConstructor): Deleted.
(JSC::NativeErrorConstructor::finishCreation): Deleted.
(JSC::NativeErrorConstructor::visitChildren): Deleted.
(JSC::Interpreter::constructWithNativeErrorConstructor): Deleted.
(JSC::Interpreter::callNativeErrorConstructor): Deleted.
* runtime/NativeErrorConstructor.h:
(JSC::NativeErrorConstructorBase::createStructure):
(JSC::NativeErrorConstructorBase::NativeErrorConstructorBase):
* runtime/NativeErrorPrototype.cpp:
(JSC::NativeErrorPrototype::finishCreation): Deleted.
* runtime/NativeErrorPrototype.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
* wasm/js/WasmToJS.cpp:
(JSC::Wasm::handleBadI64Use):
2019-01-25 Devin Rousso <drousso@apple.com>
Web Inspector: provide a way to edit page settings on a remote target
https://bugs.webkit.org/show_bug.cgi?id=193813
<rdar://problem/47359510>
Reviewed by Joseph Pecoraro.
* inspector/protocol/Page.json:
Add `overrideSetting` command with supporting `Setting` enum type.
2019-01-25 Keith Rollin <krollin@apple.com>
Update Xcode projects with "Check .xcfilelists" build phase
https://bugs.webkit.org/show_bug.cgi?id=193790
<rdar://problem/47201374>
Reviewed by Alex Christensen.
Support for XCBuild includes specifying inputs and outputs to various
Run Script build phases. These inputs and outputs are specified as
.xcfilelist files. Once created, these .xcfilelist files need to be
kept up-to-date. In order to check that they are up-to-date or not,
add an Xcode build step that invokes an external script that performs
the checking. If the .xcfilelists are found to be out-of-date, update
them, halt the build, and instruct the developer to restart the build
with up-to-date files.
At this time, the checking and regenerating is performed only if the
WK_ENABLE_CHECK_XCFILELISTS environment variable is set to 1. People
who want to use this facility can set this variable and test out the
checking/regenerating. Once it seems like there are no egregious
issues that upset a developer's workflow, we'll unconditionally enable
this facility.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Scripts/check-xcfilelists.sh: Added.
2019-01-25 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Exclude Debugger Threads from CPU Usage values in Web Inspector
https://bugs.webkit.org/show_bug.cgi?id=193796
<rdar://problem/47532910>
Reviewed by Devin Rousso.
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::machThread):
* runtime/SamplingProfiler.h:
Expose the mach_port_t of the SamplingProfiler thread
so it can be tested against later.
2019-01-25 Alex Christensen <achristensen@webkit.org>
Fix Windows build after r240511
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
2019-01-25 Keith Rollin <krollin@apple.com>
Update Xcode projects with "Apply Configuration to XCFileLists" build target
https://bugs.webkit.org/show_bug.cgi?id=193781
<rdar://problem/47201153>
Reviewed by Alex Christensen.
Part of generating the .xcfilelists used as part of adopting XCBuild
includes running `make DerivedSources.make` from a standalone script.
It’s important for this invocation to have the same environment as
when the actual build invokes `make DerivedSources.make`. If the
environments are different, then the two invocations will provide
different results. In order to get the same environment in the
standalone script, have the script launch xcodebuild targeting the
"Apply Configuration to XCFileLists" build target, which will then
re-invoke our standalone script. The script is now running again, this
time in an environment with all workspace, project, target, xcconfig
and other environment variables established.
The "Apply Configuration to XCFileLists" build target accomplishes
this task via a small embedded shell script that consists only of:
eval "${WK_SUBLAUNCH_SCRIPT_PARAMETERS[@]}"
The process that invokes "Apply Configuration to XCFileLists" first
sets WK_SUBLAUNCH_SCRIPT_PARAMETERS to an array of commands to be
evaluated and exports it into the shell environment. When xcodebuild
is invoked, it inherits the value of this variable and can `eval` the
contents of that variable. Our external standalone script can then set
WK_SUBLAUNCH_SCRIPT_PARAMETERS to the path to itself, along with a set
of command-line parameters needed to restart itself in the appropriate
state.
* JavaScriptCore.xcodeproj/project.pbxproj:
2019-01-25 Tadeu Zagallo <tzagallo@apple.com>
Add API to generate and consume cached bytecode
https://bugs.webkit.org/show_bug.cgi?id=193401
<rdar://problem/47514099>
Reviewed by Keith Miller.
Add the `generateBytecode` and `generateModuleBytecode` functions to
generate serialized bytecode for a given `SourceCode`. These functions
will eagerly generate code for all the nested functions.
Additionally, update the API methods in JSScript to generate and use the
bytecode when the bytecodeCache path is provided.
* API/JSAPIGlobalObject.mm:
(JSC::JSAPIGlobalObject::moduleLoaderFetch):
* API/JSContext.mm:
(-[JSContext wrapperMap]):
* API/JSContextInternal.h:
* API/JSScript.mm:
(+[JSScript scriptWithSource:inVirtualMachine:]):
(+[JSScript scriptFromASCIIFile:inVirtualMachine:withCodeSigning:andBytecodeCache:]):
(-[JSScript dealloc]):
(-[JSScript readCache]):
(-[JSScript writeCache]):
(-[JSScript hash]):
(-[JSScript source]):
(-[JSScript cachedBytecode]):
(-[JSScript jsSourceCode:]):
* API/JSScriptInternal.h:
* API/JSScriptSourceProvider.h: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
(JSScriptSourceProvider::create):
(JSScriptSourceProvider::JSScriptSourceProvider):
* API/JSScriptSourceProvider.mm: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
(JSScriptSourceProvider::hash const):
(JSScriptSourceProvider::source const):
(JSScriptSourceProvider::cachedBytecode const):
* API/JSVirtualMachine.mm:
(-[JSVirtualMachine vm]):
* API/JSVirtualMachineInternal.h:
* API/tests/testapi.mm:
(testBytecodeCache):
(-[JSContextFileLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
(testObjectiveCAPI):
* JavaScriptCore.xcodeproj/project.pbxproj:
* SourcesCocoa.txt:
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
* bytecode/UnlinkedFunctionExecutable.h:
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::source const):
* parser/SourceProvider.h:
(JSC::CachedBytecode::CachedBytecode):
(JSC::CachedBytecode::operator=):
(JSC::CachedBytecode::data const):
(JSC::CachedBytecode::size const):
(JSC::CachedBytecode::owned const):
(JSC::CachedBytecode::~CachedBytecode):
(JSC::CachedBytecode::freeDataIfOwned):
(JSC::SourceProvider::cachedBytecode const):
* parser/UnlinkedSourceCode.h:
(JSC::UnlinkedSourceCode::provider const):
* runtime/CodeCache.cpp:
(JSC::generateUnlinkedCodeBlockForFunctions):
(JSC::writeCodeBlock):
(JSC::serializeBytecode):
* runtime/CodeCache.h:
(JSC::CodeCacheMap::fetchFromDiskImpl):
(JSC::CodeCacheMap::findCacheAndUpdateAge):
(JSC::generateUnlinkedCodeBlockImpl):
(JSC::generateUnlinkedCodeBlock):
* runtime/Completion.cpp:
(JSC::generateBytecode):
(JSC::generateModuleBytecode):
* runtime/Completion.h:
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
2019-01-25 Keith Rollin <krollin@apple.com>
Update WebKitAdditions.xcconfig with correct order of variable definitions
https://bugs.webkit.org/show_bug.cgi?id=193793
<rdar://problem/47532439>
Reviewed by Alex Christensen.
XCBuild changes the way xcconfig variables are evaluated. In short,
all config file assignments are now considered in part of the
evaluation. When using the new build system and an .xcconfig file
contains multiple assignments of the same build setting:
- Later assignments using $(inherited) will inherit from earlier
assignments in the xcconfig file.
- Later assignments not using $(inherited) will take precedence over
earlier assignments. An assignment to a more general setting will
mask an earlier assignment to a less general setting. For example,
an assignment without a condition ('FOO = bar') will completely mask
an earlier assignment with a condition ('FOO[sdk=macos*] = quux').
This affects some of our .xcconfig files, in that sometimes platform-
or sdk-specific definitions appear before the general definitions.
Under the new evaluations rules, the general definitions alway take
effect because they always overwrite the more-specific definitions. The
solution is to swap the order, so that the general definitions are
established first, and then conditionally overwritten by the
more-specific definitions.
* Configurations/Version.xcconfig:
2019-01-25 Keith Rollin <krollin@apple.com>
Update existing .xcfilelists
https://bugs.webkit.org/show_bug.cgi?id=193791
<rdar://problem/47201706>
Reviewed by Alex Christensen.
Many .xcfilelist files were added in r238824 in order to support
XCBuild. Update these with recent changes to the set of build files
and with the current generate-xcfilelist script.
* DerivedSources-input.xcfilelist:
* DerivedSources-output.xcfilelist:
* UnifiedSources-input.xcfilelist:
* UnifiedSources-output.xcfilelist:
2019-01-25 Jon Davis <jond@apple.com>
Update JavaScriptCore feature status entries.
https://bugs.webkit.org/show_bug.cgi?id=193797
Reviewed by Mark Lam.
Updated feature status for Async Iteration, and Object rest/spread.
* features.json:
2019-01-24 Keith Miller <keith_miller@apple.com>
Remove usage of internal macro from private header
https://bugs.webkit.org/show_bug.cgi?id=193809
Reviewed by Saam Barati.
Also, add a new file to include all of our API headers to make sure
they don't accidentally include C++ or internal values.
* API/JSScript.h:
* API/tests/testIncludes.m: Added.
* JavaScriptCore.xcodeproj/project.pbxproj:
2019-01-24 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] ErrorConstructor should not have own IsoSubspace
https://bugs.webkit.org/show_bug.cgi?id=193800
Reviewed by Saam Barati.
Similar to r240456, sizeof(ErrorConstructor) != sizeof(InternalFunction), and that is why we have
IsoSubspace errorConstructorSpace in VM. But it is allocated only one-per-JSGlobalObject, and it is
too costly to have IsoSubspace which allocates 16KB. Since stackTraceLimit information is per
JSGlobalObject information, we should have m_stackTraceLimit in JSGlobalObject instead and put
ErrorConstructor in InternalFunction's IsoSubspace. As r230813 (moving InternalFunction and subclasses
into IsoSubspaces) described,
"subclasses that are the same size as InternalFunction share its subspace. I did this because the subclasses
appear to just override methods, which are called dynamically via the structure or class of the object.
So, I don't see a type confusion risk if UAF is used to allocate one kind of InternalFunction over another."
Then, putting ErrorConstructor in InternalFunction IsoSubspace is fine since it meets the above condition.
This patch removes m_stackTraceLimit in ErrorConstructor, and drops IsoSubspace for errorConstructorSpace.
This reduces the memory usage.
* interpreter/Interpreter.h:
* runtime/Error.cpp:
(JSC::getStackTrace):
* runtime/ErrorConstructor.cpp:
(JSC::ErrorConstructor::ErrorConstructor):
(JSC::ErrorConstructor::finishCreation):
(JSC::constructErrorConstructor):
(JSC::callErrorConstructor):
(JSC::ErrorConstructor::put):
(JSC::ErrorConstructor::deleteProperty):
(JSC::Interpreter::constructWithErrorConstructor): Deleted.
(JSC::Interpreter::callErrorConstructor): Deleted.
* runtime/ErrorConstructor.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::JSGlobalObject):
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::stackTraceLimit const):
(JSC::JSGlobalObject::setStackTraceLimit):
(JSC::JSGlobalObject::errorConstructor const): Deleted.
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2019-01-24 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: CPU Usage Timeline
https://bugs.webkit.org/show_bug.cgi?id=193730
<rdar://problem/46797201>
Reviewed by Devin Rousso.
* CMakeLists.txt:
* DerivedSources-input.xcfilelist:
* DerivedSources.make:
New files.
* inspector/protocol/CPUProfiler.json: Added.
New domain that follows the pattern of Memory/ScriptProfiler.
* inspector/protocol/Timeline.json:
New enum to auto-start a CPU instrument in the backend.
2019-01-24 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] SharedArrayBufferConstructor and ArrayBufferConstructor should not have their own IsoSubspace
https://bugs.webkit.org/show_bug.cgi?id=193774
Reviewed by Mark Lam.
We put all the instances of InternalFunction and its subclasses in IsoSubspace to make safer from UAF.
But since IsoSubspace requires the memory layout of instances is the same, we created different IsoSubspace
for subclasses of InternalFunction if sizeof(subclass) != sizeof(InternalFunction). One example is
ArrayBufferConstructor and SharedArrayBufferConstructor. But it is too costly to allocate 16KB page just
for these two constructor instances. They are only two instances per JSGlobalObject.
This patch makes sizeof(ArrayBufferConstructor) == sizeof(InternalFunction) so that they can use IsoSubspace
of InternalFunction. We introduce JSGenericArrayBufferConstructor, and it takes ArrayBufferSharingMode as
its template parameter. We define JSArrayBufferConstructor as JSGenericArrayBufferConstructor<ArrayBufferSharingMode::Default>
and JSSharedArrayBufferConstructor as JSGenericArrayBufferConstructor<ArrayBufferSharingMode::Shared> so that
we do not need to hold ArrayBufferSharingMode in the field of the constructor. This change removes IsoSubspace
for ArrayBufferConstructors, and reduces the memory usage.
* runtime/JSArrayBufferConstructor.cpp:
(JSC::JSGenericArrayBufferConstructor<sharingMode>::JSGenericArrayBufferConstructor):
(JSC::JSGenericArrayBufferConstructor<sharingMode>::finishCreation):
(JSC::JSGenericArrayBufferConstructor<sharingMode>::constructArrayBuffer):
(JSC::JSGenericArrayBufferConstructor<sharingMode>::createStructure):
(JSC::JSGenericArrayBufferConstructor<sharingMode>::info):
(JSC::JSArrayBufferConstructor::JSArrayBufferConstructor): Deleted.
(JSC::JSArrayBufferConstructor::finishCreation): Deleted.
(JSC::JSArrayBufferConstructor::create): Deleted.
(JSC::JSArrayBufferConstructor::createStructure): Deleted.
(JSC::constructArrayBuffer): Deleted.
* runtime/JSArrayBufferConstructor.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObject.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2019-01-24 Yusuke Suzuki <ysuzuki@apple.com>
stress/const-semantics.js fails a dfg-eager / ftl-eager run with an ASAN release build.
https://bugs.webkit.org/show_bug.cgi?id=190693
Reviewed by Michael Saboff.
JITStubRoutine's fields are marked only when JITStubRoutine::m_mayBeExecuting is true.
This becomes true when we find the executable address in our conservative roots, which
means that we could be executing it right now. This means that object liveness in
JITStubRoutine depends on the information gathered in ConservativeRoots. However, our
constraints are separated, "Conservative Scan" and "JIT Stub Routines". They can even
be executed concurrently, so that "JIT Stub Routines" may miss to mark the actually
executing JITStubRoutine because "Conservative Scan" finds it later.
When finalizing the GC, we delete the dead JITStubRoutines. At that time, since
"Conservative Scan" already finishes, we do not delete some JITStubRoutines which do not
mark the depending objects. Then, in the next cycle, we find JITStubRoutines still live,
attempt to mark the depending objects, and encounter the dead objects which are collected
in the previous cycles.
This patch removes "JIT Stub Routines" and merge it to "Conservative Scan". Since
"Conservative Scan" and "JIT Stub Routines" need to be executed only when the execution
happens (ensured by GreyedByExecution and CollectionPhase check), this change is OK for
GC stop time.
* heap/ConservativeRoots.h:
(JSC::ConservativeRoots::roots const):
(JSC::ConservativeRoots::roots): Deleted.
* heap/Heap.cpp:
(JSC::Heap::addCoreConstraints):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::append):
* heap/SlotVisitor.h:
* jit/GCAwareJITStubRoutine.cpp:
(JSC::GCAwareJITStubRoutine::GCAwareJITStubRoutine):
* jit/GCAwareJITStubRoutine.h:
2019-01-24 Saam Barati <sbarati@apple.com>
Update ARM64EHash
https://bugs.webkit.org/show_bug.cgi?id=193776
<rdar://problem/47526457>
Reviewed by Mark Lam.
See radar for details.
* assembler/AssemblerBuffer.h:
(JSC::ARM64EHash::update):
(JSC::ARM64EHash::finalHash const):
2019-01-24 Saam Barati <sbarati@apple.com>
Object Allocation Sinking phase can move a node that walks the stack into a place where the InlineCallFrame is no longer valid
https://bugs.webkit.org/show_bug.cgi?id=193751
<rdar://problem/47280215>
Reviewed by Michael Saboff.
The Object Allocation Sinking phase may move allocations around inside
of the program. However, it was not ensuring that it's still possible
to walk the stack at the point in the program that it moved the allocation to.
Certain InlineCallFrames rely on data in the stack when taking a stack trace.
All allocation sites can do a stack walk (we do a stack walk when we GC).
Conservatively, this patch says we're ok to move this allocation if we are
moving within the same InlineCallFrame. We could be more precise and do an
analysis of stack writes. However, this scenario is so rare that we just
take the conservative-and-straight-forward approach of checking that the place
we're moving to is the same InlineCallFrame as the allocation site.
In general, this issue arises anytime we do any kind of code motion.
Interestingly, LICM gets this right. It gets it right because the only
InlineCallFrames we can't move out of are the InlineCallFrames that
have metadata stored on the stack (callee for closure calls and argument
count for varargs calls). LICM doesn't have this issue because it relies
on Clobberize for doing its effects analysis. In clobberize, we model every
node within an InlineCallFrame that meets the above criteria as reading
from those stack fields. Consequently, LICM won't hoist any node in that
InlineCallFrame past the beginning of the InlineCallFrame since the IR
we generate to set up such an InlineCallFrame contains writes to that
stack location.
* dfg/DFGObjectAllocationSinkingPhase.cpp:
2019-01-24 Guillaume Emont <guijemont@igalia.com>
[JSC] Reenable baseline JIT on mips
https://bugs.webkit.org/show_bug.cgi?id=192983
Reviewed by Mark Lam.
Use $s0 as metadata register and make sure it's properly saved and
restored.
* jit/GPRInfo.h:
* jit/RegisterSet.cpp:
(JSC::RegisterSet::vmCalleeSaveRegisters):
(JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
* llint/LowLevelInterpreter.asm:
* offlineasm/mips.rb:
2019-01-24 Carlos Garcia Campos <cgarcia@igalia.com>
[GLIB] Expose JavaScriptCore options in GLib public API
https://bugs.webkit.org/show_bug.cgi?id=188742
Reviewed by Michael Catanzaro.
Add new API to set, get and iterate JSC options.
* API/glib/JSCOptions.cpp: Added.
(valueFromGValue):
(valueToGValue):
(jscOptionsSetValue):
(jscOptionsGetValue):
(jsc_options_set_boolean):
(jsc_options_get_boolean):
(jsc_options_set_int):
(jsc_options_get_int):
(jsc_options_set_uint):
(jsc_options_get_uint):
(jsc_options_set_size):
(jsc_options_get_size):
(jsc_options_set_double):
(jsc_options_get_double):
(jsc_options_set_string):
(jsc_options_get_string):
(jsc_options_set_range_string):
(jsc_options_get_range_string):
(jscOptionsType):
(jsc_options_foreach):
(setOptionEntry):
(jsc_options_get_option_group):
* API/glib/JSCOptions.h: Added.
* API/glib/docs/jsc-glib-4.0-sections.txt:
* API/glib/docs/jsc-glib-docs.sgml:
* API/glib/jsc.h:
* GLib.cmake:
2019-01-23 Mark Lam <mark.lam@apple.com>
ARM64E should not ENABLE(SEPARATED_WX_HEAP).
https://bugs.webkit.org/show_bug.cgi?id=193744
<rdar://problem/46262952>
Reviewed by Saam Barati.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::copyCompactAndLinkCode):
2019-01-23 Yusuke Suzuki <ysuzuki@apple.com>
[DFG] AvailabilityMap::pruneByLiveness should make non-live operands Availability::unavailable instead of Availability()
https://bugs.webkit.org/show_bug.cgi?id=193711
<rdar://problem/47250262>
Reviewed by Saam Barati.
When pruning OSR Availability based on bytecode liveness, we accidentally clear the Availability (making it DeadFlush) instead of
making it Availability::unavailable() (Making it ConflictingFlush). In OSRAvailabilityAnalysisPhase, we perform forward analysis.
We first clear all the availability of basic blocks DeadFlush, which is an empty set. And then, we set operands in the root block
ConflictingFlush. In this forward analysis, DeadFlush is BOTTOM, and ConflictingFlush is TOP. Then, we propagate information by
merging availability until we reach to the fixed-point. As an optimization, we perform "pruning" of the availability in the head
of the basic blocks. We remove availabilities of operands which are not live in the bytecode liveness at the head of the basic block.
The problem is, when removing availabilities, we set DeadFlush for them instead of ConflictingFlush. Basically, it means that we set
BOTTOM (an empty set) instead of TOP. Let's consider the following simple example. We have 6 basic blocks, and they are connected
as follows.
BB0 -> BB1 -> BB2 -> BB4
| \ ^
v > BB3 /
BB5
And consider about loc1 in FTL, which is required to be recovered in BB4's OSR exit.
BB0 does nothing
head: loc1 is dead
tail: loc1 is dead
BB1 has MovHint @1, loc1
head: loc1 is dead
tail: loc1 is live
BB2 does nothing
head: loc1 is live
tail: loc1 is live
BB3 has PutStack @1, loc1
head: loc1 is live
tail: loc1 is live
BB4 has OSR exit using loc1
head: loc1 is live
tail: loc1 is live (in bytecode)
BB5 does nothing
head: loc1 is dead
tail: loc1 is dead
In our OSR Availability analysis, we always prune loc1 result in BB1's head since its head says "loc1 is dead".
But at that time, we clear the availability for loc1, which makes it DeadFlush, instead of making it ConflictingFlush.
So, the flush format of loc1 in each tail of BB is like this.
BB0
ConflictingFlush (because all the local operands are initialized with ConflictingFlush)
BB1
DeadFlush+@1 (pruning clears it)
BB2
DeadFlush+@1 (since it is propagated from BB1)
BB3
FlushedJSValue+@1 with loc1 (since it has PutStack)
BB4
FlushedJSValue+@1 with loc1 (since MERGE(DeadFlush, FlushedJSValue) = FlushedJSValue)
BB5
DeadFlush (pruning clears it)
Then, if we go the path BB0->BB1->BB2->BB4, we read the value from the stack while it is not flushed.
The correct fix is making availability "unavailable" when pruning based on bytecode liveness.
* dfg/DFGAvailabilityMap.cpp:
(JSC::DFG::AvailabilityMap::pruneByLiveness): When pruning availability, we first set all the operands Availability::unavailable(),
and copy the calculated value from the current availability map.
* dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
(JSC::DFG::OSRAvailabilityAnalysisPhase::run): Add logging things for debugging.
2019-01-23 David Kilzer <ddkilzer@apple.com>
[JSC] Duplicate global variables: JSC::opcodeLengths
<https://webkit.org/b/193714>
<rdar://problem/47340200>
Reviewed by Mark Lam.
* bytecode/Opcode.cpp:
(JSC::opcodeLengths): Move array implementation here and mark
const.
* bytecode/Opcode.h:
(JSC::opcodeLengths): Change to extern declaration.
2019-01-23 Carlos Garcia Campos <cgarcia@igalia.com>
[GLIB] Remote Inspector: no data displayed
https://bugs.webkit.org/show_bug.cgi?id=193569
Reviewed by Michael Catanzaro.
Release the remote inspector mutex before using RemoteConnectionToTarget in RemoteInspector::setup() to avoid a
deadlock.
* inspector/remote/glib/RemoteInspectorGlib.cpp:
(Inspector::RemoteInspector::receivedSetupMessage):
(Inspector::RemoteInspector::setup):
2019-01-22 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, fix initial global lexical binding epoch
https://bugs.webkit.org/show_bug.cgi?id=193603
<rdar://problem/47380869>
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
2019-01-22 Yusuke Suzuki <ysuzuki@apple.com>
REGRESSION(r239612) Crash at runtime due to broken DFG assumption
https://bugs.webkit.org/show_bug.cgi?id=193709
<rdar://problem/47363838>
Unreviewed, rollout to watch the tests.
* JavaScriptCore.xcodeproj/project.pbxproj:
* 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):
(JSC::DFG::FixupPhase::fixupObjectToString): Deleted.
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileObjectToString): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileToStringOrCallStringConstructorOrStringValueOf):
(JSC::FTL::DFG::LowerDFGToB3::compileObjectToString): Deleted.
* runtime/Intrinsic.cpp:
(JSC::intrinsicName):
* runtime/Intrinsic.h:
* runtime/ObjectPrototype.cpp:
(JSC::ObjectPrototype::finishCreation):
(JSC::objectProtoFuncToString):
* runtime/ObjectPrototype.h:
* runtime/ObjectPrototypeInlines.h: Removed.
* runtime/StructureRareData.h:
2019-01-22 Devin Rousso <drousso@apple.com>
Web Inspector: expose Audit and Recording versions to the frontend
https://bugs.webkit.org/show_bug.cgi?id=193262
<rdar://problem/47130684>
Reviewed by Joseph Pecoraro.
* inspector/protocol/Audit.json:
* inspector/protocol/Recording.json:
Add `version` values.
* inspector/scripts/codegen/models.py:
(Protocol.parse_domain):
(Domain.__init__):
(Domain.version): Added.
(Domains):
* inspector/scripts/codegen/generator.py:
(Generator.version_for_domain): Added.
* inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
(CppProtocolTypesHeaderGenerator.generate_output):
(CppProtocolTypesHeaderGenerator._generate_versions): Added.
* inspector/scripts/codegen/generate_js_backend_commands.py:
(JSBackendCommandsGenerator.should_generate_domain):
(JSBackendCommandsGenerator.generate_domain):
* inspector/scripts/tests/generic/version.json: Added.
* inspector/scripts/tests/generic/expected/version.json-result: Added.
* inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/generic/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/generic/expected/domain-availability.json-result:
* inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/generic/expected/enum-values.json-result:
* inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/generic/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
* inspector/scripts/tests/generic/expected/type-with-open-parameters.json-result:
* inspector/scripts/tests/ios/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result:
2019-01-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Intl constructors should fit in sizeof(InternalFunction)
https://bugs.webkit.org/show_bug.cgi?id=193661
Reviewed by Mark Lam.
Previously all the Intl constructors have their own subspace. This is because these constructors have different size from InternalFunction.
But it is too costly approach in terms of the memory usage since these constructors are only one per JSGlobalObject. This patch attempts to
reduce the memory size consumed by these Intl objects by holding instance structures in IntlObject instead of in each Intl constructors.
So that we can make sizeof(Intl constructors) == sizeof(InternalFunction) and drop costly subspaces. Since this patch drops subspaces in VM,
it also significantly reduces the sizeof(VM), from 76696 to 74680.
This patch also includes the preparation for making Intl properties lazy. But currently it is not possible since @Collator reference exists
in builtin code.
* CMakeLists.txt:
* DerivedSources.make:
* runtime/IntlCollatorConstructor.cpp:
(JSC::IntlCollatorConstructor::create):
(JSC::IntlCollatorConstructor::finishCreation):
(JSC::constructIntlCollator):
(JSC::callIntlCollator):
(JSC::IntlCollatorConstructor::visitChildren): Deleted.
* runtime/IntlCollatorConstructor.h:
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::IntlDateTimeFormatConstructor::create):
(JSC::IntlDateTimeFormatConstructor::finishCreation):
(JSC::constructIntlDateTimeFormat):
(JSC::callIntlDateTimeFormat):
(JSC::IntlDateTimeFormatConstructor::visitChildren): Deleted.
* runtime/IntlDateTimeFormatConstructor.h:
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::IntlNumberFormatConstructor::create):
(JSC::IntlNumberFormatConstructor::finishCreation):
(JSC::constructIntlNumberFormat):
(JSC::callIntlNumberFormat):
(JSC::IntlNumberFormatConstructor::visitChildren): Deleted.
* runtime/IntlNumberFormatConstructor.h:
* runtime/IntlObject.cpp:
(JSC::createCollatorConstructor):
(JSC::createNumberFormatConstructor):
(JSC::createDateTimeFormatConstructor):
(JSC::createPluralRulesConstructor):
(JSC::IntlObject::create):
(JSC::IntlObject::finishCreation):
(JSC::IntlObject::visitChildren):
* runtime/IntlObject.h:
* runtime/IntlPluralRulesConstructor.cpp:
(JSC::IntlPluralRulesConstructor::create):
(JSC::IntlPluralRulesConstructor::finishCreation):
(JSC::constructIntlPluralRules):
(JSC::IntlPluralRulesConstructor::visitChildren): Deleted.
* runtime/IntlPluralRulesConstructor.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::intlObject const):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2019-01-22 Saam Barati <sbarati@apple.com>
Unreviewed. Rollout r240223. It regressed JetStream2 by 1%.
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
2019-01-22 Tadeu Zagallo <tzagallo@apple.com>
Unreviewed, restore bytecode cache-related JSC options deleted in r240254
https://bugs.webkit.org/show_bug.cgi?id=192782
The JSC options were committed as part of r240210, which got rolled out in
r240224. However, the options got re-landed in r240248 and then deleted
again in 240254 (immediately before the caching code code landed in 240255)
* runtime/Options.h:
2019-01-22 Tadeu Zagallo <tzagallo@apple.com>
Cache bytecode to disk
https://bugs.webkit.org/show_bug.cgi?id=192782
<rdar://problem/46084932>
Reviewed by Keith Miller.
Add the logic to serialize and deserialize the new JSC bytecode. For now,
the cache is only used for tests.
Each class that can be serialized has a counterpart in CachedTypes, which
handles the decoding and encoding. When decoding, the cached objects are
mmap'd from disk, but only used for creating instances of the respective
in-memory version of each object. Ideally, the mmap'd objects should be
used at runtime in the future.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* builtins/BuiltinNames.cpp:
(JSC::BuiltinNames::BuiltinNames):
* builtins/BuiltinNames.h:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::setConstantIdentifierSetRegisters):
* bytecode/CodeBlock.h:
* bytecode/HandlerInfo.h:
(JSC::UnlinkedHandlerInfo::UnlinkedHandlerInfo):
* bytecode/InstructionStream.h:
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::addSetConstant):
(JSC::UnlinkedCodeBlock::constantIdentifierSets):
* bytecode/UnlinkedEvalCodeBlock.h:
* bytecode/UnlinkedFunctionCodeBlock.h:
* bytecode/UnlinkedFunctionExecutable.h:
* bytecode/UnlinkedGlobalCodeBlock.h:
(JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock):
* bytecode/UnlinkedMetadataTable.h:
* bytecode/UnlinkedModuleProgramCodeBlock.h:
* bytecode/UnlinkedProgramCodeBlock.h:
* interpreter/Interpreter.cpp:
* jsc.cpp:
(functionQuit):
(runJSC):
* parser/SourceCode.h:
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::operator!= const):
* parser/UnlinkedSourceCode.h:
* parser/VariableEnvironment.h:
* runtime/CachedTypes.cpp: Added.
(JSC::Encoder::Allocation::buffer const):
(JSC::Encoder::Allocation::offset const):
(JSC::Encoder::Allocation::Allocation):
(JSC::Encoder::Encoder):
(JSC::Encoder::vm):
(JSC::Encoder::malloc):
(JSC::Encoder::offsetOf):
(JSC::Encoder::cachePtr):
(JSC::Encoder::offsetForPtr):
(JSC::Encoder::release):
(JSC::Encoder::Page::Page):
(JSC::Encoder::Page::malloc):
(JSC::Encoder::Page::buffer const):
(JSC::Encoder::Page::size const):
(JSC::Encoder::Page::getOffset const):
(JSC::Encoder::allocateNewPage):
(JSC::Decoder::Decoder):
(JSC::Decoder::~Decoder):
(JSC::Decoder::vm):
(JSC::Decoder::offsetOf):
(JSC::Decoder::cacheOffset):
(JSC::Decoder::addFinalizer):
(JSC::encode):
(JSC::decode):
(JSC::VariableLengthObject::buffer const):
(JSC::VariableLengthObject::allocate):
(JSC::CachedPtr::encode):
(JSC::CachedPtr::decode const):
(JSC::CachedPtr::operator-> const):
(JSC::CachedPtr::get const):
(JSC::CachedRefPtr::encode):
(JSC::CachedRefPtr::decode const):
(JSC::CachedWriteBarrier::encode):
(JSC::CachedWriteBarrier::decode const):
(JSC::CachedVector::encode):
(JSC::CachedVector::decode const):
(JSC::CachedPair::encode):
(JSC::CachedPair::decode const):
(JSC::CachedHashMap::encode):
(JSC::CachedHashMap::decode const):
(JSC::CachedUniquedStringImpl::encode):
(JSC::CachedUniquedStringImpl::decode const):
(JSC::CachedStringImpl::encode):
(JSC::CachedStringImpl::decode const):
(JSC::CachedString::encode):
(JSC::CachedString::decode const):
(JSC::CachedIdentifier::encode):
(JSC::CachedIdentifier::decode const):
(JSC::CachedOptional::encode):
(JSC::CachedOptional::decode const):
(JSC::CachedOptional::decodeAsPtr const):
(JSC::CachedSimpleJumpTable::encode):
(JSC::CachedSimpleJumpTable::decode const):
(JSC::CachedStringJumpTable::encode):
(JSC::CachedStringJumpTable::decode const):
(JSC::CachedCodeBlockRareData::encode):
(JSC::CachedCodeBlockRareData::decode const):
(JSC::CachedBitVector::encode):
(JSC::CachedBitVector::decode const):
(JSC::CachedHashSet::encode):
(JSC::CachedHashSet::decode const):
(JSC::CachedConstantIdentifierSetEntry::encode):
(JSC::CachedConstantIdentifierSetEntry::decode const):
(JSC::CachedVariableEnvironment::encode):
(JSC::CachedVariableEnvironment::decode const):
(JSC::CachedArray::encode):
(JSC::CachedArray::decode const):
(JSC::CachedScopedArgumentsTable::encode):
(JSC::CachedScopedArgumentsTable::decode const):
(JSC::CachedSymbolTableEntry::encode):
(JSC::CachedSymbolTableEntry::decode const):
(JSC::CachedSymbolTable::encode):
(JSC::CachedSymbolTable::decode const):
(JSC::CachedImmutableButterfly::encode):
(JSC::CachedImmutableButterfly::decode const):
(JSC::CachedRegExp::encode):
(JSC::CachedRegExp::decode const):
(JSC::CachedTemplateObjectDescriptor::encode):
(JSC::CachedTemplateObjectDescriptor::decode const):
(JSC::CachedBigInt::encode):
(JSC::CachedBigInt::decode const):
(JSC::CachedJSValue::encode):
(JSC::CachedJSValue::decode const):
(JSC::CachedInstructionStream::encode):
(JSC::CachedInstructionStream::decode const):
(JSC::CachedMetadataTable::encode):
(JSC::CachedMetadataTable::decode const):
(JSC::CachedSourceOrigin::encode):
(JSC::CachedSourceOrigin::decode const):
(JSC::CachedTextPosition::encode):
(JSC::CachedTextPosition::decode const):
(JSC::CachedSourceProviderShape::encode):
(JSC::CachedSourceProviderShape::decode const):
(JSC::CachedStringSourceProvider::encode):
(JSC::CachedStringSourceProvider::decode const):
(JSC::CachedWebAssemblySourceProvider::encode):
(JSC::CachedWebAssemblySourceProvider::decode const):
(JSC::CachedSourceProvider::encode):
(JSC::CachedSourceProvider::decode const):
(JSC::CachedUnlinkedSourceCodeShape::encode):
(JSC::CachedUnlinkedSourceCodeShape::decode const):
(JSC::CachedSourceCode::encode):
(JSC::CachedSourceCode::decode const):
(JSC::CachedFunctionExecutable::firstLineOffset const):
(JSC::CachedFunctionExecutable::lineCount const):
(JSC::CachedFunctionExecutable::unlinkedFunctionNameStart const):
(JSC::CachedFunctionExecutable::unlinkedBodyStartColumn const):
(JSC::CachedFunctionExecutable::unlinkedBodyEndColumn const):
(JSC::CachedFunctionExecutable::startOffset const):
(JSC::CachedFunctionExecutable::sourceLength const):
(JSC::CachedFunctionExecutable::parametersStartOffset const):
(JSC::CachedFunctionExecutable::typeProfilingStartOffset const):
(JSC::CachedFunctionExecutable::typeProfilingEndOffset const):
(JSC::CachedFunctionExecutable::parameterCount const):
(JSC::CachedFunctionExecutable::features const):
(JSC::CachedFunctionExecutable::sourceParseMode const):
(JSC::CachedFunctionExecutable::isInStrictContext const):
(JSC::CachedFunctionExecutable::hasCapturedVariables const):
(JSC::CachedFunctionExecutable::isBuiltinFunction const):
(JSC::CachedFunctionExecutable::isBuiltinDefaultClassConstructor const):
(JSC::CachedFunctionExecutable::constructAbility const):
(JSC::CachedFunctionExecutable::constructorKind const):
(JSC::CachedFunctionExecutable::functionMode const):
(JSC::CachedFunctionExecutable::scriptMode const):
(JSC::CachedFunctionExecutable::superBinding const):
(JSC::CachedFunctionExecutable::derivedContextType const):
(JSC::CachedFunctionExecutable::name const):
(JSC::CachedFunctionExecutable::ecmaName const):
(JSC::CachedFunctionExecutable::inferredName const):
(JSC::CachedCodeBlock::instructions const):
(JSC::CachedCodeBlock::thisRegister const):
(JSC::CachedCodeBlock::scopeRegister const):
(JSC::CachedCodeBlock::globalObjectRegister const):
(JSC::CachedCodeBlock::sourceURLDirective const):
(JSC::CachedCodeBlock::sourceMappingURLDirective const):
(JSC::CachedCodeBlock::usesEval const):
(JSC::CachedCodeBlock::isStrictMode const):
(JSC::CachedCodeBlock::isConstructor const):
(JSC::CachedCodeBlock::hasCapturedVariables const):
(JSC::CachedCodeBlock::isBuiltinFunction const):
(JSC::CachedCodeBlock::superBinding const):
(JSC::CachedCodeBlock::scriptMode const):
(JSC::CachedCodeBlock::isArrowFunctionContext const):
(JSC::CachedCodeBlock::isClassContext const):
(JSC::CachedCodeBlock::wasCompiledWithDebuggingOpcodes const):
(JSC::CachedCodeBlock::constructorKind const):
(JSC::CachedCodeBlock::derivedContextType const):
(JSC::CachedCodeBlock::evalContextType const):
(JSC::CachedCodeBlock::hasTailCalls const):
(JSC::CachedCodeBlock::lineCount const):
(JSC::CachedCodeBlock::endColumn const):
(JSC::CachedCodeBlock::numVars const):
(JSC::CachedCodeBlock::numCalleeLocals const):
(JSC::CachedCodeBlock::numParameters const):
(JSC::CachedCodeBlock::features const):
(JSC::CachedCodeBlock::parseMode const):
(JSC::CachedCodeBlock::codeType const):
(JSC::CachedCodeBlock::rareData const):
(JSC::CachedProgramCodeBlock::encode):
(JSC::CachedProgramCodeBlock::decode const):
(JSC::CachedModuleCodeBlock::encode):
(JSC::CachedModuleCodeBlock::decode const):
(JSC::CachedEvalCodeBlock::encode):
(JSC::CachedEvalCodeBlock::decode const):
(JSC::CachedFunctionCodeBlock::encode):
(JSC::CachedFunctionCodeBlock::decode const):
(JSC::UnlinkedFunctionCodeBlock::UnlinkedFunctionCodeBlock):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
(JSC::CachedCodeBlock<CodeBlockType>::decode const):
(JSC::UnlinkedProgramCodeBlock::UnlinkedProgramCodeBlock):
(JSC::UnlinkedModuleProgramCodeBlock::UnlinkedModuleProgramCodeBlock):
(JSC::UnlinkedEvalCodeBlock::UnlinkedEvalCodeBlock):
(JSC::CachedFunctionExecutable::encode):
(JSC::CachedFunctionExecutable::decode const):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::CachedCodeBlock<CodeBlockType>::encode):
(JSC::CachedSourceCodeKey::encode):
(JSC::CachedSourceCodeKey::decode const):
(JSC::CacheEntry::encode):
(JSC::CacheEntry:: const):
(JSC:: const):
(JSC::encodeCodeBlock):
(JSC::decodeCodeBlockImpl):
* runtime/CachedTypes.h: Copied from Source/JavaScriptCore/bytecode/UnlinkedGlobalCodeBlock.h.
(JSC::decodeCodeBlock):
* runtime/CodeCache.cpp:
(JSC::CodeCacheMap::pruneSlowCase):
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
(JSC::CodeCache::write):
* runtime/CodeCache.h:
(JSC::CodeCacheMap::begin):
(JSC::CodeCacheMap::end):
(JSC::CodeCacheMap::fetchFromDiskImpl):
(JSC::CodeCacheMap::findCacheAndUpdateAge):
(JSC::writeCodeBlock):
* runtime/JSBigInt.cpp:
* runtime/JSBigInt.h:
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/RegExp.h:
* runtime/ScopedArgumentsTable.h:
* runtime/StackFrame.h:
* runtime/StructureInlines.h:
* runtime/SymbolTable.h:
2019-01-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Invalidate old scope operations using global lexical binding epoch
https://bugs.webkit.org/show_bug.cgi?id=193603
<rdar://problem/47380869>
Reviewed by Saam Barati.
Even if the global lexical binding does not shadow the global property at that time, we need to clear the cached information in
scope related operations since we may have a global property previously. Consider the following example,
foo = 0;
function get() { return foo; }
print(get()); // 0
print(get()); // 0
delete globalThis.foo;
$.evalScript(`const foo = 42;`);
print(get()); // Should be 42, but it returns 0 if the cached information in get() is not cleared.
To invalidate the cache easily, we introduce global lexical binding epoch. It is bumped every time we introduce a new lexical binding
into JSGlobalLexicalEnvironment, since that name could shadow the global property name previously. In op_resolve_scope, we first check
the epoch stored in the metadata, and go to slow path if it is not equal to the current epoch. Our slow path code convert the scope
operation to the appropriate one even if the resolve type is not UnresolvedProperty type. After updating the resolve type of the bytecode,
we update the cached epoch to the current one, so that we can use the cached information as long as we stay in the same epoch.
In op_get_from_scope and op_put_to_scope, we do not use this epoch since Structure check can do the same thing instead. If op_resolve_type
is updated by the epoch, and if it starts returning JSGlobalLexicalEnvironment instead JSGlobalObject, obviously the structure check fails.
And in the slow path, we update op_get_from_scope and op_put_to_scope appropriately.
So, the metadata for scope related bytecodes are eventually updated to the appropriate one. In DFG and FTL, we use the watchpoint based approach.
In DFG and FTL, we concurrently attempt to get the watchpoint for the lexical binding and look into it by using `isStillValid()` to avoid
infinite compile-and-fail loop.
When the global lexical binding epoch overflows we iterate all the live CodeBlock and update the op_resolve_scope's epoch. Even if the shadowing
happens, it is OK if we bump the epoch, since op_resolve_scope will return JSGlobalLexicalEnvironment instead of JSGlobalObject, and following
structure check in op_put_to_scope and op_get_from_scope fail. We do not need to update op_get_from_scope and op_put_to_scope because of the same
reason.
* bytecode/BytecodeList.rb:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::notifyLexicalBindingUpdate):
(JSC::CodeBlock::notifyLexicalBindingShadowing): Deleted.
* bytecode/CodeBlock.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGDesiredGlobalProperties.cpp:
(JSC::DFG::DesiredGlobalProperties::isStillValidOnMainThread):
* dfg/DFGDesiredGlobalProperties.h:
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::watchGlobalProperty):
* dfg/DFGGraph.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::isStillValidOnMainThread):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_resolve_scope):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_resolve_scope):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
(JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::bumpGlobalLexicalBindingEpoch):
(JSC::JSGlobalObject::getReferencedPropertyWatchpointSet):
(JSC::JSGlobalObject::ensureReferencedPropertyWatchpointSet):
(JSC::JSGlobalObject::notifyLexicalBindingShadowing): Deleted.
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::globalLexicalBindingEpoch const):
(JSC::JSGlobalObject::globalLexicalBindingEpochOffset):
(JSC::JSGlobalObject::addressOfGlobalLexicalBindingEpoch):
* runtime/Options.cpp:
(JSC::correctOptions):
(JSC::Options::initialize):
(JSC::Options::setOptions):
(JSC::Options::setOptionWithoutAlias):
* runtime/Options.h:
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties):
2019-01-21 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, roll out r240220 due to date-format-xparb regression
https://bugs.webkit.org/show_bug.cgi?id=193603
* bytecode/BytecodeList.rb:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::notifyLexicalBindingShadowing):
(JSC::CodeBlock::notifyLexicalBindingUpdate): Deleted.
* bytecode/CodeBlock.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGDesiredGlobalProperties.cpp:
(JSC::DFG::DesiredGlobalProperties::isStillValidOnMainThread):
* dfg/DFGDesiredGlobalProperties.h:
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::watchGlobalProperty): Deleted.
* dfg/DFGGraph.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::isStillValidOnMainThread):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_resolve_scope):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_resolve_scope):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
(JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::notifyLexicalBindingShadowing):
(JSC::JSGlobalObject::getReferencedPropertyWatchpointSet):
(JSC::JSGlobalObject::ensureReferencedPropertyWatchpointSet):
(JSC::JSGlobalObject::bumpGlobalLexicalBindingEpoch): Deleted.
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::globalLexicalBindingEpoch const): Deleted.
(JSC::JSGlobalObject::globalLexicalBindingEpochOffset): Deleted.
(JSC::JSGlobalObject::addressOfGlobalLexicalBindingEpoch): Deleted.
* runtime/Options.cpp:
(JSC::Options::initialize):
(JSC::Options::setOptions):
(JSC::Options::setOptionWithoutAlias):
(JSC::correctOptions): Deleted.
* runtime/Options.h:
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties):
2019-01-21 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] StrictModeTypeErrorFunction is no longer used
https://bugs.webkit.org/show_bug.cgi?id=193662
Reviewed by Mark Lam.
StrictModeTypeErrorFunction is no longer used. This patch drops it. Furthermore, it also allows us to drop
strictModeTypeErrorFunctionSpace from VM.
* runtime/Error.cpp:
(JSC::StrictModeTypeErrorFunction::destroy): Deleted.
* runtime/Error.h:
(): Deleted.
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2019-01-21 Caio Lima <ticaiolima@gmail.com>
DoesGC rule is wrong for nodes with BigIntUse
https://bugs.webkit.org/show_bug.cgi?id=193652
Reviewed by Saam Barati.
Former rule was that ValueOp does not GC. However this is wrong, since
these operations can trigger GC and mess up memory management. In the end, this
will generate wrong code because we will have wrong GC epoch value during
Store Barrier Insertion phase.
We changed this to consider BigIntUse for such nodes and properly return true when
they are BigIntUse.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
2019-01-21 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Lazily initialize JSModuleLoader
https://bugs.webkit.org/show_bug.cgi?id=193646
Reviewed by Keith Miller and Saam Barati.
Lazily initialize JSModuleLoader so that we do not need to initialize it until we need modules.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::moduleLoader const):
2019-01-20 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] sub op with 0 should be optimized
https://bugs.webkit.org/show_bug.cgi?id=190751
Reviewed by Mark Lam.
LLInt sometimes emit `subp 0, %rxx`. For example, `maxFrameExtentForSlowPathCall` is 0 in X86_64, ARM64, and ARM64E.
So `subp maxFrameExtentForSlowPathCall sp` becomes `subp 0, %rsp`. While `addp 0, %rsp` is removed in offlineasm,
sub operation does not have such an optimization. This patch applies the same optimization to sub operation already
done in add operation. Since the CPU flags changed in offlineasm's these operations are not considered (if these flags
are required, we use special branch operations instead), this optimization is sane.
One problem is that zero-extension of the 32bit register in 64bit architecture. If the instruction emission is skipped,
this won't be happen. Currently, we align our sub to add operation: we skip emission in this case.
* offlineasm/arm64.rb:
* offlineasm/x86.rb:
2019-01-20 Saam Barati <sbarati@apple.com>
DFG: When inlining DataView set* intrinsics we need to set undefined as our result
https://bugs.webkit.org/show_bug.cgi?id=193644
<rdar://problem/46209745>
Reviewed by Yusuke Suzuki.
This patch also makes it so we fail fast when we make this mistake.
I've made this mistake more than once.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2019-01-20 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Reduce size of SourceProvider
https://bugs.webkit.org/show_bug.cgi?id=193544
Reviewed by Saam Barati.
This patch attempts to reduce the dirty memory footprint by the following 3 optimizations.
1. Reordering the members of SourceProvider to reduce the size. This affects on JSC, and CachedScriptSourceProvider used in WebCore.
2. Create one SourceProvider for all the builtin code and use substring to create builtin JS functions.
This reduces # of SourceProvider created for builtins.
3. Drop m_validated flag in SourceProvider since nobody uses it. It also deletes dead code in Parser.cpp.
Unfortunately, MSVC does not accept super long C string literal. So instead, we construct combined string in a form of C array.
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
* Scripts/wkbuiltins/builtins_generate_combined_header.py:
(BuiltinsCombinedHeaderGenerator.generate_output):
* Scripts/wkbuiltins/builtins_generate_combined_implementation.py:
(BuiltinsCombinedImplementationGenerator.generate_output):
* Scripts/wkbuiltins/builtins_generate_separate_implementation.py:
(BuiltinsSeparateImplementationGenerator.generate_output):
* Scripts/wkbuiltins/builtins_generator.py:
(BuiltinsGenerator.generate_embedded_code_data_for_function):
(BuiltinsGenerator.generate_embedded_code_string_section_for_data):
(BuiltinsGenerator.generate_embedded_code_string_section_for_function): Deleted.
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::BuiltinExecutables):
(JSC::JSC_FOREACH_BUILTIN_CODE):
(JSC::BuiltinExecutables::createExecutable):
* builtins/BuiltinExecutables.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::Parser):
(JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
(JSC::Parser<LexerType>::shouldCheckPropertyForUnderscoreProtoDuplicate):
(JSC::Parser<LexerType>::parseObjectLiteral):
(JSC::Parser<LexerType>::parseUnaryExpression):
* parser/Parser.h:
* parser/SourceCode.h:
* parser/SourceProvider.cpp:
(JSC::SourceProvider::SourceProvider):
* parser/SourceProvider.h:
(JSC::SourceProvider::isValid const): Deleted.
(JSC::SourceProvider::setValid): Deleted.
* runtime/CachedTypes.cpp:
(JSC::CachedSourceProviderShape::encode):
(JSC::CachedSourceProviderShape::decode const):
2019-01-20 Michael Catanzaro <mcatanzaro@igalia.com>
Unreviewed, fix -Wint-in-bool-context warning
https://bugs.webkit.org/show_bug.cgi?id=193483
<rdar://problem/47280522>
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::addCheckStructureForOriginalStringObjectUse):
2019-01-20 Saam Barati <sbarati@apple.com>
Rollout r240210: It broke tests on iOS
https://bugs.webkit.org/show_bug.cgi?id=193640
Unreviewed. ~2650 tests are failing on iOS.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* builtins/BuiltinNames.cpp:
(JSC::BuiltinNames::BuiltinNames):
* builtins/BuiltinNames.h:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::setConstantIdentifierSetRegisters):
* bytecode/CodeBlock.h:
* bytecode/HandlerInfo.h:
* bytecode/InstructionStream.h:
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::addSetConstant):
(JSC::UnlinkedCodeBlock::constantIdentifierSets):
* bytecode/UnlinkedEvalCodeBlock.h:
* bytecode/UnlinkedFunctionCodeBlock.h:
* bytecode/UnlinkedFunctionExecutable.h:
* bytecode/UnlinkedGlobalCodeBlock.h:
(JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock):
* bytecode/UnlinkedMetadataTable.h:
* bytecode/UnlinkedModuleProgramCodeBlock.h:
* bytecode/UnlinkedProgramCodeBlock.h:
* interpreter/Interpreter.cpp:
* jsc.cpp:
(functionQuit):
(runJSC):
* parser/SourceCode.h:
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::operator!= const): Deleted.
* parser/UnlinkedSourceCode.h:
* parser/VariableEnvironment.h:
* runtime/CachedTypes.cpp:
(): Deleted.
(JSC::Encoder::Allocation::buffer const): Deleted.
(JSC::Encoder::Allocation::offset const): Deleted.
(JSC::Encoder::Allocation::Allocation): Deleted.
(JSC::Encoder::Encoder): Deleted.
(JSC::Encoder::vm): Deleted.
(JSC::Encoder::malloc): Deleted.
(JSC::Encoder::offsetOf): Deleted.
(JSC::Encoder::cachePtr): Deleted.
(JSC::Encoder::offsetForPtr): Deleted.
(JSC::Encoder::release): Deleted.
(JSC::Encoder::Page::Page): Deleted.
(JSC::Encoder::Page::malloc): Deleted.
(JSC::Encoder::Page::buffer const): Deleted.
(JSC::Encoder::Page::size const): Deleted.
(JSC::Encoder::Page::getOffset const): Deleted.
(JSC::Encoder::allocateNewPage): Deleted.
(JSC::Decoder::Decoder): Deleted.
(JSC::Decoder::~Decoder): Deleted.
(JSC::Decoder::vm): Deleted.
(JSC::Decoder::offsetOf): Deleted.
(JSC::Decoder::cacheOffset): Deleted.
(JSC::Decoder::addFinalizer): Deleted.
(JSC::encode): Deleted.
(JSC::decode): Deleted.
(JSC::VariableLengthObject::buffer const): Deleted.
(JSC::VariableLengthObject::allocate): Deleted.
(JSC::CachedPtr::encode): Deleted.
(JSC::CachedPtr::decode const): Deleted.
(JSC::CachedPtr::operator-> const): Deleted.
(JSC::CachedPtr::get const): Deleted.
(JSC::CachedRefPtr::encode): Deleted.
(JSC::CachedRefPtr::decode const): Deleted.
(JSC::CachedWriteBarrier::encode): Deleted.
(JSC::CachedWriteBarrier::decode const): Deleted.
(JSC::CachedVector::encode): Deleted.
(JSC::CachedVector::decode const): Deleted.
(JSC::CachedPair::encode): Deleted.
(JSC::CachedPair::decode const): Deleted.
(JSC::CachedHashMap::encode): Deleted.
(JSC::CachedHashMap::decode const): Deleted.
(JSC::CachedUniquedStringImpl::encode): Deleted.
(JSC::CachedUniquedStringImpl::decode const): Deleted.
(JSC::CachedStringImpl::encode): Deleted.
(JSC::CachedStringImpl::decode const): Deleted.
(JSC::CachedString::encode): Deleted.
(JSC::CachedString::decode const): Deleted.
(JSC::CachedIdentifier::encode): Deleted.
(JSC::CachedIdentifier::decode const): Deleted.
(JSC::CachedOptional::encode): Deleted.
(JSC::CachedOptional::decode const): Deleted.
(JSC::CachedOptional::decodeAsPtr const): Deleted.
(JSC::CachedSimpleJumpTable::encode): Deleted.
(JSC::CachedSimpleJumpTable::decode const): Deleted.
(JSC::CachedStringJumpTable::encode): Deleted.
(JSC::CachedStringJumpTable::decode const): Deleted.
(JSC::CachedCodeBlockRareData::encode): Deleted.
(JSC::CachedCodeBlockRareData::decode const): Deleted.
(JSC::CachedBitVector::encode): Deleted.
(JSC::CachedBitVector::decode const): Deleted.
(JSC::CachedHashSet::encode): Deleted.
(JSC::CachedHashSet::decode const): Deleted.
(JSC::CachedConstantIdentifierSetEntry::encode): Deleted.
(JSC::CachedConstantIdentifierSetEntry::decode const): Deleted.
(JSC::CachedVariableEnvironment::encode): Deleted.
(JSC::CachedVariableEnvironment::decode const): Deleted.
(JSC::CachedArray::encode): Deleted.
(JSC::CachedArray::decode const): Deleted.
(JSC::CachedScopedArgumentsTable::encode): Deleted.
(JSC::CachedScopedArgumentsTable::decode const): Deleted.
(JSC::CachedSymbolTableEntry::encode): Deleted.
(JSC::CachedSymbolTableEntry::decode const): Deleted.
(JSC::CachedSymbolTable::encode): Deleted.
(JSC::CachedSymbolTable::decode const): Deleted.
(JSC::CachedImmutableButterfly::encode): Deleted.
(JSC::CachedImmutableButterfly::decode const): Deleted.
(JSC::CachedRegExp::encode): Deleted.
(JSC::CachedRegExp::decode const): Deleted.
(JSC::CachedTemplateObjectDescriptor::encode): Deleted.
(JSC::CachedTemplateObjectDescriptor::decode const): Deleted.
(JSC::CachedBigInt::encode): Deleted.
(JSC::CachedBigInt::decode const): Deleted.
(JSC::CachedJSValue::encode): Deleted.
(JSC::CachedJSValue::decode const): Deleted.
(JSC::CachedInstructionStream::encode): Deleted.
(JSC::CachedInstructionStream::decode const): Deleted.
(JSC::CachedMetadataTable::encode): Deleted.
(JSC::CachedMetadataTable::decode const): Deleted.
(JSC::CachedSourceOrigin::encode): Deleted.
(JSC::CachedSourceOrigin::decode const): Deleted.
(JSC::CachedTextPosition::encode): Deleted.
(JSC::CachedTextPosition::decode const): Deleted.
(JSC::CachedSourceProviderShape::encode): Deleted.
(JSC::CachedSourceProviderShape::decode const): Deleted.
(JSC::CachedStringSourceProvider::encode): Deleted.
(JSC::CachedStringSourceProvider::decode const): Deleted.
(JSC::CachedWebAssemblySourceProvider::encode): Deleted.
(JSC::CachedWebAssemblySourceProvider::decode const): Deleted.
(JSC::CachedSourceProvider::encode): Deleted.
(JSC::CachedSourceProvider::decode const): Deleted.
(JSC::CachedUnlinkedSourceCodeShape::encode): Deleted.
(JSC::CachedUnlinkedSourceCodeShape::decode const): Deleted.
(JSC::CachedSourceCode::encode): Deleted.
(JSC::CachedSourceCode::decode const): Deleted.
(JSC::CachedFunctionExecutable::firstLineOffset const): Deleted.
(JSC::CachedFunctionExecutable::lineCount const): Deleted.
(JSC::CachedFunctionExecutable::unlinkedFunctionNameStart const): Deleted.
(JSC::CachedFunctionExecutable::unlinkedBodyStartColumn const): Deleted.
(JSC::CachedFunctionExecutable::unlinkedBodyEndColumn const): Deleted.
(JSC::CachedFunctionExecutable::startOffset const): Deleted.
(JSC::CachedFunctionExecutable::sourceLength const): Deleted.
(JSC::CachedFunctionExecutable::parametersStartOffset const): Deleted.
(JSC::CachedFunctionExecutable::typeProfilingStartOffset const): Deleted.
(JSC::CachedFunctionExecutable::typeProfilingEndOffset const): Deleted.
(JSC::CachedFunctionExecutable::parameterCount const): Deleted.
(JSC::CachedFunctionExecutable::features const): Deleted.
(JSC::CachedFunctionExecutable::sourceParseMode const): Deleted.
(JSC::CachedFunctionExecutable::isInStrictContext const): Deleted.
(JSC::CachedFunctionExecutable::hasCapturedVariables const): Deleted.
(JSC::CachedFunctionExecutable::isBuiltinFunction const): Deleted.
(JSC::CachedFunctionExecutable::isBuiltinDefaultClassConstructor const): Deleted.
(JSC::CachedFunctionExecutable::constructAbility const): Deleted.
(JSC::CachedFunctionExecutable::constructorKind const): Deleted.
(JSC::CachedFunctionExecutable::functionMode const): Deleted.
(JSC::CachedFunctionExecutable::scriptMode const): Deleted.
(JSC::CachedFunctionExecutable::superBinding const): Deleted.
(JSC::CachedFunctionExecutable::derivedContextType const): Deleted.
(JSC::CachedFunctionExecutable::name const): Deleted.
(JSC::CachedFunctionExecutable::ecmaName const): Deleted.
(JSC::CachedFunctionExecutable::inferredName const): Deleted.
(JSC::CachedCodeBlock::instructions const): Deleted.
(JSC::CachedCodeBlock::thisRegister const): Deleted.
(JSC::CachedCodeBlock::scopeRegister const): Deleted.
(JSC::CachedCodeBlock::globalObjectRegister const): Deleted.
(JSC::CachedCodeBlock::sourceURLDirective const): Deleted.
(JSC::CachedCodeBlock::sourceMappingURLDirective const): Deleted.
(JSC::CachedCodeBlock::usesEval const): Deleted.
(JSC::CachedCodeBlock::isStrictMode const): Deleted.
(JSC::CachedCodeBlock::isConstructor const): Deleted.
(JSC::CachedCodeBlock::hasCapturedVariables const): Deleted.
(JSC::CachedCodeBlock::isBuiltinFunction const): Deleted.
(JSC::CachedCodeBlock::superBinding const): Deleted.
(JSC::CachedCodeBlock::scriptMode const): Deleted.
(JSC::CachedCodeBlock::isArrowFunctionContext const): Deleted.
(JSC::CachedCodeBlock::isClassContext const): Deleted.
(JSC::CachedCodeBlock::wasCompiledWithDebuggingOpcodes const): Deleted.
(JSC::CachedCodeBlock::constructorKind const): Deleted.
(JSC::CachedCodeBlock::derivedContextType const): Deleted.
(JSC::CachedCodeBlock::evalContextType const): Deleted.
(JSC::CachedCodeBlock::hasTailCalls const): Deleted.
(JSC::CachedCodeBlock::lineCount const): Deleted.
(JSC::CachedCodeBlock::endColumn const): Deleted.
(JSC::CachedCodeBlock::numVars const): Deleted.
(JSC::CachedCodeBlock::numCalleeLocals const): Deleted.
(JSC::CachedCodeBlock::numParameters const): Deleted.
(JSC::CachedCodeBlock::features const): Deleted.
(JSC::CachedCodeBlock::parseMode const): Deleted.
(JSC::CachedCodeBlock::codeType const): Deleted.
(JSC::CachedCodeBlock::rareData const): Deleted.
(JSC::CachedProgramCodeBlock::encode): Deleted.
(JSC::CachedProgramCodeBlock::decode const): Deleted.
(JSC::CachedModuleCodeBlock::encode): Deleted.
(JSC::CachedModuleCodeBlock::decode const): Deleted.
(JSC::CachedEvalCodeBlock::encode): Deleted.
(JSC::CachedEvalCodeBlock::decode const): Deleted.
(JSC::CachedFunctionCodeBlock::encode): Deleted.
(JSC::CachedFunctionCodeBlock::decode const): Deleted.
(JSC::UnlinkedFunctionCodeBlock::UnlinkedFunctionCodeBlock): Deleted.
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): Deleted.
(JSC::CachedCodeBlock<CodeBlockType>::decode const): Deleted.
(JSC::UnlinkedProgramCodeBlock::UnlinkedProgramCodeBlock): Deleted.
(JSC::UnlinkedModuleProgramCodeBlock::UnlinkedModuleProgramCodeBlock): Deleted.
(JSC::UnlinkedEvalCodeBlock::UnlinkedEvalCodeBlock): Deleted.
(JSC::CachedFunctionExecutable::encode): Deleted.
(JSC::CachedFunctionExecutable::decode const): Deleted.
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable): Deleted.
(JSC::CachedCodeBlock<CodeBlockType>::encode): Deleted.
(JSC::CachedSourceCodeKey::encode): Deleted.
(JSC::CachedSourceCodeKey::decode const): Deleted.
(JSC::CacheEntry::encode): Deleted.
(JSC::CacheEntry:: const): Deleted.
(JSC:: const): Deleted.
(JSC::encodeCodeBlock): Deleted.
(JSC::decodeCodeBlockImpl): Deleted.
* runtime/CachedTypes.h:
(JSC::decodeCodeBlock): Deleted.
* runtime/CodeCache.cpp:
(JSC::CodeCacheMap::pruneSlowCase):
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
(JSC::CodeCache::write): Deleted.
* runtime/CodeCache.h:
(JSC::CodeCacheMap::findCacheAndUpdateAge):
(JSC::CodeCache::clear):
(JSC::CodeCacheMap::begin): Deleted.
(JSC::CodeCacheMap::end): Deleted.
(JSC::CodeCacheMap::fetchFromDiskImpl): Deleted.
(): Deleted.
(JSC::writeCodeBlock): Deleted.
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::offsetOfData):
(JSC::JSBigInt::dataStorage):
* runtime/JSBigInt.h:
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/Options.h:
* runtime/RegExp.h:
* runtime/ScopedArgumentsTable.h:
* runtime/StackFrame.h:
* runtime/StructureInlines.h:
* runtime/SymbolTable.h:
2019-01-20 Saam Barati <sbarati@apple.com>
MovHint must merge NodeBytecodeUsesAsValue for its child in backwards propagation
https://bugs.webkit.org/show_bug.cgi?id=186916
<rdar://problem/41396612>
Reviewed by Yusuke Suzuki.
Otherwise, we may not think we care about the non-integral part in
a division (or perhaps overflow in an add, etc). Consider a program
like this:
```return a / b```
That gets compiled to:
```
a: ArithDiv // We don't check that the remainder is zero here.
b: MovHint(@a)
c: ForceOSRExit
d: Unreachable
```
If we don't inform @a that we care about its result in full number
accuracy, it will choose to ignore its non-integral remainder. This
makes sense if *everybody* that all uses of the Div only cared about
the integral part. However, OSR exit is not one of those users. OSR
exit cares about the fractional bits in such a Div.
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
2019-01-20 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Invalidate old scope operations using global lexical binding epoch
https://bugs.webkit.org/show_bug.cgi?id=193603
<rdar://problem/47380869>
Reviewed by Saam Barati.
Even if the global lexical binding does not shadow the global property at that time, we need to clear the cached information in
scope related operations since we may have a global property previously. Consider the following example,
foo = 0;
function get() { return foo; }
print(get()); // 0
print(get()); // 0
delete globalThis.foo;
$.evalScript(`const foo = 42;`);
print(get()); // Should be 42, but it returns 0 if the cached information in get() is not cleared.
To invalidate the cache easily, we introduce global lexical binding epoch. It is bumped every time we introduce a new lexical binding
into JSGlobalLexicalEnvironment, since that name could shadow the global property name previously. In op_resolve_scope, we first check
the epoch stored in the metadata, and go to slow path if it is not equal to the current epoch. Our slow path code convert the scope
operation to the appropriate one even if the resolve type is not UnresolvedProperty type. After updating the resolve type of the bytecode,
we update the cached epoch to the current one, so that we can use the cached information as long as we stay in the same epoch.
In op_get_from_scope and op_put_to_scope, we do not use this epoch since Structure check can do the same thing instead. If op_resolve_type
is updated by the epoch, and if it starts returning JSGlobalLexicalEnvironment instead JSGlobalObject, obviously the structure check fails.
And in the slow path, we update op_get_from_scope and op_put_to_scope appropriately.
So, the metadata for scope related bytecodes are eventually updated to the appropriate one. In DFG and FTL, we use the watchpoint based approach.
In DFG and FTL, we concurrently attempt to get the watchpoint for the lexical binding and look into it by using `isStillValid()` to avoid
infinite compile-and-fail loop.
When the global lexical binding epoch overflows we iterate all the live CodeBlock and update the op_resolve_scope's epoch. Even if the shadowing
happens, it is OK if we bump the epoch, since op_resolve_scope will return JSGlobalLexicalEnvironment instead of JSGlobalObject, and following
structure check in op_put_to_scope and op_get_from_scope fail. We do not need to update op_get_from_scope and op_put_to_scope because of the same
reason.
* bytecode/BytecodeList.rb:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::notifyLexicalBindingUpdate):
(JSC::CodeBlock::notifyLexicalBindingShadowing): Deleted.
* bytecode/CodeBlock.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGDesiredGlobalProperties.cpp:
(JSC::DFG::DesiredGlobalProperties::isStillValidOnMainThread):
* dfg/DFGDesiredGlobalProperties.h:
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::watchGlobalProperty):
* dfg/DFGGraph.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::isStillValidOnMainThread):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_resolve_scope):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_resolve_scope):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
(JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::bumpGlobalLexicalBindingEpoch):
(JSC::JSGlobalObject::getReferencedPropertyWatchpointSet):
(JSC::JSGlobalObject::ensureReferencedPropertyWatchpointSet):
(JSC::JSGlobalObject::notifyLexicalBindingShadowing): Deleted.
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::globalLexicalBindingEpoch const):
(JSC::JSGlobalObject::globalLexicalBindingEpochOffset):
(JSC::JSGlobalObject::addressOfGlobalLexicalBindingEpoch):
* runtime/Options.cpp:
(JSC::correctOptions):
(JSC::Options::initialize):
(JSC::Options::setOptions):
(JSC::Options::setOptionWithoutAlias):
* runtime/Options.h:
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties):
2019-01-20 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Shrink data structure size in JSC/heap
https://bugs.webkit.org/show_bug.cgi?id=193612
Reviewed by Saam Barati.
This patch reduces the size of data structures in JSC/heap. Basically, we reorder the members to remove paddings.
For Subspace, we drop CellAttributes `m_attributes`. Instead, we use `heapCellType->attributes()`. And we use
FreeList::cellSize() instead of holding m_cellSize in LocalAllocator.
This change reduces the size of JSC::VM too since it includes JSC::Heap. The size of VM becomes from 78208 to 76696.
* heap/BlockDirectory.cpp:
* heap/BlockDirectory.h:
* heap/CollectionScope.h:
* heap/CompleteSubspace.cpp:
(JSC::CompleteSubspace::allocatorForSlow):
* heap/FreeList.h:
(JSC::FreeList::offsetOfCellSize):
(JSC::FreeList::cellSize const):
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::updateObjectCounts):
(JSC::Heap::addToRememberedSet):
(JSC::Heap::runBeginPhase):
(JSC::Heap::willStartCollection):
(JSC::Heap::pruneStaleEntriesFromWeakGCMaps):
(JSC::Heap::deleteSourceProviderCaches):
(JSC::Heap::notifyIncrementalSweeper):
(JSC::Heap::updateAllocationLimits):
* heap/Heap.h:
* heap/IsoAlignedMemoryAllocator.h:
* heap/LargeAllocation.cpp:
* heap/LocalAllocator.cpp:
(JSC::LocalAllocator::LocalAllocator):
* heap/LocalAllocator.h:
(JSC::LocalAllocator::cellSize const):
(JSC::LocalAllocator::offsetOfCellSize):
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::MarkedSpace):
* heap/MarkedSpace.h:
* heap/MarkingConstraint.h:
* heap/Subspace.cpp:
(JSC::Subspace::initialize):
* heap/Subspace.h:
(JSC::Subspace::attributes const): Deleted.
* heap/SubspaceInlines.h:
(JSC::Subspace::forEachMarkedCell):
(JSC::Subspace::forEachMarkedCellInParallel):
(JSC::Subspace::forEachLiveCell):
(JSC::Subspace::attributes const):
2019-01-20 Tadeu Zagallo <tzagallo@apple.com>
Cache bytecode to disk
https://bugs.webkit.org/show_bug.cgi?id=192782
<rdar://problem/46084932>
Reviewed by Keith Miller.
Add the logic to serialize and deserialize the new JSC bytecode. For now,
the cache is only used for tests.
Each class that can be serialized has a counterpart in CachedTypes, which
handles the decoding and encoding. When decoding, the cached objects are
mmap'd from disk, but only used for creating instances of the respective
in-memory version of each object. Ideally, the mmap'd objects should be
used at runtime in the future.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* builtins/BuiltinNames.cpp:
(JSC::BuiltinNames::BuiltinNames):
* builtins/BuiltinNames.h:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::setConstantIdentifierSetRegisters):
* bytecode/CodeBlock.h:
* bytecode/HandlerInfo.h:
(JSC::UnlinkedHandlerInfo::UnlinkedHandlerInfo):
* bytecode/InstructionStream.h:
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::addSetConstant):
(JSC::UnlinkedCodeBlock::constantIdentifierSets):
* bytecode/UnlinkedEvalCodeBlock.h:
* bytecode/UnlinkedFunctionCodeBlock.h:
* bytecode/UnlinkedFunctionExecutable.h:
* bytecode/UnlinkedGlobalCodeBlock.h:
(JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock):
* bytecode/UnlinkedMetadataTable.h:
* bytecode/UnlinkedModuleProgramCodeBlock.h:
* bytecode/UnlinkedProgramCodeBlock.h:
* interpreter/Interpreter.cpp:
* jsc.cpp:
(functionQuit):
(runJSC):
* parser/SourceCode.h:
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::operator!= const):
* parser/UnlinkedSourceCode.h:
* parser/VariableEnvironment.h:
* runtime/CachedTypes.cpp: Added.
(JSC::Encoder::Allocation::buffer const):
(JSC::Encoder::Allocation::offset const):
(JSC::Encoder::Allocation::Allocation):
(JSC::Encoder::Encoder):
(JSC::Encoder::vm):
(JSC::Encoder::malloc):
(JSC::Encoder::offsetOf):
(JSC::Encoder::cachePtr):
(JSC::Encoder::offsetForPtr):
(JSC::Encoder::release):
(JSC::Encoder::Page::Page):
(JSC::Encoder::Page::malloc):
(JSC::Encoder::Page::buffer const):
(JSC::Encoder::Page::size const):
(JSC::Encoder::Page::getOffset const):
(JSC::Encoder::allocateNewPage):
(JSC::Decoder::Decoder):
(JSC::Decoder::~Decoder):
(JSC::Decoder::vm):
(JSC::Decoder::offsetOf):
(JSC::Decoder::cacheOffset):
(JSC::Decoder::addFinalizer):
(JSC::encode):
(JSC::decode):
(JSC::VariableLengthObject::buffer const):
(JSC::VariableLengthObject::allocate):
(JSC::CachedPtr::encode):
(JSC::CachedPtr::decode const):
(JSC::CachedPtr::operator-> const):
(JSC::CachedPtr::get const):
(JSC::CachedRefPtr::encode):
(JSC::CachedRefPtr::decode const):
(JSC::CachedWriteBarrier::encode):
(JSC::CachedWriteBarrier::decode const):
(JSC::CachedVector::encode):
(JSC::CachedVector::decode const):
(JSC::CachedPair::encode):
(JSC::CachedPair::decode const):
(JSC::CachedHashMap::encode):
(JSC::CachedHashMap::decode const):
(JSC::CachedUniquedStringImpl::encode):
(JSC::CachedUniquedStringImpl::decode const):
(JSC::CachedStringImpl::encode):
(JSC::CachedStringImpl::decode const):
(JSC::CachedString::encode):
(JSC::CachedString::decode const):
(JSC::CachedIdentifier::encode):
(JSC::CachedIdentifier::decode const):
(JSC::CachedOptional::encode):
(JSC::CachedOptional::decode const):
(JSC::CachedOptional::decodeAsPtr const):
(JSC::CachedSimpleJumpTable::encode):
(JSC::CachedSimpleJumpTable::decode const):
(JSC::CachedStringJumpTable::encode):
(JSC::CachedStringJumpTable::decode const):
(JSC::CachedCodeBlockRareData::encode):
(JSC::CachedCodeBlockRareData::decode const):
(JSC::CachedBitVector::encode):
(JSC::CachedBitVector::decode const):
(JSC::CachedHashSet::encode):
(JSC::CachedHashSet::decode const):
(JSC::CachedConstantIdentifierSetEntry::encode):
(JSC::CachedConstantIdentifierSetEntry::decode const):
(JSC::CachedVariableEnvironment::encode):
(JSC::CachedVariableEnvironment::decode const):
(JSC::CachedArray::encode):
(JSC::CachedArray::decode const):
(JSC::CachedScopedArgumentsTable::encode):
(JSC::CachedScopedArgumentsTable::decode const):
(JSC::CachedSymbolTableEntry::encode):
(JSC::CachedSymbolTableEntry::decode const):
(JSC::CachedSymbolTable::encode):
(JSC::CachedSymbolTable::decode const):
(JSC::CachedImmutableButterfly::encode):
(JSC::CachedImmutableButterfly::decode const):
(JSC::CachedRegExp::encode):
(JSC::CachedRegExp::decode const):
(JSC::CachedTemplateObjectDescriptor::encode):
(JSC::CachedTemplateObjectDescriptor::decode const):
(JSC::CachedBigInt::encode):
(JSC::CachedBigInt::decode const):
(JSC::CachedJSValue::encode):
(JSC::CachedJSValue::decode const):
(JSC::CachedInstructionStream::encode):
(JSC::CachedInstructionStream::decode const):
(JSC::CachedMetadataTable::encode):
(JSC::CachedMetadataTable::decode const):
(JSC::CachedSourceOrigin::encode):
(JSC::CachedSourceOrigin::decode const):
(JSC::CachedTextPosition::encode):
(JSC::CachedTextPosition::decode const):
(JSC::CachedSourceProviderShape::encode):
(JSC::CachedSourceProviderShape::decode const):
(JSC::CachedStringSourceProvider::encode):
(JSC::CachedStringSourceProvider::decode const):
(JSC::CachedWebAssemblySourceProvider::encode):
(JSC::CachedWebAssemblySourceProvider::decode const):
(JSC::CachedSourceProvider::encode):
(JSC::CachedSourceProvider::decode const):
(JSC::CachedUnlinkedSourceCodeShape::encode):
(JSC::CachedUnlinkedSourceCodeShape::decode const):
(JSC::CachedSourceCode::encode):
(JSC::CachedSourceCode::decode const):
(JSC::CachedFunctionExecutable::firstLineOffset const):
(JSC::CachedFunctionExecutable::lineCount const):
(JSC::CachedFunctionExecutable::unlinkedFunctionNameStart const):
(JSC::CachedFunctionExecutable::unlinkedBodyStartColumn const):
(JSC::CachedFunctionExecutable::unlinkedBodyEndColumn const):
(JSC::CachedFunctionExecutable::startOffset const):
(JSC::CachedFunctionExecutable::sourceLength const):
(JSC::CachedFunctionExecutable::parametersStartOffset const):
(JSC::CachedFunctionExecutable::typeProfilingStartOffset const):
(JSC::CachedFunctionExecutable::typeProfilingEndOffset const):
(JSC::CachedFunctionExecutable::parameterCount const):
(JSC::CachedFunctionExecutable::features const):
(JSC::CachedFunctionExecutable::sourceParseMode const):
(JSC::CachedFunctionExecutable::isInStrictContext const):
(JSC::CachedFunctionExecutable::hasCapturedVariables const):
(JSC::CachedFunctionExecutable::isBuiltinFunction const):
(JSC::CachedFunctionExecutable::isBuiltinDefaultClassConstructor const):
(JSC::CachedFunctionExecutable::constructAbility const):
(JSC::CachedFunctionExecutable::constructorKind const):
(JSC::CachedFunctionExecutable::functionMode const):
(JSC::CachedFunctionExecutable::scriptMode const):
(JSC::CachedFunctionExecutable::superBinding const):
(JSC::CachedFunctionExecutable::derivedContextType const):
(JSC::CachedFunctionExecutable::name const):
(JSC::CachedFunctionExecutable::ecmaName const):
(JSC::CachedFunctionExecutable::inferredName const):
(JSC::CachedCodeBlock::instructions const):
(JSC::CachedCodeBlock::thisRegister const):
(JSC::CachedCodeBlock::scopeRegister const):
(JSC::CachedCodeBlock::globalObjectRegister const):
(JSC::CachedCodeBlock::sourceURLDirective const):
(JSC::CachedCodeBlock::sourceMappingURLDirective const):
(JSC::CachedCodeBlock::usesEval const):
(JSC::CachedCodeBlock::isStrictMode const):
(JSC::CachedCodeBlock::isConstructor const):
(JSC::CachedCodeBlock::hasCapturedVariables const):
(JSC::CachedCodeBlock::isBuiltinFunction const):
(JSC::CachedCodeBlock::superBinding const):
(JSC::CachedCodeBlock::scriptMode const):
(JSC::CachedCodeBlock::isArrowFunctionContext const):
(JSC::CachedCodeBlock::isClassContext const):
(JSC::CachedCodeBlock::wasCompiledWithDebuggingOpcodes const):
(JSC::CachedCodeBlock::constructorKind const):
(JSC::CachedCodeBlock::derivedContextType const):
(JSC::CachedCodeBlock::evalContextType const):
(JSC::CachedCodeBlock::hasTailCalls const):
(JSC::CachedCodeBlock::lineCount const):
(JSC::CachedCodeBlock::endColumn const):
(JSC::CachedCodeBlock::numVars const):
(JSC::CachedCodeBlock::numCalleeLocals const):
(JSC::CachedCodeBlock::numParameters const):
(JSC::CachedCodeBlock::features const):
(JSC::CachedCodeBlock::parseMode const):
(JSC::CachedCodeBlock::codeType const):
(JSC::CachedCodeBlock::rareData const):
(JSC::CachedProgramCodeBlock::encode):
(JSC::CachedProgramCodeBlock::decode const):
(JSC::CachedModuleCodeBlock::encode):
(JSC::CachedModuleCodeBlock::decode const):
(JSC::CachedEvalCodeBlock::encode):
(JSC::CachedEvalCodeBlock::decode const):
(JSC::CachedFunctionCodeBlock::encode):
(JSC::CachedFunctionCodeBlock::decode const):
(JSC::UnlinkedFunctionCodeBlock::UnlinkedFunctionCodeBlock):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
(JSC::CachedCodeBlock<CodeBlockType>::decode const):
(JSC::UnlinkedProgramCodeBlock::UnlinkedProgramCodeBlock):
(JSC::UnlinkedModuleProgramCodeBlock::UnlinkedModuleProgramCodeBlock):
(JSC::UnlinkedEvalCodeBlock::UnlinkedEvalCodeBlock):
(JSC::CachedFunctionExecutable::encode):
(JSC::CachedFunctionExecutable::decode const):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::CachedCodeBlock<CodeBlockType>::encode):
(JSC::CachedSourceCodeKey::encode):
(JSC::CachedSourceCodeKey::decode const):
(JSC::CacheEntry::encode):
(JSC::CacheEntry:: const):
(JSC:: const):
(JSC::encodeCodeBlock):
(JSC::decodeCodeBlockImpl):
* runtime/CachedTypes.h: Copied from Source/JavaScriptCore/bytecode/UnlinkedGlobalCodeBlock.h.
(JSC::decodeCodeBlock):
* runtime/CodeCache.cpp:
(JSC::CodeCacheMap::pruneSlowCase):
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
(JSC::CodeCache::write):
* runtime/CodeCache.h:
(JSC::CodeCacheMap::begin):
(JSC::CodeCacheMap::end):
(JSC::CodeCacheMap::fetchFromDiskImpl):
(JSC::CodeCacheMap::findCacheAndUpdateAge):
(JSC::writeCodeBlock):
* runtime/JSBigInt.cpp:
* runtime/JSBigInt.h:
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/Options.h:
* runtime/RegExp.h:
* runtime/ScopedArgumentsTable.h:
* runtime/StackFrame.h:
* runtime/StructureInlines.h:
* runtime/SymbolTable.h:
2019-01-20 Antoine Quint <graouts@apple.com>
Add a POINTER_EVENTS feature flag
https://bugs.webkit.org/show_bug.cgi?id=193577
<rdar://problem/47408511>
Unreviewed. Also enable Pointer Events for iosmac.
* Configurations/FeatureDefines.xcconfig:
2019-01-19 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Reorder JSSegmentedVariableObject member for preparation of JSGlobalObject memory reduction
https://bugs.webkit.org/show_bug.cgi?id=193609
Reviewed by Sam Weinig.
Basically, we should order the members in large => small order not to add paddings.
* runtime/JSSegmentedVariableObject.h:
2019-01-19 Antoine Quint <graouts@apple.com>
Add a POINTER_EVENTS feature flag
https://bugs.webkit.org/show_bug.cgi?id=193577
Reviewed by Dean Jackson.
* Configurations/FeatureDefines.xcconfig:
2019-01-18 Keith Miller <keith_miller@apple.com>
JSScript API should only take ascii files.
https://bugs.webkit.org/show_bug.cgi?id=193420
Reviewed by Saam Barati.
This patch leaves the UTF8 method for binary compatablity, which
will be removed later.
* API/JSScript.h:
* API/JSScript.mm:
(fillBufferWithContentsOfFile):
(+[JSScript scriptFromASCIIFile:inVirtualMachine:withCodeSigning:andBytecodeCache:]):
(+[JSScript scriptFromUTF8File:inVirtualMachine:withCodeSigning:andBytecodeCache:]):
* API/tests/testapi.mm:
(-[JSContextFileLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
2019-01-18 David Kilzer <ddkilzer@apple.com>
Follow-up: Gigacages should start allocations from a slide
<https://bugs.webkit.org/show_bug.cgi?id=193523>
<rdar://problem/44958707>
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::caged): Add UNUSED_PARAM(kind) to
fix the build.
2019-01-18 Jer Noble <jer.noble@apple.com>
SDK_VARIANT build destinations should be separate from non-SDK_VARIANT builds
https://bugs.webkit.org/show_bug.cgi?id=189553
Reviewed by Tim Horton.
* Configurations/Base.xcconfig:
* Configurations/SDKVariant.xcconfig: Added.
2019-01-18 Keith Miller <keith_miller@apple.com>
Gigacages should start allocations from a slide
https://bugs.webkit.org/show_bug.cgi?id=193523
Reviewed by Mark Lam.
This patch changes some macros into constants since macros are the
devil.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::caged):
* llint/LowLevelInterpreter64.asm:
2019-01-18 Matt Lewis <jlewis3@apple.com>
Unreviewed, rolling out r240160.
This broke multiple internal builds.
Reverted changeset:
"Gigacages should start allocations from a slide"
https://bugs.webkit.org/show_bug.cgi?id=193523
https://trac.webkit.org/changeset/240160
2019-01-18 Keith Miller <keith_miller@apple.com>
Gigacages should start allocations from a slide
https://bugs.webkit.org/show_bug.cgi?id=193523
Reviewed by Mark Lam.
This patch changes some macros into constants since macros are the
devil.
* llint/LowLevelInterpreter64.asm:
2019-01-17 Mark Lam <mark.lam@apple.com>
Audit bytecode fields and ensure that LLInt instructions for accessing them are appropriate.
https://bugs.webkit.org/show_bug.cgi?id=193557
<rdar://problem/47369125>
Reviewed by Yusuke Suzuki.
1. Rename some bytecode fields so that it's easier to discern whether the LLInt
is accessing them the right way:
- distinguish between targetVirtualRegister and targetLabel.
- name all StructureID fields as structureID (oldStructureID, newStructureID)
instead of structure (oldStructure, newStructure).
2. Use bitwise_cast in struct Fits when sizeof(T) == size.
This prevents potential undefined behavior issues arising from doing
assignments with reinterpret_cast'ed pointers.
3. Make Special::Pointer an unsigned type (previously int).
Make ResolveType an unsigned type (previously int).
4. In LowLevelInterpreter*.asm:
- rename the op macro argument to opcodeName or opcodeStruct respectively.
This makes it clearer which argument type the macro is working with.
- rename the name macro argument to opcodeName.
- fix operator types to match the field type being accessed. The following
may have resulted in bugs before:
1. The following should be read with getu() instead of get() because they
are unsigned ints:
OpSwitchImm::m_tableIndex
OpSwitchChar::m_tableIndex
OpGetFromArguments::m_index
OpPutToArguments::m_index
OpGetRestLength::m_numParametersToSkip
OpJneqPtr::m_specialPointer should also be read with getu() though this
wasn't a bug because it was previously an int by default, and is only
changed to an unsigned int in this patch.
2.The following should be read with loadi (not loadp) because they are of
unsigned type (not a pointer):
OpResolveScope::Metadata::m_resolveType
CodeBlock::m_numParameters (see prepareForTailCall)
3. OpPutToScope::Metadata::m_operand should be read with loadp (not loadis)
because it is a uintptr_t.
4. The following should be read with loadi (not loadis) because they are
unsigned ints:
OpNegate::Metadata::m_arithProfile + ArithProfile::m_bits
OpPutById::Metadata::m_oldStructureID
OpPutToScope::Metadata::m_getPutInfo + GetPutInfo::m_operand
These may not have manifested in bugs because the operations that follow
the load are 32-bit instructions which ignore the high word.
5. Give class GetPutInfo a default constructor so that we can use bitwise_cast
on it. Also befriend LLIntOffsetsExtractor so that we can take the offset of
m_operand in it.
* bytecode/ArithProfile.h:
* bytecode/BytecodeList.rb:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::finalizeLLIntInlineCaches):
* bytecode/Fits.h:
* bytecode/GetByIdMetadata.h:
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFromLLInt):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::clearLLIntGetByIdCache):
* bytecode/PreciseJumpTargetsInlines.h:
(JSC::jumpTargetForInstruction):
(JSC::updateStoredJumpTargetsForInstruction):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
* bytecode/SpecialPointer.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::Label::setLocation):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_compareAndJump):
(JSC::JIT::emit_compareUnsignedAndJump):
(JSC::JIT::emit_compareAndJumpSlow):
* jit/JITArithmetic32_64.cpp:
(JSC::JIT::emit_compareAndJump):
(JSC::JIT::emit_compareUnsignedAndJump):
(JSC::JIT::emit_compareAndJumpSlow):
(JSC::JIT::emitBinaryDoubleOp):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_jmp):
(JSC::JIT::emit_op_jfalse):
(JSC::JIT::emit_op_jeq_null):
(JSC::JIT::emit_op_jneq_null):
(JSC::JIT::emit_op_jneq_ptr):
(JSC::JIT::emit_op_jeq):
(JSC::JIT::emit_op_jtrue):
(JSC::JIT::emit_op_jneq):
(JSC::JIT::compileOpStrictEqJump):
(JSC::JIT::emitSlow_op_jstricteq):
(JSC::JIT::emitSlow_op_jnstricteq):
(JSC::JIT::emit_op_check_tdz):
(JSC::JIT::emitSlow_op_jeq):
(JSC::JIT::emitSlow_op_jneq):
(JSC::JIT::emit_op_profile_type):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_jmp):
(JSC::JIT::emit_op_jfalse):
(JSC::JIT::emit_op_jtrue):
(JSC::JIT::emit_op_jeq_null):
(JSC::JIT::emit_op_jneq_null):
(JSC::JIT::emit_op_jneq_ptr):
(JSC::JIT::emit_op_jeq):
(JSC::JIT::emitSlow_op_jeq):
(JSC::JIT::emit_op_jneq):
(JSC::JIT::emitSlow_op_jneq):
(JSC::JIT::compileOpStrictEqJump):
(JSC::JIT::emitSlow_op_jstricteq):
(JSC::JIT::emitSlow_op_jnstricteq):
(JSC::JIT::emit_op_check_tdz):
(JSC::JIT::emit_op_profile_type):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::setupGetByIdPrototypeCache):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
* runtime/GetPutInfo.h:
2019-01-17 Truitt Savell <tsavell@apple.com>
Unreviewed, rolling out r240124.
This commit broke an internal build.
Reverted changeset:
"SDK_VARIANT build destinations should be separate from non-
SDK_VARIANT builds"
https://bugs.webkit.org/show_bug.cgi?id=189553
https://trac.webkit.org/changeset/240124
2019-01-17 Jer Noble <jer.noble@apple.com>
SDK_VARIANT build destinations should be separate from non-SDK_VARIANT builds
https://bugs.webkit.org/show_bug.cgi?id=189553
Reviewed by Tim Horton.
* Configurations/Base.xcconfig:
* Configurations/SDKVariant.xcconfig: Added.
2019-01-17 Saam barati <sbarati@apple.com>
StringObjectUse should not be a structure check for the original string object structure
https://bugs.webkit.org/show_bug.cgi?id=193483
<rdar://problem/47280522>
Reviewed by Yusuke Suzuki.
Prior to this patch, the use kind for StringObjectUse implied that we
do a StructureCheck on the input operand for the *original* StringObject
structure. This is generally not how we use UseKinds, so it's no surprise
that this is buggy. A UseKind should map to a set of SpeculatedTypes, not an
actual set of structures. This patch changes the meaning of StringObjectUse
to mean an object where jsDynamicCast<StringObject*> would succeed.
This patch also fixes a bug that was caused by the old and weird usage of the
UseKind to mean StructureCheck. Consider a program like this:
```
S1 = Original StringObject structure
S2 = Original StringObject structure with the field "f" added
a: GetLocal()
b: CheckStructure(@a, {S2})
c: ToString(StringObject:@a)
```
According to AI, in the above program, we would exit at @c, since
StringObject:@a implies a structure check of {S1}, and the intersection
of {S1} and {S2} is {}. So, we'd convert the program to be:
```
a: GetLocal()
b: CheckStructure(@a, {S2})
c: Check(StringObject:@a)
d: Unreachable
```
However, AI would set the proof status of the StringObject:@a edge
to be proven, since the SpeculatedType for @a is SpecStringObject.
This was incorrect of AI to do because the SpeculatedType itself
didn't capture the full power of StringObjectUse. However, having
a UseKind mean CheckStructure is weird precisely because what AI was
doing is a natural fit to how we typically we think about UseKinds.
So the above program would then incorrectly be converted to this, and
we'd crash when reaching the Unreachable node:
```
a: GetLocal()
b: CheckStructure(@a, {S2})
d: Unreachable
```
This patch makes it so that StringObjectUse just means that the object that
filters through a StringObjectUse check must !!jsDynamicCast<StringObject*>.
This is now in line with all other UseKinds. It also lets us simplify a bunch
of other code that had weird checks for the StringObjectUse UseKind.
This patch also makes it so that anywhere where we used to rely on
StringObjectUse implying a structure check we actually emit an explicit
CheckStructure node.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/ExitKind.cpp:
(JSC::exitKindToString):
* bytecode/ExitKind.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGCSEPhase.cpp:
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGEdgeUsesStructure.h: Removed.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::attemptToForceStringArrayModeByToStringConversion):
(JSC::DFG::FixupPhase::addCheckStructureForOriginalStringObjectUse):
(JSC::DFG::FixupPhase::fixupToPrimitive):
(JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor):
(JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
(JSC::DFG::FixupPhase::isStringObjectUse): Deleted.
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::canOptimizeStringObjectAccess):
* dfg/DFGMayExit.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOrStringValueOf):
(JSC::DFG::SpeculativeJIT::speculateStringObject):
(JSC::DFG::SpeculativeJIT::speculateStringOrStringObject):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure): Deleted.
* dfg/DFGUseKind.h:
(JSC::DFG::alreadyChecked):
(JSC::DFG::usesStructure): Deleted.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileToStringOrCallStringConstructorOrStringValueOf):
(JSC::FTL::DFG::LowerDFGToB3::speculateStringObject):
(JSC::FTL::DFG::LowerDFGToB3::speculateStringOrStringObject):
(JSC::FTL::DFG::LowerDFGToB3::speculateStringObjectForCell):
(JSC::FTL::DFG::LowerDFGToB3::speculateStringObjectForStructureID): Deleted.
* runtime/JSType.cpp:
(WTF::printInternal):
* runtime/JSType.h:
* runtime/StringObject.h:
(JSC::StringObject::createStructure):
* runtime/StringPrototype.h:
2019-01-17 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Add generateHeapSnapshotForGCDebugging function to dump GCDebugging data
https://bugs.webkit.org/show_bug.cgi?id=193526
Reviewed by Michael Saboff.
This patch adds generateHeapSnapshotForGCDebugging to JSC shell to dump heap snapshot JSON string with GCDebugging option.
GCDebuggingSnapshot mode is slightly different from InspectorSnapshot in terms of both the output data and the behavior.
It always takes full snapshot, and it reports internal data too. This is useful to view the live heap objects after running
the code. Also, generateHeapSnapshotForGCDebugging returns String instead of parsing it to JSObject internally by calling
JSON.parse. If we convert the String to bunch of objects by using JSON.parse, it is difficult to call generateHeapSnapshotForGCDebugging
multiple times for debugging. Currently, it only generates a large string, which is easily distinguishable in the heap inspector tool.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionGenerateHeapSnapshotForGCDebugging):
2019-01-17 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] ToThis omission in DFGByteCodeParser is wrong
https://bugs.webkit.org/show_bug.cgi?id=193513
<rdar://problem/45842236>
Reviewed by Saam Barati.
DFGByteCodeParser omitted ToThis node when we have `ToThis(ToThis(value))`. This semantics is wrong if ToThis has different semantics
in the sloppy mode and the strict mode. If we convert `ToThisInSloppyMode(ToThisInStrictMode(boolean))` to `ToThisInStrictMode(boolean)`,
we get boolean instead of BooleanObject.
This optimization is introduced more than 7 years ago, and from that, we have several optimizations that can remove such ToThis nodes
in BytecodeParser, AI, and Fixup. Furthermore, this optimization is simply wrong since `toThis()` function of JSCell can be defined
as they want. Before ensuring all the toThis function is safe, we should not fold `ToThis(ToThis(value))` => `ToThis(value)`.
This patch just removes the problematic optimization. The performance numbers look neutral.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
2019-01-16 Mark Lam <mark.lam@apple.com>
Refactor new bytecode structs so that the fields are prefixed with "m_".
https://bugs.webkit.org/show_bug.cgi?id=193467
Reviewed by Saam Barati and Tadeu Zagallo.
This makes it easier to do a manual audit of type correctness of the LLInt
instructions used to access these fields. Without this change, it would be
difficult (and error prone) to distinguish the difference between field names and
macro variables. This audit will be done after this patch lands.
* bytecode/BytecodeGeneratorification.cpp:
(JSC::BytecodeGeneratorification::BytecodeGeneratorification):
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFromLLInt):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::finalizeLLIntInlineCaches):
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffset):
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
(JSC::CodeBlock::getArrayProfile):
(JSC::CodeBlock::notifyLexicalBindingShadowing):
(JSC::CodeBlock::tryGetValueProfileForBytecodeOffset):
(JSC::CodeBlock::arithProfileForPC):
(JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
* bytecode/CodeBlockInlines.h:
(JSC::CodeBlock::forEachValueProfile):
(JSC::CodeBlock::forEachArrayProfile):
(JSC::CodeBlock::forEachArrayAllocationProfile):
(JSC::CodeBlock::forEachObjectAllocationProfile):
(JSC::CodeBlock::forEachLLIntCallLinkInfo):
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFromLLInt):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::clearLLIntGetByIdCache):
* bytecode/PreciseJumpTargetsInlines.h:
(JSC::jumpTargetForInstruction):
(JSC::extractStoredJumpTargetsForInstruction):
(JSC::updateStoredJumpTargetsForInstruction):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::dumpLineColumnEntry):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::fuseCompareAndJump):
(JSC::BytecodeGenerator::fuseTestAndJmp):
(JSC::BytecodeGenerator::emitEqualityOp):
(JSC::BytecodeGenerator::endSwitch):
(JSC::StructureForInContext::finalize):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleCall):
(JSC::DFG::ByteCodeParser::handleVarargsCall):
(JSC::DFG::ByteCodeParser::parseGetById):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::handlePutByVal):
(JSC::DFG::ByteCodeParser::handlePutAccessorById):
(JSC::DFG::ByteCodeParser::handlePutAccessorByVal):
(JSC::DFG::ByteCodeParser::handleNewFunc):
(JSC::DFG::ByteCodeParser::handleNewFuncExp):
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareCatchOSREntry):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
* generator/Argument.rb:
* generator/Metadata.rb:
* generator/Opcode.rb:
* jit/JIT.h:
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_unsigned):
(JSC::JIT::emit_compareAndJump):
(JSC::JIT::emit_compareUnsignedAndJump):
(JSC::JIT::emit_compareUnsigned):
(JSC::JIT::emit_compareAndJumpSlow):
(JSC::JIT::emit_op_inc):
(JSC::JIT::emit_op_dec):
(JSC::JIT::emit_op_mod):
(JSC::JIT::emit_op_negate):
(JSC::JIT::emitBitBinaryOpFastPath):
(JSC::JIT::emit_op_bitnot):
(JSC::JIT::emitRightShiftFastPath):
(JSC::JIT::emit_op_add):
(JSC::JIT::emitMathICFast):
(JSC::JIT::emitMathICSlow):
(JSC::JIT::emit_op_div):
(JSC::JIT::emit_op_mul):
(JSC::JIT::emit_op_sub):
* jit/JITArithmetic32_64.cpp:
(JSC::JIT::emit_compareAndJump):
(JSC::JIT::emit_compareUnsignedAndJump):
(JSC::JIT::emit_compareUnsigned):
(JSC::JIT::emit_compareAndJumpSlow):
(JSC::JIT::emit_op_unsigned):
(JSC::JIT::emit_op_inc):
(JSC::JIT::emit_op_dec):
(JSC::JIT::emitBinaryDoubleOp):
(JSC::JIT::emit_op_mod):
* jit/JITCall.cpp:
(JSC::JIT::emitPutCallResult):
(JSC::JIT::compileSetupFrame):
(JSC::JIT::compileCallEvalSlowCase):
(JSC::JIT::compileTailCall):
(JSC::JIT::compileOpCall):
* jit/JITCall32_64.cpp:
(JSC::JIT::emitPutCallResult):
(JSC::JIT::emit_op_ret):
(JSC::JIT::compileSetupFrame):
(JSC::JIT::compileCallEvalSlowCase):
(JSC::JIT::compileOpCall):
* jit/JITInlines.h:
(JSC::JIT::emitValueProfilingSiteIfProfiledOpcode):
(JSC::JIT::emitValueProfilingSite):
(JSC::JIT::copiedGetPutInfo):
(JSC::JIT::copiedArithProfile):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_mov):
(JSC::JIT::emit_op_end):
(JSC::JIT::emit_op_jmp):
(JSC::JIT::emit_op_new_object):
(JSC::JIT::emitSlow_op_new_object):
(JSC::JIT::emit_op_overrides_has_instance):
(JSC::JIT::emit_op_instanceof):
(JSC::JIT::emitSlow_op_instanceof):
(JSC::JIT::emit_op_is_empty):
(JSC::JIT::emit_op_is_undefined):
(JSC::JIT::emit_op_is_undefined_or_null):
(JSC::JIT::emit_op_is_boolean):
(JSC::JIT::emit_op_is_number):
(JSC::JIT::emit_op_is_cell_with_type):
(JSC::JIT::emit_op_is_object):
(JSC::JIT::emit_op_ret):
(JSC::JIT::emit_op_to_primitive):
(JSC::JIT::emit_op_set_function_name):
(JSC::JIT::emit_op_not):
(JSC::JIT::emit_op_jfalse):
(JSC::JIT::emit_op_jeq_null):
(JSC::JIT::emit_op_jneq_null):
(JSC::JIT::emit_op_jneq_ptr):
(JSC::JIT::emit_op_eq):
(JSC::JIT::emit_op_jeq):
(JSC::JIT::emit_op_jtrue):
(JSC::JIT::emit_op_neq):
(JSC::JIT::emit_op_jneq):
(JSC::JIT::emit_op_throw):
(JSC::JIT::compileOpStrictEq):
(JSC::JIT::compileOpStrictEqJump):
(JSC::JIT::emitSlow_op_jstricteq):
(JSC::JIT::emitSlow_op_jnstricteq):
(JSC::JIT::emit_op_to_number):
(JSC::JIT::emit_op_to_string):
(JSC::JIT::emit_op_to_object):
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_get_parent_scope):
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emit_op_switch_char):
(JSC::JIT::emit_op_switch_string):
(JSC::JIT::emit_op_debug):
(JSC::JIT::emit_op_eq_null):
(JSC::JIT::emit_op_neq_null):
(JSC::JIT::emit_op_get_scope):
(JSC::JIT::emit_op_to_this):
(JSC::JIT::emit_op_create_this):
(JSC::JIT::emit_op_check_tdz):
(JSC::JIT::emitSlow_op_eq):
(JSC::JIT::emitSlow_op_neq):
(JSC::JIT::emitSlow_op_jeq):
(JSC::JIT::emitSlow_op_jneq):
(JSC::JIT::emitSlow_op_instanceof_custom):
(JSC::JIT::emit_op_new_regexp):
(JSC::JIT::emitNewFuncCommon):
(JSC::JIT::emitNewFuncExprCommon):
(JSC::JIT::emit_op_new_array):
(JSC::JIT::emit_op_new_array_with_size):
(JSC::JIT::emit_op_has_structure_property):
(JSC::JIT::emit_op_has_indexed_property):
(JSC::JIT::emitSlow_op_has_indexed_property):
(JSC::JIT::emit_op_get_direct_pname):
(JSC::JIT::emit_op_enumerator_structure_pname):
(JSC::JIT::emit_op_enumerator_generic_pname):
(JSC::JIT::emit_op_profile_type):
(JSC::JIT::emit_op_log_shadow_chicken_prologue):
(JSC::JIT::emit_op_log_shadow_chicken_tail):
(JSC::JIT::emit_op_profile_control_flow):
(JSC::JIT::emit_op_argument_count):
(JSC::JIT::emit_op_get_rest_length):
(JSC::JIT::emit_op_get_argument):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_mov):
(JSC::JIT::emit_op_end):
(JSC::JIT::emit_op_jmp):
(JSC::JIT::emit_op_new_object):
(JSC::JIT::emitSlow_op_new_object):
(JSC::JIT::emit_op_overrides_has_instance):
(JSC::JIT::emit_op_instanceof):
(JSC::JIT::emitSlow_op_instanceof):
(JSC::JIT::emitSlow_op_instanceof_custom):
(JSC::JIT::emit_op_is_empty):
(JSC::JIT::emit_op_is_undefined):
(JSC::JIT::emit_op_is_undefined_or_null):
(JSC::JIT::emit_op_is_boolean):
(JSC::JIT::emit_op_is_number):
(JSC::JIT::emit_op_is_cell_with_type):
(JSC::JIT::emit_op_is_object):
(JSC::JIT::emit_op_to_primitive):
(JSC::JIT::emit_op_set_function_name):
(JSC::JIT::emit_op_not):
(JSC::JIT::emit_op_jfalse):
(JSC::JIT::emit_op_jtrue):
(JSC::JIT::emit_op_jeq_null):
(JSC::JIT::emit_op_jneq_null):
(JSC::JIT::emit_op_jneq_ptr):
(JSC::JIT::emit_op_eq):
(JSC::JIT::emitSlow_op_eq):
(JSC::JIT::emit_op_jeq):
(JSC::JIT::emitSlow_op_jeq):
(JSC::JIT::emit_op_neq):
(JSC::JIT::emitSlow_op_neq):
(JSC::JIT::emit_op_jneq):
(JSC::JIT::emitSlow_op_jneq):
(JSC::JIT::compileOpStrictEq):
(JSC::JIT::compileOpStrictEqJump):
(JSC::JIT::emitSlow_op_jstricteq):
(JSC::JIT::emitSlow_op_jnstricteq):
(JSC::JIT::emit_op_eq_null):
(JSC::JIT::emit_op_neq_null):
(JSC::JIT::emit_op_throw):
(JSC::JIT::emit_op_to_number):
(JSC::JIT::emit_op_to_string):
(JSC::JIT::emit_op_to_object):
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_get_parent_scope):
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emit_op_switch_char):
(JSC::JIT::emit_op_switch_string):
(JSC::JIT::emit_op_debug):
(JSC::JIT::emit_op_get_scope):
(JSC::JIT::emit_op_create_this):
(JSC::JIT::emit_op_to_this):
(JSC::JIT::emit_op_check_tdz):
(JSC::JIT::emit_op_has_structure_property):
(JSC::JIT::emit_op_has_indexed_property):
(JSC::JIT::emitSlow_op_has_indexed_property):
(JSC::JIT::emit_op_get_direct_pname):
(JSC::JIT::emit_op_enumerator_structure_pname):
(JSC::JIT::emit_op_enumerator_generic_pname):
(JSC::JIT::emit_op_profile_type):
(JSC::JIT::emit_op_log_shadow_chicken_prologue):
(JSC::JIT::emit_op_log_shadow_chicken_tail):
* jit/JITOperations.cpp:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emitGetByValWithCachedId):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emit_op_put_by_val):
(JSC::JIT::emitGenericContiguousPutByVal):
(JSC::JIT::emitArrayStoragePutByVal):
(JSC::JIT::emitPutByValWithCachedId):
(JSC::JIT::emitSlow_op_put_by_val):
(JSC::JIT::emit_op_put_getter_by_id):
(JSC::JIT::emit_op_put_setter_by_id):
(JSC::JIT::emit_op_put_getter_setter_by_id):
(JSC::JIT::emit_op_put_getter_by_val):
(JSC::JIT::emit_op_put_setter_by_val):
(JSC::JIT::emit_op_del_by_id):
(JSC::JIT::emit_op_del_by_val):
(JSC::JIT::emit_op_try_get_by_id):
(JSC::JIT::emitSlow_op_try_get_by_id):
(JSC::JIT::emit_op_get_by_id_direct):
(JSC::JIT::emitSlow_op_get_by_id_direct):
(JSC::JIT::emit_op_get_by_id):
(JSC::JIT::emit_op_get_by_id_with_this):
(JSC::JIT::emitSlow_op_get_by_id):
(JSC::JIT::emitSlow_op_get_by_id_with_this):
(JSC::JIT::emit_op_put_by_id):
(JSC::JIT::emitSlow_op_put_by_id):
(JSC::JIT::emit_op_in_by_id):
(JSC::JIT::emitSlow_op_in_by_id):
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emitSlow_op_get_from_scope):
(JSC::JIT::emit_op_put_to_scope):
(JSC::JIT::emit_op_get_from_arguments):
(JSC::JIT::emit_op_put_to_arguments):
(JSC::JIT::emitIntTypedArrayPutByVal):
(JSC::JIT::emitFloatTypedArrayPutByVal):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_put_getter_by_id):
(JSC::JIT::emit_op_put_setter_by_id):
(JSC::JIT::emit_op_put_getter_setter_by_id):
(JSC::JIT::emit_op_put_getter_by_val):
(JSC::JIT::emit_op_put_setter_by_val):
(JSC::JIT::emit_op_del_by_id):
(JSC::JIT::emit_op_del_by_val):
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emitGetByValWithCachedId):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emit_op_put_by_val):
(JSC::JIT::emitGenericContiguousPutByVal):
(JSC::JIT::emitArrayStoragePutByVal):
(JSC::JIT::emitPutByValWithCachedId):
(JSC::JIT::emitSlow_op_put_by_val):
(JSC::JIT::emit_op_try_get_by_id):
(JSC::JIT::emitSlow_op_try_get_by_id):
(JSC::JIT::emit_op_get_by_id_direct):
(JSC::JIT::emitSlow_op_get_by_id_direct):
(JSC::JIT::emit_op_get_by_id):
(JSC::JIT::emitSlow_op_get_by_id):
(JSC::JIT::emit_op_get_by_id_with_this):
(JSC::JIT::emitSlow_op_get_by_id_with_this):
(JSC::JIT::emit_op_put_by_id):
(JSC::JIT::emitSlow_op_put_by_id):
(JSC::JIT::emit_op_in_by_id):
(JSC::JIT::emitSlow_op_in_by_id):
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emitSlow_op_get_from_scope):
(JSC::JIT::emit_op_put_to_scope):
(JSC::JIT::emit_op_get_from_arguments):
(JSC::JIT::emit_op_put_to_arguments):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::setupGetByIdPrototypeCache):
(JSC::LLInt::getByVal):
(JSC::LLInt::genericCall):
(JSC::LLInt::varargsSetup):
(JSC::LLInt::commonCallEval):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
(JSC::updateArithProfileForUnaryArithOp):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
(JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
2019-01-15 Mark Lam <mark.lam@apple.com>
JSFunction::canUseAllocationProfile() should account for builtin functions with no own prototypes.
https://bugs.webkit.org/show_bug.cgi?id=193423
<rdar://problem/46209355>
Reviewed by Saam Barati.
JSFunction::canUseAllocationProfile() should return false for most builtins
because the majority of them have no prototype property. The only exception to
this is the few builtin functions that are explicitly used as constructors.
For these builtin constructors, JSFunction::canUseAllocationProfile() should also
return false if the prototype property is a getter or custom getter because
getting the prototype would then be effectful.
* dfg/DFGOperations.cpp:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSFunctionInlines.h:
(JSC::JSFunction::canUseAllocationProfile):
* runtime/PropertySlot.h:
2019-01-15 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Use KnownStringUse for GetByVal(Array::String) since AI would offer wider type information and offer non-string type after removing Check(String)
https://bugs.webkit.org/show_bug.cgi?id=193438
<rdar://problem/45581249>
Reviewed by Saam Barati and Keith Miller.
GetByVal(Array::String) emits Check(String) before that. But AI can broaden type constraint in the second run.
After the first run removes Check(String), it would happen that AI starts saying the type of 1st child is not String.
To claim that it *is* a String type, we should use KnownStringUse here.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode): StringCharAt and GetByVal(Array::String) share the underlying compiler code. We should
change StringUse => KnownStringUse for StringCharAt too. And StringCharAt and StringCharCodeAt potentially have the same
problem. This patch fixes it too.
* dfg/DFGSSALoweringPhase.cpp:
(JSC::DFG::SSALoweringPhase::lowerBoundsCheck):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt):
2019-01-15 Saam Barati <sbarati@apple.com>
Try ripping out inferred types because it might be a performance improvement
https://bugs.webkit.org/show_bug.cgi?id=190906
Reviewed by Yusuke Suzuki.
This patch removes inferred types from JSC. Initial evidence shows that
this might be around a ~1% speedup on Speedometer2 and JetStream2.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateImpl):
* bytecode/Fits.h:
* bytecode/PutByIdFlags.cpp:
(WTF::printInternal):
* bytecode/PutByIdFlags.h:
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
(JSC::PutByIdStatus::computeForStubInfo):
(JSC::PutByIdStatus::computeFor):
* bytecode/PutByIdVariant.cpp:
(JSC::PutByIdVariant::operator=):
(JSC::PutByIdVariant::replace):
(JSC::PutByIdVariant::transition):
(JSC::PutByIdVariant::setter):
(JSC::PutByIdVariant::attemptToMerge):
(JSC::PutByIdVariant::dumpInContext const):
* bytecode/PutByIdVariant.h:
(JSC::PutByIdVariant::requiredType const): Deleted.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::isType const): Deleted.
* dfg/DFGAbstractValue.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleGetByOffset):
(JSC::DFG::ByteCodeParser::handlePutByOffset):
(JSC::DFG::ByteCodeParser::load):
(JSC::DFG::ByteCodeParser::store):
(JSC::DFG::ByteCodeParser::handlePutById):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
(JSC::DFG::ConstantFoldingPhase::emitGetByOffset):
(JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
* dfg/DFGDesiredInferredType.h: Removed.
* dfg/DFGDesiredWatchpoints.cpp:
(JSC::DFG::DesiredWatchpoints::reallyAdd):
(JSC::DFG::DesiredWatchpoints::areStillValid const):
(JSC::DFG::DesiredWatchpoints::dumpInContext const):
(JSC::DFG::InferredTypeAdaptor::add): Deleted.
* dfg/DFGDesiredWatchpoints.h:
(JSC::DFG::DesiredWatchpoints::isWatched):
(JSC::DFG::InferredTypeAdaptor::hasBeenInvalidated): Deleted.
(JSC::DFG::InferredTypeAdaptor::dumpInContext): Deleted.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
(JSC::DFG::Graph::inferredValueForProperty):
(JSC::DFG::Graph::inferredTypeFor): Deleted.
* dfg/DFGGraph.h:
(JSC::DFG::Graph::registerInferredType): Deleted.
(JSC::DFG::Graph::inferredTypeForProperty): Deleted.
* dfg/DFGInferredTypeCheck.cpp: Removed.
* dfg/DFGInferredTypeCheck.h: Removed.
* dfg/DFGNode.h:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset):
(JSC::FTL::DFG::LowerDFGToB3::checkInferredType): Deleted.
* generator/DSL.rb:
* heap/Heap.cpp:
(JSC::Heap::finalizeUnconditionalFinalizers):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::branchIfNotType): Deleted.
* jit/AssemblyHelpers.h:
* jit/Repatch.cpp:
(JSC::tryCachePutByID):
* llint/LLIntOffsetsExtractor.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/InferredStructure.cpp:
(JSC::InferredStructure::InferredStructure): Deleted.
* runtime/InferredStructure.h:
(): Deleted.
* runtime/InferredStructureWatchpoint.cpp:
(JSC::InferredStructureWatchpoint::fireInternal): Deleted.
* runtime/InferredType.cpp: Removed.
* runtime/InferredType.h: Removed.
* runtime/InferredTypeInlines.h: Removed.
* runtime/InferredTypeTable.cpp: Removed.
* runtime/InferredTypeTable.h: Removed.
* runtime/JSObjectInlines.h:
(JSC::JSObject::putDirectInternal):
* runtime/Structure.cpp:
(JSC::Structure::materializePropertyTable):
(JSC::Structure::addNewPropertyTransition):
(JSC::Structure::removePropertyTransition):
(JSC::Structure::willStoreValueSlow):
(JSC::Structure::visitChildren):
* runtime/Structure.h:
(JSC::PropertyMapEntry::PropertyMapEntry):
* runtime/StructureInlines.h:
(JSC::Structure::get):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2019-01-15 Tomas Popela <tpopela@redhat.com>
Unreviewed: Fix the -Wformat compiler warnings
* jsc.cpp:
(jscmain):
2019-01-15 Caio Lima <ticaiolima@gmail.com>
DFGByteCodeParser rules for bitwise operations should consider type of their operands
https://bugs.webkit.org/show_bug.cgi?id=192966
Reviewed by Yusuke Suzuki.
This patch is changing the logic how we lower bitwise operations, to
consider only the type of input nodes and fix them during FixupPhase,
if necessary. We are also changing the prediction propagation rules
for ValueBitOp to use `getHeapPrediction()`.
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo):
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasInt32Result):
(JSC::DFG::Node::hasNumberOrAnyIntResult):
(JSC::DFG::Node::hasHeapPrediction):
* dfg/DFGPredictionPropagationPhase.cpp:
2019-01-15 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Generate the DOMDebugger domain for Augmenting Agents (ObjC protocol)
https://bugs.webkit.org/show_bug.cgi?id=193409
<rdar://problem/44349411>
Reviewed by Devin Rousso.
* inspector/scripts/codegen/objc_generator.py:
(ObjCGenerator):
Generate DOMDebugger domain ObjC interfaces.
2019-01-15 Devin Rousso <drousso@apple.com>
Web Inspector: Audit: create new IDL type for exposing special functionality in test context
https://bugs.webkit.org/show_bug.cgi?id=193149
<rdar://problem/46801218>
Reviewed by Joseph Pecoraro.
Create a new `AuditAgent` (and various subclasses for different inspection targets)
* inspector/protocol/Audit.json: Added.
Add a `run` command that is a simpler version of `Runtime.evaluate`, except that it expects
a function string instead of an arbitrary JavaScript expression.
Add `setup` and `teardown` commands that create a JavaScript object that will be passed in
to the test as an argument. Keep this object alive so that tests can add to the object and
have later tests use what was added.
* inspector/agents/InspectorAuditAgent.h: Added.
* inspector/agents/InspectorAuditAgent.cpp: Added.
(Inspector::InspectorAuditAgent::InspectorAuditAgent):
(Inspector::InspectorAuditAgent::didCreateFrontendAndBackend):
(Inspector::InspectorAuditAgent::willDestroyFrontendAndBackend):
(Inspector::InspectorAuditAgent::setup):
(Inspector::InspectorAuditAgent::run):
(Inspector::InspectorAuditAgent::teardown):
(Inspector::InspectorAuditAgent::hasActiveAudit):
(Inspector::InspectorAuditAgent::populateAuditObject):
* inspector/agents/JSGlobalObjectAuditAgent.h: Added.
* inspector/agents/JSGlobalObjectAuditAgent.cpp: Added.
(Inspector::JSGlobalObjectAuditAgent::JSGlobalObjectAuditAgent):
(Inspector::JSGlobalObjectAuditAgent::injectedScriptForEval):
* inspector/JSGlobalObjectInspectorController.h:
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
(Inspector::JSGlobalObjectInspectorController::connectFrontend):
(Inspector::JSGlobalObjectInspectorController::jsAgentContext): Added.
(Inspector::JSGlobalObjectInspectorController::createLazyAgents): Added.
* inspector/InjectedScript.h:
* inspector/InjectedScript.cpp:
(Inspector::InjectedScript::execute): Added.
(Inspector::InjectedScript::arrayFromVector): Added.
Create a version of `evaluate` that accepts a list of values to be passed in as arguments
to the function that was created by the `eval` of the given `functionString`.
* inspector/InjectedScriptSource.js:
(InjectedScript.prototype.execute): Added.
(InjectedScript.prototype.evaluate):
(InjectedScript.prototype.evaluateOnCallFrame):
(InjectedScript.prototype._evaluateAndWrap):
(InjectedScript.prototype._wrapAndSaveCall): Added.
(InjectedScript.prototype._wrapCall): Added.
(InjectedScript.prototype._evaluateOn):
Refactor the `eval` and `saveResult` logic to allow for more flexibility for other callers.
* CMakeLists.txt:
* DerivedSources-input.xcfilelist:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* UnifiedSources-input.xcfilelist:
2019-01-14 Michael Saboff <msaboff@apple.com>
Add option to JSC to dump memory footprint on script completion
https://bugs.webkit.org/show_bug.cgi?id=193422
Reviewed by Mark Lam.
Added the --footprint option to dump peak and current memory usage. This uses the same
OS calls added in r2362362.
* jsc.cpp:
(printUsageStatement):
(CommandLine::parseArguments):
(jscmain):
2019-01-14 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] AI should check the given constant's array type when folding GetByVal into constant
https://bugs.webkit.org/show_bug.cgi?id=193413
<rdar://problem/46092389>
Reviewed by Keith Miller.
If GetByVal's DFG::ArrayMode's type is Array::Double, we expect that the result of GetByVal is Double, since we already performed CheckStructure or CheckArray
to ensure this array type. But this assumption on the given value becomes wrong in AI, since CheckStructure may not perform filtering. And the proven AbstractValue
in GetByVal would not be expected one.
We have the graph before performing constant folding.
53:<!0:-> GetLocal(Check:Untyped:@77, JS|MustGen|UseAsOther, Array, arg2(C<Array>/FlushedCell), R:Stack(7), bc#37, ExitValid) predicting Array
54:< 1:-> JSConstant(JS|PureNum|UseAsOther|UseAsInt|ReallyWantsInt, BoolInt32, Int32: 0, bc#37, ExitValid)
93:<!0:-> CheckStructure(Cell:@53, MustGen, [%C7:Array], R:JSCell_structureID, Exits, bc#37, ExitValid)
94:< 1:-> GetButterfly(Check:Cell:@53, Storage|PureInt, R:JSObject_butterfly, Exits, bc#37, ExitValid)
55:<!0:-> GetByVal(Check:KnownCell:@53, Check:Int32:@54, Check:Untyped:@94, Double|MustGen|VarArgs|PureInt, AnyIntAsDouble|NonIntAsdouble, Double+OriginalCopyOnWriteArray+SaneChain+AsIs+Read, R:Butterfly_publicLength,IndexedDoubleProperties, Exits, bc#37, ExitValid) predicting StringIdent|NonIntAsdouble
And 53 is converted to JSConstant in the constant folding. It leads to constant folding attempt in GetByVal.
53:< 1:-> JSConstant(JS|UseAsOther, Array, Weak:Object: 0x117fb4370 with butterfly 0x8000e4050 (Structure %BV:Array), StructureID: 104, bc#37, ExitValid)
54:< 1:-> JSConstant(JS|PureNum|UseAsOther|UseAsInt|ReallyWantsInt, BoolInt32, Int32: 0, bc#37, ExitValid)
93:<!0:-> CheckStructure(Cell:@53, MustGen, [%C7:Array], R:JSCell_structureID, Exits, bc#37, ExitValid)
94:< 1:-> GetButterfly(Check:Cell:@53, Storage|PureInt, R:JSObject_butterfly, Exits, bc#37, ExitValid)
55:<!0:-> GetByVal(Check:KnownCell:@53, Check:Int32:@54, Check:Untyped:@94, Double|MustGen|VarArgs|PureInt, AnyIntAsDouble|NonIntAsdouble, Double+OriginalCopyOnWriteArray+SaneChain+AsIs+Read, R:Butterfly_publicLength,IndexedDoubleProperties, Exits, bc#37, ExitValid) predicting StringIdent|NonIntAsdouble
GetByVal gets constant Array from @53, and attempt to perform constant folding by leverating CoW state: if the given array's butterfly is CoW and we performed CoW array check for this GetByVal, the array would not be changed as long as the check works.
However, CheckStructure for @53 does not filter anything at AI. So, if @53 is CopyOnWrite | Contiguous array (not CopyOnWrite | Double array!), GetByVal will get a JSValue. But it does not meet the requirement of GetByVal since it has Double Array mode, and says it returns Double.
Here, CheckStructure is valid because structure of the constant object would be changed. What we should do is additional CoW & ArrayShape check in GetByVal when folding since this node leverages CoW's interesting feature,
"If CoW array check (CheckStructure etc.) is emitted by GetByVal's DFG::ArrayMode, the content is not changed from the creation!".
This patch adds ArrayShape check in addition to CoW status check in GetByVal.
Unfortunately, this crash is very flaky. In the above case, if @53 stays GetLocal after the constant folding phase, this issue does not occur. We can see this crash in r238109, but it is really hard to reproduce it in the current ToT.
I verified this fix works in r238109 with the attached test.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::fixTypeForRepresentation):
2019-01-14 Caio Lima <ticaiolima@gmail.com>
[BigInt] Literal parsing is crashing when used inside a Object Literal
https://bugs.webkit.org/show_bug.cgi?id=193404
Reviewed by Yusuke Suzuki.
Former implementation was relying into token.m_data.radix after the
call of `next()` into Parser.cpp. This is not safe because next
clobbers token.m_data.radix in some cases (e.g is CLOSEBRACE).
Now we get radix value before calling `next()` into parser and store
in a local variable.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parsePrimaryExpression):
2019-01-14 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Do not use asArrayModes() with Structures because it discards TypedArray information
https://bugs.webkit.org/show_bug.cgi?id=193372
Reviewed by Saam Barati.
When RegisteredStructureSet is filtered with AbstractValue, we use structure, SpeculationType, and ArrayModes.
However, we use asArrayModes() function with IndexingMode to compute the ArrayModes in AbstractValue. This is
wrong since this discards TypedArray ArrayModes. As a result, if RegisteredStructureSet with TypedArrays is
filtered with ArrayModes of AbstractValue populated from TypedArrays, we filter all the structures out since
AbstractValue's ArrayModes become NonArray, which is wrong with the TypedArrays' ArrayModes. This leads to
incorrect FTL code generation with MultiGetByOffset etc. nodes because,
1. AI think that this MultiGetByOffset never succeeds since all the values of RegisteredStructureSet are filtered out by the AbstractValue.
2. AI says the state of MultiGetByOffset is invalid since AI think it never succeeds.
3. So subsequent code becomes FTL crash code since AI think the execution should do OSR exit.
4. Then, FTL emits the code for MultiGetByOffset, and emits crash after that.
5. But in reality, the incoming value can match to the one of the RegisteredStructureSet value since (1)'s structures are incorrectly filtered by the incorrect ArrayModes.
6. Then, the execution goes on, and falls into the FTL crash.
This patch fixes the incorrect ArrayModes calculation by the following changes
1. Rename asArrayModes to asArrayModesIgnoringTypedArrays.
2. Fix incorrect asArrayModesIgnoringTypedArrays use in our code. Use arrayModesFromStructure instead.
3. Fix OSR exit code which stores incorrect ArrayModes to the profiles.
* bytecode/ArrayProfile.cpp:
(JSC::dumpArrayModes):
(JSC::ArrayProfile::computeUpdatedPrediction):
* bytecode/ArrayProfile.h:
(JSC::asArrayModesIgnoringTypedArrays):
(JSC::arrayModesFromStructure):
(JSC::arrayModesIncludeIgnoringTypedArrays):
(JSC::shouldUseSlowPutArrayStorage):
(JSC::shouldUseFastArrayStorage):
(JSC::shouldUseContiguous):
(JSC::shouldUseDouble):
(JSC::shouldUseInt32):
(JSC::asArrayModes): Deleted.
(JSC::arrayModeFromStructure): Deleted.
(JSC::arrayModesInclude): Deleted.
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::observeTransitions):
(JSC::DFG::AbstractValue::set):
(JSC::DFG::AbstractValue::mergeOSREntryValue):
(JSC::DFG::AbstractValue::contains const):
* dfg/DFGAbstractValue.h:
(JSC::DFG::AbstractValue::observeTransition):
(JSC::DFG::AbstractValue::validate const):
(JSC::DFG::AbstractValue::observeIndexingTypeTransition):
* dfg/DFGArrayMode.cpp:
(JSC::DFG::ArrayMode::fromObserved):
(JSC::DFG::ArrayMode::alreadyChecked const):
* dfg/DFGArrayMode.h:
(JSC::DFG::ArrayMode::structureWouldPassArrayModeFiltering):
(JSC::DFG::ArrayMode::arrayModesThatPassFiltering const):
(JSC::DFG::ArrayMode::arrayModesWithIndexingShape const):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::executeOSRExit):
(JSC::DFG::OSRExit::compileExit):
* dfg/DFGRegisteredStructureSet.cpp:
(JSC::DFG::RegisteredStructureSet::filterArrayModes):
(JSC::DFG::RegisteredStructureSet::arrayModesFromStructures const):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* jit/JITInlines.h:
(JSC::JIT::chooseArrayMode):
(JSC::arrayProfileSaw): Deleted.
* runtime/JSType.h:
(JSC::isTypedArrayType):
2019-01-14 Mark Lam <mark.lam@apple.com>
Re-enable ability to build --cloop builds.
https://bugs.webkit.org/show_bug.cgi?id=192955
<rdar://problem/46882363>
Reviewed by Saam barati and Keith Miller.
* Configurations/FeatureDefines.xcconfig:
2019-01-14 Mark Lam <mark.lam@apple.com>
Fix all CLoop JSC test failures (including some LLInt bugs due to recent bytecode format change).
https://bugs.webkit.org/show_bug.cgi?id=193402
<rdar://problem/46012309>
Reviewed by Keith Miller.
The CLoop builds via build-jsc were previously completely disabled after our
change to enable ASM LLInt build without the JIT. As a result, JSC tests have
regressed on CLoop builds. The CLoop builds and tests will be re-enabled when
the fix for https://bugs.webkit.org/show_bug.cgi?id=192955 lands. This patch
fixes all the regressions (and some old bugs) so that the CLoop test bots won't
be red when CLoop build gets re-enabled.
In this patch, we do the following:
1. Change CLoopStack::grow() to set the new CLoop stack top at the maximum
allocated capacity (after discounting the reserved zone) as opposed to setting
it only at the level that the client requested.
This fixes a small performance bug that I happened to noticed when I was
debugging a stack issue. It does not affect correctness.
2. In LowLevelInterpreter32_64.asm:
1. Fix loadConstantOrVariableTag() to use subi for computing the constant
index because the VirtualRegister offset and FirstConstantRegisterIndex
values it is operating on are both signed ints. This is just to be
pedantic. The previous use of subu will still produce a correct value.
2. Fix llintOpWithReturn() to use getu (instead of get) for reading
OpIsCellWithType::type because it is of type JSType, which is a uint8_t.
3. Fix llintOpWithMetadata() to use loadis for loading
OpGetById::Metadata::modeMetadata.protoLoadMode.cachedOffset[t5] because it
is of type PropertyOffset, which is a signed int.
4. Fix commonCallOp() to use getu for loading fields argv and argc because they
are of type unsigned for OpCall, OpConstruct, and OpTailCall, which are the
clients of commonCallOp.
5. Fix llintOpWithMetadata() and getClosureVar() to use loadp for loading
OpGetFromScope::Metadata::operand because it is of type uintptr_t.
3. In LowLevelInterpreter64.asm:
1. Fix llintOpWithReturn() to use getu for reading OpIsCellWithType::type
because it is of type JSType, which is a uint8_t.
2. Fix llintOpWithMetadata() to use loadi for loading
OpGetById::Metadata::modeMetadata.protoLoadMode.structure[t2] because it is
of type StructureID, which is a uint32_t.
Fix llintOpWithMetadata() to use loadis for loading
OpGetById::Metadata::modeMetadata.protoLoadMode.cachedOffset[t2] because it
is of type PropertyOffset, which is a signed int.
3. commonOp() should reload the metadataTable for op_catch because unlike
for the ASM LLInt, the exception unwinding code is not able to restore
"callee saved registers" for the CLoop interpreter because the CLoop uses
pseudo-registers (see the CLoopRegister class).
This was the source of many exotic Cloop failures after the bytecode format
change (which introduced the metadataTable callee saved register). Hence,
we fix it by reloading metadataTable's value on re-entry via op_catch for
exception handling. We already take care of restoring it in op_ret.
4. Fix llintOpWithMetadata() and getClosureVar() to use loadp for loading
OpGetFromScope::Metadata::operand because it is of type uintptr_t.
4. In LowLevelInterpreter.asm:
Fix metadata() to use loadi for loading metadataTable offsets because they are
of type unsigned. This was also a source of many exotic CLoop test failures.
5. Change CLoopRegister into a class with a uintptr_t as its storage element.
Previously, we were using a union to convert between various value types that
we would store in this pseudo-register. This method of type conversion is
undefined behavior according to the C++ spec. As a result, the C++ compiler
may choose to elide some CLoop statements, thereby resulting in some exotic
bugs.
We fix this by now always using accessor methods and assignment operators to
ensure that we use bitwise_cast to do the type conversions. Since bitwise_cast
uses a memcpy, this ensures that there's no undefined behavior, and that CLoop
statements won't get elided willy-nilly by the compiler.
Ditto for the CloopDobleRegisters.
Similarly, use bitwise_cast for ints2Double() and double2Ints() utility
functions.
Also use bitwise_cast (instead of reinterpret_cast) for the CLoop CAST macro.
6. Fix cloop.rb to use the new CLoopRegister and CLoopDoubleRegister classes.
Add a clLValue accessor for offlineasm operand types to distinguish
LValue use of the operands from RValue uses.
Replace the use of clearHighWord() with simply casting to uint32_t. This is
more efficient for the C++ compiler (and help speed up debug build runs).
Also fix 32-bit arithmetic operations to only set the lower 32-bit value of
the pseudo registers. This fixes some CLoop JSC test failures.
This patch has been manually tested with the JSC tests on the following builds:
64bit X86 ASM LLLint (without JIT), 64bit and 32bit X86 CLoop, and ARMv7 Cloop.
* interpreter/CLoopStack.cpp:
(JSC::CLoopStack::grow):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter.cpp:
(JSC::CLoopRegister::i const):
(JSC::CLoopRegister::u const):
(JSC::CLoopRegister::i32 const):
(JSC::CLoopRegister::u32 const):
(JSC::CLoopRegister::i8 const):
(JSC::CLoopRegister::u8 const):
(JSC::CLoopRegister::ip const):
(JSC::CLoopRegister::i8p const):
(JSC::CLoopRegister::vp const):
(JSC::CLoopRegister::cvp const):
(JSC::CLoopRegister::callFrame const):
(JSC::CLoopRegister::execState const):
(JSC::CLoopRegister::instruction const):
(JSC::CLoopRegister::vm const):
(JSC::CLoopRegister::cell const):
(JSC::CLoopRegister::protoCallFrame const):
(JSC::CLoopRegister::nativeFunc const):
(JSC::CLoopRegister::i64 const):
(JSC::CLoopRegister::u64 const):
(JSC::CLoopRegister::encodedJSValue const):
(JSC::CLoopRegister::opcode const):
(JSC::CLoopRegister::operator ExecState*):
(JSC::CLoopRegister::operator const Instruction*):
(JSC::CLoopRegister::operator JSCell*):
(JSC::CLoopRegister::operator ProtoCallFrame*):
(JSC::CLoopRegister::operator Register*):
(JSC::CLoopRegister::operator VM*):
(JSC::CLoopRegister::operator=):
(JSC::CLoopRegister::bitsAsDouble const):
(JSC::CLoopRegister::bitsAsInt64 const):
(JSC::CLoopDoubleRegister::operator T const):
(JSC::CLoopDoubleRegister::d const):
(JSC::CLoopDoubleRegister::bitsAsInt64 const):
(JSC::CLoopDoubleRegister::operator=):
(JSC::LLInt::ints2Double):
(JSC::LLInt::double2Ints):
(JSC::LLInt::decodeResult):
(JSC::CLoop::execute):
(JSC::LLInt::Ints2Double): Deleted.
(JSC::LLInt::Double2Ints): Deleted.
(JSC::CLoopRegister::CLoopRegister): Deleted.
(JSC::CLoopRegister::clearHighWord): Deleted.
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* offlineasm/cloop.rb:
2019-01-14 Keith Miller <keith_miller@apple.com>
JSC should have a module loader API
https://bugs.webkit.org/show_bug.cgi?id=191121
Reviewed by Michael Saboff.
This patch adds a new delegate to JSContext that is called to fetch
any resolved module. The resolution of a module identifier is computed
as if it were a URL on the web with the caveat that it must be a file URL.
A new class JSScript has also been added that is similar to JSScriptRef.
Right now all JSScripts are copied into memory. In the future we should
mmap the provided file into memory so the OS can evict it to disk under
pressure. Additionally, the API does not make use of the code signing path
nor the bytecode caching path, which we will add in subsequent patches.
Lastly, a couple of new convenience methods have been added. C API
conversion, can now toRef a JSValue with just a vm rather than
requiring an ExecState. Secondly, there is now a call wrapper that
does not require CallData and CallType since many places don't
care about this.
* API/APICast.h:
(toRef):
* API/JSAPIGlobalObject.cpp: Copied from Source/JavaScriptCore/API/JSVirtualMachineInternal.h.
* API/JSAPIGlobalObject.h: Added.
(JSC::JSAPIGlobalObject::create):
(JSC::JSAPIGlobalObject::createStructure):
(JSC::JSAPIGlobalObject::JSAPIGlobalObject):
* API/JSAPIGlobalObject.mm: Added.
(JSC::JSAPIGlobalObject::moduleLoaderResolve):
(JSC::JSAPIGlobalObject::moduleLoaderImportModule):
(JSC::JSAPIGlobalObject::moduleLoaderFetch):
(JSC::JSAPIGlobalObject::moduleLoaderCreateImportMetaProperties):
* API/JSAPIValueWrapper.h:
(JSC::jsAPIValueWrapper): Deleted.
* API/JSContext.h:
* API/JSContext.mm:
(-[JSContext moduleLoaderDelegate]):
(-[JSContext setModuleLoaderDelegate:]):
* API/JSContextInternal.h:
* API/JSContextPrivate.h:
* API/JSContextRef.cpp:
(JSGlobalContextCreateInGroup):
* API/JSScript.h: Added.
* API/JSScript.mm: Added.
(+[JSScript scriptWithSource:inVirtualMachine:]):
(fillBufferWithContentsOfFile):
(+[JSScript scriptFromUTF8File:inVirtualMachine:withCodeSigning:andBytecodeCache:]):
(getJSScriptSourceCode):
* API/JSScriptInternal.h: Copied from Source/JavaScriptCore/API/JSVirtualMachineInternal.h.
* API/JSValueInternal.h:
* API/JSVirtualMachineInternal.h:
* API/tests/testapi.mm:
(+[JSContextFetchDelegate contextWithBlockForFetch:]):
(-[JSContextFetchDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
(checkModuleCodeRan):
(checkModuleWasRejected):
(testFetch):
(testFetchWithTwoCycle):
(testFetchWithThreeCycle):
(testLoaderResolvesAbsoluteScriptURL):
(testLoaderRejectsNilScriptURL):
(testLoaderRejectsFailedFetch):
(testImportModuleTwice):
(+[JSContextFileLoaderDelegate newContext]):
(resolvePathToScripts):
(-[JSContextFileLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
(testLoadBasicFile):
(testObjectiveCAPI):
* API/tests/testapiScripts/basic.js: Copied from Source/JavaScriptCore/API/JSVirtualMachineInternal.h.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* SourcesCocoa.txt:
* config.h:
* postprocess-headers.sh:
* runtime/CallData.cpp:
(JSC::call):
* runtime/CallData.h:
* runtime/Completion.cpp:
(JSC::loadAndEvaluateModule):
* runtime/Completion.h:
* runtime/JSCast.h:
(JSC::jsSecureCast):
* runtime/JSGlobalObject.cpp:
(JSC::createProxyProperty):
2019-01-14 Dominik Infuehr <dinfuehr@igalia.com>
Fix property access on ARM with the baseline JIT
https://bugs.webkit.org/show_bug.cgi?id=193393
Reviewed by Yusuke Suzuki.
Code was still using currentInstruction[4] to access the instruction's metadata.
Updated to use metadata.getPutInfo and metadata.resolveType.
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emit_op_put_to_scope):
2019-01-12 Timothy Hatcher <timothy@apple.com>
Have prefers-color-scheme: light always match on macOS versions before Mojave.
https://bugs.webkit.org/show_bug.cgi?id=191655
rdar://problem/46074680
Reviewed by Megan Gardner.
* Configurations/FeatureDefines.xcconfig: ENABLE_DARK_MODE_CSS_macosx for all OS versions.
2019-01-12 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Unreviewed, fix scope check assertions
https://bugs.webkit.org/show_bug.cgi?id=193308
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::notifyLexicalBindingShadowing):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::notifyLexicalBindingShadowing):
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties):
2019-01-11 John Wilander <wilander@apple.com>
Compile out Web API Statistics Collection
https://bugs.webkit.org/show_bug.cgi?id=193370
<rdar://problem/45388584>
Reviewed by Brent Fulgham.
* Configurations/FeatureDefines.xcconfig:
Defined ENABLE_WEB_API_STATISTICS, off by default.
2019-01-11 Saam barati <sbarati@apple.com>
DFG combined liveness can be wrong for terminal basic blocks
https://bugs.webkit.org/show_bug.cgi?id=193304
<rdar://problem/45268632>
Reviewed by Yusuke Suzuki.
If a block doesn't have any successors, it can't rely on the typical
backwards liveness propagation that CombinedLiveness was doing. The phase
first got what was live in bytecode and IR at the heads of each block. Then
for each block, it made the live at tail the union of the live at head for
each successor. For a terminal block though, this could be wrong. We could
end up saying nothing is live even though many things may be live in bytecode.
We must account for what's bytecode live at the end of the block. Consider a
block that ends with:
```
ForceOSRExit
Unreachable
```
Things may definitely be live in bytecode at the tail. However, we'll
report nothing as being alive. This probably subtly breaks many analyses,
but we have a test case of it breaking the interference analysis that
the ArgumentsEliminationPhase performs.
* dfg/DFGBasicBlock.h:
(JSC::DFG::BasicBlock::last const):
* dfg/DFGCombinedLiveness.cpp:
(JSC::DFG::addBytecodeLiveness):
(JSC::DFG::liveNodesAtHead):
(JSC::DFG::CombinedLiveness::CombinedLiveness):
* dfg/DFGCombinedLiveness.h:
2019-01-11 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Global lexical bindings can shadow global variables if it is `configurable = true`
https://bugs.webkit.org/show_bug.cgi?id=193308
<rdar://problem/45546542>
Reviewed by Saam Barati.
Previously, we assumed that lexical bindings in JSGlobalLexicalEnvironment cannot shadow existing global properties.
However, it is wrong. According to the spec, we can shadow global properties if a property's attribute is configurable = true.
For example, we execute two scripts.
script1.js
bar = 42;
function load() { return bar; }
print(bar); // 42
print(load()); // 42
script2.js
let bar = 0; // This lexical binding can shadow the global.bar defined in script1.js
print(bar); // 0
print(load()); // 0
In JSC, we cache GlobalProperty resolve type and its associated information in op_resolve_type, op_get_from_scope, and op_put_to_scope.
They attempt to load a property from JSGlobalObject directly. However, once the newly added lexical binding starts shadowing this, our existing instructions
become invalid since they do not respect JSGlobalLexicalEnvironment.
In this patch, we fix this issue by introducing the following mechanisms.
1. We have a HashMap<property name, watchpoint set> in JSGlobalObject. DFG and FTL create a watchpoint set with the property name if the generated code
depends on GlobalProperty condition of op_resolve_scope etc. These watchpoint will be fired when the shadowing happens, so that our generated DFG and FTL
code will be invalidated if it depends on the condition which is no longer valid.
2. When we detect shadowing, we iterate all the live CodeBlocks which globalObject is the target one. And we rewrite instructions in them from GlobalProperty
to GlobalLexicalVar (or Dynamic precisely). So, the subsequent LLInt code just works well. "Dynamic" conversion happens when your op_put_to_scope attempts to
put a value onto a const lexical binding. This fails and it should throw a type error.
3. GlobalProperty scope operations in Baseline JIT start checking ResolveType in metadata, and emit code for GlobalProperty and GlobalLexicalVar. Once the rewrite
happens, baseline JIT continues working because it checks the rewritten metadata's ResolveType.
We use this mechanism (which is similar to haveABadTime() thing) because,
1. Shadowing should be super rare. Before r214145, we made these cases as SytaxError. Thus, before r214145, this type of code cannot be executed in WebKit.
And the number of the live CodeBlocks for the given JSGlobalObject should be small. This supports introducing rather simple (but not so efficient) mechanism
instead of the complicated one.
2. Rewriting instructions immediately forces GlobalProperty => GlobalLexicalVar / Dynamic conversion in all the possible CodeBlock. This allows us to avoid
compilation failure loop in DFG and FTL: DFG and FTL codes are invalidated by the watchpoint, but we may attempt to compile the code with the invalidated watchpoint
and GlobalProperty status if we do not rewrite it. One possible other implementation is having and checking a counter in instruction, and every time we introduce
a new shadow binding, bump the counter. And eventually executed instruction will go to the slow path and rewrite itself. However, this way leaves the not-executed-again-yet
instructions as is, and DFG and FTL repeatedly fail to compile if we just watch the invalidated watchpoint for that. Rewriting all the existing GlobalProperty immediately
avoids this situation easily.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::notifyLexicalBindingShadowing):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::scriptMode const):
* bytecode/Watchpoint.h:
(JSC::WatchpointSet::create):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGDesiredGlobalProperties.cpp: Added.
(JSC::DFG::DesiredGlobalProperties::isStillValidOnMainThread):
(JSC::DFG::DesiredGlobalProperties::reallyAdd):
* dfg/DFGDesiredGlobalProperties.h: Added.
(JSC::DFG::DesiredGlobalProperties::addLazily):
We need this DesiredGlobalProperties mechanism since we do not want to ref() the UniquedStringImpl in DFG and FTL thread.
We keep JSGlobalObject* and identifierNumber, and materialize WatchpointSets for each JSGlobalObject's property referenced
from DFG and FTL and inject CodeBlock jettison watchpoints in the main thread.
* dfg/DFGDesiredGlobalProperty.h: Added.
(JSC::DFG::DesiredGlobalProperty::DesiredGlobalProperty):
(JSC::DFG::DesiredGlobalProperty::globalObject const):
(JSC::DFG::DesiredGlobalProperty::identifierNumber const):
(JSC::DFG::DesiredGlobalProperty::operator== const):
(JSC::DFG::DesiredGlobalProperty::operator!= const):
(JSC::DFG::DesiredGlobalProperty::isHashTableDeletedValue const):
(JSC::DFG::DesiredGlobalProperty::hash const):
(JSC::DFG::DesiredGlobalProperty::dumpInContext const):
(JSC::DFG::DesiredGlobalProperty::dump const):
(JSC::DFG::DesiredGlobalPropertyHash::hash):
(JSC::DFG::DesiredGlobalPropertyHash::equal):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::globalProperties):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::reallyAdd):
(JSC::DFG::Plan::isStillValidOnMainThread):
(JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
(JSC::DFG::Plan::cancel):
* dfg/DFGPlan.h:
(JSC::DFG::Plan::globalProperties):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emit_op_put_to_scope):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emit_op_put_to_scope):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::addStaticGlobals):
(JSC::JSGlobalObject::notifyLexicalBindingShadowing):
(JSC::JSGlobalObject::getReferencedPropertyWatchpointSet):
(JSC::JSGlobalObject::ensureReferencedPropertyWatchpointSet):
* runtime/JSGlobalObject.h:
* runtime/ProgramExecutable.cpp:
(JSC::hasRestrictedGlobalProperty):
(JSC::ProgramExecutable::initializeGlobalProperties):
2019-01-11 Dominik Infuehr <dinfuehr@igalia.com>
Enable DFG on ARM/Linux again
https://bugs.webkit.org/show_bug.cgi?id=192496
Reviewed by Yusuke Suzuki.
After changing the bytecode format DFG was disabled on all 32-bit
architectures. Enable DFG now again on ARM/Linux. Do not use register
r11 in compiled DFG mode since it is already used in LLInt as metadataTable
register. Also clean up code since ARM traditional isn't supported anymore.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
(JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
* jit/CallFrameShuffler.cpp:
(JSC::CallFrameShuffler::CallFrameShuffler):
* jit/GPRInfo.h:
(JSC::GPRInfo::toIndex):
* llint/LowLevelInterpreter32_64.asm:
* offlineasm/arm.rb:
2019-01-10 Brian Burg <bburg@apple.com>
Web Inspector: incorrect type signature used for protocol enums in async command results
https://bugs.webkit.org/show_bug.cgi?id=193331
Reviewed by Devin Rousso.
When an enum is returned by an async command, the type signature should be that of the
Inspector::Protocol::* generated enum, rather than the underlying primitive type (i.e., String).
* inspector/scripts/codegen/cpp_generator.py:
(CppGenerator.cpp_type_for_formal_async_parameter):
* inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
Rebaseline generator test results.
2019-01-10 Brian Burg <bburg@apple.com>
Rebaseline inspector generator test results after recent changes.
Unreviewed test gardening.
* inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/generic/expected/fail-on-domain-availability-value.json-error:
2019-01-10 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r239825.
https://bugs.webkit.org/show_bug.cgi?id=193330
Broke tests on armv7/linux bots (Requested by guijemont on
#webkit).
Reverted changeset:
"Enable DFG on ARM/Linux again"
https://bugs.webkit.org/show_bug.cgi?id=192496
https://trac.webkit.org/changeset/239825
2019-01-10 Dominik Infuehr <dinfuehr@igalia.com>
Enable DFG on ARM/Linux again
https://bugs.webkit.org/show_bug.cgi?id=192496
Reviewed by Yusuke Suzuki.
After changing the bytecode format DFG was disabled on all 32-bit
architectures. Enable DFG now again on ARM/Linux. Do not use register
r11 in compiled DFG mode since it is already used in LLInt as metadataTable
register. Also clean up code since ARM traditional isn't supported anymore.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
(JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
* jit/CallFrameShuffler.cpp:
(JSC::CallFrameShuffler::CallFrameShuffler):
* jit/GPRInfo.h:
(JSC::GPRInfo::toIndex):
* llint/LowLevelInterpreter32_64.asm:
* offlineasm/arm.rb:
2019-01-09 Mark Lam <mark.lam@apple.com>
Restore bytecode dumper's ability to dump jump target as offset#(->targetBytecodeIndex#).
https://bugs.webkit.org/show_bug.cgi?id=193300
Reviewed by Saam Barati.
For example, instead of:
[ 95] jtrue loc11, 9
We can now again (as before the bytecode format rewrite) have:
[ 95] jtrue loc11, 9(->104)
* bytecode/BytecodeDumper.cpp:
(JSC::BytecodeDumper<Block>::printLocationAndOp):
* bytecode/BytecodeDumper.h:
(JSC::BytecodeDumper::dumpValue):
2019-01-09 Mark Lam <mark.lam@apple.com>
Gigacage disabling checks should handle the GIGACAGE_ALLOCATION_CAN_FAIL case properly.
https://bugs.webkit.org/show_bug.cgi?id=193292
<rdar://problem/46485450>
Reviewed by Yusuke Suzuki.
* runtime/VM.h:
(JSC::VM::gigacageAuxiliarySpace):
2019-01-08 Keith Miller <keith_miller@apple.com>
builtins should be able to use async/await
https://bugs.webkit.org/show_bug.cgi?id=193263
Reviewed by Saam Barati.
This patch makes it possible to use async functions when writing builtin JS code.
* Scripts/wkbuiltins/builtins_generator.py:
(BuiltinsGenerator.generate_embedded_code_string_section_for_function):
* Scripts/wkbuiltins/builtins_model.py:
(BuiltinFunction.__init__):
(BuiltinFunction.fromString):
(BuiltinFunction.__str__):
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createExecutable):
* builtins/ModuleLoader.js:
(requestInstantiate):
(async.loadModule):
(async.loadAndEvaluateModule):
(async.requestImportModule):
(loadModule): Deleted.
(): Deleted.
(loadAndEvaluateModule): Deleted.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
2019-01-08 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Array.prototype.flat/flatMap have a minor bug in ArraySpeciesCreate
https://bugs.webkit.org/show_bug.cgi?id=193127
Reviewed by Saam Barati.
`== null` is frequently used idiom to check `null` or `undefined` in JS.
However, it has a problem in terms of the builtin JS implementation: it
returns true if masquerade-as-undefined objects (e.g. document.all) come.
In this patch, we introduce a convenient builtin intrinsic @isUndefinedOrNull,
which is equivalent to C++ `JSValue::isUndefinedOrNull`. It does not consider
about masquerade-as-undefined objects, so that we can use it instead of
`value === null || value === @undefined`. We introduce is_undefined_or_null
bytecode, IsUndefinedOrNull DFG node and its DFG and FTL backends. Since
Null and Undefined have some bit patterns, we can implement this query
very efficiently.
* builtins/ArrayIteratorPrototype.js:
(next):
* builtins/ArrayPrototype.js:
(globalPrivate.arraySpeciesCreate):
* builtins/GlobalOperations.js:
(globalPrivate.speciesConstructor):
(globalPrivate.copyDataProperties):
(globalPrivate.copyDataPropertiesNoExclusions):
* builtins/MapIteratorPrototype.js:
(next):
* builtins/SetIteratorPrototype.js:
(next):
* builtins/StringIteratorPrototype.js:
(next):
* builtins/StringPrototype.js:
(match):
(repeat):
(padStart):
(padEnd):
(intrinsic.StringPrototypeReplaceIntrinsic.replace):
(search):
(split):
(concat):
(globalPrivate.createHTML):
* builtins/TypedArrayPrototype.js:
(globalPrivate.typedArraySpeciesConstructor):
(map):
(filter):
* bytecode/BytecodeIntrinsicRegistry.h:
* bytecode/BytecodeList.rb:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitIsUndefinedOrNull):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::BytecodeIntrinsicNode::emit_intrinsic_isUndefinedOrNull):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileIsUndefinedOrNull):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_is_undefined_or_null):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_is_undefined_or_null):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2019-01-08 David Kilzer <ddkilzer@apple.com>
Leak of VectorBufferBase.m_buffer (16-64 bytes) under JSC::CompactVariableEnvironment in com.apple.WebKit.WebContent running layout tests
<https://webkit.org/b/193264>
<rdar://problem/46651026>
Reviewed by Yusuke Suzuki.
* parser/VariableEnvironment.cpp:
(JSC::CompactVariableMap::Handle::~Handle): Call delete on
m_environment instead of fastFree() to make sure the destructors
for the Vector instance variables are run. This fixes the leaks
because calling fastFree() would only free the
CompactVariableEnvironment object, but not the heap-based
buffers allocated for the Vector instance variables.
2019-01-08 Joseph Pecoraro <pecoraro@apple.com>
ASSERT when paused in debugger and console evaluation causes exception
https://bugs.webkit.org/show_bug.cgi?id=193246
Reviewed by Mark Lam.
* runtime/VM.cpp:
(JSC::VM::throwException):
Improve assertion to allow for the debugger's evaluate on call frame condition.
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::callFrameAtDebuggerEntry const):
(JSC::JSGlobalObject::setCallFrameAtDebuggerEntry):
Debugger call frame only used by assertions.
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::evaluateWithScopeExtension):
* debugger/DebuggerEvalEnabler.h:
(JSC::DebuggerEvalEnabler::DebuggerEvalEnabler):
(JSC::DebuggerEvalEnabler::~DebuggerEvalEnabler):
When evaluating on a call frame, set a debug GlobalObject state.
2019-01-08 Keith Miller <keith_miller@apple.com>
Move JSValueMakeSymbol to private header
https://bugs.webkit.org/show_bug.cgi?id=193254
Reviewed by Saam Barati.
When moving other functions in JSValueRef I guess I forgot to move this one.
* API/JSObjectRefPrivate.h:
* API/JSValueRef.h:
2019-01-08 Mark Lam <mark.lam@apple.com>
Fix some typos in comments.
Not reviewed.
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
2019-01-08 Tadeu Zagallo <tzagallo@apple.com>
LLInt put_by_id uses the wrong load instruction for loading flags from the metadata
https://bugs.webkit.org/show_bug.cgi?id=193221
Reviewed by Mark Lam.
The flags are only 4 bytes, but were loaded with loadp. It used to work,
since the flags were followed by a 4-byte padding, but it broke after the
struct was compacted in r239626.
* llint/LowLevelInterpreter64.asm:
2019-01-07 Devin Rousso <drousso@apple.com>
Web Inspector: extend XHR breakpoints to work with fetch
https://bugs.webkit.org/show_bug.cgi?id=185843
<rdar://problem/40431027>
Reviewed by Matt Baker.
* inspector/protocol/DOMDebugger.json:
Rename `XHR` to `URL`.
* inspector/protocol/Debugger.json:
Add `Fetch` to `reason` enum for the `Debugger.paused` event.
2019-01-07 Devin Rousso <drousso@apple.com>
Web Inspector: Network: show secure connection details per-request
https://bugs.webkit.org/show_bug.cgi?id=191539
<rdar://problem/45979891>
Reviewed by Joseph Pecoraro.
* inspector/protocol/Security.json:
Add `Connection` type.
* inspector/protocol/Network.json:
Send `Security.Connection` information when request metrics become available.
2019-01-04 Tadeu Zagallo <tzagallo@apple.com>
Baseline version of get_by_id may corrupt metadata
https://bugs.webkit.org/show_bug.cgi?id=193085
<rdar://problem/23453006>
Reviewed by Saam Barati.
The Baseline version of get_by_id unconditionally calls `emitArrayProfilingSiteForBytecodeIndexWithCell`
if the property is `length`. However, since the bytecode rewrite, get_by_id only has an ArrayProfile entry
in the metadata if its mode is `GetByIdMode::ArrayLength`. That might result in one of two bad things:
1) get_by_id's mode is not ArrayLength, and a duplicate, out-of-line ArrayProfile entry will be created by
`CodeBlock::getOrAddArrayProfile`.
2) get_by_id's mode *is* ArrayLength and we generate the array profiling code pointing to the ArrayProfile
that lives in the metadata table. This works fine as long as get_by_id does not change modes. If that happens,
the JIT code will write into the metadata table, overwriting the 'GetByIdModeMetadata` for another mode.
Add a check to the Baseline version of get_by_id so that we only do the ArrayProfiling if the get_by_id's
mode is ArrayLength
* bytecode/BytecodeList.rb:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::getArrayProfile):
(JSC::CodeBlock::addArrayProfile): Deleted.
(JSC::CodeBlock::getOrAddArrayProfile): Deleted.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::numberOfArrayProfiles const): Deleted.
(JSC::CodeBlock::arrayProfiles): Deleted.
* bytecode/CodeBlockInlines.h:
(JSC::CodeBlock::forEachArrayProfile):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::emitArrayProfilingSiteForBytecodeIndexWithCell): Deleted.
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_get_by_id):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_get_by_id):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
2019-01-02 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Optimize Object.prototype.toString
https://bugs.webkit.org/show_bug.cgi?id=193031
Reviewed by Saam Barati.
Object.prototype.toString is frequently used for type checking.
It is called many times in wtb-lebab.js. This patch optimizes
Object.prototype.toString by the following two optimizations.
1. We should emit code looking up cached to string in DFG and FTL.
toString's result is cached in the Structure. We emit a fast path code
in DFG and FTL to lookup this cache.
2. We should not create objects for primitive values in major cases.
When Object.prototype.toString(primitive) is called, this primitive is converted
to an object by calling ToObject. But if the result is appropriately cached in
the Structure, we should get it in the fast path without creating this object.
When converting primitives to objects, Structures used in these newly created objects
are known (Structure for StringObject etc.). So we can first query the cached string
before actually converting primitives to objects.
This patch improves wtb-lebab.js by roughly 2%.
before: lebab: 8.90 runs/s
after : lebab: 9.09 runs/s
* JavaScriptCore.xcodeproj/project.pbxproj:
* 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):
(JSC::DFG::FixupPhase::fixupObjectToString):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileObjectToString):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileObjectToString):
* runtime/Intrinsic.cpp:
(JSC::intrinsicName):
* runtime/Intrinsic.h:
* runtime/ObjectPrototype.cpp:
(JSC::ObjectPrototype::finishCreation):
(JSC::objectProtoFuncToString):
* runtime/ObjectPrototype.h:
* runtime/ObjectPrototypeInlines.h: Added.
(JSC::structureForPrimitiveValue):
(JSC::objectToString):
* runtime/StructureRareData.h:
2019-01-03 Michael Saboff <msaboff@apple.com>
DFG IntegerRangeOptimization phase exceeding loop limit shouldn't ASSERT
https://bugs.webkit.org/show_bug.cgi?id=193094
Reviewed by Saam Barati.
Removed this debug only ASSERT as one can construct test cases that will exceed the giveUpThreshold
amount. This can be done with a large switch statement with at least one const or variable case
clause. Such code bytecompiles to compare / jtrue sequences. Increasing the giveUpThreshold count
doesn't help with the eventual code generated as B3 has optimizations to coalesce compare / branch
code sequences even when we don't run the IntegerRangeOptimization phase.
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
2019-01-02 Devin Rousso <webkit@devinrousso.com>
Web Inspector: Implement `queryObjects` Command Line API
https://bugs.webkit.org/show_bug.cgi?id=176766
<rdar://problem/34890689>
Reviewed by Joseph Pecoraro.
Introduces a new Command Line function called `queryObjects` that will return an array of
object that have the given constructor/prototype argument in their prototype chain.
- `queryObjects(Promise)` will return an array of all Promises.
- `queryObjects(Foo)` will return all objects created with the constructor `Foo`.
Currently, an error is thrown if the first argument is one of the following:
- Object
- Object.prototype
- Function
- Function.prototype
- Array
- Array.prototype
- Map
- Map.prototype
- Set
- Set.prototype
- Proxy
The reason for this is that we don't want to expose any internal/builtin objects, as some of
them are highly sensitive and undefined behaviour can occur if they are modified.
* inspector/JSInjectedScriptHost.h:
* inspector/JSInjectedScriptHost.cpp:
(Inspector::checkForbiddenPrototype): Added.
(Inspector::JSInjectedScriptHost::queryObjects): Added.
Does a GC and then iterates over all live JSCell in the heap to find these objects.
* inspector/JSInjectedScriptHostPrototype.cpp:
(Inspector::JSInjectedScriptHostPrototype::finishCreation):
(Inspector::jsInjectedScriptHostPrototypeFunctionQueryObjects): Added.
* inspector/InjectedScriptSource.js:
(queryObjects): Added.
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::promisePrototype): Added.
2018-12-31 Keith Miller <keith_miller@apple.com>
SourceProviders should use an actual URL instead of a string
https://bugs.webkit.org/show_bug.cgi?id=192734
Reviewed by Yusuke Suzuki.
This will be useful for the Module loader API in the future where
by default it will use the relative path from the referring module
to resolve dependencies.
I didn't change the JSC shell's urls to be absolute paths as it
caused problems with the stack traces in our Chakra tests. Since
the absolute paths included system directories the diff would
appear incorrect.
See: https://bugs.webkit.org/show_bug.cgi?id=193077
* API/JSBase.cpp:
(JSEvaluateScript):
(JSCheckScriptSyntax):
* API/JSScriptRef.cpp:
(OpaqueJSScript::create):
(OpaqueJSScript::OpaqueJSScript):
* API/glib/JSCContext.cpp:
(jsc_context_check_syntax):
* jsc.cpp:
(jscSource):
(GlobalObject::moduleLoaderFetch):
(functionCheckModuleSyntax):
(runWithOptions):
* parser/SourceCode.h:
(JSC::makeSource):
* parser/SourceProvider.cpp:
(JSC::SourceProvider::SourceProvider):
* parser/SourceProvider.h:
(JSC::SourceProvider::url const):
(JSC::StringSourceProvider::create):
(JSC::StringSourceProvider::StringSourceProvider):
(JSC::WebAssemblySourceProvider::create):
(JSC::WebAssemblySourceProvider::WebAssemblySourceProvider):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* tools/CodeProfile.h:
(JSC::CodeProfile::CodeProfile):
* tools/FunctionOverrides.cpp:
(JSC::initializeOverrideInfo):
2019-01-01 Jeff Miller <jeffm@apple.com>
Update user-visible copyright strings to include 2019
https://bugs.webkit.org/show_bug.cgi?id=192811
Reviewed by Mark Lam.
* Info.plist:
2018-12-30 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Identifier validity should be based on ID_Start / ID_Continue properties
https://bugs.webkit.org/show_bug.cgi?id=193050
Reviewed by Yusuke Suzuki.
From https://tc39.github.io/ecma262/#sec-names-and-keywords:
UnicodeIDStart::
any Unicode code point with the Unicode property "ID_Start"
UnicodeIDContinue::
any Unicode code point with the Unicode property "ID_Continue"
* parser/Lexer.cpp:
(JSC::Lexer<T>::Lexer):
(JSC::isNonLatin1IdentStart):
(JSC::isNonLatin1IdentPart):
(JSC::isIdentPart):
(JSC::Lexer<T>::lex):
Ensure identifier start / part is based on ID_Start / ID_Continue.
(Implies a special case for U+00B7, which is Latin-1 but Other_ID_Continue.)
2018-12-28 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Remove one indirection in JSObject::toStringName
https://bugs.webkit.org/show_bug.cgi?id=193037
Reviewed by Keith Miller.
We should not have additional one-level indirection in JSObject::toStringName.
JSObject::toStringName is dispatched through methodTable. Even after that, we
need to call JSObject::className function through methodTable again. But className
function is rarely defined. So instead of introducing this indirection here,
classes having className functions should have toStringName function too. This can
remove one-level indirection in toStringName in major cases.
* API/JSCallbackObject.h:
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::toStringName):
* debugger/DebuggerScope.cpp:
(JSC::DebuggerScope::toStringName):
* debugger/DebuggerScope.h:
* runtime/JSObject.cpp:
(JSC::JSObject::toStringName):
2018-12-27 Alex Christensen <achristensen@webkit.org>
Resurrect Mac CMake build
https://bugs.webkit.org/show_bug.cgi?id=192658
Reviewed by Yusuke Suzuki.
* PlatformMac.cmake:
2018-12-25 Fujii Hironori <Hironori.Fujii@sony.com>
[JSC][Win][Clang] warning: implicit conversion from 'size_t' (aka 'unsigned long long') to 'int32_t' (aka 'int') changes value from 18446744073709551552 to -64 [-Wconstant-conversion]
https://bugs.webkit.org/show_bug.cgi?id=193035
Reviewed by Yusuke Suzuki.
Clang-cl reports a compilation warning for implicit conversion
from -64 size_t to int. Replaced '-maxFrameExtentForSlowPathCall'
with '-static_cast<int32_t>(maxFrameExtentForSlowPathCall)'.
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
* jit/JIT.cpp:
(JSC::JIT::compileWithoutLinking):
* jit/ThunkGenerators.cpp:
(JSC::slowPathFor):
2018-12-13 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[BigInt] Support BigInt in JSON.stringify
https://bugs.webkit.org/show_bug.cgi?id=192624
Reviewed by Saam Barati.
This patch adds BigInt support to JSON.stringify, specified in [1].
[1]: https://tc39.github.io/proposal-bigint/#sec-serializejsonproperty
* runtime/JSONObject.cpp:
(JSC::unwrapBoxedPrimitive):
(JSC::Stringifier::toJSON):
(JSC::Stringifier::toJSONImpl):
(JSC::Stringifier::appendStringifiedValue):
2018-12-21 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Use appendUnbarriered for cached own keys
https://bugs.webkit.org/show_bug.cgi?id=192981
Reviewed by Saam Barati.
m_cachedOwnKeys would be changed to sentinel after checking `thisObject->m_cachedOwnKeys.unvalidatedGet() != cachedOwnKeysSentinel()`
and before executing `visitor.append(thisObject->m_cachedOwnKeys)`. We never do this now, but might in the future.
To make the code safe, we should use appendUnbarriered to mark non sentinel cell.
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::visitChildren):
2018-12-20 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Use Ref<> as much as possible
https://bugs.webkit.org/show_bug.cgi?id=192808
Reviewed by Alex Christensen.
* API/JSTypedArray.cpp:
(JSObjectMakeTypedArrayWithBytesNoCopy):
* API/JSWeakObjectMapRefPrivate.cpp:
* bytecompiler/StaticPropertyAnalyzer.h:
(JSC::StaticPropertyAnalyzer::newObject):
* dfg/DFGDesiredWatchpoints.cpp:
(JSC::DFG::ArrayBufferViewWatchpointAdaptor::add):
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::sweeper):
* heap/Heap.h:
* heap/IsoCellSet.cpp:
(JSC::IsoCellSet::parallelNotEmptyMarkedBlockSource):
* heap/IsoCellSet.h:
* heap/IsoCellSetInlines.h:
(JSC::IsoCellSet::forEachMarkedCellInParallel):
* heap/Subspace.cpp:
(JSC::Subspace::parallelDirectorySource):
(JSC::Subspace::parallelNotEmptyMarkedBlockSource):
* heap/Subspace.h:
* heap/SubspaceInlines.h:
(JSC::Subspace::forEachMarkedCellInParallel):
* jsc.cpp:
(functionDollarAgentReceiveBroadcast):
* runtime/ArrayBuffer.cpp:
(JSC::ArrayBuffer::slice const):
(JSC::ArrayBuffer::sliceImpl const):
* runtime/ArrayBuffer.h:
* runtime/ArrayBufferNeuteringWatchpoint.cpp:
(JSC::ArrayBufferNeuteringWatchpoint::ArrayBufferNeuteringWatchpoint):
(JSC::ArrayBufferNeuteringWatchpoint::fireAll):
* runtime/ArrayBufferNeuteringWatchpoint.h:
* runtime/JSArrayBufferPrototype.cpp:
(JSC::arrayBufferProtoFuncSlice):
2018-12-21 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Crashes seen under Inspector::ScriptCallFrame::~ScriptCallFrame
https://bugs.webkit.org/show_bug.cgi?id=180373
<rdar://problem/33894170>
Rubber-stamped by Devin Rousso.
* inspector/AsyncStackTrace.cpp:
(Inspector::AsyncStackTrace::truncate):
The `lastUnlockedAncestor->remove()` may release the only reference to it's
parent which we intend to use later but don't hold a RefPtr to. Keep the
parent alive explicitly by protecting it.
2018-12-20 Chris Dumez <cdumez@apple.com>
Use Optional::hasValue() instead of Optional::has_value()
https://bugs.webkit.org/show_bug.cgi?id=192948
Reviewed by Tim Horton.
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
(CppBackendDispatcherImplementationGenerator._generate_async_dispatcher_class_for_domain):
(CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
2018-12-20 Keith Miller <keith_miller@apple.com>
Add support for globalThis
https://bugs.webkit.org/show_bug.cgi?id=165171
Reviewed by Mark Lam.
This patch adds support for the globalThis property on the global
object. The globalThis property spec is in stage three and is
quite simple. For reference: http://tc39.github.io/proposal-global/
* runtime/JSGlobalObject.cpp:
2018-12-20 Chris Dumez <cdumez@apple.com>
Use Optional::valueOr() instead of Optional::value_or()
https://bugs.webkit.org/show_bug.cgi?id=192933
Reviewed by Geoffrey Garen.
* inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
(Inspector::RemoteConnectionToTarget::setup):
* inspector/remote/glib/RemoteConnectionToTargetGlib.cpp:
(Inspector::RemoteConnectionToTarget::setup):
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::SourceCodeKey):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
2018-12-20 Joseph Pecoraro <pecoraro@apple.com>
ITMLKit Inspector: Elements tab does not show DOM Tree
https://bugs.webkit.org/show_bug.cgi?id=192910
<rdar://problem/46680585>
Reviewed by Brian Burg.
* inspector/agents/InspectorAgent.h:
* inspector/agents/InspectorAgent.cpp:
(Inspector::InspectorAgent::enable):
(Inspector::InspectorAgent::activateExtraDomain):
(Inspector::InspectorAgent::activateExtraDomains):
Send extra domains immediately instead of waiting until
the Inspector domain is enabled. This will ensure the frontend
hears about extra augmented domains before augmenting agents
get a chance to send any messages.
2018-12-20 Mark Lam <mark.lam@apple.com>
Fix a typo in slow_path_construct_arityCheck and operationConstructArityCheck.
https://bugs.webkit.org/show_bug.cgi?id=192939
<rdar://problem/46869516>
Reviewed by Keith Miller.
* jit/JITOperations.cpp:
* runtime/CommonSlowPaths.cpp:
2018-12-20 Caio Lima <ticaiolima@gmail.com>
[BigInt] We should enable CSE into arithmetic operations that speculate BigIntUse
https://bugs.webkit.org/show_bug.cgi?id=192723
Reviewed by Yusuke Suzuki.
This patch is adjusting clobberize rules into ValueOp nodes to enable
more optimizations when we speculate BigIntUse. In such case, DFG now
is able to apply CSE, LICM and commutativity on nodes like
ValueAdd(BigInt, BigInt), ValueSub(BigInt, BigInt), etc.
Here are the numbers we can observe with some microbenchmarks:
baseline changes
big-int-cse 108.2733+-0.8445 ^ 80.9897+-4.9781 ^ definitely 1.3369x faster
big-int-licm 75.6641+-0.3477 ^ 57.8144+-1.6043 ^ definitely 1.3087x faster
big-int-global-cse 145.3557+-1.0552 ^ 86.5866+-0.3025 ^ definitely 1.6787x faster
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
2018-12-19 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r239377.
https://bugs.webkit.org/show_bug.cgi?id=192921
broke 32-bit JSC tests (Requested by keith_miller on #webkit).
Reverted changeset:
"[BigInt] We should enable CSE into arithmetic operations that
speculate BigIntUse"
https://bugs.webkit.org/show_bug.cgi?id=192723
https://trac.webkit.org/changeset/239377
2018-12-19 Chris Dumez <cdumez@apple.com>
wtf/Optional.h: move-constructor and move-assignment operator should disengage the value being moved from
https://bugs.webkit.org/show_bug.cgi?id=192728
<rdar://problem/46746779>
Reviewed by Geoff Garen.
* API/*:
* Scripts/*:
* assembler/*:
* b3/*:
* bytecode/*:
* bytecompiler/*:
* debugger/*:
* dfg/*:
* ftl/*:
* heap/*:
* inspector/*:
* jit/*:
* llint/*:
* parser/*:
* runtime/*:
* tools/*:
* wasm/*:
* yarr/*:
2018-12-18 Simon Fraser <simon.fraser@apple.com>
Web Inspector: Timelines: correctly label Intersection Observer callbacks
https://bugs.webkit.org/show_bug.cgi?id=192669
<rdar://problem/46702490>
Reviewed by Joseph Pecoraro.
Add InspectorInstrumentation::willFireObserverCallback() and use it to wrap calls
to Intersection Observer, Performance Observer and Mutation Observer callbacks so
that they get correctly labeled in the Inspector timeline.
* inspector/protocol/Timeline.json:
2018-12-18 Mark Lam <mark.lam@apple.com>
JSPropertyNameEnumerator should cache the iterated object's structure only after getting its property names.
https://bugs.webkit.org/show_bug.cgi?id=192464
<rdar://problem/46519455>
Reviewed by Saam Barati.
This is because the process of getting its property names may cause some lazy
properties to be reified, and the structure will change. This is needed in order
for get_direct_pname to work correctly.
* runtime/JSPropertyNameEnumerator.h:
(JSC::propertyNameEnumerator):
2018-12-19 Caio Lima <ticaiolima@gmail.com>
[BigInt] We should enable CSE into arithmetic operations that speculate BigIntUse
https://bugs.webkit.org/show_bug.cgi?id=192723
Reviewed by Saam Barati.
This patch is adjusting clobberize rules into ValueOp nodes to enable
more optimizations when we speculate BigIntUse. In such case, DFG now
is able to apply CSE, LICM and commutativity on nodes like
ValueAdd(BigInt, BigInt), ValueSub(BigInt, BigInt), etc.
Here are the numbers we can observe with some microbenchmarks:
baseline changes
big-int-cse 108.2733+-0.8445 ^ 80.9897+-4.9781 ^ definitely 1.3369x faster
big-int-licm 75.6641+-0.3477 ^ 57.8144+-1.6043 ^ definitely 1.3087x faster
big-int-global-cse 145.3557+-1.0552 ^ 86.5866+-0.3025 ^ definitely 1.6787x faster
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
2018-12-19 Tadeu Zagallo <tzagallo@apple.com>
String overflow in JSC::createError results in ASSERT in WTF::makeString
https://bugs.webkit.org/show_bug.cgi?id=192833
<rdar://problem/45706868>
Reviewed by Mark Lam.
JSC::createError was calling WTF::makeString which would result in an
assertion failure when the string was too big. Change it to call
WTF::tryMakeString instead and return an OutOfMemory error if we fail
to create the error string.
* runtime/ExceptionHelpers.cpp:
(JSC::createError):
2018-12-18 Ross Kirsling <ross.kirsling@sony.com>
Error message for `-x ** y` contains a typo.
https://bugs.webkit.org/show_bug.cgi?id=192832
Reviewed by Saam Barati.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseBinaryExpression):
Make corrections to error message: "amiguous" -> "ambiguous", "parenthesis" -> "parentheses"
2018-12-18 Saam Barati <sbarati@apple.com>
Update ARM64EHash
https://bugs.webkit.org/show_bug.cgi?id=192823
<rdar://problem/45468257>
Reviewed by Mark Lam.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::ARM64Assembler):
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::AbstractMacroAssembler):
* assembler/AssemblerBuffer.h:
(JSC::ARM64EHash::update):
(JSC::ARM64EHash::finalHash const):
(JSC::AssemblerBuffer::AssemblerBuffer):
(JSC::AssemblerBuffer::putIntegralUnchecked):
(JSC::ARM64EHash::ARM64EHash): Deleted.
(JSC::ARM64EHash::hash const): Deleted.
(JSC::ARM64EHash::randomSeed const): Deleted.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::copyCompactAndLinkCode):
2018-12-18 Mark Lam <mark.lam@apple.com>
JSON.stringify() should throw OOM on StringBuilder overflows.
https://bugs.webkit.org/show_bug.cgi?id=192822
<rdar://problem/46670577>
Reviewed by Saam Barati.
* runtime/JSONObject.cpp:
(JSC::Stringifier::stringify):
(JSC::Stringifier::appendStringifiedValue):
(JSC::Stringifier::Holder::appendNextProperty):
2018-12-18 Ross Kirsling <ross.kirsling@sony.com>
Redeclaration of var over let/const/class should be a syntax error.
https://bugs.webkit.org/show_bug.cgi?id=192298
Reviewed by Keith Miller.
From https://tc39.github.io/ecma262/#sec-block-static-semantics-early-errors:
It is a Syntax Error if any element of the LexicallyDeclaredNames of StatementList also occurs in the
VarDeclaredNames of StatementList.
Accordingly, this patch ensures that { let x; { var x; } } and { { var x; } let x; } are syntax errors.
For the "var after" scenario:
When checking for existing lexically-declared names, we can't simply check the current var scope;
we need to check *all* enclosing scopes up to (and including) the current var scope. In so doing,
we must also avoid violating the Annex B.3.5 condition that allows `try {} catch (e) { var e; }`.
For the "var before" scenario:
We ensure that lexical scopes always keep track of the vars being hoisted over them; this gives us
a simple way to check the current block's var-declared names prior to making a lexical declaration.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseTryStatement):
* parser/Parser.h:
(JSC::Scope::Scope):
(JSC::Scope::setIsSimpleCatchParameterScope): Added.
(JSC::Scope::isSimpleCatchParameterScope): Added.
(JSC::Scope::declareVariable):
(JSC::Scope::addVariableBeingHoisted): Added.
(JSC::Scope::declareLexicalVariable):
(JSC::Scope::hasDeclaredVariable):
(JSC::Scope::hasLexicallyDeclaredVariable): Added.
(JSC::Parser::declareHoistedVariable): Added.
(JSC::Parser::declareVariable):
2018-12-18 David Kilzer <ddkilzer@apple.com>
clang-tidy: Use const reference for MediaTime parameter to prevent object copy
<https://webkit.org/b/192814>
Reviewed by Mark Lam.
* runtime/JSCJSValue.h:
(JSC::jsNumber):
2018-12-18 Saam Barati <sbarati@apple.com>
Unreviewed. Appease a build error where we weren't using a variable defined in an "if"
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2018-12-17 Mark Lam <mark.lam@apple.com>
Array unshift/shift should not race against the AI in the compiler thread.
https://bugs.webkit.org/show_bug.cgi?id=192795
<rdar://problem/46724263>
Reviewed by Saam Barati.
The Array unshift and shift operations for ArrayStorage type arrays are protected
using the cellLock. The AbstractInterpreter's foldGetByValOnConstantProperty()
function does grab the cellLock before reading a value from the array's ArrayStorage,
but does not get the array butterfly under the protection of the cellLock.
This is insufficient and racy. For ArrayStorage type arrays, the fetching of the
butterfly also needs to be protected by the cellLock. The unshift / shift
operations can move values around in the butterfly. Hence, the fact that AI has
fetched a butterfly pointer (while ensuring no structure change) is insufficient
to guarantee that the values in the butterfly haven't shifted.
Having AI hold the cellLock the whole time (from before fetching the butterfly
till after reading the value from it) eliminates this race. Note: we only need
to do this for ArrayStorage type arrays.
Note also that though AI is holding the cellLock in this case, we still need to
ensure that the array structure hasn't changed around the fetching of the butterfly.
This is because operations other than unshift and shift are guarded by this
protocol, and not the cellLock.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* runtime/JSArray.cpp:
(JSC::JSArray::unshiftCountSlowCase):
2018-12-16 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Optimize Object.keys by caching own keys results in StructureRareData
https://bugs.webkit.org/show_bug.cgi?id=190047
Reviewed by Saam Barati.
Object.keys is one of the most frequently used function in web-tooling-benchmarks (WTB).
Object.keys is dominant in lebab of WTB, and frequently called in babel and others.
Since our Structure knows the shape of JSObject, we can cache the result of Object.keys
in Structure (StructureRareData) as we cache JSPropertyNameEnumerator in StructureRareData.
This patch caches the result of Object.keys in StructureRareData. The cached array is created
as JSImmutableButterfly. And Object.keys creates CoW from this data. Currently, the lifetime
strategy of this JSImmutableButterfly is the same to cached JSPropertyNameEnumerator. It is
referenced from Structure, and collected when Structure is collected.
This improves several benchmarks in SixSpeed.
baseline patched
object-assign.es5 350.1710+-3.6303 ^ 226.0368+-4.7558 ^ definitely 1.5492x faster
for-of-object.es6 269.1941+-3.3430 ^ 127.9317+-2.3875 ^ definitely 2.1042x faster
And it improves WTB lebab by 11.8%.
Before: lebab: 6.10 runs/s
After: lebab: 6.82 runs/s
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* 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.cpp:
(JSC::DFG::Node::convertToNewArrayBuffer):
* dfg/DFGNode.h:
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileObjectKeys):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileObjectKeys):
* runtime/Butterfly.h:
(JSC::ContiguousData::Data::setStartingValue):
* runtime/Intrinsic.cpp:
(JSC::intrinsicName):
* runtime/Intrinsic.h:
* runtime/JSImmutableButterfly.h:
(JSC::JSImmutableButterfly::JSImmutableButterfly):
We set JSEmpty to the underlying butterfly storage if indexing type is Contiguous.
Otherwise, JSImmutableButterfly is half-baked one until all the storage is filled with some meaningful values, it leads to crash
if half-baked JSImmutableButterfly is exposed to GC.
* runtime/ObjectConstructor.cpp:
(JSC::ownPropertyKeys):
* runtime/Structure.cpp:
(JSC::Structure::canCachePropertyNameEnumerator const):
* runtime/Structure.h:
* runtime/StructureInlines.h:
(JSC::Structure::setCachedOwnKeys):
(JSC::Structure::cachedOwnKeys const):
(JSC::Structure::cachedOwnKeysIgnoringSentinel const):
(JSC::Structure::canCacheOwnKeys const):
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::visitChildren):
(JSC::StructureRareData::cachedPropertyNameEnumerator const): Deleted.
(JSC::StructureRareData::setCachedPropertyNameEnumerator): Deleted.
* runtime/StructureRareData.h:
* runtime/StructureRareDataInlines.h:
(JSC::StructureRareData::cachedPropertyNameEnumerator const):
(JSC::StructureRareData::setCachedPropertyNameEnumerator):
(JSC::StructureRareData::cachedOwnKeys const):
(JSC::StructureRareData::cachedOwnKeysIgnoringSentinel const):
(JSC::StructureRareData::cachedOwnKeysConcurrently const):
(JSC::StructureRareData::setCachedOwnKeys):
(JSC::StructureRareData::previousID const): Deleted.
* runtime/VM.cpp:
(JSC::VM::VM):
2018-12-17 Mark Lam <mark.lam@apple.com>
SamplingProfiler's isValidFramePointer() should reject address at stack origin.
https://bugs.webkit.org/show_bug.cgi?id=192779
<rdar://problem/46775869>
Reviewed by Saam Barati.
isValidFramePointer() was previously treating the address at StackBounds::origin()
as valid stack memory. This is not true. StackBounds::origin() is actually the
first address beyond valid stack memory. This is now fixed.
* runtime/SamplingProfiler.cpp:
(JSC::FrameWalker::isValidFramePointer):
2018-12-17 Mark Lam <mark.lam@apple.com>
Suppress ASAN on valid stack accesses in Probe-based OSRExit::executeOSRExit().
https://bugs.webkit.org/show_bug.cgi?id=192776
<rdar://problem/46772368>
Reviewed by Keith Miller.
1. Add some asanUnsafe methods to the Register class.
2. Update the probe-based OSRExit::executeOSRExit() to use these asanUnsafe methods.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::executeOSRExit):
* interpreter/Register.h:
(JSC::Register::asanUnsafeUnboxedInt32 const):
(JSC::Register::asanUnsafeUnboxedInt52 const):
(JSC::Register::asanUnsafeUnboxedStrictInt52 const):
(JSC::Register::asanUnsafeUnboxedDouble const):
(JSC::Register::asanUnsafeUnboxedCell const):
2018-12-17 Mark Lam <mark.lam@apple.com>
Fix stale assertion in attemptToForceStringArrayModeByToStringConversion().
https://bugs.webkit.org/show_bug.cgi?id=192770
<rdar://problem/46449037>
Reviewed by Keith Miller.
This assertion was added before Array::OriginalNonArray was introduced. It just
needs to be updated to allow for Array::OriginalNonArray.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::attemptToForceStringArrayModeByToStringConversion):
2018-12-17 Matt Lewis <jlewis3@apple.com>
Unreviewed, rolling out r239254.
This broke the Windows 10 Debug build
Reverted changeset:
"Replace many uses of String::format with more type-safe
alternatives"
https://bugs.webkit.org/show_bug.cgi?id=192742
https://trac.webkit.org/changeset/239254
2018-12-15 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Unreviewed, suppress warnings in Linux
* jsc.cpp:
(jscmain):
2018-12-15 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Null pointer dereference in JSC::WriteBarrierBase()
https://bugs.webkit.org/show_bug.cgi?id=191252
Reviewed by Keith Miller.
JSPromiseDeferred::create can return nullptr and an exception if stack overflow happens.
We would like to make it RELEASE_ASSERT since the current module mechanism is not immune
to stack overflow.
This patch renames JSPromiseDeferred::create to JSPromiseDeferred::tryCreate to tell that
it can return nullptr. And we insert error checks or assertions after this call.
* jsc.cpp:
(GlobalObject::moduleLoaderImportModule):
(GlobalObject::moduleLoaderFetch):
* runtime/Completion.cpp:
(JSC::rejectPromise):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncImportModule):
* runtime/JSInternalPromiseDeferred.cpp:
(JSC::JSInternalPromiseDeferred::tryCreate):
(JSC::JSInternalPromiseDeferred::create): Deleted.
* runtime/JSInternalPromiseDeferred.h:
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::importModule):
(JSC::JSModuleLoader::resolve):
(JSC::JSModuleLoader::fetch):
(JSC::moduleLoaderParseModule):
* runtime/JSPromise.h:
* runtime/JSPromiseDeferred.cpp:
(JSC::JSPromiseDeferred::tryCreate):
* runtime/JSPromiseDeferred.h:
* wasm/js/WebAssemblyPrototype.cpp:
(JSC::webAssemblyCompileFunc):
(JSC::webAssemblyInstantiateFunc):
(JSC::webAssemblyCompileStreamingInternal):
(JSC::webAssemblyInstantiateStreamingInternal):
2018-12-15 Darin Adler <darin@apple.com>
Use warning-ignoring macros more consistently and simply
https://bugs.webkit.org/show_bug.cgi?id=192743
Reviewed by Mark Lam.
* dfg/DFGSpeculativeJIT64.cpp: Use IGNORE_WARNINGS_BEGIN/END instead of
IGNORE_CLANG_WARNINGS_BEGIN/END. Other callsites are using the non-clang-specific
one for this warning, "implicit-fallthrough", and it seems there is no special
need to use the clang-specific one here.
* llint/LLIntData.cpp: Ditto, but here it's "missing-noreturn"."
* tools/CodeProfiling.cpp: Ditto.
2018-12-15 Darin Adler <darin@apple.com>
Replace many uses of String::format with more type-safe alternatives
https://bugs.webkit.org/show_bug.cgi?id=192742
Reviewed by Mark Lam.
* inspector/InjectedScriptBase.cpp:
(Inspector::InjectedScriptBase::makeCall): Use makeString.
(Inspector::InjectedScriptBase::makeAsyncCall): Ditto.
* inspector/InspectorBackendDispatcher.cpp:
(Inspector::BackendDispatcher::getPropertyValue): Ditto.
* inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::enable): Ditto.
* jsc.cpp:
(FunctionJSCStackFunctor::operator() const): Ditto.
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::initializeDateTimeFormat): Use string concatenation.
* runtime/IntlObject.cpp:
(JSC::canonicalizeLocaleList): Ditto.
2018-12-14 Darin Adler <darin@apple.com>
LiteralParser has a bunch of uses of String::format with untrusted data
https://bugs.webkit.org/show_bug.cgi?id=108883
rdar://problem/13666409
Reviewed by Mark Lam.
* runtime/LiteralParser.cpp:
(JSC::LiteralParser<CharType>::Lexer::lex): Use makeString instead of String::format.
(JSC::LiteralParser<CharType>::Lexer::lexStringSlow): Ditto.
(JSC::LiteralParser<CharType>::parse): Ditto.
* runtime/LiteralParser.h:
(JSC::LiteralParser::getErrorMessage): Use string concatenation instead of
String::format.
2018-12-14 Mark Lam <mark.lam@apple.com>
CallFrame::convertToStackOverflowFrame() needs to keep the top CodeBlock alive.
https://bugs.webkit.org/show_bug.cgi?id=192717
<rdar://problem/46660677>
Reviewed by Saam Barati.
When throwing a StackOverflowError, we convert the topCallFrame into a
StackOverflowFrame. Previously, we would nullify the codeBlock field in the frame
because a StackOverflowFrame is only a sentinel and doesn't really correspond to
any CodeBlocks. However, this is a problem because the topCallFrame may be the
only remaining place that references the CodeBlock that the stack overflow is
triggered in. The way we handle exceptions in JIT code is to return (from the
runtime operation function throwing the exception) to the JIT code to check for
the exception and if needed, do some clean up before jumping to the exception
handling thunk. As a result, we need to keep that JIT code alive, which means we
need to keep its CodeBlock alive. We only need to keep this CodeBlock alive until
we've unwound (in terms of exception handling) out of it.
We fix this issue by storing the CodeBlock to keep alive in the StackOverflowFrame
for the GC to scan while the frame is still on the stack.
We removed the call to convertToStackOverflowFrame() in
lookupExceptionHandlerFromCallerFrame() because it is redundant.
lookupExceptionHandlerFromCallerFrame() will only every be called after
a StackOverFlowError has been thrown. Hence, the top frame is already
guaranteed to be a StackOverflowFrame, and there should always be a
StackOverFlowError exception pending. We added assertions for these
instead.
* interpreter/CallFrame.cpp:
(JSC::CallFrame::convertToStackOverflowFrame):
* interpreter/CallFrame.h:
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::codeBlockFromCallFrameCallee):
(JSC::CommonSlowPaths::arityCheckFor):
* runtime/VM.h:
(JSC::VM::exceptionForInspection const):
2018-12-14 David Kilzer <ddkilzer@apple.com>
clang-tidy: Fix unnecessary copy of objects for operator==() methods
<https://webkit.org/b/192712>
<rdar://problem/46739332>
Reviewed by Andy Estes.
* b3/air/AirAllocateRegistersByGraphColoring.cpp:
(JSC::B3::Air::(anonymous namespace)::AbstractColoringAllocator::InterferenceEdge::operator==):
- Change argument from const to const reference to avoid a copy.
2018-12-14 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r239153, r239154, and r239155.
https://bugs.webkit.org/show_bug.cgi?id=192715
Caused flaky GC-related crashes seen with layout tests
(Requested by ryanhaddad on #webkit).
Reverted changesets:
"[JSC] Optimize Object.keys by caching own keys results in
StructureRareData"
https://bugs.webkit.org/show_bug.cgi?id=190047
https://trac.webkit.org/changeset/239153
"Unreviewed, build fix after r239153"
https://bugs.webkit.org/show_bug.cgi?id=190047
https://trac.webkit.org/changeset/239154
"Unreviewed, build fix after r239153, part 2"
https://bugs.webkit.org/show_bug.cgi?id=190047
https://trac.webkit.org/changeset/239155
2018-12-14 Keith Miller <keith_miller@apple.com>
Callers of JSString::getIndex should check for OOM exceptions
https://bugs.webkit.org/show_bug.cgi?id=192709
Reviewed by Mark Lam.
This patch also allows Strings to OOM when the StringObject wrapper
attempts to look up an own property on the string.
Remove isExtensibleImpl because it's only used in one place and call
isStructureExtensible instead.
* runtime/JSObject.cpp:
(JSC::JSObject::isExtensible):
* runtime/JSObject.h:
(JSC::JSObject::isExtensibleImpl): Deleted.
* runtime/JSString.h:
(JSC::JSString::getStringPropertySlot):
* runtime/StringObject.cpp:
(JSC::StringObject::defineOwnProperty):
2018-12-13 Fujii Hironori <Hironori.Fujii@sony.com>
[WinCairo][Clang] DLLLauncherMain.cpp: warning: unused function 'prependPath' and 'appleApplicationSupportDirectory'
https://bugs.webkit.org/show_bug.cgi?id=192688
Reviewed by Ross Kirsling.
These functions are used only in AppleWin port.
* shell/DLLLauncherMain.cpp:
(copyEnvironmentVariable): Moved.
(getStringValue): Enclosed with #if !defined(WIN_CAIRO).
(applePathFromRegistry): Ditto.
(appleApplicationSupportDirectory): Ditto.
(prependPath): Ditto.
2018-12-13 Dominik Infuehr <dinfuehr@igalia.com>
Improve GDB output for LLInt on Linux
https://bugs.webkit.org/show_bug.cgi?id=192660
Reviewed by Yusuke Suzuki.
Annotate assembly code generated for LLInt with the bytecode operation. When debugging
LLInt assembly code GDB is then able to show which bytecode instruction is implemented by
the current assembly code. This also works for linux-perf.
* llint/LowLevelInterpreter.cpp:
* offlineasm/arm.rb:
2018-12-13 Mark Lam <mark.lam@apple.com>
Add a missing exception check.
https://bugs.webkit.org/show_bug.cgi?id=192626
<rdar://problem/46662163>
Reviewed by Keith Miller.
* runtime/ScopedArguments.h:
2018-12-13 Saam Barati <sbarati@apple.com>
The JSC shell should listen for memory pressure events and respond to them
https://bugs.webkit.org/show_bug.cgi?id=192647
Reviewed by Keith Miller.
We want the JSC shell to behave more like the WebContent process when
it comes to running performance tests. One way to make the shell
more like this is to have it respond to memory pressure events in
a similar way as the WebContent process. This makes it easier to run
benchmarks like JetStream2 on the CLI on iOS.
* jsc.cpp:
(jscmain):
* runtime/VM.cpp:
(JSC::VM::drainMicrotasks):
* runtime/VM.h:
(JSC::VM::setOnEachMicrotaskTick):
2018-12-13 Mark Lam <mark.lam@apple.com>
Ensure that StructureFlags initialization always starts with Base::StructureFlags.
https://bugs.webkit.org/show_bug.cgi?id=192686
Reviewed by Keith Miller.
This is purely a refactoring effort to make the code consistently start all
StructureFlags initialization with Base::StructureFlags. Previously, sometimes
Base::StructureFlags is appended at the end, and sometimes, it is expressed using
the name of the superclass. This patch makes the code all consistent and easier
to do a quick eye scan audit on to verify that no StructureFlags are forgetting
to inherit Base::StructureFlags.
Also added a static_assert in JSCallbackObject.h and JSBoundFunction.h. Both of
these implement a customHasInstance() method, and rely on ImplementsHasInstance
being included in the StructureFlags, and conversely, ImplementsDefaultHasInstance
has to be excluded.
JSBoundFunction.h is the only case where a bit (ImplementsDefaultHasInstance)
needs to be masked out of the inherited Base::StructureFlags.
* API/JSCallbackObject.h:
* runtime/ArrayConstructor.h:
* runtime/ArrayIteratorPrototype.h:
* runtime/Exception.h:
* runtime/FunctionRareData.h:
* runtime/InferredType.h:
* runtime/InferredTypeTable.h:
* runtime/InferredValue.h:
* runtime/JSBoundFunction.h:
* runtime/MapPrototype.h:
* runtime/SetPrototype.h:
* runtime/StringPrototype.h:
* runtime/SymbolConstructor.h:
2018-12-13 Mark Lam <mark.lam@apple.com>
Add the JSC_traceBaselineJITExecution option for tracing baseline JIT execution.
https://bugs.webkit.org/show_bug.cgi?id=192684
Reviewed by Saam Barati.
This dataLogs the bytecode execution order of baseline JIT code when the
JSC_traceBaselineJITExecution option is true.
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* runtime/Options.h:
2018-12-13 David Kilzer <ddkilzer@apple.com>
clang-tidy: Fix unnecessary object copies in JavaScriptCore
<https://webkit.org/b/192680>
<rdar://problem/46708767>
Reviewed by Mark Lam.
* assembler/testmasm.cpp:
(JSC::invoke):
- Make MacroAssemblerCodeRef<JSEntryPtrTag> argument a const
reference.
* b3/testb3.cpp:
(JSC::B3::checkDisassembly):
- Make CString argument a const reference.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileStringEquality):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetByIdWithThis):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetByIdWithThis):
- Make JITCompiler::JumpList arguments a const reference.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::checkStructure):
- Make RegisteredStructureSet argument a const reference.
* jsc.cpp:
(GlobalObject::moduleLoaderImportModule): Make local auto
variables const references.
(Workers::report): Make String argument a const reference.
(addOption): Make Identifier argument a const reference.
(runJSC): Make CString loop variable a const reference.
2018-12-13 Devin Rousso <drousso@apple.com>
Web Inspector: remove DOM.BackendNodeId and associated commands/events
https://bugs.webkit.org/show_bug.cgi?id=192478
Reviewed by Matt Baker.
* inspector/protocol/DOM.json:
2018-12-13 Caio Lima <ticaiolima@gmail.com>
[BigInt] Add ValueDiv into DFG
https://bugs.webkit.org/show_bug.cgi?id=186178
Reviewed by Yusuke Suzuki.
This patch is introducing a new node type called ValueDiv. This node
is responsible to handle Untyped and Bigint specialization of division
operator, while the ArithDiv variant handles Number/Boolean cases.
BigInt specialization generates following speedup into simple
benchmark:
noSpec changes
big-int-simple-div 10.6013+-0.4682 ^ 8.4518+-0.0943 ^ definitely 1.2543x faster
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::makeDivSafe):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupArithDiv):
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::arithNodeFlags):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueDiv):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGValidate.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileValueDiv):
(JSC::FTL::DFG::LowerDFGToB3::compileArithDiv):
(JSC::FTL::DFG::LowerDFGToB3::compileArithBitNot):
2018-12-13 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Unreviewed, build fix after r239153, part 2
https://bugs.webkit.org/show_bug.cgi?id=190047
* runtime/StructureRareDataInlines.h:
(JSC::StructureRareData::cachedOwnKeys const):
2018-12-13 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Unreviewed, build fix after r239153
https://bugs.webkit.org/show_bug.cgi?id=190047
* runtime/StructureRareDataInlines.h:
(JSC::StructureRareData::cachedOwnKeys const):
2018-12-10 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Optimize Object.keys by caching own keys results in StructureRareData
https://bugs.webkit.org/show_bug.cgi?id=190047
Reviewed by Keith Miller.
Object.keys is one of the most frequently used function in web-tooling-benchmarks (WTB).
Object.keys is dominant in lebab of WTB, and frequently called in babel and others.
Since our Structure knows the shape of JSObject, we can cache the result of Object.keys
in Structure (StructureRareData) as we cache JSPropertyNameEnumerator in StructureRareData.
This patch caches the result of Object.keys in StructureRareData. The cached array is created
as JSImmutableButterfly. And Object.keys creates CoW from this data. Currently, the lifetime
strategy of this JSImmutableButterfly is the same to cached JSPropertyNameEnumerator. It is
referenced from Structure, and collected when Structure is collected.
This improves several benchmarks in SixSpeed.
baseline patched
object-assign.es5 350.1710+-3.6303 ^ 226.0368+-4.7558 ^ definitely 1.5492x faster
for-of-object.es6 269.1941+-3.3430 ^ 127.9317+-2.3875 ^ definitely 2.1042x faster
And it improves WTB lebab by 11.8%.
Before: lebab: 6.10 runs/s
After: lebab: 6.82 runs/s
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* 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.cpp:
(JSC::DFG::Node::convertToNewArrayBuffer):
* dfg/DFGNode.h:
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileObjectKeys):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileObjectKeys):
* runtime/Intrinsic.cpp:
(JSC::intrinsicName):
* runtime/Intrinsic.h:
* runtime/JSImmutableButterfly.h:
(JSC::JSImmutableButterfly::createSentinel):
* runtime/ObjectConstructor.cpp:
(JSC::ownPropertyKeys):
* runtime/Structure.cpp:
(JSC::Structure::canCachePropertyNameEnumerator const):
* runtime/Structure.h:
* runtime/StructureInlines.h:
(JSC::Structure::setCachedOwnKeys):
(JSC::Structure::cachedOwnKeys const):
(JSC::Structure::canCacheOwnKeys const):
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::visitChildren):
(JSC::StructureRareData::cachedPropertyNameEnumerator const): Deleted.
(JSC::StructureRareData::setCachedPropertyNameEnumerator): Deleted.
* runtime/StructureRareData.h:
* runtime/StructureRareDataInlines.h:
(JSC::StructureRareData::cachedPropertyNameEnumerator const):
(JSC::StructureRareData::setCachedPropertyNameEnumerator):
(JSC::StructureRareData::cachedOwnKeys const):
(JSC::StructureRareData::cachedOwnKeysConcurrently const):
(JSC::StructureRareData::setCachedOwnKeys):
(JSC::StructureRareData::previousID const): Deleted.
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2018-12-12 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[DFG][FTL] Add NewSymbol
https://bugs.webkit.org/show_bug.cgi?id=192620
Reviewed by Saam Barati.
This patch introduces NewSymbol DFG node into DFG and FTL tiers. The main goal of this patch is not optimize
NewSymbol code faster. Rather than that, this patch intends to offer SpecSymbol type information into DFG's
data flow to optimize generated code in FTL backend.
We add NewSymbol DFG node, which may take an argument. If an argument is not given, NewSymbol is for `Symbol()`.
If an argument is given, ToString is emitted to this argument before passing it to NewSymbol. So NewSymbol node
itself does not perform any type checks. ToString performs effects, but NewSymbol doesn't have any side observable
effects. So we can decouple Symbol(description) call into NewSymbol(ToString(description)).
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGClobbersExitState.cpp:
(JSC::DFG::clobbersExitState):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGMayExit.cpp:
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewSymbol):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStoreBarrierInsertionPhase.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileNewSymbol):
2018-12-12 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[BigInt] Implement DFG/FTL typeof for BigInt
https://bugs.webkit.org/show_bug.cgi?id=192619
Reviewed by Keith Miller.
This patch implements typeof for BigInt in DFG and FTL. Our DFG and FTL tiers now correctly consider about BigInt
in the code generated for typeof.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::boolify): We add (SpecCell - SpecString) type filter for proven type since isString
check is already performed here.
(JSC::FTL::DFG::LowerDFGToB3::buildTypeOf): We use (SpecCell - SpecObject - SpecString) type filter for proven type
since String and Object are already checked here. If we know the proven type does not include Symbol type here, we
can omit the code for Symbol type.
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitTypeOf):
2018-12-11 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[BigInt] Simplify boolean context evaluation by leveraging JSString::offsetOfLength() == JSBigInt::offsetOfLength()
https://bugs.webkit.org/show_bug.cgi?id=192615
Reviewed by Saam Barati.
JSString and JSBigInt have similar concept in terms of the implementation.
Both are immutable, JSCells, and have length information. m_length is located
just after JSCell header part, we can ensure `JSString::offsetOfLength() == JSBigInt::offsetOfLength()`,
and it allows us to optimize the boolean context evaluation.
This patch leverages the above information to reduce the code size for the boolean context evaluation.
* ftl/FTLAbstractHeapRepository.cpp:
(JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::boolify):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitConvertValueToBoolean):
(JSC::AssemblyHelpers::branchIfValue):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::JSBigInt):
(JSC::JSBigInt::offsetOfLength): Deleted.
* runtime/JSBigInt.h:
2018-12-11 Justin Michaud <justin_michaud@apple.com>
Implement feature flag for CSS Typed OM
https://bugs.webkit.org/show_bug.cgi?id=192610
Reviewed by Ryosuke Niwa.
* Configurations/FeatureDefines.xcconfig:
2018-12-10 Don Olmstead <don.olmstead@sony.com>
Move ENABLE_RESOURCE_LOAD_STATISTICS to FeatureDefines.xcconfig
https://bugs.webkit.org/show_bug.cgi?id=192573
Reviewed by Simon Fraser.
* Configurations/FeatureDefines.xcconfig:
2018-12-10 Mark Lam <mark.lam@apple.com>
PropertyAttribute needs a CustomValue bit.
https://bugs.webkit.org/show_bug.cgi?id=191993
<rdar://problem/46264467>
Reviewed by Saam Barati.
This is because GetByIdStatus needs to distinguish CustomValue properties from
other types, and its only means of doing so is via the property's attributes.
Previously, there's nothing in the property's attributes that can indicate that
the property is a CustomValue.
We fix this by doing the following:
1. Added a PropertyAttribute::CustomValue bit.
2. Added a PropertyAttribute::CustomAccessorOrValue convenience bit mask that is
CustomAccessor | CustomValue.
3. Since CustomGetterSetter properties are only set via JSObject::putDirectCustomAccessor(),
we added a check in JSObject::putDirectCustomAccessor() to see if the attributes
bits include PropertyAttribute::CustomAccessor. If not, then the property
must be a CustomValue, and we'll add the PropertyAttribute::CustomValue bit
to the attributes bits.
This ensures that the property attributes is sufficient to tell us if the
property contains a CustomGetterSetter.
4. Updated all checks for PropertyAttribute::CustomAccessor to check for
PropertyAttribute::CustomAccessorOrValue instead if their intent is to check
for the presence of a CustomGetterSetter as opposed to checking specifically
for one that is used as a CustomAccessor.
This includes all the Structure transition code that needs to capture the
attributes change when a CustomValue has been added.
5. Filtered out the PropertyAttribute::CustomValue bit in PropertyDescriptor.
The fact that we're using a CustomGetterSetter as a CustomValue should remain
invisible to the descriptor. This is because the descriptor should describe
a CustomValue no differently from a plain value.
6. Added some asserts to ensure that property attributes are as expected, and to
document some invariants.
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFromLLInt):
(JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::GetByIdStatus::computeFor):
* bytecode/InByIdStatus.cpp:
(JSC::InByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
* bytecode/PropertyCondition.cpp:
(JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFor):
* runtime/JSFunction.cpp:
(JSC::getCalculatedDisplayName):
* runtime/JSObject.cpp:
(JSC::JSObject::putDirectCustomAccessor):
(JSC::JSObject::putDirectNonIndexAccessor):
(JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):
* runtime/JSObject.h:
(JSC::JSObject::putDirectIndex):
(JSC::JSObject::fillCustomGetterPropertySlot):
(JSC::JSObject::putDirect):
* runtime/JSObjectInlines.h:
(JSC::JSObject::putDirectInternal):
* runtime/PropertyDescriptor.cpp:
(JSC::PropertyDescriptor::setDescriptor):
(JSC::PropertyDescriptor::setCustomDescriptor):
(JSC::PropertyDescriptor::setAccessorDescriptor):
* runtime/PropertySlot.h:
(JSC::PropertySlot::setCustomGetterSetter):
2018-12-10 Mark Lam <mark.lam@apple.com>
LinkBuffer::copyCompactAndLinkCode() needs to be aware of ENABLE(SEPARATED_WX_HEAP).
https://bugs.webkit.org/show_bug.cgi?id=192569
<rdar://problem/45615617>
Reviewed by Saam Barati.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::copyCompactAndLinkCode):
2018-12-10 Caio Lima <ticaiolima@gmail.com>
[BigInt] Add ValueMul into DFG
https://bugs.webkit.org/show_bug.cgi?id=186175
Reviewed by Yusuke Suzuki.
This patch is adding a new DFG node called ValueMul. This node is
responsible to handle multiplication operations that can result into
non-number values. We emit such node during DFGByteCodeParser when the
operands are not numbers. During FixupPhase, we change this
operation to ArithMul if we can speculate Number/Boolean operands.
The BigInt specialization shows a small progression:
noSpec changes
big-int-simple-mul 18.8090+-1.0435 ^ 17.4305+-0.2673 ^ definitely 1.0791x faster
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::makeSafe):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupMultiplication):
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::arithNodeFlags):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueMul):
(JSC::DFG::SpeculativeJIT::compileArithMul):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGValidate.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileValueMul):
(JSC::FTL::DFG::LowerDFGToB3::compileArithMul):
2018-12-08 Mark Lam <mark.lam@apple.com>
Reduce size of PropertySlot and PutPropertySlot.
https://bugs.webkit.org/show_bug.cgi?id=192526
Reviewed by Keith Miller.
With some minor adjustments, we can reduce the size of PropertySlot from 80 bytes
(19 padding bytes) to 64 bytes (3 padding bytes), and PutPropertySlot from 40
bytes (4 padding bytes) to 32 bytes (0 padding bytes but with 6 unused bits).
These measurements are for a 64-bit build.
* runtime/PropertySlot.h:
* runtime/PutPropertySlot.h:
(JSC::PutPropertySlot::PutPropertySlot):
2018-12-08 Dominik Infuehr <dinfuehr@igalia.com>
Record right offset with aligned wide instructions
https://bugs.webkit.org/show_bug.cgi?id=192006
Reviewed by Yusuke Suzuki.
Aligning bytecode instructions inserts nops into the instruction stream.
Emitting an instruction did not record the actual start of the instruction with
aligned instructions, but the nop just before the actual instruction. This was
problematic with the StaticPropertyAnalyzer that used the wrong instruction offset.
* bytecode/InstructionStream.h:
(JSC::InstructionStream::MutableRef::clone):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::alignWideOpcode):
(JSC::BytecodeGenerator::emitCreateThis):
(JSC::BytecodeGenerator::emitNewObject):
* generator/Opcode.rb:
2018-12-07 Tadeu Zagallo <tzagallo@apple.com>
Align the metadata table on all platforms
https://bugs.webkit.org/show_bug.cgi?id=192050
<rdar://problem/46312674>
Reviewed by Mark Lam.
Although certain platforms don't require the metadata to be aligned,
values were being concurrently read and written to ValueProfiles,
which caused crashes since these operations are not atomic on unaligned
addresses.
* bytecode/Opcode.cpp:
(JSC::metadataAlignment):
* bytecode/Opcode.h:
* bytecode/UnlinkedMetadataTableInlines.h:
(JSC::UnlinkedMetadataTable::finalize):
2018-12-05 Mark Lam <mark.lam@apple.com>
speculationFromCell() should speculate non-Identifier strings as SpecString instead of SpecStringVar.
https://bugs.webkit.org/show_bug.cgi?id=192441
<rdar://problem/46480355>
Reviewed by Saam Barati.
This is because a regular String (non-Identifier) can be converted into an
Identifier. During DFG/FTL compilation, AbstractValue::checkConsistency() may
expect a value to be of type SpecStringVar, but the mutator thread may have
converted the string into an Identifier. This creates a race where
AbstractValue::checkConsistency() may fail because it sees a SpecStringIdent when
it expects the a SpecStringVar.
The fix is to speculate non-Identifier strings as type SpecString which allows it
to be SpecStringVar or SpecStringIndent.
* bytecode/SpeculatedType.cpp:
(JSC::speculationFromCell):
2018-12-04 Mark Lam <mark.lam@apple.com>
DFG's StrengthReduction phase should not reduce Construct into DirectContruct when the executable does not have constructAbility.
https://bugs.webkit.org/show_bug.cgi?id=192386
<rdar://problem/46445516>
Reviewed by Saam Barati.
This violates an invariant documented by a RELEASE_ASSERT in operationLinkDirectCall().
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
2018-12-04 Caio Lima <ticaiolima@gmail.com>
[ESNext][BigInt] Support logic operations
https://bugs.webkit.org/show_bug.cgi?id=179903
Reviewed by Yusuke Suzuki.
We are introducing in this patch the ToBoolean support for JSBigInt.
With this change, we can implement the correct behavior of BigInt as
operand of logical opertions. During JIT genertion into DFG and FTL,
we are using JSBigInt::m_length to verify if the number is 0n or not,
following the same approach used by JSString. This is also safe in the case
of BigInt, because only 0n has m_length == 0.
We are not including BigInt speculation into Branch nodes in this
patch, but the plan is to implement it in further patches.
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::boolify):
(JSC::FTL::DFG::LowerDFGToB3::isBigInt):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitConvertValueToBoolean):
(JSC::AssemblyHelpers::branchIfValue):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::isZero const):
(JSC::JSBigInt::offsetOfLength):
(JSC::JSBigInt::toBoolean const):
(JSC::JSBigInt::isZero): Deleted.
* runtime/JSBigInt.h:
* runtime/JSCellInlines.h:
(JSC::JSCell::toBoolean const):
(JSC::JSCell::pureToBoolean const):
2018-12-04 Devin Rousso <drousso@apple.com>
Web Inspector: Audit: tests should support async operations
https://bugs.webkit.org/show_bug.cgi?id=192171
<rdar://problem/46423562>
Reviewed by Joseph Pecoraro.
Add `awaitPromise` command for executing a callback when a Promise gets settled.
Drive-by: allow `wasThrown` to be optional, instead of expecting it to always have a value.
* inspector/protocol/Runtime.json:
* inspector/InjectedScriptSource.js:
(InjectedScript.prototype.awaitPromise): Added.
* inspector/InjectedScript.h:
* inspector/InjectedScript.cpp:
(Inspector::InjectedScript::evaluate):
(Inspector::InjectedScript::awaitPromise): Added.
(Inspector::InjectedScript::callFunctionOn):
(Inspector::InjectedScript::evaluateOnCallFrame):
* inspector/InjectedScriptBase.h:
* inspector/InjectedScriptBase.cpp:
(Inspector::InjectedScriptBase::makeEvalCall):
(Inspector::InjectedScriptBase::makeAsyncCall): Added.
(Inspector::InjcetedScriptBase::checkCallResult): Added.
(Inspector::InjcetedScriptBase::checkAsyncCallResult): Added.
* inspector/agents/InspectorRuntimeAgent.h:
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::evaluate):
(Inspector::InspectorRuntimeAgent::awaitPromise):
(Inspector::InspectorRuntimeAgent::callFunctionOn):
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::evaluateOnCallFrame):
2018-12-03 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r238833.
Breaks macOS and iOS debug builds.
Reverted changeset:
"[ESNext][BigInt] Support logic operations"
https://bugs.webkit.org/show_bug.cgi?id=179903
https://trac.webkit.org/changeset/238833
2018-12-03 Caio Lima <ticaiolima@gmail.com>
[ESNext][BigInt] Support logic operations
https://bugs.webkit.org/show_bug.cgi?id=179903
Reviewed by Yusuke Suzuki.
We are introducing in this patch the ToBoolean support for JSBigInt.
With this change, we can implement the correct behavior of BigInt as
operand of logical opertions. During JIT genertion into DFG and FTL,
we are using JSBigInt::m_length to verify if the number is 0n or not,
following the same approach used by JSString. This is also safe in the case
of BigInt, because only 0n has m_length == 0.
We are not including BigInt speculation into Branch nodes in this
patch, but the plan is to implement it in further patches.
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::boolify):
(JSC::FTL::DFG::LowerDFGToB3::isBigInt):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitConvertValueToBoolean):
(JSC::AssemblyHelpers::branchIfValue):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::isZero const):
(JSC::JSBigInt::offsetOfLength):
(JSC::JSBigInt::toBoolean const):
(JSC::JSBigInt::isZero): Deleted.
* runtime/JSBigInt.h:
* runtime/JSCellInlines.h:
(JSC::JSCell::toBoolean const):
(JSC::JSCell::pureToBoolean const):
2018-12-03 Keith Rollin <krollin@apple.com>
Add .xcfilelist files
https://bugs.webkit.org/show_bug.cgi?id=192082
<rdar://problem/46312533>
Reviewed by Brent Fulgham.
Add .xcfilelist files for Generate Derived Sources and Generate
Unified Sources build phases in Xcode. These are just being staged for
now; they'll be added to the Xcode projects later.
* DerivedSources-input.xcfilelist: Added.
* DerivedSources-output.xcfilelist: Added.
* UnifiedSources-input.xcfilelist: Added.
* UnifiedSources-output.xcfilelist: Added.
2018-12-03 Mark Lam <mark.lam@apple.com>
Fix the bytecode code generator scripts to pretty print BytecodeStructs.h and BytecodeIndices.h.
https://bugs.webkit.org/show_bug.cgi?id=192271
Reviewed by Keith Miller.
This makes the generated code style compliant and human readable.
* generator/Argument.rb:
* generator/DSL.rb:
* generator/Fits.rb:
* generator/Metadata.rb:
* generator/Opcode.rb:
2018-12-02 Zalan Bujtas <zalan@apple.com>
Add a runtime feature flag for LayoutFormattingContext.
https://bugs.webkit.org/show_bug.cgi?id=192280
Reviewed by Simon Fraser.
* Configurations/FeatureDefines.xcconfig:
2018-12-02 Caio Lima <ticaiolima@gmail.com>
[ESNext][BigInt] Implement support for "<<" and ">>"
https://bugs.webkit.org/show_bug.cgi?id=186233
Reviewed by Yusuke Suzuki.
This patch is introducing the support for BigInt into lshift and
rshift into LLint and Baseline layers.
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::createWithLength):
(JSC::JSBigInt::leftShift):
(JSC::JSBigInt::signedRightShift):
(JSC::JSBigInt::leftShiftByAbsolute):
(JSC::JSBigInt::rightShiftByAbsolute):
(JSC::JSBigInt::rightShiftByMaximum):
(JSC::JSBigInt::toShiftAmount):
* runtime/JSBigInt.h:
2018-12-01 Simon Fraser <simon.fraser@apple.com>
Heap.h refers to the non-existent HeapStatistics
https://bugs.webkit.org/show_bug.cgi?id=187882
Reviewed by Keith Miller.
Just remove the "friend class HeapStatistics".
* heap/Heap.h:
2018-11-29 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Keep TypeMaybeBigInt small
https://bugs.webkit.org/show_bug.cgi?id=192203
Reviewed by Saam Barati.
As BigInt is being implemented, more and more bytecodes start returning BigInt.
It means that ResultType of these bytecodes include TypeMaybeBigInt. However,
TypeMaybeBigInt was large number 0x20, leading to wide instruction since ResultType
easily becomes larger than 32 (e.g. TypeInt32 | TypeMaybeBigInt == 33).
This patch sorts the numbers of TypeMaybeXXX based on the frequency of appearance in
the code.
* parser/ResultType.h:
2018-11-30 Dean Jackson <dino@apple.com>
Try to fix Windows build by using strcmp instead of strcasecmp.
* jsc.cpp:
(isMJSFile):
2018-11-30 Mark Lam <mark.lam@apple.com>
Fix the bytecode code generator scripts to pretty print Bytecodes.h.
https://bugs.webkit.org/show_bug.cgi?id=192258
Reviewed by Keith Miller.
This makes Bytecodes.h more human readable.
* generator/DSL.rb:
* generator/Section.rb:
2018-11-30 Mark Lam <mark.lam@apple.com>
Add the generator directory to the Xcode project.
https://bugs.webkit.org/show_bug.cgi?id=192252
Reviewed by Michael Saboff.
This is so that we can work with these bytecode class generator files easily in Xcode.
* JavaScriptCore.xcodeproj/project.pbxproj:
2018-11-30 Don Olmstead <don.olmstead@sony.com>
Rename ENABLE_SUBTLE_CRYPTO to ENABLE_WEB_CRYPTO
https://bugs.webkit.org/show_bug.cgi?id=192197
Reviewed by Jiewen Tan.
* Configurations/FeatureDefines.xcconfig:
2018-11-30 Dean Jackson <dino@apple.com>
Add first-class support for .mjs files in jsc binary
https://bugs.webkit.org/show_bug.cgi?id=192190
<rdar://problem/46375715>
Reviewed by Keith Miller.
Treat files with a .mjs extension as a module, regardless
of whether or not the --module-file argument was given.
* jsc.cpp:
(printUsageStatement): Update usage.
(isMJSFile): Helper to look for .mjs extensions.
(CommandLine::parseArguments): Pick the appropriate script type.
2018-11-30 Caio Lima <ticaiolima@gmail.com>
[BigInt] Implement ValueBitXor into DFG
https://bugs.webkit.org/show_bug.cgi?id=190264
Reviewed by Yusuke Suzuki.
This patch is splitting the BitXor node into ArithBitXor and
ValueBitXor. This is necessary due the introduction of
BigInt, since BitXor operations now can result into Int32 or BigInt.
In such case, we use ArithBitXor when operands are Int and fallback to
ValueBitXor when operands are anything else. In the case of
ValueBitXor, we speculate BigInt when op1 and op2 are predicted as
BigInt as well. BigInt specialization consist into call
`operationBigIntBitXor` function, that calls JSBigInt::bitXor.
* bytecode/BytecodeList.rb:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::arithProfileForPC):
* bytecode/Opcode.h:
(JSC::padOpcodeName):
* bytecompiler/BytecodeGenerator.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo):
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueBitwiseOp):
(JSC::DFG::SpeculativeJIT::compileBitwiseOp):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::bitOp):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileValueBitXor):
(JSC::FTL::DFG::LowerDFGToB3::compileArithBitXor):
(JSC::FTL::DFG::LowerDFGToB3::compileBitXor): Deleted.
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_bitxor):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
2018-11-29 Justin Michaud <justin_michaud@apple.com>
CSS Painting API should pass 'this' correctly to paint callback, and repaint when properties change.
https://bugs.webkit.org/show_bug.cgi?id=191443
Reviewed by Dean Jackson.
Export the simpler construct() method for use in WebCore.
* runtime/ConstructData.h:
2018-11-28 Mark Lam <mark.lam@apple.com>
ENABLE_SEPARATED_WX_HEAP needs to be defined in Platform.h.
https://bugs.webkit.org/show_bug.cgi?id=192110
<rdar://problem/46317746>
Reviewed by Saam Barati.
* config.h:
2018-11-28 Keith Rollin <krollin@apple.com>
Update generate-{derived,unified}-sources scripts to support generating .xcfilelist files
https://bugs.webkit.org/show_bug.cgi?id=192031
<rdar://problem/46286816>
Reviewed by Alex Christensen.
The Generate Derived Sources and Generate Unified Sources build phases
in Xcode need to have their inputs and outputs specified. This
specification will come in the form of .xcfilelist files that will be
attached to these build phases. There is one .xcfilelist file that
lists the input file and one that lists the output files. As part of
this work, the various generate-{derived,unified}-sources scripts that
are executed in these Generate build phases are modified to help in
the creation of these .xcfilelist files. In particular, they can now
be invoked with command-line parameters. These parameters are then
used to alter the normal execution of these scripts, causing them to
produce the .xcfilelist files as opposed to actually generating the
files that are listed in those files.
* Scripts/generate-derived-sources.sh:
* Scripts/generate-unified-sources.sh:
2018-11-28 Keith Rollin <krollin@apple.com>
Revert print_all_generated_files work in r238008; tighten up target specifications
https://bugs.webkit.org/show_bug.cgi?id=192025
<rdar://problem/46284301>
Reviewed by Alex Christensen.
In r238008, I added a facility for DerivedSources.make makefiles to
print out the list of files that they generate. This output was used
in the generation of .xcfilelist files used to specify the output of
the associated Generate Derived Sources build phases in Xcode. This
approach worked, but it meant that people would need to follow a
specific convention to keep this mechanism working.
Instead of continuing this approach, I'm going to implement a new
facility based on the output of `make` when passed the -d flag (which
prints dependency information). This new mechanism is completely
automatic and doesn't need maintainers to follow a convention. To that
end, remove most of the work performed in r238008 that supports the
print_all_generated_files target.
At the same time, it's important for the sets of targets and their
dependencies to be complete and correct. Therefore, also include
changes to bring those up-to-date. As part of that, you'll see
prevalent use of a particular technique. Here's an example:
BYTECODE_FILES = \
Bytecodes.h \
BytecodeIndices.h \
BytecodeStructs.h \
InitBytecodes.asm \
#
BYTECODE_FILES_PATTERNS = $(subst .,%,$(BYTECODE_FILES))
all : $(BYTECODE_FILES)
$(BYTECODE_FILES_PATTERNS): $(wildcard $(JavaScriptCore)/generator/*.rb) $(JavaScriptCore)/bytecode/BytecodeList.rb
...
These lines indicate a set of generated files (those specified in
BYTECODE_FILES). These files are generated by the BytecodeList.rb
tool. But, as opposed to the normal rule where a single foo.output is
generated by foo.input plus some additional dependencies, this rule
produces multiple output files from a tool whose connection to the
output files is not immediately clear. A special approach is needed
where a single rule produces multiple output files. The normal way to
implement this is to use an .INTERMEDIATE target. However, we used
this approach in the past and ran into a problem with it, addressing
it with an alternate approach in r210507. The above example shows this
approach. The .'s in the list of target files are replaced with %'s,
and the result is used as the left side of the dependency rule.
* DerivedSources.make:
2018-11-28 Keith Rollin <krollin@apple.com>
Remove Postprocess Headers dependencies
https://bugs.webkit.org/show_bug.cgi?id=192023
<rdar://problem/46283377>
Reviewed by Mark Lam.
JavaScriptCore's Xcode Postprocess Headers build phase used to have a
dependency on a specific handful of files. In r234227, the script used
in this phase (postprocess-headers.sh) was completely rewritten to
operate on *all* files in JSC's Public and Private headers directories
instead of just this handful. This rewrite makes the previous
dependency specification insufficient, leading to incorrect
incremental builds if the right files weren't touched. Address this by
removing the dependencies completely. This will cause
postprocess-headers.sh to always be executed, even when none of its
files are touch. Running this script all the time is OK, since it has
built-in protections against unnecessarily touching files that haven't
changed.
* JavaScriptCore.xcodeproj/project.pbxproj:
2018-11-27 Mark Lam <mark.lam@apple.com>
ENABLE_FAST_JIT_PERMISSIONS should be false for iosmac.
https://bugs.webkit.org/show_bug.cgi?id=192055
<rdar://problem/46288783>
Reviewed by Saam Barati.
* Configurations/FeatureDefines.xcconfig:
2018-11-27 Saam barati <sbarati@apple.com>
r238510 broke scopes of size zero
https://bugs.webkit.org/show_bug.cgi?id=192033
<rdar://problem/46281734>
Reviewed by Keith Miller.
In r238510, I wrote the loop like this:
`for (ScopeOffset offset { 0 }; offset <= symbolTable->maxScopeOffset(); offset += 1)`
This breaks for scopes of size zero because maxScopeOffset() will be UINT_MAX.
This patch fixes this by writing the loop as:
`for (unsigned offset = 0; offset < symbolTable->scopeSize(); ++offset)`
* dfg/DFGObjectAllocationSinkingPhase.cpp:
2018-11-27 Mark Lam <mark.lam@apple.com>
ASSERTION FAILED: capacity && isPageAligned(capacity) in JSC::CLoopStack::CLoopStack(JSC::VM&).
https://bugs.webkit.org/show_bug.cgi?id=192018
Reviewed by Saam Barati.
This assertion failed because the regress-191579.js test was specifying
--maxPerThreadStackUsage=400000 i.e. it was running with a stack size that is not
page aligned. Given that the user can specify any arbitrary stack size, and the
CLoop stack expects to be page aligned, we'll just round up the requested capacity
to the next page alignment.
* interpreter/CLoopStack.cpp:
(JSC::CLoopStack::CLoopStack):
2018-11-27 Mark Lam <mark.lam@apple.com>
[Re-landing] NaNs read from Wasm code needs to be be purified.
https://bugs.webkit.org/show_bug.cgi?id=191056
<rdar://problem/45660341>
Reviewed by Filip Pizlo.
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
2018-11-27 Timothy Hatcher <timothy@apple.com>
Web Inspector: Add support for forcing color scheme appearance in DOM tree.
https://bugs.webkit.org/show_bug.cgi?id=191820
rdar://problem/46153172
Reviewed by Devin Rousso.
* inspector/protocol/Page.json: Added setForcedAppearance.
Also added the defaultAppearanceDidChange event and Appearance enum.
2018-11-27 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r238509.
Causes JSC tests to fail on iOS.
Reverted changeset:
"NaNs read from Wasm code needs to be be purified."
https://bugs.webkit.org/show_bug.cgi?id=191056
https://trac.webkit.org/changeset/238509
2018-11-27 Mark Lam <mark.lam@apple.com>
Introducing a ENABLE_SEPARATED_WX_HEAP macro.
https://bugs.webkit.org/show_bug.cgi?id=192013
<rdar://problem/45494310>
Reviewed by Keith Miller.
This makes the code a little more readable.
I put the definition of ENABLE_SEPARATED_WX_HEAP in JSC's config.h instead of
Platform.h because ENABLE_SEPARATED_WX_HEAP is only needed inside JSC. Also,
ENABLE_SEPARATED_WX_HEAP depends on ENABLE(FAST_JIT_PERMISSIONS), which is only
defined for JSC.
* config.h:
* jit/ExecutableAllocator.cpp:
(JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
(JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
* jit/ExecutableAllocator.h:
(JSC::performJITMemcpy):
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
2018-11-26 Caio Lima <ticaiolima@gmail.com>
Re-introduce op_bitnot
https://bugs.webkit.org/show_bug.cgi?id=190923
Reviewed by Yusuke Suzuki.
With the introduction of BigInt as a new type, we can't emit bitwise
not as `x ^ -1` anymore, because this is incompatible with the new type.
Based on that, this Patch is adding `op_bitnot` as a new operation
into LLInt, as well as introducing ArithBitNot node into DFG to support
JIT compilation of such opcode. We will use the ValueProfile of this
intruction in the future to generate better code when its operand
is not Int32.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::not32):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::not32):
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::not32):
* bytecode/BytecodeList.rb:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* bytecode/Opcode.h:
(JSC::padOpcodeName):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitUnaryOp):
* bytecompiler/NodesCodegen.cpp:
(JSC::UnaryPlusNode::emitBytecode):
(JSC::BitwiseNotNode::emitBytecode): Deleted.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileBitwiseNot):
* 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::compileArithBitNot):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JIT.h:
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_bitnot):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* offlineasm/cloop.rb:
* parser/NodeConstructors.h:
(JSC::BitwiseNotNode::BitwiseNotNode):
* parser/Nodes.h:
* parser/ResultType.h:
(JSC::ResultType::bigIntOrInt32Type):
(JSC::ResultType::forBitOp):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
2018-11-26 Saam barati <sbarati@apple.com>
InPlaceAbstractState::endBasicBlock rule for SetLocal should filter the value based on the flush format
https://bugs.webkit.org/show_bug.cgi?id=191956
<rdar://problem/45665806>
Reviewed by Yusuke Suzuki.
This is a similar bug to what Keith fixed in r232134. The issue is if we have
a program like this:
a: JSConstant(jsNumber(0))
b: SetLocal(Int32:@a, loc1, FlushedInt32)
c: ArrayifyToStructure(Cell:@a)
d: Jump(...)
At the point in the program right after the Jump, a GetLocal for loc1
would return whatever the ArrayifyToStructure resulting type is. This breaks
the invariant that a GetLocal must return a value that is a subtype of its
FlushFormat. InPlaceAbstractState::endBasicBlock will know if a SetLocal is
the final node touching a local slot. If so, it'll see if any nodes later
in the block may have refined the type of the value stored in that slot. If
so, endBasicBlock() further refines the type to ensure that any GetLocals
loading from the same slot will result in having this more refined type.
However, we must ensure that this logic only considers types within the
hierarchy of the variable access data's FlushFormat, otherwise, we may
break the invariant that a GetLocal's type is a subtype of its FlushFormat.
* dfg/DFGInPlaceAbstractState.cpp:
(JSC::DFG::InPlaceAbstractState::endBasicBlock):
2018-11-26 Saam barati <sbarati@apple.com>
Object allocation sinking phase needs to iterate each scope offset instead of just iterating the symbol table's hashmap when handling an activation
https://bugs.webkit.org/show_bug.cgi?id=191958
<rdar://problem/46221877>
Reviewed by Yusuke Suzuki.
There may be more entries in an activation than unique variables
in a symbol table's hashmap. For example, if you have two parameters
to a function, and they both are the same name, and the function
uses eval, we'll end up with two scope slots, but only a single
entry in the hashmap in the symbol table. Object allocation sinking
phase was previously iterating over the hashmap, assuming these
values were equivalent. This is wrong in the above case. Instead,
we need to iterate over each scope offset.
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* runtime/GenericOffset.h:
(JSC::GenericOffset::operator+=):
(JSC::GenericOffset::operator-=):
2018-11-26 Mark Lam <mark.lam@apple.com>
NaNs read from Wasm code needs to be be purified.
https://bugs.webkit.org/show_bug.cgi?id=191056
<rdar://problem/45660341>
Reviewed by Filip Pizlo.
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
2018-11-26 Tadeu Zagallo <tzagallo@apple.com>
ASSERTION FAILED: m_outOfLineJumpTargets.contains(bytecodeOffset)
https://bugs.webkit.org/show_bug.cgi?id=191716
<rdar://problem/45723878>
Reviewed by Saam Barati.
After https://bugs.webkit.org/show_bug.cgi?id=187373, when updating
jump targets during generatorification, we only stored the new jump
target when it changed. However, the out-of-line jump targets are
cleared at the beginning of the pass, so we need to store it
unconditionally.
* bytecode/PreciseJumpTargetsInlines.h:
(JSC::extractStoredJumpTargetsForInstruction):
(JSC::updateStoredJumpTargetsForInstruction):
2018-11-23 Wenson Hsieh <wenson_hsieh@apple.com>
Enable drag and drop support for iOSMac
https://bugs.webkit.org/show_bug.cgi?id=191818
<rdar://problem/43907454>
Reviewed by Dean Jackson.
* Configurations/FeatureDefines.xcconfig:
2018-11-22 Mark Lam <mark.lam@apple.com>
Make the jsc shell's dumpException() more robust against long exception strings.
https://bugs.webkit.org/show_bug.cgi?id=191910
<rdar://problem/46212980>
Reviewed by Michael Saboff.
This only affects the dumping of the exception string in the jsc shell due to
unhandled exceptions or exceptions at shell boot time before any JS code is
running.
* jsc.cpp:
(dumpException):
2018-11-21 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Drop ARM_TRADITIONAL support in LLInt, baseline JIT, and DFG
https://bugs.webkit.org/show_bug.cgi?id=191675
Reviewed by Mark Lam.
We no longer maintain ARM_TRADITIONAL LLInt and JIT in JSC. This architecture will use
CLoop instead. This patch removes ARM_TRADITIONAL support in LLInt and JIT.
Discussed in https://lists.webkit.org/pipermail/webkit-dev/2018-October/030220.html.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* assembler/ARMAssembler.cpp: Removed.
* assembler/ARMAssembler.h: Removed.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::linkCode):
(JSC::LinkBuffer::dumpCode):
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::patchableBranch32):
* assembler/MacroAssemblerARM.cpp: Removed.
* assembler/MacroAssemblerARM.h: Removed.
* assembler/PerfLog.cpp:
* assembler/PerfLog.h:
* assembler/ProbeContext.h:
(JSC::Probe::CPUState::pc):
(JSC::Probe::CPUState::fp):
(JSC::Probe::CPUState::sp):
* assembler/testmasm.cpp:
(JSC::isPC):
(JSC::testProbeModifiesStackPointer):
(JSC::testProbeModifiesStackValues):
* bytecode/InlineAccess.h:
(JSC::InlineAccess::sizeForPropertyAccess):
(JSC::InlineAccess::sizeForPropertyReplace):
(JSC::InlineAccess::sizeForLengthAccess):
* dfg/DFGSpeculativeJIT.h:
* disassembler/CapstoneDisassembler.cpp:
(JSC::tryToDisassemble):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::debugCall):
* jit/AssemblyHelpers.h:
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsImpl):
(JSC::CCallHelpers::prepareForTailCallSlow):
* jit/CallFrameShuffler.cpp:
(JSC::CallFrameShuffler::prepareForTailCall):
* jit/HostCallReturnValue.cpp:
* jit/JITMathIC.h:
(JSC::isProfileEmpty):
* jit/RegisterSet.cpp:
(JSC::RegisterSet::reservedHardwareRegisters):
(JSC::RegisterSet::calleeSaveRegisters):
(JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
(JSC::RegisterSet::dfgCalleeSaveRegisters):
* jit/Repatch.cpp:
(JSC::forceICFailure):
* jit/ThunkGenerators.cpp:
(JSC::nativeForGenerator):
* llint/LLIntOfflineAsmConfig.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* offlineasm/arm.rb:
* offlineasm/backends.rb:
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::generateEnter):
(JSC::Yarr::YarrGenerator::generateReturn):
2018-11-21 Saam barati <sbarati@apple.com>
DFGSpeculativeJIT should not &= exitOK with mayExit(node)
https://bugs.webkit.org/show_bug.cgi?id=191897
<rdar://problem/45871998>
Reviewed by Mark Lam.
exitOK is a statement about it being legal to exit. mayExit() is about being
conservative and returning false only if an OSR exit *could never* happen.
mayExit() tries to be as smart as possible to see if it can return false.
It can't return false if a runtime exit *could* happen. However, there is
code in the compiler where mayExit() returns false (because it uses data
generated from AI about type checks being proved), but the code we emit in the
compiler backend unconditionally generates an OSR exit, even if that exit may
never execute. For example, let's say we have this IR:
SomeNode(Boolean:@input)
And we always emit code like this as a way of emitting a boolean type check:
jump L1 if input == true
jump L1 if input == false
emit an OSR exit
In such a program, when we generate the above OSR exit, in a validationEnabled()
build, and if @input is proved to be a boolean, we'll end up crashing because we
have the bogus assertion saying !exitOK. This is one reason why things are cleaner
if we don't conflate mayExit() with exitOK.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2018-11-21 Saam barati <sbarati@apple.com>
Fix assertion in KnownCellUse inside SpeculativeJIT::speculate
https://bugs.webkit.org/show_bug.cgi?id=191895
<rdar://problem/46167406>
Reviewed by Mark Lam.
We were asserting that the input edge should have type SpecCell but it should
really be SpecCellCheck since the type filter for KnownCellUse is SpecCellCheck.
This patch cleans up that assertion code by joining a bunch of cases into a
single function call which grabs the type filter for the edge UseKind and
asserts that the incoming edge meets the type filter criteria.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::speculate):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::speculate):
2018-11-21 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Use ProtoCallFrame::numberOfRegisters instead of raw number `4`
https://bugs.webkit.org/show_bug.cgi?id=191877
Reviewed by Sam Weinig.
Instead of hard-coding `4` into LowLevelInterpreter, use ProtoCallFrame::numberOfRegisters.
* interpreter/ProtoCallFrame.h:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2018-11-21 Mark Lam <mark.lam@apple.com>
Creating a wasm memory that is bigger than the ArrayBuffer limit but smaller than the spec limit should throw OOME not RangeError.
https://bugs.webkit.org/show_bug.cgi?id=191776
<rdar://problem/46152851>
Reviewed by Saam Barati.
* wasm/WasmMemory.cpp:
(JSC::Wasm::Memory::tryCreate):
- return nullptr if the requested bytes exceed MAX_ARRAY_BUFFER_SIZE.
The clients will already do a null check and throw an OutOfMemoryError if needed.
(JSC::Wasm::Memory::grow):
- throw OOME if newPageCount.bytes() > MAX_ARRAY_BUFFER_SIZE.
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::constructJSWebAssemblyMemory):
- throw OOME if newPageCount.bytes() > MAX_ARRAY_BUFFER_SIZE.
2018-11-21 Caio Lima <ticaiolima@gmail.com>
[BigInt] JSBigInt::createWithLength should throw when length is greater than JSBigInt::maxLength
https://bugs.webkit.org/show_bug.cgi?id=190836
Reviewed by Saam Barati and Yusuke Suzuki.
In this patch we are creating a new method called `JSBigInt::createWithLengthUnchecked`
where we allocate a BigInt trusting the length received as argument.
With this additional method, we now check if length passed to
`JSBigInt::tryCreateWithLength` is not greater than JSBigInt::maxLength.
When the length is greater than JSBigInt::maxLength, we then throw OOM
exception.
This required us to change the interface of some JSBigInt operations to
receive `ExecState*` instead of `VM&`. We changed only operations that
can throw because of OOM.
We beleive that this approach of throwing instead of finishing the
execution abruptly is better because JS programs can catch such
exception and handle this issue properly.
* dfg/DFGOperations.cpp:
* jit/JITOperations.cpp:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::createZero):
(JSC::JSBigInt::tryCreateWithLength):
(JSC::JSBigInt::createWithLengthUnchecked):
(JSC::JSBigInt::createFrom):
(JSC::JSBigInt::multiply):
(JSC::JSBigInt::divide):
(JSC::JSBigInt::copy):
(JSC::JSBigInt::unaryMinus):
(JSC::JSBigInt::remainder):
(JSC::JSBigInt::add):
(JSC::JSBigInt::sub):
(JSC::JSBigInt::bitwiseAnd):
(JSC::JSBigInt::bitwiseOr):
(JSC::JSBigInt::bitwiseXor):
(JSC::JSBigInt::absoluteAdd):
(JSC::JSBigInt::absoluteSub):
(JSC::JSBigInt::absoluteDivWithDigitDivisor):
(JSC::JSBigInt::absoluteDivWithBigIntDivisor):
(JSC::JSBigInt::absoluteLeftShiftAlwaysCopy):
(JSC::JSBigInt::absoluteBitwiseOp):
(JSC::JSBigInt::absoluteAddOne):
(JSC::JSBigInt::absoluteSubOne):
(JSC::JSBigInt::toStringGeneric):
(JSC::JSBigInt::rightTrim):
(JSC::JSBigInt::allocateFor):
(JSC::JSBigInt::createWithLength): Deleted.
* runtime/JSBigInt.h:
* runtime/Operations.cpp:
(JSC::jsAddSlowCase):
* runtime/Operations.h:
(JSC::jsSub):
(JSC::jsMul):
2018-11-20 Mark Lam <mark.lam@apple.com>
Remove invalid assertion in VMTraps::SignalSender's SignalAction.
https://bugs.webkit.org/show_bug.cgi?id=191856
<rdar://problem/46089992>
Reviewed by Yusuke Suzuki.
The ASSERT(vm.traps().needTrapHandling()) assertion in SignalSender's SigAction
function is invalid because we can't be sure that the trap has been handled yet
by the time the trap fires. This is because the main thread may also check traps
(in LLInt, baseline JIT and VM runtime code). There's a race to handle the trap.
Hence, the SigAction cannot assume that the trap still needs handling by the time
it is executed. This patch removed the invalid assertion.
Also renamed m_trapSet to m_condition because it is a AutomaticThreadCondition,
and all the ways it is used is as a condvar. The m_trapSet name doesn't seem
appropriate nor meaningful.
* runtime/VMTraps.cpp:
(JSC::VMTraps::tryInstallTrapBreakpoints):
- Added a !needTrapHandling() check as an optimization: there's no need to install
VMTrap breakpoints if someone already beat us to handling the trap (remember,
the main thread is racing against the VMTraps signalling thread to handle the
trap too). We only need to install the VMTraps breakpoints if we need DFG/FTL
compiled code to deopt so that they can check and handle pending traps. If the
trap has already been handled, it's better to not deopt any DFG/FTL functions.
(JSC::VMTraps::willDestroyVM):
(JSC::VMTraps::fireTrap):
(JSC::VMTraps::VMTraps):
* runtime/VMTraps.h:
2018-11-21 Dominik Infuehr <dinfuehr@igalia.com>
Enable JIT on ARM/Linux
https://bugs.webkit.org/show_bug.cgi?id=191548
Reviewed by Yusuke Suzuki.
Enable JIT by default on ARMv7/Linux after it was disabled with
recent bytcode format change.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::getICStatusMap):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::metadata):
* bytecode/InByIdStatus.cpp:
(JSC::InByIdStatus::computeFor):
* bytecode/Instruction.h:
(JSC::Instruction::cast):
* bytecode/MetadataTable.h:
(JSC::MetadataTable::forEach):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFor):
(JSC::PutByIdStatus::hasExitSite): Deleted.
* bytecode/PutByIdStatus.h:
* dfg/DFGOSRExit.cpp:
(JSC::DFG::reifyInlinedCallFrames):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
* generator/Argument.rb:
* generator/Opcode.rb:
* jit/GPRInfo.h:
* jit/JIT.h:
* jit/JITArithmetic32_64.cpp:
(JSC::JIT::emit_compareAndJump):
(JSC::JIT::emit_compareUnsignedAndJump):
(JSC::JIT::emit_compareUnsigned):
(JSC::JIT::emit_compareAndJumpSlow):
(JSC::JIT::emit_op_unsigned):
(JSC::JIT::emit_op_inc):
(JSC::JIT::emit_op_dec):
(JSC::JIT::emitBinaryDoubleOp):
(JSC::JIT::emit_op_mod):
(JSC::JIT::emitSlow_op_mod):
* jit/JITCall32_64.cpp:
(JSC::JIT::emitPutCallResult):
(JSC::JIT::emit_op_ret):
(JSC::JIT::emitSlow_op_call):
(JSC::JIT::emitSlow_op_tail_call):
(JSC::JIT::emitSlow_op_call_eval):
(JSC::JIT::emitSlow_op_call_varargs):
(JSC::JIT::emitSlow_op_tail_call_varargs):
(JSC::JIT::emitSlow_op_tail_call_forward_arguments):
(JSC::JIT::emitSlow_op_construct_varargs):
(JSC::JIT::emitSlow_op_construct):
(JSC::JIT::emit_op_call):
(JSC::JIT::emit_op_tail_call):
(JSC::JIT::emit_op_call_eval):
(JSC::JIT::emit_op_call_varargs):
(JSC::JIT::emit_op_tail_call_varargs):
(JSC::JIT::emit_op_tail_call_forward_arguments):
(JSC::JIT::emit_op_construct_varargs):
(JSC::JIT::emit_op_construct):
(JSC::JIT::compileSetupFrame):
(JSC::JIT::compileCallEval):
(JSC::JIT::compileCallEvalSlowCase):
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
(JSC::JIT::compileSetupVarargsFrame): Deleted.
* jit/JITInlines.h:
(JSC::JIT::updateTopCallFrame):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_catch):
(JSC::JIT::emitSlow_op_loop_hint):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_mov):
(JSC::JIT::emit_op_end):
(JSC::JIT::emit_op_jmp):
(JSC::JIT::emit_op_new_object):
(JSC::JIT::emitSlow_op_new_object):
(JSC::JIT::emit_op_overrides_has_instance):
(JSC::JIT::emit_op_instanceof):
(JSC::JIT::emit_op_instanceof_custom):
(JSC::JIT::emitSlow_op_instanceof):
(JSC::JIT::emitSlow_op_instanceof_custom):
(JSC::JIT::emit_op_is_empty):
(JSC::JIT::emit_op_is_undefined):
(JSC::JIT::emit_op_is_boolean):
(JSC::JIT::emit_op_is_number):
(JSC::JIT::emit_op_is_cell_with_type):
(JSC::JIT::emit_op_is_object):
(JSC::JIT::emit_op_to_primitive):
(JSC::JIT::emit_op_set_function_name):
(JSC::JIT::emit_op_not):
(JSC::JIT::emit_op_jfalse):
(JSC::JIT::emit_op_jtrue):
(JSC::JIT::emit_op_jeq_null):
(JSC::JIT::emit_op_jneq_null):
(JSC::JIT::emit_op_jneq_ptr):
(JSC::JIT::emit_op_eq):
(JSC::JIT::emitSlow_op_eq):
(JSC::JIT::emit_op_jeq):
(JSC::JIT::emitSlow_op_jeq):
(JSC::JIT::emit_op_neq):
(JSC::JIT::emitSlow_op_neq):
(JSC::JIT::emit_op_jneq):
(JSC::JIT::emitSlow_op_jneq):
(JSC::JIT::compileOpStrictEq):
(JSC::JIT::emit_op_stricteq):
(JSC::JIT::emit_op_nstricteq):
(JSC::JIT::compileOpStrictEqJump):
(JSC::JIT::emit_op_jstricteq):
(JSC::JIT::emit_op_jnstricteq):
(JSC::JIT::emitSlow_op_jstricteq):
(JSC::JIT::emitSlow_op_jnstricteq):
(JSC::JIT::emit_op_eq_null):
(JSC::JIT::emit_op_neq_null):
(JSC::JIT::emit_op_throw):
(JSC::JIT::emit_op_to_number):
(JSC::JIT::emit_op_to_string):
(JSC::JIT::emit_op_to_object):
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_identity_with_profile):
(JSC::JIT::emit_op_get_parent_scope):
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emit_op_switch_char):
(JSC::JIT::emit_op_switch_string):
(JSC::JIT::emit_op_debug):
(JSC::JIT::emit_op_enter):
(JSC::JIT::emit_op_get_scope):
(JSC::JIT::emit_op_create_this):
(JSC::JIT::emit_op_to_this):
(JSC::JIT::emit_op_check_tdz):
(JSC::JIT::emit_op_has_structure_property):
(JSC::JIT::privateCompileHasIndexedProperty):
(JSC::JIT::emit_op_has_indexed_property):
(JSC::JIT::emitSlow_op_has_indexed_property):
(JSC::JIT::emit_op_get_direct_pname):
(JSC::JIT::emit_op_enumerator_structure_pname):
(JSC::JIT::emit_op_enumerator_generic_pname):
(JSC::JIT::emit_op_profile_type):
(JSC::JIT::emit_op_log_shadow_chicken_prologue):
(JSC::JIT::emit_op_log_shadow_chicken_tail):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_put_getter_by_id):
(JSC::JIT::emit_op_put_setter_by_id):
(JSC::JIT::emit_op_put_getter_setter_by_id):
(JSC::JIT::emit_op_put_getter_by_val):
(JSC::JIT::emit_op_put_setter_by_val):
(JSC::JIT::emit_op_del_by_id):
(JSC::JIT::emit_op_del_by_val):
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emitGetByValWithCachedId):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emit_op_put_by_val_direct):
(JSC::JIT::emit_op_put_by_val):
(JSC::JIT::emitGenericContiguousPutByVal):
(JSC::JIT::emitArrayStoragePutByVal):
(JSC::JIT::emitPutByValWithCachedId):
(JSC::JIT::emitSlow_op_put_by_val):
(JSC::JIT::emit_op_try_get_by_id):
(JSC::JIT::emitSlow_op_try_get_by_id):
(JSC::JIT::emit_op_get_by_id_direct):
(JSC::JIT::emitSlow_op_get_by_id_direct):
(JSC::JIT::emit_op_get_by_id):
(JSC::JIT::emitSlow_op_get_by_id):
(JSC::JIT::emit_op_get_by_id_with_this):
(JSC::JIT::emitSlow_op_get_by_id_with_this):
(JSC::JIT::emit_op_put_by_id):
(JSC::JIT::emitSlow_op_put_by_id):
(JSC::JIT::emit_op_in_by_id):
(JSC::JIT::emitSlow_op_in_by_id):
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emitSlow_op_get_from_scope):
(JSC::JIT::emit_op_put_to_scope):
(JSC::JIT::emitSlow_op_put_to_scope):
(JSC::JIT::emit_op_get_from_arguments):
(JSC::JIT::emit_op_put_to_arguments):
* jit/RegisterSet.cpp:
(JSC::RegisterSet::vmCalleeSaveRegisters):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LowLevelInterpreter.asm:
* runtime/SamplingProfiler.cpp:
(JSC::tryGetBytecodeIndex):
2018-11-20 Saam barati <sbarati@apple.com>
Merging an IC variant may lead to the IC status containing overlapping structure sets
https://bugs.webkit.org/show_bug.cgi?id=191869
<rdar://problem/45403453>
Reviewed by Mark Lam.
When merging two IC variant lists, we may end up in a world where we have
overlapping structure sets. We defend against this when we append a new
variant, but we should also defend against it once we merge in a new variant.
Consider this case with MultiPutByOffset, where we merge two PutByIdStatuses
together, P1 and P2.
Let's consider these structures:
s1 = {}
s2 = {p: 0}
s3 = {p: 0, p2: 1}
P1 contains these variants:
Transition: [s1 => s2]
Replace: [s2, s3]
P2 contains:
Replace: [s2]
Because of the ordering of the variants, we may end up combining
P2's replace into P1's transition, forming this new list:
Transition: [(s1, s2) => s2]
Replace: [s2, s3]
Obviously the ideal thing here is to have some ordering when we merge
in variants to choose the most ideal option. It'd be ideal for P2's
Replace to be merged into P1's replace.
If we notice that this is super important, we can implement some kind
of ordering. None of our tests (until this patch) stress this. This patch
just makes it so we defend against this crazy scenario by falling back
to the slow path gracefully. This prevents us from emitting invalid
IR in FTL->B3 lowering by creating a switch with two case labels being
identical values.
* bytecode/ICStatusUtils.h:
(JSC::appendICStatusVariant):
2018-11-20 Fujii Hironori <Hironori.Fujii@sony.com>
REGRESSION(r238039) WebCore::JSDOMGlobalObject::createStructure is using JSC::Structure::create without including StructureInlines.h
https://bugs.webkit.org/show_bug.cgi?id=191626
<rdar://problem/46161064>
Unreviewed adding comment for my change r238366.
* runtime/Structure.h: Added a comment for Structure::create.
2018-11-19 Mark Lam <mark.lam@apple.com>
globalFuncImportModule() should return a promise when it clears exceptions.
https://bugs.webkit.org/show_bug.cgi?id=191792
<rdar://problem/46090763>
Reviewed by Michael Saboff.
If we're clearing the exceptions in a CatchScope, then it means that we've handled
the exception, and is able to proceed in a normal manner. Hence, we should not
return the empty JSValue in this case: instead, we should return a Promise as
expected by import's API.
The only time when we can't return a promise is when we fail to create a Promise.
In that case, we should be propagating the exception.
Hence, globalFuncImportModule() contains a ThrowScope (for propagating the
exception that arises from failure to create the Promise) wrapping a CatchScope
(for catching any exception that arises from failure to execute the import).
Also fixed similar issues, and some exception check issues in JSModuleLoader and
the jsc shell.
* jsc.cpp:
(GlobalObject::moduleLoaderImportModule):
(GlobalObject::moduleLoaderFetch):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncImportModule):
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::loadAndEvaluateModule):
(JSC::JSModuleLoader::loadModule):
(JSC::JSModuleLoader::requestImportModule):
(JSC::JSModuleLoader::importModule):
(JSC::JSModuleLoader::resolve):
(JSC::JSModuleLoader::fetch):
(JSC::moduleLoaderParseModule):
(JSC::moduleLoaderResolveSync):
2018-11-19 Alex Christensen <achristensen@webkit.org>
Add SPI to disable JIT in a WKWebView
https://bugs.webkit.org/show_bug.cgi?id=191822
<rdar://problem/28119360>
Reviewed by Geoffrey Garen.
* jit/ExecutableAllocator.cpp:
(JSC::jitDisabled):
(JSC::allowJIT):
(JSC::ExecutableAllocator::setJITEnabled):
* jit/ExecutableAllocator.h:
(JSC::ExecutableAllocator::setJITEnabled):
2018-11-19 Fujii Hironori <Hironori.Fujii@sony.com>
[MSVC] X86Assembler.h(108): error C2666: 'WebCore::operator -': 7 overloads have similar conversions
https://bugs.webkit.org/show_bug.cgi?id=189467
<rdar://problem/44290945>
Reviewed by Mark Lam.
This issue has happened several times. And, it seems that it will
take more time for Microsoft to fix the MSVC bug. We need a
effective workaround not to repeat this issue until they fix MSVC.
Remove ": int8_t" of RegisterID only for COMPILER(MSVC).
* assembler/X86Assembler.h: Added JSC_X86_ASM_REGISTER_ID_ENUM_BASE_TYPE macro.
2018-11-19 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[WebAssembly] I64 arguments / return value check should be moved from callWebAssemblyFunction to JSToWasm wrapper
https://bugs.webkit.org/show_bug.cgi?id=190512
Reviewed by Keith Miller.
This patch moves I64 arguments / return value check from callWebAssemblyFunction to JSToWasm wrapper. Since this
check can be done when compiling the function, we should encode the result into the generated wrapper instead of
checking every time we call callWebAssemblyFunction. This change is also one of the steps removing callWebAssemblyFunction
entirely.
* wasm/WasmExceptionType.h:
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::createJSToWasmWrapper):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
* wasm/js/WebAssemblyWrapperFunction.cpp:
(JSC::callWebAssemblyWrapperFunction):
2018-11-12 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Consider removing double load for accessing the instructions from LLInt
https://bugs.webkit.org/show_bug.cgi?id=190932
Reviewed by Mark Lam.
Changing InstructionStream to RefCountedArray like structure involves so much changes
including BytecodeGraph, PreciseJumpTargets etc. Instead, CodeBlock simply hold a raw
pointer to the InstructionStream's data. Since InstructionStream is not changed
anymore, this pointer is valid while CodeBlock is live.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
* bytecode/CodeBlock.h:
* bytecode/InstructionStream.h:
(JSC::InstructionStream::rawPointer const):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2018-11-18 Fujii Hironori <Hironori.Fujii@sony.com>
REGRESSION(r238039) WebCore::JSDOMGlobalObject::createStructure is using JSC::Structure::create without including StructureInlines.h
https://bugs.webkit.org/show_bug.cgi?id=191626
Reviewed by Yusuke Suzuki.
JSC::Structure::create is used everywhere. It should be defined in
Structure.h, not in StructureInlines.h.
* runtime/Structure.h:
(JSC::Structure::create): Moved.
* runtime/StructureInlines.h: Moved JSC::Structure::create.
2018-11-18 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Unreviewed, rolling in the rest of r237254
https://bugs.webkit.org/show_bug.cgi?id=190340
* parser/ParserModes.h:
* parser/ParserTokens.h:
(JSC::JSTextPosition::JSTextPosition):
(JSC::JSTokenLocation::JSTokenLocation): Deleted.
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
2018-11-17 Devin Rousso <drousso@apple.com>
Web Inspector: Network: add button to show system certificate dialog
https://bugs.webkit.org/show_bug.cgi?id=191458
<rdar://problem/45977019>
Reviewed by Joseph Pecoraro.
* inspector/protocol/Network.json:
Add `getSerializedCertificate` command.
2018-11-17 Dominik Infuehr <dinfuehr@igalia.com>
Fix build with disabled DFG/FTL
https://bugs.webkit.org/show_bug.cgi?id=191256
Reviewed by Yusuke Suzuki.
Fix compilation errors and warnings with both DFG and FTL
disabled at compile-time.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::getICStatusMap):
* bytecode/InByIdStatus.cpp:
(JSC::InByIdStatus::computeFor):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFor):
(JSC::PutByIdStatus::hasExitSite): Deleted.
* bytecode/PutByIdStatus.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_catch):
2018-11-16 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Keep Web Inspector window alive across process swaps (PSON) (Local Inspector)
https://bugs.webkit.org/show_bug.cgi?id=191740
<rdar://problem/45470897>
Reviewed by Timothy Hatcher.
* inspector/InspectorFrontendChannel.h:
Expose EnumTraits for ConnectionType for WebKit IPC messages.
2018-11-16 Filip Pizlo <fpizlo@apple.com>
All users of ArrayBuffer should agree on the same max size
https://bugs.webkit.org/show_bug.cgi?id=191771
Reviewed by Mark Lam.
Array buffers cannot be larger than 0x7fffffff, because otherwise loading typedArray.length in the DFG/FTL would produce
a uint32 or would require a signedness check, neither of which sounds reasonable. It's better to just bound their max size
instead.
* runtime/ArrayBuffer.cpp:
(JSC::ArrayBufferContents::ArrayBufferContents):
(JSC::ArrayBufferContents::tryAllocate):
(JSC::ArrayBufferContents::transferTo):
(JSC::ArrayBufferContents::copyTo):
(JSC::ArrayBufferContents::shareWith):
* runtime/ArrayBuffer.h:
* wasm/WasmMemory.cpp:
(JSC::Wasm::Memory::tryCreate):
(JSC::Wasm::Memory::grow):
* wasm/WasmPageCount.h:
2018-11-16 Saam Barati <sbarati@apple.com>
KnownCellUse should also have SpecCellCheck as its type filter
https://bugs.webkit.org/show_bug.cgi?id=191729
<rdar://problem/45872852>
Reviewed by Filip Pizlo.
We write transformations in the compiler like this where we emit edges with
KnownCellUse if we know we're inserting code at a point where we're dominated
by a Cell check:
a: SomeValue
b: Something(Cell:@a)
c: SomethingElse(@b)
d: CheckNotEmpty(@a)
=>
a: SomeValue
b: Something(Cell:@a)
e: RandomOtherThing(KnownCellUse:@a)
c: SomethingElse(@b)
d: CheckNotEmpty(@a)
However, doing this used to lead to subtly incorrect programs since KnownCellUse
did not allow the empty value to flow through it. We used to end up incorrectly
deleting @d in the above program. We fix this, we make KnownCellUse allow the empty
value to flow through.
* dfg/DFGUseKind.h:
(JSC::DFG::typeFilterFor):
2018-11-16 Tadeu Zagallo <tzagallo@apple.com>
Fix assertion failure on BytecodeGenerator::recordOpcode
https://bugs.webkit.org/show_bug.cgi?id=191724
<rdar://problem/45724395>
Reviewed by Saam Barati.
Since https://bugs.webkit.org/show_bug.cgi?id=187373, we were not
restoring m_lastInstruction after patching the bytecode when
finalizing StructureForInContexts, only m_lastOpcodeID, which led to
the assertion failure.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::StructureForInContext::finalize):
2018-11-15 Mark Lam <mark.lam@apple.com>
RegExpObject's collectMatches should not be using JSArray::push to fill in its match results.
https://bugs.webkit.org/show_bug.cgi?id=191730
<rdar://problem/46048517>
Reviewed by Saam Barati.
According to the spec https://www.ecma-international.org/ecma-262/9.0/index.html#sec-regexp.prototype-@@match,
the RegExp match results are filled in using the spec's CreateDataProperty()
function which does not consult the prototype for setters. JSArray:push()
consults the prototype for setters. We should be using putDirectIndex() instead.
* runtime/RegExpObjectInlines.h:
(JSC::collectMatches):
2018-11-15 Mark Lam <mark.lam@apple.com>
RegExp operations should not take fast patch if lastIndex is not numeric.
https://bugs.webkit.org/show_bug.cgi?id=191731
<rdar://problem/46017305>
Reviewed by Saam Barati.
This is because if lastIndex is an object with a valueOf() method, it can execute
arbitrary code which may have side effects, and side effects are not permitted by
the RegExp fast paths.
* builtins/RegExpPrototype.js:
(globalPrivate.hasObservableSideEffectsForRegExpMatch):
(overriddenName.string_appeared_here.search):
(globalPrivate.hasObservableSideEffectsForRegExpSplit):
(intrinsic.RegExpTestIntrinsic.test):
* builtins/StringPrototype.js:
(globalPrivate.hasObservableSideEffectsForStringReplace):
2018-11-15 Keith Rollin <krollin@apple.com>
Delete old .xcfilelist files
https://bugs.webkit.org/show_bug.cgi?id=191669
<rdar://problem/46081994>
Reviewed by Chris Dumez.
.xcfilelist files were created and added to the Xcode project files in
https://trac.webkit.org/changeset/238008/webkit. However, they caused
build issues and they were removed from the Xcode projects in
https://trac.webkit.org/changeset/238055/webkit. This check-in removes
the files from the repository altogether. They'll ultimately be
replaced with new files with names that indicate whether the
associated files are inputs to the Run Script phase or are files
created by the Run Script phase.
* DerivedSources.xcfilelist: Removed.
* UnifiedSources.xcfilelist: Removed.
2018-11-14 Keith Rollin <krollin@apple.com>
Move scripts for Derived and Unified Sources to external files
https://bugs.webkit.org/show_bug.cgi?id=191670
<rdar://problem/46082278>
Reviewed by Keith Miller.
Move the scripts in the Generate Derived Sources and Generate Unified
Sources Run Script phases from the Xcode projects to external shell
script files. Then invoke those scripts from the Run Script phases.
This refactoring is being performed to support later work that will
invoke these scripts in other contexts.
The scripts were maintained as-is when making the move. I did a little
reformatting and added 'set -e' to the top of each file, but that's
it.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Scripts/generate-derived-sources.sh: Added.
* Scripts/generate-unified-sources.sh: Added.
2018-11-14 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Pass Inspector::FrontendChannel as a reference connect/disconnect methods
https://bugs.webkit.org/show_bug.cgi?id=191612
Reviewed by Matt Baker.
* inspector/InspectorFrontendRouter.cpp:
(Inspector::FrontendRouter::connectFrontend):
(Inspector::FrontendRouter::disconnectFrontend):
* inspector/InspectorFrontendRouter.h:
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::connectFrontend):
(Inspector::JSGlobalObjectInspectorController::disconnectFrontend):
* inspector/JSGlobalObjectInspectorController.h:
* inspector/remote/RemoteControllableTarget.h:
* inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
(Inspector::RemoteConnectionToTarget::setup):
(Inspector::RemoteConnectionToTarget::close):
* inspector/remote/glib/RemoteConnectionToTargetGlib.cpp:
(Inspector::RemoteConnectionToTarget::setup):
(Inspector::RemoteConnectionToTarget::close):
* runtime/JSGlobalObjectDebuggable.cpp:
(JSC::JSGlobalObjectDebuggable::connect):
(JSC::JSGlobalObjectDebuggable::disconnect):
* runtime/JSGlobalObjectDebuggable.h:
2018-11-14 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Keep Web Inspector window alive across process swaps (PSON) (Remote Inspector)
https://bugs.webkit.org/show_bug.cgi?id=191494
<rdar://problem/45469854>
Reviewed by Devin Rousso.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
New domain and resources.
* inspector/protocol/Target.json: Added.
New protocol domain, modeled after Worker.json, to allow for
multiplexing between different targets.
* inspector/InspectorTarget.h:
Each target will instantiate an InspectorTarget and must
provide an identifier, type, and means of connecting/disconnecting
to a frontend channel.
* inspector/agents/InspectorTargetAgent.cpp: Added.
(Inspector::InspectorTargetAgent::InspectorTargetAgent):
(Inspector::InspectorTargetAgent::didCreateFrontendAndBackend):
(Inspector::InspectorTargetAgent::willDestroyFrontendAndBackend):
(Inspector::InspectorTargetAgent::exists):
(Inspector::InspectorTargetAgent::initialized):
(Inspector::InspectorTargetAgent::sendMessageToTarget):
(Inspector::InspectorTargetAgent::sendMessageFromTargetToFrontend):
(Inspector::targetTypeToProtocolType):
(Inspector::buildTargetInfoObject):
(Inspector::InspectorTargetAgent::targetCreated):
(Inspector::InspectorTargetAgent::targetTerminated):
(Inspector::InspectorTargetAgent::connectToTargets):
(Inspector::InspectorTargetAgent::disconnectFromTargets):
* inspector/agents/InspectorTargetAgent.h: Added.
TargetAgent holds a list of targets, and connects/disconnects to each
of the targets when a frontend connects/disconnects.
* inspector/scripts/codegen/generator.py:
Better enum casing of ServiceWorker.
2018-11-14 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Unreviewed, rolling in CodeCache in r237254
https://bugs.webkit.org/show_bug.cgi?id=190340
Land the CodeCache part without adding an additional hash value.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
* bytecode/UnlinkedFunctionExecutable.h:
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::SourceCodeKey):
(JSC::SourceCodeKey::operator== const):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
* runtime/CodeCache.h:
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/FunctionExecutable.h:
2018-11-13 Saam Barati <sbarati@apple.com>
ProxyObject should check for VMInquiry and return early before throwing a stack overflow exception
https://bugs.webkit.org/show_bug.cgi?id=191601
Reviewed by Mark Lam.
This doesn't fix any bugs today, but it may reduce future bugs. It was
always weird that ProxyObject::getOwnPropertySlot with VMInquiry might
throw a stack overflow error instead of just returning false like it
normally does when VMInquiry is passed in.
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::getOwnPropertySlotCommon):
2018-11-13 Saam Barati <sbarati@apple.com>
TypeProfileLog::processLogEntries should stash away any pending exceptions and re-apply them to the VM
https://bugs.webkit.org/show_bug.cgi?id=191600
Reviewed by Mark Lam.
processLogEntries will call into calculatedClassName, which will clear
any exceptions it encounters (it assumes that they're stack overflow exceptions).
However, this code may be called when an exception is already pending on the
VM (e.g, when we throw an exception in the DFG, we compile an OSR exit
offramp, which may compile a baseline codeblock, which will process
the type profiler log). To get around this, processLogEntires should stash
away and re-apply any pending exceptions.
* dfg/DFGDriver.cpp:
(JSC::DFG::compileImpl):
* dfg/DFGOperations.cpp:
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
* jit/JIT.cpp:
(JSC::JIT::doMainThreadPreparationBeforeCompile):
* jit/JITOperations.cpp:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/TypeProfilerLog.cpp:
(JSC::TypeProfilerLog::processLogEntries):
* runtime/TypeProfilerLog.h:
* runtime/VM.cpp:
(JSC::VM::dumpTypeProfilerData):
* runtime/VM.h:
(JSC::VM::DeferExceptionScope::DeferExceptionScope):
* tools/JSDollarVM.cpp:
(JSC::functionFindTypeForExpression):
(JSC::functionReturnTypeFor):
2018-11-13 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r238132.
The test added with this change is timing out on Debug JSC
bots.
Reverted changeset:
"[BigInt] JSBigInt::createWithLength should throw when length
is greater than JSBigInt::maxLength"
https://bugs.webkit.org/show_bug.cgi?id=190836
https://trac.webkit.org/changeset/238132
2018-11-12 Mark Lam <mark.lam@apple.com>
Add OOM detection to StringPrototype's substituteBackreferences().
https://bugs.webkit.org/show_bug.cgi?id=191563
<rdar://problem/45720428>
Reviewed by Saam Barati.
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* runtime/StringPrototype.cpp:
(JSC::substituteBackreferencesSlow):
(JSC::substituteBackreferencesInline):
(JSC::substituteBackreferences):
(JSC::replaceUsingRegExpSearch):
(JSC::replaceUsingStringSearch):
* runtime/StringPrototype.h:
2018-11-13 Mark Lam <mark.lam@apple.com>
LLIntSlowPath's llint_loop_osr and llint_replace should set the topCallFrame.
https://bugs.webkit.org/show_bug.cgi?id=191579
<rdar://problem/45942472>
Reviewed by Saam Barati.
Both of these functions do a lot of work. It would be good for the topCallFrame
to be correct should we need to throw an exception.
For example, we've observed the following crash trace:
* frame #0: WTFCrash() at Assertions.cpp:253
frame #1: ...
frame #2: JSC::StructureIDTable::get(this=0x00006040000162f0, structureID=1874583248) at StructureIDTable.h:129
frame #3: JSC::VM::getStructure(this=0x0000604000016210, id=4022066896) at VM.h:705
frame #4: JSC::JSCell::structure(this=0x00007ffeefbbde30, vm=0x0000604000016210) const at JSCellInlines.h:125
frame #5: JSC::JSCell::classInfo(this=0x00007ffeefbbde30, vm=0x0000604000016210) const at JSCellInlines.h:335
frame #6: JSC::JSCell::inherits(this=0x00007ffeefbbde30, vm=0x0000604000016210, info=0x0000000105eaf020) const at JSCellInlines.h:302
frame #7: JSC::JSObject* JSC::jsCast<JSC::JSObject*, JSC::JSCell>(from=0x00007ffeefbbde30) at JSCast.h:36
frame #8: JSC::asObject(cell=0x00007ffeefbbde30) at JSObject.h:1299
frame #9: JSC::asObject(value=JSValue @ 0x00007ffeefbba380) at JSObject.h:1304
frame #10: JSC::Register::object(this=0x00007ffeefbbdd58) const at JSObject.h:1514
frame #11: JSC::ExecState::jsCallee(this=0x00007ffeefbbdd40) const at CallFrame.h:107
frame #12: JSC::ExecState::isStackOverflowFrame(this=0x00007ffeefbbdd40) const at CallFrameInlines.h:36
frame #13: JSC::StackVisitor::StackVisitor(this=0x00007ffeefbba860, startFrame=0x00007ffeefbbdd40, vm=0x0000631000000800) at StackVisitor.cpp:52
frame #14: JSC::StackVisitor::StackVisitor(this=0x00007ffeefbba860, startFrame=0x00007ffeefbbdd40, vm=0x0000631000000800) at StackVisitor.cpp:41
frame #15: void JSC::StackVisitor::visit<(JSC::StackVisitor::EmptyEntryFrameAction)0, JSC::Interpreter::getStackTrace(JSC::JSCell*, WTF::Vector<JSC::StackFrame, 0ul, WTF::CrashOnOverflow, 16ul>&, unsigned long, unsigned long)::$_3>(startFrame=0x00007ffeefbbdd40, vm=0x0000631000000800, functor=0x00007ffeefbbaa60)::$_3 const&) at StackVisitor.h:147
frame #16: JSC::Interpreter::getStackTrace(this=0x0000602000005db0, owner=0x000062d00020cbe0, results=0x00006020000249d0, framesToSkip=0, maxStackSize=1) at Interpreter.cpp:437
frame #17: JSC::getStackTrace(exec=0x000062d00002c048, vm=0x0000631000000800, obj=0x000062d00020cbe0, useCurrentFrame=true) at Error.cpp:170
frame #18: JSC::ErrorInstance::finishCreation(this=0x000062d00020cbe0, exec=0x000062d00002c048, vm=0x0000631000000800, message=0x00007ffeefbbb800, useCurrentFrame=true) at ErrorInstance.cpp:119
frame #19: JSC::ErrorInstance::create(exec=0x000062d00002c048, vm=0x0000631000000800, structure=0x000062d0000f5730, message=0x00007ffeefbbb800, appender=0x0000000000000000, type=TypeNothing, useCurrentFrame=true)(WTF::String const&, WTF::String const&, JSC::RuntimeType, JSC::ErrorInstance::SourceTextWhereErrorOccurred), JSC::RuntimeType, bool) at ErrorInstance.h:49
frame #20: JSC::createRangeError(exec=0x000062d00002c048, globalObject=0x000062d00002c000, message=0x00007ffeefbbb800, appender=0x0000000000000000)(WTF::String const&, WTF::String const&, JSC::RuntimeType, JSC::ErrorInstance::SourceTextWhereErrorOccurred)) at Error.cpp:68
frame #21: JSC::createRangeError(exec=0x000062d00002c048, globalObject=0x000062d00002c000, message=0x00007ffeefbbb800) at Error.cpp:316
frame #22: JSC::createStackOverflowError(exec=0x000062d00002c048, globalObject=0x000062d00002c000) at ExceptionHelpers.cpp:77
frame #23: JSC::createStackOverflowError(exec=0x000062d00002c048) at ExceptionHelpers.cpp:72
frame #24: JSC::throwStackOverflowError(exec=0x000062d00002c048, scope=0x00007ffeefbbbaa0) at ExceptionHelpers.cpp:335
frame #25: JSC::ProxyObject::getOwnPropertySlotCommon(this=0x000062d000200e40, exec=0x000062d00002c048, propertyName=PropertyName @ 0x00007ffeefbbba80, slot=0x00007ffeefbbc720) at ProxyObject.cpp:372
frame #26: JSC::ProxyObject::getOwnPropertySlot(object=0x000062d000200e40, exec=0x000062d00002c048, propertyName=PropertyName @ 0x00007ffeefbbbd40, slot=0x00007ffeefbbc720) at ProxyObject.cpp:395
frame #27: JSC::JSObject::getNonIndexPropertySlot(this=0x000062d000200e40, exec=0x000062d00002c048, propertyName=PropertyName @ 0x00007ffeefbbbea0, slot=0x00007ffeefbbc720) at JSObjectInlines.h:150
frame #28: bool JSC::JSObject::getPropertySlot<false>(this=0x000062d000200e40, exec=0x000062d00002c048, propertyName=PropertyName @ 0x00007ffeefbbc320, slot=0x00007ffeefbbc720) at JSObject.h:1424
frame #29: JSC::JSObject::calculatedClassName(object=0x000062d000200e40) at JSObject.cpp:535
frame #30: JSC::Structure::toStructureShape(this=0x000062d000007410, value=JSValue @ 0x00007ffeefbbcae0, sawPolyProtoStructure=0x00007ffeefbbcf60) at Structure.cpp:1142
frame #31: JSC::TypeProfilerLog::processLogEntries(this=0x000060400000a950, reason=0x00007ffeefbbd5c0) at TypeProfilerLog.cpp:89
frame #32: JSC::JIT::doMainThreadPreparationBeforeCompile(this=0x0000619000034da0) at JIT.cpp:951
frame #33: JSC::JITWorklist::Plan::Plan(this=0x0000619000034d80, codeBlock=0x000062d0001d88c0, loopOSREntryBytecodeOffset=0) at JITWorklist.cpp:43
frame #34: JSC::JITWorklist::Plan::Plan(this=0x0000619000034d80, codeBlock=0x000062d0001d88c0, loopOSREntryBytecodeOffset=0) at JITWorklist.cpp:42
frame #35: JSC::JITWorklist::compileLater(this=0x0000616000001b80, codeBlock=0x000062d0001d88c0, loopOSREntryBytecodeOffset=0) at JITWorklist.cpp:256
frame #36: JSC::LLInt::jitCompileAndSetHeuristics(codeBlock=0x000062d0001d88c0, exec=0x00007ffeefbbde30, loopOSREntryBytecodeOffset=0) at LLIntSlowPaths.cpp:391
frame #37: llint_replace(exec=0x00007ffeefbbde30, pc=0x00006040000161ba) at LLIntSlowPaths.cpp:516
frame #38: llint_entry at LowLevelInterpreter64.asm:98
frame #39: vmEntryToJavaScript at LowLevelInterpreter64.asm:296
...
This crash occurred because StackVisitor was seeing an invalid topCallFrame while
trying to capture the Error stack while throwing a StackOverflowError below
llint_replace. While in this specific example, it is questionable whether we
should be executing JS code below TypeProfilerLog::processLogEntries(), it is
correct to have set the topCallFrame in llint_replace. We do this by calling
LLINT_BEGIN_NO_SET_PC() at the top of llint_replace.
We also do the same for llint_osr.
Note: both of these LLInt slow path functions are called with a fully initialized
CallFrame. Hence, there's no issue with setting topCallFrame to their CallFrames
for these functions.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
2018-11-13 Caio Lima <ticaiolima@gmail.com>
[BigInt] JSBigInt::createWithLength should throw when length is greater than JSBigInt::maxLength
https://bugs.webkit.org/show_bug.cgi?id=190836
Reviewed by Saam Barati.
In this patch we are creating a new method called `JSBigInt::createWithLengthUnchecked`
where we allocate a BigInt trusting the length received as argument.
With this additional method, we now check if length passed to
`JSBigInt::createWithLength` is not greater than JSBigInt::maxLength.
When the length is greater than maxLength, we then throw OOM
exception.
This required change the interface of some JSBigInt operations to
receive `ExecState*` instead of `VM&`. We changed only operations that
can throw because of OOM.
We beleive that this approach of throwing instead of finishing the
execution abruptly is better because JS programs can catch such
exception and handle this issue properly.
* dfg/DFGOperations.cpp:
* jit/JITOperations.cpp:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::createZero):
(JSC::JSBigInt::tryCreateWithLength):
(JSC::JSBigInt::createWithLengthUnchecked):
(JSC::JSBigInt::createFrom):
(JSC::JSBigInt::multiply):
(JSC::JSBigInt::divide):
(JSC::JSBigInt::copy):
(JSC::JSBigInt::unaryMinus):
(JSC::JSBigInt::remainder):
(JSC::JSBigInt::add):
(JSC::JSBigInt::sub):
(JSC::JSBigInt::bitwiseAnd):
(JSC::JSBigInt::bitwiseOr):
(JSC::JSBigInt::bitwiseXor):
(JSC::JSBigInt::absoluteAdd):
(JSC::JSBigInt::absoluteSub):
(JSC::JSBigInt::absoluteDivWithDigitDivisor):
(JSC::JSBigInt::absoluteDivWithBigIntDivisor):
(JSC::JSBigInt::absoluteLeftShiftAlwaysCopy):
(JSC::JSBigInt::absoluteBitwiseOp):
(JSC::JSBigInt::absoluteAddOne):
(JSC::JSBigInt::absoluteSubOne):
(JSC::JSBigInt::toStringGeneric):
(JSC::JSBigInt::rightTrim):
(JSC::JSBigInt::allocateFor):
(JSC::JSBigInt::createWithLength): Deleted.
* runtime/JSBigInt.h:
* runtime/Operations.cpp:
(JSC::jsAddSlowCase):
* runtime/Operations.h:
(JSC::jsSub):
(JSC::jsMul):
2018-11-12 Devin Rousso <drousso@apple.com>
Web Inspector: Network: show secure certificate details per-request
https://bugs.webkit.org/show_bug.cgi?id=191447
<rdar://problem/30019476>
Reviewed by Joseph Pecoraro.
Add Security domain to hold security related protocol types.
* CMakeLists.txt:
* DerivedSources.make:
* inspector/protocol/Network.json:
* inspector/protocol/Security.json: Added.
* inspector/scripts/codegen/objc_generator.py:
(ObjCGenerator):
2018-11-12 Saam barati <sbarati@apple.com>
Unreviewed. Rollout 238026: It caused ~8% JetStream 2 regressions on some iOS devices
https://bugs.webkit.org/show_bug.cgi?id=191555
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
* bytecode/UnlinkedFunctionExecutable.h:
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::SourceCodeKey):
(JSC::SourceCodeKey::operator== const):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
* runtime/CodeCache.h:
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/FunctionExecutable.h:
2018-11-11 Benjamin Poulain <benjamin@webkit.org>
Fix a fixme: rename wtfObjcMsgSend to wtfObjCMsgSend
https://bugs.webkit.org/show_bug.cgi?id=191492
Reviewed by Alex Christensen.
Rename file.
* API/JSValue.mm:
2018-11-10 Benjamin Poulain <benjamin@webkit.org>
Fix a fixme: rename wtfObjcMsgSend to wtfObjCMsgSend
https://bugs.webkit.org/show_bug.cgi?id=191492
Reviewed by Alex Christensen.
* API/JSValue.mm:
2018-11-10 Michael Catanzaro <mcatanzaro@igalia.com>
Unreviewed, silence -Wunused-variable warning
* bytecode/Opcode.h:
(JSC::padOpcodeName):
2018-11-09 Keith Rollin <krollin@apple.com>
Unreviewed build fix after https://bugs.webkit.org/show_bug.cgi?id=191324
Remove the use of .xcfilelists until their side-effects are better
understood.
* JavaScriptCore.xcodeproj/project.pbxproj:
2018-11-09 Keith Miller <keith_miller@apple.com>
LLInt VectorSizeOffset should be based on offset extraction
https://bugs.webkit.org/show_bug.cgi?id=191468
Reviewed by Yusuke Suzuki.
This patch also adds some usings to LLIntOffsetsExtractor that
make it possible to use the bare names of Vector/RefCountedArray
in offsets extraction.
* llint/LLIntOffsetsExtractor.cpp:
* llint/LowLevelInterpreter.asm:
2018-11-09 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Unreviewed, rolling in CodeCache in r237254
https://bugs.webkit.org/show_bug.cgi?id=190340
Land the CodeCache part, which uses DefaultHash<>::Hash instead of computeHash.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
* bytecode/UnlinkedFunctionExecutable.h:
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::SourceCodeKey):
(JSC::SourceCodeKey::operator== const):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
* runtime/CodeCache.h:
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/FunctionExecutable.h:
2018-11-08 Keith Miller <keith_miller@apple.com>
put_by_val opcodes need to add the number tag as a 64-bit register
https://bugs.webkit.org/show_bug.cgi?id=191456
Reviewed by Saam Barati.
Previously the LLInt would add it as a pointer sized value. That is
wrong if pointer size is less 64-bits.
* llint/LowLevelInterpreter64.asm:
2018-11-08 Ross Kirsling <ross.kirsling@sony.com>
[JSC] isStrWhiteSpace seems redundant with Lexer<UChar>::isWhiteSpace
https://bugs.webkit.org/show_bug.cgi?id=191439
Reviewed by Saam Barati.
* CMakeLists.txt:
* runtime/ParseInt.h:
(JSC::isStrWhiteSpace):
Define isStrWhiteSpace in terms of isWhiteSpace and isLineTerminator.
2018-11-08 Michael Saboff <msaboff@apple.com>
Options::useRegExpJIT() should use jitEnabledByDefault() just like useJIT()
https://bugs.webkit.org/show_bug.cgi?id=191444
Reviewed by Saam Barati.
* runtime/Options.h:
2018-11-08 Fujii Hironori <Hironori.Fujii@sony.com>
[Win] UDis86Disassembler.cpp: warning: format specifies type 'unsigned long' but the argument has type 'uintptr_t' (aka 'unsigned long long')
https://bugs.webkit.org/show_bug.cgi?id=191416
Reviewed by Saam Barati.
* disassembler/UDis86Disassembler.cpp:
(JSC::tryToDisassembleWithUDis86): Use PRIxPTR for uintptr_t.
2018-11-08 Keith Rollin <krollin@apple.com>
Create .xcfilelist files
https://bugs.webkit.org/show_bug.cgi?id=191324
<rdar://problem/45852819>
Reviewed by Alex Christensen.
As part of preparing for enabling XCBuild, create and use .xcfilelist
files. These files are using during Run Script build phases in an
Xcode project. If a Run Script build phase produces new files that are
used later as inputs to subsequent build phases, XCBuild needs to know
about these files. These files can be either specified in an "output
files" section of the Run Script phase editor, or in .xcfilelist files
that are associated with the Run Script build phase.
This patch takes the second approach. It consists of three sets of changes:
- Modify the DerivedSources.make files to have a
'print_all_generated_files" target that produces a list of the files
they create.
- Create a shell script that produces .xcfilelist files from the
output of the previous step, as well as for the files created in the
Generate Unified Sources build steps.
- Add the new .xcfilelist files to the associated projects.
Note that, with these changes, the Xcode workspace and projects can no
longer be fully loaded into Xcode 9. Xcode will attempt to load the
projects that have .xcfilelist files associated with them, but will
fail and display a placeholder for those projects instead. It's
expected that all developers are using Xcode 10 by now and that not
being able to load into Xcode 9 is not a practical issue. Keep in mind
that this is strictly an IDE issue, and that the projects can still be
built with `xcodebuild`.
Also note that the shell script that creates the .xcfilelist files can
also be used to verify that the set of files that's currently checked
in is up-to-date. This checking can be used as part of a check-in hook
or part of check-webkit-style to sooner catch cases where the
.xcfilelist files need to be regenerated.
* DerivedSources.make:
* DerivedSources.xcfilelist: Added.
* JavaScriptCore.xcodeproj/project.pbxproj:
* UnifiedSources.xcfilelist: Added.
2018-11-08 Ross Kirsling <ross.kirsling@sony.com>
U+180E is no longer a whitespace character
https://bugs.webkit.org/show_bug.cgi?id=191415
Reviewed by Saam Barati.
Mongolian Vowel Separator stopped being a valid whitespace character as of ES2016.
(https://github.com/tc39/ecma262/pull/300)
* parser/Lexer.h:
(JSC::Lexer<UChar>::isWhiteSpace):
* runtime/ParseInt.h:
(JSC::isStrWhiteSpace):
* yarr/create_regex_tables:
2018-11-08 Keith Miller <keith_miller@apple.com>
jitEnabledByDefault() should be on useJIT not useBaselineJIT
https://bugs.webkit.org/show_bug.cgi?id=191434
Reviewed by Saam Barati.
* runtime/Options.h:
2018-11-08 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Restrict domains at the target level instead of only at the window level
https://bugs.webkit.org/show_bug.cgi?id=191344
Reviewed by Devin Rousso.
* inspector/protocol/Console.json:
* inspector/protocol/Debugger.json:
* inspector/protocol/Heap.json:
* inspector/protocol/Runtime.json:
Remove workerSupported as it is now no longer necessary. It is implied
by availability being empty (meaning it is supported everywhere).
* inspector/protocol/Inspector.json:
* inspector/protocol/ScriptProfiler.json:
Restrict to "javascript" and "web" debuggables, not available in workers.
* inspector/protocol/Worker.json:
Cleanup, remove empty types list.
* inspector/protocol/Recording.json:
Cleanup, only expose this in the "web" domain for now.
* inspector/scripts/codegen/generate_js_backend_commands.py:
(JSBackendCommandsGenerator.generate_domain):
* inspector/scripts/codegen/models.py:
(Protocol.parse_domain):
Allow a list of debuggable types. Add "worker" even though it is unused
since that is a type we would want to allow or consider.
(Domain.__init__):
(Domains):
Remove now unnecessary workerSupported code.
Allow availability on a domain with only types.
* inspector/scripts/tests/generic/expected/worker-supported-domains.json-result: Removed.
* inspector/scripts/tests/generic/worker-supported-domains.json: Removed.
2018-11-07 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Consider removing double load for accessing the MetadataTable from LLInt
https://bugs.webkit.org/show_bug.cgi?id=190933
Reviewed by Keith Miller.
This patch removes double load for accesses to MetadataTable from LLInt.
MetadataTable is now specially RefCounted class, which has interesting memory layout.
When refcount becomes 0, MetadataTable asks UnlinkedMetadataTable to destroy itself.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::estimatedSize):
(JSC::CodeBlock::visitChildren):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::metadata):
* bytecode/CodeBlockInlines.h:
(JSC::CodeBlock::forEachValueProfile):
(JSC::CodeBlock::forEachArrayProfile):
(JSC::CodeBlock::forEachArrayAllocationProfile):
(JSC::CodeBlock::forEachObjectAllocationProfile):
(JSC::CodeBlock::forEachLLIntCallLinkInfo):
* bytecode/MetadataTable.cpp:
(JSC::MetadataTable::MetadataTable):
(JSC::MetadataTable::~MetadataTable):
(JSC::MetadataTable::sizeInBytes):
* bytecode/MetadataTable.h:
(JSC::MetadataTable::get):
(JSC::MetadataTable::forEach):
(JSC::MetadataTable::ref const):
(JSC::MetadataTable::deref const):
(JSC::MetadataTable::refCount const):
(JSC::MetadataTable::hasOneRef const):
(JSC::MetadataTable::buffer):
(JSC::MetadataTable::linkingData const):
(JSC::MetadataTable::getImpl):
* bytecode/UnlinkedMetadataTable.h:
(JSC::UnlinkedMetadataTable::buffer const):
* bytecode/UnlinkedMetadataTableInlines.h:
(JSC::UnlinkedMetadataTable::UnlinkedMetadataTable):
(JSC::UnlinkedMetadataTable::~UnlinkedMetadataTable):
(JSC::UnlinkedMetadataTable::addEntry):
(JSC::UnlinkedMetadataTable::sizeInBytes):
(JSC::UnlinkedMetadataTable::finalize):
(JSC::UnlinkedMetadataTable::link):
(JSC::UnlinkedMetadataTable::unlink):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
2018-11-07 Caio Lima <ticaiolima@gmail.com>
[BigInt] Add support to BigInt into ValueAdd
https://bugs.webkit.org/show_bug.cgi?id=186177
Reviewed by Keith Miller.
We are adding a very primitive specialization case of BigInts into ValueAdd.
When compiling a speculated version of this node to BigInt, we are currently
calling 'operationAddBigInt', a function that expects only BigInts as
parameter and effectly add numbers using JSBigInt::add. To properly
speculate BigInt operands, we changed ArithProfile to observe when
its result is a BigInt. With this new observation, we are able to identify
when ValueAdd results into a String or BigInt.
Here are some numbers for this specialization running
microbenchmarks:
big-int-simple-add 21.5411+-1.1096 ^ 15.3502+-0.7027 ^ definitely 1.4033x faster
big-int-add-prediction-propagation 13.7762+-0.5578 ^ 10.8117+-0.5330 ^ definitely 1.2742x faster
* bytecode/ArithProfile.cpp:
(JSC::ArithProfile::emitObserveResult):
(JSC::ArithProfile::shouldEmitSetNonNumeric const):
(JSC::ArithProfile::shouldEmitSetBigInt const):
(JSC::ArithProfile::emitSetNonNumeric const):
(JSC::ArithProfile::emitSetBigInt const):
(WTF::printInternal):
(JSC::ArithProfile::shouldEmitSetNonNumber const): Deleted.
(JSC::ArithProfile::emitSetNonNumber const): Deleted.
* bytecode/ArithProfile.h:
(JSC::ArithProfile::observedUnaryInt):
(JSC::ArithProfile::observedUnaryNumber):
(JSC::ArithProfile::observedBinaryIntInt):
(JSC::ArithProfile::observedBinaryNumberInt):
(JSC::ArithProfile::observedBinaryIntNumber):
(JSC::ArithProfile::observedBinaryNumberNumber):
(JSC::ArithProfile::didObserveNonInt32 const):
(JSC::ArithProfile::didObserveNonNumeric const):
(JSC::ArithProfile::didObserveBigInt const):
(JSC::ArithProfile::setObservedNonNumeric):
(JSC::ArithProfile::setObservedBigInt):
(JSC::ArithProfile::observeResult):
(JSC::ArithProfile::didObserveNonNumber const): Deleted.
(JSC::ArithProfile::setObservedNonNumber): Deleted.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::makeSafe):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::mayHaveNonNumericResult):
(JSC::DFG::Node::mayHaveBigIntResult):
(JSC::DFG::Node::mayHaveNonNumberResult): Deleted.
* dfg/DFGNodeFlags.cpp:
(JSC::DFG::dumpNodeFlags):
* dfg/DFGNodeFlags.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueAdd):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
* runtime/CommonSlowPaths.cpp:
(JSC::updateArithProfileForUnaryArithOp):
(JSC::updateArithProfileForBinaryArithOp):
2018-11-07 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Fix "Javascript" => "JavaScript" enum in protocol generated objects
https://bugs.webkit.org/show_bug.cgi?id=191340
Reviewed by Devin Rousso.
* inspector/ConsoleMessage.cpp:
(Inspector::messageSourceValue):
Use new enum name.
* inspector/scripts/codegen/generator.py:
Correct the casing of "JavaScript".
2018-11-07 Tadeu Zagallo <tzagallo@apple.com>
Align wide opcodes in the instruction stream
https://bugs.webkit.org/show_bug.cgi?id=191254
Reviewed by Keith Miller.
Pad the bytecode with nops to ensure that wide opcodes are 4-byte
aligned on platforms that don't like unaligned memory access.
For that, add a new type to represent jump targets, BoundLabel, which
delays computing the offset in case we need to emit nops for padding.
Extra padding is also emitted before op_yield and at the of each
BytecodeWriter fragment, to ensure that the bytecode remains aligned
after the rewriting.
As a side effect, we can longer guarantee that the point immediately
before emitting an opcode is the start of that opcode, since nops
might be emitted in between if the opcode needs to be wide. To fix
that, we only take the offset of opcodes after they have been emitted,
using `m_lastInstruction.offset()`.
* bytecode/BytecodeDumper.h:
(JSC::BytecodeDumper::dumpValue):
* bytecode/BytecodeGeneratorification.cpp:
(JSC::BytecodeGeneratorification::run):
* bytecode/BytecodeList.rb:
* bytecode/BytecodeRewriter.h:
(JSC::BytecodeRewriter::Fragment::align):
(JSC::BytecodeRewriter::insertFragmentBefore):
(JSC::BytecodeRewriter::insertFragmentAfter):
* bytecode/Fits.h:
* bytecode/InstructionStream.h:
(JSC::InstructionStreamWriter::ref):
* bytecode/PreciseJumpTargetsInlines.h:
(JSC::updateStoredJumpTargetsForInstruction):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::Label::setLocation):
(JSC::BoundLabel::target):
(JSC::BoundLabel::saveTarget):
(JSC::BoundLabel::commitTarget):
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::recordOpcode):
(JSC::BytecodeGenerator::alignWideOpcode):
(JSC::BytecodeGenerator::emitProfileControlFlow):
(JSC::BytecodeGenerator::emitResolveScope):
(JSC::BytecodeGenerator::emitGetFromScope):
(JSC::BytecodeGenerator::emitPutToScope):
(JSC::BytecodeGenerator::emitGetById):
(JSC::BytecodeGenerator::emitDirectGetById):
(JSC::BytecodeGenerator::emitPutById):
(JSC::BytecodeGenerator::emitDirectPutById):
(JSC::BytecodeGenerator::emitGetByVal):
(JSC::BytecodeGenerator::emitCreateThis):
(JSC::BytecodeGenerator::beginSwitch):
(JSC::BytecodeGenerator::endSwitch):
(JSC::BytecodeGenerator::emitRequireObjectCoercible):
(JSC::BytecodeGenerator::emitYieldPoint):
(JSC::BytecodeGenerator::emitToThis):
(JSC::Label::bind): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::recordOpcode): Deleted.
* bytecompiler/Label.h:
(JSC::BoundLabel::BoundLabel):
(JSC::BoundLabel::operator int):
(JSC::Label::bind):
* generator/Opcode.rb:
2018-11-07 Tadeu Zagallo <tzagallo@apple.com>
REGRESSION(r237547): Test failures on 32-bit JSC since the JIT was disabled
https://bugs.webkit.org/show_bug.cgi?id=191184
Reviewed by Saam Barati.
Fix API test on CLoop: we can only disable the LLInt when the JIT is enabled.
* API/tests/PingPongStackOverflowTest.cpp:
(testPingPongStackOverflow):
2018-11-06 Justin Fan <justin_fan@apple.com>
[WebGPU] Experimental prototype for WebGPURenderPipeline and WebGPUSwapChain
https://bugs.webkit.org/show_bug.cgi?id=191291
Reviewed by Myles Maxfield.
Properly disable WEBGPU on all non-Metal platforms for now.
* Configurations/FeatureDefines.xcconfig:
2018-11-06 Keith Rollin <krollin@apple.com>
Adjust handling of Include paths that need quoting
https://bugs.webkit.org/show_bug.cgi?id=191314
<rdar://problem/45849143>
Reviewed by Dan Bernstein.
There are several places in the JavaScriptCore Xcode project where the
paths defined in HEADER_SEARCH_PATHS are quoted. That is, the
definitions look like:
HEADER_SEARCH_PATHS = (
"\"${BUILT_PRODUCTS_DIR}/DerivedSources/JavaScriptCore\"",
"\"${BUILT_PRODUCTS_DIR}/LLIntOffsets/${ARCHS}\"",
"\"$(JAVASCRIPTCORE_FRAMEWORKS_DIR)/JavaScriptCore.framework/PrivateHeaders\"",
"$(inherited)",
);
The idea here is presumably to have the resulting $(CPP) command have
-I options where the associated paths are themselves quoted,
protecting against space characters in the paths.
This approach to quote management can break under Xcode 9. If
.xcfilelist files are added to the project, the 'objectVersion' value
in the Xcode project file is changed from 46 to 51. If a project with
objectVersion=51 is presented to Xcode 9 (as can happen when we build
for older OS's), it produces build lines where the quotes are escaped,
thereby becoming part of the path. The build then fails because a
search for a file normally found in a directory called "Foo" will be
looked for in "\"Foo\"", which doesn't exist.
Simply removing the escaped quotes from the HEADER_SEARCH_PATHS
definition doesn't work, leading to paths that need quoting due to
space characters but that don't get this quoting (the part of the path
after the space appears to simply go missing).
Removing the escaped quotes from the HEADER_SEARCH_PATHS and moving
the definitions to the .xcconfig fixes this problem.
* Configurations/ToolExecutable.xcconfig:
* JavaScriptCore.xcodeproj/project.pbxproj:
2018-11-06 Michael Saboff <msaboff@apple.com>
Multiple stress/regexp-compile-oom.js tests are failing on High Sierra Debug and Release JSC testers.
https://bugs.webkit.org/show_bug.cgi?id=191271
Reviewed by Saam Barati.
Fixed use of ThrowScope my adding release() calls. Found a few places where we needed
RETURN_IF_EXCEPTION(). After some code inspections determined that we need to cover the
exception bubbling for String.match() with a global RegExp as well as String.replace()
and String.search().
* runtime/RegExpObjectInlines.h:
(JSC::RegExpObject::matchInline):
(JSC::collectMatches):
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoFuncSearchFast):
* runtime/StringPrototype.cpp:
(JSC::removeUsingRegExpSearch):
(JSC::replaceUsingRegExpSearch):
2018-11-05 Don Olmstead <don.olmstead@sony.com>
Fix typos in closing ENABLE guards
https://bugs.webkit.org/show_bug.cgi?id=191273
Reviewed by Keith Miller.
* ftl/FTLForOSREntryJITCode.h:
* ftl/FTLJITCode.h:
* jsc.cpp:
* wasm/WasmMemoryInformation.h:
* wasm/WasmPageCount.h:
2018-11-05 Keith Miller <keith_miller@apple.com>
Make static_asserts in APICast into bitwise_cast
https://bugs.webkit.org/show_bug.cgi?id=191272
Reviewed by Filip Pizlo.
* API/APICast.h:
(toJS):
(toJSForGC):
(toRef):
2018-11-05 Dominik Infuehr <dinfuehr@igalia.com>
Enable LLInt on ARMv7/Linux
https://bugs.webkit.org/show_bug.cgi?id=191190
Reviewed by Yusuke Suzuki.
After enabling the new bytecode format in r237547, C_LOOP was
forced on all 32-bit platforms. Now enable LLInt again on
ARMv7-Thumb2/Linux.
This adds a callee-saved register in ARMv7/Linux for the metadataTable and
stores/restores it on LLInt function calls. It also introduces the globaladdr-
instruction for the ARM-offlineasm to access the opcode-table.
* jit/GPRInfo.h:
* jit/RegisterSet.cpp:
(JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* offlineasm/arm.rb:
* offlineasm/asm.rb:
* offlineasm/instructions.rb:
2018-11-05 Fujii Hironori <Hironori.Fujii@sony.com>
[Win][Clang][JSC] JIT::is64BitType reports "warning: explicit specialization cannot have a storage class"
https://bugs.webkit.org/show_bug.cgi?id=191146
Reviewed by Yusuke Suzuki.
* jit/JIT.h: Changed is64BitType from a template class method to a
template inner class.
2018-11-02 Keith Miller <keith_miller@apple.com>
Assert JSValues can fit into a pointer when API casting
https://bugs.webkit.org/show_bug.cgi?id=191220
Reviewed by Michael Saboff.
* API/APICast.h:
(toJS):
(toJSForGC):
(toRef):
2018-11-02 Michael Saboff <msaboff@apple.com>
Rolling in r237753 with unreviewed build fix.
Fixed issues with DECLARE_THROW_SCOPE placement.
2018-11-02 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r237753.
Introduced JSC test failures
Reverted changeset:
"Running out of stack space not properly handled in
RegExp::compile() and its callers"
https://bugs.webkit.org/show_bug.cgi?id=191206
https://trac.webkit.org/changeset/237753
2018-11-02 Michael Saboff <msaboff@apple.com>
Running out of stack space not properly handled in RegExp::compile() and its callers
https://bugs.webkit.org/show_bug.cgi?id=191206
Reviewed by Filip Pizlo.
Eliminated two RELEASE_ASSERT_NOT_REACHED() for errors returned by Yarr parsing code. Bubbled those errors
up to where they are turned into the appropriate exceptions in matchInline(). If the errors are not due
to syntax, we reset the RegExp state in case the parsing is tried with a smaller stack.
* runtime/RegExp.cpp:
(JSC::RegExp::compile):
(JSC::RegExp::compileMatchOnly):
* runtime/RegExp.h:
* runtime/RegExpInlines.h:
(JSC::RegExp::compileIfNecessary):
(JSC::RegExp::matchInline):
(JSC::RegExp::compileIfNecessaryMatchOnly):
* runtime/RegExpObjectInlines.h:
(JSC::RegExpObject::execInline):
* yarr/YarrErrorCode.h:
(JSC::Yarr::hasHardError):
2018-11-02 Keith Miller <keith_miller@apple.com>
API should use wrapper object if address is 32-bit
https://bugs.webkit.org/show_bug.cgi?id=191203
Reviewed by Filip Pizlo.
* API/APICast.h:
(toJS):
(toJSForGC):
(toRef):
2018-11-02 Tadeu Zagallo <tzagallo@apple.com>
Metadata should not be copyable
https://bugs.webkit.org/show_bug.cgi?id=191193
Reviewed by Keith Miller.
We should only ever hold references to the entry in the metadata table.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finalizeLLIntInlineCaches):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* generator/Metadata.rb:
2018-11-02 Tadeu Zagallo <tzagallo@apple.com>
REGRESSION(r237547): Exception handlers should be aware of wide opcodes when JIT is disabled
https://bugs.webkit.org/show_bug.cgi?id=191175
Reviewed by Keith Miller.
https://bugs.webkit.org/show_bug.cgi?id=191108 did not handle the case where JIT is not enabled
* jit/JITExceptions.cpp:
(JSC::genericUnwind):
* llint/LLIntData.h:
(JSC::LLInt::getWideCodePtr):
2018-11-01 Fujii Hironori <Hironori.Fujii@sony.com>
Rename <wtf/unicode/UTF8.h> to <wtf/unicode/UTF8Conversion.h> in order to avoid conflicting with ICU's unicode/utf8.h
https://bugs.webkit.org/show_bug.cgi?id=189693
Reviewed by Yusuke Suzuki.
* API/JSClassRef.cpp: Replaced <wtf/unicode/UTF8.h> with <wtf/unicode/UTF8Conversion.h>.
* API/JSStringRef.cpp: Ditto.
* runtime/JSGlobalObjectFunctions.cpp: Ditto.
* wasm/WasmParser.h: Ditto.
2018-11-01 Keith Miller <keith_miller@apple.com>
Unreviewed, JavaScriptCore should only guarantee to produce a
modulemap if we are building for iOSMac.
* Configurations/JavaScriptCore.xcconfig:
2018-10-31 Devin Rousso <drousso@apple.com>
Web Inspector: Canvas: create a setting for auto-recording newly created contexts
https://bugs.webkit.org/show_bug.cgi?id=190856
Reviewed by Brian Burg.
* inspector/protocol/Canvas.json:
Add `setRecordingAutoCaptureFrameCount` command for setting the number of frames to record
immediately after a context is created.
* inspector/protocol/Recording.json:
Add `creation` value for `Initiator` enum.
2018-10-31 Devin Rousso <drousso@apple.com>
Web Inspector: display low-power enter/exit events in Timelines and Network node waterfalls
https://bugs.webkit.org/show_bug.cgi?id=190641
<rdar://problem/45319049>
Reviewed by Joseph Pecoraro.
* inspector/protocol/DOM.json:
Add `videoLowPowerChanged` event that is fired when `InspectorDOMAgent` is able to determine
whether a video element's low power state has changed.
2018-10-31 Tadeu Zagallo <tzagallo@apple.com>
Adjust inlining threshold for new bytecode format
https://bugs.webkit.org/show_bug.cgi?id=191115
Reviewed by Saam Barati.
The new format reduced the number of operands for many opcodes, which
changed inlining decisions and impacted performance negatively.
* runtime/Options.h:
2018-10-31 Tadeu Zagallo <tzagallo@apple.com>
REGRESSION(r237547): Exception handlers should be aware of wide opcodes
https://bugs.webkit.org/show_bug.cgi?id=191108
<rdar://problem/45690700>
Reviewed by Saam Barati.
When linking the handler, we need to check whether the target op_catch is
wide or narrow in order to chose the right code pointer for the handler.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
2018-10-31 Dominik Infuehr <dinfuehr@igalia.com>
Align entries in metadata table
https://bugs.webkit.org/show_bug.cgi?id=191062
Reviewed by Filip Pizlo.
Entries in the metadata table need to be aligned on some 32-bit
architectures.
* bytecode/MetadataTable.h:
(JSC::MetadataTable::forEach):
* bytecode/Opcode.cpp:
(JSC::metadataAlignment):
* bytecode/Opcode.h:
* bytecode/UnlinkedMetadataTableInlines.h:
(JSC::UnlinkedMetadataTable::finalize):
* generator/Section.rb:
2018-10-31 Jim Mason <jmason@ibinx.com>
Static global 'fastHandlerInstalled' conditionally declared in WasmFaultSignalHandler.cpp
https://bugs.webkit.org/show_bug.cgi?id=191063
Reviewed by Yusuke Suzuki.
* wasm/WasmFaultSignalHandler.cpp:
2018-10-30 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC][LLInt] Compact LLInt ASM code by removing unnecessary instructions
https://bugs.webkit.org/show_bug.cgi?id=191092
Reviewed by Saam Barati.
Looking through LLIntAssembly.h, we can find several inefficiencies. This patch fixes the
following things to tighten LLInt ASM code.
1. Remove unnecessary load instructions. Use jmp with BaseIndex directly.
2. Introduce strength reduction for mul instructions in offlineasm layer. This is now critical
since mul instruction is executed in `metadata` operation in LLInt. If the given immediate is
a power of two, we convert it to lshift instruction.
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* offlineasm/arm64.rb:
* offlineasm/instructions.rb:
* offlineasm/x86.rb:
2018-10-30 Don Olmstead <don.olmstead@sony.com>
[PlayStation] Enable JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=191072
Reviewed by Brent Fulgham.
Add platform files for the PlayStation port.
* PlatformPlayStation.cmake: Added.
2018-10-30 Alexey Proskuryakov <ap@apple.com>
Clean up some obsolete MAX_ALLOWED macros
https://bugs.webkit.org/show_bug.cgi?id=190916
Reviewed by Tim Horton.
* API/JSManagedValue.mm:
* API/JSVirtualMachine.mm:
* API/JSWrapperMap.mm:
2018-10-30 Ross Kirsling <ross.kirsling@sony.com>
useProbeOSRExit causes failures for Win64 DFG JIT
https://bugs.webkit.org/show_bug.cgi?id=190656
Reviewed by Keith Miller.
* assembler/ProbeContext.cpp:
(JSC::Probe::executeProbe):
If lowWatermark is expected to equal lowWatermarkFromVisitingDirtyPages *regardless* of the input param,
then let's just call lowWatermarkFromVisitingDirtyPages instead.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::executeOSRExit):
The result of VariableEventStream::reconstruct appears to be inappropriate for direct use as a stack pointer offset;
mimic the non-probe case and use requiredRegisterCountForExit from DFGCommonData instead.
(Also, stop redundantly setting the stack pointer twice in a row.)
2018-10-30 Yusuke Suzuki <yusukesuzuki@slowstart.org>
"Unreviewed, partial rolling in r237254"
https://bugs.webkit.org/show_bug.cgi?id=190340
This only adds Parser.{cpp,h}. And it is not used in this patch.
It examines that the regression is related to exact Parser changes.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseSingleFunction):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
(JSC::parse):
(JSC::parseFunctionForFunctionConstructor):
2018-10-29 Mark Lam <mark.lam@apple.com>
Correctly detect string overflow when using the 'Function' constructor.
https://bugs.webkit.org/show_bug.cgi?id=184883
<rdar://problem/36320331>
Reviewed by Saam Barati.
Added StringBuilder::hasOverflowed() checks, and throwing OutOfMemoryErrors if
we detect an overflow.
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::encode):
(JSC::decode):
* runtime/JSONObject.cpp:
(JSC::Stringifier::stringify):
(JSC::Stringifier::appendStringifiedValue):
2018-10-29 Tadeu Zagallo <tzagallo@apple.com>
Unreviewed, fix JSC on arm64e after r237547
https://bugs.webkit.org/show_bug.cgi?id=187373
Unreviewed.
Remove unused move guarded by POINTER_PROFILING that was trashing the
metadata on arm64e.
* llint/LowLevelInterpreter64.asm:
2018-10-29 Keith Miller <keith_miller@apple.com>
JSC should explicitly list its modulemap file
https://bugs.webkit.org/show_bug.cgi?id=191032
Reviewed by Saam Barati.
The automagically generated module map file for JSC will
include headers where they may not work out of the box.
This patch makes it so we now export the same modulemap
that used to be provided via the legacy system.
* Configurations/JavaScriptCore.xcconfig:
* JavaScriptCore.modulemap: Added.
* JavaScriptCore.xcodeproj/project.pbxproj:
2018-10-29 Tim Horton <timothy_horton@apple.com>
Modernize WebKit nibs and lprojs for localization's sake
https://bugs.webkit.org/show_bug.cgi?id=190911
<rdar://problem/45349466>
Reviewed by Dan Bernstein.
* JavaScriptCore.xcodeproj/project.pbxproj:
English->en
2018-10-29 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r237492.
https://bugs.webkit.org/show_bug.cgi?id=191035
"It regresses JetStream 2 by 5% on some iOS devices"
(Requested by saamyjoon on #webkit).
Reverted changeset:
"Unreviewed, partial rolling in r237254"
https://bugs.webkit.org/show_bug.cgi?id=190340
https://trac.webkit.org/changeset/237492
2018-10-29 Tadeu Zagallo <tzagallo@apple.com>
Add support for GetStack FlushedDouble
https://bugs.webkit.org/show_bug.cgi?id=191012
<rdar://problem/45265141>
Reviewed by Saam Barati.
LowerDFGToB3::compileGetStack assumed that we would not emit GetStack
for doubles, but it turns out it may arise from the PutStack sinking
phase: if we sink a PutStack into a successor block, other predecessors
will emit a GetStack followed by a Upsilon.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetStack):
2018-10-29 Tadeu Zagallo <tzagallo@apple.com>
New bytecode format for JSC
https://bugs.webkit.org/show_bug.cgi?id=187373
<rdar://problem/44186758>
Reviewed by Filip Pizlo.
Replace unlinked and linked bytecode with a new immutable bytecode that does not embed
any addresses. Instructions can be encoded as narrow (1-byte operands) or wide (4-byte
operands) and might contain an extra operand, the metadataID. The metadataID is used to
access the instruction's mutable data in a side table in the CodeBlock (the MetadataTable).
Bytecodes now must be structs declared in the new BytecodeList.rb. All bytecodes give names
and types to all its operands. Additionally, reading a bytecode from the instruction stream
requires decoding the whole bytecode, i.e. it's no longer possible to access arbitrary
operands directly from the stream.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* assembler/MacroAssemblerCodeRef.h:
(JSC::ReturnAddressPtr::ReturnAddressPtr):
(JSC::ReturnAddressPtr::value const):
(JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr):
(JSC::MacroAssemblerCodePtr::createFromExecutableAddress):
* bytecode/ArithProfile.h:
(JSC::ArithProfile::ArithProfile):
* bytecode/ArrayAllocationProfile.h:
(JSC::ArrayAllocationProfile::ArrayAllocationProfile):
* bytecode/ArrayProfile.h:
* bytecode/BytecodeBasicBlock.cpp:
(JSC::isJumpTarget):
(JSC::BytecodeBasicBlock::computeImpl):
(JSC::BytecodeBasicBlock::compute):
* bytecode/BytecodeBasicBlock.h:
(JSC::BytecodeBasicBlock::leaderOffset const):
(JSC::BytecodeBasicBlock::totalLength const):
(JSC::BytecodeBasicBlock::offsets const):
(JSC::BytecodeBasicBlock::BytecodeBasicBlock):
(JSC::BytecodeBasicBlock::addLength):
* bytecode/BytecodeDumper.cpp:
(JSC::BytecodeDumper<Block>::printLocationAndOp):
(JSC::BytecodeDumper<Block>::dumpBytecode):
(JSC::BytecodeDumper<Block>::dumpIdentifiers):
(JSC::BytecodeDumper<Block>::dumpConstants):
(JSC::BytecodeDumper<Block>::dumpExceptionHandlers):
(JSC::BytecodeDumper<Block>::dumpSwitchJumpTables):
(JSC::BytecodeDumper<Block>::dumpStringSwitchJumpTables):
(JSC::BytecodeDumper<Block>::dumpBlock):
* bytecode/BytecodeDumper.h:
(JSC::BytecodeDumper::dumpOperand):
(JSC::BytecodeDumper::dumpValue):
(JSC::BytecodeDumper::BytecodeDumper):
(JSC::BytecodeDumper::block const):
* bytecode/BytecodeGeneratorification.cpp:
(JSC::BytecodeGeneratorification::BytecodeGeneratorification):
(JSC::BytecodeGeneratorification::enterPoint const):
(JSC::BytecodeGeneratorification::instructions const):
(JSC::GeneratorLivenessAnalysis::run):
(JSC::BytecodeGeneratorification::run):
(JSC::performGeneratorification):
* bytecode/BytecodeGeneratorification.h:
* bytecode/BytecodeGraph.h:
(JSC::BytecodeGraph::blockContainsBytecodeOffset):
(JSC::BytecodeGraph::findBasicBlockForBytecodeOffset):
(JSC::BytecodeGraph::findBasicBlockWithLeaderOffset):
(JSC::BytecodeGraph::BytecodeGraph):
* bytecode/BytecodeKills.h:
* bytecode/BytecodeList.json: Removed.
* bytecode/BytecodeList.rb: Added.
* bytecode/BytecodeLivenessAnalysis.cpp:
(JSC::BytecodeLivenessAnalysis::dumpResults):
* bytecode/BytecodeLivenessAnalysis.h:
* bytecode/BytecodeLivenessAnalysisInlines.h:
(JSC::isValidRegisterForLiveness):
(JSC::BytecodeLivenessPropagation::stepOverInstruction):
* bytecode/BytecodeRewriter.cpp:
(JSC::BytecodeRewriter::applyModification):
(JSC::BytecodeRewriter::execute):
(JSC::BytecodeRewriter::adjustJumpTargetsInFragment):
(JSC::BytecodeRewriter::insertImpl):
(JSC::BytecodeRewriter::adjustJumpTarget):
(JSC::BytecodeRewriter::adjustJumpTargets):
* bytecode/BytecodeRewriter.h:
(JSC::BytecodeRewriter::InsertionPoint::InsertionPoint):
(JSC::BytecodeRewriter::Fragment::Fragment):
(JSC::BytecodeRewriter::Fragment::appendInstruction):
(JSC::BytecodeRewriter::BytecodeRewriter):
(JSC::BytecodeRewriter::insertFragmentBefore):
(JSC::BytecodeRewriter::insertFragmentAfter):
(JSC::BytecodeRewriter::removeBytecode):
(JSC::BytecodeRewriter::adjustAbsoluteOffset):
(JSC::BytecodeRewriter::adjustJumpTarget):
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFromLLInt):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::estimatedSize):
(JSC::CodeBlock::visitChildren):
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::finalizeLLIntInlineCaches):
(JSC::CodeBlock::addJITAddIC):
(JSC::CodeBlock::addJITMulIC):
(JSC::CodeBlock::addJITSubIC):
(JSC::CodeBlock::addJITNegIC):
(JSC::CodeBlock::stronglyVisitStrongReferences):
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffset):
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
(JSC::CodeBlock::hasOpDebugForLineAndColumn):
(JSC::CodeBlock::getArrayProfile):
(JSC::CodeBlock::updateAllArrayPredictions):
(JSC::CodeBlock::predictedMachineCodeSize):
(JSC::CodeBlock::tryGetValueProfileForBytecodeOffset):
(JSC::CodeBlock::valueProfilePredictionForBytecodeOffset):
(JSC::CodeBlock::valueProfileForBytecodeOffset):
(JSC::CodeBlock::validate):
(JSC::CodeBlock::outOfLineJumpOffset):
(JSC::CodeBlock::outOfLineJumpTarget):
(JSC::CodeBlock::arithProfileForBytecodeOffset):
(JSC::CodeBlock::arithProfileForPC):
(JSC::CodeBlock::couldTakeSpecialFastCase):
(JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::addMathIC):
(JSC::CodeBlock::outOfLineJumpOffset):
(JSC::CodeBlock::bytecodeOffset):
(JSC::CodeBlock::instructions const):
(JSC::CodeBlock::instructionCount const):
(JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters):
(JSC::CodeBlock::metadata):
(JSC::CodeBlock::metadataSizeInBytes):
(JSC::CodeBlock::numberOfNonArgumentValueProfiles):
(JSC::CodeBlock::totalNumberOfValueProfiles):
* bytecode/CodeBlockInlines.h: Added.
(JSC::CodeBlock::forEachValueProfile):
(JSC::CodeBlock::forEachArrayProfile):
(JSC::CodeBlock::forEachArrayAllocationProfile):
(JSC::CodeBlock::forEachObjectAllocationProfile):
(JSC::CodeBlock::forEachLLIntCallLinkInfo):
* bytecode/Fits.h: Added.
* bytecode/GetByIdMetadata.h: Copied from Source/JavaScriptCore/bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h.
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFromLLInt):
* bytecode/Instruction.h:
(JSC::Instruction::Instruction):
(JSC::Instruction::Impl::opcodeID const):
(JSC::Instruction::opcodeID const):
(JSC::Instruction::name const):
(JSC::Instruction::isWide const):
(JSC::Instruction::size const):
(JSC::Instruction::is const):
(JSC::Instruction::as const):
(JSC::Instruction::cast):
(JSC::Instruction::cast const):
(JSC::Instruction::narrow const):
(JSC::Instruction::wide const):
* bytecode/InstructionStream.cpp: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
(JSC::InstructionStream::InstructionStream):
(JSC::InstructionStream::sizeInBytes const):
* bytecode/InstructionStream.h: Added.
(JSC::InstructionStream::BaseRef::BaseRef):
(JSC::InstructionStream::BaseRef::operator=):
(JSC::InstructionStream::BaseRef::operator-> const):
(JSC::InstructionStream::BaseRef::ptr const):
(JSC::InstructionStream::BaseRef::operator!= const):
(JSC::InstructionStream::BaseRef::next const):
(JSC::InstructionStream::BaseRef::offset const):
(JSC::InstructionStream::BaseRef::isValid const):
(JSC::InstructionStream::BaseRef::unwrap const):
(JSC::InstructionStream::MutableRef::freeze const):
(JSC::InstructionStream::MutableRef::operator->):
(JSC::InstructionStream::MutableRef::ptr):
(JSC::InstructionStream::MutableRef::operator Ref):
(JSC::InstructionStream::MutableRef::unwrap):
(JSC::InstructionStream::iterator::operator*):
(JSC::InstructionStream::iterator::operator++):
(JSC::InstructionStream::begin const):
(JSC::InstructionStream::end const):
(JSC::InstructionStream::at const):
(JSC::InstructionStream::size const):
(JSC::InstructionStreamWriter::InstructionStreamWriter):
(JSC::InstructionStreamWriter::ref):
(JSC::InstructionStreamWriter::seek):
(JSC::InstructionStreamWriter::position):
(JSC::InstructionStreamWriter::write):
(JSC::InstructionStreamWriter::rewind):
(JSC::InstructionStreamWriter::finalize):
(JSC::InstructionStreamWriter::swap):
(JSC::InstructionStreamWriter::iterator::operator*):
(JSC::InstructionStreamWriter::iterator::operator++):
(JSC::InstructionStreamWriter::begin):
(JSC::InstructionStreamWriter::end):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::clearLLIntGetByIdCache):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* bytecode/MetadataTable.cpp: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
(JSC::MetadataTable::MetadataTable):
(JSC::DeallocTable::withOpcodeType):
(JSC::MetadataTable::~MetadataTable):
(JSC::MetadataTable::sizeInBytes):
* bytecode/MetadataTable.h: Copied from Source/JavaScriptCore/runtime/Watchdog.h.
(JSC::MetadataTable::get):
(JSC::MetadataTable::forEach):
(JSC::MetadataTable::getImpl):
* bytecode/Opcode.cpp:
(JSC::metadataSize):
* bytecode/Opcode.h:
(JSC::padOpcodeName):
* bytecode/OpcodeInlines.h:
(JSC::isOpcodeShape):
(JSC::getOpcodeType):
* bytecode/OpcodeSize.h: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
* bytecode/PreciseJumpTargets.cpp:
(JSC::getJumpTargetsForInstruction):
(JSC::computePreciseJumpTargetsInternal):
(JSC::computePreciseJumpTargets):
(JSC::recomputePreciseJumpTargets):
(JSC::findJumpTargetsForInstruction):
* bytecode/PreciseJumpTargets.h:
* bytecode/PreciseJumpTargetsInlines.h:
(JSC::jumpTargetForInstruction):
(JSC::extractStoredJumpTargetsForInstruction):
(JSC::updateStoredJumpTargetsForInstruction):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
* bytecode/SpecialPointer.cpp:
(WTF::printInternal):
* bytecode/SpecialPointer.h:
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
(JSC::UnlinkedCodeBlock::visitChildren):
(JSC::UnlinkedCodeBlock::estimatedSize):
(JSC::UnlinkedCodeBlock::lineNumberForBytecodeOffset):
(JSC::dumpLineColumnEntry):
(JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset const):
(JSC::UnlinkedCodeBlock::setInstructions):
(JSC::UnlinkedCodeBlock::instructions const):
(JSC::UnlinkedCodeBlock::applyModification):
(JSC::UnlinkedCodeBlock::addOutOfLineJumpTarget):
(JSC::UnlinkedCodeBlock::outOfLineJumpOffset):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::addPropertyAccessInstruction):
(JSC::UnlinkedCodeBlock::propertyAccessInstructions const):
(JSC::UnlinkedCodeBlock::addOpProfileControlFlowBytecodeOffset):
(JSC::UnlinkedCodeBlock::opProfileControlFlowBytecodeOffsets const):
(JSC::UnlinkedCodeBlock::metadata):
(JSC::UnlinkedCodeBlock::metadataSizeInBytes):
(JSC::UnlinkedCodeBlock::outOfLineJumpOffset):
(JSC::UnlinkedCodeBlock::replaceOutOfLineJumpTargets):
* bytecode/UnlinkedInstructionStream.cpp: Removed.
* bytecode/UnlinkedInstructionStream.h: Removed.
* bytecode/UnlinkedMetadataTable.h: Copied from Source/JavaScriptCore/bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h.
* bytecode/UnlinkedMetadataTableInlines.h: Added.
(JSC::UnlinkedMetadataTable::UnlinkedMetadataTable):
(JSC::UnlinkedMetadataTable::~UnlinkedMetadataTable):
(JSC::UnlinkedMetadataTable::addEntry):
(JSC::UnlinkedMetadataTable::sizeInBytes):
(JSC::UnlinkedMetadataTable::finalize):
(JSC::UnlinkedMetadataTable::link):
(JSC::UnlinkedMetadataTable::unlink):
* bytecode/VirtualRegister.cpp:
(JSC::VirtualRegister::VirtualRegister):
* bytecode/VirtualRegister.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::Label::setLocation):
(JSC::Label::bind):
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeVarLexicalEnvironment):
(JSC::BytecodeGenerator::emitEnter):
(JSC::BytecodeGenerator::emitLoopHint):
(JSC::BytecodeGenerator::emitJump):
(JSC::BytecodeGenerator::emitCheckTraps):
(JSC::BytecodeGenerator::rewind):
(JSC::BytecodeGenerator::fuseCompareAndJump):
(JSC::BytecodeGenerator::fuseTestAndJmp):
(JSC::BytecodeGenerator::emitJumpIfTrue):
(JSC::BytecodeGenerator::emitJumpIfFalse):
(JSC::BytecodeGenerator::emitJumpIfNotFunctionCall):
(JSC::BytecodeGenerator::emitJumpIfNotFunctionApply):
(JSC::BytecodeGenerator::moveLinkTimeConstant):
(JSC::BytecodeGenerator::moveEmptyValue):
(JSC::BytecodeGenerator::emitMove):
(JSC::BytecodeGenerator::emitUnaryOp):
(JSC::BytecodeGenerator::emitBinaryOp):
(JSC::BytecodeGenerator::emitToObject):
(JSC::BytecodeGenerator::emitToNumber):
(JSC::BytecodeGenerator::emitToString):
(JSC::BytecodeGenerator::emitTypeOf):
(JSC::BytecodeGenerator::emitInc):
(JSC::BytecodeGenerator::emitDec):
(JSC::BytecodeGenerator::emitEqualityOp):
(JSC::BytecodeGenerator::emitProfileType):
(JSC::BytecodeGenerator::emitProfileControlFlow):
(JSC::BytecodeGenerator::pushLexicalScopeInternal):
(JSC::BytecodeGenerator::emitResolveScopeForHoistingFuncDeclInEval):
(JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
(JSC::BytecodeGenerator::emitOverridesHasInstance):
(JSC::BytecodeGenerator::emitResolveScope):
(JSC::BytecodeGenerator::emitGetFromScope):
(JSC::BytecodeGenerator::emitPutToScope):
(JSC::BytecodeGenerator::emitInstanceOf):
(JSC::BytecodeGenerator::emitInstanceOfCustom):
(JSC::BytecodeGenerator::emitInByVal):
(JSC::BytecodeGenerator::emitInById):
(JSC::BytecodeGenerator::emitTryGetById):
(JSC::BytecodeGenerator::emitGetById):
(JSC::BytecodeGenerator::emitDirectGetById):
(JSC::BytecodeGenerator::emitPutById):
(JSC::BytecodeGenerator::emitDirectPutById):
(JSC::BytecodeGenerator::emitPutGetterById):
(JSC::BytecodeGenerator::emitPutSetterById):
(JSC::BytecodeGenerator::emitPutGetterSetter):
(JSC::BytecodeGenerator::emitPutGetterByVal):
(JSC::BytecodeGenerator::emitPutSetterByVal):
(JSC::BytecodeGenerator::emitDeleteById):
(JSC::BytecodeGenerator::emitGetByVal):
(JSC::BytecodeGenerator::emitPutByVal):
(JSC::BytecodeGenerator::emitDirectPutByVal):
(JSC::BytecodeGenerator::emitDeleteByVal):
(JSC::BytecodeGenerator::emitSuperSamplerBegin):
(JSC::BytecodeGenerator::emitSuperSamplerEnd):
(JSC::BytecodeGenerator::emitIdWithProfile):
(JSC::BytecodeGenerator::emitUnreachable):
(JSC::BytecodeGenerator::emitGetArgument):
(JSC::BytecodeGenerator::emitCreateThis):
(JSC::BytecodeGenerator::emitTDZCheck):
(JSC::BytecodeGenerator::emitNewObject):
(JSC::BytecodeGenerator::emitNewArrayBuffer):
(JSC::BytecodeGenerator::emitNewArray):
(JSC::BytecodeGenerator::emitNewArrayWithSpread):
(JSC::BytecodeGenerator::emitNewArrayWithSize):
(JSC::BytecodeGenerator::emitNewRegExp):
(JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
(JSC::BytecodeGenerator::emitNewDefaultConstructor):
(JSC::BytecodeGenerator::emitNewFunction):
(JSC::BytecodeGenerator::emitSetFunctionNameIfNeeded):
(JSC::BytecodeGenerator::emitCall):
(JSC::BytecodeGenerator::emitCallInTailPosition):
(JSC::BytecodeGenerator::emitCallEval):
(JSC::BytecodeGenerator::emitExpectedFunctionSnippet):
(JSC::BytecodeGenerator::emitCallVarargs):
(JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
(JSC::BytecodeGenerator::emitConstructVarargs):
(JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition):
(JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary):
(JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary):
(JSC::BytecodeGenerator::emitCallDefineProperty):
(JSC::BytecodeGenerator::emitReturn):
(JSC::BytecodeGenerator::emitEnd):
(JSC::BytecodeGenerator::emitConstruct):
(JSC::BytecodeGenerator::emitStrcat):
(JSC::BytecodeGenerator::emitToPrimitive):
(JSC::BytecodeGenerator::emitGetScope):
(JSC::BytecodeGenerator::emitPushWithScope):
(JSC::BytecodeGenerator::emitGetParentScope):
(JSC::BytecodeGenerator::emitDebugHook):
(JSC::BytecodeGenerator::emitCatch):
(JSC::BytecodeGenerator::emitThrow):
(JSC::BytecodeGenerator::emitArgumentCount):
(JSC::BytecodeGenerator::emitThrowStaticError):
(JSC::BytecodeGenerator::beginSwitch):
(JSC::prepareJumpTableForSwitch):
(JSC::prepareJumpTableForStringSwitch):
(JSC::BytecodeGenerator::endSwitch):
(JSC::BytecodeGenerator::emitGetEnumerableLength):
(JSC::BytecodeGenerator::emitHasGenericProperty):
(JSC::BytecodeGenerator::emitHasIndexedProperty):
(JSC::BytecodeGenerator::emitHasStructureProperty):
(JSC::BytecodeGenerator::emitGetPropertyEnumerator):
(JSC::BytecodeGenerator::emitEnumeratorStructurePropertyName):
(JSC::BytecodeGenerator::emitEnumeratorGenericPropertyName):
(JSC::BytecodeGenerator::emitToIndexString):
(JSC::BytecodeGenerator::emitIsCellWithType):
(JSC::BytecodeGenerator::emitIsObject):
(JSC::BytecodeGenerator::emitIsNumber):
(JSC::BytecodeGenerator::emitIsUndefined):
(JSC::BytecodeGenerator::emitIsEmpty):
(JSC::BytecodeGenerator::emitRestParameter):
(JSC::BytecodeGenerator::emitRequireObjectCoercible):
(JSC::BytecodeGenerator::emitYieldPoint):
(JSC::BytecodeGenerator::emitYield):
(JSC::BytecodeGenerator::emitGetAsyncIterator):
(JSC::BytecodeGenerator::emitDelegateYield):
(JSC::BytecodeGenerator::emitFinallyCompletion):
(JSC::BytecodeGenerator::emitJumpIf):
(JSC::ForInContext::finalize):
(JSC::StructureForInContext::finalize):
(JSC::IndexedForInContext::finalize):
(JSC::StaticPropertyAnalysis::record):
(JSC::BytecodeGenerator::emitToThis):
* bytecompiler/BytecodeGenerator.h:
(JSC::StructureForInContext::addGetInst):
(JSC::BytecodeGenerator::recordOpcode):
(JSC::BytecodeGenerator::addMetadataFor):
(JSC::BytecodeGenerator::emitUnaryOp):
(JSC::BytecodeGenerator::kill):
(JSC::BytecodeGenerator::instructions const):
(JSC::BytecodeGenerator::write):
(JSC::BytecodeGenerator::withWriter):
* bytecompiler/Label.h:
(JSC::Label::Label):
(JSC::Label::bind):
* bytecompiler/NodesCodegen.cpp:
(JSC::ArrayNode::emitBytecode):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_argumentCount):
(JSC::ApplyFunctionCallDotNode::emitBytecode):
(JSC::BitwiseNotNode::emitBytecode):
(JSC::BinaryOpNode::emitBytecode):
(JSC::EqualNode::emitBytecode):
(JSC::StrictEqualNode::emitBytecode):
(JSC::emitReadModifyAssignment):
(JSC::ForInNode::emitBytecode):
(JSC::CaseBlockNode::emitBytecodeForBlock):
(JSC::FunctionNode::emitBytecode):
(JSC::ClassExprNode::emitBytecode):
* bytecompiler/ProfileTypeBytecodeFlag.cpp: Copied from Source/JavaScriptCore/bytecode/VirtualRegister.cpp.
(WTF::printInternal):
* bytecompiler/ProfileTypeBytecodeFlag.h: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
* bytecompiler/RegisterID.h:
* bytecompiler/StaticPropertyAnalysis.h:
(JSC::StaticPropertyAnalysis::create):
(JSC::StaticPropertyAnalysis::StaticPropertyAnalysis):
* bytecompiler/StaticPropertyAnalyzer.h:
(JSC::StaticPropertyAnalyzer::createThis):
(JSC::StaticPropertyAnalyzer::newObject):
(JSC::StaticPropertyAnalyzer::putById):
(JSC::StaticPropertyAnalyzer::mov):
(JSC::StaticPropertyAnalyzer::kill):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addCall):
(JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
(JSC::DFG::ByteCodeParser::getArrayMode):
(JSC::DFG::ByteCodeParser::handleCall):
(JSC::DFG::ByteCodeParser::handleVarargsCall):
(JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
(JSC::DFG::ByteCodeParser::inlineCall):
(JSC::DFG::ByteCodeParser::handleCallVariant):
(JSC::DFG::ByteCodeParser::handleVarargsInlining):
(JSC::DFG::ByteCodeParser::handleInlining):
(JSC::DFG::ByteCodeParser::handleMinMax):
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
(JSC::DFG::ByteCodeParser::handleDOMJITCall):
(JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
(JSC::DFG::ByteCodeParser::handleDOMJITGetter):
(JSC::DFG::ByteCodeParser::handleModuleNamespaceLoad):
(JSC::DFG::ByteCodeParser::handleTypedArrayConstructor):
(JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::handlePutById):
(JSC::DFG::ByteCodeParser::parseGetById):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::parseCodeBlock):
(JSC::DFG::ByteCodeParser::handlePutByVal):
(JSC::DFG::ByteCodeParser::handlePutAccessorById):
(JSC::DFG::ByteCodeParser::handlePutAccessorByVal):
(JSC::DFG::ByteCodeParser::handleNewFunc):
(JSC::DFG::ByteCodeParser::handleNewFuncExp):
(JSC::DFG::ByteCodeParser::parse):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGCapabilities.h:
(JSC::DFG::capabilityLevel):
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareCatchOSREntry):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueAdd):
(JSC::DFG::SpeculativeJIT::compileValueSub):
(JSC::DFG::SpeculativeJIT::compileValueNegate):
(JSC::DFG::SpeculativeJIT::compileArithMul):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
(JSC::FTL::DFG::LowerDFGToB3::compileValueSub):
(JSC::FTL::DFG::LowerDFGToB3::compileUnaryMathIC):
(JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC):
(JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
(JSC::FTL::DFG::LowerDFGToB3::compileArithMul):
(JSC::FTL::DFG::LowerDFGToB3::compileValueNegate):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
* generate-bytecode-files: Removed.
* generator/Argument.rb: Added.
* generator/Assertion.rb: Added.
* generator/DSL.rb: Added.
* generator/Fits.rb: Added.
* generator/GeneratedFile.rb: Added.
* generator/Metadata.rb: Added.
* generator/Opcode.rb: Added.
* generator/OpcodeGroup.rb: Added.
* generator/Options.rb: Added.
* generator/Section.rb: Added.
* generator/Template.rb: Added.
* generator/Type.rb: Added.
* generator/main.rb: Added.
* interpreter/AbstractPC.h:
* interpreter/CallFrame.cpp:
(JSC::CallFrame::currentVPC const):
(JSC::CallFrame::setCurrentVPC):
* interpreter/CallFrame.h:
(JSC::CallSiteIndex::CallSiteIndex):
(JSC::ExecState::setReturnPC):
* interpreter/Interpreter.cpp:
(WTF::printInternal):
* interpreter/Interpreter.h:
* interpreter/InterpreterInlines.h:
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::dump const):
* interpreter/VMEntryRecord.h:
* jit/JIT.cpp:
(JSC::JIT::JIT):
(JSC::JIT::emitSlowCaseCall):
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
(JSC::JIT::compileWithoutLinking):
(JSC::JIT::link):
* jit/JIT.h:
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_jless):
(JSC::JIT::emit_op_jlesseq):
(JSC::JIT::emit_op_jgreater):
(JSC::JIT::emit_op_jgreatereq):
(JSC::JIT::emit_op_jnless):
(JSC::JIT::emit_op_jnlesseq):
(JSC::JIT::emit_op_jngreater):
(JSC::JIT::emit_op_jngreatereq):
(JSC::JIT::emitSlow_op_jless):
(JSC::JIT::emitSlow_op_jlesseq):
(JSC::JIT::emitSlow_op_jgreater):
(JSC::JIT::emitSlow_op_jgreatereq):
(JSC::JIT::emitSlow_op_jnless):
(JSC::JIT::emitSlow_op_jnlesseq):
(JSC::JIT::emitSlow_op_jngreater):
(JSC::JIT::emitSlow_op_jngreatereq):
(JSC::JIT::emit_op_below):
(JSC::JIT::emit_op_beloweq):
(JSC::JIT::emit_op_jbelow):
(JSC::JIT::emit_op_jbeloweq):
(JSC::JIT::emit_op_unsigned):
(JSC::JIT::emit_compareAndJump):
(JSC::JIT::emit_compareUnsignedAndJump):
(JSC::JIT::emit_compareUnsigned):
(JSC::JIT::emit_compareAndJumpSlow):
(JSC::JIT::emit_op_inc):
(JSC::JIT::emit_op_dec):
(JSC::JIT::emit_op_mod):
(JSC::JIT::emitSlow_op_mod):
(JSC::JIT::emit_op_negate):
(JSC::JIT::emitSlow_op_negate):
(JSC::JIT::emitBitBinaryOpFastPath):
(JSC::JIT::emit_op_bitand):
(JSC::JIT::emit_op_bitor):
(JSC::JIT::emit_op_bitxor):
(JSC::JIT::emit_op_lshift):
(JSC::JIT::emitRightShiftFastPath):
(JSC::JIT::emit_op_rshift):
(JSC::JIT::emit_op_urshift):
(JSC::getOperandTypes):
(JSC::JIT::emit_op_add):
(JSC::JIT::emitSlow_op_add):
(JSC::JIT::emitMathICFast):
(JSC::JIT::emitMathICSlow):
(JSC::JIT::emit_op_div):
(JSC::JIT::emit_op_mul):
(JSC::JIT::emitSlow_op_mul):
(JSC::JIT::emit_op_sub):
(JSC::JIT::emitSlow_op_sub):
* jit/JITCall.cpp:
(JSC::JIT::emitPutCallResult):
(JSC::JIT::compileSetupFrame):
(JSC::JIT::compileCallEval):
(JSC::JIT::compileCallEvalSlowCase):
(JSC::JIT::compileTailCall):
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
(JSC::JIT::emit_op_call):
(JSC::JIT::emit_op_tail_call):
(JSC::JIT::emit_op_call_eval):
(JSC::JIT::emit_op_call_varargs):
(JSC::JIT::emit_op_tail_call_varargs):
(JSC::JIT::emit_op_tail_call_forward_arguments):
(JSC::JIT::emit_op_construct_varargs):
(JSC::JIT::emit_op_construct):
(JSC::JIT::emitSlow_op_call):
(JSC::JIT::emitSlow_op_tail_call):
(JSC::JIT::emitSlow_op_call_eval):
(JSC::JIT::emitSlow_op_call_varargs):
(JSC::JIT::emitSlow_op_tail_call_varargs):
(JSC::JIT::emitSlow_op_tail_call_forward_arguments):
(JSC::JIT::emitSlow_op_construct_varargs):
(JSC::JIT::emitSlow_op_construct):
* jit/JITDisassembler.cpp:
(JSC::JITDisassembler::JITDisassembler):
* jit/JITExceptions.cpp:
(JSC::genericUnwind):
* jit/JITInlines.h:
(JSC::JIT::emitDoubleGetByVal):
(JSC::JIT::emitLoadForArrayMode):
(JSC::JIT::emitContiguousGetByVal):
(JSC::JIT::emitArrayStorageGetByVal):
(JSC::JIT::appendCallWithExceptionCheckSetJSValueResultWithProfile):
(JSC::JIT::sampleInstruction):
(JSC::JIT::emitValueProfilingSiteIfProfiledOpcode):
(JSC::JIT::emitValueProfilingSite):
(JSC::JIT::jumpTarget):
(JSC::JIT::copiedGetPutInfo):
(JSC::JIT::copiedArithProfile):
* jit/JITMathIC.h:
(JSC::isProfileEmpty):
(JSC::JITBinaryMathIC::JITBinaryMathIC):
(JSC::JITUnaryMathIC::JITUnaryMathIC):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_mov):
(JSC::JIT::emit_op_end):
(JSC::JIT::emit_op_jmp):
(JSC::JIT::emit_op_new_object):
(JSC::JIT::emitSlow_op_new_object):
(JSC::JIT::emit_op_overrides_has_instance):
(JSC::JIT::emit_op_instanceof):
(JSC::JIT::emitSlow_op_instanceof):
(JSC::JIT::emit_op_instanceof_custom):
(JSC::JIT::emit_op_is_empty):
(JSC::JIT::emit_op_is_undefined):
(JSC::JIT::emit_op_is_boolean):
(JSC::JIT::emit_op_is_number):
(JSC::JIT::emit_op_is_cell_with_type):
(JSC::JIT::emit_op_is_object):
(JSC::JIT::emit_op_ret):
(JSC::JIT::emit_op_to_primitive):
(JSC::JIT::emit_op_set_function_name):
(JSC::JIT::emit_op_not):
(JSC::JIT::emit_op_jfalse):
(JSC::JIT::emit_op_jeq_null):
(JSC::JIT::emit_op_jneq_null):
(JSC::JIT::emit_op_jneq_ptr):
(JSC::JIT::emit_op_eq):
(JSC::JIT::emit_op_jeq):
(JSC::JIT::emit_op_jtrue):
(JSC::JIT::emit_op_neq):
(JSC::JIT::emit_op_jneq):
(JSC::JIT::emit_op_throw):
(JSC::JIT::compileOpStrictEq):
(JSC::JIT::emit_op_stricteq):
(JSC::JIT::emit_op_nstricteq):
(JSC::JIT::compileOpStrictEqJump):
(JSC::JIT::emit_op_jstricteq):
(JSC::JIT::emit_op_jnstricteq):
(JSC::JIT::emitSlow_op_jstricteq):
(JSC::JIT::emitSlow_op_jnstricteq):
(JSC::JIT::emit_op_to_number):
(JSC::JIT::emit_op_to_string):
(JSC::JIT::emit_op_to_object):
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_identity_with_profile):
(JSC::JIT::emit_op_get_parent_scope):
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emit_op_switch_char):
(JSC::JIT::emit_op_switch_string):
(JSC::JIT::emit_op_debug):
(JSC::JIT::emit_op_eq_null):
(JSC::JIT::emit_op_neq_null):
(JSC::JIT::emit_op_enter):
(JSC::JIT::emit_op_get_scope):
(JSC::JIT::emit_op_to_this):
(JSC::JIT::emit_op_create_this):
(JSC::JIT::emit_op_check_tdz):
(JSC::JIT::emitSlow_op_eq):
(JSC::JIT::emitSlow_op_neq):
(JSC::JIT::emitSlow_op_jeq):
(JSC::JIT::emitSlow_op_jneq):
(JSC::JIT::emitSlow_op_instanceof_custom):
(JSC::JIT::emit_op_loop_hint):
(JSC::JIT::emitSlow_op_loop_hint):
(JSC::JIT::emit_op_check_traps):
(JSC::JIT::emit_op_nop):
(JSC::JIT::emit_op_super_sampler_begin):
(JSC::JIT::emit_op_super_sampler_end):
(JSC::JIT::emitSlow_op_check_traps):
(JSC::JIT::emit_op_new_regexp):
(JSC::JIT::emitNewFuncCommon):
(JSC::JIT::emit_op_new_func):
(JSC::JIT::emit_op_new_generator_func):
(JSC::JIT::emit_op_new_async_generator_func):
(JSC::JIT::emit_op_new_async_func):
(JSC::JIT::emitNewFuncExprCommon):
(JSC::JIT::emit_op_new_func_exp):
(JSC::JIT::emit_op_new_generator_func_exp):
(JSC::JIT::emit_op_new_async_func_exp):
(JSC::JIT::emit_op_new_async_generator_func_exp):
(JSC::JIT::emit_op_new_array):
(JSC::JIT::emit_op_new_array_with_size):
(JSC::JIT::emit_op_has_structure_property):
(JSC::JIT::privateCompileHasIndexedProperty):
(JSC::JIT::emit_op_has_indexed_property):
(JSC::JIT::emitSlow_op_has_indexed_property):
(JSC::JIT::emit_op_get_direct_pname):
(JSC::JIT::emit_op_enumerator_structure_pname):
(JSC::JIT::emit_op_enumerator_generic_pname):
(JSC::JIT::emit_op_profile_type):
(JSC::JIT::emit_op_log_shadow_chicken_prologue):
(JSC::JIT::emit_op_log_shadow_chicken_tail):
(JSC::JIT::emit_op_profile_control_flow):
(JSC::JIT::emit_op_argument_count):
(JSC::JIT::emit_op_get_rest_length):
(JSC::JIT::emit_op_get_argument):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_to_this):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emitGetByValWithCachedId):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emit_op_put_by_val_direct):
(JSC::JIT::emit_op_put_by_val):
(JSC::JIT::emitGenericContiguousPutByVal):
(JSC::JIT::emitArrayStoragePutByVal):
(JSC::JIT::emitPutByValWithCachedId):
(JSC::JIT::emitSlow_op_put_by_val):
(JSC::JIT::emit_op_put_getter_by_id):
(JSC::JIT::emit_op_put_setter_by_id):
(JSC::JIT::emit_op_put_getter_setter_by_id):
(JSC::JIT::emit_op_put_getter_by_val):
(JSC::JIT::emit_op_put_setter_by_val):
(JSC::JIT::emit_op_del_by_id):
(JSC::JIT::emit_op_del_by_val):
(JSC::JIT::emit_op_try_get_by_id):
(JSC::JIT::emitSlow_op_try_get_by_id):
(JSC::JIT::emit_op_get_by_id_direct):
(JSC::JIT::emitSlow_op_get_by_id_direct):
(JSC::JIT::emit_op_get_by_id):
(JSC::JIT::emit_op_get_by_id_with_this):
(JSC::JIT::emitSlow_op_get_by_id):
(JSC::JIT::emitSlow_op_get_by_id_with_this):
(JSC::JIT::emit_op_put_by_id):
(JSC::JIT::emitSlow_op_put_by_id):
(JSC::JIT::emit_op_in_by_id):
(JSC::JIT::emitSlow_op_in_by_id):
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emitSlow_op_get_from_scope):
(JSC::JIT::emit_op_put_to_scope):
(JSC::JIT::emitSlow_op_put_to_scope):
(JSC::JIT::emit_op_get_from_arguments):
(JSC::JIT::emit_op_put_to_arguments):
(JSC::JIT::privateCompileGetByVal):
(JSC::JIT::privateCompileGetByValWithCachedId):
(JSC::JIT::privateCompilePutByVal):
(JSC::JIT::privateCompilePutByValWithCachedId):
(JSC::JIT::emitDoubleLoad):
(JSC::JIT::emitContiguousLoad):
(JSC::JIT::emitArrayStorageLoad):
(JSC::JIT::emitDirectArgumentsGetByVal):
(JSC::JIT::emitScopedArgumentsGetByVal):
(JSC::JIT::emitIntTypedArrayGetByVal):
(JSC::JIT::emitFloatTypedArrayGetByVal):
(JSC::JIT::emitIntTypedArrayPutByVal):
(JSC::JIT::emitFloatTypedArrayPutByVal):
* jit/RegisterSet.cpp:
(JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
* jit/SlowPathCall.h:
(JSC::JITSlowPathCall::JITSlowPathCall):
* llint/LLIntData.cpp:
(JSC::LLInt::initialize):
(JSC::LLInt::Data::performAssertions):
* llint/LLIntData.h:
(JSC::LLInt::exceptionInstructions):
(JSC::LLInt::opcodeMap):
(JSC::LLInt::opcodeMapWide):
(JSC::LLInt::getOpcode):
(JSC::LLInt::getOpcodeWide):
(JSC::LLInt::getWideCodePtr):
* llint/LLIntOffsetsExtractor.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::llint_trace_operand):
(JSC::LLInt::llint_trace_value):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::entryOSR):
(JSC::LLInt::setupGetByIdPrototypeCache):
(JSC::LLInt::getByVal):
(JSC::LLInt::handleHostCall):
(JSC::LLInt::setUpCall):
(JSC::LLInt::genericCall):
(JSC::LLInt::varargsSetup):
(JSC::LLInt::commonCallEval):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter.cpp:
(JSC::CLoopRegister::operator const Instruction*):
(JSC::CLoop::execute):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* offlineasm/arm64.rb:
* offlineasm/asm.rb:
* offlineasm/ast.rb:
* offlineasm/cloop.rb:
* offlineasm/generate_offset_extractor.rb:
* offlineasm/instructions.rb:
* offlineasm/offsets.rb:
* offlineasm/parser.rb:
* offlineasm/transform.rb:
* offlineasm/x86.rb:
* parser/ResultType.h:
(JSC::ResultType::dump const):
(JSC::OperandTypes::first const):
(JSC::OperandTypes::second const):
(JSC::OperandTypes::dump const):
* profiler/ProfilerBytecodeSequence.cpp:
(JSC::Profiler::BytecodeSequence::BytecodeSequence):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
(JSC::updateArithProfileForUnaryArithOp):
(JSC::updateArithProfileForBinaryArithOp):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
(JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
* runtime/ExceptionFuzz.cpp:
(JSC::doExceptionFuzzing):
* runtime/ExceptionFuzz.h:
(JSC::doExceptionFuzzingIfEnabled):
* runtime/GetPutInfo.cpp: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
(JSC::GetPutInfo::dump const):
(WTF::printInternal):
* runtime/GetPutInfo.h:
(JSC::GetPutInfo::operand const):
* runtime/JSCPoison.h:
* runtime/JSType.cpp: Added.
(WTF::printInternal):
* runtime/JSType.h:
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::StackFrame::displayName):
* runtime/SamplingProfiler.h:
(JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame):
* runtime/SlowPathReturnType.h:
(JSC::encodeResult):
(JSC::decodeResult):
* runtime/VM.h:
* runtime/Watchdog.h:
* tools/HeapVerifier.cpp:
2018-10-27 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Unreviewed, partial rolling in r237254
https://bugs.webkit.org/show_bug.cgi?id=190340
We do not use the added function right now to investigate what is the reason of the regression.
It also does not include any Parser.{h,cpp} changes to ensure that Parser.cpp's inlining decision
seems culprit of the regression on iOS devices.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
* bytecode/UnlinkedFunctionExecutable.h:
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::SourceCodeKey):
(JSC::SourceCodeKey::operator== const):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
* runtime/CodeCache.h:
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/FunctionExecutable.h:
2018-10-26 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r237479 and r237484.
https://bugs.webkit.org/show_bug.cgi?id=190978
broke JSC on iOS (Requested by tadeuzagallo on #webkit).
Reverted changesets:
"New bytecode format for JSC"
https://bugs.webkit.org/show_bug.cgi?id=187373
https://trac.webkit.org/changeset/237479
"Gardening: Build fix after r237479."
https://bugs.webkit.org/show_bug.cgi?id=187373
https://trac.webkit.org/changeset/237484
2018-10-26 Tadeu Zagallo <tzagallo@apple.com>
Gardening: Build fix after r237479.
https://bugs.webkit.org/show_bug.cgi?id=187373
Unreviewed.
* Configurations/JSC.xcconfig:
* JavaScriptCore.xcodeproj/project.pbxproj:
* llint/LLIntData.cpp:
(JSC::LLInt::initialize):
2018-10-26 Tadeu Zagallo <tzagallo@apple.com>
New bytecode format for JSC
https://bugs.webkit.org/show_bug.cgi?id=187373
<rdar://problem/44186758>
Reviewed by Filip Pizlo.
Replace unlinked and linked bytecode with a new immutable bytecode that does not embed
any addresses. Instructions can be encoded as narrow (1-byte operands) or wide (4-byte
operands) and might contain an extra operand, the metadataID. The metadataID is used to
access the instruction's mutable data in a side table in the CodeBlock (the MetadataTable).
Bytecodes now must be structs declared in the new BytecodeList.rb. All bytecodes give names
and types to all its operands. Additionally, reading a bytecode from the instruction stream
requires decoding the whole bytecode, i.e. it's no longer possible to access arbitrary
operands directly from the stream.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* assembler/MacroAssemblerCodeRef.h:
(JSC::ReturnAddressPtr::ReturnAddressPtr):
(JSC::ReturnAddressPtr::value const):
(JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr):
(JSC::MacroAssemblerCodePtr::createFromExecutableAddress):
* bytecode/ArithProfile.h:
(JSC::ArithProfile::ArithProfile):
* bytecode/ArrayAllocationProfile.h:
(JSC::ArrayAllocationProfile::ArrayAllocationProfile):
* bytecode/ArrayProfile.h:
* bytecode/BytecodeBasicBlock.cpp:
(JSC::isJumpTarget):
(JSC::BytecodeBasicBlock::computeImpl):
(JSC::BytecodeBasicBlock::compute):
* bytecode/BytecodeBasicBlock.h:
(JSC::BytecodeBasicBlock::leaderOffset const):
(JSC::BytecodeBasicBlock::totalLength const):
(JSC::BytecodeBasicBlock::offsets const):
(JSC::BytecodeBasicBlock::BytecodeBasicBlock):
(JSC::BytecodeBasicBlock::addLength):
* bytecode/BytecodeDumper.cpp:
(JSC::BytecodeDumper<Block>::printLocationAndOp):
(JSC::BytecodeDumper<Block>::dumpBytecode):
(JSC::BytecodeDumper<Block>::dumpIdentifiers):
(JSC::BytecodeDumper<Block>::dumpConstants):
(JSC::BytecodeDumper<Block>::dumpExceptionHandlers):
(JSC::BytecodeDumper<Block>::dumpSwitchJumpTables):
(JSC::BytecodeDumper<Block>::dumpStringSwitchJumpTables):
(JSC::BytecodeDumper<Block>::dumpBlock):
* bytecode/BytecodeDumper.h:
(JSC::BytecodeDumper::dumpOperand):
(JSC::BytecodeDumper::dumpValue):
(JSC::BytecodeDumper::BytecodeDumper):
(JSC::BytecodeDumper::block const):
* bytecode/BytecodeGeneratorification.cpp:
(JSC::BytecodeGeneratorification::BytecodeGeneratorification):
(JSC::BytecodeGeneratorification::enterPoint const):
(JSC::BytecodeGeneratorification::instructions const):
(JSC::GeneratorLivenessAnalysis::run):
(JSC::BytecodeGeneratorification::run):
(JSC::performGeneratorification):
* bytecode/BytecodeGeneratorification.h:
* bytecode/BytecodeGraph.h:
(JSC::BytecodeGraph::blockContainsBytecodeOffset):
(JSC::BytecodeGraph::findBasicBlockForBytecodeOffset):
(JSC::BytecodeGraph::findBasicBlockWithLeaderOffset):
(JSC::BytecodeGraph::BytecodeGraph):
* bytecode/BytecodeKills.h:
* bytecode/BytecodeList.json: Removed.
* bytecode/BytecodeList.rb: Added.
* bytecode/BytecodeLivenessAnalysis.cpp:
(JSC::BytecodeLivenessAnalysis::dumpResults):
* bytecode/BytecodeLivenessAnalysis.h:
* bytecode/BytecodeLivenessAnalysisInlines.h:
(JSC::isValidRegisterForLiveness):
(JSC::BytecodeLivenessPropagation::stepOverInstruction):
* bytecode/BytecodeRewriter.cpp:
(JSC::BytecodeRewriter::applyModification):
(JSC::BytecodeRewriter::execute):
(JSC::BytecodeRewriter::adjustJumpTargetsInFragment):
(JSC::BytecodeRewriter::insertImpl):
(JSC::BytecodeRewriter::adjustJumpTarget):
(JSC::BytecodeRewriter::adjustJumpTargets):
* bytecode/BytecodeRewriter.h:
(JSC::BytecodeRewriter::InsertionPoint::InsertionPoint):
(JSC::BytecodeRewriter::Fragment::Fragment):
(JSC::BytecodeRewriter::Fragment::appendInstruction):
(JSC::BytecodeRewriter::BytecodeRewriter):
(JSC::BytecodeRewriter::insertFragmentBefore):
(JSC::BytecodeRewriter::insertFragmentAfter):
(JSC::BytecodeRewriter::removeBytecode):
(JSC::BytecodeRewriter::adjustAbsoluteOffset):
(JSC::BytecodeRewriter::adjustJumpTarget):
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFromLLInt):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::estimatedSize):
(JSC::CodeBlock::visitChildren):
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::finalizeLLIntInlineCaches):
(JSC::CodeBlock::addJITAddIC):
(JSC::CodeBlock::addJITMulIC):
(JSC::CodeBlock::addJITSubIC):
(JSC::CodeBlock::addJITNegIC):
(JSC::CodeBlock::stronglyVisitStrongReferences):
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffset):
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
(JSC::CodeBlock::hasOpDebugForLineAndColumn):
(JSC::CodeBlock::getArrayProfile):
(JSC::CodeBlock::updateAllArrayPredictions):
(JSC::CodeBlock::predictedMachineCodeSize):
(JSC::CodeBlock::tryGetValueProfileForBytecodeOffset):
(JSC::CodeBlock::valueProfilePredictionForBytecodeOffset):
(JSC::CodeBlock::valueProfileForBytecodeOffset):
(JSC::CodeBlock::validate):
(JSC::CodeBlock::outOfLineJumpOffset):
(JSC::CodeBlock::outOfLineJumpTarget):
(JSC::CodeBlock::arithProfileForBytecodeOffset):
(JSC::CodeBlock::arithProfileForPC):
(JSC::CodeBlock::couldTakeSpecialFastCase):
(JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::addMathIC):
(JSC::CodeBlock::outOfLineJumpOffset):
(JSC::CodeBlock::bytecodeOffset):
(JSC::CodeBlock::instructions const):
(JSC::CodeBlock::instructionCount const):
(JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters):
(JSC::CodeBlock::metadata):
(JSC::CodeBlock::metadataSizeInBytes):
(JSC::CodeBlock::numberOfNonArgumentValueProfiles):
(JSC::CodeBlock::totalNumberOfValueProfiles):
* bytecode/CodeBlockInlines.h: Added.
(JSC::CodeBlock::forEachValueProfile):
(JSC::CodeBlock::forEachArrayProfile):
(JSC::CodeBlock::forEachArrayAllocationProfile):
(JSC::CodeBlock::forEachObjectAllocationProfile):
(JSC::CodeBlock::forEachLLIntCallLinkInfo):
* bytecode/Fits.h: Added.
* bytecode/GetByIdMetadata.h: Copied from Source/JavaScriptCore/bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h.
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFromLLInt):
* bytecode/Instruction.h:
(JSC::Instruction::Instruction):
(JSC::Instruction::Impl::opcodeID const):
(JSC::Instruction::opcodeID const):
(JSC::Instruction::name const):
(JSC::Instruction::isWide const):
(JSC::Instruction::size const):
(JSC::Instruction::is const):
(JSC::Instruction::as const):
(JSC::Instruction::cast):
(JSC::Instruction::cast const):
(JSC::Instruction::narrow const):
(JSC::Instruction::wide const):
* bytecode/InstructionStream.cpp: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
(JSC::InstructionStream::InstructionStream):
(JSC::InstructionStream::sizeInBytes const):
* bytecode/InstructionStream.h: Added.
(JSC::InstructionStream::BaseRef::BaseRef):
(JSC::InstructionStream::BaseRef::operator=):
(JSC::InstructionStream::BaseRef::operator-> const):
(JSC::InstructionStream::BaseRef::ptr const):
(JSC::InstructionStream::BaseRef::operator!= const):
(JSC::InstructionStream::BaseRef::next const):
(JSC::InstructionStream::BaseRef::offset const):
(JSC::InstructionStream::BaseRef::isValid const):
(JSC::InstructionStream::BaseRef::unwrap const):
(JSC::InstructionStream::MutableRef::freeze const):
(JSC::InstructionStream::MutableRef::operator->):
(JSC::InstructionStream::MutableRef::ptr):
(JSC::InstructionStream::MutableRef::operator Ref):
(JSC::InstructionStream::MutableRef::unwrap):
(JSC::InstructionStream::iterator::operator*):
(JSC::InstructionStream::iterator::operator++):
(JSC::InstructionStream::begin const):
(JSC::InstructionStream::end const):
(JSC::InstructionStream::at const):
(JSC::InstructionStream::size const):
(JSC::InstructionStreamWriter::InstructionStreamWriter):
(JSC::InstructionStreamWriter::ref):
(JSC::InstructionStreamWriter::seek):
(JSC::InstructionStreamWriter::position):
(JSC::InstructionStreamWriter::write):
(JSC::InstructionStreamWriter::rewind):
(JSC::InstructionStreamWriter::finalize):
(JSC::InstructionStreamWriter::swap):
(JSC::InstructionStreamWriter::iterator::operator*):
(JSC::InstructionStreamWriter::iterator::operator++):
(JSC::InstructionStreamWriter::begin):
(JSC::InstructionStreamWriter::end):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::clearLLIntGetByIdCache):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* bytecode/MetadataTable.cpp: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
(JSC::MetadataTable::MetadataTable):
(JSC::DeallocTable::withOpcodeType):
(JSC::MetadataTable::~MetadataTable):
(JSC::MetadataTable::sizeInBytes):
* bytecode/MetadataTable.h: Copied from Source/JavaScriptCore/runtime/Watchdog.h.
(JSC::MetadataTable::get):
(JSC::MetadataTable::forEach):
(JSC::MetadataTable::getImpl):
* bytecode/Opcode.cpp:
(JSC::metadataSize):
* bytecode/Opcode.h:
(JSC::padOpcodeName):
* bytecode/OpcodeInlines.h:
(JSC::isOpcodeShape):
(JSC::getOpcodeType):
* bytecode/OpcodeSize.h: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
* bytecode/PreciseJumpTargets.cpp:
(JSC::getJumpTargetsForInstruction):
(JSC::computePreciseJumpTargetsInternal):
(JSC::computePreciseJumpTargets):
(JSC::recomputePreciseJumpTargets):
(JSC::findJumpTargetsForInstruction):
* bytecode/PreciseJumpTargets.h:
* bytecode/PreciseJumpTargetsInlines.h:
(JSC::jumpTargetForInstruction):
(JSC::extractStoredJumpTargetsForInstruction):
(JSC::updateStoredJumpTargetsForInstruction):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
* bytecode/SpecialPointer.cpp:
(WTF::printInternal):
* bytecode/SpecialPointer.h:
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
(JSC::UnlinkedCodeBlock::visitChildren):
(JSC::UnlinkedCodeBlock::estimatedSize):
(JSC::UnlinkedCodeBlock::lineNumberForBytecodeOffset):
(JSC::dumpLineColumnEntry):
(JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset const):
(JSC::UnlinkedCodeBlock::setInstructions):
(JSC::UnlinkedCodeBlock::instructions const):
(JSC::UnlinkedCodeBlock::applyModification):
(JSC::UnlinkedCodeBlock::addOutOfLineJumpTarget):
(JSC::UnlinkedCodeBlock::outOfLineJumpOffset):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::addPropertyAccessInstruction):
(JSC::UnlinkedCodeBlock::propertyAccessInstructions const):
(JSC::UnlinkedCodeBlock::addOpProfileControlFlowBytecodeOffset):
(JSC::UnlinkedCodeBlock::opProfileControlFlowBytecodeOffsets const):
(JSC::UnlinkedCodeBlock::metadata):
(JSC::UnlinkedCodeBlock::metadataSizeInBytes):
(JSC::UnlinkedCodeBlock::outOfLineJumpOffset):
(JSC::UnlinkedCodeBlock::replaceOutOfLineJumpTargets):
* bytecode/UnlinkedInstructionStream.cpp: Removed.
* bytecode/UnlinkedInstructionStream.h: Removed.
* bytecode/UnlinkedMetadataTable.h: Copied from Source/JavaScriptCore/bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h.
* bytecode/UnlinkedMetadataTableInlines.h: Added.
(JSC::UnlinkedMetadataTable::UnlinkedMetadataTable):
(JSC::UnlinkedMetadataTable::~UnlinkedMetadataTable):
(JSC::UnlinkedMetadataTable::addEntry):
(JSC::UnlinkedMetadataTable::sizeInBytes):
(JSC::UnlinkedMetadataTable::finalize):
(JSC::UnlinkedMetadataTable::link):
(JSC::UnlinkedMetadataTable::unlink):
* bytecode/VirtualRegister.cpp:
(JSC::VirtualRegister::VirtualRegister):
* bytecode/VirtualRegister.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::Label::setLocation):
(JSC::Label::bind):
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeVarLexicalEnvironment):
(JSC::BytecodeGenerator::emitEnter):
(JSC::BytecodeGenerator::emitLoopHint):
(JSC::BytecodeGenerator::emitJump):
(JSC::BytecodeGenerator::emitCheckTraps):
(JSC::BytecodeGenerator::rewind):
(JSC::BytecodeGenerator::fuseCompareAndJump):
(JSC::BytecodeGenerator::fuseTestAndJmp):
(JSC::BytecodeGenerator::emitJumpIfTrue):
(JSC::BytecodeGenerator::emitJumpIfFalse):
(JSC::BytecodeGenerator::emitJumpIfNotFunctionCall):
(JSC::BytecodeGenerator::emitJumpIfNotFunctionApply):
(JSC::BytecodeGenerator::moveLinkTimeConstant):
(JSC::BytecodeGenerator::moveEmptyValue):
(JSC::BytecodeGenerator::emitMove):
(JSC::BytecodeGenerator::emitUnaryOp):
(JSC::BytecodeGenerator::emitBinaryOp):
(JSC::BytecodeGenerator::emitToObject):
(JSC::BytecodeGenerator::emitToNumber):
(JSC::BytecodeGenerator::emitToString):
(JSC::BytecodeGenerator::emitTypeOf):
(JSC::BytecodeGenerator::emitInc):
(JSC::BytecodeGenerator::emitDec):
(JSC::BytecodeGenerator::emitEqualityOp):
(JSC::BytecodeGenerator::emitProfileType):
(JSC::BytecodeGenerator::emitProfileControlFlow):
(JSC::BytecodeGenerator::pushLexicalScopeInternal):
(JSC::BytecodeGenerator::emitResolveScopeForHoistingFuncDeclInEval):
(JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
(JSC::BytecodeGenerator::emitOverridesHasInstance):
(JSC::BytecodeGenerator::emitResolveScope):
(JSC::BytecodeGenerator::emitGetFromScope):
(JSC::BytecodeGenerator::emitPutToScope):
(JSC::BytecodeGenerator::emitInstanceOf):
(JSC::BytecodeGenerator::emitInstanceOfCustom):
(JSC::BytecodeGenerator::emitInByVal):
(JSC::BytecodeGenerator::emitInById):
(JSC::BytecodeGenerator::emitTryGetById):
(JSC::BytecodeGenerator::emitGetById):
(JSC::BytecodeGenerator::emitDirectGetById):
(JSC::BytecodeGenerator::emitPutById):
(JSC::BytecodeGenerator::emitDirectPutById):
(JSC::BytecodeGenerator::emitPutGetterById):
(JSC::BytecodeGenerator::emitPutSetterById):
(JSC::BytecodeGenerator::emitPutGetterSetter):
(JSC::BytecodeGenerator::emitPutGetterByVal):
(JSC::BytecodeGenerator::emitPutSetterByVal):
(JSC::BytecodeGenerator::emitDeleteById):
(JSC::BytecodeGenerator::emitGetByVal):
(JSC::BytecodeGenerator::emitPutByVal):
(JSC::BytecodeGenerator::emitDirectPutByVal):
(JSC::BytecodeGenerator::emitDeleteByVal):
(JSC::BytecodeGenerator::emitSuperSamplerBegin):
(JSC::BytecodeGenerator::emitSuperSamplerEnd):
(JSC::BytecodeGenerator::emitIdWithProfile):
(JSC::BytecodeGenerator::emitUnreachable):
(JSC::BytecodeGenerator::emitGetArgument):
(JSC::BytecodeGenerator::emitCreateThis):
(JSC::BytecodeGenerator::emitTDZCheck):
(JSC::BytecodeGenerator::emitNewObject):
(JSC::BytecodeGenerator::emitNewArrayBuffer):
(JSC::BytecodeGenerator::emitNewArray):
(JSC::BytecodeGenerator::emitNewArrayWithSpread):
(JSC::BytecodeGenerator::emitNewArrayWithSize):
(JSC::BytecodeGenerator::emitNewRegExp):
(JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
(JSC::BytecodeGenerator::emitNewDefaultConstructor):
(JSC::BytecodeGenerator::emitNewFunction):
(JSC::BytecodeGenerator::emitSetFunctionNameIfNeeded):
(JSC::BytecodeGenerator::emitCall):
(JSC::BytecodeGenerator::emitCallInTailPosition):
(JSC::BytecodeGenerator::emitCallEval):
(JSC::BytecodeGenerator::emitExpectedFunctionSnippet):
(JSC::BytecodeGenerator::emitCallVarargs):
(JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
(JSC::BytecodeGenerator::emitConstructVarargs):
(JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition):
(JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary):
(JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary):
(JSC::BytecodeGenerator::emitCallDefineProperty):
(JSC::BytecodeGenerator::emitReturn):
(JSC::BytecodeGenerator::emitEnd):
(JSC::BytecodeGenerator::emitConstruct):
(JSC::BytecodeGenerator::emitStrcat):
(JSC::BytecodeGenerator::emitToPrimitive):
(JSC::BytecodeGenerator::emitGetScope):
(JSC::BytecodeGenerator::emitPushWithScope):
(JSC::BytecodeGenerator::emitGetParentScope):
(JSC::BytecodeGenerator::emitDebugHook):
(JSC::BytecodeGenerator::emitCatch):
(JSC::BytecodeGenerator::emitThrow):
(JSC::BytecodeGenerator::emitArgumentCount):
(JSC::BytecodeGenerator::emitThrowStaticError):
(JSC::BytecodeGenerator::beginSwitch):
(JSC::prepareJumpTableForSwitch):
(JSC::prepareJumpTableForStringSwitch):
(JSC::BytecodeGenerator::endSwitch):
(JSC::BytecodeGenerator::emitGetEnumerableLength):
(JSC::BytecodeGenerator::emitHasGenericProperty):
(JSC::BytecodeGenerator::emitHasIndexedProperty):
(JSC::BytecodeGenerator::emitHasStructureProperty):
(JSC::BytecodeGenerator::emitGetPropertyEnumerator):
(JSC::BytecodeGenerator::emitEnumeratorStructurePropertyName):
(JSC::BytecodeGenerator::emitEnumeratorGenericPropertyName):
(JSC::BytecodeGenerator::emitToIndexString):
(JSC::BytecodeGenerator::emitIsCellWithType):
(JSC::BytecodeGenerator::emitIsObject):
(JSC::BytecodeGenerator::emitIsNumber):
(JSC::BytecodeGenerator::emitIsUndefined):
(JSC::BytecodeGenerator::emitIsEmpty):
(JSC::BytecodeGenerator::emitRestParameter):
(JSC::BytecodeGenerator::emitRequireObjectCoercible):
(JSC::BytecodeGenerator::emitYieldPoint):
(JSC::BytecodeGenerator::emitYield):
(JSC::BytecodeGenerator::emitGetAsyncIterator):
(JSC::BytecodeGenerator::emitDelegateYield):
(JSC::BytecodeGenerator::emitFinallyCompletion):
(JSC::BytecodeGenerator::emitJumpIf):
(JSC::ForInContext::finalize):
(JSC::StructureForInContext::finalize):
(JSC::IndexedForInContext::finalize):
(JSC::StaticPropertyAnalysis::record):
(JSC::BytecodeGenerator::emitToThis):
* bytecompiler/BytecodeGenerator.h:
(JSC::StructureForInContext::addGetInst):
(JSC::BytecodeGenerator::recordOpcode):
(JSC::BytecodeGenerator::addMetadataFor):
(JSC::BytecodeGenerator::emitUnaryOp):
(JSC::BytecodeGenerator::kill):
(JSC::BytecodeGenerator::instructions const):
(JSC::BytecodeGenerator::write):
(JSC::BytecodeGenerator::withWriter):
* bytecompiler/Label.h:
(JSC::Label::Label):
(JSC::Label::bind):
* bytecompiler/NodesCodegen.cpp:
(JSC::ArrayNode::emitBytecode):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_argumentCount):
(JSC::ApplyFunctionCallDotNode::emitBytecode):
(JSC::BitwiseNotNode::emitBytecode):
(JSC::BinaryOpNode::emitBytecode):
(JSC::EqualNode::emitBytecode):
(JSC::StrictEqualNode::emitBytecode):
(JSC::emitReadModifyAssignment):
(JSC::ForInNode::emitBytecode):
(JSC::CaseBlockNode::emitBytecodeForBlock):
(JSC::FunctionNode::emitBytecode):
(JSC::ClassExprNode::emitBytecode):
* bytecompiler/ProfileTypeBytecodeFlag.cpp: Copied from Source/JavaScriptCore/bytecode/VirtualRegister.cpp.
(WTF::printInternal):
* bytecompiler/ProfileTypeBytecodeFlag.h: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
* bytecompiler/RegisterID.h:
* bytecompiler/StaticPropertyAnalysis.h:
(JSC::StaticPropertyAnalysis::create):
(JSC::StaticPropertyAnalysis::StaticPropertyAnalysis):
* bytecompiler/StaticPropertyAnalyzer.h:
(JSC::StaticPropertyAnalyzer::createThis):
(JSC::StaticPropertyAnalyzer::newObject):
(JSC::StaticPropertyAnalyzer::putById):
(JSC::StaticPropertyAnalyzer::mov):
(JSC::StaticPropertyAnalyzer::kill):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addCall):
(JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
(JSC::DFG::ByteCodeParser::getArrayMode):
(JSC::DFG::ByteCodeParser::handleCall):
(JSC::DFG::ByteCodeParser::handleVarargsCall):
(JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
(JSC::DFG::ByteCodeParser::inlineCall):
(JSC::DFG::ByteCodeParser::handleCallVariant):
(JSC::DFG::ByteCodeParser::handleVarargsInlining):
(JSC::DFG::ByteCodeParser::handleInlining):
(JSC::DFG::ByteCodeParser::handleMinMax):
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
(JSC::DFG::ByteCodeParser::handleDOMJITCall):
(JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
(JSC::DFG::ByteCodeParser::handleDOMJITGetter):
(JSC::DFG::ByteCodeParser::handleModuleNamespaceLoad):
(JSC::DFG::ByteCodeParser::handleTypedArrayConstructor):
(JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::handlePutById):
(JSC::DFG::ByteCodeParser::parseGetById):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::parseCodeBlock):
(JSC::DFG::ByteCodeParser::handlePutByVal):
(JSC::DFG::ByteCodeParser::handlePutAccessorById):
(JSC::DFG::ByteCodeParser::handlePutAccessorByVal):
(JSC::DFG::ByteCodeParser::handleNewFunc):
(JSC::DFG::ByteCodeParser::handleNewFuncExp):
(JSC::DFG::ByteCodeParser::parse):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGCapabilities.h:
(JSC::DFG::capabilityLevel):
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareCatchOSREntry):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueAdd):
(JSC::DFG::SpeculativeJIT::compileValueSub):
(JSC::DFG::SpeculativeJIT::compileValueNegate):
(JSC::DFG::SpeculativeJIT::compileArithMul):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
(JSC::FTL::DFG::LowerDFGToB3::compileValueSub):
(JSC::FTL::DFG::LowerDFGToB3::compileUnaryMathIC):
(JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC):
(JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
(JSC::FTL::DFG::LowerDFGToB3::compileArithMul):
(JSC::FTL::DFG::LowerDFGToB3::compileValueNegate):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
* generate-bytecode-files: Removed.
* generator/Argument.rb: Added.
* generator/Assertion.rb: Added.
* generator/DSL.rb: Added.
* generator/Fits.rb: Added.
* generator/GeneratedFile.rb: Added.
* generator/Metadata.rb: Added.
* generator/Opcode.rb: Added.
* generator/OpcodeGroup.rb: Added.
* generator/Options.rb: Added.
* generator/Section.rb: Added.
* generator/Template.rb: Added.
* generator/Type.rb: Added.
* generator/main.rb: Added.
* interpreter/AbstractPC.h:
* interpreter/CallFrame.cpp:
(JSC::CallFrame::currentVPC const):
(JSC::CallFrame::setCurrentVPC):
* interpreter/CallFrame.h:
(JSC::CallSiteIndex::CallSiteIndex):
(JSC::ExecState::setReturnPC):
* interpreter/Interpreter.cpp:
(WTF::printInternal):
* interpreter/Interpreter.h:
* interpreter/InterpreterInlines.h:
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::dump const):
* interpreter/VMEntryRecord.h:
* jit/JIT.cpp:
(JSC::JIT::JIT):
(JSC::JIT::emitSlowCaseCall):
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
(JSC::JIT::compileWithoutLinking):
(JSC::JIT::link):
* jit/JIT.h:
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_jless):
(JSC::JIT::emit_op_jlesseq):
(JSC::JIT::emit_op_jgreater):
(JSC::JIT::emit_op_jgreatereq):
(JSC::JIT::emit_op_jnless):
(JSC::JIT::emit_op_jnlesseq):
(JSC::JIT::emit_op_jngreater):
(JSC::JIT::emit_op_jngreatereq):
(JSC::JIT::emitSlow_op_jless):
(JSC::JIT::emitSlow_op_jlesseq):
(JSC::JIT::emitSlow_op_jgreater):
(JSC::JIT::emitSlow_op_jgreatereq):
(JSC::JIT::emitSlow_op_jnless):
(JSC::JIT::emitSlow_op_jnlesseq):
(JSC::JIT::emitSlow_op_jngreater):
(JSC::JIT::emitSlow_op_jngreatereq):
(JSC::JIT::emit_op_below):
(JSC::JIT::emit_op_beloweq):
(JSC::JIT::emit_op_jbelow):
(JSC::JIT::emit_op_jbeloweq):
(JSC::JIT::emit_op_unsigned):
(JSC::JIT::emit_compareAndJump):
(JSC::JIT::emit_compareUnsignedAndJump):
(JSC::JIT::emit_compareUnsigned):
(JSC::JIT::emit_compareAndJumpSlow):
(JSC::JIT::emit_op_inc):
(JSC::JIT::emit_op_dec):
(JSC::JIT::emit_op_mod):
(JSC::JIT::emitSlow_op_mod):
(JSC::JIT::emit_op_negate):
(JSC::JIT::emitSlow_op_negate):
(JSC::JIT::emitBitBinaryOpFastPath):
(JSC::JIT::emit_op_bitand):
(JSC::JIT::emit_op_bitor):
(JSC::JIT::emit_op_bitxor):
(JSC::JIT::emit_op_lshift):
(JSC::JIT::emitRightShiftFastPath):
(JSC::JIT::emit_op_rshift):
(JSC::JIT::emit_op_urshift):
(JSC::getOperandTypes):
(JSC::JIT::emit_op_add):
(JSC::JIT::emitSlow_op_add):
(JSC::JIT::emitMathICFast):
(JSC::JIT::emitMathICSlow):
(JSC::JIT::emit_op_div):
(JSC::JIT::emit_op_mul):
(JSC::JIT::emitSlow_op_mul):
(JSC::JIT::emit_op_sub):
(JSC::JIT::emitSlow_op_sub):
* jit/JITCall.cpp:
(JSC::JIT::emitPutCallResult):
(JSC::JIT::compileSetupFrame):
(JSC::JIT::compileCallEval):
(JSC::JIT::compileCallEvalSlowCase):
(JSC::JIT::compileTailCall):
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
(JSC::JIT::emit_op_call):
(JSC::JIT::emit_op_tail_call):
(JSC::JIT::emit_op_call_eval):
(JSC::JIT::emit_op_call_varargs):
(JSC::JIT::emit_op_tail_call_varargs):
(JSC::JIT::emit_op_tail_call_forward_arguments):
(JSC::JIT::emit_op_construct_varargs):
(JSC::JIT::emit_op_construct):
(JSC::JIT::emitSlow_op_call):
(JSC::JIT::emitSlow_op_tail_call):
(JSC::JIT::emitSlow_op_call_eval):
(JSC::JIT::emitSlow_op_call_varargs):
(JSC::JIT::emitSlow_op_tail_call_varargs):
(JSC::JIT::emitSlow_op_tail_call_forward_arguments):
(JSC::JIT::emitSlow_op_construct_varargs):
(JSC::JIT::emitSlow_op_construct):
* jit/JITDisassembler.cpp:
(JSC::JITDisassembler::JITDisassembler):
* jit/JITExceptions.cpp:
(JSC::genericUnwind):
* jit/JITInlines.h:
(JSC::JIT::emitDoubleGetByVal):
(JSC::JIT::emitLoadForArrayMode):
(JSC::JIT::emitContiguousGetByVal):
(JSC::JIT::emitArrayStorageGetByVal):
(JSC::JIT::appendCallWithExceptionCheckSetJSValueResultWithProfile):
(JSC::JIT::sampleInstruction):
(JSC::JIT::emitValueProfilingSiteIfProfiledOpcode):
(JSC::JIT::emitValueProfilingSite):
(JSC::JIT::jumpTarget):
(JSC::JIT::copiedGetPutInfo):
(JSC::JIT::copiedArithProfile):
* jit/JITMathIC.h:
(JSC::isProfileEmpty):
(JSC::JITBinaryMathIC::JITBinaryMathIC):
(JSC::JITUnaryMathIC::JITUnaryMathIC):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_mov):
(JSC::JIT::emit_op_end):
(JSC::JIT::emit_op_jmp):
(JSC::JIT::emit_op_new_object):
(JSC::JIT::emitSlow_op_new_object):
(JSC::JIT::emit_op_overrides_has_instance):
(JSC::JIT::emit_op_instanceof):
(JSC::JIT::emitSlow_op_instanceof):
(JSC::JIT::emit_op_instanceof_custom):
(JSC::JIT::emit_op_is_empty):
(JSC::JIT::emit_op_is_undefined):
(JSC::JIT::emit_op_is_boolean):
(JSC::JIT::emit_op_is_number):
(JSC::JIT::emit_op_is_cell_with_type):
(JSC::JIT::emit_op_is_object):
(JSC::JIT::emit_op_ret):
(JSC::JIT::emit_op_to_primitive):
(JSC::JIT::emit_op_set_function_name):
(JSC::JIT::emit_op_not):
(JSC::JIT::emit_op_jfalse):
(JSC::JIT::emit_op_jeq_null):
(JSC::JIT::emit_op_jneq_null):
(JSC::JIT::emit_op_jneq_ptr):
(JSC::JIT::emit_op_eq):
(JSC::JIT::emit_op_jeq):
(JSC::JIT::emit_op_jtrue):
(JSC::JIT::emit_op_neq):
(JSC::JIT::emit_op_jneq):
(JSC::JIT::emit_op_throw):
(JSC::JIT::compileOpStrictEq):
(JSC::JIT::emit_op_stricteq):
(JSC::JIT::emit_op_nstricteq):
(JSC::JIT::compileOpStrictEqJump):
(JSC::JIT::emit_op_jstricteq):
(JSC::JIT::emit_op_jnstricteq):
(JSC::JIT::emitSlow_op_jstricteq):
(JSC::JIT::emitSlow_op_jnstricteq):
(JSC::JIT::emit_op_to_number):
(JSC::JIT::emit_op_to_string):
(JSC::JIT::emit_op_to_object):
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_identity_with_profile):
(JSC::JIT::emit_op_get_parent_scope):
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emit_op_switch_char):
(JSC::JIT::emit_op_switch_string):
(JSC::JIT::emit_op_debug):
(JSC::JIT::emit_op_eq_null):
(JSC::JIT::emit_op_neq_null):
(JSC::JIT::emit_op_enter):
(JSC::JIT::emit_op_get_scope):
(JSC::JIT::emit_op_to_this):
(JSC::JIT::emit_op_create_this):
(JSC::JIT::emit_op_check_tdz):
(JSC::JIT::emitSlow_op_eq):
(JSC::JIT::emitSlow_op_neq):
(JSC::JIT::emitSlow_op_jeq):
(JSC::JIT::emitSlow_op_jneq):
(JSC::JIT::emitSlow_op_instanceof_custom):
(JSC::JIT::emit_op_loop_hint):
(JSC::JIT::emitSlow_op_loop_hint):
(JSC::JIT::emit_op_check_traps):
(JSC::JIT::emit_op_nop):
(JSC::JIT::emit_op_super_sampler_begin):
(JSC::JIT::emit_op_super_sampler_end):
(JSC::JIT::emitSlow_op_check_traps):
(JSC::JIT::emit_op_new_regexp):
(JSC::JIT::emitNewFuncCommon):
(JSC::JIT::emit_op_new_func):
(JSC::JIT::emit_op_new_generator_func):
(JSC::JIT::emit_op_new_async_generator_func):
(JSC::JIT::emit_op_new_async_func):
(JSC::JIT::emitNewFuncExprCommon):
(JSC::JIT::emit_op_new_func_exp):
(JSC::JIT::emit_op_new_generator_func_exp):
(JSC::JIT::emit_op_new_async_func_exp):
(JSC::JIT::emit_op_new_async_generator_func_exp):
(JSC::JIT::emit_op_new_array):
(JSC::JIT::emit_op_new_array_with_size):
(JSC::JIT::emit_op_has_structure_property):
(JSC::JIT::privateCompileHasIndexedProperty):
(JSC::JIT::emit_op_has_indexed_property):
(JSC::JIT::emitSlow_op_has_indexed_property):
(JSC::JIT::emit_op_get_direct_pname):
(JSC::JIT::emit_op_enumerator_structure_pname):
(JSC::JIT::emit_op_enumerator_generic_pname):
(JSC::JIT::emit_op_profile_type):
(JSC::JIT::emit_op_log_shadow_chicken_prologue):
(JSC::JIT::emit_op_log_shadow_chicken_tail):
(JSC::JIT::emit_op_profile_control_flow):
(JSC::JIT::emit_op_argument_count):
(JSC::JIT::emit_op_get_rest_length):
(JSC::JIT::emit_op_get_argument):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_to_this):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emitGetByValWithCachedId):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emit_op_put_by_val_direct):
(JSC::JIT::emit_op_put_by_val):
(JSC::JIT::emitGenericContiguousPutByVal):
(JSC::JIT::emitArrayStoragePutByVal):
(JSC::JIT::emitPutByValWithCachedId):
(JSC::JIT::emitSlow_op_put_by_val):
(JSC::JIT::emit_op_put_getter_by_id):
(JSC::JIT::emit_op_put_setter_by_id):
(JSC::JIT::emit_op_put_getter_setter_by_id):
(JSC::JIT::emit_op_put_getter_by_val):
(JSC::JIT::emit_op_put_setter_by_val):
(JSC::JIT::emit_op_del_by_id):
(JSC::JIT::emit_op_del_by_val):
(JSC::JIT::emit_op_try_get_by_id):
(JSC::JIT::emitSlow_op_try_get_by_id):
(JSC::JIT::emit_op_get_by_id_direct):
(JSC::JIT::emitSlow_op_get_by_id_direct):
(JSC::JIT::emit_op_get_by_id):
(JSC::JIT::emit_op_get_by_id_with_this):
(JSC::JIT::emitSlow_op_get_by_id):
(JSC::JIT::emitSlow_op_get_by_id_with_this):
(JSC::JIT::emit_op_put_by_id):
(JSC::JIT::emitSlow_op_put_by_id):
(JSC::JIT::emit_op_in_by_id):
(JSC::JIT::emitSlow_op_in_by_id):
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emitSlow_op_get_from_scope):
(JSC::JIT::emit_op_put_to_scope):
(JSC::JIT::emitSlow_op_put_to_scope):
(JSC::JIT::emit_op_get_from_arguments):
(JSC::JIT::emit_op_put_to_arguments):
(JSC::JIT::privateCompileGetByVal):
(JSC::JIT::privateCompileGetByValWithCachedId):
(JSC::JIT::privateCompilePutByVal):
(JSC::JIT::privateCompilePutByValWithCachedId):
(JSC::JIT::emitDoubleLoad):
(JSC::JIT::emitContiguousLoad):
(JSC::JIT::emitArrayStorageLoad):
(JSC::JIT::emitDirectArgumentsGetByVal):
(JSC::JIT::emitScopedArgumentsGetByVal):
(JSC::JIT::emitIntTypedArrayGetByVal):
(JSC::JIT::emitFloatTypedArrayGetByVal):
(JSC::JIT::emitIntTypedArrayPutByVal):
(JSC::JIT::emitFloatTypedArrayPutByVal):
* jit/RegisterSet.cpp:
(JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
* jit/SlowPathCall.h:
(JSC::JITSlowPathCall::JITSlowPathCall):
* llint/LLIntData.cpp:
(JSC::LLInt::initialize):
(JSC::LLInt::Data::performAssertions):
* llint/LLIntData.h:
(JSC::LLInt::exceptionInstructions):
(JSC::LLInt::opcodeMap):
(JSC::LLInt::opcodeMapWide):
(JSC::LLInt::getOpcode):
(JSC::LLInt::getOpcodeWide):
(JSC::LLInt::getWideCodePtr):
* llint/LLIntOffsetsExtractor.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::llint_trace_operand):
(JSC::LLInt::llint_trace_value):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::entryOSR):
(JSC::LLInt::setupGetByIdPrototypeCache):
(JSC::LLInt::getByVal):
(JSC::LLInt::handleHostCall):
(JSC::LLInt::setUpCall):
(JSC::LLInt::genericCall):
(JSC::LLInt::varargsSetup):
(JSC::LLInt::commonCallEval):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter.cpp:
(JSC::CLoopRegister::operator const Instruction*):
(JSC::CLoop::execute):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* offlineasm/arm64.rb:
* offlineasm/asm.rb:
* offlineasm/ast.rb:
* offlineasm/cloop.rb:
* offlineasm/generate_offset_extractor.rb:
* offlineasm/instructions.rb:
* offlineasm/offsets.rb:
* offlineasm/parser.rb:
* offlineasm/transform.rb:
* offlineasm/x86.rb:
* parser/ResultType.h:
(JSC::ResultType::dump const):
(JSC::OperandTypes::first const):
(JSC::OperandTypes::second const):
(JSC::OperandTypes::dump const):
* profiler/ProfilerBytecodeSequence.cpp:
(JSC::Profiler::BytecodeSequence::BytecodeSequence):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
(JSC::updateArithProfileForUnaryArithOp):
(JSC::updateArithProfileForBinaryArithOp):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
(JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
* runtime/ExceptionFuzz.cpp:
(JSC::doExceptionFuzzing):
* runtime/ExceptionFuzz.h:
(JSC::doExceptionFuzzingIfEnabled):
* runtime/GetPutInfo.cpp: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
(JSC::GetPutInfo::dump const):
(WTF::printInternal):
* runtime/GetPutInfo.h:
(JSC::GetPutInfo::operand const):
* runtime/JSCPoison.h:
* runtime/JSType.cpp: Added.
(WTF::printInternal):
* runtime/JSType.h:
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::StackFrame::displayName):
* runtime/SamplingProfiler.h:
(JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame):
* runtime/SlowPathReturnType.h:
(JSC::encodeResult):
(JSC::decodeResult):
* runtime/VM.h:
* runtime/Watchdog.h:
* tools/HeapVerifier.cpp:
2018-10-26 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r237445.
https://bugs.webkit.org/show_bug.cgi?id=190972
Cause performance regression on iOS devices (Requested by
yusukesuzuki on #webkit).
Reverted changeset:
"Unreviewed, partial rolling in r237254"
https://bugs.webkit.org/show_bug.cgi?id=190340
https://trac.webkit.org/changeset/237445
2018-10-26 Mark Lam <mark.lam@apple.com>
Fix missing edge cases with JSGlobalObjects having a bad time.
https://bugs.webkit.org/show_bug.cgi?id=189028
<rdar://problem/45204939>
Reviewed by Saam Barati.
Consider the following scenario:
let object O1 (of global G1) have an indexing type that is not SlowPut.
let global G2 have a bad time.
let object O2 (of global G2) be set as the prototype of O1.
let object O3 (of global G2) have indexed accessors.
In the existing code, if we set O3 as O2's prototype, we'll have a bug where
O1 will not be made aware that that there are indexed accessors in its prototype
chain.
In this patch, we solve this issue by introducing a new invariant:
A prototype chain is considered to possibly have indexed accessors if any
object in the chain belongs to a global object that is having a bad time.
We apply this invariant as follows:
1. Enhance JSGlobalObject::haveABadTime() to also check if other global objects are
affected by it having a bad time. If so, it also ensures that those affected
global objects have a bad time.
The original code for JSGlobalObject::haveABadTime() uses a ObjectsWithBrokenIndexingFinder
to find all objects affected by the global object having a bad time. We enhance
ObjectsWithBrokenIndexingFinder to also check for the possibility that any global
objects may be affected by other global objects having a bad time i.e.
let g1 = global1
let g2 = global2
let o1 = an object in g1
let o2 = an object in g2
let g1 have a bad time
g2 is affected if
o1 is in the prototype chain of o2,
and o2 may be a prototype.
If the ObjectsWithBrokenIndexingFinder does find the possibility of other global
objects being affected, it will abort its heap scan and let haveABadTime() take
a slow path to do a more complete multi global object scan.
The slow path works as follows:
1. Iterate the heap and record the graph of all global object dependencies.
For each global object, record the list of other global objects that are
affected by it.
2. Compute a list of global objects that need to have a bad time using the
current global object dependency graph.
3. For each global object in the list of affected global objects, fire their
HaveABadTime watchpoint and convert all their array structures to the
SlowPut alternatives.
4. Re-run ObjectsWithBrokenIndexingFinder to find all objects that are affected
by any of the globals in the list from (2).
2. Enhance Structure::mayInterceptIndexedAccesses() to also return true if the
structure's global object is having a bad time.
Note: there are 3 scenarios that we need to consider:
let g1 = global1
let g2 = global2
let o1 = an object in g1
let o2 = an object in g2
Scenario 1: o2 is a prototype, and
g1 has a bad time after o1 is inserted into the o2's prototype chain.
Scenario 2: o2 is a prototype, and
o1 is inserted into the o2's prototype chain after g1 has a bad time.
Scenario 3: o2 is NOT a prototype, and
o1 is inserted into the o2's prototype chain after g1 has a bad time.
For scenario 1, when g1 has a bad time, we need to also make sure g2 has
a bad time. This is handled by enhancement 1 above.
For scenario 2, when o1 is inserted into o2's prototype chain, we need to check
if o1's global object has a bad time. If so, then we need to make sure o2's
global also has a bad time (because o2 is a prototype) and convert o2's
storage type to SlowPut. This is handled by enhancement 2 above in conjunction
with JSObject::setPrototypeDirect().
For scenario 3, when o1 is inserted into o2's prototype chain, we need to check
if o1's global object has a bad time. If so, then we only need to convert o2's
storage type to SlowPut (because o2 is NOT a prototype). This is handled by
enhancement 2 above.
3. Also add $vm.isHavingABadTime(), $vm.createGlobalObject() to enable us to
write some tests for this issue.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::fireWatchpointAndMakeAllArrayStructuresSlowPut):
(JSC::JSGlobalObject::haveABadTime):
* runtime/JSGlobalObject.h:
* runtime/JSObject.h:
(JSC::JSObject::mayInterceptIndexedAccesses): Deleted.
* runtime/JSObjectInlines.h:
(JSC::JSObject::mayInterceptIndexedAccesses):
* runtime/Structure.h:
* runtime/StructureInlines.h:
(JSC::Structure::mayInterceptIndexedAccesses const):
* tools/JSDollarVM.cpp:
(JSC::functionHaveABadTime):
(JSC::functionIsHavingABadTime):
(JSC::functionCreateGlobalObject):
(JSC::JSDollarVM::finishCreation):
2018-10-26 Keith Miller <keith_miller@apple.com>
JSC xcconfig should set DEFINES_MODULE
https://bugs.webkit.org/show_bug.cgi?id=190952
Reviewed by Mark Lam.
This should mean that the JavaScriptCore.framework will have a module map.
* Configurations/JavaScriptCore.xcconfig:
2018-10-25 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] havingABadTimeWatchpoint is not required in Array#indexOf optimization
https://bugs.webkit.org/show_bug.cgi?id=190941
Reviewed by Saam Barati.
While "Rest" operation fast path requires havingABadTimeWatchpoint since it allocates
JSArray, Array#{indexOf,lastIndexOf} do not require it when we use the fast path for them.
This patch removes watching on havingABadTimeWatchpoint in Array#indexOf. The test causing
"havingABadTime" is already included in our test suites (e.g. array-indexof-have-a-bad-time.js).
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* runtime/JSArrayInlines.h:
(JSC::JSArray::canDoFastIndexedAccess):
* runtime/JSGlobalObject.h:
* runtime/JSGlobalObjectInlines.h:
(JSC::JSGlobalObject::isArrayPrototypeIteratorProtocolFastAndNonObservable):
(JSC::JSGlobalObject::isArrayPrototypeIndexedAccessFastAndNonObservable): Deleted.
2018-10-25 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Unreviewed, partial rolling in r237254
https://bugs.webkit.org/show_bug.cgi?id=190340
We do not use the added function right now to investigate what is the reason of the regression.
If it causes the regression, it seems that Parser.cpp's inlining decision seems culprit.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
* bytecode/UnlinkedFunctionExecutable.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseSingleFunction):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
(JSC::parse):
(JSC::parseFunctionForFunctionConstructor):
* parser/ParserModes.h:
* parser/ParserTokens.h:
(JSC::JSTextPosition::JSTextPosition):
(JSC::JSTokenLocation::JSTokenLocation): Deleted.
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::SourceCodeKey):
(JSC::SourceCodeKey::operator== const):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
* runtime/CodeCache.h:
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/FunctionExecutable.h:
2018-10-25 Brent Fulgham <bfulgham@apple.com>
Unreviewed build fix for Visual Studio 2017
* API/tests/testapi.c:
(testMarkingConstraintsAndHeapFinalizers):
(main):
2018-10-25 Devin Rousso <drousso@apple.com>
Web Inspector: display fullscreen enter/exit events in Timelines and Network node waterfalls
https://bugs.webkit.org/show_bug.cgi?id=189874
<rdar://problem/44700000>
Reviewed by Joseph Pecoraro.
* inspector/protocol/DOM.json:
Allow `data` to be passed to the frontend with `didFireEvent`.
2018-10-25 Ross Kirsling <ross.kirsling@sony.com>
Cleanup: inline constexpr is redundant as constexpr implies inline
https://bugs.webkit.org/show_bug.cgi?id=190819
Reviewed by Mark Lam.
* bytecode/ArrayProfile.h:
(JSC::asArrayModes):
* runtime/IndexingType.h:
(JSC::isCopyOnWrite):
* runtime/MathCommon.h:
(JSC::maxSafeInteger):
(JSC::minSafeInteger):
* runtime/StackAlignment.h:
(JSC::stackAlignmentBytes):
(JSC::stackAlignmentRegisters):
2018-10-24 Megan Gardner <megan_gardner@apple.com>
Turn on Conic Gradients
https://bugs.webkit.org/show_bug.cgi?id=190810
Reviewed by Tim Horton.
* Configurations/FeatureDefines.xcconfig:
2018-10-24 Michael Saboff <msaboff@apple.com>
Increase executable memory pool from 64MB to 128MB for ARM64
https://bugs.webkit.org/show_bug.cgi?id=190453
Unreviewed, rolling back in r237024.
The original change did impact ARES-6 performance by 4-8%. That will
be investigated separately.
2018-10-22 Keith Rollin <krollin@apple.com>
Use Location = "Relative to Build Products" rather than "Relative to Group"
https://bugs.webkit.org/show_bug.cgi?id=190781
Reviewed by Alexey Proskuryakov.
Almost all Derived Files are included in Xcode projects with the
Location attribute set to "Relative to Group". While this currently
works, the Derived Files can no longer be found when enabling XCBuild
(which has stricter requirements). Fix this by setting the Location
attribute to "Relative to Build Products".
* JavaScriptCore.xcodeproj/project.pbxproj:
2018-10-22 Mark Lam <mark.lam@apple.com>
DFGAbstractValue::m_arrayModes expects IndexingMode values, not IndexingType.
https://bugs.webkit.org/show_bug.cgi?id=190515
<rdar://problem/45222379>
Reviewed by Saam Barati.
1. Fixes calls to asArrayModes() to take a structure's IndexingMode instead of
IndexingType.
2. DFG's compileNewArrayBuffer()'s HaveABadTime case was previously using the
node's indexingType (instead of indexingMode) to choose the array structure
to use for creating an array buffer with. This turns out to not be an issue
because when the VM is in having a bad time, all the
arrayStructureForIndexingTypeDuringAllocation structure pointers will point to
the SlowPutArrayStorage structure anyway. However, to be strictly correct,
we'll fix it to use the structure for the node's indexingMode.
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::set):
(JSC::DFG::AbstractValue::mergeOSREntryValue):
* dfg/DFGAbstractValue.h:
(JSC::DFG::AbstractValue::validate const):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::executeOSRExit):
* dfg/DFGRegisteredStructureSet.cpp:
(JSC::DFG::RegisteredStructureSet::arrayModesFromStructures const):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewArrayBuffer):
2018-10-19 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r237254.
https://bugs.webkit.org/show_bug.cgi?id=190760
"It regresses JetStream 2 by 5% on some iOS devices"
(Requested by saamyjoon on #webkit).
Reverted changeset:
"[JSC] JSC should have "parseFunction" to optimize Function
constructor"
https://bugs.webkit.org/show_bug.cgi?id=190340
https://trac.webkit.org/changeset/237254
2018-10-19 Saam Barati <sbarati@apple.com>
vmCall should check if we exit before emitting an OSR exit due to exceptions
https://bugs.webkit.org/show_bug.cgi?id=190740
<rdar://problem/45220139>
Reviewed by Mark Lam.
The bug we were seeing is the MovHint removal phase would
eliminate a superfluous MovHint. This left a certain range
of nodes in a state where they would not be able to reconstruct
values for an OSR exit. This is OK, since this phase proved those
nodes don't exit. However, some of these nodes may use the vmCall
construct in FTLLower. vmCall used to unconditionally emit an
exception check after each call. However, if such a call happens
in the range of nodes where we can't exit, we would end up generating
an invalid exit (and running with validateFTLOSRExitLiveness flag
would find this issue).
This patch makes vmCall check to see if the node can exit before
emitting an exception check. A node not being able to exit implies
that it can't exit for exceptions, therefore, by definition, it can't
throw an exception.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::vmCall):
2018-10-19 Caio Lima <ticaiolima@gmail.com>
[ESNext][BigInt] Implement support for "^"
https://bugs.webkit.org/show_bug.cgi?id=186235
Reviewed by Yusuke Suzuki.
This patch is introducing support for BigInt into bitwise xor
operation. We are including only support into LLInt and Baseline.
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::bitwiseXor):
(JSC::JSBigInt::absoluteXor):
* runtime/JSBigInt.h:
2018-10-19 Caio Lima <ticaiolima@gmail.com>
[BigInt] Add ValueSub into DFG
https://bugs.webkit.org/show_bug.cgi?id=186176
Reviewed by Yusuke Suzuki.
We are introducing in this patch a new node called ValueSub. This node
is necessary due to introduction of BigInt, making subtraction
operations result in non-Number values in some cases. In such case, ValueSub is
responsible to handle Untyped and BigInt operations.
In addition, we are also creating a speculative path when both
operands are BigInt. According to a simple BigInt subtraction microbenchmark,
this represents a speedup of ~1.2x faster.
big-int-simple-sub 14.6427+-0.5652 ^ 11.9559+-0.6485 ^ definitely 1.2247x faster
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::addSpeculationMode):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueSub):
(JSC::DFG::SpeculativeJIT::compileArithSub):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGValidate.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
(JSC::FTL::DFG::LowerDFGToB3::compileValueSub):
2018-10-18 Alexey Proskuryakov <ap@apple.com>
Switch from PLATFORM(IOS) to PLATFORM(IOS_FAMILY)
https://bugs.webkit.org/show_bug.cgi?id=190729
Reviewed by Tim Horton.
* API/JSBase.cpp:
* API/JSWrapperMap.mm:
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::cacheFlush):
* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::cacheFlush):
* assembler/AssemblerCommon.h:
(JSC::isIOS):
* heap/FullGCActivityCallback.cpp:
(JSC::FullGCActivityCallback::doCollection):
* heap/Heap.cpp:
(JSC::Heap::overCriticalMemoryThreshold):
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::collectIfNecessaryOrDefer):
* heap/Heap.h:
* inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
(Inspector::RemoteConnectionToTarget::dispatchAsyncOnTarget):
* jit/ExecutableAllocator.cpp:
(JSC::allowJIT):
* jit/ExecutableAllocator.h:
* jit/RegisterSet.cpp:
(JSC::RegisterSet::reservedHardwareRegisters):
(JSC::RegisterSet::calleeSaveRegisters):
* jit/ThunkGenerators.cpp:
* jsc.cpp:
(main):
* runtime/MathCommon.cpp:
* runtime/Options.cpp:
(JSC::overrideDefaults):
(JSC::recomputeDependentOptions):
* runtime/Options.h:
2018-10-18 Ross Kirsling <ross.kirsling@sony.com>
delete expression should not throw without a reference
https://bugs.webkit.org/show_bug.cgi?id=190637
Reviewed by Yusuke Suzuki.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseUnaryExpression):
Eliminate non-spec-compliant switch case.
2018-10-18 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] JSC should have "parseFunction" to optimize Function constructor
https://bugs.webkit.org/show_bug.cgi?id=190340
Reviewed by Mark Lam.
The current Function constructor is suboptimal. We parse the piece of the same code three times to meet
the spec requirement. (1) check parameters syntax, (2) check body syntax, and (3) parse the entire function.
And to parse 1-3 correctly, we create two strings, the parameters and the entire function. This operation
is really costly and ideally we should meet the above requirement by the one time parsing.
To meet the above requirement, we add a special function for Parser, parseSingleFunction. This function
takes `std::optional<int> functionConstructorParametersEndPosition` and check this end position is correct in the parser.
For example, if we run the code,
Function('/*', '*/){')
According to the spec, this should produce '/*' parameter string and '*/){' body string. And parameter
string should be syntax-checked by the parser, and raise the error since it is incorrect. Instead of doing
that, in our implementation, we first create the entire string.
function anonymous(/*) {
*/){
}
And we parse it. At that time, we also pass the end position of the parameters to the parser. In the above case,
the position of the `function anonymous(/*)' <> is passed. And in the parser, we check that the last token
offset of the parameters is the given end position. This check allows us to raise the error correctly to the
above example while we parse the entire function only once. And we do not need to create two strings too.
This improves the performance of the Function constructor significantly. And web-tooling-benchmark/uglify-js is
significantly sped up (28.2%).
Before:
uglify-js: 2.94 runs/s
After:
uglify-js: 3.77 runs/s
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
* bytecode/UnlinkedFunctionExecutable.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseSingleFunction):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
(JSC::parse):
(JSC::parseFunctionForFunctionConstructor):
* parser/ParserModes.h:
* parser/ParserTokens.h:
(JSC::JSTextPosition::JSTextPosition):
(JSC::JSTokenLocation::JSTokenLocation): Deleted.
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::SourceCodeKey):
(JSC::SourceCodeKey::operator== const):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
* runtime/CodeCache.h:
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/FunctionExecutable.h:
2018-10-18 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r237242.
https://bugs.webkit.org/show_bug.cgi?id=190701
it breaks "stress/sampling-profiler-basic.js" (Requested by
caiolima on #webkit).
Reverted changeset:
"[BigInt] Add ValueSub into DFG"
https://bugs.webkit.org/show_bug.cgi?id=186176
https://trac.webkit.org/changeset/237242
2018-10-18 Takafumi Kubota <takafumi.kubota1012@sslab.ics.keio.ac.jp>
Missing #pragma once in WasmOpcodeOrigin.h
https://bugs.webkit.org/show_bug.cgi?id=190699
Reviewed by Yusuke Suzuki.
This patch add ''#pragma once'' into WasmOpcodeOrigin.h to avoid the
multiple inclusion that can happen in the unified build
configuration.
* wasm/WasmOpcodeOrigin.h:
2018-10-17 Wenson Hsieh <wenson_hsieh@apple.com>
Enable the datalist element by default on iOS and macOS
https://bugs.webkit.org/show_bug.cgi?id=190594
<rdar://problem/45281159>
Reviewed by Ryosuke Niwa and Tim Horton.
* Configurations/FeatureDefines.xcconfig:
2018-10-17 Caio Lima <ticaiolima@gmail.com>
[BigInt] Add ValueSub into DFG
https://bugs.webkit.org/show_bug.cgi?id=186176
Reviewed by Yusuke Suzuki.
We are introducing in this patch a new node called ValueSub. This node
is necessary due to introduction of BigInt, making subtraction
operations result in non-Number values in some cases. In such case, ValueSub is
responsible to handle Untyped and BigInt operations.
In addition, we are also creating a speculative path when both
operands are BigInt. According to a simple BigInt subtraction microbenchmark,
this represents a speedup of ~1.2x faster.
big-int-simple-sub 14.6427+-0.5652 ^ 11.9559+-0.6485 ^ definitely 1.2247x faster
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::addSpeculationMode):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueSub):
(JSC::DFG::SpeculativeJIT::compileArithSub):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGValidate.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
(JSC::FTL::DFG::LowerDFGToB3::compileValueSub):
2018-10-17 Mark Lam <mark.lam@apple.com>
The parser should not emit a ApplyFunctionCallDotNode for Reflect.apply.
https://bugs.webkit.org/show_bug.cgi?id=190671
<rdar://problem/45201145>
Reviewed by Saam Barati.
The bytecode generator does not currently know how to inline Reflect.apply (see
https://bugs.webkit.org/show_bug.cgi?id=190668). Hence, it's a waste of time to
emit the ApplyFunctionCallDotNode since the function check against Function.apply
that it will generate will always fail.
Also fixed CallVariant::dump() to be able to handle dumping a non-executable
callee. Reflect.apply used to trip this up. Any object with an apply property
invoked as a function could also trip this up. This is now fixed.
* bytecode/CallVariant.cpp:
(JSC::CallVariant::dump const):
* bytecompiler/NodesCodegen.cpp:
(JSC::ApplyFunctionCallDotNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::makeFunctionCallNode):
2018-10-17 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r237024.
https://bugs.webkit.org/show_bug.cgi?id=190673
"It regressed ARES6 on iOS devices by 4-8%" (Requested by
saamyjoon on #webkit).
Reverted changeset:
"Increase executable memory pool from 64MB to 128MB for ARM64"
https://bugs.webkit.org/show_bug.cgi?id=190453
https://trac.webkit.org/changeset/237024
2018-10-17 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Use WTF::Function instead of std::function
https://bugs.webkit.org/show_bug.cgi?id=190665
Reviewed by Keith Miller.
We should use WTF::Function as much as possible. It allocates memory from bmalloc instead of standard malloc.
* runtime/JSNativeStdFunction.h:
2018-10-17 Keith Miller <keith_miller@apple.com>
Remove debug logging from generate_offsets_extractor.rb
https://bugs.webkit.org/show_bug.cgi?id=190667
Reviewed by Mark Lam.
* offlineasm/generate_offset_extractor.rb:
2018-10-17 Keith Miller <keith_miller@apple.com>
AI does not clear Phantom allocation nodes.
https://bugs.webkit.org/show_bug.cgi?id=190694
Reviewed by Saam Barati.
Phantom nodes claim to have a result so they should make sure they clear
their abstract values.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2018-10-17 Keith Miller <keith_miller@apple.com>
Unreviewed, fix windows build.
* offlineasm/generate_offset_extractor.rb:
2018-10-17 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] More aggressively use `constexpr` in LowLevelInterpreter.asm for constant values
https://bugs.webkit.org/show_bug.cgi?id=190659
Reviewed by Keith Miller.
Asking the actual constant value to the JSC binary is always the best way to get the correct value.
The value is correctly updated once the original value is changed. We would like to encourage this
approach more in LowLevelInterpreter.asm.
This patch expands the coverage of this approach. We make ObservedType, ResultType, and ArithProfile
constexpr-friendly to produce the magic value used in LowLevelInterpreter.asm at compiling time.
This change allows us to easily extend ArithProfile in the future to adopt BigInt efficiently.
We additionally use `constexpr` for several constant values in LowLevelInterpreter.asm.
* assembler/MaxFrameExtentForSlowPathCall.h:
Use this value in LowLevelInterpreter.asm directly. We also make them constexpr. And we add CPU(ARM64E).
* bytecode/ArithProfile.h:
(JSC::ObservedType::ObservedType):
(JSC::ObservedType::sawInt32 const):
(JSC::ObservedType::isOnlyInt32 const):
(JSC::ObservedType::sawNumber const):
(JSC::ObservedType::isOnlyNumber const):
(JSC::ObservedType::sawNonNumber const):
(JSC::ObservedType::isOnlyNonNumber const):
(JSC::ObservedType::isEmpty const):
(JSC::ObservedType::bits const):
(JSC::ObservedType::withInt32 const):
(JSC::ObservedType::withNumber const):
(JSC::ObservedType::withNonNumber const):
(JSC::ObservedType::withoutNonNumber const):
(JSC::ObservedType::operator== const):
(JSC::ArithProfile::ArithProfile):
(JSC::ArithProfile::fromInt):
(JSC::ArithProfile::observedUnaryInt):
(JSC::ArithProfile::observedUnaryNumber):
(JSC::ArithProfile::observedBinaryIntInt):
(JSC::ArithProfile::observedBinaryNumberInt):
(JSC::ArithProfile::observedBinaryIntNumber):
(JSC::ArithProfile::observedBinaryNumberNumber):
(JSC::ArithProfile::lhsObservedType const):
(JSC::ArithProfile::rhsObservedType const):
(JSC::ArithProfile::bits const):
Make ObservedType and ArithProfile constexpr-friendly.
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
Make several ASSERTs to STATIC_ASSERTs. Remove some unnecessary checks.
* llint/LLIntOffsetsExtractor.cpp:
* llint/LowLevelInterpreter.asm:
Remove unused constant values. Use constexpr more and more aggressively.
* parser/ResultType.h:
(JSC::ResultType::ResultType):
(JSC::ResultType::isInt32 const):
(JSC::ResultType::definitelyIsNumber const):
(JSC::ResultType::definitelyIsString const):
(JSC::ResultType::definitelyIsBoolean const):
(JSC::ResultType::definitelyIsBigInt const):
(JSC::ResultType::mightBeNumber const):
(JSC::ResultType::isNotNumber const):
(JSC::ResultType::mightBeBigInt const):
(JSC::ResultType::isNotBigInt const):
(JSC::ResultType::nullType):
(JSC::ResultType::booleanType):
(JSC::ResultType::numberType):
(JSC::ResultType::numberTypeIsInt32):
(JSC::ResultType::stringOrNumberType):
(JSC::ResultType::addResultType):
(JSC::ResultType::stringType):
(JSC::ResultType::bigIntType):
(JSC::ResultType::unknownType):
(JSC::ResultType::forAdd):
(JSC::ResultType::forLogicalOp):
(JSC::ResultType::forBitOp):
(JSC::ResultType::bits const):
Make ResultType constexpr-friendly.
* runtime/JSCJSValue.h:
Use offsetof instead of OBJECT_OFFSETOF. It is OK since EncodedValueDescriptor is POD.
This change makes TagOffset and PayloadOffset macros constexpr-friendly while OBJECT_OFFSETOF
cannot be used in constexpr since it uses reinterpret_cast.
2018-10-17 Keith Miller <keith_miller@apple.com>
Unreviewed revert Fujii's revert in r237214 with new WinCairo build fix.
2018-10-16 Mark Lam <mark.lam@apple.com>
GetIndexedPropertyStorage can GC.
https://bugs.webkit.org/show_bug.cgi?id=190625
<rdar://problem/45309366>
Reviewed by Saam Barati.
This is because if the ArrayMode type is String, the DFG and FTL will be emitting
a call to operationResolveRope, and operationResolveRope can GC. This patch
updates doesGC() to reflect this.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
2018-10-16 Fujii Hironori <Hironori.Fujii@sony.com>
Unreviewed, rolling out r237188, r237189, and r237197.
It breaks WinCairo Debug builds and Release LayoutTests
Reverted changesets:
https://bugs.webkit.org/show_bug.cgi?id=189708
https://trac.webkit.org/changeset/237188
"Unreviewed, forgot to add untracked files."
https://trac.webkit.org/changeset/237189
"isASTErroneous in offlineasm should de-macroify before
looking for Errors"
https://bugs.webkit.org/show_bug.cgi?id=190634
https://trac.webkit.org/changeset/237197
2018-10-16 Devin Rousso <drousso@apple.com>
Web Inspector: Canvas: capture previously saved states and add them to the recording payload
https://bugs.webkit.org/show_bug.cgi?id=190473
Reviewed by Joseph Pecoraro.
* inspector/protocol/Recording.json:
Add `states` key to `InitialState` object.
2018-10-16 Keith Miller <keith_miller@apple.com>
isASTErroneous in offlineasm should de-macroify before looking for Errors
https://bugs.webkit.org/show_bug.cgi?id=190634
Reviewed by Mark Lam.
If a macro isn't usable in a configuration it might still cause us to
think the ast is invalid. This change runs the de-macroifier before
looking for errors.
Also, it adds a missing include to Printer.h.
* assembler/Printer.h:
* offlineasm/settings.rb:
2018-10-16 Justin Michaud <justin_michaud@apple.com>
Implement feature flag and bindings for CSS Painting API
https://bugs.webkit.org/show_bug.cgi?id=190237
Reviewed by Ryosuke Niwa.
* Configurations/FeatureDefines.xcconfig:
2018-10-16 Keith Miller <keith_miller@apple.com>
Unreviewed, forgot to add untracked files.
* llint/LLIntSettingsExtractor.cpp: Added.
(main):
* offlineasm/generate_settings_extractor.rb: Added.
2018-10-16 Keith Miller <keith_miller@apple.com>
Unreviewed, reland https://bugs.webkit.org/show_bug.cgi?id=189708 with build fix.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* llint/LLIntOffsetsExtractor.cpp:
(JSC::LLIntOffsetsExtractor::dummy):
* offlineasm/generate_offset_extractor.rb:
* offlineasm/offsets.rb:
* offlineasm/settings.rb:
2018-10-16 Keith Miller <keith_miller@apple.com>
Unreviewed, add missing include.
* runtime/BasicBlockLocation.h:
2018-10-15 Keith Miller <keith_miller@apple.com>
Support arm64 CPUs with a 32-bit address space
https://bugs.webkit.org/show_bug.cgi?id=190273
Reviewed by Michael Saboff.
This patch adds support for arm64_32 in the LLInt. In order to
make this work we needed to add a new type that reflects the size
of a cpu register. This type is called CPURegister or UCPURegister
for the unsigned version. Most places that used void* or intptr_t
to refer to a register have been changed to use this new type.
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/ARM64Assembler.h:
(JSC::isInt):
(JSC::is4ByteAligned):
(JSC::PairPostIndex::PairPostIndex):
(JSC::PairPreIndex::PairPreIndex):
(JSC::ARM64Assembler::readPointer):
(JSC::ARM64Assembler::readCallTarget):
(JSC::ARM64Assembler::computeJumpType):
(JSC::ARM64Assembler::linkCompareAndBranch):
(JSC::ARM64Assembler::linkConditionalBranch):
(JSC::ARM64Assembler::linkTestAndBranch):
(JSC::ARM64Assembler::loadRegisterLiteral):
(JSC::ARM64Assembler::loadStoreRegisterPairPostIndex):
(JSC::ARM64Assembler::loadStoreRegisterPairPreIndex):
(JSC::ARM64Assembler::loadStoreRegisterPairOffset):
(JSC::ARM64Assembler::loadStoreRegisterPairNonTemporal):
(JSC::isInt7): Deleted.
(JSC::isInt11): Deleted.
* assembler/CPU.h:
(JSC::isAddress64Bit):
(JSC::isAddress32Bit):
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::shouldBlind):
* assembler/MacroAssemblerARM64.cpp:
(JSC::MacroAssemblerARM64::collectCPUFeatures):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::load):
(JSC::MacroAssemblerARM64::store):
(JSC::MacroAssemblerARM64::isInIntRange): Deleted.
* assembler/Printer.h:
* assembler/ProbeContext.h:
(JSC::Probe::CPUState::gpr):
(JSC::Probe::CPUState::spr):
(JSC::Probe::Context::gpr):
(JSC::Probe::Context::spr):
* b3/B3ConstPtrValue.h:
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::isArgValidForRep):
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::stackSlot const):
(JSC::B3::Air::Arg::special const):
* b3/air/testair.cpp:
* b3/testb3.cpp:
(JSC::B3::testStoreConstantPtr):
(JSC::B3::testInterpreter):
(JSC::B3::testAddShl32):
(JSC::B3::testLoadBaseIndexShift32):
* bindings/ScriptFunctionCall.cpp:
(Deprecated::ScriptCallArgumentHandler::appendArgument):
* bindings/ScriptFunctionCall.h:
* bytecode/CodeBlock.cpp:
(JSC::roundCalleeSaveSpaceAsVirtualRegisters):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::restoreCalleeSavesFor):
(JSC::DFG::saveCalleeSavesFor):
(JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
(JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* disassembler/UDis86Disassembler.cpp:
(JSC::tryToDisassembleWithUDis86):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileWeakMapGet):
* heap/MachineStackMarker.cpp:
(JSC::copyMemory):
* interpreter/CallFrame.h:
(JSC::ExecState::returnPC const):
(JSC::ExecState::hasReturnPC const):
(JSC::ExecState::clearReturnPC):
(JSC::ExecState::returnPCOffset):
(JSC::ExecState::isGlobalExec const):
(JSC::ExecState::setReturnPC):
* interpreter/CalleeBits.h:
(JSC::CalleeBits::boxWasm):
(JSC::CalleeBits::isWasm const):
(JSC::CalleeBits::asWasmCallee const):
* interpreter/Interpreter.cpp:
(JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
* interpreter/VMEntryRecord.h:
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::clearStackFrame):
* jit/RegisterAtOffset.h:
(JSC::RegisterAtOffset::offsetAsIndex const):
* jit/RegisterAtOffsetList.cpp:
(JSC::RegisterAtOffsetList::RegisterAtOffsetList):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LLIntOfflineAsmConfig.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter64.asm:
* offlineasm/arm64.rb:
* offlineasm/asm.rb:
* offlineasm/ast.rb:
* offlineasm/backends.rb:
* offlineasm/parser.rb:
* offlineasm/x86.rb:
* runtime/BasicBlockLocation.cpp:
(JSC::BasicBlockLocation::dumpData const):
(JSC::BasicBlockLocation::emitExecuteCode const):
* runtime/BasicBlockLocation.h:
* runtime/HasOwnPropertyCache.h:
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::inplaceMultiplyAdd):
(JSC::JSBigInt::digitDiv):
* runtime/JSBigInt.h:
* runtime/JSObject.h:
* runtime/Options.cpp:
(JSC::jitEnabledByDefault):
* runtime/Options.h:
* runtime/RegExp.cpp:
(JSC::RegExp::printTraceData):
* runtime/SamplingProfiler.cpp:
(JSC::CFrameWalker::walk):
* runtime/SlowPathReturnType.h:
(JSC::encodeResult):
(JSC::decodeResult):
* tools/SigillCrashAnalyzer.cpp:
(JSC::SigillCrashAnalyzer::dumpCodeBlock):
2018-10-15 Justin Fan <justin_fan@apple.com>
Add WebGPU 2018 feature flag and experimental feature flag
https://bugs.webkit.org/show_bug.cgi?id=190509
Reviewed by Dean Jackson.
Re-add ENABLE_WEBGPU, an experimental feature flag, and a RuntimeEnabledFeature
for the 2018 WebGPU prototype.
* Configurations/FeatureDefines.xcconfig:
2018-10-15 Timothy Hatcher <timothy@apple.com>
Add support for prefers-color-scheme media query
https://bugs.webkit.org/show_bug.cgi?id=190499
rdar://problem/45212025
Reviewed by Dean Jackson.
* Configurations/FeatureDefines.xcconfig: Added ENABLE_DARK_MODE_CSS.
2018-10-15 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r237084, r237088, r237098, and
r237114.
https://bugs.webkit.org/show_bug.cgi?id=190602
Breaks internal builds. (Requested by ryanhaddad on #webkit).
Reverted changesets:
"Separate configuration extraction from offset extraction"
https://bugs.webkit.org/show_bug.cgi?id=189708
https://trac.webkit.org/changeset/237084
"Gardening: Build fix after r237084."
https://bugs.webkit.org/show_bug.cgi?id=189708
https://trac.webkit.org/changeset/237088
"Gardening: Build fix after r237084."
https://bugs.webkit.org/show_bug.cgi?id=189708
https://trac.webkit.org/changeset/237098
"REGRESSION (r237084): JavaScriptCore fails to build on Linux"
https://trac.webkit.org/changeset/237114
2018-10-15 Keith Miller <keith_miller@apple.com>
BytecodeDumper should print all switch labels
https://bugs.webkit.org/show_bug.cgi?id=190596
Reviewed by Saam Barati.
Right now the bytecode dumper only prints the default target not any of the
non-default targets.
* bytecode/BytecodeDumper.cpp:
(JSC::BytecodeDumper<Block>::dumpBytecode):
2018-10-15 Saam barati <sbarati@apple.com>
Emit fjcvtzs on ARM64E on Darwin
https://bugs.webkit.org/show_bug.cgi?id=184023
Reviewed by Yusuke Suzuki and Filip Pizlo.
ARMv8.3 introduced the fjcvtzs instruction which does double->int32
conversion using the semantics defined by JavaScript:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0801g/hko1477562192868.html
This patch teaches JSC to use that instruction when possible.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::fjcvtzs):
(JSC::ARM64Assembler::fjcvtzsInsn):
* assembler/MacroAssemblerARM64.cpp:
(JSC::MacroAssemblerARM64::collectCPUFeatures):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::supportsDoubleToInt32ConversionUsingJavaScriptSemantics):
(JSC::MacroAssemblerARM64::convertDoubleToInt32UsingJavaScriptSemantics):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueToInt32):
* disassembler/ARM64/A64DOpcode.cpp:
* disassembler/ARM64/A64DOpcode.h:
(JSC::ARM64Disassembler::A64DOpcode::appendInstructionName):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::doubleToInt32):
* jit/JITRightShiftGenerator.cpp:
(JSC::JITRightShiftGenerator::generateFastPath):
* runtime/MathCommon.h:
(JSC::toInt32):
2018-10-15 Saam Barati <sbarati@apple.com>
JSArray::shiftCountWithArrayStorage is wrong when an array has holes
https://bugs.webkit.org/show_bug.cgi?id=190262
<rdar://problem/44986241>
Reviewed by Mark Lam.
We would take the fast path for shiftCountWithArrayStorage when the array
hasHoles(). However, the code for this was wrong. It'd incorrectly update
ArrayStorage::m_numValuesInVector. Since the hasHoles() for ArrayStorage
path is never taken in JetStream 2, this patch just removes that from
the fast path. Instead, we just fallback to the slow path when hasHoles().
If we find evidence that this matters for real use cases, we can
figure out a way to make the fast path work.
* runtime/JSArray.cpp:
(JSC::JSArray::shiftCountWithArrayStorage):
2018-10-15 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r237054.
https://bugs.webkit.org/show_bug.cgi?id=190593
"this regressed JetStream 2 by 6% on iOS" (Requested by
saamyjoon on #webkit).
Reverted changeset:
"[JSC] JSC should have "parseFunction" to optimize Function
constructor"
https://bugs.webkit.org/show_bug.cgi?id=190340
https://trac.webkit.org/changeset/237054
2018-10-14 David Kilzer <ddkilzer@apple.com>
REGRESSION (r237084): JavaScriptCore fails to build on Linux
<https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10949>
* llint/LLIntSettingsExtractor.cpp: Attempt to fix build by
including <stdio.h>.
2018-10-15 Alex Christensen <achristensen@webkit.org>
Shrink more enum classes
https://bugs.webkit.org/show_bug.cgi?id=190540
Reviewed by Chris Dumez.
* runtime/ConsoleTypes.h:
2018-10-15 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Disable DOMJIT on 32bit architecture
https://bugs.webkit.org/show_bug.cgi?id=190387
Reviewed by Mark Lam.
We disable DOMJIT on 32bit architecture due to exhaustion of registers.
* runtime/Options.h:
2018-10-15 Alex Christensen <achristensen@webkit.org>
Include EnumTraits.h less
https://bugs.webkit.org/show_bug.cgi?id=190535
Reviewed by Chris Dumez.
* runtime/ConsoleTypes.h:
2018-10-14 Mark Lam <mark.lam@apple.com>
Gardening: Build fix after r237084.
https://bugs.webkit.org/show_bug.cgi?id=189708
Unreviewd.
* llint/LLIntOffsetsExtractor.cpp:
2018-10-14 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Remove Option::useAsyncIterator
https://bugs.webkit.org/show_bug.cgi?id=190567
Reviewed by Saam Barati.
Async iterator is enabled by default at 2017-08-09. It is already shipped in several releases,
and we can think that it is already mature. Let's drop the option `Option::useAsyncIterator`.
* Configurations/FeatureDefines.xcconfig:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
(JSC::BytecodeGenerator::emitNewFunction):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionMetadata):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseForStatement):
(JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseProperty):
(JSC::Parser<LexerType>::parseAsyncFunctionExpression):
* runtime/Options.h:
2018-10-14 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Remove Options::useObjectRestSpread
https://bugs.webkit.org/show_bug.cgi?id=190568
Reviewed by Saam Barati.
Options::useObjectRestSpread is enabled by default at 2017-06-27. It is already shipped in several releases,
and we can think that it is mature. Let's drop Options::useObjectRestSpread() flag.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::Parser):
(JSC::Parser<LexerType>::parseDestructuringPattern):
(JSC::Parser<LexerType>::parseProperty):
* parser/Parser.h:
* runtime/Options.h:
2018-10-13 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] JSON.stringify can accept call-with-no-arguments
https://bugs.webkit.org/show_bug.cgi?id=190343
Reviewed by Mark Lam.
JSON.stringify can accept `JSON.stringify()` call (call-with-no-arguments) according to the spec[1].
Instead of throwing an error, we should take the first argument as `undefined` if it is not given.
[1]: https://tc39.github.io/ecma262/#sec-json.stringify
* runtime/JSONObject.cpp:
(JSC::JSONProtoFuncStringify):
2018-10-12 Tadeu Zagallo <tzagallo@apple.com>
Gardening: Build fix after r237084.
https://bugs.webkit.org/show_bug.cgi?id=189708
Unreviewd.
* JavaScriptCore.xcodeproj/project.pbxproj:
2018-10-12 Tadeu Zagallo <tzagallo@apple.com>
Separate configuration extraction from offset extraction
https://bugs.webkit.org/show_bug.cgi?id=189708
Reviewed by Keith Miller.
Instead of generating a file with all offsets for every combination of
configurations, we first generate a file with only the configuration
indices and pass that to the offset extractor. The offset extractor then
only generates the offsets for valid configurations
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* llint/LLIntOffsetsExtractor.cpp:
(JSC::LLIntOffsetsExtractor::dummy):
* llint/LLIntSettingsExtractor.cpp: Added.
(main):
* offlineasm/generate_offset_extractor.rb:
* offlineasm/generate_settings_extractor.rb: Added.
* offlineasm/offsets.rb:
* offlineasm/settings.rb:
2018-10-12 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r237063.
Caused layout test fast/dom/Window/window-postmessage-clone-
deep-array.html to fail on macOS and iOS Debug bots.
Reverted changeset:
"[JSC] Remove gcc warnings on mips and armv7"
https://bugs.webkit.org/show_bug.cgi?id=188598
https://trac.webkit.org/changeset/237063
2018-10-11 Guillaume Emont <guijemont@igalia.com>
[JSC] Remove gcc warnings on mips and armv7
https://bugs.webkit.org/show_bug.cgi?id=188598
Reviewed by Mark Lam.
Fix many gcc/clang warnings that are false positives, mostly alignment
issues.
* assembler/MacroAssemblerPrinter.cpp:
(JSC::Printer::printMemory):
Use bitwise_cast instead of reinterpret_cast.
* assembler/testmasm.cpp:
(JSC::floatOperands):
marked as potentially unused as it is not used on all platforms.
(JSC::testProbeModifiesStackValues):
modifiedFlags is not used on mips, so don't declare it.
* bytecode/CodeBlock.h:
Make ScriptExecutable::prepareForExecution() return an
std::optional<Exception*> instead of a JSObject*.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::executeProgram):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
(JSC::Interpreter::prepareForRepeatCall):
(JSC::Interpreter::execute):
(JSC::Interpreter::executeModuleProgram):
Update calling code for the prototype change of
ScriptExecutable::prepareForExecution().
* jit/JITOperations.cpp: Same as for Interpreter.cpp.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setUpCall): Same as for Interpreter.cpp.
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::dataStorage):
Use bitwise_cast instead of reinterpret_cast.
* runtime/ScriptExecutable.cpp:
* runtime/ScriptExecutable.h:
Make ScriptExecutable::prepareForExecution() return an
std::optional<Exception*> instead of a JSObject*.
* tools/JSDollarVM.cpp:
(JSC::codeBlockFromArg): Use bitwise_cast instead of reinterpret_cast.
2018-10-11 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Use currentStackPointer more
https://bugs.webkit.org/show_bug.cgi?id=190503
Reviewed by Saam Barati.
* runtime/VM.cpp:
(JSC::VM::committedStackByteCount):
2018-10-08 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] JSC should have "parseFunction" to optimize Function constructor
https://bugs.webkit.org/show_bug.cgi?id=190340
Reviewed by Mark Lam.
The current Function constructor is suboptimal. We parse the piece of the same code three times to meet
the spec requirement. (1) check parameters syntax, (2) check body syntax, and (3) parse the entire function.
And to parse 1-3 correctly, we create two strings, the parameters and the entire function. This operation
is really costly and ideally we should meet the above requirement by the one time parsing.
To meet the above requirement, we add a special function for Parser, parseSingleFunction. This function
takes `std::optional<int> functionConstructorParametersEndPosition` and check this end position is correct in the parser.
For example, if we run the code,
Function('/*', '*/){')
According to the spec, this should produce '/*' parameter string and '*/){' body string. And parameter
string should be syntax-checked by the parser, and raise the error since it is incorrect. Instead of doing
that, in our implementation, we first create the entire string.
function anonymous(/*) {
*/){
}
And we parse it. At that time, we also pass the end position of the parameters to the parser. In the above case,
the position of the `function anonymous(/*)' <> is passed. And in the parser, we check that the last token
offset of the parameters is the given end position. This check allows us to raise the error correctly to the
above example while we parse the entire function only once. And we do not need to create two strings too.
This improves the performance of the Function constructor significantly. And web-tooling-benchmark/uglify-js is
significantly sped up (28.2%).
Before:
uglify-js: 2.94 runs/s
After:
uglify-js: 3.77 runs/s
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
* bytecode/UnlinkedFunctionExecutable.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseSingleFunction):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parsePropertyMethod):
(JSC::Parser<LexerType>::parseGetterSetter):
(JSC::Parser<LexerType>::parseFunctionExpression):
(JSC::Parser<LexerType>::parseAsyncFunctionExpression):
(JSC::Parser<LexerType>::parseArrowFunctionExpression):
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
(JSC::parse):
(JSC::parseFunctionForFunctionConstructor):
* parser/ParserModes.h:
* parser/ParserTokens.h:
(JSC::JSTextPosition::JSTextPosition):
(JSC::JSTokenLocation::JSTokenLocation): Deleted.
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::SourceCodeKey):
(JSC::SourceCodeKey::operator== const):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
* runtime/CodeCache.h:
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/FunctionExecutable.h:
2018-10-11 Ross Kirsling <ross.kirsling@sony.com>
Fix non-existent define `CPU(JSVALUE64)`
https://bugs.webkit.org/show_bug.cgi?id=190479
Reviewed by Yusuke Suzuki.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsImpl):
Correct CPU(JSVALUE64) to USE(JSVALUE64).
2018-10-11 Keith Rollin <krollin@apple.com>
CURRENT_ARCH should not be used in Run Script phase.
https://bugs.webkit.org/show_bug.cgi?id=190407
<rdar://problem/45133556>
Reviewed by Alexey Proskuryakov.
CURRENT_ARCH is used in a number of Xcode Run Script phases. However,
CURRENT_ARCH is not well-defined during this phase (and may even have
the value "undefined") since this phase is run just once per build
rather than once per supported architecture. Migrate away from
CURRENT_ARCH in favor of ARCHS, either by iterating over ARCHS and
performing an operation for each value, or by picking the first entry
in ARCHS and using that as a representative value.
* JavaScriptCore.xcodeproj/project.pbxproj: Store
LLIntDesiredOffsets.h into a directory with a name based on ARCHS
rather than CURRENT_ARCH.
2018-10-10 Mark Lam <mark.lam@apple.com>
Changes towards allowing use of the ASAN detect_stack_use_after_return option.
https://bugs.webkit.org/show_bug.cgi?id=190405
<rdar://problem/45131464>
Reviewed by Michael Saboff.
The ASAN detect_stack_use_after_return option checks for use of stack variables
after they have been freed. It does this by allocating relevant stack variables
in heap memory (instead of on the stack) if the code ever takes the address of
those stack variables. Unfortunately, this is a common idiom that we use to
compute the approximate stack pointer value. As a result, on such ASAN runs, the
computed approximate stack pointer value will point into the heap instead of the
stack. This breaks the VM's expectations and wreaks havoc.
To fix this, we use the newly introduced WTF::currentStackPointer() instead of
taking the address of stack variables.
We also need to enhance ExceptionScopes to be able to work with ASAN
detect_stack_use_after_return which will allocated the scope in the heap. We
work around this by passing the current stack pointer of the instantiating calling
frame into the scope constructor, and using that for the position check in
~ThrowScope() instead.
The above is only a start towards enabling ASAN detect_stack_use_after_return on
the VM. There are still other issues to be resolved before we can run with this
ASAN option.
* runtime/CatchScope.h:
* runtime/ExceptionEventLocation.h:
(JSC::ExceptionEventLocation::ExceptionEventLocation):
* runtime/ExceptionScope.h:
(JSC::ExceptionScope::stackPosition const):
* runtime/JSLock.cpp:
(JSC::JSLock::didAcquireLock):
* runtime/ThrowScope.cpp:
(JSC::ThrowScope::~ThrowScope):
* runtime/ThrowScope.h:
* runtime/VM.h:
(JSC::VM::needExceptionCheck const):
(JSC::VM::isSafeToRecurse const):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
* yarr/YarrPattern.cpp:
(JSC::Yarr::YarrPatternConstructor::isSafeToRecurse const):
2018-10-10 Devin Rousso <drousso@apple.com>
Web Inspector: create special Network waterfall for media events
https://bugs.webkit.org/show_bug.cgi?id=189773
<rdar://problem/44626605>
Reviewed by Joseph Pecoraro.
* inspector/protocol/DOM.json:
Add `didFireEvent` event that is fired when specific event listeners added by
`InspectorInstrumentation::addEventListenersToNode` are fired.
2018-10-10 Michael Saboff <msaboff@apple.com>
Increase executable memory pool from 64MB to 128MB for ARM64
https://bugs.webkit.org/show_bug.cgi?id=190453
Reviewed by Saam Barati.
* jit/ExecutableAllocator.cpp:
2018-10-10 Devin Rousso <drousso@apple.com>
Web Inspector: notify the frontend when a canvas has started recording via console.record
https://bugs.webkit.org/show_bug.cgi?id=190306
Reviewed by Brian Burg.
* inspector/protocol/Canvas.json:
Add `recordingStarted` event.
* inspector/protocol/Recording.json:
Add `Initiator` enum for determining who started the recording.
2018-10-10 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Rename createXXX to tryCreateXXX if it can return RefPtr
https://bugs.webkit.org/show_bug.cgi?id=190429
Reviewed by Saam Barati.
Some createXXX functions can fail. But sometimes the caller does not perform error checking.
To make it explicit that these functions can fail, we rename these functions from createXXX
to tryCreateXXX. In this patch, we focus on non-JS-managed factory functions. If the factory
function does not fail, it should return Ref<>. Otherwise, it should be named as tryCreateXXX
and it should return RefPtr<>.
This patch mainly focuses on TypedArray factory functions. Previously, these functions are
`RefPtr<XXXArray> create(...)`. This patch changes them to `RefPtr<XXXArray> tryCreate(...)`.
And we also introduce `Ref<XXXArray> create(...)` function which internally performs
RELEASE_ASSERT on the result of `tryCreate(...)`.
And we also convert OpaqueJSString::create to OpaqueJSString::tryCreate since it can fail.
This change actually finds one place which does not perform any null checkings while it uses
`RefPtr<> create(...)` function.
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::getOwnPropertySlot):
(JSC::JSCallbackObject<Parent>::put):
(JSC::JSCallbackObject<Parent>::putByIndex):
(JSC::JSCallbackObject<Parent>::deleteProperty):
(JSC::JSCallbackObject<Parent>::callbackGetter):
* API/JSClassRef.h:
(StaticValueEntry::StaticValueEntry):
* API/JSContext.mm:
(-[JSContext evaluateScript:withSourceURL:]):
(-[JSContext setName:]):
* API/JSContextRef.cpp:
(JSGlobalContextCopyName):
(JSContextCreateBacktrace):
* API/JSObjectRef.cpp:
(JSObjectCopyPropertyNames):
* API/JSScriptRef.cpp:
* API/JSStringRef.cpp:
(JSStringCreateWithCharactersNoCopy):
* API/JSValue.mm:
(+[JSValue valueWithNewRegularExpressionFromPattern:flags:inContext:]):
(+[JSValue valueWithNewErrorFromMessage:inContext:]):
(+[JSValue valueWithNewSymbolFromDescription:inContext:]):
(performPropertyOperation):
(-[JSValue invokeMethod:withArguments:]):
(containerValueToObject):
(objectToValueWithoutCopy):
(objectToValue):
* API/JSValueRef.cpp:
(JSValueCreateJSONString):
(JSValueToStringCopy):
* API/OpaqueJSString.cpp:
(OpaqueJSString::tryCreate):
(OpaqueJSString::create): Deleted.
* API/OpaqueJSString.h:
* API/glib/JSCContext.cpp:
(evaluateScriptInContext):
* API/glib/JSCValue.cpp:
(jsc_value_new_string_from_bytes):
* ftl/FTLLazySlowPath.h:
(JSC::FTL::LazySlowPath::createGenerator):
* ftl/FTLLazySlowPathCall.h:
(JSC::FTL::createLazyCallGenerator):
* ftl/FTLOSRExit.cpp:
(JSC::FTL::OSRExitDescriptor::emitOSRExit):
(JSC::FTL::OSRExitDescriptor::emitOSRExitLater):
(JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
* ftl/FTLOSRExit.h:
* ftl/FTLPatchpointExceptionHandle.cpp:
(JSC::FTL::PatchpointExceptionHandle::create):
(JSC::FTL::PatchpointExceptionHandle::createHandle):
* ftl/FTLPatchpointExceptionHandle.h:
* heap/EdenGCActivityCallback.h:
(JSC::GCActivityCallback::tryCreateEdenTimer):
(JSC::GCActivityCallback::createEdenTimer): Deleted.
* heap/FullGCActivityCallback.h:
(JSC::GCActivityCallback::tryCreateFullTimer):
(JSC::GCActivityCallback::createFullTimer): Deleted.
* heap/GCActivityCallback.h:
* heap/Heap.cpp:
(JSC::Heap::Heap):
* inspector/AsyncStackTrace.cpp:
(Inspector::AsyncStackTrace::create):
* inspector/AsyncStackTrace.h:
* jsc.cpp:
(fillBufferWithContentsOfFile):
* runtime/ArrayBuffer.h:
* runtime/GenericTypedArrayView.h:
* runtime/GenericTypedArrayViewInlines.h:
(JSC::GenericTypedArrayView<Adaptor>::create):
(JSC::GenericTypedArrayView<Adaptor>::tryCreate):
(JSC::GenericTypedArrayView<Adaptor>::createUninitialized):
(JSC::GenericTypedArrayView<Adaptor>::tryCreateUninitialized):
(JSC::GenericTypedArrayView<Adaptor>::subarray const):
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::possiblySharedImpl):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::possiblySharedTypedImpl):
(JSC::JSGenericTypedArrayView<Adaptor>::unsharedTypedImpl):
* wasm/WasmMemory.cpp:
(JSC::Wasm::Memory::create):
(JSC::Wasm::Memory::tryCreate):
* wasm/WasmMemory.h:
* wasm/WasmTable.cpp:
(JSC::Wasm::Table::tryCreate):
(JSC::Wasm::Table::create): Deleted.
* wasm/WasmTable.h:
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::create):
* wasm/js/JSWebAssemblyMemory.cpp:
(JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::constructJSWebAssemblyMemory):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
* wasm/js/WebAssemblyTableConstructor.cpp:
(JSC::constructJSWebAssemblyTable):
2018-10-09 Devin Rousso <drousso@apple.com>
Web Inspector: show redirect requests in Network and Timelines tabs
https://bugs.webkit.org/show_bug.cgi?id=150005
<rdar://problem/5378164>
Reviewed by Joseph Pecoraro.
* inspector/protocol/Network.json:
Add missing fields to `ResourceTiming`.
2018-10-09 Claudio Saavedra <csaavedra@igalia.com>
[WPE] Explicitly link against gmodule where used
https://bugs.webkit.org/show_bug.cgi?id=190398
Reviewed by Michael Catanzaro.
* PlatformWPE.cmake:
2018-10-08 Justin Fan <justin_fan@apple.com>
WebGPU: Rename old WebGPU prototype to WebMetal
https://bugs.webkit.org/show_bug.cgi?id=190325
<rdar://problem/44990443>
Reviewed by Dean Jackson.
Rename WebGPU prototype files to WebMetal in preparation for implementing the new (Oct 2018) WebGPU interface.
* Configurations/FeatureDefines.xcconfig:
* inspector/protocol/Canvas.json:
* inspector/scripts/codegen/generator.py:
2018-10-08 Aditya Keerthi <akeerthi@apple.com>
Make <input type=color> a runtime enabled (on-by-default) feature
https://bugs.webkit.org/show_bug.cgi?id=189162
Reviewed by Wenson Hsieh and Tim Horton.
* Configurations/FeatureDefines.xcconfig:
2018-10-08 Devin Rousso <drousso@apple.com>
Web Inspector: group media network entries by the node that triggered the request
https://bugs.webkit.org/show_bug.cgi?id=189606
<rdar://problem/44438527>
Reviewed by Brian Burg.
* inspector/protocol/Network.json:
Add an optional `nodeId` field to the `Initiator` object that is set it is possible to
determine which ancestor node triggered the load. It may not correspond directly to the node
with the href/src, as that url may only be used by an ancestor for loading.
2018-10-07 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC][Linux] Use non-truncated name for JIT workers in Linux
https://bugs.webkit.org/show_bug.cgi?id=190339
Reviewed by Mark Lam.
The current thread names are meaningless in Linux environment. We do not want to
have truncated name in Linux: we want to have clear name in Linux. Instead, we
should have the name for Linux separately from the name used in the non-Linux
environments. This patch adds FTLWorker, DFGWorker, and JITWorker names for
Linux environment.
* dfg/DFGWorklist.cpp:
(JSC::DFG::createWorklistName):
(JSC::DFG::Worklist::Worklist):
(JSC::DFG::Worklist::create):
(JSC::DFG::ensureGlobalDFGWorklist):
(JSC::DFG::ensureGlobalFTLWorklist):
* dfg/DFGWorklist.h:
* jit/JITWorklist.cpp:
2018-10-07 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Name Heap threads
https://bugs.webkit.org/show_bug.cgi?id=190337
Reviewed by Mark Lam.
Name heap threads as "Heap Helper Thread". In Linux, we name it "HeapHelper" since
Linux does not accept the name longer than 15. We do not want to use the short name
for non-Linux environment. And we want to have clear name in Linux: truncated name
is not good. So, having the two names is the only way.
* heap/HeapHelperPool.cpp:
(JSC::heapHelperPool):
2018-10-07 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Avoid creating ProgramExecutable in checkSyntax
https://bugs.webkit.org/show_bug.cgi?id=190332
Reviewed by Mark Lam.
uglify-js in web-tooling-benchmark executes massive number of Function constructor calls.
In Function constructor code, we perform checkSyntax for body and parameters. So fast checkSyntax
is important when the performance of Function constructor matters. Current checkSyntax code
unnecessarily allocates ProgramExecutable. This patch removes this allocation and improves
the benchmark score slightly.
Before:
uglify-js: 2.87 runs/s
After:
uglify-js: 2.94 runs/s
* runtime/Completion.cpp:
(JSC::checkSyntaxInternal):
(JSC::checkSyntax):
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::checkSyntax): Deleted.
* runtime/ProgramExecutable.h:
2018-10-06 Caio Lima <ticaiolima@gmail.com>
[ESNext][BigInt] Implement support for "|"
https://bugs.webkit.org/show_bug.cgi?id=186229
Reviewed by Yusuke Suzuki.
This patch is introducing support for BigInt into bitwise "or" operator.
In addition, we are also introducing 2 new DFG nodes, named "ArithBitOr" and
"ValueBitOr", to replace "BitOr" node. The idea is to follow the
difference that we make on Arith<op> and Value<op>, where ArithBitOr
handles cases when the operands are Int32 and ValueBitOr handles
the remaining cases.
We are also changing op_bitor to use ValueProfile. We are using
ValueProfile during DFG generation to emit "ArithBitOr" when
outcome prediction is Int32.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::arithProfileForPC):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitBinaryOp):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo):
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
(JSC::DFG::bitwiseOp):
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueBitwiseOp):
(JSC::DFG::SpeculativeJIT::compileBitwiseOp):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::bitOp):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileValueBitOr):
(JSC::FTL::DFG::LowerDFGToB3::compileArithBitOr):
(JSC::FTL::DFG::LowerDFGToB3::compileBitOr): Deleted.
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_bitor):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::bitwiseAnd):
(JSC::JSBigInt::bitwiseOr):
(JSC::JSBigInt::absoluteBitwiseOp):
(JSC::JSBigInt::absoluteAddOne):
* runtime/JSBigInt.h:
2018-10-05 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Use new extra memory reporting in SparseArrayMap
https://bugs.webkit.org/show_bug.cgi?id=190278
Reviewed by Keith Miller.
This patch switches the extra memory reporting mechanism from deprecatedReportExtraMemory
to reportExtraMemoryAllocated & reportExtraMemoryVisited in SparseArrayMap.
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::add):
(JSC::SparseArrayValueMap::visitChildren):
2018-10-05 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC][Linux] Support Perf JITDump logging
https://bugs.webkit.org/show_bug.cgi?id=189893
Reviewed by Mark Lam.
This patch adds Linux `perf` command's JIT Dump support. It allows JSC to tell perf about JIT code information.
We add a command line option, `--logJITCodeForPerf`, which dumps `jit-%pid.dump` in the current directory.
By using this dump and perf.data output, we can annotate JIT code with profiling information.
$ echo "(function f() { var s = 0; for (var i = 0; i < 1000000000; i++) { s += i; } return s; })();" > test.js
$ perf record -k mono ../../WebKitBuild/perf/Release/bin/jsc test.js --logJITCodeForPerf=true
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.182 MB perf.data (4346 samples) ]
$ perf inject --jit -i perf.data -o perf.jit.data
$ perf report -i perf.jit.data
* Sources.txt:
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::finalizeCodeWithDisassemblyImpl):
* assembler/LinkBuffer.h:
(JSC::LinkBuffer::finalizeCodeWithDisassembly):
* assembler/PerfLog.cpp: Added.
(JSC::PerfLog::singleton):
(JSC::generateTimestamp):
(JSC::getCurrentThreadID):
(JSC::PerfLog::PerfLog):
(JSC::PerfLog::write):
(JSC::PerfLog::flush):
(JSC::PerfLog::log):
* assembler/PerfLog.h: Added.
* jit/ExecutableAllocator.cpp:
(JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
* runtime/Options.cpp:
(JSC::Options::isAvailable):
* runtime/Options.h:
2018-10-05 Mark Lam <mark.lam@apple.com>
Gardening: Build fix after r236880.
https://bugs.webkit.org/show_bug.cgi?id=190317
Unreviewed.
* jit/ExecutableAllocator.h:
2018-10-05 Mark Lam <mark.lam@apple.com>
performJITMemcpy() should handle the case when the executable allocator is not initialized yet.
https://bugs.webkit.org/show_bug.cgi?id=190317
<rdar://problem/45039398>
Reviewed by Saam Barati.
When SeparatedWXHeaps is in use, jitWriteThunkGenerator() will call performJITMemcpy()
to copy memory before the JIT fixed memory pool is initialize. Before r236864,
performJITMemcpy() would just do a memcpy in that case. We need to restore the
equivalent behavior.
* jit/ExecutableAllocator.cpp:
(JSC::isJITPC):
* jit/ExecutableAllocator.h:
(JSC::performJITMemcpy):
2018-10-05 Carlos Eduardo Ramalho <cadubentzen@gmail.com>
[WPE][JSC] Use Unified Sources for Platform-specific sources
https://bugs.webkit.org/show_bug.cgi?id=190300
Reviewed by Yusuke Suzuki.
Currently the GTK port already used Unified Sources with the same source files.
As WPE has conditional code using gmodule, we need to add GLIB_GMODULE_LIBRARIES
to the list of libraries to link with.
* PlatformWPE.cmake:
* SourcesWPE.txt: Added.
* shell/PlatformWPE.cmake:
2018-10-05 Mike Gorse <mgorse@alum.wpi.edu>
[GTK] build fails with python 3 if LANG and LC_TYPE are unset
https://bugs.webkit.org/show_bug.cgi?id=190258
Reviewed by Konstantin Tokarev.
* Scripts/cssmin.py: Set stdout to UTF-8 on python 3.
* Scripts/generateIntlCanonicalizeLanguage.py: Open files with
encoding=UTF-8 on Python 3.
* yarr/generateYarrCanonicalizeUnicode: Ditto.
* yarr/generateYarrUnicodePropertyTables.py: Ditto.
2018-10-04 Mark Lam <mark.lam@apple.com>
Move start/EndOfFixedExecutableMemoryPool pointers into the FixedVMPoolExecutableAllocator object.
https://bugs.webkit.org/show_bug.cgi?id=190295
<rdar://problem/19197193>
Reviewed by Saam Barati.
This allows us to use the tagging logic already baked into MacroAssemblerCodePtr
instead of needing to use our own custom version here.
* jit/ExecutableAllocator.cpp:
(JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
(JSC::FixedVMPoolExecutableAllocator::memoryStart):
(JSC::FixedVMPoolExecutableAllocator::memoryEnd):
(JSC::FixedVMPoolExecutableAllocator::isJITPC):
(JSC::ExecutableAllocator::allocate):
(JSC::startOfFixedExecutableMemoryPoolImpl):
(JSC::endOfFixedExecutableMemoryPoolImpl):
(JSC::isJITPC):
* jit/ExecutableAllocator.h:
2018-10-04 Mark Lam <mark.lam@apple.com>
Disable Options::useWebAssemblyFastMemory() on linux if ASAN signal handling is not disabled.
https://bugs.webkit.org/show_bug.cgi?id=190283
<rdar://problem/45015752>
Reviewed by Keith Miller.
* runtime/Options.cpp:
(JSC::Options::initialize):
* wasm/WasmFaultSignalHandler.cpp:
(JSC::Wasm::enableFastMemory):
2018-10-03 Ross Kirsling <ross.kirsling@sony.com>
[JSC] print() changes CRLF to CRCRLF on Windows
https://bugs.webkit.org/show_bug.cgi?id=190228
Reviewed by Mark Lam.
* jsc.cpp:
(main):
Ultimately, this is just the normal behavior of printf in text mode on Windows.
Since we're reading in files as binary, we need to be printing out as binary too
(just as we do in DumpRenderTree and ImageDiff.)
2018-10-03 Saam barati <sbarati@apple.com>
lowXYZ in FTLLower should always filter the type of the incoming edge
https://bugs.webkit.org/show_bug.cgi?id=189939
<rdar://problem/44407030>
Reviewed by Michael Saboff.
For example, the FTL may know more about data flow than AI in certain programs,
and it needs to inform AI of these data flow properties to appease the assertion
we have in AI that a node must perform type checks on its child nodes.
For example, consider this program:
```
bb#1
a: Phi // Let's say it has an Int32 result, so it goes into the int32 hash table in FTLLower
Branch(..., #2, #3)
bb#2
ArrayifyToStructure(Cell:@a) // This modifies @a to have the its previous type union the type of some structure set.
Jump(#3)
bb#3
c: Add(Int32:@something, Int32:@a)
```
When the Add node does lowInt32() for @a, FTL lower used to just grab it
from the int32 hash table without filtering the AbstractValue. However,
the parent node is asking for a type check to happen, so we must inform
AI of this "type check" if we want to appease the assertion that all nodes
perform type checks for their edges that semantically perform type checks.
This patch makes it so we filter the AbstractValue in the lowXYZ even
if FTLLower proved the value must be XYZ.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compilePhi):
(JSC::FTL::DFG::LowerDFGToB3::simulatedTypeCheck):
(JSC::FTL::DFG::LowerDFGToB3::lowInt32):
(JSC::FTL::DFG::LowerDFGToB3::lowCell):
(JSC::FTL::DFG::LowerDFGToB3::lowBoolean):
2018-10-03 Michael Saboff <msaboff@apple.com>
Command line jsc should report memory footprint in bytes
https://bugs.webkit.org/show_bug.cgi?id=190267
Reviewed by Mark Lam.
Change to leave the footprint values from the system unmodified.
* jsc.cpp:
(JSCMemoryFootprint::finishCreation):
2018-10-03 Mark Lam <mark.lam@apple.com>
Suppress unreachable code warning for LLIntAssembly.h code.
https://bugs.webkit.org/show_bug.cgi?id=190263
<rdar://problem/44986532>
Reviewed by Saam Barati.
This is needed because LLIntAssembly.h is template generated from LowLevelInterpreter
asm files, and may contain dead code which are harmless, but will trip up the warning.
We should suppress the warning so that it doesn't break builds.
* llint/LowLevelInterpreter.cpp:
(JSC::CLoop::execute):
2018-10-03 Dan Bernstein <mitz@apple.com>
JavaScriptCore part of [Xcode] Update some build settings as recommended by Xcode 10
https://bugs.webkit.org/show_bug.cgi?id=190250
Reviewed by Alex Christensen.
* API/tests/Regress141275.mm:
(-[JSTEvaluator _sourcePerform]): Addressed newly-enabled CLANG_WARN_OBJC_IMPLICIT_RETAIN_SELF
by making the self-retaining explicit.
* API/tests/testapi.cpp:
(testCAPIViaCpp): Addressed newly-enabled CLANG_WARN_UNREACHABLE_CODE by breaking out of the
loop instead of returning from the lambda.
* Configurations/Base.xcconfig: Enabled CLANG_WARN_COMMA, CLANG_WARN_UNREACHABLE_CODE,
CLANG_WARN_DEPRECATED_OBJC_IMPLEMENTATIONS, CLANG_WARN_OBJC_IMPLICIT_RETAIN_SELF, and
CLANG_ANALYZER_LOCALIZABILITY_NONLOCALIZED.
* JavaScriptCore.xcodeproj/project.pbxproj: Removed a duplicate reference to
UnlinkedFunctionExecutable.h, and let Xcode update the project file.
* assembler/MacroAssemblerPrinter.cpp:
(JSC::Printer::printAllRegisters): Addressed newly-enabled CLANG_WARN_COMMA by replacing
some commas with semicolons.
2018-10-03 Mark Lam <mark.lam@apple.com>
Make string MaxLength for all WTF and JS strings consistently equal to INT_MAX.
https://bugs.webkit.org/show_bug.cgi?id=190187
<rdar://problem/42512909>
Reviewed by Michael Saboff.
Allowing different max string lengths at each level opens up opportunities for
bugs to creep in. With 2 different max length values, it is more difficult to
keep the story straight on how we do overflow / bounds checks at each place in
the code. It's also difficult to tell if a seemingly valid check at the WTF level
will have bad ramifications at the JSC level. Also, it's also not meaningful to
support a max length > INT_MAX. To eliminate this class of bugs, we'll
standardize on a MaxLength of INT_MAX at all levels.
We'll also standardize the way we do length overflow checks on using
CheckedArithmetic, and add some asserts to document the assumptions of the code.
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
- Fix OOM error handling which crashed a test after the new MaxLength was applied.
* runtime/JSString.h:
(JSC::JSString::finishCreation):
(JSC::JSString::createHasOtherOwner):
(JSC::JSString::setLength):
* runtime/JSStringInlines.h:
(JSC::jsMakeNontrivialString):
* runtime/Operations.h:
(JSC::jsString):
2018-10-03 Koby Boyango <koby.b@mce-sys.com>
[JSC] Add a C++ callable overload of objectConstructorSeal
https://bugs.webkit.org/show_bug.cgi?id=190137
Reviewed by Yusuke Suzuki.
* runtime/ObjectConstructor.cpp:
* runtime/ObjectConstructor.h:
2018-10-02 Dominik Infuehr <dinfuehr@igalia.com>
Fix Disassembler-output on ARM Thumb2
https://bugs.webkit.org/show_bug.cgi?id=190203
On ARMv7 with Thumb2 addresses have bit 0 set to 1 to force
execution in thumb mode for jumps and calls. The actual machine
instructions are still aligned to 2-bytes though. Use dataLocation() as
start address for disassembling since it unsets the thumb bit.
Until now the disassembler would start at the wrong address (off by 1),
resulting in the wrong disassembled machine instructions.
Reviewed by Mark Lam.
* disassembler/CapstoneDisassembler.cpp:
(JSC::tryToDisassemble):
2018-10-02 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Add stub of ExecutableAllocator used when JIT is disabled
https://bugs.webkit.org/show_bug.cgi?id=190215
Reviewed by Mark Lam.
When ENABLE(JIT) is disabled, we do not use JIT. But we ExecutableAllocator is still available since
it is guarded by ENABLE(ASSEMBLER). ENABLE(ASSEMBLER) is necessary for LLInt ASM interpreter since
our MacroAssembler tells machine architecture information. Eventually, we would like to decouple
this machine architecture information from MacroAssembler. But for now, we use ENABLE(ASSEMBLER)
for LLInt ASM interpreter even if JIT is disabled by ENABLE(JIT).
To ensure any executable memory allocation is not done, we add a stub of ExecutableAllocator for
non-JIT configurations. This does not have any functionality allocating executable memory, thus
any accidental operation cannot attempt to allocate executable memory if ENABLE(JIT) = OFF.
* jit/ExecutableAllocator.cpp:
(JSC::ExecutableAllocator::initializeAllocator):
(JSC::ExecutableAllocator::singleton):
* jit/ExecutableAllocator.h:
(JSC::ExecutableAllocator::isValid const):
(JSC::ExecutableAllocator::underMemoryPressure):
(JSC::ExecutableAllocator::memoryPressureMultiplier):
(JSC::ExecutableAllocator::dumpProfile):
(JSC::ExecutableAllocator::allocate):
(JSC::ExecutableAllocator::isValidExecutableMemory):
(JSC::ExecutableAllocator::committedByteCount):
(JSC::ExecutableAllocator::getLock const):
(JSC::performJITMemcpy):
2018-10-01 Dean Jackson <dino@apple.com>
Remove CSS Animation Triggers
https://bugs.webkit.org/show_bug.cgi?id=190175
<rdar://problem/44925626>
Reviewed by Simon Fraser.
* Configurations/FeatureDefines.xcconfig:
2018-10-02 Caio Lima <ticaiolima@gmail.com>
[BigInt] BigInt.proptotype.toString is broken when radix is power of 2
https://bugs.webkit.org/show_bug.cgi?id=190033
Reviewed by Yusuke Suzuki.
The implementation of JSBigInt::toStringToGeneric doesn't handle power
of 2 radix when JSBigInt length is >= 2. To handle such cases, we
implemented JSBigInt::toStringBasePowerOfTwo that follows the
algorithm that groups bits using mask of (2 ^ n) - 1 to extract every
digit.
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::toString):
(JSC::JSBigInt::toStringBasePowerOfTwo):
* runtime/JSBigInt.h:
2018-10-01 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Add branchIfNaN and branchIfNotNaN
https://bugs.webkit.org/show_bug.cgi?id=190122
Reviewed by Mark Lam.
Add AssemblyHelpers::{branchIfNaN, branchIfNotNaN} to make code more readable.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
(JSC::DFG::SpeculativeJIT::compileDoubleRep):
(JSC::DFG::SpeculativeJIT::getIntTypedArrayStoreOperand):
(JSC::DFG::SpeculativeJIT::compileSpread):
(JSC::DFG::SpeculativeJIT::compileNewArray):
(JSC::DFG::SpeculativeJIT::speculateRealNumber):
(JSC::DFG::SpeculativeJIT::speculateDoubleRepReal):
(JSC::DFG::SpeculativeJIT::compileNormalizeMapKey):
(JSC::DFG::SpeculativeJIT::compileHasIndexedProperty):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::purifyNaN):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::branchIfNaN):
(JSC::AssemblyHelpers::branchIfNotNaN):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitGenericContiguousPutByVal):
(JSC::JIT::emitDoubleLoad):
(JSC::JIT::emitFloatTypedArrayGetByVal):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emitGenericContiguousPutByVal):
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::createJSToWasmWrapper):
2018-10-01 Mark Lam <mark.lam@apple.com>
Function.toString() should also copy the source code Functions that are class definitions.
https://bugs.webkit.org/show_bug.cgi?id=190186
<rdar://problem/44733360>
Reviewed by Saam Barati.
Previously, if the Function is a class definition, functionProtoFuncToString()
would create a String using StringView::toStringWithoutCopying(), and use that
String to make a JSString. This is not a problem if the underlying SourceProvider
(that backs the characters in that StringView) is immortal. However, this is
not always the case in practice.
This patch fixes this issue by changing functionProtoFuncToString() to create the
String using StringView::toString() instead, which makes a copy of the underlying
characters buffer. This detaches the resultant JSString from the SourceProvider
characters buffer that it was created from, and ensure that the underlying
characters buffer of the string will be alive for the entire lifetime of the
JSString.
* runtime/FunctionPrototype.cpp:
(JSC::functionProtoFuncToString):
2018-10-01 Keith Miller <keith_miller@apple.com>
Create a RELEASE_AND_RETURN macro for ExceptionScopes
https://bugs.webkit.org/show_bug.cgi?id=190163
Reviewed by Mark Lam.
The new RELEASE_AND_RETURN does all the work for cases
where you want to return the result of some expression
without explicitly checking for an exception. This is
much like the existing RETURN_IF_EXCEPTION macro.
* dfg/DFGOperations.cpp:
(JSC::DFG::newTypedArrayWithSize):
* interpreter/Interpreter.cpp:
(JSC::eval):
* jit/JITOperations.cpp:
(JSC::getByVal):
* jsc.cpp:
(functionDollarAgentReceiveBroadcast):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setUpCall):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::varargsSetup):
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::toJSON const):
* runtime/AbstractModuleRecord.cpp:
(JSC::AbstractModuleRecord::hostResolveImportedModule):
* runtime/ArrayConstructor.cpp:
(JSC::constructArrayWithSizeQuirk):
* runtime/ArrayPrototype.cpp:
(JSC::getProperty):
(JSC::fastJoin):
(JSC::arrayProtoFuncToString):
(JSC::arrayProtoFuncToLocaleString):
(JSC::arrayProtoFuncJoin):
(JSC::arrayProtoFuncPop):
(JSC::arrayProtoPrivateFuncConcatMemcpy):
* runtime/BigIntConstructor.cpp:
(JSC::toBigInt):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::opInByVal):
* runtime/ConstructData.cpp:
(JSC::construct):
* runtime/DateConstructor.cpp:
(JSC::dateParse):
* runtime/DatePrototype.cpp:
(JSC::dateProtoFuncToPrimitiveSymbol):
* runtime/DirectArguments.h:
* runtime/ErrorConstructor.cpp:
(JSC::Interpreter::constructWithErrorConstructor):
* runtime/ErrorPrototype.cpp:
(JSC::errorProtoFuncToString):
* runtime/ExceptionScope.h:
* runtime/FunctionConstructor.cpp:
(JSC::constructFunction):
* runtime/FunctionPrototype.cpp:
(JSC::functionProtoFuncToString):
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments<Type>::defineOwnProperty):
* runtime/GetterSetter.cpp:
(JSC::callGetter):
* runtime/IntlCollatorConstructor.cpp:
(JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
* runtime/IntlCollatorPrototype.cpp:
(JSC::IntlCollatorFuncCompare):
(JSC::IntlCollatorPrototypeFuncResolvedOptions):
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::IntlDateTimeFormatFuncFormatDateTime):
(JSC::IntlDateTimeFormatPrototypeFuncFormatToParts):
(JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::IntlNumberFormatFuncFormatNumber):
(JSC::IntlNumberFormatPrototypeFuncFormatToParts):
(JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
* runtime/IntlObject.cpp:
(JSC::intlNumberOption):
* runtime/IntlObjectInlines.h:
(JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
* runtime/IntlPluralRules.cpp:
(JSC::IntlPluralRules::resolvedOptions):
* runtime/IntlPluralRulesConstructor.cpp:
(JSC::IntlPluralRulesConstructorFuncSupportedLocalesOf):
* runtime/IntlPluralRulesPrototype.cpp:
(JSC::IntlPluralRulesPrototypeFuncSelect):
(JSC::IntlPluralRulesPrototypeFuncResolvedOptions):
* runtime/JSArray.cpp:
(JSC::JSArray::defineOwnProperty):
(JSC::JSArray::put):
(JSC::JSArray::setLength):
(JSC::JSArray::unshiftCountWithAnyIndexingType):
* runtime/JSArrayBufferPrototype.cpp:
(JSC::arrayBufferProtoGetterFuncByteLength):
(JSC::sharedArrayBufferProtoGetterFuncByteLength):
* runtime/JSArrayInlines.h:
(JSC::toLength):
* runtime/JSBoundFunction.cpp:
(JSC::boundFunctionCall):
(JSC::boundFunctionConstruct):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive):
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::toIndex const):
(JSC::JSValue::toPropertyKey const):
(JSC::JSValue::get const):
(JSC::JSValue::getPropertySlot const):
(JSC::JSValue::getOwnPropertySlot const):
(JSC::JSValue::equalSlowCaseInline):
* runtime/JSDataView.cpp:
(JSC::JSDataView::put):
(JSC::JSDataView::defineOwnProperty):
* runtime/JSFunction.cpp:
(JSC::JSFunction::put):
(JSC::JSFunction::defineOwnProperty):
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayViewWithArguments):
(JSC::constructGenericTypedArrayView):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::set):
(JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::speciesConstruct):
(JSC::genericTypedArrayViewProtoFuncJoin):
(JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::put):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::decode):
(JSC::globalFuncEval):
(JSC::globalFuncProtoGetter):
* runtime/JSInternalPromise.cpp:
(JSC::JSInternalPromise::then):
* runtime/JSModuleEnvironment.cpp:
(JSC::JSModuleEnvironment::put):
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::provideFetch):
(JSC::JSModuleLoader::loadAndEvaluateModule):
(JSC::JSModuleLoader::loadModule):
(JSC::JSModuleLoader::linkAndEvaluateModule):
(JSC::JSModuleLoader::requestImportModule):
(JSC::JSModuleLoader::getModuleNamespaceObject):
(JSC::moduleLoaderRequestedModules):
* runtime/JSONObject.cpp:
(JSC::Stringifier::stringify):
(JSC::Stringifier::toJSON):
(JSC::Walker::walk):
(JSC::JSONProtoFuncStringify):
* runtime/JSObject.cpp:
(JSC::ordinarySetSlow):
(JSC::JSObject::putInlineSlow):
(JSC::JSObject::toPrimitive const):
(JSC::JSObject::hasInstance):
(JSC::JSObject::toNumber const):
(JSC::JSObject::defineOwnIndexedProperty):
(JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
(JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
(JSC::JSObject::defineOwnNonIndexProperty):
* runtime/JSObject.h:
(JSC::JSObject::get const):
* runtime/JSObjectInlines.h:
(JSC::JSObject::getPropertySlot const):
(JSC::JSObject::putInlineForJSObject):
* runtime/MapConstructor.cpp:
(JSC::constructMap):
* runtime/NativeErrorConstructor.cpp:
(JSC::Interpreter::constructWithNativeErrorConstructor):
* runtime/ObjectConstructor.cpp:
(JSC::constructObject):
(JSC::objectConstructorGetPrototypeOf):
(JSC::objectConstructorGetOwnPropertyDescriptor):
(JSC::objectConstructorGetOwnPropertyDescriptors):
(JSC::objectConstructorGetOwnPropertyNames):
(JSC::objectConstructorGetOwnPropertySymbols):
(JSC::objectConstructorKeys):
(JSC::objectConstructorDefineProperty):
(JSC::objectConstructorDefineProperties):
(JSC::objectConstructorCreate):
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncToLocaleString):
(JSC::objectProtoFuncToString):
* runtime/Operations.cpp:
(JSC::jsAddSlowCase):
* runtime/Operations.h:
(JSC::jsString):
(JSC::jsLess):
(JSC::jsLessEq):
* runtime/ParseInt.h:
(JSC::toStringView):
* runtime/ProxyConstructor.cpp:
(JSC::constructProxyObject):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::toStringName):
(JSC::performProxyGet):
(JSC::ProxyObject::performInternalMethodGetOwnProperty):
(JSC::ProxyObject::performHasProperty):
(JSC::ProxyObject::getOwnPropertySlotCommon):
(JSC::ProxyObject::performPut):
(JSC::ProxyObject::putByIndexCommon):
(JSC::performProxyCall):
(JSC::performProxyConstruct):
(JSC::ProxyObject::performDelete):
(JSC::ProxyObject::performPreventExtensions):
(JSC::ProxyObject::performIsExtensible):
(JSC::ProxyObject::performDefineOwnProperty):
(JSC::ProxyObject::performSetPrototype):
(JSC::ProxyObject::performGetPrototype):
* runtime/ReflectObject.cpp:
(JSC::reflectObjectConstruct):
(JSC::reflectObjectDefineProperty):
(JSC::reflectObjectGet):
(JSC::reflectObjectGetOwnPropertyDescriptor):
(JSC::reflectObjectGetPrototypeOf):
(JSC::reflectObjectOwnKeys):
(JSC::reflectObjectSet):
* runtime/RegExpConstructor.cpp:
(JSC::constructRegExp):
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::defineOwnProperty):
(JSC::RegExpObject::matchGlobal):
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoFuncTestFast):
(JSC::regExpProtoFuncExec):
(JSC::regExpProtoFuncToString):
* runtime/ScriptExecutable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
* runtime/SetConstructor.cpp:
(JSC::constructSet):
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::putEntry):
(JSC::SparseArrayEntry::put):
* runtime/StringConstructor.cpp:
(JSC::stringFromCharCode):
(JSC::stringFromCodePoint):
* runtime/StringObject.cpp:
(JSC::StringObject::put):
(JSC::StringObject::putByIndex):
(JSC::StringObject::defineOwnProperty):
* runtime/StringPrototype.cpp:
(JSC::jsSpliceSubstrings):
(JSC::jsSpliceSubstringsWithSeparators):
(JSC::removeUsingRegExpSearch):
(JSC::replaceUsingRegExpSearch):
(JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
(JSC::replaceUsingStringSearch):
(JSC::repeatCharacter):
(JSC::replace):
(JSC::stringProtoFuncReplaceUsingRegExp):
(JSC::stringProtoFuncReplaceUsingStringSearch):
(JSC::stringProtoFuncSplitFast):
(JSC::stringProtoFuncToLowerCase):
(JSC::stringProtoFuncToUpperCase):
(JSC::toLocaleCase):
(JSC::trimString):
(JSC::stringProtoFuncIncludes):
(JSC::builtinStringIncludesInternal):
(JSC::normalize):
(JSC::stringProtoFuncNormalize):
* runtime/SymbolPrototype.cpp:
(JSC::symbolProtoFuncToString):
(JSC::symbolProtoFuncValueOf):
* tools/JSDollarVM.cpp:
(WTF::functionWasmStreamingParserAddBytes):
(JSC::functionGetPrivateProperty):
* wasm/js/WebAssemblyCompileErrorConstructor.cpp:
(JSC::constructJSWebAssemblyCompileError):
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::constructJSWebAssemblyModule):
(JSC::WebAssemblyModuleConstructor::createModule):
* wasm/js/WebAssemblyTableConstructor.cpp:
(JSC::constructJSWebAssemblyTable):
* wasm/js/WebAssemblyWrapperFunction.cpp:
(JSC::callWebAssemblyWrapperFunction):
2018-10-01 Koby Boyango <koby.b@mce-sys.com>
[JSC] Add a JSONStringify overload that receives a JSValue space
https://bugs.webkit.org/show_bug.cgi?id=190131
Reviewed by Yusuke Suzuki.
* runtime/JSONObject.cpp:
* runtime/JSONObject.h:
2018-10-01 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r236647.
https://bugs.webkit.org/show_bug.cgi?id=190124
Breaking test stress/big-int-to-string.js (Requested by
caiolima_ on #webkit).
Reverted changeset:
"[BigInt] BigInt.proptotype.toString is broken when radix is
power of 2"
https://bugs.webkit.org/show_bug.cgi?id=190033
https://trac.webkit.org/changeset/236647
2018-10-01 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[WebAssembly] Move type conversion code of JSToWasm return type to JS wasm wrapper
https://bugs.webkit.org/show_bug.cgi?id=189498
Reviewed by Saam Barati.
To call JS-to-Wasm code we need to convert the result value from wasm function to
the JS type. Previously this is done by callWebAssemblyFunction by using swtich
over signature.returnType(). But since we know the value of `signature.returnType()`
at compiling phase, we can emit a small conversion code directly to JSToWasm glue
and remove this switch from callWebAssemblyFunction.
In JSToWasm glue code, we do not have tag registers. So we use DoNotHaveTagRegisters
in boxInt32 and boxDouble. Since boxDouble does not have DoNotHaveTagRegisters version,
we add an implementation for that.
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::boxDouble):
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::createJSToWasmWrapper):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
2018-09-30 Caio Lima <ticaiolima@gmail.com>
[BigInt] BigInt.proptotype.toString is broken when radix is power of 2
https://bugs.webkit.org/show_bug.cgi?id=190033
Reviewed by Yusuke Suzuki.
The implementation of JSBigInt::toStringToGeneric doesn't handle power
of 2 radix when JSBigInt length is >= 2. To handle such cases, we
implemented JSBigInt::toStringBasePowerOfTwo that follows the
algorithm that groups bits using mask of (2 ^ n) - 1 to extract every
digit.
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::toString):
(JSC::JSBigInt::toStringBasePowerOfTwo):
* runtime/JSBigInt.h:
2018-09-28 Caio Lima <ticaiolima@gmail.com>
[ESNext][BigInt] Implement support for "&"
https://bugs.webkit.org/show_bug.cgi?id=186228
Reviewed by Yusuke Suzuki.
This patch introduces support of BigInt into bitwise "&" operation.
We are also introducing the ValueBitAnd DFG node, that is responsible
to take care of JIT for non-Int32 operands. With the introduction of this
new node, we renamed the BitAnd node to ArithBitAnd. The ArithBitAnd
follows the behavior of ArithAdd and other arithmetic nodes, where
the Arith<op> version always results in Number (in the case of
ArithBitAnd, its is always an Int32).
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitBinaryOp):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo):
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueBitwiseOp):
(JSC::DFG::SpeculativeJIT::compileBitwiseOp):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::bitOp):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileValueBitAnd):
(JSC::FTL::DFG::LowerDFGToB3::compileArithBitAnd):
(JSC::FTL::DFG::LowerDFGToB3::compileBitAnd): Deleted.
* jit/JIT.h:
* jit/JITArithmetic.cpp:
(JSC::JIT::emitBitBinaryOpFastPath):
(JSC::JIT::emit_op_bitand):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::JSBigInt):
(JSC::JSBigInt::initialize):
(JSC::JSBigInt::createZero):
(JSC::JSBigInt::createFrom):
(JSC::JSBigInt::bitwiseAnd):
(JSC::JSBigInt::absoluteBitwiseOp):
(JSC::JSBigInt::absoluteAnd):
(JSC::JSBigInt::absoluteOr):
(JSC::JSBigInt::absoluteAndNot):
(JSC::JSBigInt::absoluteAddOne):
(JSC::JSBigInt::absoluteSubOne):
* runtime/JSBigInt.h:
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::toBigIntOrInt32 const):
2018-09-28 Mark Lam <mark.lam@apple.com>
Gardening: speculative build fix.
<rdar://problem/44869924>
Not reviewed.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::copyCompactAndLinkCode):
2018-09-28 Guillaume Emont <guijemont@igalia.com>
[JSC] [Armv7] Add a copy function argument to MacroAssemblerARMv7::link() and pass it down to the assembler's linking functions.
https://bugs.webkit.org/show_bug.cgi?id=190080
Reviewed by Mark Lam.
* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::link):
(JSC::ARMv7Assembler::linkJumpT1):
(JSC::ARMv7Assembler::linkJumpT2):
(JSC::ARMv7Assembler::linkJumpT3):
(JSC::ARMv7Assembler::linkJumpT4):
(JSC::ARMv7Assembler::linkConditionalJumpT4):
(JSC::ARMv7Assembler::linkBX):
(JSC::ARMv7Assembler::linkConditionalBX):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::link):
2018-09-27 Saam barati <sbarati@apple.com>
Verify the contents of AssemblerBuffer on arm64e
https://bugs.webkit.org/show_bug.cgi?id=190057
<rdar://problem/38916630>
Reviewed by Mark Lam.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::ARM64Assembler):
(JSC::ARM64Assembler::fillNops):
(JSC::ARM64Assembler::link):
(JSC::ARM64Assembler::linkJumpOrCall):
(JSC::ARM64Assembler::linkCompareAndBranch):
(JSC::ARM64Assembler::linkConditionalBranch):
(JSC::ARM64Assembler::linkTestAndBranch):
(JSC::ARM64Assembler::unlinkedCode): Deleted.
* assembler/ARMAssembler.h:
(JSC::ARMAssembler::fillNops):
* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::unlinkedCode): Deleted.
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::emitNops):
(JSC::AbstractMacroAssembler::AbstractMacroAssembler):
* assembler/AssemblerBuffer.h:
(JSC::ARM64EHash::ARM64EHash):
(JSC::ARM64EHash::update):
(JSC::ARM64EHash::hash const):
(JSC::ARM64EHash::randomSeed const):
(JSC::AssemblerBuffer::AssemblerBuffer):
(JSC::AssemblerBuffer::putShort):
(JSC::AssemblerBuffer::putIntUnchecked):
(JSC::AssemblerBuffer::putInt):
(JSC::AssemblerBuffer::hash const):
(JSC::AssemblerBuffer::data const):
(JSC::AssemblerBuffer::putIntegralUnchecked):
(JSC::AssemblerBuffer::append): Deleted.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::copyCompactAndLinkCode):
* assembler/MIPSAssembler.h:
(JSC::MIPSAssembler::fillNops):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::jumpsToLink):
(JSC::MacroAssemblerARM64::link):
(JSC::MacroAssemblerARM64::unlinkedCode): Deleted.
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::jumpsToLink):
(JSC::MacroAssemblerARMv7::unlinkedCode): Deleted.
* assembler/X86Assembler.h:
(JSC::X86Assembler::fillNops):
2018-09-27 Mark Lam <mark.lam@apple.com>
ByValInfo should not use integer offsets.
https://bugs.webkit.org/show_bug.cgi?id=190070
<rdar://problem/44803430>
Reviewed by Saam Barati.
Also moved some fields around to allow the ByValInfo struct to be more densely packed.
* bytecode/ByValInfo.h:
(JSC::ByValInfo::ByValInfo):
* jit/JIT.cpp:
(JSC::JIT::link):
* jit/JITOpcodes.cpp:
(JSC::JIT::privateCompileHasIndexedProperty):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::privateCompileHasIndexedProperty):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::privateCompileGetByVal):
(JSC::JIT::privateCompileGetByValWithCachedId):
(JSC::JIT::privateCompilePutByVal):
(JSC::JIT::privateCompilePutByValWithCachedId):
2018-09-27 Saam barati <sbarati@apple.com>
DFG::OSRExit::m_patchableCodeOffset should not be an int
https://bugs.webkit.org/show_bug.cgi?id=190066
<rdar://problem/39498244>
Reviewed by Mark Lam.
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::linkOSRExits):
(JSC::DFG::JITCompiler::link):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::codeLocationForRepatch const):
(JSC::DFG::OSRExit::compileOSRExit):
(JSC::DFG::OSRExit::setPatchableCodeOffset): Deleted.
(JSC::DFG::OSRExit::getPatchableCodeOffsetAsJump const): Deleted.
(JSC::DFG::OSRExit::correctJump): Deleted.
* dfg/DFGOSRExit.h:
* dfg/DFGOSRExitCompilationInfo.h:
2018-09-27 Saam barati <sbarati@apple.com>
Don't use int offsets in StructureStubInfo
https://bugs.webkit.org/show_bug.cgi?id=190064
<rdar://problem/44784719>
Reviewed by Mark Lam.
* bytecode/InlineAccess.cpp:
(JSC::linkCodeInline):
* bytecode/StructureStubInfo.h:
(JSC::StructureStubInfo::slowPathCallLocation):
(JSC::StructureStubInfo::doneLocation):
(JSC::StructureStubInfo::slowPathStartLocation):
* jit/JITInlineCacheGenerator.cpp:
(JSC::JITInlineCacheGenerator::finalize):
2018-09-27 Mark Lam <mark.lam@apple.com>
DFG::OSREntry::m_machineCodeOffset should be a CodeLocation.
https://bugs.webkit.org/show_bug.cgi?id=190054
<rdar://problem/44803543>
Reviewed by Saam Barati.
* dfg/DFGJITCode.h:
(JSC::DFG::JITCode::appendOSREntryData):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::noticeOSREntry):
* dfg/DFGOSREntry.cpp:
(JSC::DFG::OSREntryData::dumpInContext const):
(JSC::DFG::prepareOSREntry):
* dfg/DFGOSREntry.h:
* runtime/JSCPtrTag.h:
2018-09-27 Mark Lam <mark.lam@apple.com>
JITMathIC should not use integer offsets into machine code.
https://bugs.webkit.org/show_bug.cgi?id=190030
<rdar://problem/44803307>
Reviewed by Saam Barati.
We'll replace them with CodeLocation smart pointers instead.
* jit/JITMathIC.h:
(JSC::isProfileEmpty):
2018-09-26 Mark Lam <mark.lam@apple.com>
Options::useSeparatedWXHeap() should always be false when ENABLE(FAST_JIT_PERMISSIONS) && CPU(ARM64E).
https://bugs.webkit.org/show_bug.cgi?id=190022
<rdar://problem/44800928>
Reviewed by Saam Barati.
* jit/ExecutableAllocator.cpp:
(JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
(JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
* jit/ExecutableAllocator.h:
(JSC::performJITMemcpy):
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
2018-09-26 Mark Lam <mark.lam@apple.com>
Assert that performJITMemcpy() is always called with instruction size aligned addresses on ARM64.
https://bugs.webkit.org/show_bug.cgi?id=190016
<rdar://problem/44802875>
Reviewed by Saam Barati.
Also assert in performJITMemcpy() that the entire buffer to be copied will fit in
JIT memory.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::fillNops):
(JSC::ARM64Assembler::replaceWithVMHalt):
(JSC::ARM64Assembler::replaceWithJump):
(JSC::ARM64Assembler::replaceWithLoad):
(JSC::ARM64Assembler::replaceWithAddressComputation):
(JSC::ARM64Assembler::setPointer):
(JSC::ARM64Assembler::repatchInt32):
(JSC::ARM64Assembler::repatchCompact):
(JSC::ARM64Assembler::linkJumpOrCall):
(JSC::ARM64Assembler::linkCompareAndBranch):
(JSC::ARM64Assembler::linkConditionalBranch):
(JSC::ARM64Assembler::linkTestAndBranch):
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::copyCompactAndLinkCode):
(JSC::LinkBuffer::linkCode):
* jit/ExecutableAllocator.h:
(JSC::performJITMemcpy):
2018-09-25 Keith Miller <keith_miller@apple.com>
Move Symbol API to SPI
https://bugs.webkit.org/show_bug.cgi?id=189946
Reviewed by Michael Saboff.
Some of the property access methods on JSValue needed to be moved
to a category so that SPI overloads don't result in a compiler
error for internal users.
Additionally, this patch does not move the new enum entry for
Symbols in the JSType enumeration.
* API/JSObjectRef.h:
* API/JSObjectRefPrivate.h:
* API/JSValue.h:
* API/JSValuePrivate.h:
* API/JSValueRef.h:
2018-09-26 Keith Miller <keith_miller@apple.com>
We should zero unused property storage when rebalancing array storage.
https://bugs.webkit.org/show_bug.cgi?id=188151
Reviewed by Michael Saboff.
In unshiftCountSlowCase we sometimes will move property storage to the right even when net adding elements.
This can happen because we "balance" the pre/post-capacity in that code so we need to zero the unused
property storage.
* runtime/JSArray.cpp:
(JSC::JSArray::unshiftCountSlowCase):
2018-09-26 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Unreviewed, add scope verification handling
https://bugs.webkit.org/show_bug.cgi?id=189780
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncIndexOf):
(JSC::arrayProtoFuncLastIndexOf):
2018-09-26 Koby Boyango <koby.b@mce.systems>
[JSC] offlineasm parser should handle CRLF in asm files
https://bugs.webkit.org/show_bug.cgi?id=189949
Reviewed by Mark Lam.
* offlineasm/parser.rb:
2018-09-20 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Optimize Array#lastIndexOf
https://bugs.webkit.org/show_bug.cgi?id=189780
Reviewed by Saam Barati.
Optimize Array#lastIndexOf as the same to Array#indexOf. We add a fast path
for JSArray with contiguous storage.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncLastIndexOf):
2018-09-25 Saam Barati <sbarati@apple.com>
Calls to baselineCodeBlockForOriginAndBaselineCodeBlock in operationMaterializeObjectInOSR should actually pass in the baseline CodeBlock
https://bugs.webkit.org/show_bug.cgi?id=189940
<rdar://problem/43640987>
Reviewed by Mark Lam.
We were calling baselineCodeBlockForOriginAndBaselineCodeBlock with the FTL
CodeBlock. There is nothing semantically wrong with doing that (except for
poor naming), however, the poor naming here led us to make a real semantic
mistake. We wanted the baseline CodeBlock's constant pool, but we were
accessing the FTL CodeBlock's constant pool accidentally. We need to
access the baseline CodeBlock's constant pool when we update the NewArrayBuffer
constant value.
* bytecode/InlineCallFrame.h:
(JSC::baselineCodeBlockForOriginAndBaselineCodeBlock):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
2018-09-25 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Stricter block syntax in generated ObjC protocol interfaces
https://bugs.webkit.org/show_bug.cgi?id=189962
<rdar://problem/44648287>
Reviewed by Brian Burg.
* inspector/scripts/codegen/generate_objc_header.py:
(ObjCHeaderGenerator._callback_block_for_command):
If there are no return parameters include "void" in the block signature.
* inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/generic/expected/domain-availability.json-result:
* inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/generic/expected/worker-supported-domains.json-result:
* inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result:
Rebaseline test results.
2018-09-24 Joseph Pecoraro <pecoraro@apple.com>
Remove AUTHORS and THANKS files which are stale
https://bugs.webkit.org/show_bug.cgi?id=189941
Reviewed by Darin Adler.
Included mentions below so their names are still in ChangeLogs.
* AUTHORS: Removed.
Harri Porten (porten@kde.org) and Peter Kelly (pmk@post.com).
These authors remain mentioned in copyrights in source files.
* THANKS: Removed.
Richard Moore <rich@kde.org> - for filling the Math object with some life
Daegeun Lee <realking@mizi.com> - for pointing out some bugs and providing much code for the String and Date object.
Marco Pinelli <pinmc@libero.it> - for his patches
Christian Kirsch <ck@held.mind.de> - for his contribution to the Date object
2018-09-24 Fujii Hironori <Hironori.Fujii@sony.com>
Rename WTF_COMPILER_GCC_OR_CLANG to WTF_COMPILER_GCC_COMPATIBLE
https://bugs.webkit.org/show_bug.cgi?id=189733
Reviewed by Michael Catanzaro.
* assembler/ARM64Assembler.h:
* assembler/ARMAssembler.h:
(JSC::ARMAssembler::cacheFlush):
* assembler/MacroAssemblerARM.cpp:
(JSC::isVFPPresent):
* assembler/MacroAssemblerARM64.cpp:
* assembler/MacroAssemblerARMv7.cpp:
* assembler/MacroAssemblerMIPS.cpp:
* assembler/MacroAssemblerX86Common.cpp:
* heap/HeapCell.cpp:
* heap/HeapCell.h:
* jit/HostCallReturnValue.h:
* jit/JIT.h:
* jit/JITOperations.cpp:
* jit/ThunkGenerators.cpp:
* runtime/ArrayConventions.cpp:
(JSC::clearArrayMemset):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::digitDiv):
2018-09-24 Saam Barati <sbarati@apple.com>
Array.prototype.indexOf fast path needs to ensure the length is still valid after performing effects
https://bugs.webkit.org/show_bug.cgi?id=189922
<rdar://problem/44651275>
Reviewed by Mark Lam.
The implementation was first getting the length to iterate up to,
then getting the starting index. However, getting the starting
index may perform effects. e.g, it could change the length of the
array. This changes it so we verify the length is still valid.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncIndexOf):
2018-09-24 Tadeu Zagallo <tzagallo@apple.com>
offlineasm: fix macro scoping
https://bugs.webkit.org/show_bug.cgi?id=189902
Reviewed by Mark Lam.
In the code below, the reference to `f` in `g`, which should refer to
the outer macro definition will instead refer to the f argument of the
anonymous macro passed to `g`. That leads to this code failing to
compile (f expected 0 args but got 1).
```
macro f(x)
move x, t0
end
macro g(fn)
fn(macro () f(42) end)
end
g(macro(f) f() end)
```
* offlineasm/ast.rb:
* offlineasm/transform.rb:
2018-09-24 Tadeu Zagallo <tzagallo@apple.com>
Add forEach method for iterating CodeBlock's ValueProfiles
https://bugs.webkit.org/show_bug.cgi?id=189897
Reviewed by Mark Lam.
Add method to abstract how we find ValueProfiles in a CodeBlock in
preparation for https://bugs.webkit.org/show_bug.cgi?id=189785, when
ValueProfiles will be stored in the MetadataTable.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
(JSC::CodeBlock::updateAllValueProfilePredictions):
(JSC::CodeBlock::shouldOptimizeNow):
(JSC::CodeBlock::dumpValueProfiles):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::forEachValueProfile):
(JSC::CodeBlock::numberOfArgumentValueProfiles):
(JSC::CodeBlock::valueProfileForArgument):
(JSC::CodeBlock::numberOfValueProfiles):
(JSC::CodeBlock::valueProfile):
(JSC::CodeBlock::totalNumberOfValueProfiles): Deleted.
(JSC::CodeBlock::getFromAllValueProfiles): Deleted.
* tools/HeapVerifier.cpp:
(JSC::HeapVerifier::validateJSCell):
2018-09-24 Saam barati <sbarati@apple.com>
ArgumentsEliminationPhase should snip basic blocks after proven OSR exits
https://bugs.webkit.org/show_bug.cgi?id=189682
<rdar://problem/43557315>
Reviewed by Mark Lam.
Otherwise, if we have code like this:
```
a: Arguments
b: GetButterfly(@a)
c: ForceExit
d: GetArrayLength(@a, @b)
```
it will get transformed into this invalid DFG IR:
```
a: PhantomArguments
b: Check(@a)
c: ForceExit
d: GetArrayLength(@a, @b)
```
And we will fail DFG validation since @b does not have a result.
The fix is to just remove all nodes after the ForceExit and plant an
Unreachable after it. So the above code program will now turn into this:
```
a: PhantomArguments
b: Check(@a)
c: ForceExit
e: Unreachable
```
* dfg/DFGArgumentsEliminationPhase.cpp:
2018-09-22 Saam barati <sbarati@apple.com>
The sampling should not use Strong<CodeBlock> in its machineLocation field
https://bugs.webkit.org/show_bug.cgi?id=189319
Reviewed by Filip Pizlo.
The sampling profiler has a CLI mode where we gather information about inline
call frames. That data structure was using a Strong<CodeBlock>. We were
constructing this Strong<CodeBlock> during GC concurrently to processing all
the Strong handles. This is a bug since we end up corrupting that data
structure. This patch fixes this by just making this data structure use the
sampling profiler's mechanism for holding onto and properly visiting heap pointers.
* inspector/agents/InspectorScriptProfilerAgent.cpp:
(Inspector::InspectorScriptProfilerAgent::trackingComplete):
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::processUnverifiedStackTraces):
(JSC::SamplingProfiler::reportTopFunctions):
(JSC::SamplingProfiler::reportTopBytecodes):
These CLI helpers needed a DeferGC otherwise we may end up deadlocking when we
cause a GC to happen while already holding the sampling profiler's
lock.
2018-09-21 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Enable LLInt ASM interpreter on X64 and ARM64 in non JIT configuration
https://bugs.webkit.org/show_bug.cgi?id=189778
Reviewed by Keith Miller.
LLInt ASM interpreter is 2x and 15% faster than CLoop interpreter on
Linux and macOS respectively. We would like to enable it for non JIT
configurations in X86_64 and ARM64.
This patch enables LLInt for non JIT builds in X86_64 and ARM64 architectures.
Previously, we switch LLInt ASM interpreter and CLoop by using ENABLE(JIT)
configuration. But it is wrong in the new scenario since we have a build
configuration that uses LLInt ASM interpreter and JIT is disabled. We introduce
ENABLE(C_LOOP) option, which represents that we use CLoop. And we replace
ENABLE(JIT) with ENABLE(C_LOOP) if the previous ENABLE(JIT) is essentially just
related to LLInt ASM interpreter and not related to JIT.
We also replace some ENABLE(JIT) configurations with ENABLE(ASSEMBLER).
ENABLE(ASSEMBLER) is now enabled even if we disable JIT since MacroAssembler
has machine register information that is used in LLInt ASM interpreter.
* API/tests/PingPongStackOverflowTest.cpp:
(testPingPongStackOverflow):
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/MaxFrameExtentForSlowPathCall.h:
* bytecode/CallReturnOffsetToBytecodeOffset.h: Removed. It is no longer used.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::calleeSaveRegisters const):
(JSC::CodeBlock::numberOfLLIntBaselineCalleeSaveRegisters):
(JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters):
(JSC::CodeBlock::calleeSaveSpaceAsVirtualRegisters):
* bytecode/Opcode.h:
(JSC::padOpcodeName):
* heap/Heap.cpp:
(JSC::Heap::gatherJSStackRoots):
(JSC::Heap::stopThePeriphery):
* interpreter/CLoopStack.cpp:
* interpreter/CLoopStack.h:
* interpreter/CLoopStackInlines.h:
* interpreter/EntryFrame.h:
* interpreter/Interpreter.cpp:
(JSC::Interpreter::Interpreter):
(JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
* interpreter/Interpreter.h:
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::calleeSaveRegisters):
* interpreter/VMEntryRecord.h:
* jit/ExecutableAllocator.h:
* jit/FPRInfo.h:
(WTF::printInternal):
* jit/GPRInfo.cpp:
* jit/GPRInfo.h:
(WTF::printInternal):
* jit/HostCallReturnValue.cpp:
(JSC::getHostCallReturnValueWithExecState): Moved. They are used in LLInt ASM interpreter too.
* jit/HostCallReturnValue.h:
* jit/JITOperations.cpp:
(JSC::getHostCallReturnValueWithExecState): Deleted.
* jit/JITOperationsMSVC64.cpp:
* jit/Reg.cpp:
* jit/Reg.h:
* jit/RegisterAtOffset.cpp:
* jit/RegisterAtOffset.h:
* jit/RegisterAtOffsetList.cpp:
* jit/RegisterAtOffsetList.h:
* jit/RegisterMap.h:
* jit/RegisterSet.cpp:
* jit/RegisterSet.h:
* jit/TempRegisterSet.cpp:
* jit/TempRegisterSet.h:
* llint/LLIntCLoop.cpp:
* llint/LLIntCLoop.h:
* llint/LLIntData.cpp:
(JSC::LLInt::initialize):
(JSC::LLInt::Data::performAssertions):
* llint/LLIntData.h:
* llint/LLIntOfflineAsmConfig.h:
* llint/LLIntOpcode.h:
* llint/LLIntPCRanges.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LLIntThunks.cpp:
* llint/LowLevelInterpreter.cpp:
* llint/LowLevelInterpreter.h:
* runtime/JSCJSValue.h:
* runtime/MachineContext.h:
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::processUnverifiedStackTraces): Enable SamplingProfiler
for LLInt ASM interpreter with non JIT configuration.
* runtime/TestRunnerUtils.cpp:
(JSC::optimizeNextInvocation):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::getHostFunction):
(JSC::VM::updateSoftReservedZoneSize):
(JSC::sanitizeStackForVM):
(JSC::VM::committedStackByteCount):
* runtime/VM.h:
* runtime/VMInlines.h:
(JSC::VM::ensureStackCapacityFor):
(JSC::VM::isSafeToRecurseSoft const):
2018-09-21 Keith Miller <keith_miller@apple.com>
Add Promise SPI
https://bugs.webkit.org/show_bug.cgi?id=189809
Reviewed by Saam Barati.
The Patch adds new SPI to create promises. It's mostly SPI because
I want to see how internal users react to it before we make it
public.
This patch adds a couple of new Obj-C SPI methods. The first
creates a new promise using the same API that JS does where the
user provides an executor callback. If an exception is raised
in/to that callback the promise is automagically rejected. The
other methods create a pre-resolved or rejected promise as this
appears to be a common way to initialize a promise.
I was also considering adding a second version of executor API
where it would catch specific Obj-C exceptions. This would work by
taking a Class paramter and checking isKindOfClass: on the
exception. I decided against this as nothing else in our API
handles Obj-C exceptions. I'm pretty sure the VM will end up in a
corrupt state if an Obj-C exception unwinds through JS frames.
This patch adds a new C function that will create a "deferred"
promise. A deferred promise is a style of creating promise/futures
where the resolve and reject functions are passed as outputs of a
function. I went with this style for the C SPI because we don't have
any concept of forwarding exceptions in the C API.
In order to make the C API work I refactored a bit of the promise code
so that we can call a static method on JSDeferredPromise and just get
the components without allocating an extra cell wrapper.
* API/JSContext.mm:
(+[JSContext currentCallee]):
* API/JSObjectRef.cpp:
(JSObjectMakeDeferredPromise):
* API/JSObjectRefPrivate.h:
* API/JSValue.mm:
(+[JSValue valueWithNewPromiseInContext:fromExecutor:]):
(+[JSValue valueWithNewPromiseResolvedWithResult:inContext:]):
(+[JSValue valueWithNewPromiseRejectedWithReason:inContext:]):
* API/JSValuePrivate.h: Added.
* API/JSVirtualMachine.mm:
* API/JSVirtualMachinePrivate.h:
* API/tests/testapi.c:
(main):
* API/tests/testapi.cpp:
(APIContext::operator JSC::ExecState*):
(TestAPI::failed const):
(TestAPI::check):
(TestAPI::basicSymbol):
(TestAPI::symbolsTypeof):
(TestAPI::symbolsGetPropertyForKey):
(TestAPI::symbolsSetPropertyForKey):
(TestAPI::symbolsHasPropertyForKey):
(TestAPI::symbolsDeletePropertyForKey):
(TestAPI::promiseResolveTrue):
(TestAPI::promiseRejectTrue):
(testCAPIViaCpp):
(TestAPI::run): Deleted.
* API/tests/testapi.mm:
(testObjectiveCAPIMain):
(promiseWithExecutor):
(promiseRejectOnJSException):
(promiseCreateResolved):
(promiseCreateRejected):
(parallelPromiseResolveTest):
(testObjectiveCAPI):
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/JSInternalPromiseDeferred.cpp:
(JSC::JSInternalPromiseDeferred::create):
* runtime/JSPromise.h:
* runtime/JSPromiseConstructor.cpp:
(JSC::constructPromise):
* runtime/JSPromiseDeferred.cpp:
(JSC::JSPromiseDeferred::createDeferredData):
(JSC::JSPromiseDeferred::create):
(JSC::JSPromiseDeferred::finishCreation):
(JSC::newPromiseCapability): Deleted.
* runtime/JSPromiseDeferred.h:
(JSC::JSPromiseDeferred::promise const):
(JSC::JSPromiseDeferred::resolve const):
(JSC::JSPromiseDeferred::reject const):
2018-09-21 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r236359.
Broke the Windows build.
Reverted changeset:
"Add Promise SPI"
https://bugs.webkit.org/show_bug.cgi?id=189809
https://trac.webkit.org/changeset/236359
2018-09-21 Mark Lam <mark.lam@apple.com>
JSRopeString::resolveRope() wrongly assumes that tryGetValue() passes it a valid ExecState.
https://bugs.webkit.org/show_bug.cgi?id=189855
<rdar://problem/44680181>
Reviewed by Filip Pizlo.
tryGetValue() always passes a nullptr to JSRopeString::resolveRope() for the
ExecState* argument. This is intentional so that resolveRope() does not throw
in the event of an OutOfMemory error. Hence, JSRopeString::resolveRope() should
get the VM from the cell instead of via the ExecState.
Also removed an obsolete and unused field in JSString.
* runtime/JSString.cpp:
(JSC::JSRopeString::resolveRope const):
(JSC::JSRopeString::outOfMemory const):
* runtime/JSString.h:
(JSC::JSString::tryGetValue const):
2018-09-21 Michael Saboff <msaboff@apple.com>
Add functions to measure memory footprint to JSC
https://bugs.webkit.org/show_bug.cgi?id=189768
Reviewed by Saam Barati.
Rolling this back in again.
Provide system memory metrics for the current process to aid in memory reduction measurement and
tuning using native JS tests.
* jsc.cpp:
(MemoryFootprint::now):
(MemoryFootprint::resetPeak):
(GlobalObject::finishCreation):
(JSCMemoryFootprint::JSCMemoryFootprint):
(JSCMemoryFootprint::createStructure):
(JSCMemoryFootprint::create):
(JSCMemoryFootprint::finishCreation):
(JSCMemoryFootprint::addProperty):
(functionResetMemoryPeak):
2018-09-21 Keith Miller <keith_miller@apple.com>
Add Promise SPI
https://bugs.webkit.org/show_bug.cgi?id=189809
Reviewed by Saam Barati.
The Patch adds new SPI to create promises. It's mostly SPI because
I want to see how internal users react to it before we make it
public.
This patch adds a couple of new Obj-C SPI methods. The first
creates a new promise using the same API that JS does where the
user provides an executor callback. If an exception is raised
in/to that callback the promise is automagically rejected. The
other methods create a pre-resolved or rejected promise as this
appears to be a common way to initialize a promise.
I was also considering adding a second version of executor API
where it would catch specific Obj-C exceptions. This would work by
taking a Class paramter and checking isKindOfClass: on the
exception. I decided against this as nothing else in our API
handles Obj-C exceptions. I'm pretty sure the VM will end up in a
corrupt state if an Obj-C exception unwinds through JS frames.
This patch adds a new C function that will create a "deferred"
promise. A deferred promise is a style of creating promise/futures
where the resolve and reject functions are passed as outputs of a
function. I went with this style for the C SPI because we don't have
any concept of forwarding exceptions in the C API.
In order to make the C API work I refactored a bit of the promise code
so that we can call a static method on JSDeferredPromise and just get
the components without allocating an extra cell wrapper.
* API/JSContext.mm:
(+[JSContext currentCallee]):
* API/JSObjectRef.cpp:
(JSObjectMakeDeferredPromise):
* API/JSObjectRefPrivate.h:
* API/JSValue.mm:
(+[JSValue valueWithNewPromiseInContext:fromExecutor:]):
(+[JSValue valueWithNewPromiseResolvedWithResult:inContext:]):
(+[JSValue valueWithNewPromiseRejectedWithReason:inContext:]):
* API/JSValuePrivate.h: Added.
* API/JSVirtualMachine.mm:
* API/JSVirtualMachinePrivate.h:
* API/tests/testapi.c:
(main):
* API/tests/testapi.cpp:
(APIContext::operator JSC::ExecState*):
(TestAPI::failed const):
(TestAPI::check):
(TestAPI::basicSymbol):
(TestAPI::symbolsTypeof):
(TestAPI::symbolsGetPropertyForKey):
(TestAPI::symbolsSetPropertyForKey):
(TestAPI::symbolsHasPropertyForKey):
(TestAPI::symbolsDeletePropertyForKey):
(TestAPI::promiseResolveTrue):
(TestAPI::promiseRejectTrue):
(testCAPIViaCpp):
(TestAPI::run): Deleted.
* API/tests/testapi.mm:
(testObjectiveCAPIMain):
(promiseWithExecutor):
(promiseRejectOnJSException):
(promiseCreateResolved):
(promiseCreateRejected):
(parallelPromiseResolveTest):
(testObjectiveCAPI):
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/JSInternalPromiseDeferred.cpp:
(JSC::JSInternalPromiseDeferred::create):
* runtime/JSPromise.h:
* runtime/JSPromiseConstructor.cpp:
(JSC::constructPromise):
* runtime/JSPromiseDeferred.cpp:
(JSC::JSPromiseDeferred::createDeferredData):
(JSC::JSPromiseDeferred::create):
(JSC::JSPromiseDeferred::finishCreation):
(JSC::newPromiseCapability): Deleted.
* runtime/JSPromiseDeferred.h:
(JSC::JSPromiseDeferred::promise const):
(JSC::JSPromiseDeferred::resolve const):
(JSC::JSPromiseDeferred::reject const):
2018-09-21 Truitt Savell <tsavell@apple.com>
Rebaseline tests after changes in https://trac.webkit.org/changeset/236321/webkit
https://bugs.webkit.org/show_bug.cgi?id=156674
Unreviewed Test Gardening
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
2018-09-21 Mike Gorse <mgorse@suse.com>
Build tools should work when the /usr/bin/python is python3
https://bugs.webkit.org/show_bug.cgi?id=156674
Reviewed by Michael Catanzaro.
* Scripts/cssmin.py:
* Scripts/generate-js-builtins.py:
(do_open):
(generate_bindings_for_builtins_files):
* Scripts/generateIntlCanonicalizeLanguage.py:
* Scripts/jsmin.py:
(JavascriptMinify.minify.write):
(JavascriptMinify):
(JavascriptMinify.minify):
* Scripts/make-js-file-arrays.py:
(chunk):
(main):
* Scripts/wkbuiltins/__init__.py:
* Scripts/wkbuiltins/builtins_generate_combined_header.py:
(generate_section_for_global_private_code_name_macro):
* Scripts/wkbuiltins/builtins_generate_internals_wrapper_header.py:
(BuiltinsInternalsWrapperHeaderGenerator.__init__):
* Scripts/wkbuiltins/builtins_generate_internals_wrapper_implementation.py:
(BuiltinsInternalsWrapperImplementationGenerator.__init__):
* Scripts/wkbuiltins/builtins_model.py:
(BuiltinFunction.__lt__):
(BuiltinsCollection.copyrights):
(BuiltinsCollection._parse_functions):
* disassembler/udis86/ud_opcode.py:
(UdOpcodeTables.pprint.printWalk):
* generate-bytecode-files:
* inspector/scripts/codegen/__init__.py:
* inspector/scripts/codegen/cpp_generator.py:
* inspector/scripts/codegen/generate_cpp_alternate_backend_dispatcher_header.py:
(CppAlternateBackendDispatcherHeaderGenerator.generate_output):
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
(CppBackendDispatcherHeaderGenerator.domains_to_generate):
(CppBackendDispatcherHeaderGenerator.generate_output):
(CppBackendDispatcherHeaderGenerator._generate_dispatcher_declarations_for_domain):
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
(CppBackendDispatcherImplementationGenerator.domains_to_generate):
(CppBackendDispatcherImplementationGenerator.generate_output):
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
(CppFrontendDispatcherHeaderGenerator.domains_to_generate):
(CppFrontendDispatcherHeaderGenerator.generate_output):
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
(CppFrontendDispatcherImplementationGenerator.domains_to_generate):
(CppFrontendDispatcherImplementationGenerator.generate_output):
* inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
(CppProtocolTypesHeaderGenerator.generate_output):
(CppProtocolTypesHeaderGenerator._generate_forward_declarations):
* inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
(CppProtocolTypesImplementationGenerator.generate_output):
(CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain):
(CppProtocolTypesImplementationGenerator._generate_enum_mapping_and_conversion_methods):
(CppProtocolTypesImplementationGenerator._generate_open_field_names):
(CppProtocolTypesImplementationGenerator._generate_builders_for_domain):
(CppProtocolTypesImplementationGenerator._generate_assertion_for_object_declaration):
* inspector/scripts/codegen/generate_js_backend_commands.py:
(JSBackendCommandsGenerator.should_generate_domain):
(JSBackendCommandsGenerator.domains_to_generate):
(JSBackendCommandsGenerator.generate_output):
(JSBackendCommandsGenerator.generate_domain):
* inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
(ObjCBackendDispatcherHeaderGenerator.domains_to_generate):
(ObjCBackendDispatcherHeaderGenerator.generate_output):
* inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
(ObjCBackendDispatcherImplementationGenerator.domains_to_generate):
(ObjCBackendDispatcherImplementationGenerator.generate_output):
(ObjCBackendDispatcherImplementationGenerator._generate_success_block_for_command):
* inspector/scripts/codegen/generate_objc_configuration_header.py:
* inspector/scripts/codegen/generate_objc_configuration_implementation.py:
* inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
(ObjCFrontendDispatcherImplementationGenerator.domains_to_generate):
(ObjCFrontendDispatcherImplementationGenerator.generate_output):
(ObjCFrontendDispatcherImplementationGenerator._generate_event):
* inspector/scripts/codegen/generate_objc_header.py:
(ObjCHeaderGenerator.generate_output):
(ObjCHeaderGenerator._generate_type_interface):
* inspector/scripts/codegen/generate_objc_internal_header.py:
(ObjCInternalHeaderGenerator.generate_output):
* inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py:
(ObjCProtocolTypeConversionsHeaderGenerator.domains_to_generate):
(ObjCProtocolTypeConversionsHeaderGenerator.generate_output):
* inspector/scripts/codegen/generate_objc_protocol_type_conversions_implementation.py:
(ObjCProtocolTypeConversionsImplementationGenerator.domains_to_generate):
* inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
(ObjCProtocolTypesImplementationGenerator.domains_to_generate):
(ObjCProtocolTypesImplementationGenerator.generate_output):
(ObjCProtocolTypesImplementationGenerator.generate_type_implementation):
(ObjCProtocolTypesImplementationGenerator._generate_init_method_for_required_members):
* inspector/scripts/codegen/generator.py:
(Generator.non_supplemental_domains):
(Generator.open_fields):
(Generator.calculate_types_requiring_shape_assertions):
(Generator._traverse_and_assign_enum_values):
(Generator.stylized_name_for_enum_value):
* inspector/scripts/codegen/models.py:
(find_duplicates):
* inspector/scripts/codegen/objc_generator.py:
* wasm/generateWasm.py:
(opcodeIterator):
* yarr/generateYarrCanonicalizeUnicode:
* yarr/generateYarrUnicodePropertyTables.py:
* yarr/hasher.py:
(stringHash):
2018-09-21 Tomas Popela <tpopela@redhat.com>
[ARM] Build broken on armv7hl after r235517
https://bugs.webkit.org/show_bug.cgi?id=189831
Reviewed by Yusuke Suzuki.
Add missing implementation of patchebleBranch8() for traditional ARM.
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::patchableBranch8):
2018-09-20 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r236293.
Internal build still broken.
Reverted changeset:
"Add functions to measure memory footprint to JSC"
https://bugs.webkit.org/show_bug.cgi?id=189768
https://trac.webkit.org/changeset/236293
2018-09-20 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Heap::reportExtraMemoryVisited shows contention if we have many JSString
https://bugs.webkit.org/show_bug.cgi?id=189558
Reviewed by Mark Lam.
When running web-tooling-benchmark postcss test on Linux JSCOnly port, we get the following result in `perf report`.
10.95% AutomaticThread libJavaScriptCore.so.1.0.0 [.] JSC::Heap::reportExtraMemoryVisited
This is because postcss produces bunch of JSString, which require reportExtraMemoryVisited calls in JSString::visitChildren.
And since reportExtraMemoryVisited attempts to update atomic counter, if we have bunch of marking threads, it becomes super contended.
This patch reduces the frequency of updating the atomic counter. Each SlotVisitor has per-SlotVisitor m_extraMemorySize counter.
And we propagate this value to the global atomic counter when rebalance happens.
We also reduce HeapCell::heap() access by using `vm.heap`.
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::didStartMarking):
(JSC::SlotVisitor::propagateExternalMemoryVisitedIfNecessary):
(JSC::SlotVisitor::drain):
(JSC::SlotVisitor::performIncrementOfDraining):
* heap/SlotVisitor.h:
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::reportExtraMemoryVisited):
* runtime/JSString.cpp:
(JSC::JSRopeString::resolveRopeToAtomicString const):
(JSC::JSRopeString::resolveRope const):
* runtime/JSString.h:
(JSC::JSString::finishCreation):
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::finishCreation):
* wasm/js/JSWebAssemblyMemory.cpp:
(JSC::JSWebAssemblyMemory::finishCreation):
2018-09-20 Michael Saboff <msaboff@apple.com>
Add functions to measure memory footprint to JSC
https://bugs.webkit.org/show_bug.cgi?id=189768
Reviewed by Saam Barati.
Rolling this back in.
Provide system memory metrics for the current process to aid in memory reduction measurement and
tuning using native JS tests.
* jsc.cpp:
(MemoryFootprint::now):
(MemoryFootprint::resetPeak):
(GlobalObject::finishCreation):
(JSCMemoryFootprint::JSCMemoryFootprint):
(JSCMemoryFootprint::createStructure):
(JSCMemoryFootprint::create):
(JSCMemoryFootprint::finishCreation):
(JSCMemoryFootprint::addProperty):
(functionResetMemoryPeak):
2018-09-20 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r236235.
Breaks internal builds.
Reverted changeset:
"Add functions to measure memory footprint to JSC"
https://bugs.webkit.org/show_bug.cgi?id=189768
https://trac.webkit.org/changeset/236235
2018-09-20 Fujii Hironori <Hironori.Fujii@sony.com>
[Win][Clang] JITMathIC.h: error: missing 'template' keyword prior to dependent template name 'retagged'
https://bugs.webkit.org/show_bug.cgi?id=189730
Reviewed by Saam Barati.
Clang for Windows can't compile the workaround for MSVC quirk in generateOutOfLine.
* jit/JITMathIC.h:
(generateOutOfLine): Append "&& !COMPILER(CLANG)" to "#if COMPILER(MSVC)".
2018-09-19 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Optimize Array#indexOf in C++ runtime
https://bugs.webkit.org/show_bug.cgi?id=189507
Reviewed by Saam Barati.
C++ Array#indexOf runtime function takes so much time in babylon benchmark in
web-tooling-benchmark. While our DFG and FTL has Array#indexOf optimization
and actually it is working well, C++ Array#indexOf is called significant amount
of time before tiering up, and it takes 6.74% of jsc main thread samples according
to perf command in Linux. This is because C++ Array#indexOf is too generic and
misses the chance to optimize JSArray cases.
This patch adds JSArray fast path for Array#indexOf. If we know that indexed
access to the given JSArray is non-observable and indexing type is good for the fast
path, we go to the fast path. This makes sampling of Array#indexOf 3.83% in
babylon web-tooling-benchmark.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncIndexOf):
* runtime/JSArray.h:
* runtime/JSArrayInlines.h:
(JSC::JSArray::canDoFastIndexedAccess):
(JSC::toLength):
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::JSValue):
* runtime/JSGlobalObject.h:
* runtime/JSGlobalObjectInlines.h:
(JSC::JSGlobalObject::isArrayPrototypeIndexedAccessFastAndNonObservable):
(JSC::JSGlobalObject::isArrayPrototypeIteratorProtocolFastAndNonObservable):
* runtime/MathCommon.h:
(JSC::canBeStrictInt32):
(JSC::canBeInt32):
2018-09-19 Michael Saboff <msaboff@apple.com>
Add functions to measure memory footprint to JSC
https://bugs.webkit.org/show_bug.cgi?id=189768
Reviewed by Saam Barati.
Provide system memory metrics for the current process to aid in memory reduction measurement and
tuning using native JS tests.
* jsc.cpp:
(MemoryFootprint::now):
(MemoryFootprint::resetPeak):
(GlobalObject::finishCreation):
(JSCMemoryFootprint::JSCMemoryFootprint):
(JSCMemoryFootprint::createStructure):
(JSCMemoryFootprint::create):
(JSCMemoryFootprint::finishCreation):
(JSCMemoryFootprint::addProperty):
(functionResetMemoryPeak):
2018-09-19 Saam barati <sbarati@apple.com>
CheckStructureOrEmpty should pass in a tempGPR to emitStructureCheck since it may jump over that code
https://bugs.webkit.org/show_bug.cgi?id=189703
Reviewed by Mark Lam.
This fixes a crash that a TypeProfiler change revealed.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
2018-09-19 Saam barati <sbarati@apple.com>
AI rule for MultiPutByOffset executes its effects in the wrong order
https://bugs.webkit.org/show_bug.cgi?id=189757
<rdar://problem/43535257>
Reviewed by Michael Saboff.
The AI rule for MultiPutByOffset was executing effects in the wrong order.
It first executed the transition effects and the effects on the base, and
then executed the filtering effects on the value being stored. However, you
can end up with the wrong type when the base and the value being stored
are the same. E.g, in a program like `o.f = o`. These effects need to happen
in the opposite order, modeling what happens in the runtime executing of
MultiPutByOffset.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2018-09-18 Mark Lam <mark.lam@apple.com>
Ensure that ForInContexts are invalidated if their loop local is over-written.
https://bugs.webkit.org/show_bug.cgi?id=189571
<rdar://problem/44402277>
Reviewed by Saam Barati.
Instead of hunting down every place in the BytecodeGenerator that potentially
needs to invalidate an enclosing ForInContext (if one exists), we simply iterate
the bytecode range of the loop body when the ForInContext is popped, and
invalidate the context if we ever find the loop temp variable over-written.
This has 2 benefits:
1. It ensures that every type of opcode that can write to the loop temp will be
handled appropriately, not just the op_mov that we've hunted down.
2. It avoids us having to check the BytecodeGenerator's m_forInContextStack
every time we emit an op_mov (or other opcodes that can write to a local)
even when we're not inside a for-in loop.
JSC benchmarks show that that this change is performance neutral.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::pushIndexedForInScope):
(JSC::BytecodeGenerator::popIndexedForInScope):
(JSC::BytecodeGenerator::pushStructureForInScope):
(JSC::BytecodeGenerator::popStructureForInScope):
(JSC::ForInContext::finalize):
(JSC::StructureForInContext::finalize):
(JSC::IndexedForInContext::finalize):
(JSC::BytecodeGenerator::invalidateForInContextForLocal): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::ForInContext::ForInContext):
(JSC::ForInContext::bodyBytecodeStartOffset const):
(JSC::StructureForInContext::StructureForInContext):
(JSC::IndexedForInContext::IndexedForInContext):
* bytecompiler/NodesCodegen.cpp:
(JSC::PostfixNode::emitResolve):
(JSC::PrefixNode::emitResolve):
(JSC::ReadModifyResolveNode::emitBytecode):
(JSC::AssignResolveNode::emitBytecode):
(JSC::EmptyLetExpression::emitBytecode):
(JSC::ForInNode::emitLoopHeader):
(JSC::ForOfNode::emitBytecode):
(JSC::BindingNode::bindValue const):
(JSC::AssignmentElementNode::bindValue const):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
2018-09-17 Devin Rousso <drousso@apple.com>
Web Inspector: generate CSSKeywordCompletions from backend values
https://bugs.webkit.org/show_bug.cgi?id=189041
Reviewed by Joseph Pecoraro.
* inspector/protocol/CSS.json:
Include an optional `aliases` array and `inherited` boolean for `CSSPropertyInfo`.
2018-09-17 Saam barati <sbarati@apple.com>
We must convert ProfileType to CheckStructureOrEmpty instead of CheckStructure
https://bugs.webkit.org/show_bug.cgi?id=189676
<rdar://problem/39682897>
Reviewed by Michael Saboff.
Because the incoming value may be TDZ, CheckStructure may end up crashing.
Since the Type Profile does not currently record TDZ values in any of its
data structures, this is not a semantic change in how it will show you data.
It just fixes crashes when we emit a CheckStructure and the incoming value
is TDZ.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToCheckStructureOrEmpty):
2018-09-17 Darin Adler <darin@apple.com>
Use OpaqueJSString rather than JSRetainPtr inside WebKit
https://bugs.webkit.org/show_bug.cgi?id=189652
Reviewed by Saam Barati.
* API/JSCallbackObjectFunctions.h: Removed an uneeded include of
JSStringRef.h.
* API/JSContext.mm:
(-[JSContext evaluateScript:withSourceURL:]): Use OpaqueJSString::create rather
than JSStringCreateWithCFString, simplifying the code and also obviating the
need for explicit JSStringRelease.
(-[JSContext setName:]): Ditto.
* API/JSStringRef.cpp:
(JSStringIsEqualToUTF8CString): Use adoptRef rather than explicit JSStringRelease.
It seems that additional optimization is possible, obviating the need to allocate
an OpaqueJSString, but that's true almost everywhere else in this patch, too.
* API/JSValue.mm:
(+[JSValue valueWithNewRegularExpressionFromPattern:flags:inContext:]): Use
OpaqueJSString::create and adoptRef as appropriate.
(+[JSValue valueWithNewErrorFromMessage:inContext:]): Ditto.
(+[JSValue valueWithNewSymbolFromDescription:inContext:]): Ditto.
(performPropertyOperation): Ditto.
(-[JSValue invokeMethod:withArguments:]): Ditto.
(valueToObjectWithoutCopy): Ditto.
(containerValueToObject): Ditto.
(valueToString): Ditto.
(objectToValueWithoutCopy): Ditto.
(objectToValue): Ditto.
2018-09-08 Darin Adler <darin@apple.com>
Streamline JSRetainPtr, fix leaks of JSString and JSGlobalContext
https://bugs.webkit.org/show_bug.cgi?id=189455
Reviewed by Keith Miller.
* API/JSObjectRef.cpp:
(OpaqueJSPropertyNameArray): Use Ref<OpaqueJSString> instead of
JSRetainPtr<JSStringRef>.
(JSObjectCopyPropertyNames): Remove now-unneeded use of leakRef and
adopt constructor.
(JSPropertyNameArrayGetNameAtIndex): Use ptr() instead of get() since
the array elements are now Ref.
* API/JSRetainPtr.h: While JSRetainPtr is written as a template,
it only works for two specific unrelated types, JSStringRef and
JSGlobalContextRef. Simplified the default constructor using data
member initialization. Prepared to make the adopt constructor private
(got everything compiling that way, then made it public again so that
Apple internal software will still build). Got rid of unneeded
templated constructor and assignment operator, since it's not relevant
since there is no inheritance between JSRetainPtr template types.
Added WARN_UNUSED_RETURN to leakRef as in RefPtr and RetainPtr.
Added move constructor and move assignment operator for slightly better
performance. Simplified implementations of various member functions
so they are more obviously correct, by using leakPtr in more of them
and using std::exchange to make the flow of values more obvious.
* API/JSValue.mm:
(+[JSValue valueWithNewSymbolFromDescription:inContext:]): Added a
missing JSStringRelease to fix a leak.
* API/tests/CustomGlobalObjectClassTest.c:
(customGlobalObjectClassTest): Added a JSGlobalContextRelease to fix a leak.
(globalObjectSetPrototypeTest): Ditto.
(globalObjectPrivatePropertyTest): Ditto.
* API/tests/ExecutionTimeLimitTest.cpp:
(testResetAfterTimeout): Added a call to JSStringRelease to fix a leak.
(testExecutionTimeLimit): Ditto, lots more.
* API/tests/FunctionOverridesTest.cpp:
(testFunctionOverrides): Added a call to JSStringRelease to fix a leak.
* API/tests/JSObjectGetProxyTargetTest.cpp:
(testJSObjectGetProxyTarget): Added a call to JSGlobalContextRelease to fix
a leak.
* API/tests/PingPongStackOverflowTest.cpp:
(testPingPongStackOverflow): Added calls to JSGlobalContextRelease and
JSStringRelease to fix leaks.
* API/tests/testapi.c:
(throwException): Added. Helper function for repeated idiom where we want
to throw an exception, but with additional JSStringRelease calls so we don't
have to leak just to keep the code simpler to read.
(MyObject_getProperty): Use throwException.
(MyObject_setProperty): Ditto.
(MyObject_deleteProperty): Ditto.
(isValueEqualToString): Added. Helper function for an idiom where we check
if something is a string and then if it's equal to a particular string
constant, but a version that has an additional JSStringRelease call so we
don't have to leak just to keep the code simpler to read.
(MyObject_callAsFunction): Use isValueEqualToString and throwException.
(MyObject_callAsConstructor): Ditto.
(MyObject_hasInstance): Ditto.
(globalContextNameTest): Added a JSGlobalContextRelease to fix a leak.
(testMarkingConstraintsAndHeapFinalizers): Ditto.
2018-09-14 Saam barati <sbarati@apple.com>
Don't dump OSRAvailabilityData in Graph::dump because a stale Availability may point to a Node that is already freed
https://bugs.webkit.org/show_bug.cgi?id=189628
<rdar://problem/39481690>
Reviewed by Mark Lam.
An Availability may point to a Node. And that Node may be removed from
the graph, e.g, it's freed and its memory is no longer owned by Graph.
This patch makes it so we no longer dump this metadata by default. If
this metadata is interesting to you, you'll need to go in and change
Graph::dump to dump the needed metadata.
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
2018-09-14 Mark Lam <mark.lam@apple.com>
Refactor some ForInContext code for better encapsulation.
https://bugs.webkit.org/show_bug.cgi?id=189626
<rdar://problem/44466415>
Reviewed by Keith Miller.
1. Add a ForInContext::m_type field to store the context type. This does not
increase the class size, but eliminates the need for a virtual call to get the
type.
Note: we still need a virtual destructor because we'll be mingling
IndexedForInContexts and StructureForInContexts in the BytecodeGenerator::m_forInContextStack.
2. Add ForInContext::isIndexedForInContext() and ForInContext::isStructureForInContext()
convenience methods.
3. Add ForInContext::asIndexedForInContext() and ForInContext::asStructureForInContext()
to do the casting to the subclass types. This ensures that we'll properly
assert that the casting is legal.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitGetByVal):
(JSC::BytecodeGenerator::popIndexedForInScope):
(JSC::BytecodeGenerator::popStructureForInScope):
* bytecompiler/BytecodeGenerator.h:
(JSC::ForInContext::type const):
(JSC::ForInContext::isIndexedForInContext const):
(JSC::ForInContext::isStructureForInContext const):
(JSC::ForInContext::asIndexedForInContext):
(JSC::ForInContext::asStructureForInContext):
(JSC::ForInContext::ForInContext):
(JSC::StructureForInContext::StructureForInContext):
(JSC::IndexedForInContext::IndexedForInContext):
(JSC::ForInContext::~ForInContext): Deleted.
2018-09-14 Devin Rousso <webkit@devinrousso.com>
Web Inspector: Record actions performed on ImageBitmapRenderingContext
https://bugs.webkit.org/show_bug.cgi?id=181341
Reviewed by Joseph Pecoraro.
* inspector/protocol/Recording.json:
* inspector/scripts/codegen/generator.py:
2018-09-14 Mike Gorse <mgorse@suse.com>
builtins directory causes name conflict on Python 3
https://bugs.webkit.org/show_bug.cgi?id=189552
Reviewed by Michael Catanzaro.
* CMakeLists.txt: builtins -> wkbuiltins.
* DerivedSources.make: builtins -> wkbuiltins.
* Scripts/generate-js-builtins.py: import wkbuiltins, rather than
builtins.
* Scripts/wkbuiltins/__init__.py: Renamed from Source/JavaScriptCore/Scripts/builtins/__init__.py.
* Scripts/wkbuiltins/builtins_generate_combined_header.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generate_combined_header.py.
* Scripts/wkbuiltins/builtins_generate_internals_wrapper_implementation.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generate_internals_wrapper_implementation.py.
* Scripts/wkbuiltins/builtins_generate_separate_header.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generate_separate_header.py.
* Scripts/wkbuiltins/builtins_generate_separate_implementation.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generate_separate_implementation.py.
* Scripts/wkbuiltins/builtins_generate_wrapper_header.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generate_wrapper_header.py.
* Scripts/wkbuiltins/builtins_generate_wrapper_implementation.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generate_wrapper_implementation.py.
* Scripts/wkbuiltins/builtins_generator.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generator.py.
* Scripts/wkbuiltins/builtins_model.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_model.py.
* Scripts/wkbuiltins/builtins_templates.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_templates.py.
* Scripts/wkbuiltins/wkbuiltins.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins.py.
* JavaScriptCore.xcodeproj/project.pbxproj: Update for the renaming.
2018-09-13 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[WebAssembly] Inline WasmContext accessor functions
https://bugs.webkit.org/show_bug.cgi?id=189416
Reviewed by Saam Barati.
WasmContext accessor functions are very small while it resides in the critical path of
JS to Wasm function call. This patch makes them inline to improve performance.
This change improves a small benchmark (calling JS to Wasm function 1e7 times) from 320ms to 270ms.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* interpreter/CallFrame.cpp:
* jit/AssemblyHelpers.cpp:
* wasm/WasmB3IRGenerator.cpp:
* wasm/WasmContextInlines.h: Renamed from Source/JavaScriptCore/wasm/WasmContext.cpp.
(JSC::Wasm::Context::useFastTLS):
(JSC::Wasm::Context::load const):
(JSC::Wasm::Context::store):
* wasm/WasmMemoryInformation.cpp:
* wasm/WasmModuleParser.cpp: Include <wtf/SHA1.h> due to changes of unified source combinations.
* wasm/js/JSToWasm.cpp:
* wasm/js/WebAssemblyFunction.cpp:
2018-09-12 David Kilzer <ddkilzer@apple.com>
Move JavaScriptCore files to match Xcode project hierarchy
<https://webkit.org/b/189574>
Reviewed by Filip Pizlo.
* API/JSAPIValueWrapper.cpp: Rename from Source/JavaScriptCore/runtime/JSAPIValueWrapper.cpp.
* API/JSAPIValueWrapper.h: Rename from Source/JavaScriptCore/runtime/JSAPIValueWrapper.h.
* CMakeLists.txt: Update for new path to
generateYarrUnicodePropertyTables.py, hasher.py and
JSAPIValueWrapper.h.
* DerivedSources.make: Ditto. Add missing dependency on
hasher.py captured by CMakeLists.txt.
* JavaScriptCore.xcodeproj/project.pbxproj: Update for new file
reference paths. Add hasher.py library to project.
* Sources.txt: Update for new path to
JSAPIValueWrapper.cpp.
* runtime/JSImmutableButterfly.h: Add missing includes
after changes to Sources.txt and regenerating unified
sources.
* runtime/RuntimeType.h: Ditto.
* yarr/generateYarrUnicodePropertyTables.py: Rename from Source/JavaScriptCore/Scripts/generateYarrUnicodePropertyTables.py.
* yarr/hasher.py: Rename from Source/JavaScriptCore/Scripts/hasher.py.
2018-09-12 David Kilzer <ddkilzer@apple.com>
Let Xcode have its way with the JavaScriptCore project
* JavaScriptCore.xcodeproj/project.pbxproj:
2018-09-12 Guillaume Emont <guijemont@igalia.com>
Add IGNORE_WARNING_.* macros
https://bugs.webkit.org/show_bug.cgi?id=188996
Reviewed by Michael Catanzaro.
* API/JSCallbackObject.h:
* API/tests/testapi.c:
* assembler/LinkBuffer.h:
(JSC::LinkBuffer::finalizeCodeWithDisassembly):
* b3/B3LowerToAir.cpp:
* b3/B3Opcode.cpp:
* b3/B3Type.h:
* b3/B3TypeMap.h:
* b3/B3Width.h:
* b3/air/AirArg.cpp:
* b3/air/AirArg.h:
* b3/air/AirCode.h:
* bytecode/Opcode.h:
(JSC::padOpcodeName):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::speculateNumber):
(JSC::DFG::SpeculativeJIT::speculateMisc):
* dfg/DFGSpeculativeJIT64.cpp:
* ftl/FTLOutput.h:
* jit/CCallHelpers.h:
(JSC::CCallHelpers::calculatePokeOffset):
* llint/LLIntData.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::slowPathLogF):
* runtime/ConfigFile.cpp:
(JSC::ConfigFile::canonicalizePaths):
* runtime/JSDataViewPrototype.cpp:
* runtime/JSGenericTypedArrayViewConstructor.h:
* runtime/JSGenericTypedArrayViewPrototype.h:
* runtime/Options.cpp:
(JSC::Options::setAliasedOption):
* tools/CodeProfiling.cpp:
* wasm/WasmSections.h:
* wasm/generateWasmValidateInlinesHeader.py:
== Rolled over to ChangeLog-2018-09-11 ==