Google Git
Sign in
webkit / WebKit / 8f6d45fb9c8b188a7f9b17be40cf7dea6763c462 / . / Source / JavaScriptCore / ChangeLog
blob: 0c3213b9a19440bcfd28dd39fbf47c513229f350 [file] [log] [blame]
2017-05-04 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Math unary functions should be handled by DFG
https://bugs.webkit.org/show_bug.cgi?id=171269
Reviewed by Saam Barati.
ArithSin, ArithCos, and ArithLog are just calling a C runtime function.
While handling them in DFG is not very effective for performance, they
can drop some type checks & value conversions and mark them as pure
operations. It is effective if they are involved in some complex
optimization phase. Actually, ArithLog is effective in kraken.
While a few of Math functions have DFG nodes, basically math functions
are pure. And large part of these functions are just calling a C runtime
function. This patch generalizes these nodes in DFG as ArithUnary. And
we annotate many unary math functions with Intrinsics and convert them
to ArithUnary in DFG. It also cleans up duplicate code in ArithSin,
ArithCos, and ArithLog. If your math function has some good DFG / FTL
optimization rather than calling a C runtime function, you should add
a specialized DFG node, like ArithSqrt.
We also create a new namespace JSC::Math. Inside it, we collect math functions.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGArithMode.cpp:
(JSC::DFG::arithUnaryFunction):
(JSC::DFG::arithUnaryOperation):
(WTF::printInternal):
* dfg/DFGArithMode.h:
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasArithUnaryType):
(JSC::DFG::Node::arithUnaryType):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithUnary):
(JSC::DFG::SpeculativeJIT::compileArithCos): Deleted.
(JSC::DFG::SpeculativeJIT::compileArithTan): Deleted.
(JSC::DFG::SpeculativeJIT::compileArithSin): Deleted.
(JSC::DFG::SpeculativeJIT::compileArithLog): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileArithUnary):
(JSC::FTL::DFG::LowerDFGToB3::compileArithSin): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::compileArithCos): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::compileArithTan): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::compileArithLog): Deleted.
* ftl/FTLOutput.cpp:
(JSC::FTL::Output::doubleUnary):
(JSC::FTL::Output::doubleSin): Deleted.
(JSC::FTL::Output::doubleCos): Deleted.
(JSC::FTL::Output::doubleTan): Deleted.
(JSC::FTL::Output::doubleLog): Deleted.
* ftl/FTLOutput.h:
* runtime/Intrinsic.h:
* runtime/MathCommon.cpp:
(JSC::Math::log1p):
* runtime/MathCommon.h:
* runtime/MathObject.cpp:
(JSC::MathObject::finishCreation):
(JSC::mathProtoFuncACos):
(JSC::mathProtoFuncASin):
(JSC::mathProtoFuncATan):
(JSC::mathProtoFuncCos):
(JSC::mathProtoFuncExp):
(JSC::mathProtoFuncLog):
(JSC::mathProtoFuncSin):
(JSC::mathProtoFuncTan):
(JSC::mathProtoFuncACosh):
(JSC::mathProtoFuncASinh):
(JSC::mathProtoFuncATanh):
(JSC::mathProtoFuncCbrt):
(JSC::mathProtoFuncCosh):
(JSC::mathProtoFuncExpm1):
(JSC::mathProtoFuncLog1p):
(JSC::mathProtoFuncLog10):
(JSC::mathProtoFuncLog2):
(JSC::mathProtoFuncSinh):
(JSC::mathProtoFuncTanh):
2017-05-03 Saam Barati <sbarati@apple.com>
How we build polymorphic cases is wrong when making a call from Wasm
https://bugs.webkit.org/show_bug.cgi?id=171527
Reviewed by JF Bastien.
This patches fixes a bug when we emit a polymorphic call IC from
Wasm. We were incorrectly assuming that if we made a call *from wasm*,
then the thing we are *calling to* does not have a CodeBlock. This
is obviously wrong. This patch fixes the incorrect assumption.
This patch also does two more things:
1. Add a new option that makes us make calls to JS using a
slow path instead of using a call IC.
2. Fixes a potential GC bug where we didn't populate JSWebAssemblyCodeBlock's
JSWebAssemblyModule pointer.
* jit/Repatch.cpp:
(JSC::linkPolymorphicCall):
* runtime/Options.h:
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToJs):
* wasm/js/JSWebAssemblyCodeBlock.cpp:
(JSC::JSWebAssemblyCodeBlock::create):
(JSC::JSWebAssemblyCodeBlock::finishCreation):
* wasm/js/JSWebAssemblyCodeBlock.h:
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::finalizeCreation):
2017-05-03 Keith Miller <keith_miller@apple.com>
Array.prototype.sort should also allow a null comparator
https://bugs.webkit.org/show_bug.cgi?id=171621
<rdar://problem/30757933>
Reviewed by Michael Saboff.
It looks like sort not accepting a null comparator
causes some pages to stop working. Those pages work in
Chrome/Firefox so we should try to match them.
* builtins/ArrayPrototype.js:
(sort):
2017-05-03 Mark Lam <mark.lam@apple.com>
Use the CLoop for CPU(ARM64E).
https://bugs.webkit.org/show_bug.cgi?id=171620
<rdar://problem/31973027>
Reviewed by Geoffrey Garen.
* llint/LLIntOfflineAsmConfig.h:
* tools/SigillCrashAnalyzer.cpp:
(JSC::SigillCrashAnalyzer::dumpCodeBlock):
2017-05-03 Keith Miller <keith_miller@apple.com>
Different behaviour with the .sort(callback) method (unlike Firefox & Chrome)
https://bugs.webkit.org/show_bug.cgi?id=47825
Reviewed by Saam Barati.
This patch makes our sort function match the behavior of Firefox
and Chrome when the result of the comparison function is a
boolean. When we first switched to using merge sort, it regressed
JQuery sorting of DOM nodes by 30%. The regression was do to the
fact that JQuery was using compareDocumentPosition to compare the
locations of objects. Since one of the benchmarks would pass a
reverse sorted list to the sort function we would end up walking
the entire DOM to do comparisons. The solution to this was to
merge based on comparison(right, left) rather than
comparison(left, right). Although, in practice this does nothing
since sort could just as easily receive an already sorted list and
we're back in the same spot.
The downside of sorting with comparison(right, left) is that to
maintain stability when sorting, you only want to merge from right
when the comparison function returns a negative value. This is
where the problem with booleans comes in. Since booleans toNumber
false to 0 and true to 1 both values are "equal". This patch fixes
this by special casing boolean return values.
* builtins/ArrayPrototype.js:
(sort.merge):
2017-05-03 Andy VanWagoner <thetalecrafter@gmail.com>
[INTL] Support dashed values in unicode locale extensions
https://bugs.webkit.org/show_bug.cgi?id=171480
Reviewed by JF Bastien.
Implements the UnicodeExtensionSubtags operation and updates the ResolveLocale operation to use it.
This fixes locale extensions with values that include '-'. The following calendars work now:
ethiopic-amete-alem
islamic-umalqura
islamic-tbla
islamic-civil
islamic-rgsa
While updating IntlObject, the comments containing spec text were replaced with a single url at the
top of each function pointing to the relevant part of ECMA-402.
* runtime/IntlObject.cpp:
(JSC::unicodeExtensionSubTags): Added.
(JSC::resolveLocale): Updated to latest standard.
2017-05-02 Don Olmstead <don.olmstead@am.sony.com>
Build fix after r216078
https://bugs.webkit.org/show_bug.cgi?id=171554
Reviewed by Saam Barati.
* API/tests/testapi.c:
2017-05-02 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix pedantic C compilers.
* API/tests/testapi.c:
(markingConstraint):
(testMarkingConstraints):
2017-05-02 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix cmake build.
* CMakeLists.txt:
2017-05-02 Filip Pizlo <fpizlo@apple.com>
JSC C API should expose GC marking constraints and weak references
https://bugs.webkit.org/show_bug.cgi?id=171554
Reviewed by Geoffrey Garen.
This exposes an API that lets you participate in the GC's fixpoint. You can ask the GC
what is marked and you can tell the GC to mark things. The constraint callback cannot
do a whole lot, but it can query marking state and it can dereference weak references.
Additionally, this exposes a very simple weak reference API in C.
* API/JSMarkingConstraintPrivate.cpp: Added.
(JSC::isMarked):
(JSC::mark):
(JSContextGroupRegisterMarkingConstraint):
* API/JSMarkingConstraintPrivate.h: Added.
* API/JSWeakPrivate.cpp: Added.
(OpaqueJSWeak::OpaqueJSWeak):
(JSWeakCreate):
(JSWeakRetain):
(JSWeakRelease):
(JSWeakGetObject):
* API/JSWeakPrivate.h: Added.
* API/tests/testapi.c:
(markingConstraint):
(testMarkingConstraints):
(main):
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/SlotVisitor.h:
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::appendHiddenUnbarriered):
(JSC::SlotVisitor::appendHidden):
2017-05-02 Mark Lam <mark.lam@apple.com>
JSFixedArray::allocationSize() should not allow for allocation failure.
https://bugs.webkit.org/show_bug.cgi?id=171516
Reviewed by Geoffrey Garen.
Since JSFixedArray::createFromArray() now handles allocation failures by throwing
OutOfMemoryErrors, its helper function allocationSize() (which computes the buffer
size to allocate) should also allow for allocation failure on overflow.
This issue is covered by the stress/js-fixed-array-out-of-memory.js test when
run on 32-bit builds.
* runtime/JSFixedArray.h:
(JSC::JSFixedArray::tryCreate):
(JSC::JSFixedArray::allocationSize):
2017-05-01 Zan Dobersek <zdobersek@igalia.com>
[aarch64][Linux] m_allowScratchRegister assert hit in MacroAssemblerARM64 under B3::Air::CCallSpecial::generate()
https://bugs.webkit.org/show_bug.cgi?id=170672
Reviewed by Filip Pizlo.
In Air::CCallSpecial::admitsStack() we reject admitting the callee argument on
the stack for ARM64 because that can lead to disallowed usage of the scratch
register in MacroAssemblerARM64 when generating a call with an address Arg
in Air::CCallSpecial::generate().
The testLinearScanWithCalleeOnStack test is added to testb3. It reproduces the
original issue by force-spilling everything on the stack and enforcing the use
of the linear scan register allocation by using an optimization level of 1.
* b3/air/AirCCallSpecial.cpp:
(JSC::B3::Air::CCallSpecial::admitsStack):
* b3/testb3.cpp:
(JSC::B3::testLinearScanWithCalleeOnStack):
(JSC::B3::run):
2017-05-01 David Kilzer <ddkilzer@apple.com>
Stop using sprintf() in JavaScriptCore debugger
<https://webkit.org/b/171512>
Reviewed by Keith Miller.
* disassembler/udis86/udis86.c:
(ud_insn_hex): Switch from sprintf() to snprintf().
2017-04-21 Filip Pizlo <fpizlo@apple.com>
Air::fixObviousSpills should remove totally redundant instructions
https://bugs.webkit.org/show_bug.cgi?id=171131
Reviewed by Saam Barati.
This is a modest compile-time-neutral improvement to fixObviousSpills. That phase
builds up a classic alias analysis data structure over spills and registers and then
uses it to remove the most common spill pathologies we encounter. For example, if you
use a spill but the spill is aliased to a register or constant, then we can replace the
use of the spill with a use of the register or constant.
But that phase was missing perhaps one of the most obvious fixups that its analysis
allows us to do: if any instruction creates an alias we already know about, then the
instruction is redundant. This turned out to be super important for
https://bugs.webkit.org/show_bug.cgi?id=171075. That patch didn't work out, but this
kind of optimization might be a good clean-up for many other kinds of optimizations.
* b3/air/AirFixObviousSpills.cpp:
2017-04-30 Oleksandr Skachkov <gskachkov@gmail.com>
We initialize functions too early in an eval
https://bugs.webkit.org/show_bug.cgi?id=161099
Reviewed by Saam Barati.
Current patch allow to fix problem with scope in function that is
declared within eval. Before scope was set inside Interpretator.cpp and it
was scope where eval is executed, but in this case function would not
see let/const variables and classes declated in eval.
This patch devide declaration and binding in two operation, first just declare
variable with function name, and second bind variable to function with correct
scope
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::BytecodeGenerator):
* bytecompiler/BytecodeGenerator.h:
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
2017-04-30 Oleksandr Skachkov <gskachkov@gmail.com>
[ES6]. Implement Annex B.3.3 function hoisting rules for eval
https://bugs.webkit.org/show_bug.cgi?id=163208
Reviewed by Saam Barati.
Current patch implements Annex B.3.3 that is related to
hoisting of function declaration in eval.
https://tc39.github.io/ecma262/#sec-web-compat-evaldeclarationinstantiation
Function declaration in eval should create variable with
function name in function scope where eval is invoked
or bind to variable if it declared outside of the eval.
If variable is created it can be removed by 'delete a;' command.
If eval is invoke in block scope that contains let/const
variable with the same name as function declaration
we do not bind. This patch leads to the following behavior:
'''
function foo() {
{
print(boo); // undefined
eval('{ function boo() {}}');
print(boo); // function boo() {}
}
print(boo); // function boo() {}
}
function foobar() {
{
let boo = 10;
print(boo); // 10;
eval('{ function boo() {}}');
print(boo); // 10;
}
print(boo) // 10
}
function bar() {
{
var boo = 10;
print(boo); // 10
eval('{ function boo() {} }');
print(boo); // function boo() {}
}
print(boo); // function boo() {}
}
function bas() {
{
let boo = 10;
eval(' { function boo() {} } ');
print(boo); // 10
}
print(boo); //Reference Error
}
'''
Current implementation relies on already implemented
'hoist function in sloppy mode' feature, with small changes.
In short it works in following way: during hoisting of function
with name S in eval, we are looking for first scope that
contains space for variable with name S and if this scope
has var type we bind function there
To implement this feature was added bytecode ops:
op_resolve_scope_for_hoisting_func_decl_in_eval - get variable scope
or return undefined if variable can't be binded there.
There is a corner case, hoist function in eval within catch block,
that is not covered by this patch, and will be fixed in
https://bugs.webkit.org/show_bug.cgi?id=168184
* bytecode/BytecodeDumper.cpp:
(JSC::BytecodeDumper<Block>::dumpBytecode):
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finalizeLLIntInlineCaches):
* bytecode/EvalCodeBlock.h:
(JSC::EvalCodeBlock::functionHoistingCandidate):
(JSC::EvalCodeBlock::numFunctionHoistingCandidates):
* bytecode/UnlinkedEvalCodeBlock.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
(JSC::BytecodeGenerator::emitResolveScopeForHoistingFuncDeclInEval):
* bytecompiler/BytecodeGenerator.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasIdentifier):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileResolveScopeForHoistingFuncDeclInEval):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileResolveScopeForHoistingFuncDeclInEval):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval):
* llint/LowLevelInterpreter.asm:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionDeclarationStatement):
* parser/Parser.h:
(JSC::Scope::getSloppyModeHoistedFunctions):
(JSC::Parser::declareFunction):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* runtime/EvalExecutable.h:
(JSC::EvalExecutable::numFunctionHoistingCandidates):
(JSC::EvalExecutable::numTopLevelFunctionDecls):
(JSC::EvalExecutable::numberOfFunctionDecls): Deleted.
* runtime/JSScope.cpp:
(JSC::JSScope::resolve):
(JSC::JSScope::resolveScopeForHoistingFuncDeclInEval):
* runtime/JSScope.h:
2017-04-29 Oleksandr Skachkov <gskachkov@gmail.com>
Deep nesting is leading to ReferenceError for hoisted function
https://bugs.webkit.org/show_bug.cgi?id=171456
Reviewed by Yusuke Suzuki.
Current patch fix error that appears during hoisting of the function
in block scope. Error happens only when exist some deep scope that lead
to increase scope stack, after which list of the hosted candidates do not
copied to updated scope stack.
* parser/Parser.h:
(JSC::Scope::Scope):
2017-04-29 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] LabelScopePtr is not necessary
https://bugs.webkit.org/show_bug.cgi?id=171474
Reviewed by Geoffrey Garen.
Originally, LabelScopePtr is introduced because LabelScopes uses Vector<> instead of SegmentedVector<>.
LabelScopePtr holds the pointer to the vector owner and index instead of the pointer to LabelScope directly
since Vector<> can relocate LocalScopes inside it.
The reason why LabelScopes use Vector instead is that there is code copying this vector. SegmentedVector<>
prohibits copying since it is so costly. So, we used Vector<> here instead of SegmentedVector<>.
But the latest code does not have copying code for LabelScopes. Thus, we can take the same design to Label and
RegisterID. Just use SegmentedVector<> and Ref<>/RefPtr<>. This patch removes LabelScopePtr since it is no
longer necessary. And use SegmentedVector for LabelScopes.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::reclaim):
(JSC::BytecodeGenerator::reclaimFreeRegisters):
(JSC::BytecodeGenerator::newLabelScope):
(JSC::BytecodeGenerator::newLabel):
(JSC::BytecodeGenerator::pushFinallyControlFlowScope):
(JSC::BytecodeGenerator::breakTarget):
(JSC::BytecodeGenerator::continueTarget):
(JSC::BytecodeGenerator::emitEnumeration):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/LabelScope.h:
(JSC::LabelScope::LabelScope):
(JSC::LabelScope::breakTarget):
(JSC::LabelScope::continueTarget):
(JSC::LabelScope::type):
(JSC::LabelScope::name):
(JSC::LabelScope::scopeDepth):
(JSC::LabelScope::ref):
(JSC::LabelScope::deref):
(JSC::LabelScope::refCount):
(JSC::LabelScopePtr::LabelScopePtr): Deleted.
(JSC::LabelScopePtr::operator=): Deleted.
(JSC::LabelScopePtr::~LabelScopePtr): Deleted.
(JSC::LabelScopePtr::operator!): Deleted.
(JSC::LabelScopePtr::operator*): Deleted.
(JSC::LabelScopePtr::operator->): Deleted.
(JSC::LabelScopePtr::null): Deleted.
* bytecompiler/NodesCodegen.cpp:
(JSC::DoWhileNode::emitBytecode):
(JSC::WhileNode::emitBytecode):
(JSC::ForNode::emitBytecode):
(JSC::ForInNode::emitBytecode):
(JSC::ContinueNode::trivialTarget):
(JSC::ContinueNode::emitBytecode):
(JSC::BreakNode::trivialTarget):
(JSC::BreakNode::emitBytecode):
(JSC::SwitchNode::emitBytecode):
(JSC::LabelNode::emitBytecode):
2017-04-28 Mark Lam <mark.lam@apple.com>
Revert instrumentation from https://bugs.webkit.org/show_bug.cgi?id=170086 that is no longer needed.
https://bugs.webkit.org/show_bug.cgi?id=170094
Reviewed by JF Bastien and Keith Miller.
* heap/Heap.cpp:
(JSC::Heap::resumeThePeriphery):
2017-04-27 Andy VanWagoner <thetalecrafter@gmail.com>
[INTL] Implement the caseFirst option for Intl.Collator
https://bugs.webkit.org/show_bug.cgi?id=158188
Reviewed by Geoffrey Garen.
Implements the caseFirst option and unicode locale extension.
The caseFirst option explicitly determines whether upper or lower case comes first.
* runtime/IntlCollator.cpp:
(JSC::sortLocaleData): Added kf data.
(JSC::searchLocaleData): Added kf data.
(JSC::IntlCollator::initializeCollator): Set caseFirst option.
(JSC::IntlCollator::createCollator): Set new attributes on ICU collator.
(JSC::IntlCollator::caseFirstString): Added.
(JSC::IntlCollator::resolvedOptions): Added caseFirst property.
* runtime/IntlCollator.h:
2017-04-27 Mark Lam <mark.lam@apple.com>
Fix some RELEASE_ASSERT failures caused by OutOfMemoryErrors.
https://bugs.webkit.org/show_bug.cgi?id=171404
<rdar://problem/31876178>
Reviewed by Saam Barati.
1. Added some tryAllocate() functions in JSCellInlines.h.
2. Consolidated the implementations of allocateCell() template functions into a
single tryAllocateCellHelper() to reduce redundancy and eliminate needing to
copy-paste for variations of allocateCell and tryAllocateCell.
3. Changed JSFixedArray::createFromArray() and constructEmptyArray() to check for
allocation failure and throw an OutOfMemoryError. It was already possible to
throw errors from these functions for other reasons. So, their clients are
already ready to handle OOMEs.
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
* runtime/JSCInlines.h:
* runtime/JSCell.h:
* runtime/JSCellInlines.h:
(JSC::tryAllocateCellHelper):
(JSC::allocateCell):
(JSC::tryAllocateCell):
* runtime/JSFixedArray.h:
(JSC::JSFixedArray::createFromArray):
(JSC::JSFixedArray::tryCreate):
(JSC::JSFixedArray::create): Deleted.
* runtime/JSGlobalObject.h:
(JSC::constructEmptyArray):
2017-04-27 Joseph Pecoraro <pecoraro@apple.com>
Support for promise rejection events (unhandledrejection)
https://bugs.webkit.org/show_bug.cgi?id=150358
<rdar://problem/28441651>
Reviewed by Saam Barati.
Patch by Joseph Pecoraro and Yusuke Suzuki.
Implement support for promise.[[PromiseIsHandled]] and the
HostPromiseRejectionTracker hook for HTML to track promise rejections:
https://tc39.github.io/ecma262/#sec-host-promise-rejection-tracker
https://html.spec.whatwg.org/multipage/webappapis.html#unhandled-promise-rejections
* builtins/BuiltinNames.h:
New private symbols.
* builtins/PromiseOperations.js:
(globalPrivate.newHandledRejectedPromise):
Utility to create a rejected promise with [[PromiseIsHandled]] to true.
(globalPrivate.rejectPromise):
(globalPrivate.initializePromise):
* builtins/PromisePrototype.js:
(then):
Implement standard behavior of [[PromiseIsHandled]] and the host hook.
* runtime/JSPromise.cpp:
(JSC::JSPromise::isHandled):
* runtime/JSPromise.h:
C++ accessors for the [[PromiseIsHandled]] state.
* bytecode/BytecodeIntrinsicRegistry.cpp:
(JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
* bytecode/BytecodeIntrinsicRegistry.h:
Expose private values for the Reject / Handle enum values in built-ins.
* jsc.cpp:
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::promiseResolveFunction):
Add a new GlobalObjectMethodTable hook matching the promise rejection hook.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncHostPromiseRejectionTracker):
* runtime/JSGlobalObjectFunctions.h:
Plumb the builtin hook through to the optional GlobalObjectMethodTable hook.
* inspector/InjectedScriptSource.js:
(InjectedScript.prototype.createFakeValueDescriptor):
Silence possible rejected promises created internally via Web Inspector.
2017-04-27 Saam Barati <sbarati@apple.com>
B3::FoldPathConstants does not consider the fall through case for Switch
https://bugs.webkit.org/show_bug.cgi?id=171390
Reviewed by Filip Pizlo.
foldPathConstants was not taking into account a Switch's default
case when it tried to constant propagate the switch's operand value.
e.g, we incorrectly transformed this code:
```
x = argumentGPR0;
switch (x) {
case 10: return 20;
case 0:
default: return x == 0;
}
```
into:
```
x = argumentGPR0;
switch (x) {
case 10: return 20;
case 0:
default: return 1;
}
```
Because we didn't take into account the default case, we incorrectly
optimized the code as if case 0's block was only reachable if x is
equal to zero. This is obviously not true, since it's the same block
as the default case.
This fix ensures that we can run the WebAssembly Tanks demo even when
we set webAssemblyBBQOptimizationLevel=2.
* b3/B3FoldPathConstants.cpp:
* b3/B3SwitchValue.cpp:
(JSC::B3::SwitchValue::fallThrough):
(JSC::B3::SwitchValue::removeCase): Deleted.
* b3/B3SwitchValue.h:
* b3/testb3.cpp:
(JSC::B3::testCallFunctionWithHellaArguments):
(JSC::B3::testSwitchSameCaseAsDefault):
(JSC::B3::testWasmBoundsCheck):
(JSC::B3::run):
2017-04-27 Keith Miller <keith_miller@apple.com>
WebAssembly: Don't tier up the same function twice
https://bugs.webkit.org/show_bug.cgi?id=171397
Reviewed by Filip Pizlo.
Because we don't CAS the tier up count on function entry/loop backedge and we use the least significant to indicate whether or not tier up has already started we could see the following:
Threads A and B are running count in memory is (0):
A: load tier up count (0)
B: load tier up count (0)
A: decrement count to -2 and see we need to check for tier up (0)
A: store -2 to count (-2)
A: exchangeOr(1) to tier up count (-1)
B: decrement count to -2 and see we need to check for tier up (-1)
B: store -2 to count (-2)
B: exchangeOr(1) to tier up count (-1)
This would cause us to tier up the same function twice, which we would rather avoid.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::emitTierUpCheck):
* wasm/WasmTierUpCount.h:
(JSC::Wasm::TierUpCount::TierUpCount):
(JSC::Wasm::TierUpCount::loopDecrement):
(JSC::Wasm::TierUpCount::functionEntryDecrement):
(JSC::Wasm::TierUpCount::shouldStartTierUp):
2017-04-27 Keith Miller <keith_miller@apple.com>
REGRESSION (r215843): ASSERTION FAILED: !m_completionTasks[0].first in JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast(JSC::VM &)
https://bugs.webkit.org/show_bug.cgi?id=171380
Reviewed by JF Bastien.
This patch fixes the association of VMs to Wasm::Plans. For validation
we want all the completion tasks to be associate with a VM. For BBQ,
we want the main task to not be associated with any VM.
* jsc.cpp:
(functionTestWasmModuleFunctions):
* wasm/WasmBBQPlan.cpp:
(JSC::Wasm::BBQPlan::BBQPlan):
* wasm/WasmBBQPlan.h:
* wasm/WasmCodeBlock.cpp:
(JSC::Wasm::CodeBlock::CodeBlock):
(JSC::Wasm::CodeBlock::compileAsync):
* wasm/WasmCodeBlock.h:
(JSC::Wasm::CodeBlock::create):
* wasm/WasmModule.cpp:
(JSC::Wasm::makeValidationCallback):
(JSC::Wasm::Module::validateSync):
(JSC::Wasm::Module::validateAsync):
(JSC::Wasm::Module::getOrCreateCodeBlock):
(JSC::Wasm::Module::compileSync):
(JSC::Wasm::Module::compileAsync):
* wasm/WasmModule.h:
* wasm/WasmOMGPlan.cpp:
(JSC::Wasm::OMGPlan::OMGPlan):
(JSC::Wasm::runOMGPlanForIndex):
* wasm/WasmOMGPlan.h:
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::Plan):
(JSC::Wasm::Plan::runCompletionTasks):
(JSC::Wasm::Plan::addCompletionTask):
(JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast):
* wasm/WasmPlan.h:
(JSC::Wasm::Plan::dontFinalize):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance):
* wasm/js/WebAssemblyPrototype.cpp:
(JSC::webAssemblyValidateFunc):
2017-04-27 Saam Barati <sbarati@apple.com>
Restore some caching functionality that got accidentally removed when doing Wasm PIC patches
https://bugs.webkit.org/show_bug.cgi?id=171382
Reviewed by Keith Miller.
When I created Wasm::CodeBlock, I accidentally removed caching
the creation of JSWebAssemblyCodeBlocks. This patch restores it.
It's worth keeping JSWebAssemblyModule's JSWebAssemblyCodeBlock
cache because creating a JSWebAssemblyCodeBlock does non trivial
work by creating the various IC call stubs.
* wasm/js/JSWebAssemblyCodeBlock.h:
(JSC::JSWebAssemblyCodeBlock::codeBlock):
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::finalizeCreation):
(JSC::JSWebAssemblyInstance::create):
* wasm/js/JSWebAssemblyModule.h:
2017-04-27 Mark Lam <mark.lam@apple.com>
Audit and fix incorrect uses of JSArray::tryCreateForInitializationPrivate().
https://bugs.webkit.org/show_bug.cgi?id=171344
<rdar://problem/31352667>
Reviewed by Filip Pizlo.
JSArray::tryCreateForInitializationPrivate() should only be used in performance
critical paths, and should always be used with care because it creates an
uninitialized object that needs to be initialized by its client before the object
can be released into the system. Before the object is fully initialized:
a. the client should not re-enter the VM to execute JS code, and
b. GC should not run.
This is because until the object is fully initialized, it is an inconsistent
state that the GC and JS code will not be happy about.
In this patch, we do the following:
1. Renamed JSArray::tryCreateForInitializationPrivate() to
JSArray::tryCreateUninitializedRestricted() because "private" is a bit ambiguous
and can be confused with APIs that are called freely within WebKit but are
not meant for clients of WebKit. In this case, we intend for use of this API
to be restricted to only a few carefully considered and crafted cases.
2. Introduce the ObjectInitializationScope RAII object which covers the period
when the uninitialized object is created and gets initialized.
ObjectInitializationScope will asserts that either the object is created
fully initialized (in the case where the object structure is not an "original"
structure) or if created uninitialized, is fully initialized at the end of
the scope.
If the object is created uninitialized, the ObjectInitializationScope also
ensures that we do not GC nor re-enter the VM to execute JS code. This is
achieved by enabling DisallowGC and DisallowVMReentry scopes.
tryCreateUninitializedRestricted() and initializeIndex() now requires an
ObjectInitializationScope instance. The ObjectInitializationScope replaces
the VM& argument because it can be used to pass the VM& itself. This is a
small optimization that makes passing the ObjectInitializationScope free even
on release builds.
3. Factored a DisallowScope out of DisallowGC, and make DisallowGC extend it.
Introduce a DisallowVMReentry class that extends DisallowScope.
4. Fixed a bug found by the ObjectInitializationScope. The bug is that there are
scenarios where the structure passed to tryCreateUninitializedRestricted()
that may not be an "original" structure. As a result, initializeIndex() would
end up allocating new structures, and therefore trigger a GC.
The fix is to detect that the structure passed to tryCreateUninitializedRestricted()
is not an "original" one, and pre-initialize the array with 0s.
This bug was detected by existing tests. Hence, no new test needed.
5. Replaced all inappropriate uses of tryCreateUninitializedRestricted() with
tryCreate(). Inappropriate uses here means code that is not in performance
critical paths.
Similarly, replaced accompanying uses of initializeIndex() with putDirectIndex().
This patch is performance neutral (according to the JSC command line benchmarks).
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGOperations.cpp:
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
* heap/DeferGC.cpp:
* heap/DeferGC.h:
(JSC::DisallowGC::DisallowGC):
(JSC::DisallowGC::initialize):
(JSC::DisallowGC::scopeReentryCount):
(JSC::DisallowGC::setScopeReentryCount):
(JSC::DisallowGC::~DisallowGC): Deleted.
(JSC::DisallowGC::isGCDisallowedOnCurrentThread): Deleted.
* heap/GCDeferralContextInlines.h:
(JSC::GCDeferralContext::~GCDeferralContext):
* heap/Heap.cpp:
(JSC::Heap::collectIfNecessaryOrDefer):
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoPrivateFuncConcatMemcpy):
* runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::createWithInlineFrame):
(JSC::ClonedArguments::createByCopyingFrom):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/DisallowScope.h: Added.
(JSC::DisallowScope::DisallowScope):
(JSC::DisallowScope::~DisallowScope):
(JSC::DisallowScope::isInEffectOnCurrentThread):
(JSC::DisallowScope::enable):
(JSC::DisallowScope::enterScope):
(JSC::DisallowScope::exitScope):
* runtime/DisallowVMReentry.cpp: Added.
* runtime/DisallowVMReentry.h: Added.
(JSC::DisallowVMReentry::DisallowVMReentry):
(JSC::DisallowVMReentry::initialize):
(JSC::DisallowVMReentry::scopeReentryCount):
(JSC::DisallowVMReentry::setScopeReentryCount):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSArray.cpp:
(JSC::JSArray::tryCreateUninitializedRestricted):
(JSC::JSArray::fastSlice):
(JSC::JSArray::tryCreateForInitializationPrivate): Deleted.
* runtime/JSArray.h:
(JSC::JSArray::tryCreateUninitializedRestricted):
(JSC::JSArray::tryCreate):
(JSC::constructArray):
(JSC::constructArrayNegativeIndexed):
(JSC::JSArray::tryCreateForInitializationPrivate): Deleted.
(JSC::createArrayButterfly): Deleted.
* runtime/JSCellInlines.h:
(JSC::allocateCell):
* runtime/JSObject.h:
(JSC::JSObject::initializeIndex):
(JSC::JSObject::initializeIndexWithoutBarrier):
* runtime/ObjectInitializationScope.cpp: Added.
(JSC::ObjectInitializationScope::ObjectInitializationScope):
(JSC::ObjectInitializationScope::~ObjectInitializationScope):
(JSC::ObjectInitializationScope::notifyAllocated):
(JSC::ObjectInitializationScope::verifyPropertiesAreInitialized):
* runtime/ObjectInitializationScope.h: Added.
(JSC::ObjectInitializationScope::ObjectInitializationScope):
(JSC::ObjectInitializationScope::vm):
(JSC::ObjectInitializationScope::notifyAllocated):
* runtime/Operations.h:
(JSC::isScribbledValue):
(JSC::scribble):
* runtime/RegExpMatchesArray.cpp:
(JSC::createEmptyRegExpMatchesArray):
* runtime/RegExpMatchesArray.h:
(JSC::tryCreateUninitializedRegExpMatchesArray):
(JSC::createRegExpMatchesArray):
* runtime/VMEntryScope.cpp:
(JSC::VMEntryScope::VMEntryScope):
2017-04-27 Carlos Garcia Campos <cgarcia@igalia.com>
[GTK] Remote inspector should support inspecting targets with previous version of backend commands
https://bugs.webkit.org/show_bug.cgi?id=171267
Reviewed by Michael Catanzaro.
Rename GetTargetList DBus method as SetupInspectorClient since this method is actually called only once by
client right after connecting to the server. The method now receives the client backend commands hash as
argument and returns the contents of the backend commands file in case the hash doesn't match with the local
version.
* PlatformGTK.cmake: Add RemoteInspectorUtils to compilation.
* inspector/remote/glib/RemoteInspectorServer.cpp:
(Inspector::RemoteInspectorServer::setupInspectorClient):
* inspector/remote/glib/RemoteInspectorServer.h:
* inspector/remote/glib/RemoteInspectorUtils.cpp: Added.
(Inspector::backendCommands):
(Inspector::backendCommandsHash):
* inspector/remote/glib/RemoteInspectorUtils.h: Added.
2017-04-27 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Handle PhantomSpread in LoadVarargs as the same to the others
https://bugs.webkit.org/show_bug.cgi?id=171262
Reviewed by Saam Barati.
This is follow-up patch after r215720. In that patch, accidentally
we did not apply the same change to LoadVarargs in argument elimination
phase. This patch just does the same rewriting to handle PhantomSpread
correctly.
* dfg/DFGArgumentsEliminationPhase.cpp:
2017-04-26 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Uint8ClampedArray should be treated like an array, not an object
https://bugs.webkit.org/show_bug.cgi?id=171364
<rdar://problem/10873037>
Reviewed by Sam Weinig.
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::subtype):
Treat Uint8ClampedArray (like other Typed Arrays) as an array.
2017-04-26 Saam Barati <sbarati@apple.com>
Print Wasm function index in stack trace
https://bugs.webkit.org/show_bug.cgi?id=171349
Reviewed by JF Bastien.
This patch prints a Callee's index in the function index
space in Error.stack.
This will lead to stack traces that have lines of text like:
wasm function index: 4@[wasm code]
We don't ascribe indices to everything in wasm. Specifically, the
Wasm->JS call stub callee does not get a name, and neither does
the JS -> Wasm entrypoint.
* interpreter/Interpreter.cpp:
(JSC::GetStackTraceFunctor::operator()):
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::readNonInlinedFrame):
(JSC::StackVisitor::Frame::functionName):
* interpreter/StackVisitor.h:
(JSC::StackVisitor::Frame::wasmFunctionIndex):
* runtime/StackFrame.cpp:
(JSC::StackFrame::functionName):
* runtime/StackFrame.h:
(JSC::StackFrame::StackFrame):
(JSC::StackFrame::wasm):
(JSC::StackFrame::hasBytecodeOffset):
(JSC::StackFrame::bytecodeOffset):
* wasm/WasmBBQPlanInlines.h:
(JSC::Wasm::BBQPlan::initializeCallees):
* wasm/WasmCallee.cpp:
(JSC::Wasm::Callee::Callee):
* wasm/WasmCallee.h:
(JSC::Wasm::Callee::create):
(JSC::Wasm::Callee::index):
* wasm/WasmOMGPlan.cpp:
(JSC::Wasm::OMGPlan::work):
2017-04-26 Keith Miller <keith_miller@apple.com>
Follow up to r215843
https://bugs.webkit.org/show_bug.cgi?id=171361
Reviewed by Saam Barati.
This patch fixes some style comments Saam didn't get a chance to
request before I landed: https://bugs.webkit.org/show_bug.cgi?id=170134.
It renames Wasm::CodeBlock::m_wasmEntrypoints to
m_wasmIndirectCallEntrypoints, as well as fixes some copyrights and
indentation.
* wasm/WasmBBQPlan.cpp:
* wasm/WasmCodeBlock.cpp:
(JSC::Wasm::CodeBlock::CodeBlock):
* wasm/WasmCodeBlock.h:
(JSC::Wasm::CodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace):
* wasm/WasmOMGPlan.cpp:
(JSC::Wasm::OMGPlan::work):
* wasm/WasmTierUpCount.h:
(JSC::Wasm::TierUpCount::TierUpCount):
(JSC::Wasm::TierUpCount::loopDecrement):
(JSC::Wasm::TierUpCount::functionEntryDecrement):
(JSC::Wasm::TierUpCount::shouldStartTierUp):
(JSC::Wasm::TierUpCount::count):
2017-04-26 Saam Barati <sbarati@apple.com>
ASSERTION FAILED: inIndex != notFound in JSC::invalidParameterInSourceAppender()
https://bugs.webkit.org/show_bug.cgi?id=170924
<rdar://problem/31721052>
Reviewed by Mark Lam.
The error message handler for "in" was searching for the literal
string "in". However, our parser incorrectly allows escaped characters
to be part of keywords. So this is parsed as "in" in JSC: "i\u006E".
It should not be parsed that way. I opened https://bugs.webkit.org/show_bug.cgi?id=171310
to address this issue.
Regardless, the error message handlers should handle unexpected text gracefully.
All functions that try to augment error messages with the goal of
providing a more textual context for the error message should use
the original error message instead of crashing when they detect
unexpected text.
This patch also changes the already buggy code that tries to find
the base of a function call. That could would fail for code like this:
"zoo.bar("/abc\)*/");". See https://bugs.webkit.org/show_bug.cgi?id=146304
It would think that the base is "z". However, the algorithm that tries
to find the base can often tell when it fails, and when it does, it should
happily return the approximate text error message instead of thinking
that the base is "z".
* runtime/ExceptionHelpers.cpp:
(JSC::functionCallBase):
(JSC::notAFunctionSourceAppender):
(JSC::invalidParameterInSourceAppender):
2017-04-26 Keith Miller <keith_miller@apple.com>
WebAssembly: Implement tier up
https://bugs.webkit.org/show_bug.cgi?id=170134
Reviewed by Filip Pizlo.
This patch implements tier up for wasm functions. Unlike with JS
code, wasm code needs to be able to tier up concurrently with the
running code. Since JS code is synchronous we can always link on
the running thread, wasm, however, can run the same code on more
than one thread. In order to make patching work correctly, we need
to ensure that all patches of callsites are aligned. On ARM we get
this for free since every call is a near call. On X86 we ensure
that the 32-bit relative offset is 32-bit aligned.
This patch also modifies how Wasm::Plan works. Now Plan is a
abstract super class and there are two subclasses, which
correspond to the different tiers of our wasm engine. The first,
Build Bytecode Quickly (BBQ) tier, roughly does what the old plan
code did before. The new tier, Optimized Machine code Generation
(OMG), can be called at any point by BBQ code and compiles exactly
one function. Once an OMGPlan finishes it will link it's code
internally then reset the instruction cache of all running wasm
threads, via, a ThreadMessage. Once the instruction caches have
been reset all the other functions will be patched to call the new
code.
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::ensureCacheLineSpace):
* assembler/CodeLocation.h:
(JSC::CodeLocationThreadSafeNearCall::CodeLocationThreadSafeNearCall):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::threadSafePatchableNearCall):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::threadSafeNearCall):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::threadSafePatchableNearCall):
* b3/air/AirEmitShuffle.cpp:
(JSC::B3::Air::ShufflePair::inst):
(JSC::B3::Air::ShufflePair::opcode): Deleted.
* b3/air/AirEmitShuffle.h:
* jsc.cpp:
(functionTestWasmModuleFunctions):
* runtime/JSLock.cpp:
(JSC::JSLock::didAcquireLock):
* runtime/Options.h:
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::materializeWasmContext):
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::B3IRGenerator::constant):
(JSC::Wasm::B3IRGenerator::emitTierUpCheck):
(JSC::Wasm::B3IRGenerator::addLoop):
(JSC::Wasm::B3IRGenerator::addTopLevel):
(JSC::Wasm::B3IRGenerator::addBlock):
(JSC::Wasm::createJSToWasmWrapper):
(JSC::Wasm::parseAndCompile):
* wasm/WasmB3IRGenerator.h:
* wasm/WasmBBQPlan.cpp: Copied from Source/JavaScriptCore/wasm/WasmPlan.cpp.
(JSC::Wasm::BBQPlan::BBQPlan):
(JSC::Wasm::BBQPlan::stateString):
(JSC::Wasm::BBQPlan::moveToState):
(JSC::Wasm::BBQPlan::parseAndValidateModule):
(JSC::Wasm::BBQPlan::prepare):
(JSC::Wasm::BBQPlan::ThreadCountHolder::ThreadCountHolder):
(JSC::Wasm::BBQPlan::ThreadCountHolder::~ThreadCountHolder):
(JSC::Wasm::BBQPlan::compileFunctions):
(JSC::Wasm::BBQPlan::complete):
(JSC::Wasm::BBQPlan::work):
* wasm/WasmBBQPlan.h: Copied from Source/JavaScriptCore/wasm/WasmPlan.h.
* wasm/WasmBBQPlanInlines.h: Copied from Source/JavaScriptCore/wasm/WasmPlanInlines.h.
(JSC::Wasm::BBQPlan::initializeCallees):
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToWasm):
* wasm/WasmCallee.h:
(JSC::Wasm::Callee::entrypoint):
* wasm/WasmCodeBlock.cpp:
(JSC::Wasm::CodeBlock::CodeBlock):
* wasm/WasmCodeBlock.h:
(JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
(JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
(JSC::Wasm::CodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace):
(JSC::Wasm::CodeBlock::tierUpCount):
(JSC::Wasm::CodeBlock::mode):
* wasm/WasmFormat.h:
(JSC::Wasm::CallableFunction::CallableFunction):
(JSC::Wasm::CallableFunction::offsetOfWasmEntrypointLoadLocation):
* wasm/WasmMachineThreads.cpp: Copied from Source/JavaScriptCore/wasm/WasmPlanInlines.h.
(JSC::Wasm::wasmThreads):
(JSC::Wasm::startTrackingCurrentThread):
(JSC::Wasm::resetInstructionCacheOnAllThreads):
* wasm/WasmMachineThreads.h: Copied from Source/JavaScriptCore/wasm/WasmCallee.h.
* wasm/WasmModule.cpp:
(JSC::Wasm::makeValidationResult):
(JSC::Wasm::makeValidationCallback):
(JSC::Wasm::Module::validateSync):
(JSC::Wasm::Module::validateAsync):
* wasm/WasmModule.h:
(JSC::Wasm::Module::codeBlockFor):
* wasm/WasmOMGPlan.cpp: Added.
(JSC::Wasm::OMGPlan::OMGPlan):
(JSC::Wasm::OMGPlan::work):
(JSC::Wasm::runOMGPlanForIndex):
* wasm/WasmOMGPlan.h: Copied from Source/JavaScriptCore/wasm/WasmPlanInlines.h.
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::Plan):
(JSC::Wasm::Plan::runCompletionTasks):
(JSC::Wasm::Plan::addCompletionTask):
(JSC::Wasm::Plan::waitForCompletion):
(JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast):
(JSC::Wasm::Plan::fail):
(JSC::Wasm::Plan::stateString): Deleted.
(JSC::Wasm::Plan::moveToState): Deleted.
(JSC::Wasm::Plan::parseAndValidateModule): Deleted.
(JSC::Wasm::Plan::prepare): Deleted.
(JSC::Wasm::Plan::ThreadCountHolder::ThreadCountHolder): Deleted.
(JSC::Wasm::Plan::ThreadCountHolder::~ThreadCountHolder): Deleted.
(JSC::Wasm::Plan::compileFunctions): Deleted.
(JSC::Wasm::Plan::complete): Deleted.
* wasm/WasmPlan.h:
(JSC::Wasm::Plan::exports): Deleted.
(JSC::Wasm::Plan::internalFunctionCount): Deleted.
(JSC::Wasm::Plan::takeModuleInformation): Deleted.
(JSC::Wasm::Plan::takeCallLinkInfos): Deleted.
(JSC::Wasm::Plan::takeWasmToWasmExitStubs): Deleted.
(JSC::Wasm::Plan::hasWork): Deleted.
(JSC::Wasm::Plan::hasBeenPrepared): Deleted.
* wasm/WasmTierUpCount.h: Renamed from Source/JavaScriptCore/wasm/WasmPlanInlines.h.
(JSC::Wasm::TierUpCount::TierUpCount):
(JSC::Wasm::TierUpCount::loopDecrement):
(JSC::Wasm::TierUpCount::functionEntryDecrement):
(JSC::Wasm::TierUpCount::shouldStartTierUp):
(JSC::Wasm::TierUpCount::count):
* wasm/WasmWorklist.cpp:
* wasm/WasmWorklist.h:
(JSC::Wasm::Worklist::nextTicket):
* wasm/js/JSWebAssemblyCodeBlock.cpp:
* wasm/js/JSWebAssemblyCodeBlock.h:
(JSC::JSWebAssemblyCodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace):
(JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport):
(JSC::JSWebAssemblyCodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace): Deleted.
* wasm/js/JSWebAssemblyTable.cpp:
(JSC::JSWebAssemblyTable::setFunction):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::create):
(JSC::WebAssemblyFunction::WebAssemblyFunction):
* wasm/js/WebAssemblyFunction.h:
(JSC::WebAssemblyFunction::signatureIndex):
(JSC::WebAssemblyFunction::wasmEntrypointLoadLocation):
(JSC::WebAssemblyFunction::callableFunction):
(JSC::WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation):
(JSC::WebAssemblyFunction::wasmEntrypoint): Deleted.
(JSC::WebAssemblyFunction::offsetOfWasmEntrypoint): Deleted.
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
(JSC::WebAssemblyModuleRecord::evaluate):
* wasm/js/WebAssemblyPrototype.cpp:
(JSC::webAssemblyValidateFunc):
* wasm/js/WebAssemblyWrapperFunction.cpp:
(JSC::WebAssemblyWrapperFunction::WebAssemblyWrapperFunction):
(JSC::WebAssemblyWrapperFunction::create):
* wasm/js/WebAssemblyWrapperFunction.h:
(JSC::WebAssemblyWrapperFunction::signatureIndex):
(JSC::WebAssemblyWrapperFunction::wasmEntrypointLoadLocation):
(JSC::WebAssemblyWrapperFunction::callableFunction):
(JSC::WebAssemblyWrapperFunction::wasmEntrypoint): Deleted.
2017-04-26 Caitlin Potter <caitp@igalia.com>
[JSC] fix RETURN_IF_EXCEPTION() placement in ownPropertyKeys()
https://bugs.webkit.org/show_bug.cgi?id=171330
Reviewed by Mark Lam.
Ensure RETURN_IF_EXCEPTION() following invokation of the
filterPropertyIfNeeded() lambda.
* runtime/ObjectConstructor.cpp:
(JSC::ownPropertyKeys):
2017-04-26 Caitlin Potter <caitp@igalia.com>
[JSC] Object.keys() must discard property names with no PropertyDescriptor
https://bugs.webkit.org/show_bug.cgi?id=171291
Reviewed by Yusuke Suzuki.
Proxy objects can produce an arbitrary list of property names from the
"ownKeys" trap, however the Object.keys() algorithm is required to
discard names which do not have a PropertyDescriptor. This also
applies to other uses of the EnumerableOwnProperties() algorithm
(https://tc39.github.io/ecma262/#sec-enumerableownproperties)
Related to https://bugs.chromium.org/p/v8/issues/detail?id=6290
* runtime/ObjectConstructor.cpp:
(JSC::ownPropertyKeys):
2017-04-25 Andy VanWagoner <thetalecrafter@gmail.com>
Unhandled enumeration values in IntlDateTimeFormat.cpp
https://bugs.webkit.org/show_bug.cgi?id=171241
Reviewed by JF Bastien.
Added some missing cases of the UDateFormatField to partTypeString,
and made them conditional to the ICU version that added them.
This should remove the warnings that appear on platform builds using the
newer system ICU headers.
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::partTypeString):
2017-04-25 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r215476.
https://bugs.webkit.org/show_bug.cgi?id=171304
"It broke JSBench" (Requested by saamyjoon on #webkit).
Reverted changeset:
"[ES6]. Implement Annex B.3.3 function hoisting rules for
eval"
https://bugs.webkit.org/show_bug.cgi?id=163208
http://trac.webkit.org/changeset/215476
2017-04-25 Saam Barati <sbarati@apple.com>
JSArray::isArrayPrototypeIteratorProtocolFastAndNonObservable is wrong because it does not do the necessary checks on the base object
https://bugs.webkit.org/show_bug.cgi?id=171150
<rdar://problem/31771880>
Reviewed by Sam Weinig.
This patch fixes a huge oversight from the patch that introduced
op_spread/Spread. The original patch did not account for the
base object having Symbol.iterator or getters that could
change the iterator protocol. This patch fixes the oversight both
in the C code, as well as the DFG/FTL backends. We only perform
the memcpy version of spread if we've proven that it's guaranteed
to be side-effect free (no indexed getters), and if the iterator
protocol is guaranteed to be the original protocol. To do this, we
must prove that:
1. The protocol on Array.prototype hasn't changed (this is the same as the
introductory patch for op_spread).
2. The base object's __proto__ is Array.prototype
3. The base object does not have indexed getters
4. The base object does not have Symbol.iterator property.
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::canDoFastSpread):
* dfg/DFGGraph.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileSpread):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileSpread):
* runtime/JSArray.cpp:
(JSC::JSArray::isIteratorProtocolFastAndNonObservable):
* runtime/JSArray.h:
* runtime/JSArrayInlines.h:
(JSC::JSArray::isIteratorProtocolFastAndNonObservable): Deleted.
* runtime/JSGlobalObject.h:
* runtime/JSGlobalObjectInlines.h:
(JSC::JSGlobalObject::isArrayPrototypeIteratorProtocolFastAndNonObservable):
(JSC::JSGlobalObject::isArrayIteratorProtocolFastAndNonObservable): Deleted.
2017-04-25 Mark Lam <mark.lam@apple.com>
Array.prototype.slice() should ensure that end >= begin.
https://bugs.webkit.org/show_bug.cgi?id=170989
<rdar://problem/31705652>
Reviewed by Saam Barati.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncSlice):
2017-04-25 Don Olmstead <don.olmstead@am.sony.com>
[Win] Use Clang's __has_declspec_attribute for export macros
https://bugs.webkit.org/show_bug.cgi?id=171240
Reviewed by Alex Christensen.
* runtime/JSExportMacros.h:
2017-04-25 Saam Barati <sbarati@apple.com>
Unreviewed. Attempt armv7k build fix after r215720
I think we're just missing an include for the definition of ExecState::r().
* runtime/JSFixedArray.cpp:
2017-04-25 Daniel Bates <dabates@apple.com>
[Cocoa][Win] Enable of X-Content-Type-Options: nosniff header
https://bugs.webkit.org/show_bug.cgi?id=136452
<rdar://problem/23412620>
Reviewed by Brent Fulgham.
Enable X-Content-Type-Options: nosniff on Mac, iOS and Windows platforms.
* Configurations/FeatureDefines.xcconfig:
2017-04-25 Mark Lam <mark.lam@apple.com>
Local CSE wrongly CSEs array accesses with different result types.
https://bugs.webkit.org/show_bug.cgi?id=170990
<rdar://problem/31705945>
Reviewed by Saam Barati.
The fix is to use different LocationKind enums for the different type of array
result types. This makes the HeapLocation values different based on the result
types, and allows CSE to discern between them.
* dfg/DFGCSEPhase.cpp:
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGHeapLocation.h:
(JSC::DFG::indexedPropertyLocForResultType):
2017-04-25 Mark Lam <mark.lam@apple.com>
Make DFG SpeculatedType dumps easier to read.
https://bugs.webkit.org/show_bug.cgi?id=171280
Reviewed by Saam Barati.
Adding a pretty printer to insert |s between each type string and changing the
dumped strings to match the SpeculatedType names case-wise.
* bytecode/SpeculatedType.cpp:
(JSC::PrettyPrinter::PrettyPrinter):
(JSC::PrettyPrinter::print):
(JSC::dumpSpeculation):
* bytecode/SpeculatedType.h:
2017-04-25 JF Bastien <jfbastien@apple.com>
lowerStackArgs: check Arg::addr.isValidForm when falling back to SP offsets
https://bugs.webkit.org/show_bug.cgi?id=171278
Reviewed by Filip Pizlo.
lowerStackArgs checked that the FP offsets it tries to generate
are valid form, but didn't check that the fallback was valid
form. This lead to stackAddr's assertion being dead, and the
MaroAssembler asserting way later on move / add when handed a huge
immediate.
* b3/air/AirArg.cpp:
(JSC::B3::Air::Arg::stackAddrImpl):
2017-04-25 Zan Dobersek <zdobersek@igalia.com>
[aarch64] moveConditionally32(), moveConditionallyTest32() should move from/to 64-bit registers
https://bugs.webkit.org/show_bug.cgi?id=170891
Reviewed by Saam Barati.
moveConditionally32() and moveConditionallyTest32() operations in
MacroAssemblerARM64 properly perform comparisons and tests on 32-bit
values, but end up performing the moves from and to 32-bit registers.
Move operations should instead be done on 64-bit registers, just like
on the X86_64 platform. This is achieved by specifying 64 as the data
size for the csel instructions.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::moveConditionally32):
(JSC::MacroAssemblerARM64::moveConditionallyTest32):
2017-04-24 Joseph Pecoraro <pecoraro@apple.com>
test262: test262/test/language/expressions/object/method-definition/early-errors-object-method-duplicate-parameters.js
https://bugs.webkit.org/show_bug.cgi?id=171190
Reviewed by Saam Barati.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
(JSC::BytecodeGenerator::emitNewFunction):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionNode::emitBytecode):
(JSC::Scope::setSourceParseMode):
* parser/ParserModes.h:
(JSC::isFunctionParseMode):
(JSC::isMethodParseMode):
(JSC::isGeneratorOrAsyncFunctionWrapperParseMode):
(JSC::isGeneratorParseMode):
(JSC::isGeneratorWrapperParseMode):
* runtime/FunctionExecutable.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::getOwnPropertySlot):
Add a new GeneratorWrapperMethodMode parse mode. The other function types
(async, arrow) already have a FunctionMode and a MethodMode. Give
generators one as well. This lets isMethodParseMode actually be accurate.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::isArrowFunctionParameters):
(JSC::Parser<LexerType>::parseFormalParameters):
(JSC::stringForFunctionMode):
(JSC::Parser<LexerType>::parseFunctionParameters):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parsePropertyMethod):
* parser/Parser.h:
Add a duplicate parameter failure if there are duplicate parameters
in method syntax.
2017-04-24 Andy VanWagoner <thetalecrafter@gmail.com>
Clean up ICU headers
https://bugs.webkit.org/show_bug.cgi?id=170997
Reviewed by JF Bastien.
Update all icu headers to 55.1
* icu/LICENSE: Update copyright
* icu/README: Explain ICU headers for OS X better
* icu/unicode/localpointer.h:
(LocalPointer::LocalPointer):
(LocalPointer::adoptInsteadAndCheckErrorCode):
* icu/unicode/platform.h:
* icu/unicode/putil.h:
* icu/unicode/ucal.h:
* icu/unicode/uchar.h:
* icu/unicode/ucnv.h:
* icu/unicode/ucol.h:
* icu/unicode/uconfig.h:
* icu/unicode/ucurr.h:
* icu/unicode/udatpg.h:
* icu/unicode/udisplaycontext.h:
* icu/unicode/uformattable.h:
* icu/unicode/uloc.h:
* icu/unicode/umachine.h:
* icu/unicode/unum.h:
* icu/unicode/unumsys.h:
* icu/unicode/urename.h:
* icu/unicode/uscript.h:
* icu/unicode/uset.h:
* icu/unicode/ustring.h:
* icu/unicode/utf8.h:
* icu/unicode/utypes.h:
2017-04-24 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Use JSFixedArray directly when using call_varargs
https://bugs.webkit.org/show_bug.cgi?id=171057
Reviewed by Saam Barati.
Previously we always emit new_array_with_spread when calling call(...args).
But this array is unnecessary if varargs operation can handle Spread directly.
This patch implements a peep-hole optimization in the bytecode compiler layer
to omit new_array_with_spread. This is very simple and effective because this
peep-hole optimization is quite common when using (...args) style calls and
this optimization works all the tiers. While we can implement the phase to
omit this NewArrayWithSpread in argument elimination phase, it only works
for FTL. While such an optimization can work with complex data flow, this
peep-hole optimization can optimize a common case easily.
For now, Spread and PhantomSpread can be directly drained by CallVarargs
and LoadVarargs related operations. We modify DFG and FTL to handle this correctly.
This shows six-speed improvement.
spread.es6 89.4300+-2.0236 ^ 69.6015+-1.7278 ^ definitely 1.2849x faster
spread-generator.es6 344.7879+-5.9147 ^ 331.2712+-6.8610 ^ definitely 1.0408x faster
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitCall):
(JSC::BytecodeGenerator::emitConstruct):
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGPreciseLocalClobberize.h:
(JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
(JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
(JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargsWithSpread):
* interpreter/Interpreter.cpp:
(JSC::sizeOfVarargs):
(JSC::loadVarargs):
* parser/Nodes.h:
(JSC::ArrayNode::elements):
* runtime/JSFixedArray.cpp:
(JSC::JSFixedArray::copyToArguments):
* runtime/JSFixedArray.h:
2017-04-24 Yusuke Suzuki <utatane.tea@gmail.com>
[WTF] Move JSC tools/StackTrace to WTF and unify stack trace dump code
https://bugs.webkit.org/show_bug.cgi?id=171199
Reviewed by Mark Lam.
This patch adds a utility method to produce demangled names with dladdr.
It fixes several memory leaks because the result of abi::__cxa_demangle()
needs to be `free`-ed.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace):
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::StackFrame::displayName):
* tools/CellProfile.h:
* tools/CodeProfile.cpp:
(JSC::CodeProfile::report):
(JSC::symbolName): Deleted.
2017-04-24 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: ObjC RWIProtocol codegen should better handle optional members
https://bugs.webkit.org/show_bug.cgi?id=171251
<rdar://problem/31697002>
Reviewed by Brian Burg.
* inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
(ObjCProtocolTypesImplementationGenerator._generate_getter_for_member):
* inspector/scripts/codegen/objc_generator.py:
(ObjCGenerator.protocol_to_objc_expression_for_member):
(ObjCGenerator.protocol_to_objc_code_block_for_object_member):
Always be safe and nil check object property accesses, optional or not.
* inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
Rebaselined inspector generator tests.
2017-04-24 Saam Barati <sbarati@apple.com>
ASSERTION FAILED: m_table seen with workers/wasm-hashset LayoutTests
https://bugs.webkit.org/show_bug.cgi?id=171119
<rdar://problem/31760635>
Reviewed by Keith Miller.
The HashSet of timer set notification callbacks can be accessed
and augmented simultaneously from different threads. e.g, the worker
thread can augment it while the wasm compilation thread will
access it. Therefore, accesses must be guarded by a lock.
* runtime/JSRunLoopTimer.cpp:
(JSC::JSRunLoopTimer::scheduleTimer):
(JSC::JSRunLoopTimer::addTimerSetNotification):
(JSC::JSRunLoopTimer::removeTimerSetNotification):
* runtime/JSRunLoopTimer.h:
2017-04-24 Joseph Pecoraro <pecoraro@apple.com>
test262: test262/test/language/computed-property-names/class/static/getter-prototype.js
https://bugs.webkit.org/show_bug.cgi?id=170897
Reviewed by Saam Barati.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createArguments):
(JSC::ASTBuilder::createArgumentsList):
Reorder so all the createProperty methods are grouped together.
* parser/Parser.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseProperty):
(JSC::Parser<LexerType>::parseGetterSetter):
Refine the conditions for syntax errors for getter/setter
properties names. "prototype" is not allowed as a static
and "constructor" is not all when non-static.
* runtime/JSObject.cpp:
(JSC::JSObject::putGetter):
(JSC::JSObject::putSetter):
Throw exceptions. These methods are only used by this path
via op_put_getter_by_val / op_put_setter_by_val.
2017-04-24 Joseph Pecoraro <pecoraro@apple.com>
test262: test262/test/language/statements/for-of/dstr-array-elem-init-fn-name-arrow.js
https://bugs.webkit.org/show_bug.cgi?id=171160
Reviewed by JF Bastien.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::tryInferNameInPattern):
(JSC::ASTBuilder::tryInferNameInPatternWithIdentifier):
We supported getting the name from a BindingNode.
We extend this to support getting the name from a
ResolveNode inside of an AssignmentElementNode.
* parser/Nodes.h:
(JSC::DestructuringPatternNode::isAssignmentElementNode):
(JSC::AssignmentElementNode::isAssignmentElementNode):
Make it possible to identify an assignment element node.
2017-04-24 Alex Christensen <achristensen@webkit.org>
Reduce copies and allocations in SharedBuffer::append
https://bugs.webkit.org/show_bug.cgi?id=170956
Reviewed by Andreas Kling.
* runtime/ArrayBuffer.h:
2017-04-24 Carlos Garcia Campos <cgarcia@igalia.com>
[GTK] Switch to use ENABLE_REMOTE_INSPECTOR instead of ENABLE_INSPECTOR_SERVER for the remote inspector
https://bugs.webkit.org/show_bug.cgi?id=166680
Reviewed by Michael Catanzaro.
Add GTK+ port implementation of RemoteInspector.
* PlatformGTK.cmake:
* inspector/remote/RemoteConnectionToTarget.h:
* inspector/remote/RemoteInspector.h:
* inspector/remote/glib/RemoteConnectionToTargetGlib.cpp: Added.
(Inspector::RemoteConnectionToTarget::RemoteConnectionToTarget):
(Inspector::RemoteConnectionToTarget::~RemoteConnectionToTarget):
(Inspector::RemoteConnectionToTarget::setup):
(Inspector::RemoteConnectionToTarget::sendMessageToTarget):
(Inspector::RemoteConnectionToTarget::close):
(Inspector::RemoteConnectionToTarget::targetClosed):
(Inspector::RemoteConnectionToTarget::targetIdentifier):
(Inspector::RemoteConnectionToTarget::sendMessageToFrontend):
* inspector/remote/glib/RemoteInspectorGlib.cpp: Added.
(Inspector::RemoteInspector::singleton):
(Inspector::RemoteInspector::RemoteInspector):
(Inspector::RemoteInspector::start):
(Inspector::RemoteInspector::stopInternal):
(Inspector::RemoteInspector::setupConnection):
(Inspector::dbusConnectionCallAsyncReadyCallback):
(Inspector::RemoteInspector::listingForInspectionTarget):
(Inspector::RemoteInspector::listingForAutomationTarget):
(Inspector::RemoteInspector::pushListingsNow):
(Inspector::RemoteInspector::pushListingsSoon):
(Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
(Inspector::RemoteInspector::sendAutomaticInspectionCandidateMessage):
(Inspector::RemoteInspector::sendMessageToRemote):
(Inspector::RemoteInspector::receivedGetTargetListMessage):
(Inspector::RemoteInspector::receivedSetupMessage):
(Inspector::RemoteInspector::receivedDataMessage):
(Inspector::RemoteInspector::receivedCloseMessage):
(Inspector::RemoteInspector::setup):
(Inspector::RemoteInspector::sendMessageToTarget):
(Inspector::RemoteInspector::requestAutomationSession):
* inspector/remote/glib/RemoteInspectorServer.cpp: Added.
(Inspector::generateConnectionID):
(Inspector::RemoteInspectorServer::singleton):
(Inspector::RemoteInspectorServer::~RemoteInspectorServer):
(Inspector::RemoteInspectorServer::interfaceInfo):
(Inspector::RemoteInspectorServer::start):
(Inspector::RemoteInspectorServer::newConnectionCallback):
(Inspector::RemoteInspectorServer::connectionClosedCallback):
(Inspector::RemoteInspectorServer::newConnection):
(Inspector::dbusConnectionCallAsyncReadyCallback):
(Inspector::RemoteInspectorServer::setTargetList):
(Inspector::RemoteInspectorServer::clientConnectionClosedCallback):
(Inspector::RemoteInspectorServer::getTargetList):
(Inspector::RemoteInspectorServer::setup):
(Inspector::RemoteInspectorServer::close):
(Inspector::RemoteInspectorServer::clientConnectionClosed):
(Inspector::RemoteInspectorServer::connectionClosed):
(Inspector::RemoteInspectorServer::sendMessageToBackend):
(Inspector::RemoteInspectorServer::sendMessageToFrontend):
(Inspector::RemoteInspectorServer::startAutomationSession):
* inspector/remote/glib/RemoteInspectorServer.h: Added.
(Inspector::RemoteInspectorServer::isRunning):
2017-04-24 Joseph Pecoraro <pecoraro@apple.com>
test262: test262/test/language/expressions/generators/yield-as-label.js
https://bugs.webkit.org/show_bug.cgi?id=170979
Reviewed by Saam Barati.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseVariableDeclarationList):
(JSC::Parser<LexerType>::parseDestructuringPattern):
(JSC::Parser<LexerType>::parseFormalParameters):
Converge on "Cannot" instead of "Can't" in error messages.
(JSC::Parser<LexerType>::parseFunctionInfo):
Disallow "yield" as the generator function name in function expressions.
This refers to the difference between Declaration and Expression, where
only GeneratorExpression explicitly has [+Yield] disallowing yield for
the generator name:
GeneratorDeclaration[Yield, Await, Default]:
function * BindingIdentifier[?Yield, ?Await] ...
GeneratorExpression:
function * BindingIdentifier[+Yield, ~Await]opt ...
(JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
Disallow "yield" as a label name in strict mode or inside a generator.
(JSC::Parser<LexerType>::parseProperty):
Disallow "yield" or any keyword in object literal shorthands.
* parser/Parser.h:
(JSC::Parser::getToken):
(JSC::Parser::isDisallowedIdentifierLet):
(JSC::Parser::isDisallowedIdentifierYield):
(JSC::Parser::disallowedIdentifierLetReason):
(JSC::Parser::disallowedIdentifierYieldReason):
Follow pattern for improved error messages based on context.
2017-04-23 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r215674.
https://bugs.webkit.org/show_bug.cgi?id=171212
Possible unintended commit. This patch was on the wrong bug.
(Requested by JoePeck on #webkit).
Reverted changeset:
"test262: test262/test/language/expressions/generators/yield-
as-label.js"
https://bugs.webkit.org/show_bug.cgi?id=170979
http://trac.webkit.org/changeset/215674
2017-04-23 Joseph Pecoraro <pecoraro@apple.com>
test262: test262/test/built-ins/Number/prototype/toPrecision/nan.js
https://bugs.webkit.org/show_bug.cgi?id=171197
Reviewed by Saam Barati.
* runtime/NumberPrototype.cpp:
(JSC::numberProtoFuncToExponential):
(JSC::numberProtoFuncToFixed):
(JSC::numberProtoFuncToPrecision):
Refine the order of operations to match the spec.
2017-04-23 Joseph Pecoraro <pecoraro@apple.com>
test262: test262/test/language/expressions/generators/yield-as-label.js
https://bugs.webkit.org/show_bug.cgi?id=170979
Reviewed by Saam Barati.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseVariableDeclarationList):
(JSC::Parser<LexerType>::parseDestructuringPattern):
(JSC::Parser<LexerType>::parseFormalParameters):
Converge on "Cannot" instead of "Can't" in error messages.
(JSC::Parser<LexerType>::parseFunctionInfo):
Disallow "yield" as the generator function name in function expressions.
This refers to the difference between Declaration and Expression, where
only GeneratorExpression explicitly has [+Yield] disallowing yield for
the generator name:
GeneratorDeclaration[Yield, Await, Default]:
function * BindingIdentifier[?Yield, ?Await] ...
GeneratorExpression:
function * BindingIdentifier[+Yield, ~Await]opt ...
(JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
Disallow "yield" as a label name in strict mode or inside a generator.
(JSC::Parser<LexerType>::parseProperty):
Disallow "yield" or any keyword in object literal shorthands.
* parser/Parser.h:
(JSC::Parser::getToken):
(JSC::Parser::isDisallowedIdentifierLet):
(JSC::Parser::isDisallowedIdentifierYield):
(JSC::Parser::disallowedIdentifierLetReason):
(JSC::Parser::disallowedIdentifierYieldReason):
Follow pattern for improved error messages based on context.
2017-04-23 Joseph Pecoraro <pecoraro@apple.com>
test262: test262/test/built-ins/Number/parseFloat.js
https://bugs.webkit.org/show_bug.cgi?id=171193
Reviewed by Yusuke Suzuki.
* runtime/CommonIdentifiers.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::parseFloatFunction):
Expose parseFloat on the global object to be shared with Number constructor.
* runtime/NumberConstructor.cpp:
(JSC::NumberConstructor::finishCreation):
parseFloat uses the same value as the global parseFloat.
2017-04-22 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Use DoublyLinkedList for MachineThread
https://bugs.webkit.org/show_bug.cgi?id=171171
Reviewed by Mark Lam.
MachineThread can use WTF::DoublyLinkedList to simplify
its implementation. We should not use Vector<> etc. since
we do not want to call allocations during suspending and
resuming threads.
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::MachineThreads):
(JSC::MachineThreads::~MachineThreads):
(JSC::MachineThreads::addCurrentThread):
(JSC::MachineThreads::removeThreadIfFound):
(JSC::MachineThreads::MachineThread::MachineThread):
(JSC::MachineThreads::tryCopyOtherThreadStacks):
* heap/MachineStackMarker.h:
(JSC::MachineThreads::threadsListHead):
* runtime/SamplingProfiler.cpp:
(JSC::FrameWalker::isValidFramePointer):
* runtime/VMTraps.cpp:
(JSC::findActiveVMAndStackBounds):
2017-04-22 JF Bastien <jfbastien@apple.com>
WebAssembly: Module.exports, Module.imports, Module.customSections are wrong
https://bugs.webkit.org/show_bug.cgi?id=171078
Reviewed by Saam Barati.
They're static properties of Module, not instance properties of a module.
https://github.com/WebAssembly/design/blob/master/JS.md#webassemblymoduleexports
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::webAssemblyModuleCustomSections):
(JSC::webAssemblyModuleImports):
(JSC::webAssemblyModuleExports):
* wasm/js/WebAssemblyModulePrototype.cpp:
(JSC::webAssemblyModuleProtoCustomSections): Deleted.
(JSC::webAssemblyModuleProtoImports): Deleted.
(JSC::webAssemblyModuleProtoExports): Deleted.
2017-04-21 Saam Barati <sbarati@apple.com>
SharedArrayBuffer-opt.js fails with Briggs
https://bugs.webkit.org/show_bug.cgi?id=170948
<rdar://problem/31740568>
Reviewed by Michael Saboff.
The bug was not actually with Briggs, but instead was with
our X86-64 MacroAssembler. Michael fixed the bug here:
https://trac.webkit.org/changeset/215618/webkit
The issue was we weren't adding the REX byte for AtomicXchg8,
leading to the incorrect encoding for the result register depending
on which register it was. If you look at this code, you'll see the issue:
Int32 @38 = AtomicXchg(@59, @64, width = 8, range = 0, fenceRange = 0, ControlDependent|Fence|Writes:0|Reads:0, DFG:@49)
AtomicXchg8 %rsi, (%rax,%rdx), @38
0x2dcb5bc0015e: lock xchg %dh, (%rax,%rdx)
Int32 @66 = Const32(255, DFG:@49)
Int32 @67 = BitAnd(@38, $255(@66), DFG:@49)
ZeroExtend8To32 %rsi, %rax, @67
0x2dcb5bc00162: movzx %sil, %eax
Air thought the result was in the lower 8 bits of %rsi,
however, the code we emitted stored it in the [8-15] bits
of %rdx. Since this issue is fixed, I'm turning Briggs back
on.
* b3/air/AirAllocateRegistersByGraphColoring.h:
(JSC::B3::Air::useIRC):
2017-04-20 Mark Lam <mark.lam@apple.com>
Refactor MASM probe to allow printing of custom types.
https://bugs.webkit.org/show_bug.cgi?id=171101
Reviewed by JF Bastien.
For example, this allows us to add MASM printing of CodeBlock* and Air::Args.
In general, MASM print can be used like dataLog, except that it generates JITted
code for doing the dataLogging later when the JITted code runs. MASM print can
print any value type that a specialized Printer template or a setPrinter()
function implemented for that type.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/MacroAssembler.h:
* assembler/MacroAssemblerPrinter.cpp:
(JSC::Printer::printAllRegisters):
(JSC::Printer::printPCRegister):
(JSC::Printer::printRegisterID):
(JSC::Printer::printFPRegisterID):
(JSC::Printer::printAddress):
(JSC::Printer::printMemory):
(JSC::Printer::printCallback):
(JSC::printIndent): Deleted.
(JSC::printCPU): Deleted.
(JSC::printCPURegisters): Deleted.
(JSC::printPC): Deleted.
(JSC::printRegister): Deleted.
(JSC::printMemory): Deleted.
(JSC::MacroAssemblerPrinter::printCallback): Deleted.
* assembler/MacroAssemblerPrinter.h:
(JSC::AllRegisters::AllRegisters):
(JSC::Printer::Printer<AllRegisters>::Printer):
(JSC::Printer::Printer<PCRegister>::Printer):
(JSC::Printer::Printer<MacroAssembler::RegisterID>::Printer):
(JSC::Printer::Printer<MacroAssembler::FPRegisterID>::Printer):
(JSC::Printer::Printer<MacroAssembler::Address>::Printer):
(JSC::Printer::Printer<Memory>::Printer):
(JSC::Printer::Printer<MemWord<IntType>>::Printer):
(JSC::MacroAssembler::print):
(JSC::MacroAssemblerPrinter::print): Deleted.
(JSC::MacroAssemblerPrinter::PrintArg::PrintArg): Deleted.
(JSC::MacroAssemblerPrinter::appendPrintArg): Deleted.
- Refactored to move the underlying PrintRecord (and associated data structures)
out to Printer.cpp/h.
- MacroAssemblerPrinter.cpp/h now only add custom Printers for MASM types like
RegisterID and Memory. It also defines the implementation of
MacroAssembler::print().
As before, JIT code that wishes to use MacroAssembler::print() needs to
#include "MacroAssemblerPrinter.h".
- Also added the ability to specify an optional indentation (in number of chars)
when MASM printing AllRegisters. This is useful because AllRegisters prints
a block of data unlike other printers which print inline.
* assembler/Printer.cpp: Added.
(JSC::Printer::printConstCharString):
(JSC::Printer::printIntptr):
(JSC::Printer::printUintptr):
(JSC::Printer::printPointer):
(JSC::Printer::setPrinter):
* assembler/Printer.h: Added.
(JSC::Printer::Context::Context):
(JSC::Printer::PrintRecord::PrintRecord):
(JSC::Printer::appendPrinter):
(JSC::Printer::makePrintRecordList):
(JSC::Printer::Printer<RawPointer>::Printer):
(JSC::Printer::setPrinter):
(JSC::Printer::Printer::Printer):
- Data structures for creating a list of PrintRecords. Classes which wish to
add custom support for MASM printing can #include "Printer.h" and implement
either:
1. a specialized Printer template, or
2. a setPrinter() function.
See Printer<Reg> and Printer<B3::Air::Tmp> in AirPrintSpecial.h for examples of
(1). See CodeBlock's setPrinter() for an example of (2).
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::print):
* b3/air/AirPrintSpecial.cpp: Added.
(JSC::B3::Air::PrintSpecial::PrintSpecial):
(JSC::B3::Air::PrintSpecial::~PrintSpecial):
(JSC::B3::Air::PrintSpecial::forEachArg):
(JSC::B3::Air::PrintSpecial::isValid):
(JSC::B3::Air::PrintSpecial::admitsStack):
(JSC::B3::Air::PrintSpecial::reportUsedRegisters):
(JSC::B3::Air::PrintSpecial::generate):
(JSC::B3::Air::PrintSpecial::extraEarlyClobberedRegs):
(JSC::B3::Air::PrintSpecial::extraClobberedRegs):
(JSC::B3::Air::PrintSpecial::dumpImpl):
(JSC::B3::Air::PrintSpecial::deepDumpImpl):
(JSC::Printer::printAirArg):
* b3/air/AirPrintSpecial.h: Added.
(JSC::Printer::appendAirArg):
(JSC::Printer::appendAirArgs):
(JSC::Printer::Printer<B3::Air::Tmp>::Printer):
(JSC::Printer::Printer<Reg>::Printer):
- Add the print() operation for use in LowerToAir. print() will emit a
PrintSpecial that will ultimately emit a MASM print to print what we want.
- LowerToAir's print() adds the ability to print Air::Args.
- Unlike in the baseline JIT and the DFG, LowerToAir's print() can perturb the
usage of registers. This is because PrintSpecial is a patch point, and it
prevents certain optimizations. If not used carefully, an attempt to print()
an Arg by taking a Tmp, can force the B3 Value into a Tmp earlier than it would
otherwise do so. So, use LowerToAir's print() with care.
* bytecode/CodeBlock.cpp:
(JSC::setPrinter):
- Now we can MASM print CodeBlock*.
(WTF::printInternal):
- Now we can dataLog CodeBlock* (including null CodeBlock pointers).
* bytecode/CodeBlock.h:
* runtime/VM.cpp:
(JSC::VM::throwException):
- Use the new ability to dataLog CodeBlock*. No need to do an explicit null
check before printing anymore.
2017-04-21 Keith Miller <keith_miller@apple.com>
Unreviewed, rolling out r215634.
underlying build issues should have been fixed
Reverted changeset:
"Unreviewed, rolling out r215620 and r215623."
https://bugs.webkit.org/show_bug.cgi?id=171139
http://trac.webkit.org/changeset/215634
2017-04-21 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r215620 and r215623.
https://bugs.webkit.org/show_bug.cgi?id=171139
broke arm64 build (Requested by keith_miller on #webkit).
Reverted changesets:
"Add signaling API"
https://bugs.webkit.org/show_bug.cgi?id=170976
http://trac.webkit.org/changeset/215620
"Unreviewed, fix Cloop build."
http://trac.webkit.org/changeset/215623
2017-04-21 Keith Miller <keith_miller@apple.com>
Remove LL/SC from Atomics
https://bugs.webkit.org/show_bug.cgi?id=171141
Reviewed by Saam Barati.
Adding load link and store conditionally was not an actual progression
and the existing code is causing problems for users of Atomics. So let's
get rid of it.
* heap/LargeAllocation.h:
(JSC::LargeAllocation::testAndSetMarked):
* heap/MarkedBlock.h:
(JSC::MarkedBlock::testAndSetMarked):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
2017-04-21 Keith Miller <keith_miller@apple.com>
Unreviewed, fix Cloop build.
* jit/ExecutableAllocator.h:
(JSC::isJITPC):
2017-04-20 Keith Miller <keith_miller@apple.com>
Add signaling API
https://bugs.webkit.org/show_bug.cgi?id=170976
Reviewed by Filip Pizlo.
Update various uses of sigaction to use the new signaling API.
Also switch VMTraps to use the thread message system instead of
rolling it's own.
* jit/ExecutableAllocator.h:
(JSC::isJITPC):
* runtime/VMTraps.cpp:
(JSC::installSignalHandler):
(JSC::VMTraps::VMTraps):
(JSC::VMTraps::SignalSender::send):
(JSC::handleSigusr1): Deleted.
(JSC::handleSigtrap): Deleted.
(JSC::installSignalHandlers): Deleted.
* runtime/VMTraps.h:
* tools/SigillCrashAnalyzer.cpp:
(JSC::installCrashHandler):
(JSC::handleCrash): Deleted.
* wasm/WasmFaultSignalHandler.cpp:
(JSC::Wasm::trapHandler):
(JSC::Wasm::enableFastMemory):
2017-04-21 Michael Saboff <msaboff@apple.com>
X86-64 Assembler doesn't handle xchg with byte register src
https://bugs.webkit.org/show_bug.cgi?id=171118
Reviewed by Saam Barati.
* assembler/X86Assembler.h:
(JSC::X86Assembler::xchgb_rm): Use oneByteOp8() since these are 8 bit opcodes.
2017-04-21 Andy VanWagoner <thetalecrafter@gmail.com>
[INTL] Implement Intl.DateTimeFormat.prototype.formatToParts
https://bugs.webkit.org/show_bug.cgi?id=169458
Reviewed by JF Bastien.
Use udat_formatForFields to iterate through the parts of a formatted date string.
Make formatToParts and related functions dependent on ICU version >= 55.
* icu/unicode/udat.h: Update to 55.1.
* icu/unicode/ufieldpositer.h: Added from 55.1.
* icu/unicode/uvernum.h: Update to 55.1
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::partTypeString): Convert UDateFormatField to string.
(JSC::IntlDateTimeFormat::formatToParts): Return parts of formatted date string.
* runtime/IntlDateTimeFormat.h:
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::IntlDateTimeFormatPrototypeFuncFormatToParts): Add prototype function formatToParts.
2017-04-20 Konstantin Tokarev <annulen@yandex.ru>
[cmake] Define FORWARDING_HEADERS_DIR in WebKitFS and use it everywhere
https://bugs.webkit.org/show_bug.cgi?id=171071
Reviewed by Michael Catanzaro.
"${DERIVED_SOURCES_DIR}/ForwardingHeaders" path occurs very often in the
build system files. GTK-specifc FORWARDING_HEADERS_DIR variable should
be available for all ports.
* CMakeLists.txt:
* PlatformWin.cmake:
2017-04-20 Konstantin Tokarev <annulen@yandex.ru>
Remove unused lamda captures
https://bugs.webkit.org/show_bug.cgi?id=171098
Reviewed by Yusuke Suzuki.
* bytecompiler/NodesCodegen.cpp:
(JSC::ArrayNode::emitBytecode):
* ftl/FTLState.cpp:
(JSC::FTL::State::State):
* wasm/WasmB3IRGenerator.cpp:
2017-04-20 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC][FTL] FTL should support Arrayify
https://bugs.webkit.org/show_bug.cgi?id=169596
Reviewed by Saam Barati.
This patch simply expands the coverage of FTL by supporting Arrayify.
While ArrayifyToStructure is already supported, Arrayify is not supported
in FTL. While supporting Arrayify in FTL itself does not offer so much
performance difference from DFG's one, no FTL support for Arrayify
prevents us applying FTL to the code including Arrayify.
* dfg/DFGArrayMode.cpp:
(JSC::DFG::toIndexingShape):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileArrayify):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckArray):
(JSC::FTL::DFG::LowerDFGToB3::isArrayTypeForArrayify):
(JSC::FTL::DFG::LowerDFGToB3::isArrayTypeForCheckArray):
(JSC::FTL::DFG::LowerDFGToB3::compileArrayifyToStructure): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::isArrayType): Deleted.
2017-04-20 Mark Lam <mark.lam@apple.com>
virtualThunkFor() needs to materialize its of tagMaskRegister for tail calls.
https://bugs.webkit.org/show_bug.cgi?id=171079
<rdar://problem/31684756>
Reviewed by Saam Barati.
This is needed because tail calls would restore callee saved registers (and
therefore, potentially clobber the tag registers) before jumping to the thunk.
* jit/ThunkGenerators.cpp:
(JSC::virtualThunkFor):
2017-04-20 Mark Lam <mark.lam@apple.com>
Build fix after r215592.
https://bugs.webkit.org/show_bug.cgi?id=171088
Not reviewed.
* assembler/MacroAssemblerPrinter.h:
2017-04-20 Mark Lam <mark.lam@apple.com>
Update the MASM probe to only take 1 arg instead of 2 (in addition to the callback function).
https://bugs.webkit.org/show_bug.cgi?id=171088
Reviewed by Michael Saboff and Saam Barati.
Experience shows that we never use the 2nd arg. So, let's remove it to reduce
the footprint at each probe site.
Also fix the MacroAssembler::print() function so that it is a no-op when
!ENABLE(MASM_PROBE). This will allow us to have print() statements in JIT code
without a lot of #if ENABLE(MASM_PROBE)s later.
* assembler/AbstractMacroAssembler.h:
* assembler/MacroAssembler.cpp:
(JSC::stdFunctionCallback):
(JSC::MacroAssembler::probe):
* assembler/MacroAssembler.h:
* assembler/MacroAssemblerARM.cpp:
(JSC::MacroAssemblerARM::probe):
* assembler/MacroAssemblerARM.h:
* assembler/MacroAssemblerARM64.cpp:
(JSC::MacroAssemblerARM64::probe):
* assembler/MacroAssemblerARM64.h:
* assembler/MacroAssemblerARMv7.cpp:
(JSC::MacroAssemblerARMv7::probe):
* assembler/MacroAssemblerARMv7.h:
* assembler/MacroAssemblerPrinter.cpp:
(JSC::MacroAssemblerPrinter::printCallback):
* assembler/MacroAssemblerPrinter.h:
(JSC::MacroAssemblerPrinter::print):
(JSC::MacroAssembler::print):
* assembler/MacroAssemblerX86Common.cpp:
(JSC::MacroAssemblerX86Common::probe):
* assembler/MacroAssemblerX86Common.h:
2017-04-20 Matt Baker <mattbaker@apple.com>
Web Inspector: Add regular expression support to XHR breakpoints
https://bugs.webkit.org/show_bug.cgi?id=170099
<rdar://problem/31558082>
Reviewed by Joseph Pecoraro.
* inspector/protocol/DOMDebugger.json:
New optional `isRegex` parameter denotes whether `url` contains
a regular expression.
2017-04-15 Filip Pizlo <fpizlo@apple.com>
Optimize SharedArrayBuffer in the DFG+FTL
https://bugs.webkit.org/show_bug.cgi?id=164108
Reviewed by Saam Barati.
This adds atomics intrinsics to the DFG and wires them through to the DFG and FTL backends. This
was super easy in the FTL since B3 already has comprehensive atomic intrinsics, which are more
powerful than what we need right now. In the DFG backend, I went with an easy-to-write
implementation that just reduces everything to a weak CAS loop. It's very inefficient with
registers (it needs ~8) but it's the DFG backend, so it's not obvious how much we care.
To make the rare cases easy to handle, I refactored AtomicsObject.cpp so that the operations for
the slow paths can share code with the native functions.
This also fixes register handling in the X86 implementations of CAS, in the case that
expectedAndResult is not %rax. This also fixes the ARM64 implementation of branchWeakCAS.
I adapted the CascadeLock from WTF/benchmarks/ToyLocks.h as a microbenchmark of lock performance.
This benchmark performs 2.5x faster, in both the contended and uncontended case, thanks to this
change. It's still about 3x slower than native. I investigated this only a bit. I suspect that
the story will be different in asm.js code, which will get constant-folding of the typed array
backing store by virtue of how it uses lexically scoped variables as pointers to the heap arrays.
It's worth noting that the native lock I was comparing against, the very nicely-tuned
CascadeLock, is at the very high end of lock throughput under virtually all conditions
(uncontended, microcontended, held for a long time). I also compared to WTF::Lock and others, and
the only ones that performed better in this microbenchmark were spinlocks. I don't recommend
using those. So, when I say this is 3x slower than native, I really mean that it's 3x slower than
the fastest native lock that I have in my arsenal.
Also worth noting is that I experimented with exposing Atomics.yield(), which uses sched_yield,
as a way of testing if adding a yield loop to the JS cascadeLock would help. It does not help. I
did not investigate why.
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::JumpList::append):
* assembler/CPU.h:
(JSC::is64Bit):
(JSC::is32Bit):
* b3/B3Common.h:
(JSC::B3::is64Bit): Deleted.
(JSC::B3::is32Bit): Deleted.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::appendTrapping):
(JSC::B3::Air::LowerToAir::appendCAS):
(JSC::B3::Air::LowerToAir::appendGeneralAtomic):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasHeapPrediction):
(JSC::DFG::Node::hasArrayMode):
* dfg/DFGNodeType.h:
(JSC::DFG::isAtomicsIntrinsic):
(JSC::DFG::numExtraAtomicsArgs):
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSSALoweringPhase.cpp:
(JSC::DFG::SSALoweringPhase::handleNode):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::loadFromIntTypedArray):
(JSC::DFG::SpeculativeJIT::setIntTypedArrayLoadResult):
(JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
(JSC::DFG::SpeculativeJIT::getIntTypedArrayStoreOperand):
(JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLAbstractHeapRepository.cpp:
(JSC::FTL::AbstractHeapRepository::decorateFencedAccess):
(JSC::FTL::AbstractHeapRepository::computeRangesAndDecorateInstructions):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileAtomicsReadModifyWrite):
(JSC::FTL::DFG::LowerDFGToB3::compileAtomicsIsLockFree):
(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
(JSC::FTL::DFG::LowerDFGToB3::pointerIntoTypedArray):
(JSC::FTL::DFG::LowerDFGToB3::loadFromIntTypedArray):
(JSC::FTL::DFG::LowerDFGToB3::storeType):
(JSC::FTL::DFG::LowerDFGToB3::setIntTypedArrayLoadResult):
(JSC::FTL::DFG::LowerDFGToB3::getIntTypedArrayStoreOperand):
(JSC::FTL::DFG::LowerDFGToB3::vmCall):
* ftl/FTLOutput.cpp:
(JSC::FTL::Output::store):
(JSC::FTL::Output::store32As8):
(JSC::FTL::Output::store32As16):
(JSC::FTL::Output::atomicXchgAdd):
(JSC::FTL::Output::atomicXchgAnd):
(JSC::FTL::Output::atomicXchgOr):
(JSC::FTL::Output::atomicXchgSub):
(JSC::FTL::Output::atomicXchgXor):
(JSC::FTL::Output::atomicXchg):
(JSC::FTL::Output::atomicStrongCAS):
* ftl/FTLOutput.h:
(JSC::FTL::Output::store32):
(JSC::FTL::Output::store64):
(JSC::FTL::Output::storePtr):
(JSC::FTL::Output::storeFloat):
(JSC::FTL::Output::storeDouble):
* jit/JITOperations.h:
* runtime/AtomicsObject.cpp:
(JSC::atomicsFuncAdd):
(JSC::atomicsFuncAnd):
(JSC::atomicsFuncCompareExchange):
(JSC::atomicsFuncExchange):
(JSC::atomicsFuncIsLockFree):
(JSC::atomicsFuncLoad):
(JSC::atomicsFuncOr):
(JSC::atomicsFuncStore):
(JSC::atomicsFuncSub):
(JSC::atomicsFuncWait):
(JSC::atomicsFuncWake):
(JSC::atomicsFuncXor):
(JSC::operationAtomicsAdd):
(JSC::operationAtomicsAnd):
(JSC::operationAtomicsCompareExchange):
(JSC::operationAtomicsExchange):
(JSC::operationAtomicsIsLockFree):
(JSC::operationAtomicsLoad):
(JSC::operationAtomicsOr):
(JSC::operationAtomicsStore):
(JSC::operationAtomicsSub):
(JSC::operationAtomicsXor):
* runtime/AtomicsObject.h:
2017-04-19 Youenn Fablet <youenn@apple.com>
[Mac] Allow customizing H264 encoder
https://bugs.webkit.org/show_bug.cgi?id=170829
Reviewed by Alex Christensen.
* Configurations/FeatureDefines.xcconfig:
2017-04-19 Michael Saboff <msaboff@apple.com>
Tune GC related JSC options for iOS
https://bugs.webkit.org/show_bug.cgi?id=171019
Reviewed by Mark Lam.
Always set these GC options on iOS.
* runtime/Options.cpp:
(JSC::overrideDefaults):
2017-04-19 JF Bastien <jfbastien@apple.com>
WebAssembly: fast memory cleanups
https://bugs.webkit.org/show_bug.cgi?id=170909
Reviewed by Saam Barati.
* b3/B3LowerToAir.cpp: correct comment, and make wasm-independent
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Procedure.h:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::effects):
* b3/B3WasmBoundsCheckValue.cpp: have the creator pass in a
maximum, so we don't have to know so much about wasm here
(JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
(JSC::B3::WasmBoundsCheckValue::cloneImpl):
(JSC::B3::WasmBoundsCheckValue::dumpMeta):
* b3/B3WasmBoundsCheckValue.h:
(JSC::B3::WasmBoundsCheckValue::boundsType):
(JSC::B3::WasmBoundsCheckValue::bounds):
* b3/air/AirCode.h:
* b3/air/AirCustom.h:
(JSC::B3::Air::WasmBoundsCheckCustom::generate):
* b3/testb3.cpp:
(JSC::B3::testWasmBoundsCheck):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
(JSC::Wasm::createJSToWasmWrapper): remove dead code
* wasm/WasmMemory.cpp: don't GC if no memory could possibly be free'd
(JSC::Wasm::Memory::initializePreallocations): verbose-only code,
and copy-pasta bug
2017-04-19 Mark Lam <mark.lam@apple.com>
B3StackmapSpecial should handle when stackmap values are not recoverable from a Def'ed arg.
https://bugs.webkit.org/show_bug.cgi?id=170973
<rdar://problem/30318657>
Reviewed by Filip Pizlo.
In the event of an arithmetic overflow on a binary sub instruction (where the
result register is same as one of the operand registers), the CheckSub FTL
operation will try to recover the original value in the clobbered result register.
This recover is done by adding the other operand value to the result register.
However, this recovery method only works if the width of the original value in
the result register is less or equal to the width of the expected result. If the
width of the original operand value (e.g. a JSInt32) is wider than the result
(e.g. a machine Int32), then the sub operation would have zero extended the
result and cleared the upper 32-bits of the result register. Recovery by adding
back the other operand will not restore the JSValue tag in the upper word.
This poses a problem if the stackmap value for the operand relies on that same
clobbered register.
The fix is to detect this potential scenario (i.e. width of the Def's arg < width
of a stackmap value). If this condition is detected, we'll declare the stackmap
value to be LateColdUse to ensure that the register allocator gives it a
different register if needed so that it's not dependent on the clobbered register.
* b3/B3CheckSpecial.cpp:
(JSC::B3::CheckSpecial::forEachArg):
* b3/B3PatchpointSpecial.cpp:
(JSC::B3::PatchpointSpecial::forEachArg):
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::forEachArgImpl):
* b3/B3StackmapSpecial.h:
2017-04-19 JF Bastien <jfbastien@apple.com>
Unreviewed, rolling out r215520.
Broke Debian 8
Reverted changeset:
"[INTL] Implement Intl.DateTimeFormat.prototype.formatToParts"
https://bugs.webkit.org/show_bug.cgi?id=169458
http://trac.webkit.org/changeset/215520
2017-04-19 JF Bastien <jfbastien@apple.com>
WebAssembly: limit slow memories
https://bugs.webkit.org/show_bug.cgi?id=170825
Reviewed by Saam Barati.
We limits the number of fast memories, partly because ASLR. The
code then falls back to slow memories. It first tries to virtually
allocated any declared maximum (and in there, physically the
initial), and if that fails it tries to physically allocate the
initial without any extra.
This can still be used to cause a bunch of virtual
allocation. This patch imposes soft limit on slow memories as
well. The total virtual maximum for slow memories is set at the
same (theoretical) value as that for fast memories.
Anything exceeding that limit causes allocation/grow to fail.
* wasm/WasmMemory.cpp:
2017-04-19 JF Bastien <jfbastien@apple.com>
Cannot compile JavaScriptCore/runtime/VMTraps.cpp on FreeBSD because std::pair has a non-trivial copy constructor
https://bugs.webkit.org/show_bug.cgi?id=170875
Reviewed by Mark Lam.
WTF::ExpectedDetail::ConstexprBase doesn't have a user-defined
copy constructor, and its implicitly-defined copy constructor is
deleted because the default std::pair implementation on FreeBSD
has a non-trivial copy constructor. /usr/include/c++/v1/__config
says _LIBCPP_TRIVIAL_PAIR_COPY_CTOR is disabled in order to keep
ABI compatibility:
https://svnweb.freebsd.org/changeset/base/261801.
That's a huge bummer, and I'm not a fan of broken stdlibs, but in
this case it's pretty nice to have a custom named type anyways and
costs nothing.
* runtime/VMTraps.cpp:
(JSC::findActiveVMAndStackBounds):
(JSC::handleSigusr1):
(JSC::handleSigtrap):
2017-04-19 Andy VanWagoner <thetalecrafter@gmail.com>
[INTL] Implement Intl.DateTimeFormat.prototype.formatToParts
https://bugs.webkit.org/show_bug.cgi?id=169458
Reviewed by JF Bastien.
Use udat_formatForFields to iterate through the parts of a formatted date string.
* icu/unicode/udat.h: Update to 55.1.
* icu/unicode/ufieldpositer.h: Added from 55.1.
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::partTypeString): Convert UDateFormatField to string.
(JSC::IntlDateTimeFormat::formatToParts): Return parts of formatted date string.
* runtime/IntlDateTimeFormat.h:
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::IntlDateTimeFormatPrototypeFuncFormatToParts): Add prototype function formatToParts.
2017-04-19 JF Bastien <jfbastien@apple.com>
WebAssembly: don't expose any WebAssembly JS object if JIT is off
https://bugs.webkit.org/show_bug.cgi?id=170782
Reviewed by Saam Barati.
It's unexpected that we expose the global WebAssembly object if no
JIT is present because it can't be used to compile or
instantiate. Other APIs such as Memory should also be Inaccessible
in those circumstances.
Also ensure that we don't pre-allocate fast memories if
WebAssembly won't be used, and don't mark our intention to use a
fast TLS slot for WebAssembly.
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
2017-04-19 Yusuke Suzuki <utatane.tea@gmail.com>
r211670 broke double to int conversion.
https://bugs.webkit.org/show_bug.cgi?id=170961
Reviewed by Mark Lam.
In this patch, we take a template parameter way.
While it reduces duplicate code, it effectively produces
optimized code for operationToInt32SensibleSlow,
and fixes kraken pbkdf2 regression on Linux.
And this patch also fixes undefined behavior by changing
int32_t to uint32_t. If exp is 31, missingOne is 1 << 31,
INT32_MIN. Thus missingOne - 1 will cause int32_t overflow,
and it is an undefined behavior.
* runtime/MathCommon.cpp:
(JSC::operationToInt32SensibleSlow):
* runtime/MathCommon.h:
(JSC::toInt32Internal):
(JSC::toInt32):
2017-04-18 Mark Lam <mark.lam@apple.com>
r211670 broke double to int conversion.
https://bugs.webkit.org/show_bug.cgi?id=170961
<rdar://problem/31687696>
Reviewed by Yusuke Suzuki.
This is because operationToInt32SensibleSlow() assumes that left shifts of greater
than 31 bits on an 31-bit value will produce a 0. However, the spec says that
"if the value of the right operand is negative or is greater or equal to the
number of bits in the promoted left operand, the behavior is undefined."
See http://en.cppreference.com/w/cpp/language/operator_arithmetic#Bitwise_shift_operators.
This patch fixes this by restoring the check to prevent a shift of greater than
31 bits. It also consolidates the optimization in operationToInt32SensibleSlow()
back into toInt32() so that we don't have 2 copies of the same code with only a
slight variation.
JSC benchmarks shows that performance is neutral with this patch.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueToInt32):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32):
* runtime/MathCommon.cpp:
(JSC::operationToInt32SensibleSlow): Deleted.
* runtime/MathCommon.h:
(JSC::toInt32):
2017-04-18 Oleksandr Skachkov <gskachkov@gmail.com>
[ES6]. Implement Annex B.3.3 function hoisting rules for eval
https://bugs.webkit.org/show_bug.cgi?id=163208
Reviewed by Saam Barati.
Current patch implements Annex B.3.3 that is related to
hoisting of function declaration in eval.
https://tc39.github.io/ecma262/#sec-web-compat-evaldeclarationinstantiation
Function declaration in eval should create variable with
function name in function scope where eval is invoked
or bind to variable if it declared outside of the eval.
If variable is created it can be removed by 'delete a;' command.
If eval is invoke in block scope that contains let/const
variable with the same name as function declaration
we do not bind. This patch leads to the following behavior:
'''
function foo() {
{
print(boo); // undefined
eval('{ function boo() {}}');
print(boo); // function boo() {}
}
print(boo); // function boo() {}
}
function foobar() {
{
let boo = 10;
print(boo); // 10;
eval('{ function boo() {}}');
print(boo); // 10;
}
print(boo) // 10
}
function bar() {
{
var boo = 10;
print(boo); // 10
eval('{ function boo() {} }');
print(boo); // function boo() {}
}
print(boo); // function boo() {}
}
function bas() {
{
let boo = 10;
eval(' { function boo() {} } ');
print(boo); // 10
}
print(boo); //Reference Error
}
'''
Current implementation relies on already implemented
'hoist function in sloppy mode' feature, with small changes.
In short it works in following way: during hoisting of function
with name S in eval, we are looking for first scope that
contains space for variable with name S and if this scope
has var type we bind function there
To implement this feature was added bytecode ops:
op_resolve_scope_for_hoisting_func_decl_in_eval - get variable scope
or return undefined if variable can't be binded there.
There is a corner case, hoist function in eval within catch block,
that is not covered by this patch, and will be fixed in
https://bugs.webkit.org/show_bug.cgi?id=168184
* bytecode/BytecodeDumper.cpp:
(JSC::BytecodeDumper<Block>::dumpBytecode):
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finalizeLLIntInlineCaches):
* bytecode/EvalCodeBlock.h:
(JSC::EvalCodeBlock::functionHoistingCandidate):
(JSC::EvalCodeBlock::numFunctionHoistingCandidates):
* bytecode/UnlinkedEvalCodeBlock.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
(JSC::BytecodeGenerator::emitResolveScopeForHoistingFuncDeclInEval):
* bytecompiler/BytecodeGenerator.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasIdentifier):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileResolveScopeForHoistingFuncDeclInEval):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileResolveScopeForHoistingFuncDeclInEval):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval):
* llint/LowLevelInterpreter.asm:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionDeclarationStatement):
* parser/Parser.h:
(JSC::Scope::getSloppyModeHoistedFunctions):
(JSC::Parser::declareFunction):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* runtime/EvalExecutable.h:
(JSC::EvalExecutable::numFunctionHoistingCandidates):
(JSC::EvalExecutable::numTopLevelFunctionDecls):
(JSC::EvalExecutable::numberOfFunctionDecls): Deleted.
* runtime/JSScope.cpp:
(JSC::JSScope::resolve):
(JSC::JSScope::resolveScopeForHoistingFuncDeclInEval):
* runtime/JSScope.h:
2017-04-18 Saam Barati <sbarati@apple.com>
Follow up to address Mark's comments after r215453
Rubber stamped by Mark Lam.
This patch chooses better names for things, adhering to Mark's suggestions
in https://bugs.webkit.org/show_bug.cgi?id=139847
* bytecompiler/NodesCodegen.cpp:
(JSC::CallFunctionCallDotNode::emitBytecode):
(JSC::ApplyFunctionCallDotNode::emitBytecode):
* parser/NodeConstructors.h:
(JSC::CallFunctionCallDotNode::CallFunctionCallDotNode):
(JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode):
* parser/Nodes.h:
* parser/Parser.cpp:
(JSC::recordCallOrApplyDepth):
(JSC::Parser<LexerType>::parseMemberExpression):
* parser/Parser.h:
(JSC::Parser::CallOrApplyDepthScope::CallOrApplyDepthScope):
(JSC::Parser::CallOrApplyDepthScope::distanceToInnermostChild):
(JSC::Parser::CallOrApplyDepthScope::~CallOrApplyDepthScope):
(JSC::Parser::CallOrApplyDepth::CallOrApplyDepth): Deleted.
(JSC::Parser::CallOrApplyDepth::maxChildDepth): Deleted.
(JSC::Parser::CallOrApplyDepth::~CallOrApplyDepth): Deleted.
2017-04-18 Yusuke Suzuki <utatane.tea@gmail.com>
[DFG] Convert ValueAdd(Int32, String) => MakeRope(ToString(Int32), String)
https://bugs.webkit.org/show_bug.cgi?id=170943
Reviewed by Geoffrey Garen.
This patch converts ValueAdd(Int32, String) to MakeRope(ToString(Int32), String).
This has 2 great features.
1. MakeRope(ToString(Int32), String) is less clobbering.
While ValueAdd ends up calling functions, VM knows much about MakeRope(ToString(Int32), String)
and VM knows it is less clobbering. It encourages LICM and other operations that is conservatively
executed because of ValueAdd's clobbering.
2. Simply, MakeRope(ToString(Int32), String) is faster than ValueAdd.
While ValueAdd ends up calling a generic function, our ToString(Int32) calls well-optimized toString
operation. And later, MakeRope can fall into the fast path that just takes a string from a free list.
It is simply faster than ValueAdd.
We ensure that this patch shows performance improvement in attached benchmarks.
baseline patched
number-to-string-with-add-empty 16.2763+-3.3930 ^ 10.3142+-1.0967 ^ definitely 1.5780x faster
number-to-string-with-add-in-loop 168.7621+-10.9738 ^ 15.5307+-3.3179 ^ definitely 10.8664x faster
number-to-string-with-add 18.8557+-4.8292 11.6901+-2.5650 might be 1.6130x faster
In SixSpeed,
baseline patched
template_string_tag.es5 200.1027+-20.6871 ^ 25.7925+-11.4052 ^ definitely 7.7582x faster
template_string_tag.es6 331.3913+-12.1750 ^ 286.6958+-26.0441 ^ definitely 1.1559x faster
for-of-array.es5 412.4344+-23.2517 ^ 272.8707+-47.2118 ^ definitely 1.5115x faster
for-of-array.es6 504.0082+-65.5045 ^ 300.3277+-12.8193 ^ definitely 1.6782x faster
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::createToString):
* dfg/DFGPredictionPropagationPhase.cpp:
2017-04-18 Michael Saboff <msaboff@apple.com>
REGRESSION(215272): microbenchmark/seal-and-do-work and microbenchmark/freeze-and-do-work are 27x slower
https://bugs.webkit.org/show_bug.cgi?id=170881
Reviewed by Saam Barati.
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorSeal):
(JSC::objectConstructorFreeze):
Restored fast paths for final objects that don't have indexed properties.
2017-04-18 Yusuke Suzuki <utatane.tea@gmail.com>
[DFG] Use Phantom for base instead of getter when inlining intrinsic getter
https://bugs.webkit.org/show_bug.cgi?id=170947
Reviewed by Saam Barati.
getter does not need to be live after OSR Exit.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleGetById):
2017-04-18 Yusuke Suzuki <utatane.tea@gmail.com>
Unreviewed, follow-up patch after r215459
https://bugs.webkit.org/show_bug.cgi?id=170940
Reviewed by Filip Pizlo.
CheckCell can cause OSRExit. Thus Phantom should be placed after CheckCell.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::emitFunctionChecks):
(JSC::DFG::ByteCodeParser::handleGetById):
2017-04-18 Yusuke Suzuki <utatane.tea@gmail.com>
[DFG] Drop unknown use of CheckCell's child2 to work ObjectAllocationSinking for Array iterator object
https://bugs.webkit.org/show_bug.cgi?id=170940
Reviewed by Filip Pizlo.
The second argument of CheckCell is not used in meaningful way. It is just *use* the node.
The problem is that it effectively *use* the child2 in ObjectAllocationSinking phase, and
prevent us from eliminating object allocations. Actually, it materializes Array iterator
when inlining `next()`. Instead, we should use Phantom in such a case.
It improves destructuring.es6 in SixSpeed 2.5x.
destructuring.es6 308.5184+-25.3490 ^ 119.5680+-15.0520 ^ definitely 2.5803x faster
Note that SixSpeed tested in arewefastyet executes all the tests in one process while our SixSpeed
tests each one in isolated way.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::emitFunctionChecks):
(JSC::DFG::ByteCodeParser::handleGetById):
2017-04-18 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC][GTK] glib RunLoop does not accept negative start interval
https://bugs.webkit.org/show_bug.cgi?id=170775
Reviewed by Saam Barati.
* heap/GCActivityCallback.cpp:
(JSC::GCActivityCallback::scheduleTimer):
2017-04-17 Saam Barati <sbarati@apple.com>
BytecodeGenerator ".call" and ".apply" is exponential in nesting depth
https://bugs.webkit.org/show_bug.cgi?id=139847
<rdar://problem/19321122>
Reviewed by Oliver Hunt.
The BytecodeGenerator's .apply(...) and .call(...) code would
emit bytecode for the evaluation of its arguments twice. This
is exponential, specifically, 2^n, where n is the nesting depth of
.call(...) or .apply(...) inside other .call(...) or .apply(...).
The reason we emit code for the arguments twice is that we try
to emit efficient code for when .call or .apply is Function.prototype.call
or Function.prototype.apply. Because of this, we compare .call/.apply to
Function.prototype.call/.apply, and if they're the same, we emit a specialized
function call in bytecode. Otherwise, we emit the generalized version.
This patch makes it so that each .call(...) and .apply(...) records
its max inner nesting depth. Then, we only perform the optimization
for the bottom k (where k = 6) layers of the nesting tree. The reason we
apply the optimization to the bottom k layers instead of top k layers
is that we'll produce less code this way.
* bytecompiler/NodesCodegen.cpp:
(JSC::CallFunctionCallDotNode::emitBytecode):
(JSC::ApplyFunctionCallDotNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::makeFunctionCallNode):
* parser/NodeConstructors.h:
(JSC::CallFunctionCallDotNode::CallFunctionCallDotNode):
(JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode):
* parser/Nodes.h:
* parser/Parser.cpp:
(JSC::recordCallOrApplyDepth):
(JSC::Parser<LexerType>::parseMemberExpression):
* parser/Parser.h:
(JSC::Parser::CallOrApplyDepth::CallOrApplyDepth):
(JSC::Parser::CallOrApplyDepth::maxChildDepth):
(JSC::Parser::CallOrApplyDepth::~CallOrApplyDepth):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::makeFunctionCallNode):
2017-04-17 Mark Lam <mark.lam@apple.com>
JSArray::appendMemcpy() needs to handle copying from Undecided indexing type too.
https://bugs.webkit.org/show_bug.cgi?id=170896
<rdar://problem/31651319>
Reviewed by JF Bastien and Keith Miller.
* runtime/JSArray.cpp:
(JSC::JSArray::appendMemcpy):
2017-04-17 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Doesn't show size of compressed content correctly
https://bugs.webkit.org/show_bug.cgi?id=155112
<rdar://problem/25006728>
Reviewed by Alex Christensen and Timothy Hatcher.
* inspector/protocol/Network.json:
New, exact size metrics, available after the load completes.
2017-04-17 Youenn Fablet <youenn@apple.com>
Disable outdated WritableStream API
https://bugs.webkit.org/show_bug.cgi?id=170749
<rdar://problem/31446233>
Reviewed by Alex Christensen.
* Configurations/FeatureDefines.xcconfig:
2017-04-17 Yusuke Suzuki <utatane.tea@gmail.com>
[JSCOnly] Fix build failures in macOS
https://bugs.webkit.org/show_bug.cgi?id=170887
Reviewed by Alex Christensen.
Align ICU header configuration to MacCMake port.
* PlatformJSCOnly.cmake:
2017-04-17 JF Bastien <jfbastien@apple.com>
B3: don't allow unsigned offsets in Value
https://bugs.webkit.org/show_bug.cgi?id=170692
Reviewed by Filip Pizlo.
MemoryValue and similar B3 opcode classes always expects a signed
offset. Giving it an out-of-bounds unsigned offset causes
implementation-defined behavior, which can cause badness as I just
fixed in WebAssembly. This patch makes it impossible to create a
Value opcodes with an unsigned value, or with an overly-large
value.
* b3/B3AtomicValue.cpp:
(JSC::B3::AtomicValue::AtomicValue):
* b3/B3AtomicValue.h:
* b3/B3Common.h:
(JSC::B3::isRepresentableAs):
* b3/B3EliminateCommonSubexpressions.cpp:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::scaleForShl):
(JSC::B3::Air::LowerToAir::effectiveAddr):
(JSC::B3::Air::LowerToAir::addr):
(JSC::B3::Air::LowerToAir::tryAppendLea):
* b3/B3MemoryValue.cpp:
(JSC::B3::MemoryValue::isLegalOffsetImpl):
(JSC::B3::MemoryValue::MemoryValue):
* b3/B3MemoryValue.h:
* b3/B3MemoryValueInlines.h:
(JSC::B3::MemoryValue::isLegalOffsetImpl):
* b3/B3MoveConstants.cpp:
* b3/B3ReduceStrength.cpp:
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::repForArg):
* b3/B3Value.h:
* b3/air/AirArg.cpp:
(JSC::B3::Air::Arg::stackAddrImpl):
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::addr):
(JSC::B3::Air::Arg::stack):
(JSC::B3::Air::Arg::callArg):
(JSC::B3::Air::Arg::stackAddr):
(JSC::B3::Air::Arg::index):
(JSC::B3::Air::Arg::offset):
(JSC::B3::Air::Arg::isValidAddrForm):
(JSC::B3::Air::Arg::isValidIndexForm):
(JSC::B3::Air::Arg::asTrustedImm32):
(JSC::B3::Air::Arg::asAddress):
(JSC::B3::Air::Arg::asBaseIndex):
* b3/air/AirLowerStackArgs.cpp:
(JSC::B3::Air::lowerStackArgs):
* b3/testb3.cpp:
(JSC::B3::testMulArgStore):
(JSC::B3::testStore32):
(JSC::B3::testStoreConstant):
(JSC::B3::testStoreConstantPtr):
(JSC::B3::testStoreAddLoad32):
(JSC::B3::testStoreAddLoadImm32):
(JSC::B3::testStoreAddLoad8):
(JSC::B3::testStoreAddLoadImm8):
(JSC::B3::testStoreAddLoad16):
(JSC::B3::testStoreAddLoadImm16):
(JSC::B3::testStoreAddLoad64):
(JSC::B3::testStoreAddLoadImm64):
(JSC::B3::testStoreAddLoad32Index):
(JSC::B3::testStoreAddLoadImm32Index):
(JSC::B3::testStoreAddLoad64Index):
(JSC::B3::testStoreAddLoadImm64Index):
(JSC::B3::testStoreSubLoad):
(JSC::B3::testStoreAddLoadInterference):
(JSC::B3::testStoreAddAndLoad):
(JSC::B3::testStoreNegLoad32):
(JSC::B3::testStoreNegLoadPtr):
(JSC::B3::testLoadOffset):
(JSC::B3::testLoadOffsetNotConstant):
(JSC::B3::testLoadOffsetUsingAdd):
(JSC::B3::testLoadOffsetUsingAddInterference):
(JSC::B3::testLoadOffsetUsingAddNotConstant):
(JSC::B3::testStoreLoadStackSlot):
(JSC::B3::testLoad):
(JSC::B3::testInterpreter):
(JSC::B3::testTrappingStore):
(JSC::B3::testTrappingLoadAddStore):
(JSC::B3::testWasmAddress):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::fixupPointerPlusOffset):
(JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
(JSC::Wasm::B3IRGenerator::emitLoadOp):
(JSC::Wasm::B3IRGenerator::emitStoreOp):
2017-04-16 Joseph Pecoraro <pecoraro@apple.com>
test262: test262/test/built-ins/Object/prototype/toLocaleString/primitive_this_value.js
https://bugs.webkit.org/show_bug.cgi?id=170882
Reviewed by Saam Barati.
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncToLocaleString):
We should be using the this value without ToObject conversion both when
getting the potential accessor and calling it. In strict mode, the this
value will remain its simple value, in non-strict it is still converted.
2017-04-16 Joseph Pecoraro <pecoraro@apple.com>
test262: test262/test/built-ins/isNaN/toprimitive-not-callable-throws.js
https://bugs.webkit.org/show_bug.cgi?id=170888
Reviewed by Saam Barati.
* runtime/ExceptionHelpers.h:
* runtime/ExceptionHelpers.cpp:
(JSC::createInvalidInstanceofParameterErrorHasInstanceValueNotFunction):
Fix up this function name.
* runtime/JSObject.cpp:
(JSC::callToPrimitiveFunction):
When called with @@isPrimitive, bail on undefined or null and
throw a type error if the value is not callable.
(JSC::JSObject::toPrimitive):
Use throw scope to check for exception.
2017-04-16 Joseph Pecoraro <pecoraro@apple.com>
test262: test262/test/language/expressions/tagged-template/template-object.js
https://bugs.webkit.org/show_bug.cgi?id=170878
Reviewed by Saam Barati.
* runtime/JSArray.cpp:
(JSC::JSArray::put):
The fast path for setting an Array's length should check if length is
writable before checking for and possibly throwing a RangeError.
2017-04-16 Joseph Pecoraro <pecoraro@apple.com>
test262: test262/test/built-ins/Object/getOwnPropertyNames/15.2.3.4-4-44.js
https://bugs.webkit.org/show_bug.cgi?id=170879
Reviewed by Saam Barati.
* runtime/StringObject.h:
* runtime/StringObject.cpp:
(JSC::StringObject::getOwnPropertyNames):
(JSC::StringObject::getOwnNonIndexPropertyNames):
Ensure 'length' comes after all indexed properties by moving
it out to the getOwnNonIndexPropertyNames method which is called
inside of getOwnPropertyNames after JSObject handles indices.
2017-04-16 Joseph Pecoraro <pecoraro@apple.com>
test262: test262/test/built-ins/Date/prototype/Symbol.toPrimitive/name.js
https://bugs.webkit.org/show_bug.cgi?id=170884
Reviewed by Yusuke Suzuki.
* runtime/DatePrototype.cpp:
(JSC::DatePrototype::finishCreation):
* runtime/FunctionPrototype.cpp:
(JSC::FunctionPrototype::addFunctionProperties):
* runtime/RegExpPrototype.cpp:
(JSC::RegExpPrototype::finishCreation):
* runtime/SymbolPrototype.cpp:
(JSC::SymbolPrototype::finishCreation):
Give symbol property functions proper function names.
This addresses function.name but not function.toString().
2017-04-15 Joseph Pecoraro <pecoraro@apple.com>
test262: test262/test/language/global-code/new.target-arrow.js
https://bugs.webkit.org/show_bug.cgi?id=170872
Reviewed by Saam Barati.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::Parser):
Mark the global code scope.
(JSC::Parser<LexerType>::parseMemberExpression):
If new.target is detected in an arrow function defined in global scope
throw a SyntaxError.
* parser/Parser.h:
(JSC::Scope::Scope):
(JSC::Scope::setIsGlobalCodeScope):
(JSC::Scope::isGlobalCodeScope):
Marker for a global code scope.
* parser/ParserModes.h:
(JSC::isModuleParseMode):
(JSC::isProgramParseMode):
(JSC::isProgramOrModuleParseMode):
Helper for detecting global code based on parse mode.
2017-04-14 Nikita Vasilyev <nvasilyev@apple.com>
Web Inspector: WebSockets: messages with non-latin letters are displayed incorrectly
https://bugs.webkit.org/show_bug.cgi?id=170760
Reviewed by Joseph Pecoraro.
Add payloadLength property, which is used to display size. When payloadLength is unavailable,
it is calculated from payloadData by Web Inspector frontend.
This fixes <webkit.org/b/170609> Web Inspector: WebSockets: Transferred size is incorrect.
* inspector/protocol/Network.json:
2017-04-14 Saam Barati <sbarati@apple.com>
ParseInt intrinsic in DFG backend doesn't properly flush its operands
https://bugs.webkit.org/show_bug.cgi?id=170865
Reviewed by Mark Lam and Geoffrey Garen.
The DFG backend code needed to first call .gpr()/.jsValueRegs()
before calling flushRegisters(), or the input JSValueOperand would
not be flushed.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileParseInt):
2017-04-14 Mark Lam <mark.lam@apple.com>
Update architectures in xcconfig files.
https://bugs.webkit.org/show_bug.cgi?id=170867
<rdar://problem/31628104>
Reviewed by Joseph Pecoraro.
* Configurations/Base.xcconfig:
* Configurations/FeatureDefines.xcconfig:
* Configurations/JavaScriptCore.xcconfig:
* Configurations/ToolExecutable.xcconfig:
2017-04-14 Keith Miller <keith_miller@apple.com>
WebAssembly: B3IRGenerator should use phis for result types
https://bugs.webkit.org/show_bug.cgi?id=170863
Reviewed by Filip Pizlo.
Currently, we use variables for the result types of control flow in
Wasm. We did this originally since we weren't sure that the phis we
generated would be optimal. Since then, we have verified that the edges
in wasm control flow ensure that each upsilon will dominate its phi
so we don't need to use variables.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::ControlData::ControlData):
(JSC::Wasm::B3IRGenerator::addTopLevel):
(JSC::Wasm::B3IRGenerator::addBlock):
(JSC::Wasm::B3IRGenerator::addLoop):
(JSC::Wasm::B3IRGenerator::unify):
2017-04-14 Alex Christensen <achristensen@webkit.org>
Fix Windows build after r215368.
https://bugs.webkit.org/show_bug.cgi?id=170641
* CMakeLists.txt:
Add new directory containing files needed in WebCore.
2017-04-14 Caitlin Potter <caitp@igalia.com>
[JSC] use ExpressionErrorClassifier for AwaitExpression operand
https://bugs.webkit.org/show_bug.cgi?id=170844
Reviewed by Saam Barati.
In parseAssignmentExpression(), several cover grammars are handled, and
use ExpressionErrorClassifier to record hints about which grammars to
try.
In parseAwaitExpression(), the hints recorded during parsing of the
operand need to be discarded, because if they propagate to the outer
parseAssignmentExpression(), the hints will lead the parser down invalid
branches that should be skipped.
This change adds an additional ExpressionErrorClassifier to
parseAwaitExpression(), in order to discard hints recorded trying to
parse the operand.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseAwaitExpression):
2017-04-14 Saam Barati <sbarati@apple.com>
WebAssembly: There is a short window of time where a CodeBlock could be destroyed before all of its async compilation callbacks are called
https://bugs.webkit.org/show_bug.cgi?id=170641
Reviewed by Keith Miller.
There is an unlikely race when a CodeBlock compilation fails,
the module compiles a new CodeBlock for that memory mode, all while
the CodeBlock is notifying its callbacks that it has finished.
There is a chance that the Module could deref its failed CodeBlock
at that point, destroying it, before the callbacks were able to
grab a Ref to the CodeBlock. This patch fixes the race by having the
callbacks ref the CodeBlock.
This patch also has the Plan clear out all of its callbacks
once it gets completed. This adds an extra defense to anybody
that grabs refs to the Plan in the callback.
* wasm/WasmCodeBlock.cpp:
(JSC::Wasm::CodeBlock::CodeBlock):
(JSC::Wasm::CodeBlock::compileAsync):
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::complete):
2017-04-13 Filip Pizlo <fpizlo@apple.com>
Air::RegLiveness should be constraint-based
https://bugs.webkit.org/show_bug.cgi?id=170817
Reviewed by Saam Barati.
Previously, I changed the Air liveness analyses based on Air::Liveness<> to be
constraint-based and this was a significant speed-up. Now I'm adding the same
functionality to RegLiveness.
This is a 1% speed-up on wasm B3 -O1 compile times.
* b3/air/AirAllocateRegistersAndStackByLinearScan.cpp:
* b3/air/AirLivenessAdapter.h:
(JSC::B3::Air::LivenessAdapter::LivenessAdapter):
(JSC::B3::Air::LivenessAdapter::prepareToCompute):
(JSC::B3::Air::LivenessAdapter::actionsAt):
* b3/air/AirRegLiveness.cpp:
(JSC::B3::Air::RegLiveness::RegLiveness):
(JSC::B3::Air::RegLiveness::LocalCalcForUnifiedTmpLiveness::LocalCalcForUnifiedTmpLiveness):
(JSC::B3::Air::RegLiveness::LocalCalcForUnifiedTmpLiveness::execute):
(JSC::B3::Air::RegLiveness::LocalCalc::execute): Deleted.
* b3/air/AirRegLiveness.h:
(JSC::B3::Air::RegLiveness::Actions::Actions):
(JSC::B3::Air::RegLiveness::LocalCalcBase::LocalCalcBase):
(JSC::B3::Air::RegLiveness::LocalCalcBase::live):
(JSC::B3::Air::RegLiveness::LocalCalcBase::isLive):
(JSC::B3::Air::RegLiveness::LocalCalc::LocalCalc):
(JSC::B3::Air::RegLiveness::LocalCalc::execute):
(JSC::B3::Air::RegLiveness::LocalCalc::live): Deleted.
(JSC::B3::Air::RegLiveness::LocalCalc::isLive): Deleted.
2017-04-13 JF Bastien <jfbastien@apple.com>
WebAssembly: fix windows build
https://bugs.webkit.org/show_bug.cgi?id=170832
Reviewed by Mark Lam.
My previous patch re-declared isIOS which AssemblerCommon.h
already provided, and which was already included by Options.cpp.
* runtime/Options.cpp:
2017-04-13 Saam Barati <sbarati@apple.com>
WebAssembly: We should be able to postMessage a JSWebAssemblyModule
https://bugs.webkit.org/show_bug.cgi?id=170573
Reviewed by Filip Pizlo.
This patch adds a callback to JSRunLoopTimer to notify
clients that a timer has been set. This is used inside
WorkerRunLoop in WebCore so that its RunLoop can perform
an iteration when it sees that a timer got set.
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/JSRunLoopTimer.cpp:
(JSC::JSRunLoopTimer::scheduleTimer):
(JSC::JSRunLoopTimer::addTimerSetNotification):
(JSC::JSRunLoopTimer::removeTimerSetNotification):
* runtime/JSRunLoopTimer.h:
* wasm/WasmCodeBlock.cpp:
(JSC::Wasm::CodeBlock::~CodeBlock):
* wasm/WasmCodeBlock.h:
* wasm/WasmModule.cpp:
(JSC::Wasm::Module::~Module):
(JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace):
(JSC::Wasm::makeValidationCallback):
(JSC::Wasm::Module::validateSync):
(JSC::Wasm::Module::validateAsync):
(JSC::Wasm::Module::validateSyncImpl): Deleted.
(JSC::Wasm::Module::makeValidationCallback): Deleted.
* wasm/WasmModule.h:
(JSC::Wasm::Module::validateSync): Deleted.
(JSC::Wasm::Module::validateAsync): Deleted.
(JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace): Deleted.
(JSC::Wasm::Module::nonNullCodeBlock): Deleted.
* wasm/js/JSWebAssemblyCodeBlock.cpp:
(JSC::JSWebAssemblyCodeBlock::create):
* wasm/js/JSWebAssemblyCodeBlock.h:
(JSC::JSWebAssemblyCodeBlock::create): Deleted.
* wasm/js/JSWebAssemblyModule.cpp:
(JSC::JSWebAssemblyModule::source):
* wasm/js/JSWebAssemblyModule.h:
(JSC::JSWebAssemblyModule::source): Deleted.
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
* wasm/js/WebAssemblyModulePrototype.cpp:
2017-04-13 Mark Lam <mark.lam@apple.com>
Should use flushDirect() when flushing the scopeRegister due to needsScopeRegister().
https://bugs.webkit.org/show_bug.cgi?id=170661
<rdar://problem/31579046>
Reviewed by Filip Pizlo.
Previously, we were using flush() to flush the outermost frame's scopeRegister.
This is incorrect because flush() expects the VirtualRegister value passed to
it to be that of the top most inlined frame. In the event that we reach a
terminal condition while inside an inlined frame, flush() will end up flushing
the wrong register. The fix is simply to use flushDirect() instead.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::flush):
2017-04-13 Andy VanWagoner <thetalecrafter@gmail.com>
Change Intl prototypes to plain objects
https://bugs.webkit.org/show_bug.cgi?id=168178
Reviewed by JF Bastien.
* builtins/StringPrototype.js:
(localeCompare): Create default Collator once instead of using prototype.
* runtime/IntlCollatorPrototype.cpp:
(JSC::IntlCollatorPrototype::IntlCollatorPrototype):
* runtime/IntlCollatorPrototype.h:
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::IntlDateTimeFormatPrototype::IntlDateTimeFormatPrototype):
* runtime/IntlDateTimeFormatPrototype.h:
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::IntlNumberFormatPrototype::IntlNumberFormatPrototype):
* runtime/IntlNumberFormatPrototype.h:
* runtime/IntlObject.cpp:
(JSC::IntlObject::finishCreation): Don't set constructor on each prototype.
2017-04-13 Oliver Hunt <oliver@apple.com>
allocationSize should use safe arithmetic by default
https://bugs.webkit.org/show_bug.cgi?id=170804
Reviewed by JF Bastien.
Make all allocationSize() functions work in terms
of Checked<size_t>
* runtime/DirectArguments.h:
(JSC::DirectArguments::offsetOfSlot):
(JSC::DirectArguments::allocationSize):
* runtime/HashMapImpl.h:
(JSC::HashMapBuffer::allocationSize):
* runtime/JSArray.h:
(JSC::JSArray::allocationSize):
* runtime/JSArrayBufferView.h:
(JSC::JSArrayBufferView::allocationSize):
* runtime/JSAsyncFunction.h:
(JSC::JSAsyncFunction::allocationSize):
* runtime/JSFixedArray.h:
(JSC::JSFixedArray::allocationSize):
* runtime/JSFunction.h:
(JSC::JSFunction::allocationSize):
* runtime/JSGeneratorFunction.h:
(JSC::JSGeneratorFunction::allocationSize):
* runtime/JSModuleNamespaceObject.h:
* runtime/JSObject.h:
(JSC::JSFinalObject::allocationSize):
* runtime/JSWrapperObject.h:
(JSC::JSWrapperObject::allocationSize):
* runtime/ScopedArguments.h:
(JSC::ScopedArguments::allocationSize):
* runtime/VM.h:
(JSC::ScratchBuffer::allocationSize):
* wasm/js/JSWebAssemblyCodeBlock.h:
(JSC::JSWebAssemblyCodeBlock::offsetOfImportStubs):
(JSC::JSWebAssemblyCodeBlock::allocationSize):
* wasm/js/JSWebAssemblyInstance.h:
(JSC::JSWebAssemblyInstance::allocationSize):
2017-04-13 JF Bastien <jfbastien@apple.com>
WebAssembly: manage memory better
https://bugs.webkit.org/show_bug.cgi?id=170628
Reviewed by Keith Miller, Michael Saboff.
WebAssembly fast memories weren't managed very well. This patch
refactors it and puts us in a good position to further improve our
fast memory handling in the future.
We now cache fast memories at a process granularity, but make sure
that they don't consume dirty pages. We add a cap to the total
number of allocated fast memories to avoid ASLR degradation.
We teach the GC about memories as a kind of resource it should
care about because it didn't have visibility into the amount of
memory each represented. This allows benchmarks which allocate
memories back-to-back to reliably get fast memories 100% of the
time, even on a system under load, which wasn't the case
before. This reliability yields roughly 8% perf bump on x86-64
WasmBench.
The GC heuristic is as follows: each time we allocate a fast
memory we notify the GC, which then keeps track of the total
number of fast memories allocated since it last GC'd. We
separately keep track of the total number of fast memories which
have ever existed at any point in time (cached + allocated). This
is a monotonically-increasing high watermark. The GC will force a
full collection if, since it last ran, half or more of the high
watermark of fast memories was allocated.
At the same time, if we fail obtaining a fast memory from the
cache we do a GC to try to find one. If that fails we'll allocate
a new one (this can also fail, then we go to slow memory). This
can also be improved, but it's a good start.
This currently disables fast memories on iOS because getting fast
memories isn't a guaranteed thing. Rather, we get quite a few of
them and achieve significant speedups, but benchmarks which
allocate memories back-to-back end up falling behind because the
GC can conservatively hold onto memories, which then yields a perf
cliff. That cliff isn't reliable, WasmBench gets roughly 10 of 18
fast memories when in theory it should get all of them fast (as
MacOS does). The patch significantly improves the state of iOS
though, and in a follow-up we could re-enable fast memories.
Part of this good positioning is a facility to pre-allocate fast
memories very early at startup, before any fragmentation
occurs. This is currently disabled but worked extremely reliably
on iOS. Once we fix the above issues we'll want to re-visit and
turn on pre-allocation.
We also avoid locking for fast memory identification when
performing signal handling. I'm very nervous about acquiring locks
in a signal handler because in general signals can happen when
we've messed up. This isn't the case with fast memories: we're
raising a signal on purpose and handling it. However this doesn't
mean we won't mess up elsewhere! This will get more complicated
once we add support for multiple threads sharing memories and
being able to grow their memories. One example: the code calls
CRASH(), which executes the following code in release:
*(int *)(uintptr_t)0xbbadbeef = 0;
This is a segfault, which our fast memory signal handler tries to
handle. It does so by first figuring out whether 0xbbadbeef is in
a fast memory region, reqiring a lock. If we CRASH() while holding
the lock then our thread self-deadlocks, giving us no crash report
and a bad user experience.
Avoiding a lock therefore it's not about speed or reduced
contention. In fact, I'd use something else than a FIFO if these
were a concern. We're also doing syscalls, which dwarf any locking
cost.
We now only allocate 4GiB + redzone of 64k * 128 for fast memories
instead of 8GiB. This patch reuses the logic from
B3::WasmBoundsCheck to perform bounds checks when accesses could
exceed the redzone. We'll therefore benefit from CSE goodness when
it reaches WasmBoundsCheck. See bug #163469.
* b3/B3LowerToAir.cpp: fix a baaaaddd bug where unsigned->signed
conversion allowed out-of-bounds reads by -2GiB. I'll follow-up in
bug #170692 to prevent this type of bug once and for all.
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Validate.cpp: update WasmBoundsCheck validation.
* b3/B3Value.cpp:
(JSC::B3::Value::effects): update WasmBoundsCheck effects.
* b3/B3WasmBoundsCheckValue.cpp:
(JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
(JSC::B3::WasmBoundsCheckValue::redzoneLimit):
(JSC::B3::WasmBoundsCheckValue::dumpMeta):
* b3/B3WasmBoundsCheckValue.h:
(JSC::B3::WasmBoundsCheckValue::maximum):
* b3/air/AirCustom.cpp:
(JSC::B3::Air::WasmBoundsCheckCustom::isValidForm):
* b3/testb3.cpp:
(JSC::B3::testWasmBoundsCheck):
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::reportWebAssemblyFastMemoriesAllocated):
(JSC::Heap::webAssemblyFastMemoriesThisCycleAtThreshold):
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::didAllocateWebAssemblyFastMemories):
(JSC::Heap::shouldDoFullCollection):
(JSC::Heap::collectIfNecessaryOrDefer):
* heap/Heap.h:
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/Options.cpp:
* runtime/Options.h:
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::fixupPointerPlusOffset):
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
(JSC::Wasm::B3IRGenerator::emitLoadOp):
(JSC::Wasm::B3IRGenerator::emitStoreOp):
(JSC::Wasm::createJSToWasmWrapper):
* wasm/WasmFaultSignalHandler.cpp:
(JSC::Wasm::trapHandler):
* wasm/WasmMemory.cpp: Rewrite.
(JSC::Wasm::makeString):
(JSC::Wasm::Memory::initializePreallocations):
(JSC::Wasm::Memory::createImpl):
(JSC::Wasm::Memory::create):
(JSC::Wasm::Memory::~Memory):
(JSC::Wasm::Memory::fastMappedRedzoneBytes):
(JSC::Wasm::Memory::fastMappedBytes):
(JSC::Wasm::Memory::maxFastMemoryCount):
(JSC::Wasm::Memory::addressIsInActiveFastMemory):
(JSC::Wasm::Memory::grow):
* wasm/WasmMemory.h:
(Memory::maxFastMemoryCount):
(Memory::addressIsInActiveFastMemory):
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::finishCreation):
(JSC::JSWebAssemblyInstance::visitChildren):
(JSC::JSWebAssemblyInstance::globalMemoryByteSize):
* wasm/js/JSWebAssemblyInstance.h:
* wasm/js/JSWebAssemblyMemory.cpp:
(JSC::JSWebAssemblyMemory::grow):
(JSC::JSWebAssemblyMemory::finishCreation):
(JSC::JSWebAssemblyMemory::visitChildren):
2017-04-13 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Use proper ifdef guard for code using MachineContext
https://bugs.webkit.org/show_bug.cgi?id=170800
Reviewed by Carlos Alberto Lopez Perez.
This patch drops MachineContext use if it is not available.
This situation can be considered like, building WebKit with musl.
In that case, we simply disable features that rely on MachineContext.
Examples are wasm fast memory, sampling profiler, and code profiling.
* runtime/Options.cpp:
(JSC::overrideDefaults):
* tools/CodeProfiling.cpp:
(JSC::CodeProfiling::begin):
(JSC::CodeProfiling::end):
Previously, PLATFORM(GTK) is excluded. But it is not obvious why it is excluded.
This patch just includes such platforms.
* wasm/WasmFaultSignalHandler.cpp:
(JSC::Wasm::enableFastMemory):
2017-04-12 Dan Bernstein <mitz@apple.com>
[Mac] Future-proof .xcconfig files
https://bugs.webkit.org/show_bug.cgi?id=170802
Reviewed by Tim Horton.
* Configurations/Base.xcconfig:
* Configurations/DebugRelease.xcconfig:
* Configurations/FeatureDefines.xcconfig:
* Configurations/Version.xcconfig:
2017-04-12 Joseph Pecoraro <pecoraro@apple.com>
test262: test262/test/built-ins/NativeErrors/EvalError/proto.js
https://bugs.webkit.org/show_bug.cgi?id=170668
Reviewed by Keith Miller.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
The [[Prototype]] of NativeError Constructor's should be the %Error%.
https://tc39.github.io/ecma262/#sec-properties-of-the-nativeerror-constructors
2017-04-12 Joseph Pecoraro <pecoraro@apple.com>
test262: test262/test/language/literals/regexp/u-dec-esc.js
https://bugs.webkit.org/show_bug.cgi?id=170687
Reviewed by Michael Saboff.
* yarr/YarrParser.h:
(JSC::Yarr::Parser::parseEscape):
* yarr/YarrPattern.cpp:
(JSC::Yarr::YarrPattern::errorMessage):
(JSC::Yarr::YarrPattern::compile):
* yarr/YarrPattern.h:
In unicoe patterns, invalid backreferences are an error.
2017-04-12 Filip Pizlo <fpizlo@apple.com>
Move common stack allocation utilities out of AirAllocateStackByGraphColoring.cpp
https://bugs.webkit.org/show_bug.cgi?id=170799
Reviewed by Michael Saboff and Keith Miller.
When I added stack allocation to allocateRegistersByLinearScan, I reused a handful of
utility functions from AirAllocateStackByGraphColoring.cpp. I accomplished this by
putting their declarations in AirAllocateStackByGraphColoring.h.
That was pretty weird.
This patch moves a family of stack allocation helper functions out of
AirAllocateStackByGraphColoring.cpp and into the new AirStackAllocation.h|cpp. The
linear scan stack allocator no longer has to include the other stack allocator's
header, which addresses my OCD.
I moved the functions transitively reachable from the two functions that the linear
scan allocator needed. This forced me to give them better names (i.e. no "fooBarImpl")
and short descriptive comments. I think that such comments are useful in code that is
doing a convoluted version of some theoretical concept.
No behavior change.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/air/AirAllocateRegistersAndStackByLinearScan.cpp:
* b3/air/AirAllocateStackByGraphColoring.cpp:
(JSC::B3::Air::allocateStackByGraphColoring):
(JSC::B3::Air::allocateEscapedStackSlots): Deleted.
(JSC::B3::Air::updateFrameSizeBasedOnStackSlots): Deleted.
* b3/air/AirAllocateStackByGraphColoring.h:
* b3/air/AirStackAllocation.cpp: Added.
(JSC::B3::Air::attemptAssignment):
(JSC::B3::Air::assign):
(JSC::B3::Air::allocateAndGetEscapedStackSlotsWithoutChangingFrameSize):
(JSC::B3::Air::allocateEscapedStackSlots):
(JSC::B3::Air::updateFrameSizeBasedOnStackSlots):
* b3/air/AirStackAllocation.h: Added.
2017-04-12 Filip Pizlo <fpizlo@apple.com>
B3 -O1 should not allocateStackByGraphColoring
https://bugs.webkit.org/show_bug.cgi?id=170742
Reviewed by Keith Miller.
One of B3 -O1's longest running phases is allocateStackByGraphColoring. One approach to
this would be to make that phase cheaper. But it's weird that this phase reruns
liveness after register allocation already ran liveness. If only it could reuse the
liveness computed by register allocation then it would run a lot faster. At -O2, we do
not want this, since we run phases between register allocation and stack allocation,
and those phases are free to change the liveness of spill slots (in fact,
fixObviousSpills will both shorten and lengthen live ranges because of load and store
elimination, respectively). But at -O1, we don't really need to run any phases between
register and stack allocation.
This changes Air's backend in the following ways:
- Linear scan does stack allocation. This means that we don't need to run
allocateStackByGraphColoring at all. In reality, we reuse some of its innards, but
we don't run the expensive part of it (liveness->interference->coalescing->coloring).
This is a speed-up because we only run liveness once and reuse it for both register
and stack allocation.
- Phases that previously ran between register and stack allocation are taken care of,
each in its own special way:
-> handleCalleSaves: this is now a utility function called by both
allocateStackByGraphColoring and allocateRegistersAndStackByLinearScan.
-> fixObviousSpills: we didn't run this at -O1, so nothing needs to be done.
-> lowerAfterRegAlloc: this needed to be able to run before stack allocation because
it could change register usage (vis a vis callee saves) and it could introduce
spill slots. I changed this phase to have a secondary mode for when it runs after
stack allocation.
- The part of allocateStackByGraphColoring that lowered stack addresses and took care
of the call arg area is now a separate phase called lowerStackArgs. We run this phase
regardless of optimization level. It's a cheap and general lowering.
This also removes spillEverything, because we never use that phase, we never test it,
and it got in the way in this refactoring.
This is a 21% speed-up on wasm -O1 compile times. This does not significantly change
-O1 throughput. We had already disabled allocateStack's most important optimization
(spill coalescing). This probably regresses average stack frame size, but I didn't
measure by how much. Stack frame size is really not that important. The algorithm in
allocateStackByGraphColoring is about much more than optimal frame size; it also
tries to avoid having to zero-extend 32-bit spills, it kills dead code, and of course
it coalesces.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::calleeSaveRegisterAtOffsetList):
(JSC::B3::Procedure::calleeSaveRegisters): Deleted.
* b3/B3Procedure.h:
* b3/B3StackmapGenerationParams.cpp:
(JSC::B3::StackmapGenerationParams::unavailableRegisters):
* b3/air/AirAllocateRegistersAndStackByLinearScan.cpp: Copied from Source/JavaScriptCore/b3/air/AirAllocateRegistersByLinearScan.cpp.
(JSC::B3::Air::allocateRegistersAndStackByLinearScan):
(JSC::B3::Air::allocateRegistersByLinearScan): Deleted.
* b3/air/AirAllocateRegistersAndStackByLinearScan.h: Copied from Source/JavaScriptCore/b3/air/AirAllocateRegistersByLinearScan.h.
* b3/air/AirAllocateRegistersByLinearScan.cpp: Removed.
* b3/air/AirAllocateRegistersByLinearScan.h: Removed.
* b3/air/AirAllocateStackByGraphColoring.cpp:
(JSC::B3::Air::allocateEscapedStackSlots):
(JSC::B3::Air::updateFrameSizeBasedOnStackSlots):
(JSC::B3::Air::allocateStackByGraphColoring):
* b3/air/AirAllocateStackByGraphColoring.h:
* b3/air/AirArg.cpp:
(JSC::B3::Air::Arg::stackAddr):
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::stackAddr): Deleted.
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::addStackSlot):
(JSC::B3::Air::Code::setCalleeSaveRegisterAtOffsetList):
(JSC::B3::Air::Code::calleeSaveRegisterAtOffsetList):
(JSC::B3::Air::Code::dump):
* b3/air/AirCode.h:
(JSC::B3::Air::Code::setStackIsAllocated):
(JSC::B3::Air::Code::stackIsAllocated):
(JSC::B3::Air::Code::calleeSaveRegisters):
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::prepareForGeneration):
(JSC::B3::Air::generate):
* b3/air/AirHandleCalleeSaves.cpp:
(JSC::B3::Air::handleCalleeSaves):
* b3/air/AirHandleCalleeSaves.h:
* b3/air/AirLowerAfterRegAlloc.cpp:
(JSC::B3::Air::lowerAfterRegAlloc):
* b3/air/AirLowerStackArgs.cpp: Added.
(JSC::B3::Air::lowerStackArgs):
* b3/air/AirLowerStackArgs.h: Added.
* b3/testb3.cpp:
(JSC::B3::testPinRegisters):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* jit/RegisterAtOffsetList.h:
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::parseAndCompile):
2017-04-12 Michael Saboff <msaboff@apple.com>
Implement Object.isFrozen() and Object.isSealed() per ECMA spec
https://bugs.webkit.org/show_bug.cgi?id=170753
Reviewed by Mark Lam.
* runtime/ObjectConstructor.cpp:
(JSC::testIntegrityLevel): Added local helper as described in the ECMA standard.
(JSC::objectConstructorSeal):
(JSC::objectConstructorFreeze):
Eliminated incomplete special handling of JSFinalObjects.
(JSC::objectConstructorIsSealed):
(JSC::objectConstructorIsFrozen):
Refactored to use the new testIntegrityLevel() helper.
2017-04-12 Yusuke Suzuki <utatane.tea@gmail.com>
Use HAVE(MACHINE_CONTEXT) instead of USE(MACHINE_CONTEXT)
https://bugs.webkit.org/show_bug.cgi?id=170770
Rubber stamped by Mark Lam.
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::MachineThread::Registers::framePointer):
(JSC::MachineThreads::MachineThread::Registers::instructionPointer):
(JSC::MachineThreads::MachineThread::Registers::llintPC):
* runtime/MachineContext.h:
(JSC::MachineContext::stackPointer):
(JSC::MachineContext::framePointer):
(JSC::MachineContext::instructionPointer):
(JSC::MachineContext::argumentPointer<1>):
(JSC::MachineContext::llintInstructionPointer):
2017-04-12 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Clean up heap/MachineStackMarker by introducing USE(MACHINE_CONTEXT)
https://bugs.webkit.org/show_bug.cgi?id=170770
Reviewed by Mark Lam.
We use USE(MACHINE_CONTEXT) to clean up runtime/MachineContext.h. And
we clean up heap/MachineStackMarker.cpp by using MachineContext functions.
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::MachineThread::Registers::stackPointer):
(JSC::MachineThreads::MachineThread::Registers::framePointer):
(JSC::MachineThreads::MachineThread::Registers::instructionPointer):
(JSC::MachineThreads::MachineThread::Registers::llintPC):
* heap/MachineStackMarker.h:
* runtime/MachineContext.h:
(JSC::MachineContext::stackPointer):
(JSC::MachineContext::framePointer):
(JSC::MachineContext::instructionPointer):
(JSC::MachineContext::argumentPointer<1>):
(JSC::MachineContext::llintInstructionPointer):
2017-04-12 Yusuke Suzuki <utatane.tea@gmail.com>
[WTF] Introduce Thread class and use RefPtr<Thread> and align Windows Threading implementation semantics to Pthread one
https://bugs.webkit.org/show_bug.cgi?id=170502
Reviewed by Mark Lam.
* API/tests/CompareAndSwapTest.cpp:
(testCompareAndSwap):
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/air/testair.cpp:
* b3/testb3.cpp:
(JSC::B3::run):
* bytecode/SuperSampler.cpp:
(JSC::initializeSuperSampler):
* dfg/DFGWorklist.cpp:
* disassembler/Disassembler.cpp:
* heap/Heap.cpp:
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::notifyIsSafeToCollect):
* heap/Heap.h:
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::~MachineThreads):
(JSC::MachineThreads::addCurrentThread):
(JSC::MachineThreads::removeThread):
(JSC::MachineThreads::removeThreadIfFound):
(JSC::MachineThreads::MachineThread::MachineThread):
(JSC::MachineThreads::MachineThread::getRegisters):
(JSC::MachineThreads::MachineThread::Registers::stackPointer):
(JSC::MachineThreads::MachineThread::Registers::framePointer):
(JSC::MachineThreads::MachineThread::Registers::instructionPointer):
(JSC::MachineThreads::MachineThread::Registers::llintPC):
(JSC::MachineThreads::MachineThread::captureStack):
(JSC::MachineThreads::tryCopyOtherThreadStack):
(JSC::MachineThreads::tryCopyOtherThreadStacks):
(pthreadSignalHandlerSuspendResume): Deleted.
(JSC::threadData): Deleted.
(JSC::MachineThreads::Thread::Thread): Deleted.
(JSC::MachineThreads::Thread::createForCurrentThread): Deleted.
(JSC::MachineThreads::Thread::operator==): Deleted.
(JSC::MachineThreads::machineThreadForCurrentThread): Deleted.
(JSC::MachineThreads::ThreadData::ThreadData): Deleted.
(JSC::MachineThreads::ThreadData::~ThreadData): Deleted.
(JSC::MachineThreads::ThreadData::suspend): Deleted.
(JSC::MachineThreads::ThreadData::resume): Deleted.
(JSC::MachineThreads::ThreadData::getRegisters): Deleted.
(JSC::MachineThreads::ThreadData::Registers::stackPointer): Deleted.
(JSC::MachineThreads::ThreadData::Registers::framePointer): Deleted.
(JSC::MachineThreads::ThreadData::Registers::instructionPointer): Deleted.
(JSC::MachineThreads::ThreadData::Registers::llintPC): Deleted.
(JSC::MachineThreads::ThreadData::freeRegisters): Deleted.
(JSC::MachineThreads::ThreadData::captureStack): Deleted.
* heap/MachineStackMarker.h:
(JSC::MachineThreads::MachineThread::suspend):
(JSC::MachineThreads::MachineThread::resume):
(JSC::MachineThreads::MachineThread::threadID):
(JSC::MachineThreads::MachineThread::stackBase):
(JSC::MachineThreads::MachineThread::stackEnd):
(JSC::MachineThreads::threadsListHead):
(JSC::MachineThreads::Thread::operator!=): Deleted.
(JSC::MachineThreads::Thread::suspend): Deleted.
(JSC::MachineThreads::Thread::resume): Deleted.
(JSC::MachineThreads::Thread::getRegisters): Deleted.
(JSC::MachineThreads::Thread::freeRegisters): Deleted.
(JSC::MachineThreads::Thread::captureStack): Deleted.
(JSC::MachineThreads::Thread::platformThread): Deleted.
(JSC::MachineThreads::Thread::stackBase): Deleted.
(JSC::MachineThreads::Thread::stackEnd): Deleted.
* jit/ICStats.cpp:
(JSC::ICStats::ICStats):
(JSC::ICStats::~ICStats):
* jit/ICStats.h:
* jsc.cpp:
(functionDollarAgentStart):
(startTimeoutThreadIfNeeded):
* runtime/JSLock.cpp:
(JSC::JSLock::lock):
* runtime/JSLock.h:
(JSC::JSLock::ownerThread):
(JSC::JSLock::currentThreadIsHoldingLock):
* runtime/SamplingProfiler.cpp:
(JSC::FrameWalker::isValidFramePointer):
(JSC::SamplingProfiler::SamplingProfiler):
(JSC::SamplingProfiler::createThreadIfNecessary):
(JSC::SamplingProfiler::takeSample):
* runtime/SamplingProfiler.h:
* runtime/VM.h:
(JSC::VM::ownerThread):
* runtime/VMTraps.cpp:
(JSC::findActiveVMAndStackBounds):
(JSC::VMTraps::SignalSender::send):
(JSC::VMTraps::fireTrap):
2017-04-11 Dean Jackson <dino@apple.com>
Disable outdated WritableStream API
https://bugs.webkit.org/show_bug.cgi?id=170749
<rdar://problem/31446233>
Reviewed by Tim Horton.
The API we implement is no longer accurate. Disable it until we
are compatible with the new specification
* Configurations/FeatureDefines.xcconfig:
2017-04-11 Yusuke Suzuki <utatane.tea@gmail.com>
Unreviewed, build fix for CF ports after r215241
https://bugs.webkit.org/show_bug.cgi?id=170725
* heap/GCActivityCallback.cpp:
(JSC::GCActivityCallback::nextFireTime):
2017-04-11 Yusuke Suzuki <utatane.tea@gmail.com>
[WebCore][JSC] ResourceUsageData.{timeOfNextEdenCollection,timeOfNextFullCollection} should be MonotonicTime
https://bugs.webkit.org/show_bug.cgi?id=170725
Reviewed by Sam Weinig.
This patch makes GCActivityCallback return MonotonicTime instead of raw double value.
* heap/GCActivityCallback.cpp:
(JSC::GCActivityCallback::nextFireTime):
* heap/GCActivityCallback.h:
2017-04-11 Guillaume Emont <guijemont@igalia.com>
[jsc] Add missing MacroAssemblerMIPS::or32() implementation
https://bugs.webkit.org/show_bug.cgi?id=169714
Reviewed by Michael Catanzaro.
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::or32):
Added or32(TrustedImm32, Address).
2017-04-11 Joseph Pecoraro <pecoraro@apple.com>
test262: test262/test/annexB/language/comments/multi-line-html-close.js
https://bugs.webkit.org/show_bug.cgi?id=170648
Reviewed by Keith Miller.
* parser/Lexer.cpp:
(JSC::Lexer<T>::lex):
A multi-line comment that contains a line terminator is itself treated
like a line terminator. An HTML Close Comment that comes after it can
therefore treat it like it is at the start of a line, because it was
immediately preceeded by the equivalent of a line terminator.
2017-04-11 Joseph Pecoraro <pecoraro@apple.com>
test262: test262/test/built-ins/Array/S15.4.3_A2.2.js
https://bugs.webkit.org/show_bug.cgi?id=170652
Reviewed by Michael Saboff.
* runtime/ArrayConstructor.cpp:
(JSC::ArrayConstructor::finishCreation):
* runtime/BooleanConstructor.cpp:
(JSC::BooleanConstructor::finishCreation):
* runtime/DateConstructor.cpp:
(JSC::DateConstructor::finishCreation):
* runtime/FunctionConstructor.cpp:
(JSC::FunctionConstructor::finishCreation):
* runtime/JSArrayBufferConstructor.cpp:
(JSC::JSArrayBufferConstructor::finishCreation):
* runtime/NumberConstructor.cpp:
(JSC::NumberConstructor::finishCreation):
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructor::finishCreation):
* runtime/RegExpConstructor.cpp:
(JSC::RegExpConstructor::finishCreation):
* runtime/StringConstructor.cpp:
(JSC::StringConstructor::finishCreation):
* runtime/SymbolConstructor.cpp:
(JSC::SymbolConstructor::finishCreation):
Ensure the "length" property on these native constructors is configurable (deletable).
2017-04-11 Yusuke Suzuki <utatane.tea@gmail.com>
Unreviewed, build fix for Windows after r215228 part 2
https://bugs.webkit.org/show_bug.cgi?id=170723
Since GCActivityCallback class is annotated exported, we do not need to annotate each member.
* heap/GCActivityCallback.h:
2017-04-11 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC][GTK] Use RunLoop::Timer in GTK port
https://bugs.webkit.org/show_bug.cgi?id=170723
Reviewed by Carlos Garcia Campos.
This patch makes GTK port use RunLoop::Timer for JSRunLoopTimer.
Only Cocoa-based ports use platform-specific Timer because it
has additional feature that changes RunLoop to the WebThread one.
And we enable Heap timers in all the ports including JSCOnly port.
* heap/EdenGCActivityCallback.cpp:
(JSC::EdenGCActivityCallback::lastGCLength):
* heap/EdenGCActivityCallback.h:
* heap/FullGCActivityCallback.cpp:
(JSC::FullGCActivityCallback::lastGCLength):
* heap/FullGCActivityCallback.h:
* heap/GCActivityCallback.cpp:
(JSC::GCActivityCallback::GCActivityCallback):
(JSC::GCActivityCallback::doWork):
(JSC::GCActivityCallback::scheduleTimer):
(JSC::GCActivityCallback::cancelTimer):
(JSC::GCActivityCallback::nextFireTime):
(JSC::GCActivityCallback::didAllocate):
* heap/GCActivityCallback.h:
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::doWork):
(JSC::IncrementalSweeper::doSweep):
* heap/IncrementalSweeper.h:
* heap/StopIfNecessaryTimer.cpp:
(JSC::StopIfNecessaryTimer::scheduleSoon):
* runtime/JSRunLoopTimer.cpp:
(JSC::JSRunLoopTimer::setRunLoop):
(JSC::JSRunLoopTimer::scheduleTimer):
(JSC::JSRunLoopTimer::cancelTimer):
(JSC::JSRunLoopTimer::JSRunLoopTimer):
(JSC::JSRunLoopTimer::~JSRunLoopTimer):
(JSC::JSRunLoopTimer::timerDidFireCallback):
* runtime/JSRunLoopTimer.h:
* runtime/PromiseDeferredTimer.cpp:
(JSC::PromiseDeferredTimer::scheduleWorkSoon):
2017-04-11 Guillaume Emont <guijemont@igalia.com>
[jsc][mips] Add missing MacroAssembler functions after r214187
https://bugs.webkit.org/show_bug.cgi?id=170089
Reviewed by Yusuke Suzuki.
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::loadFloat): Added.
(JSC::MacroAssemblerMIPS::storeFloat): Added.
2017-04-11 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Enable JSRunLoopTimer for JSCOnly and Windows
https://bugs.webkit.org/show_bug.cgi?id=170655
Reviewed by Carlos Garcia Campos.
* runtime/JSRunLoopTimer.cpp:
(JSC::JSRunLoopTimer::JSRunLoopTimer):
(JSC::JSRunLoopTimer::scheduleTimer):
(JSC::JSRunLoopTimer::cancelTimer):
* runtime/JSRunLoopTimer.h:
2017-04-10 Alex Christensen <achristensen@webkit.org>
Revert r215217
https://bugs.webkit.org/show_bug.cgi?id=170703
* Configurations/FeatureDefines.xcconfig:
2017-04-10 Alex Christensen <achristensen@webkit.org>
Continue enabling WebRTC
https://bugs.webkit.org/show_bug.cgi?id=170703
Reviewed by Youenn Fablet.
* Configurations/FeatureDefines.xcconfig:
2017-04-10 Mark Lam <mark.lam@apple.com>
Move ProbeContext and ProbeFunction out of AbstractMacroAssembler.
https://bugs.webkit.org/show_bug.cgi?id=170681
Reviewed by Michael Saboff.
This is a refactoring step towards enabling custom probe printers the way printInternal() works for dataLog.
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::ProbeContext::gpr): Deleted.
(JSC::AbstractMacroAssembler::ProbeContext::fpr): Deleted.
(JSC::AbstractMacroAssembler::ProbeContext::gprName): Deleted.
(JSC::AbstractMacroAssembler::ProbeContext::fprName): Deleted.
* assembler/MacroAssembler.cpp:
(JSC::stdFunctionCallback):
(JSC::MacroAssembler::probe):
* assembler/MacroAssembler.h:
(JSC::ProbeContext::gpr):
(JSC::ProbeContext::fpr):
(JSC::ProbeContext::gprName):
(JSC::ProbeContext::fprName):
* assembler/MacroAssemblerARM.cpp:
(JSC::MacroAssemblerARM::probe):
* assembler/MacroAssemblerARM64.cpp:
(JSC::arm64ProbeTrampoline):
(JSC::MacroAssemblerARM64::probe):
* assembler/MacroAssemblerARMv7.cpp:
(JSC::MacroAssemblerARMv7::probe):
* assembler/MacroAssemblerPrinter.cpp:
* assembler/MacroAssemblerPrinter.h:
* assembler/MacroAssemblerX86Common.cpp:
(JSC::MacroAssemblerX86Common::probe):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::abstractStructure):
(JSC::FTL::DFG::LowerDFGToB3::probe): Deleted.
- Deleted because this became a useless place-holder after the transition to B3.
2017-04-10 Keith Miller <keith_miller@apple.com>
WebAssembly: Fix B3IRGenerator for BrTable
https://bugs.webkit.org/show_bug.cgi?id=170685
Reviewed by JF Bastien.
For some reason this didn't get included in r215141.
This fixes an issue with BrTable and loops where we would use the loop's return type
as the branch target type.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::ControlData::resultForBranch):
(JSC::Wasm::B3IRGenerator::unifyValuesWithBlock):
2017-04-08 Oliver Hunt <oliver@apple.com>
Remove use of strcpy from JSC
https://bugs.webkit.org/show_bug.cgi?id=170646
Reviewed by Mark Lam.
Replace the use of strcpy with memcpy as strcpy keeps
on tripping various analyser warnings even though its
trivially safe in this case.
Essentially code hygiene, no change in behaviour, no
perf impact.
* dfg/DFGDisassembler.cpp:
(JSC::DFG::Disassembler::dumpDisassembly):
2017-04-09 Joseph Pecoraro <pecoraro@apple.com>
test262: test262/test/annexB/language/expressions/object/__proto__-fn-name.js
https://bugs.webkit.org/show_bug.cgi?id=170650
Reviewed by Saam Barati.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseProperty):
There needs to be special handling of:
PropertyDefinition : PropertyName ':' AssignmentExpression
When the property name is __proto__. In this case the
SetFunctionName path does not happen, so the name "__proto__"
is not inferred on any anonymous function. See:
https://tc39.github.io/ecma262/#sec-__proto__-property-names-in-object-initializers
* parser/Parser.h:
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createProperty):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createProperty):
Add an extra parameter to see if inferring / setting names are allowed.
2017-04-09 Joseph Pecoraro <pecoraro@apple.com>
test262: test262/test/annexB/language/literals/regexp/identity-escape.js
https://bugs.webkit.org/show_bug.cgi?id=170651
Reviewed by Saam Barati.
* yarr/YarrParser.h:
(JSC::Yarr::Parser::parseEscape):
For \8 and \9 match just the number "8" or "9" instead of both "\\" and the number.
See: https://tc39.github.io/ecma262/#sec-decimalescape
2017-04-08 Youenn Fablet <youenn@apple.com>
WebRTC tests gardening
https://bugs.webkit.org/show_bug.cgi?id=170508
Reviewed by Eric Carlson.
* Configurations/FeatureDefines.xcconfig:
2017-04-07 Keith Miller <keith_miller@apple.com>
WebAssembly: Fix issue with BrTable targeting a Loop
https://bugs.webkit.org/show_bug.cgi?id=170638
Reviewed by Saam Barati.
This fixes the same issue V8 had in: https://github.com/WebAssembly/spec/pull/456#event-1033547537
* wasm/WasmValidate.cpp:
(JSC::Wasm::Validate::ControlData::branchTargetSignature):
2017-04-07 Keith Miller <keith_miller@apple.com>
Add a PriorityQueue class
https://bugs.webkit.org/show_bug.cgi?id=170579
Reviewed by Saam Barati.
Update Wasm::Worklist to use WTF::PriorityQueue.
* wasm/WasmWorklist.cpp:
(JSC::Wasm::Worklist::enqueue):
(JSC::Wasm::Worklist::completePlanSynchronously):
(JSC::Wasm::Worklist::stopAllPlansForVM):
(JSC::Wasm::Worklist::~Worklist):
(JSC::Wasm::Worklist::iterate): Deleted.
* wasm/WasmWorklist.h:
(JSC::Wasm::Worklist::isHigherPriority):
(JSC::Wasm::Worklist::Comparator::operator()): Deleted.
2017-04-07 Yuichiro Kikura <y.kikura@gmail.com>
WebGPU: implement ComputeCommandEncoder and related components
https://bugs.webkit.org/show_bug.cgi?id=170444
Reviewed by Alex Christensen.
I added some identifiers related with WebGPUComputeCommandEncoder based on the proposal.
https://webkit.org/wp-content/uploads/webgpu-api-proposal.html
* runtime/CommonIdentifiers.h:
2017-04-07 Saam Barati <sbarati@apple.com>
WebAssembly: Module::getOrCreateCodeBlock is wrong
https://bugs.webkit.org/show_bug.cgi?id=170612
Reviewed by Keith Miller.
When we were getting a module's CodeBlock, we were checking if !runnable(),
and if !runnable(), we were re-creating the CodeBlock. This is wrong, since
!runnable() is true while the CodeBlock is compiling. Instead, we should check
if we've finished compiling, and if so, if that compilation failed.
* wasm/WasmModule.cpp:
(JSC::Wasm::Module::getOrCreateCodeBlock):
2017-04-07 Saam Barati <sbarati@apple.com>
WebAssembly: Make to a compilation API that allows for multi-VM concurrent compilations of Wasm Modules
https://bugs.webkit.org/show_bug.cgi?id=170488
Reviewed by JF Bastien.
This patch adds a class called Wasm::Module. It contains the bits from
JSWebAssemblyModule that were not VM specific. JSWebAssemblyModule
now has a Ref<Wasm::Module>. Similarly, there is now a Wasm::CodeBlock,
which owns the non-VM-specific bits that JSWebAssemblyCodeBlock used
to own.
This patch also simplifies how we verify and compile code. Wasm::Module
now has an API for both sync/async validation and compilation. This
API abstracts away how Wasm::Plan works.
This is hopefully the last patch needed before we can implement
window.postMessage for a JSWebAssemblyModule. I think all that's
needed now to implement postMessage is simply creating a new
JSWebAssemblyModule with the underlying Wasm::Module.
This patch is neutral on WasmBench.
Finally, this patch changes the promise deferred timer to
allow for new tasks to be added while we're executing
a task. Before, we'd deadlock if this happened.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* jsc.cpp:
(functionTestWasmModuleFunctions):
* runtime/PromiseDeferredTimer.cpp:
(JSC::PromiseDeferredTimer::doWork):
(JSC::PromiseDeferredTimer::scheduleWorkSoon):
* runtime/PromiseDeferredTimer.h:
* wasm/WasmB3IRGenerator.cpp:
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToJs):
(JSC::Wasm::wasmToWasm):
(JSC::Wasm::exitStubGenerator): Deleted.
* wasm/WasmBinding.h:
* wasm/WasmCodeBlock.cpp: Added.
(JSC::Wasm::CodeBlock::CodeBlock):
(JSC::Wasm::CodeBlock::waitUntilFinished):
(JSC::Wasm::CodeBlock::compileAsync):
(JSC::Wasm::CodeBlock::isSafeToRun):
* wasm/WasmCodeBlock.h: Added.
(JSC::Wasm::CodeBlock::create):
(JSC::Wasm::CodeBlock::compilationFinished):
(JSC::Wasm::CodeBlock::runnable):
(JSC::Wasm::CodeBlock::errorMessage):
(JSC::Wasm::CodeBlock::functionImportCount):
(JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
(JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
* wasm/WasmModule.cpp: Added.
(JSC::Wasm::Module::Module):
(JSC::Wasm::makeValidationResult):
(JSC::Wasm::Module::validateSyncImpl):
(JSC::Wasm::Module::getOrCreateCodeBlock):
(JSC::Wasm::Module::compileSync):
(JSC::Wasm::Module::makeValidationCallback):
(JSC::Wasm::Module::compileAsync):
* wasm/WasmModule.h: Added.
(JSC::Wasm::Module::create):
(JSC::Wasm::Module::validateSync):
(JSC::Wasm::Module::validateAsync):
(JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace):
(JSC::Wasm::Module::moduleInformation):
(JSC::Wasm::Module::nonNullCodeBlock):
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::Plan):
(JSC::Wasm::Plan::addCompletionTask):
(JSC::Wasm::Plan::prepare):
(JSC::Wasm::Plan::compileFunctions):
(JSC::Wasm::Plan::complete):
(JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast):
(JSC::Wasm::Plan::cancel): Deleted.
* wasm/WasmPlan.h:
(JSC::Wasm::Plan::dontFinalize):
(JSC::Wasm::Plan::takeWasmToWasmExitStubs):
(JSC::Wasm::Plan::mode):
(JSC::Wasm::Plan::takeWasmExitStubs): Deleted.
(JSC::Wasm::Plan::vm): Deleted.
* wasm/WasmWorklist.cpp:
(JSC::Wasm::Worklist::stopAllPlansForVM):
* wasm/js/JSWebAssemblyCodeBlock.cpp:
(JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
(JSC::JSWebAssemblyCodeBlock::isSafeToRun):
(JSC::JSWebAssemblyCodeBlock::initialize): Deleted.
* wasm/js/JSWebAssemblyCodeBlock.h:
(JSC::JSWebAssemblyCodeBlock::create):
(JSC::JSWebAssemblyCodeBlock::functionImportCount):
(JSC::JSWebAssemblyCodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
(JSC::JSWebAssemblyCodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
(JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport):
(JSC::JSWebAssemblyCodeBlock::mode): Deleted.
(JSC::JSWebAssemblyCodeBlock::initialized): Deleted.
(JSC::JSWebAssemblyCodeBlock::plan): Deleted.
(JSC::JSWebAssemblyCodeBlock::runnable): Deleted.
(JSC::JSWebAssemblyCodeBlock::errorMessage): Deleted.
(JSC::JSWebAssemblyCodeBlock::setJSEntrypointCallee): Deleted.
(JSC::JSWebAssemblyCodeBlock::setWasmEntrypointCallee): Deleted.
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::finalizeCreation):
(JSC::JSWebAssemblyInstance::addUnitializedCodeBlock): Deleted.
* wasm/js/JSWebAssemblyInstance.h:
(JSC::JSWebAssemblyInstance::initialized): Deleted.
* wasm/js/JSWebAssemblyModule.cpp:
(JSC::JSWebAssemblyModule::createStub):
(JSC::JSWebAssemblyModule::JSWebAssemblyModule):
(JSC::JSWebAssemblyModule::finishCreation):
* wasm/js/JSWebAssemblyModule.h:
(JSC::JSWebAssemblyModule::moduleInformation):
(JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace):
(JSC::JSWebAssemblyModule::module):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::create):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance):
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::WebAssemblyModuleConstructor::createModule):
* wasm/js/WebAssemblyPrototype.cpp:
(JSC::reject):
(JSC::webAssemblyCompileFunc):
(JSC::resolve):
(JSC::instantiate):
(JSC::compileAndInstantiate):
(JSC::webAssemblyValidateFunc):
2017-04-07 Carlos Garcia Campos <cgarcia@igalia.com>
[GTK] Update the priorities used in glib main loop sources
https://bugs.webkit.org/show_bug.cgi?id=170457
Reviewed by Žan Doberšek.
* runtime/JSRunLoopTimer.cpp:
(JSC::JSRunLoopTimer::JSRunLoopTimer):
2017-04-06 Filip Pizlo <fpizlo@apple.com>
Rename allocateStack to allocateStackByGraphColoring.
Rubber stamped by Saam Barati.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/air/AirAllocateStack.cpp: Removed.
* b3/air/AirAllocateStack.h: Removed.
* b3/air/AirAllocateStackByGraphColoring.cpp: Copied from Source/JavaScriptCore/b3/air/AirAllocateStack.cpp.
(JSC::B3::Air::allocateStackByGraphColoring):
(JSC::B3::Air::allocateStack): Deleted.
* b3/air/AirAllocateStackByGraphColoring.h: Copied from Source/JavaScriptCore/b3/air/AirAllocateStack.h.
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::prepareForGeneration):
2017-04-06 Michael Saboff <msaboff@apple.com>
Cannot Object.seal() or Object.freeze() global "this"
https://bugs.webkit.org/show_bug.cgi?id=170549
Reviewed by Mark Lam.
Needed to implement JSProxy::isExtensible() which returns the results of calling
the same on wrapped object.
Implemented step 11 of Runtime Semantics: EvalDeclarationInstantiation from the ECMAScript
spec to properly return a TypeError object when attempting to add properties to a
non-extensible global object.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
* runtime/JSProxy.cpp:
(JSC::JSProxy::isExtensible):
* runtime/JSProxy.h:
2017-04-06 Filip Pizlo <fpizlo@apple.com>
Linear scan should run liveness only once
https://bugs.webkit.org/show_bug.cgi?id=170569
Reviewed by Keith Miller.
Air has a longstanding design bug that Tmps from different banks are indexed independently. This
means that all of our analyses over Tmps do separate GP and FP passes. This does have some
marginal benefits (the rest of the algorithm is specialized for Bank) but it's probably net bad.
However, I don't want to think about solving that general problem.
Instead, this just makes linear scan use a UnifiedTmpLiveness that uses a single "linear"
indexing for GP and FP. This lets me avoid the much larger refactoring (which would involve
substantial changes in graph coloring) while getting the bulk of the benefit (liveness runs once,
instead of twice, for linear scan).
This patch implements a lot of plumbing to make it possible for Liveness<> to view Tmps as having
a unified indexing scheme. Tmp calls this LinearlyIndexed (to match the naming convention of
AbsolutelyIndexed and Indexed), while AirLiveness calls this UnifiedTmpLiveness. With this
change, -O1 never does any liveness analysis that uses separate GP and FP passes. I think this
eliminates any urgency from the larger Tmp indexing bug. We can probably live with graph coloring
doing separate passes.
This is a ~6% speed-up for wasm -O1 compile times. I think this means that linear scan is no
longer the longest pole in the tent.
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3VariableLiveness.h:
(JSC::B3::VariableLivenessAdapter::prepareToCompute):
* b3/air/AirAllocateRegistersByLinearScan.cpp:
(JSC::B3::Air::allocateRegistersByLinearScan):
* b3/air/AirCode.h:
(JSC::B3::Air::Code::forEachTmp):
* b3/air/AirLiveness.h:
* b3/air/AirLivenessAdapter.h:
(JSC::B3::Air::LivenessAdapter::Actions::Actions):
(JSC::B3::Air::LivenessAdapter::LivenessAdapter):
(JSC::B3::Air::LivenessAdapter::adapter):
(JSC::B3::Air::LivenessAdapter::prepareToCompute):
(JSC::B3::Air::LivenessAdapter::actionsAt):
(JSC::B3::Air::LivenessAdapter::forEachUse):
(JSC::B3::Air::LivenessAdapter::forEachDef):
(JSC::B3::Air::TmpLivenessAdapter::numIndices):
(JSC::B3::Air::UnifiedTmpLivenessAdapter::UnifiedTmpLivenessAdapter):
(JSC::B3::Air::UnifiedTmpLivenessAdapter::numIndices):
(JSC::B3::Air::UnifiedTmpLivenessAdapter::acceptsBank):
(JSC::B3::Air::UnifiedTmpLivenessAdapter::acceptsRole):
(JSC::B3::Air::UnifiedTmpLivenessAdapter::valueToIndex):
(JSC::B3::Air::UnifiedTmpLivenessAdapter::indexToValue):
* b3/air/AirLivenessConstraints.h: Removed.
* b3/air/AirRegLiveness.h:
(JSC::B3::Air::RegLiveness::LocalCalc::LocalCalc):
* b3/air/AirTmp.cpp:
* b3/air/AirTmp.h:
* b3/air/AirTmpInlines.h:
(JSC::B3::Air::Tmp::LinearlyIndexed::LinearlyIndexed):
(JSC::B3::Air::Tmp::LinearlyIndexed::index):
(JSC::B3::Air::Tmp::linearlyIndexed):
(JSC::B3::Air::Tmp::indexEnd):
(JSC::B3::Air::Tmp::absoluteIndexEnd):
(JSC::B3::Air::Tmp::linearIndexEnd):
(JSC::B3::Air::Tmp::tmpForAbsoluteIndex):
(JSC::B3::Air::Tmp::tmpForLinearIndex):
* b3/air/AirTmpMap.h: Added.
(JSC::B3::Air::TmpMap::TmpMap):
(JSC::B3::Air::TmpMap::resize):
(JSC::B3::Air::TmpMap::clear):
(JSC::B3::Air::TmpMap::operator[]):
(JSC::B3::Air::TmpMap::append):
2017-04-06 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r215046.
This change broke internal builds.
Reverted changeset:
"WebRTC tests gardening"
https://bugs.webkit.org/show_bug.cgi?id=170508
http://trac.webkit.org/changeset/215046
2017-04-06 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Show all headers in the Request Headers section of the Resource details sidebar
https://bugs.webkit.org/show_bug.cgi?id=16531
<rdar://problem/5712895>
Reviewed by Timothy Hatcher.
* inspector/protocol/Network.json:
Optional refined list of request headers in Metrics.
2017-04-06 Filip Pizlo <fpizlo@apple.com>
B3 -O1 should generate better code than -O0
https://bugs.webkit.org/show_bug.cgi?id=170563
Reviewed by Michael Saboff.
Prior to this change, code generated by -O1 ran slower than code generated by -O0. This turned
out to be because of reduceStrength optimizations that increase live ranges and create register
pressure, which then creates problems for linear scan.
It seemed obvious that canonicalizations that help isel, constant folding, and one-for-one
strength reductions should stay. It also seemed obvious that SSA and CFG simplification are fast
and harmless. So, I focused on removing:
- CSE, which increases live ranges. This is a risky optimization when we know that we've chosen
to use a bad register allocator.
- Sophisticated strength reductions that create more code, like the insane division optimization.
- Anything that inserts basic blocks.
CSE appeared to be the cause of half of the throughput regression of -O1 but none of the compile
time. This change also reduces the running time of reduceStrength by making it not a fixpoint at
optLevel<2.
This makes wasm -O1 compile 17% faster. This makes wasm -O1 run 19% faster. This makes -O1 code
run 3% faster than -O0, and compile about 4% slower than -O0. We may yet end up choosing to use
-O0, but at least now -O1 isn't totally useless.
* b3/B3ReduceStrength.cpp:
2017-04-06 Jon Davis <jond@apple.com>
Updates feature status for recently shipped features
https://bugs.webkit.org/show_bug.cgi?id=170359
Reviewed by Brian Burg.
Changed "Done" status to "Supported".
* features.json:
2017-04-06 Youenn Fablet <youenn@apple.com>
WebRTC tests gardening
https://bugs.webkit.org/show_bug.cgi?id=170508
Reviewed by Eric Carlson.
* Configurations/FeatureDefines.xcconfig:
2017-04-06 Guillaume Emont <guijemont@igalia.com>
[JSC][MIPS][DFG] Use x86 generic HasOwnProperty
https://bugs.webkit.org/show_bug.cgi?id=170222
Reviewed by Yusuke Suzuki.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
use the X86 special version for HasOwnProperty on MIPS too.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
use the X86 special version for HasOwnProperty on MIPS too.
2017-04-05 Saam Barati <sbarati@apple.com>
REGRESSION fix bad isWasm() test by ensuring proper Wasm callee bit pattern
https://bugs.webkit.org/show_bug.cgi?id=170494
<rdar://problem/31446485>
Reviewed by Yusuke Suzuki and Mark Lam.
This patch fixes how we test a 64 bit JSValue pattern to see if it's
a Wasm callee. We now tag Wasm::Callee's with 0b011 in their lower 3 bits.
The new test is for a Wasm Callee is as follows:
isWasm(uint64_t x)
{
return x & 0xffff000000000007 == 3;
}
This test works because the lower 3 bits of the non-number immediate values are as follows:
undefined: 0b010
null: 0b010
true: 0b111
false: 0b110
The test rejects all of these because none have just the value 3 in their lower 3 bits.
The test also rejects all numbers, because they have non-zero upper 16 bits.
The test also rejects normal cells because they won't have the number 3 as
their lower 3 bits. Note, this bit pattern also allows the normal JSValue isCell(), etc,
predicates to work on a Wasm::Callee because the various tests will fail if you
bit casted a boxed Wasm::Callee* to a JSValue. isCell() would fail since it sees
TagBitTypeOther. The other tests also trivially fail, since it won't be a number,
and it won't be equal to null, undefined, true, or false. The isBoolean() predicate
will fail because we won't have TagBitBool set.
* interpreter/CallFrame.h:
(JSC::ExecState::guaranteedJSValueCallee):
(JSC::ExecState::calleeAsValue): Deleted.
* interpreter/CalleeBits.h:
(JSC::CalleeBits::boxWasm):
(JSC::CalleeBits::isWasm):
(JSC::CalleeBits::asWasmCallee):
* jit/JITOperations.cpp:
* runtime/JSCJSValue.h:
2017-04-05 Keith Miller <keith_miller@apple.com>
WebAssembly: Plans should be able to have more than one completion task.
https://bugs.webkit.org/show_bug.cgi?id=170516
Reviewed by Saam Barati.
This patch also eliminates the need for blocked tasks on the
PromiseDeferredTimer and pendingPromise on Wasm::Plan.
* runtime/PromiseDeferredTimer.cpp:
(JSC::PromiseDeferredTimer::doWork):
(JSC::PromiseDeferredTimer::cancelPendingPromise):
(JSC::PromiseDeferredTimer::scheduleBlockedTask): Deleted.
* runtime/PromiseDeferredTimer.h:
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::Plan):
(JSC::Wasm::Plan::addCompletionTask):
(JSC::Wasm::Plan::complete):
* wasm/WasmPlan.h:
(JSC::Wasm::Plan::setMode):
(JSC::Wasm::Plan::mode):
(JSC::Wasm::Plan::setModeAndPromise): Deleted.
(JSC::Wasm::Plan::pendingPromise): Deleted.
* wasm/WasmWorklist.cpp:
(JSC::Wasm::Worklist::enqueue):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance):
* wasm/js/WebAssemblyPrototype.cpp:
(JSC::instantiate):
2017-04-05 Guilherme Iscaro <iscaro@profusion.mobi>
Do not use BLX for immediates (ARM-32)
https://bugs.webkit.org/show_bug.cgi?id=170351
Reviewed by Mark Lam.
Currently the offline asm generator for 32-bit ARM code translates the
'call' meta-instruction (which may be found in LowLevelInterpreter.asm
and friends) to the ARM's BLX instrunction. The BLX instruction may be
used for labels (immediates) and registers and one side effect of BLX
is that it may switch the processor's instruction set.
A 'BLX register' instruction will change/remain the processor state to
ARM if the register_bit[0] is set to 0 or change/remain to Thumb if
register_bit[0] is set to 1. However, a 'BLX label' instruction will
always switch the processor state. It switches ARM to thumb and vice-versa.
This behaviour is unwanted, since the C++ code and the offlineasm generated code
are both compiled using the same instruction set, thus a instruction
set change will likely produce a crash. In order to fix the problem the
BL instruction can be used for labels. It will branch just like BLX,
but it won't change the instruction set. It's important to note that
Darwin is not affected by this problem, thus to minimize the impact of
this change the BL instruction will only be used on non-darwin targets.
BLX reference: http://infocenter.arm.com/help/topic/com.arm.doc.dui0489i/CIHBJCDC.html?resultof=%22%62%6c%78%22%20
* offlineasm/arm.rb:
2017-04-05 Keith Miller <keith_miller@apple.com>
WebAssembly: We shouldn't need to pin size registers if we have a fast memory.
https://bugs.webkit.org/show_bug.cgi?id=170504
Reviewed by Mark Lam.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::createJSToWasmWrapper):
(JSC::Wasm::parseAndCompile):
* wasm/WasmMemoryInformation.h:
(JSC::Wasm::PinnedRegisterInfo::toSave):
2017-04-05 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Suppress warnings in GCC
https://bugs.webkit.org/show_bug.cgi?id=170501
Reviewed by Keith Miller.
Should use ASSERT_NOT_REACHED since return-type pragma is only
enabled under ASSERT_DISABLED environment. We shoud use
ASSERT_NOTREACHED to emit assertions in debug build. It effectively
catches bugs while keeping performance in release build.
* b3/B3Opcode.cpp:
(JSC::B3::storeOpcode):
* b3/B3Width.h:
(JSC::B3::mask):
* runtime/Options.cpp:
(JSC::parse):
* wasm/WasmSections.h:
(JSC::Wasm::makeString):
* wasm/WasmSignature.cpp:
(JSC::Wasm::SignatureInformation::tryCleanup):
* wasm/generateWasmValidateInlinesHeader.py:
2017-04-05 Carlos Garcia Campos <cgarcia@igalia.com>
Implement PromiseDeferredTimer for non CF based ports
https://bugs.webkit.org/show_bug.cgi?id=170391
Reviewed by Yusuke Suzuki.
RunLoop handling is only implemented for CF causing several wasm tests to fail for other ports.
* jsc.cpp:
(runJSC): Remove CF ifdefs.
* runtime/PromiseDeferredTimer.cpp:
(JSC::PromiseDeferredTimer::doWork): Add non CF implementation using WTF RunLoop.
(JSC::PromiseDeferredTimer::runRunLoop): Ditto.
* runtime/PromiseDeferredTimer.h:
2017-04-05 Carlos Garcia Campos <cgarcia@igalia.com>
WebAssembly: several tests added in r214504 crash when building with GCC
https://bugs.webkit.org/show_bug.cgi?id=170390
Reviewed by Saam Barati.
The pattern foo->bar([f = WTFMove(foo)]{}); crashes when building with GCC, I assume the move happens before the
foo is used to invoke the function.
* wasm/js/WebAssemblyPrototype.cpp:
(JSC::webAssemblyCompileFunc): Use p.vm() instead of plan->vm(), because plan is moved by the lambda.
(JSC::instantiate): Ditto.
(JSC::compileAndInstantiate): Ditto.
2017-03-16 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Generate TemplateObjects at linking time
https://bugs.webkit.org/show_bug.cgi?id=169743
Reviewed by Keith Miller.
Currently, the code calls getTemplateObject to get appropriate template objects at runtime.
But this template object is constant value and never changed. So instead of creating it
at runtime, we should create it at linking time and store it in the constant registers.
* builtins/BuiltinNames.h:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::setConstantRegisters):
* bytecode/CodeBlock.h:
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::shrinkToFit):
* bytecode/UnlinkedCodeBlock.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::addTemplateRegistryKeyConstant):
(JSC::BytecodeGenerator::emitGetTemplateObject):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::TaggedTemplateNode::emitBytecode):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::getTemplateObject): Deleted.
* runtime/JSTemplateRegistryKey.cpp:
* runtime/JSTemplateRegistryKey.h:
(JSC::isTemplateRegistryKey):
2017-04-04 Mark Lam <mark.lam@apple.com>
On ARM64, DFG::SpeculativeJIT::compileArithMod() failed to ensure result is of DataFormatInt32.
https://bugs.webkit.org/show_bug.cgi?id=170473
<rdar://problem/29912391>
Reviewed by Saam Barati.
In Unchecked mode, when DFG::SpeculativeJIT::compileArithMod() detects that the
divisor is 0, we want it to return 0. The result is expected to be of
DataFormatIn32.
The ARM implementation just returns the value in the divisor register. However,
the divisor in this case can be of DataFormatJSInt32. On ARM64, returning the
divisor register yields the wrong result format because the same register also
holds the upper 32-bit of the JSValue encoding. The fix is to return an
immediate 0 instead.
Also turned on the assertion in jitAssertIsInt32 for ARM64. This assertion being
disabled may have contributed to this bug going unnoticed all this time.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithMod):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::jitAssertIsInt32):
2017-04-04 Filip Pizlo <fpizlo@apple.com>
Air::eliminateDeadCode should not repeatedly process the same live instructions
https://bugs.webkit.org/show_bug.cgi?id=170490
Reviewed by Keith Miller.
This makes the eliminateDeadCode() fixpoint somewhat worklist-based: we track the set
of Insts that might be dead. Every time we detect that one is live, we remove it from
the set. This is a big (>2x) speed-up because lots of Insts are immediately found to
be live.
This is a ~1% wasm -O1 compile time progression.
* b3/air/AirEliminateDeadCode.cpp:
(JSC::B3::Air::eliminateDeadCode):
2017-04-04 Filip Pizlo <fpizlo@apple.com>
Air::eliminateDeadCode() should not use a HashSet
https://bugs.webkit.org/show_bug.cgi?id=170487
Reviewed by Saam Barati.
Introduce TmpSet, which is like a HashSet<Tmp>. Use this to make eliminateDeadCode()
about 50% faster, resulting in a 1% wasm -O1 compile time progression.
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/air/AirEliminateDeadCode.cpp:
(JSC::B3::Air::eliminateDeadCode):
* b3/air/AirTmpSet.h: Added.
(JSC::B3::Air::TmpSet::TmpSet):
(JSC::B3::Air::TmpSet::add):
(JSC::B3::Air::TmpSet::remove):
(JSC::B3::Air::TmpSet::contains):
(JSC::B3::Air::TmpSet::size):
(JSC::B3::Air::TmpSet::isEmpty):
(JSC::B3::Air::TmpSet::iterator::iterator):
(JSC::B3::Air::TmpSet::iterator::operator*):
(JSC::B3::Air::TmpSet::iterator::operator++):
(JSC::B3::Air::TmpSet::iterator::operator==):
(JSC::B3::Air::TmpSet::iterator::operator!=):
(JSC::B3::Air::TmpSet::begin):
(JSC::B3::Air::TmpSet::end):
2017-04-04 Keith Miller <keith_miller@apple.com>
WebAssembly: ModuleInformation should be a ref counted thing that can be shared across threads.
https://bugs.webkit.org/show_bug.cgi?id=170478
Reviewed by Saam Barati.
ModuleInformation has been moved to its own file and is now
ThreadSafeRefCounted. All the Strings we used to keep in the
ModuleInformation have been switched to Vector<LChar> this has the
advantage that it can be passed across threads. However, this does
mean that we need to decode the utf8 strings in each thread. This
is likely not a problem because:
1) most modules have few imports/exports/custom sections.
2) most of the time they are ascii so the conversion is cheap.
3) we only have to do it once per thread, and there shouldn't be too many.
This patch also removes
moduleSignatureIndicesToUniquedSignatureIndices since that
information can already be recovered from the
SignatureInformation.
* JavaScriptCore.xcodeproj/project.pbxproj:
* jsc.cpp:
(functionTestWasmModuleFunctions):
* runtime/Identifier.h:
(JSC::Identifier::fromString):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::parseAndCompile):
* wasm/WasmB3IRGenerator.h:
* wasm/WasmFormat.cpp:
(JSC::Wasm::makeString):
(JSC::Wasm::ModuleInformation::~ModuleInformation): Deleted.
* wasm/WasmFormat.h:
(JSC::Wasm::makeString):
(JSC::Wasm::ModuleInformation::functionIndexSpaceSize): Deleted.
(JSC::Wasm::ModuleInformation::isImportedFunctionFromFunctionIndexSpace): Deleted.
(JSC::Wasm::ModuleInformation::signatureIndexFromFunctionIndexSpace): Deleted.
(JSC::Wasm::ModuleInformation::importFunctionCount): Deleted.
(JSC::Wasm::ModuleInformation::internalFunctionCount): Deleted.
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::FunctionParser):
* wasm/WasmModuleInformation.cpp: Copied from Source/JavaScriptCore/wasm/WasmValidate.h.
(JSC::Wasm::ModuleInformation::~ModuleInformation):
* wasm/WasmModuleInformation.h: Added.
(JSC::Wasm::ModuleInformation::functionIndexSpaceSize):
(JSC::Wasm::ModuleInformation::isImportedFunctionFromFunctionIndexSpace):
(JSC::Wasm::ModuleInformation::signatureIndexFromFunctionIndexSpace):
(JSC::Wasm::ModuleInformation::importFunctionCount):
(JSC::Wasm::ModuleInformation::internalFunctionCount):
(JSC::Wasm::ModuleInformation::ModuleInformation):
* wasm/WasmModuleParser.cpp:
* wasm/WasmModuleParser.h:
(JSC::Wasm::ModuleParser::ModuleParser):
* wasm/WasmParser.h:
(JSC::Wasm::Parser<SuccessType>::consumeUTF8String):
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::Plan):
(JSC::Wasm::Plan::parseAndValidateModule):
(JSC::Wasm::Plan::prepare):
(JSC::Wasm::Plan::compileFunctions):
(JSC::Wasm::Plan::complete):
(JSC::Wasm::Plan::cancel):
* wasm/WasmPlan.h:
(JSC::Wasm::Plan::internalFunctionCount):
(JSC::Wasm::Plan::takeModuleInformation):
* wasm/WasmSignature.cpp:
(JSC::Wasm::SignatureInformation::get):
* wasm/WasmSignature.h:
* wasm/WasmValidate.cpp:
(JSC::Wasm::validateFunction):
* wasm/WasmValidate.h:
* wasm/js/JSWebAssemblyHelpers.h:
(JSC::createSourceBufferFromValue):
* wasm/js/JSWebAssemblyModule.cpp:
(JSC::JSWebAssemblyModule::createStub):
(JSC::JSWebAssemblyModule::JSWebAssemblyModule):
(JSC::JSWebAssemblyModule::finishCreation):
* wasm/js/JSWebAssemblyModule.h:
(JSC::JSWebAssemblyModule::moduleInformation):
(JSC::JSWebAssemblyModule::source):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance):
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::WebAssemblyModuleConstructor::createModule):
* wasm/js/WebAssemblyModulePrototype.cpp:
(JSC::webAssemblyModuleProtoCustomSections):
(JSC::webAssemblyModuleProtoImports):
(JSC::webAssemblyModuleProtoExports):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
* wasm/js/WebAssemblyModuleRecord.h:
* wasm/js/WebAssemblyPrototype.cpp:
(JSC::webAssemblyCompileFunc):
(JSC::instantiate):
(JSC::compileAndInstantiate):
2017-04-04 Filip Pizlo <fpizlo@apple.com>
B3::fixSSA() needs a tune-up
https://bugs.webkit.org/show_bug.cgi?id=170485
Reviewed by Saam Barati.
After the various optimizations to liveness, register allocation, and other phases, the
fixSSA() phase now looks like one of the top offenders. This includes a bunch of
changes to make this phase run faster. This is a ~7% wasm -O1 compile time progression.
Here's what I did:
- We now use IndexSparseSet instead of IndexMap for tracking variable values. This
makes it cheaper to chew through small blocks while there is a non-trivial number of
total variables.
- We now do a "local SSA conversion" pass before anything else. This eliminates
obvious Get's. If we were using temporary Variables, it would eliminate many of
those. That's useful for when we use demoteValues() and duplciateTails(). For wasm
-O1, we mainly care about the fact that it makes a bunch of Set's dead.
- We now do a Set DCE pass after the local SSA but before SSA conversion. This ensures
that any block-local live intervals of Variables disappear and don't need further
consideration.
- We now cache the reaching defs calculation.
- We now perform the reaching defs calculation lazily.
* b3/B3FixSSA.cpp:
(JSC::B3::demoteValues):
(JSC::B3::fixSSA):
* b3/B3SSACalculator.cpp:
(JSC::B3::SSACalculator::reachingDefAtTail):
* b3/B3VariableLiveness.cpp:
(JSC::B3::VariableLiveness::VariableLiveness):
* b3/air/AirLiveness.h:
(JSC::B3::Air::Liveness::Liveness):
* dfg/DFGLivenessAnalysisPhase.cpp:
(JSC::DFG::LivenessAnalysisPhase::LivenessAnalysisPhase): Deleted.
(JSC::DFG::LivenessAnalysisPhase::run): Deleted.
(JSC::DFG::LivenessAnalysisPhase::processBlock): Deleted.
2017-04-04 Joseph Pecoraro <pecoraro@apple.com>
Remove stale LLVM Header Path includes from JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=170483
Reviewed by Mark Lam.
* Configurations/Base.xcconfig:
2017-04-04 Filip Pizlo <fpizlo@apple.com>
B3::LowerToAir incorrectly selects BitXor(AtomicStrongCAS(...), $1)
https://bugs.webkit.org/show_bug.cgi?id=169867
Reviewed by Saam Barati.
The BitXor(AtomicWeakCAS(...), $1) optimization makes a lot of sense because we an fold the
BitXor into the CAS condition read-out. But there is no version of this that is profitable or
correct for AtomicStrongCAS. The inversion case is handled by Equal(AtomicStrongCAS(...), ...)
becoming NotEqual(AtomicStrongCAS(...), ...), and we alraedy handle that separately.
So, the fix here is to make the BitXor CAS pattern only recognize AtomicWeakCAS.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/testb3.cpp:
(JSC::B3::testAtomicStrongCAS):
2017-04-04 Saam Barati <sbarati@apple.com>
WebAssembly: JSWebAssemblyCallee should not be a JSCell
https://bugs.webkit.org/show_bug.cgi?id=170135
Reviewed by Michael Saboff.
This patch is perhaps the last big change to the design of fundamental
Wasm API to allow for PIC. It changes JSWebAssemblyCallee into a thing
called Wasm::Callee. It serves the same purpose as before, except
Wasm::Callee is not a JSCell. I had to refactor the various parts of the
runtime that will see CallFrame's with Wasm::Callee's in the callee slot.
Thankfully, the parts of the runtime that Wasm touches are limited. The
main refactoring is changing the exception handling code, such as taking
a stack trace, to be friendly to seeing a non JSCell callee.
The callee() function on ExecState now returns a class I added in this
patch called CalleeBits. CalleeBits will tell you if the callee is a
JSCell or a Wasm::Callee. We tag Wasm::Callee's with a 1 in their lower
bit so we can easily tell what is and isn't a Wasm::Callee.
The stub that calls out from Wasm to JS still puts a JSCell callee
into the call frame, even though the callee logically represents a
Wasm frame. The reason for this is that we use the call IC infrastructure
to make a call out to JS code, and the code that writes the IC expects
a JSCell as the callee. This is knowingly part of our design. When we
do structured cloning of Wasm Modules, we'll need to regenerate these
JS call stubs.
* API/JSContextRef.cpp:
(BacktraceFunctor::operator()):
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* debugger/Debugger.cpp:
(JSC::Debugger::pauseIfNeeded):
(JSC::Debugger::currentDebuggerCallFrame):
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::create):
(JSC::DebuggerCallFrame::DebuggerCallFrame):
(JSC::DebuggerCallFrame::currentPosition):
(JSC::DebuggerCallFrame::positionForCallFrame):
* debugger/DebuggerCallFrame.h:
* interpreter/CallFrame.cpp:
(JSC::CallFrame::vmEntryGlobalObject):
(JSC::CallFrame::wasmAwareLexicalGlobalObject):
(JSC::CallFrame::isAnyWasmCallee):
(JSC::CallFrame::callerSourceOrigin):
* interpreter/CallFrame.h:
(JSC::ExecState::calleeAsValue):
(JSC::ExecState::jsCallee):
(JSC::ExecState::callee):
(JSC::ExecState::unsafeCallee):
(JSC::ExecState::scope):
(JSC::ExecState::iterate):
* interpreter/CalleeBits.h: Added.
(JSC::CalleeBits::CalleeBits):
(JSC::CalleeBits::operator=):
(JSC::CalleeBits::boxWasm):
(JSC::CalleeBits::isWasm):
(JSC::CalleeBits::isCell):
(JSC::CalleeBits::asCell):
(JSC::CalleeBits::asWasmCallee):
(JSC::CalleeBits::rawPtr):
* interpreter/Interpreter.cpp:
(JSC::GetStackTraceFunctor::operator()):
(JSC::Interpreter::getStackTrace):
(JSC::notifyDebuggerOfUnwinding):
(JSC::UnwindFunctor::UnwindFunctor):
(JSC::UnwindFunctor::operator()):
(JSC::UnwindFunctor::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
(JSC::Interpreter::unwind):
(JSC::Interpreter::notifyDebuggerOfExceptionToBeThrown):
* interpreter/Interpreter.h:
* interpreter/Register.h:
(JSC::Register::pointer):
* interpreter/ShadowChicken.cpp:
(JSC::ShadowChicken::update):
* interpreter/ShadowChickenInlines.h:
(JSC::ShadowChicken::iterate):
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::StackVisitor):
(JSC::StackVisitor::readFrame):
(JSC::StackVisitor::readNonInlinedFrame):
(JSC::StackVisitor::readInlinedFrame):
(JSC::StackVisitor::Frame::calleeSaveRegisters):
(JSC::StackVisitor::Frame::functionName):
(JSC::StackVisitor::Frame::dump):
* interpreter/StackVisitor.h:
(JSC::StackVisitor::Frame::callee):
(JSC::StackVisitor::visit):
* jit/Repatch.cpp:
(JSC::linkFor):
(JSC::linkPolymorphicCall):
* jsc.cpp:
(callWasmFunction):
(functionTestWasmModuleFunctions):
* runtime/ArrayPrototype.cpp:
* runtime/Error.cpp:
(JSC::addErrorInfoAndGetBytecodeOffset):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::finishCreation):
* runtime/JSCell.cpp:
(JSC::JSCell::isAnyWasmCallee): Deleted.
* runtime/JSCell.h:
* runtime/JSCellInlines.h:
(JSC::ExecState::vm):
* runtime/JSFunction.cpp:
(JSC::RetrieveArgumentsFunctor::operator()):
(JSC::RetrieveCallerFunctionFunctor::operator()):
* runtime/JSGlobalObject.cpp:
* runtime/SamplingProfiler.cpp:
(JSC::FrameWalker::recordJSFrame):
(JSC::SamplingProfiler::processUnverifiedStackTraces):
* runtime/SamplingProfiler.h:
(JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame):
* runtime/StackFrame.cpp:
(JSC::StackFrame::sourceURL):
(JSC::StackFrame::functionName):
* runtime/StackFrame.h:
(JSC::StackFrame::wasm):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::throwException):
* runtime/VM.h:
* wasm/JSWebAssembly.h:
* wasm/WasmB3IRGenerator.cpp:
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToWasm):
* wasm/WasmCallee.cpp: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyCallee.cpp.
(JSC::Wasm::Callee::Callee):
(JSC::JSWebAssemblyCallee::JSWebAssemblyCallee): Deleted.
(JSC::JSWebAssemblyCallee::finishCreation): Deleted.
(JSC::JSWebAssemblyCallee::destroy): Deleted.
* wasm/WasmCallee.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyCallee.h.
(JSC::Wasm::Callee::create):
(JSC::JSWebAssemblyCallee::create): Deleted.
(JSC::JSWebAssemblyCallee::createStructure): Deleted.
(JSC::JSWebAssemblyCallee::entrypoint): Deleted.
(JSC::JSWebAssemblyCallee::calleeSaveRegisters): Deleted.
* wasm/WasmContext.h:
* wasm/WasmPlan.cpp:
* wasm/WasmPlan.h:
* wasm/WasmPlanInlines.h:
(JSC::Wasm::Plan::initializeCallees):
* wasm/WasmThunks.cpp:
(JSC::Wasm::throwExceptionFromWasmThunkGenerator):
* wasm/js/JSWebAssemblyCallee.cpp: Removed.
* wasm/js/JSWebAssemblyCallee.h: Removed.
* wasm/js/JSWebAssemblyCodeBlock.cpp:
(JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
(JSC::JSWebAssemblyCodeBlock::initialize):
(JSC::JSWebAssemblyCodeBlock::visitChildren):
* wasm/js/JSWebAssemblyCodeBlock.h:
(JSC::JSWebAssemblyCodeBlock::create):
(JSC::JSWebAssemblyCodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
(JSC::JSWebAssemblyCodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
(JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport):
(JSC::JSWebAssemblyCodeBlock::offsetOfImportWasmToJSStub):
(JSC::JSWebAssemblyCodeBlock::setJSEntrypointCallee):
(JSC::JSWebAssemblyCodeBlock::setWasmEntrypointCallee):
(JSC::JSWebAssemblyCodeBlock::offsetOfImportStubs):
(JSC::JSWebAssemblyCodeBlock::allocationSize):
(JSC::JSWebAssemblyCodeBlock::importWasmToJSStub):
(JSC::JSWebAssemblyCodeBlock::callees): Deleted.
(JSC::JSWebAssemblyCodeBlock::offsetOfCallees): Deleted.
* wasm/js/JSWebAssemblyInstance.h:
(JSC::JSWebAssemblyInstance::webAssemblyToJSCallee):
* wasm/js/JSWebAssemblyModule.cpp:
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
(JSC::WebAssemblyFunction::create):
(JSC::WebAssemblyFunction::WebAssemblyFunction):
(JSC::WebAssemblyFunction::visitChildren):
(JSC::WebAssemblyFunction::finishCreation):
* wasm/js/WebAssemblyFunction.h:
(JSC::WebAssemblyFunction::wasmEntrypoint):
(JSC::WebAssemblyFunction::jsEntrypoint):
(JSC::WebAssemblyFunction::offsetOfWasmEntrypoint):
(JSC::WebAssemblyFunction::offsetOfWasmEntryPointCode): Deleted.
* wasm/js/WebAssemblyModuleConstructor.cpp:
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
(JSC::WebAssemblyModuleRecord::evaluate):
2017-04-04 Keith Miller <keith_miller@apple.com>
WasmBench asserts in debug jsc
https://bugs.webkit.org/show_bug.cgi?id=170462
Reviewed by Saam Barati.
The assertion should have been an if.
* wasm/WasmWorklist.cpp:
2017-04-04 Filip Pizlo <fpizlo@apple.com>
Air::lowerAfterRegAlloc should bail early if it finds no Shuffles or ColdCCalls
https://bugs.webkit.org/show_bug.cgi?id=170305
Reviewed by Saam Barati.
This reduces and sometimes completely eliminates the need to run lowerAfterRegAlloc().
This lowers the Shuffle for the arguments of a CCall before register allocation unless
the CCall arguments require a real shuffle (like if the CCall arguments were argument
registers). This lowers a ColdCCall like a CCall for optLevel<2.
Finally, lowerAfterRegAlloc() now checks if there are any Shuffles or CCalls before it
does anything else. For wasm at -O1, this means that the phase doesn't run at all. This
is a ~3% wasm -O1 compile time progression.
To make this easy, I changed optLevel into a property of Procedure and Code rather than
an argument we thread through everything. I like how Procedure and Code are dumping
ground classes. This does not bother me. Note that I cloned optLevel into Procedure and
Code so that it's cheap to query inside Air phases.
* b3/B3Compile.cpp:
(JSC::B3::compile):
* b3/B3Compile.h:
* b3/B3Generate.cpp:
(JSC::B3::prepareForGeneration):
(JSC::B3::generateToAir):
* b3/B3Generate.h:
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::setOptLevel):
* b3/B3Procedure.h:
(JSC::B3::Procedure::optLevel):
* b3/air/AirCode.h:
(JSC::B3::Air::Code::isPinned):
(JSC::B3::Air::Code::setOptLevel):
(JSC::B3::Air::Code::optLevel):
* b3/air/AirEmitShuffle.cpp:
(JSC::B3::Air::ShufflePair::bank):
(JSC::B3::Air::ShufflePair::opcode):
(JSC::B3::Air::ShufflePair::inst):
(JSC::B3::Air::emitShuffle):
* b3/air/AirEmitShuffle.h:
(JSC::B3::Air::moveFor):
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::prepareForGeneration):
* b3/air/AirGenerate.h:
* b3/air/AirLowerAfterRegAlloc.cpp:
(JSC::B3::Air::lowerAfterRegAlloc):
* b3/air/AirLowerMacros.cpp:
(JSC::B3::Air::lowerMacros):
* b3/testb3.cpp:
(JSC::B3::compileProc):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::parseAndCompile):
2017-04-04 Filip Pizlo <fpizlo@apple.com>
Don't need to Air::reportUsedRegisters for wasm at -O1
https://bugs.webkit.org/show_bug.cgi?id=170459
Reviewed by Saam Barati.
I did some refactorings to Liveness<> to try to understand its performance. Based on
this I concluded that the bigger immediate issue is just removing unnecessary phases
from -O1.
This removes Air::reportUsedRegisters() from -O1 if the user has indicated that he is
not interested in StackmapGenerationParams::usedRegisters(). The logic here is a bit
weird because of how Air does spill code generation. The register allocator's spiller
will emit spill code using identifiable spill slots, which allows subsequent phases to
register-allocate the spill slots. We do this by a forward flow CSE phase called
fixObviousSpills (which is a terrible name since there is no longer anything obvious
about some of the spills that this phase can fix!). As is most natural for CSEs over
3AC, it rewires the uses of redundant computations rather than removing the redundant
computations. This means that if a spill got "fixed", there may be either or both of
the following:
- Dead loads from the stack.
- Dead stores to the stack.
We know that a load from the stack is dead if the register is dead at the point of the
load. We know that a store to the stack is dead if the spill slot is dead at the point
of the store.
Unfortunately, liveness analysis - over either registers or spill slots - is expensive.
Fortunately, allocateStack() already does liveness analysis over spill slots. So, we
baked elimination of stores to the stack into that phase. That aspect of clean-up after
the spill CSE comes for free.
Also fortunately for the FTL, we have to do reportUsedRegisters() anyway. This is a
phase that enables StackmapGenerationParams::usedRegisters() to work, which then
enables the FTL's patchpoints to do crazy slow-path live range splitting. So, Air's
strategy for the load fix-up after spill CSE is to do it as part of
reportUsedRegisters().
This patch introduces the Procedure::setNeedsUsedRegisters() API. But if you set
needsUsedRegisters to false then we will still run reportUsedRegisters() at -O2 as an
optimization - it removes dead loads from the stack that are left behind from
fixObviousSpills().
This is a ~6% compile time progression at -O1.
* b3/B3Procedure.h:
(JSC::B3::Procedure::setNeedsUsedRegisters):
(JSC::B3::Procedure::needsUsedRegisters):
* b3/B3StackmapGenerationParams.h:
* b3/B3VariableLiveness.cpp:
(JSC::B3::VariableLiveness::VariableLiveness):
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::needsUsedRegisters):
* b3/air/AirCode.h:
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::prepareForGeneration):
* b3/air/AirLiveness.h:
(JSC::B3::Air::Liveness::Liveness):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::parseAndCompile):
2017-04-03 Filip Pizlo <fpizlo@apple.com>
Air liveness should build constraints and solve them rather than repeatedly parsing IR
https://bugs.webkit.org/show_bug.cgi?id=170421
Reviewed by Saam Barati.
Inst::forEach<> is expensive. The LivenessAdapter uses forEach with a particularly
gnarly lambda that has many extra checks. Therefore, a lot of the time spent in
liveness analysis is just recomputing forEach<> and that lambda to get uses and defs.
This introduces LivenessConstraints<>, which is a liveness constraint system based on
Adapter. It basically caches the results of doing forEach. It'll give you the uses and
defs at each instruction boundary.
This is a ~5% compile time progression at optLevel=1. It's also a ~3% compile time
progression at optLevel=2.
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/air/AirLivenessAdapter.h:
(JSC::B3::Air::LivenessAdapter::LivenessAdapter):
(JSC::B3::Air::LivenessAdapter::forEachUse):
(JSC::B3::Air::LivenessAdapter::forEachDef):
* b3/air/AirLivenessConstraints.h: Added.
(JSC::B3::Air::LivenessConstraints::Actions::Actions):
(JSC::B3::Air::LivenessConstraints::LivenessConstraints):
(JSC::B3::Air::LivenessConstraints::at):
2017-04-03 Mark Lam <mark.lam@apple.com>
Fix incorrect capacity delta calculation reported in SparseArrayValueMap::add().
https://bugs.webkit.org/show_bug.cgi?id=170412
<rdar://problem/29697336>
Reviewed by Filip Pizlo.
Here's an example of code that will trigger underflow in the "deprecatedExtraMemory"
reported by SparseArrayValueMap::add() that is added to Heap::m_deprecatedExtraMemorySize:
arr = new Array;
Object.defineProperty(arr, 18, ({writable: true, configurable: true}));
for (var i = 0; i < 3; ++i) {
Array.prototype.push.apply(arr, ["", () => {}, {}]);
Array.prototype.sort.apply(arr, [() => {}, []]);
}
However, Heap::m_deprecatedExtraMemorySize is only 1 of 3 values that are added
up to form the result of Heap::extraMemorySize(). Heap::m_extraMemorySize and
Heap::m_arrayBuffers.size() are the other 2.
While Heap::m_arrayBuffers.size() is bounded by actual allocated memory, both
Heap::m_deprecatedExtraMemorySize and Heap::m_extraMemorySize are added to
without any bounds checks, and they are only reset to 0 at the start of a full
GC. As a result, if we have a long sequence of eden GCs with a lot of additions
to Heap::m_extraMemorySize and/or Heap::m_deprecatedExtraMemorySize, then these
values could theoretically overflow. Coupling this with the underflow from
SparseArrayValueMap::add(), the result for Heap::extraMemorySize() can easily
overflow. Note: Heap::extraMemorySize() is used to compute the value
currentHeapSize.
If multiple conditions line up just right, the above overflows can result in this
debug assertion failure during an eden GC:
ASSERT(currentHeapSize >= m_sizeAfterLastCollect);
Otherwise, the effects of the overflows will only result in the computed
currentHeapSize not being representative of actual memory usage, and therefore,
a full GC may be triggered earlier or later than is ideal.
This patch ensures that SparseArrayValueMap::add() cannot underflow
Heap::m_deprecatedExtraMemorySize. It also adds overflows checks in the
calculations of Heap::m_deprecatedExtraMemorySize, Heap::m_extraMemorySize, and
Heap::extraMemorySize() so that their values are saturated appropriately to
ensure that GC collections are triggered based on representative memory usage.
* heap/Heap.cpp:
(JSC::Heap::deprecatedReportExtraMemorySlowCase):
(JSC::Heap::extraMemorySize):
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::reportExtraMemoryVisited):
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::add):
2017-04-03 Filip Pizlo <fpizlo@apple.com>
Move the Liveness<> adapters from AirLiveness.h to AirLivenessAdapter.h.
Rubber stamped by Keith Miller.
This will make it easier to write other code that uses those adapters.
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/air/AirLiveness.h:
(JSC::B3::Air::LivenessAdapter::LivenessAdapter): Deleted.
(JSC::B3::Air::LivenessAdapter::blockSize): Deleted.
(JSC::B3::Air::LivenessAdapter::forEachUse): Deleted.
(JSC::B3::Air::LivenessAdapter::forEachDef): Deleted.
(JSC::B3::Air::TmpLivenessAdapter::TmpLivenessAdapter): Deleted.
(JSC::B3::Air::TmpLivenessAdapter::numIndices): Deleted.
(JSC::B3::Air::TmpLivenessAdapter::acceptsBank): Deleted.
(JSC::B3::Air::TmpLivenessAdapter::acceptsRole): Deleted.
(JSC::B3::Air::TmpLivenessAdapter::valueToIndex): Deleted.
(JSC::B3::Air::TmpLivenessAdapter::indexToValue): Deleted.
(JSC::B3::Air::StackSlotLivenessAdapter::StackSlotLivenessAdapter): Deleted.
(JSC::B3::Air::StackSlotLivenessAdapter::numIndices): Deleted.
(JSC::B3::Air::StackSlotLivenessAdapter::acceptsBank): Deleted.
(JSC::B3::Air::StackSlotLivenessAdapter::acceptsRole): Deleted.
(JSC::B3::Air::StackSlotLivenessAdapter::valueToIndex): Deleted.
(JSC::B3::Air::StackSlotLivenessAdapter::indexToValue): Deleted.
* b3/air/AirLivenessAdapter.h: Added.
(JSC::B3::Air::LivenessAdapter::LivenessAdapter):
(JSC::B3::Air::LivenessAdapter::blockSize):
(JSC::B3::Air::LivenessAdapter::forEachUse):
(JSC::B3::Air::LivenessAdapter::forEachDef):
(JSC::B3::Air::TmpLivenessAdapter::TmpLivenessAdapter):
(JSC::B3::Air::TmpLivenessAdapter::numIndices):
(JSC::B3::Air::TmpLivenessAdapter::acceptsBank):
(JSC::B3::Air::TmpLivenessAdapter::acceptsRole):
(JSC::B3::Air::TmpLivenessAdapter::valueToIndex):
(JSC::B3::Air::TmpLivenessAdapter::indexToValue):
(JSC::B3::Air::StackSlotLivenessAdapter::StackSlotLivenessAdapter):
(JSC::B3::Air::StackSlotLivenessAdapter::numIndices):
(JSC::B3::Air::StackSlotLivenessAdapter::acceptsBank):
(JSC::B3::Air::StackSlotLivenessAdapter::acceptsRole):
(JSC::B3::Air::StackSlotLivenessAdapter::valueToIndex):
(JSC::B3::Air::StackSlotLivenessAdapter::indexToValue):
2017-04-03 Filip Pizlo <fpizlo@apple.com>
WTF::Liveness should have an API that focuses on actions at instruction boundaries
https://bugs.webkit.org/show_bug.cgi?id=170407
Reviewed by Keith Miller.
Adopt changes to the WTF::Liveness<> API. Instead of having separate functions for the
early/late versions of uses and defs, we now have just a use/def API. Those
automatically take care of eary/late issues as needed.
This reduces the API surface between WTF::Liveness<> and its clients, which makes it
easier to implement some other optimizations I'm thinking about.
* b3/B3VariableLiveness.h:
(JSC::B3::VariableLivenessAdapter::forEachUse):
(JSC::B3::VariableLivenessAdapter::forEachDef):
(JSC::B3::VariableLivenessAdapter::forEachEarlyUse): Deleted.
(JSC::B3::VariableLivenessAdapter::forEachLateUse): Deleted.
(JSC::B3::VariableLivenessAdapter::forEachEarlyDef): Deleted.
(JSC::B3::VariableLivenessAdapter::forEachLateDef): Deleted.
* b3/air/AirLiveness.h:
(JSC::B3::Air::LivenessAdapter::blockSize):
(JSC::B3::Air::LivenessAdapter::forEachUse):
(JSC::B3::Air::LivenessAdapter::forEachDef):
(JSC::B3::Air::LivenessAdapter::forEachEarlyUse): Deleted.
(JSC::B3::Air::LivenessAdapter::forEachLateUse): Deleted.
(JSC::B3::Air::LivenessAdapter::forEachEarlyDef): Deleted.
(JSC::B3::Air::LivenessAdapter::forEachLateDef): Deleted.
2017-04-03 Filip Pizlo <fpizlo@apple.com>
Inst::forEachArg could compile to more compact code
https://bugs.webkit.org/show_bug.cgi?id=170406
Reviewed by Sam Weinig.
Prior to this change, Inst::forEachArg compiled to a ginormous ALWAYS_INLINE switch statement.
It had one case for each opcode, and then each of those cases would have a switch statement over
the number of operands. Then the cases of that switch statement would have a sequence of calls to
the passed lambda. This meant that every user of forEachArg would generate an insane amount of
code. It also meant that the inlining achieved nothing, since the lambda would surely then not
be inlined - and if it was, then the icache pressure due to code bloat would surely negate any
benefits.
This replaces that code with a loop over a compact look-up table. We use the opcode and number of
operands as keys into that look-up table. The table only takes about 20KB. It has one byte for
each argument in each overload of each opcode.
I can't measure any reproducible change in performance, but the JavaScriptCore framework binary
shrinks by 2.7 MB. This is a 15% reduction in JavaScriptCore binary size.
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3Width.h:
* b3/air/AirCustom.h:
(JSC::B3::Air::PatchCustom::forEachArg):
* b3/air/AirFormTable.h: Added.
(JSC::B3::Air::decodeFormRole):
(JSC::B3::Air::decodeFormBank):
(JSC::B3::Air::decodeFormWidth):
* b3/air/AirInst.h:
* b3/air/opcode_generator.rb:
2017-04-03 Keith Miller <keith_miller@apple.com>
WebAssembly: remove lastAllocatedMode from Memory
https://bugs.webkit.org/show_bug.cgi?id=170405
Reviewed by Mark Lam.
It's not used anymore so there isn't any point in keeping it around.
* wasm/WasmMemory.cpp:
(JSC::Wasm::Memory::createImpl):
(JSC::Wasm::Memory::lastAllocatedMode): Deleted.
* wasm/WasmMemory.h:
2017-04-03 Zan Dobersek <zdobersek@igalia.com>
[jsc] Add patchableJumpSize() for MIPS
https://bugs.webkit.org/show_bug.cgi?id=169716
Reviewed by Yusuke Suzuki.
* assembler/MIPSAssembler.h:
(JSC::MIPSAssembler::patchableJumpSize): Added.
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::patchableJumpSize): Added.
2017-04-03 Guillaume Emont <guijemont@igalia.com>
[jsc] implement MIPSAssembler::relinkJumpToNop()
https://bugs.webkit.org/show_bug.cgi?id=169720
Reviewed by Yusuke Suzuki.
* assembler/MIPSAssembler.h:
(JSC::MIPSAssembler::relinkJumpToNop): Added.
2017-04-02 Carlos Garcia Campos <cgarcia@igalia.com>
Share implementation of JSRunLoopTimer::timerDidFire
https://bugs.webkit.org/show_bug.cgi?id=170392
Reviewed by Michael Catanzaro.
The code is cross-platform but it's duplicated in CF and GLib implementations, it could be shared instead.
* runtime/JSRunLoopTimer.cpp:
(JSC::JSRunLoopTimer::timerDidFire): Move common implementation here.
(JSC::JSRunLoopTimer::setRunLoop): Use timerDidFireCallback.
(JSC::JSRunLoopTimer::timerDidFireCallback): Call JSRunLoopTimer::timerDidFire().
* runtime/JSRunLoopTimer.h:
2017-04-01 Oleksandr Skachkov <gskachkov@gmail.com>
Object with numerical keys with gaps gets filled by NaN values
https://bugs.webkit.org/show_bug.cgi?id=164412
Reviewed by Mark Lam.
This patch fixes issue when object have two properties
with name as number. The issue appears when during invoking
convertDoubleToArrayStorage, array is filled by pNaN and
method converting it to real NaN. This happeneds because a
pNaN in a Double array is a hole, and Double arrays cannot
have NaN values. To fix issue we need to check value and
clear it if it pNaN.
* runtime/JSObject.cpp:
(JSC::JSObject::convertDoubleToArrayStorage):
2017-03-31 Saam Barati <sbarati@apple.com>
WebAssembly: Make our calls out to JS PIC friendly
https://bugs.webkit.org/show_bug.cgi?id=170261
Reviewed by Keith Miller.
This patch removes a direct call from the module to the Wasm to JS stub.
Instead, we do an indirect call to the stub by loading the stub's executable
address off of the CodeBlock. This is to make the code we emit for comply with
requirements needed for PIC.
Adding this indirection is not ideal. Although this patch is neutral on
WasmBench, we really want to get back to a world where we have an IC
call infrastructure. This patch is obviously a regression on some
types of programs. I've filed this bug to make sure we implement a
PIC compliant Wasm to JS call IC:
https://bugs.webkit.org/show_bug.cgi?id=170375
* wasm/WasmB3IRGenerator.cpp:
* wasm/WasmFormat.h:
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::complete):
* wasm/js/JSWebAssemblyCodeBlock.cpp:
(JSC::JSWebAssemblyCodeBlock::initialize):
* wasm/js/JSWebAssemblyCodeBlock.h:
(JSC::JSWebAssemblyCodeBlock::create):
(JSC::JSWebAssemblyCodeBlock::offsetOfImportWasmToJSStub):
(JSC::JSWebAssemblyCodeBlock::offsetOfCallees):
(JSC::JSWebAssemblyCodeBlock::allocationSize):
(JSC::JSWebAssemblyCodeBlock::importWasmToJSStub):
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::addUnitializedCodeBlock):
* wasm/js/JSWebAssemblyInstance.h:
(JSC::JSWebAssemblyInstance::offsetOfCodeBlock):
2017-03-31 Keith Miller <keith_miller@apple.com>
WebAssembly: webAssemblyB3OptimizationLevel should use defaultB3OptLevel by default
https://bugs.webkit.org/show_bug.cgi?id=170378
Reviewed by Saam Barati.
* runtime/Options.h:
* wasm/WasmB3IRGenerator.h:
2017-03-31 Keith Miller <keith_miller@apple.com>
WebAssembly: Add compilation level option
https://bugs.webkit.org/show_bug.cgi?id=170374
Reviewed by Mark Lam.
This patch adds an option, webAssemblyB3OptimizationLevel, which
changes the optimization mode wasm passes to B3.
* runtime/Options.h:
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::compileFunctions):
2017-03-31 Saam Barati <sbarati@apple.com>
WebAssembly: Strip WasmParser and WasmFunctionParser from knowing about VM
https://bugs.webkit.org/show_bug.cgi?id=170312
Reviewed by Mark Lam.
This is another step towards PIC-ifying Wasm. This patch removes
the VM field that is no longer used.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::parseAndCompile):
* wasm/WasmB3IRGenerator.h:
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::FunctionParser):
* wasm/WasmModuleParser.h:
(JSC::Wasm::ModuleParser::ModuleParser):
* wasm/WasmParser.h:
(JSC::Wasm::Parser<SuccessType>::Parser):
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::parseAndValidateModule):
(JSC::Wasm::Plan::compileFunctions):
* wasm/WasmValidate.cpp:
(JSC::Wasm::validateFunction):
* wasm/WasmValidate.h:
2017-03-31 Saam Barati <sbarati@apple.com>
WebAssembly: Ref count Signature and SignatureInformation should not care about VM
https://bugs.webkit.org/show_bug.cgi?id=170316
Reviewed by Keith Miller.
This is yet again another step towards PIC-ifying Wasm.
Signature should be ref counted so we can tell when
no code is holding onto a Signature. This makes it easy
to free unused Signatures. Also, this patch rids SignatureInfo
of any VM knowledge. Now, there is just a single SignatureInfo that
lives in a process.
* runtime/VM.h:
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::createJSToWasmWrapper):
(JSC::Wasm::parseAndCompile):
* wasm/WasmB3IRGenerator.h:
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToJs):
* wasm/WasmCallingConvention.h:
(JSC::Wasm::CallingConvention::loadArguments):
* wasm/WasmFormat.h:
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::FunctionParser):
* wasm/WasmModuleParser.cpp:
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::parseAndValidateModule):
(JSC::Wasm::Plan::compileFunctions):
(JSC::Wasm::Plan::complete):
* wasm/WasmSignature.cpp:
(JSC::Wasm::Signature::hash):
(JSC::Wasm::Signature::tryCreate):
(JSC::Wasm::SignatureInformation::SignatureInformation):
(JSC::Wasm::SignatureInformation::singleton):
(JSC::Wasm::SignatureInformation::adopt):
(JSC::Wasm::SignatureInformation::get):
(JSC::Wasm::SignatureInformation::tryCleanup):
(JSC::Wasm::Signature::create): Deleted.
(JSC::Wasm::Signature::createInvalid): Deleted.
(JSC::Wasm::Signature::destroy): Deleted.
(JSC::Wasm::SignatureInformation::~SignatureInformation): Deleted.
* wasm/WasmSignature.h:
(JSC::Wasm::Signature::allocatedSize):
(JSC::Wasm::Signature::operator==):
* wasm/WasmValidate.cpp:
(JSC::Wasm::validateFunction):
* wasm/WasmValidate.h:
* wasm/js/JSWebAssemblyModule.cpp:
(JSC::JSWebAssemblyModule::destroy):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
* wasm/js/WebAssemblyFunction.h:
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
(JSC::WebAssemblyModuleRecord::evaluate):
* wasm/js/WebAssemblyWrapperFunction.cpp:
(JSC::WebAssemblyWrapperFunction::create):
* wasm/js/WebAssemblyWrapperFunction.h:
2017-03-31 Mark Lam <mark.lam@apple.com>
Array.prototype.splice() should not be using JSArray::tryCreateForInitializationPrivate().
https://bugs.webkit.org/show_bug.cgi?id=170303
<rdar://problem/31358281>
Reviewed by Filip Pizlo.
This is because it needs to call getProperty() later to get the values for
initializing the array. getProperty() can execute arbitrary code and potentially
trigger the GC. This is not allowed for clients of JSArray::tryCreateForInitializationPrivate().
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncSplice):
(JSC::copySplicedArrayElements): Deleted.
2017-03-31 Oleksandr Skachkov <gskachkov@gmail.com>
String.prototype.replace incorrectly applies "special replacement parameters" when passed a function
https://bugs.webkit.org/show_bug.cgi?id=170151
Reviewed by Saam Barati.
This patch fixes issue for String.prototype.replace when passed a function
with special symbols "$$". It happeneds because substituteBackreferences applies
unconditionally, but according to the spec it should be applied only for text
21.1.3.16.8 https://tc39.github.io/ecma262/#sec-string.prototype.replace
* runtime/StringPrototype.cpp:
(JSC::replaceUsingStringSearch):
2017-03-30 Saam Barati <sbarati@apple.com>
WebAssembly: When Wasm calls to C, it should use Wasm::Context* instead of ExecState* to get VM
https://bugs.webkit.org/show_bug.cgi?id=170185
Reviewed by Michael Saboff.
This is one more step in the direction of PIC-ified Wasm.
When we lift WasmCallee above VM, we will no longer be
able to get VM from ExecState*. This patch ensures that
we don't do that from within the Wasm runtime. Instead,
we use the Wasm::Context* to get the VM.
This patch also adds a new class, Wasm::Thunks. There
is a single Wasm::Thunks that lives in the process. It
is responsible for generating a thunk that Wasm relies on.
The only such thunk right now is the exception throwing
thunk.
This patch also rids WasmFaultSignalHandler from any knowledge
of VM. Previously, it relied on VM to get the exception handling
thunk.
The only part of the Wasm runtime that will be allowed
to get VM& from ExecState will be WasmBinding. In the
future, we plan to keep the calls out to JS to keep
a JSCell as the callee.
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareOSREntry):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* interpreter/Interpreter.cpp:
(JSC::UnwindFunctor::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
(JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBufferImpl):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
* jit/ThunkGenerators.cpp:
(JSC::throwExceptionFromWasmThunkGenerator): Deleted.
* jit/ThunkGenerators.h:
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::getAllCalleeSaveRegisterOffsets):
* runtime/VM.h:
(JSC::VM::topVMEntryFrameOffset):
(JSC::VM::getAllCalleeSaveRegisterOffsets): Deleted.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::emitExceptionCheck):
* wasm/WasmFaultSignalHandler.cpp:
(JSC::Wasm::trapHandler):
* wasm/WasmMemory.cpp:
(JSC::Wasm::tryGetFastMemory):
* wasm/WasmThunks.cpp: Added.
(JSC::Wasm::throwExceptionFromWasmThunkGenerator):
(JSC::Wasm::Thunks::initialize):
(JSC::Wasm::Thunks::singleton):
(JSC::Wasm::Thunks::stub):
(JSC::Wasm::Thunks::existingStub):
* wasm/WasmThunks.h: Added.
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
* wasm/js/JSWebAssemblyInstance.h:
(JSC::JSWebAssemblyInstance::offsetOfVM):
* wasm/js/JSWebAssemblyMemory.cpp:
(JSC::JSWebAssemblyMemory::grow):
* wasm/js/JSWebAssemblyMemory.h:
* wasm/js/WebAssemblyMemoryPrototype.cpp:
(JSC::webAssemblyMemoryProtoFuncGrow):
2017-03-30 Mark Lam <mark.lam@apple.com>
IntlObject should not be using JSArray::initializeIndex().
https://bugs.webkit.org/show_bug.cgi?id=170302
<rdar://problem/31356918>
Reviewed by Saam Barati.
JSArray::initializeIndex() is only meant to be used with arrays created using
JSArray::tryCreateForInitializationPrivate() under very constrained conditions.
* runtime/IntlObject.cpp:
(JSC::canonicalizeLocaleList):
(JSC::intlObjectFuncGetCanonicalLocales):
2017-03-30 Filip Pizlo <fpizlo@apple.com>
Air should support linear scan for optLevel<2
https://bugs.webkit.org/show_bug.cgi?id=170161
Reviewed by Saam Barati.
This changes the default opt level of B3 to 2. It makes the other opt levels useful by adding a
new register allocator. This new linear scan allocator will produce significantly worse code.
But it will produce that code a lot faster than IRC or Briggs.
The opt levels are:
0: no optimizations, linear scan
1: some optimizations, linear scan
2: full optimizations, graph coloring (IRC or Briggs based on CPU)
What we used to call optLevel=1 is not called optLevel=2, or better yet,
optLevel=B3::defaultOptLevel(). We no longer have anything like the old optLevel=0 (which did no
optimizations but ran graph coloring).
allocateRegistersByLinearScan() faithfully implements Massimiliano Poletto and Vivek Sarkar's
famous algorithm. It uses the variant that handles clobbered registers by avoiding assigning
ranges to those registers if the range overlaps a clobber. It's engineered to allocate registers
very quickly and generate inefficient code without falling off a cliff.
The new optLevel=1 speeds up B3 by a factor of 2, and results in a 80% throughput regression.
Linear scan runs 4.7x faster than graph coloring on average.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3BasicBlockUtils.h:
(JSC::B3::blocksInPreOrder):
(JSC::B3::blocksInPostOrder):
* b3/B3BlockWorklist.h:
* b3/B3CFG.h:
(JSC::B3::CFG::newMap):
* b3/B3Common.h:
(JSC::B3::defaultOptLevel):
* b3/B3Compile.h:
* b3/B3DuplicateTails.cpp:
* b3/B3EliminateCommonSubexpressions.cpp:
* b3/B3FixSSA.cpp:
(JSC::B3::demoteValues):
(JSC::B3::fixSSA):
* b3/B3FixSSA.h:
* b3/B3Generate.cpp:
(JSC::B3::prepareForGeneration):
(JSC::B3::generateToAir):
* b3/B3Generate.h:
* b3/B3HeapRange.cpp: Removed.
* b3/B3HeapRange.h:
(JSC::B3::HeapRange::HeapRange): Deleted.
(JSC::B3::HeapRange::top): Deleted.
(JSC::B3::HeapRange::operator==): Deleted.
(JSC::B3::HeapRange::operator!=): Deleted.
(JSC::B3::HeapRange::operator|): Deleted.
(JSC::B3::HeapRange::operator bool): Deleted.
(JSC::B3::HeapRange::begin): Deleted.
(JSC::B3::HeapRange::end): Deleted.
(JSC::B3::HeapRange::overlaps): Deleted.
* b3/B3LowerToAir.cpp:
* b3/B3MoveConstants.cpp:
* b3/B3PhiChildren.h:
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::dump):
(JSC::B3::Procedure::deleteOrphans):
(JSC::B3::Procedure::setBlockOrderImpl):
* b3/B3ReduceDoubleToFloat.cpp:
* b3/B3ReduceStrength.cpp:
* b3/B3SSACalculator.h:
* b3/B3UseCounts.h:
* b3/air/AirAllocateRegistersByGraphColoring.cpp:
* b3/air/AirAllocateRegistersByLinearScan.cpp: Added.
(JSC::B3::Air::allocateRegistersByLinearScan):
* b3/air/AirAllocateRegistersByLinearScan.h: Added.
* b3/air/AirAllocateStack.cpp:
(JSC::B3::Air::allocateStack):
* b3/air/AirArg.cpp:
(WTF::printInternal):
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::activeAt):
(JSC::B3::Air::Arg::timing):
(JSC::B3::Air::Arg::forEachPhase):
* b3/air/AirBasicBlock.h:
* b3/air/AirBlockWorklist.h:
* b3/air/AirCFG.h:
(JSC::B3::Air::CFG::newMap):
* b3/air/AirEliminateDeadCode.cpp:
(JSC::B3::Air::eliminateDeadCode):
* b3/air/AirFixObviousSpills.cpp:
* b3/air/AirFixPartialRegisterStalls.cpp:
(JSC::B3::Air::fixPartialRegisterStalls):
* b3/air/AirFixSpillsAfterTerminals.cpp: Added.
(JSC::B3::Air::fixSpillsAfterTerminals):
* b3/air/AirFixSpillsAfterTerminals.h: Added.
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::prepareForGeneration):
(JSC::B3::Air::generate):
* b3/air/AirGenerate.h:
* b3/air/AirGenerationContext.h:
* b3/air/AirInsertionSet.h:
* b3/air/AirInst.cpp:
(JSC::B3::Air::Inst::needsPadding):
* b3/air/AirLowerAfterRegAlloc.cpp:
(JSC::B3::Air::lowerAfterRegAlloc):
* b3/air/AirLowerEntrySwitch.cpp:
(JSC::B3::Air::lowerEntrySwitch):
* b3/air/AirOpcode.opcodes:
* b3/air/AirPhaseInsertionSet.cpp: Added.
(JSC::B3::Air::PhaseInsertionSet::execute):
* b3/air/AirPhaseInsertionSet.h: Added.
(JSC::B3::Air::PhaseInsertion::PhaseInsertion):
(JSC::B3::Air::PhaseInsertion::phase):
(JSC::B3::Air::PhaseInsertion::operator<):
(JSC::B3::Air::PhaseInsertionSet::PhaseInsertionSet):
(JSC::B3::Air::PhaseInsertionSet::appendInsertion):
(JSC::B3::Air::PhaseInsertionSet::insertInst):
(JSC::B3::Air::PhaseInsertionSet::insert):
* b3/air/AirRegLiveness.h:
(JSC::B3::Air::RegLiveness::LocalCalc::LocalCalc):
* b3/air/AirSpillEverything.cpp:
(JSC::B3::Air::spillEverything):
* b3/air/AirTmp.cpp:
* b3/air/AirTmp.h:
(JSC::B3::Air::Tmp::tmpForIndex):
* b3/air/AirTmpInlines.h:
(JSC::B3::Air::Tmp::Indexed::Indexed):
(JSC::B3::Air::Tmp::Indexed::index):
(JSC::B3::Air::Tmp::AbsolutelyIndexed::AbsolutelyIndexed):
(JSC::B3::Air::Tmp::AbsolutelyIndexed::index):
(JSC::B3::Air::Tmp::indexed):
(JSC::B3::Air::Tmp::absolutelyIndexed):
(JSC::B3::Air::Tmp::tmpForAbsoluteIndex):
* b3/testb3.cpp:
(JSC::B3::compile):
(JSC::B3::testMulLoadTwice):
* jit/RegisterSet.h:
(JSC::RegisterSet::add):
(JSC::RegisterSet::remove):
* runtime/Options.h:
* wasm/WasmB3IRGenerator.h:
2017-03-30 Youenn Fablet <youenn@apple.com>
Clean up RTCDataChannel
https://bugs.webkit.org/show_bug.cgi?id=169732
Reviewed by Chris Dumez.
* runtime/CommonIdentifiers.h: Adding RTCDataChannelEvent.
2017-03-30 Saam Barati <sbarati@apple.com>
WebAssembly: pass Wasm::Context* to vmEntryToWasm when not using fast TLS
https://bugs.webkit.org/show_bug.cgi?id=170182
Reviewed by Mark Lam.
This is one more step in the direction of PIC-ified Wasm.
I'm removing assumptions that a wasm callee is a cell. We used to use
the callee to get the WasmContext off the callee's VM. Instead,
this patch makes it so that we pass in the context as a parameter
to the JS entrypoint.
* heap/MarkedBlock.h:
(JSC::MarkedBlock::offsetOfVM): Deleted.
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::loadWasmContext):
(JSC::AssemblyHelpers::storeWasmContext):
(JSC::AssemblyHelpers::loadWasmContextNeedsMacroScratchRegister):
(JSC::AssemblyHelpers::storeWasmContextNeedsMacroScratchRegister):
* jsc.cpp:
(functionTestWasmModuleFunctions):
* runtime/VM.h:
(JSC::VM::wasmContextOffset): Deleted.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::materializeWasmContext):
(JSC::Wasm::B3IRGenerator::restoreWasmContext):
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::createJSToWasmWrapper):
* wasm/WasmContext.cpp:
(JSC::Wasm::loadContext):
(JSC::Wasm::storeContext):
(JSC::loadWasmContext): Deleted.
(JSC::storeWasmContext): Deleted.
* wasm/WasmContext.h:
(JSC::Wasm::useFastTLS):
(JSC::Wasm::useFastTLSForContext):
* wasm/WasmMemoryInformation.cpp:
(JSC::Wasm::PinnedRegisterInfo::get):
* wasm/WasmMemoryInformation.h:
(JSC::Wasm::useFastTLS): Deleted.
(JSC::Wasm::useFastTLSForWasmContext): Deleted.
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
2017-03-30 JF Bastien <jfbastien@apple.com>
WebAssembly: fix misc JS API implementation inconsistencies
https://bugs.webkit.org/show_bug.cgi?id=170187
Reviewed by Keith Miller.
Auto-generate lookup tables.
Methods should be on prototype.
Exception returns should be idiomatic.
* wasm/JSWebAssembly.cpp: validate / compile / instantiate should
be on the prototype
(JSC::JSWebAssembly::create):
(JSC::JSWebAssembly::finishCreation):
(JSC::reject): Deleted.
(JSC::webAssemblyCompileFunc): Deleted.
(JSC::resolve): Deleted.
(JSC::instantiate): Deleted.
(JSC::compileAndInstantiate): Deleted.
(JSC::webAssemblyInstantiateFunc): Deleted.
(JSC::webAssemblyValidateFunc): Deleted.
* wasm/JSWebAssembly.h:
* wasm/js/WebAssemblyMemoryPrototype.cpp: move from JSWebAssembly.cpp
(JSC::webAssemblyMemoryProtoFuncBuffer):
(JSC::WebAssemblyMemoryPrototype::create):
(JSC::WebAssemblyMemoryPrototype::finishCreation):
* wasm/js/WebAssemblyMemoryPrototype.h:
* wasm/js/WebAssemblyPrototype.cpp:
(JSC::reject):
(JSC::webAssemblyCompileFunc):
(JSC::resolve):
(JSC::instantiate):
(JSC::compileAndInstantiate):
(JSC::webAssemblyInstantiateFunc):
(JSC::webAssemblyValidateFunc):
(JSC::webAssemblyFunctionValidate): Deleted.
(JSC::webAssemblyFunctionCompile): Deleted.
* wasm/js/WebAssemblyTablePrototype.cpp:
(JSC::webAssemblyTableProtoFuncGrow):
(JSC::webAssemblyTableProtoFuncGet):
(JSC::webAssemblyTableProtoFuncSet):
(JSC::WebAssemblyTablePrototype::create):
(JSC::WebAssemblyTablePrototype::finishCreation):
* wasm/js/WebAssemblyTablePrototype.h:
2017-03-29 Keith Miller <keith_miller@apple.com>
Unreviewed, fix the build, again. Hopefully for the last time, again!
* runtime/Options.cpp:
2017-03-29 Keith Miller <keith_miller@apple.com>
Unreviewed, fix the build, again. Hopefully for the last time!
* runtime/Options.cpp:
(JSC::parse):
2017-03-29 Keith Miller <keith_miller@apple.com>
Unreviewed, windows build fix.
* runtime/Options.cpp:
(JSC::parse):
2017-03-29 Keith Miller <keith_miller@apple.com>
WebAssembly: B3IRGenerator should pool constants
https://bugs.webkit.org/show_bug.cgi?id=170266
Reviewed by Filip Pizlo.
This patch adds a HashMap to B3IRGenerator that contains all the constants used in a function.
B3IRGenerator then uses an InsertionSet to add all those constants to the root BB. This doesn't
appear to be a compile time improvement but it could be valuable in the future.
* b3/B3Opcode.h:
(JSC::B3::opcodeForConstant):
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::addConstant):
* b3/B3Procedure.h:
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::B3IRGenerator::constant):
(JSC::Wasm::B3IRGenerator::insertConstants):
(JSC::Wasm::B3IRGenerator::addConstant):
(JSC::Wasm::B3IRGenerator::dump):
(JSC::Wasm::parseAndCompile):
(JSC::Wasm::B3IRGenerator::emitChecksForModOrDiv):
(JSC::Wasm::B3IRGenerator::zeroForType): Deleted.
* wasm/generateWasmB3IRGeneratorInlinesHeader.py:
(generateConstCode):
2017-03-29 Saam Barati <sbarati@apple.com>
LinkBuffer and ExecutableAllocator shouldn't have anything to do with VM
https://bugs.webkit.org/show_bug.cgi?id=170210
Reviewed by Mark Lam.
This is one more step in the direction of PIC-ified Wasm.
LinkBuffer and ExecutableAllocator have no business knowing about VM.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::allocate):
* assembler/LinkBuffer.h:
(JSC::LinkBuffer::LinkBuffer):
(JSC::LinkBuffer::vm): Deleted.
* b3/B3Compile.cpp:
(JSC::B3::compile):
* b3/B3Compile.h:
* b3/air/testair.cpp:
* b3/testb3.cpp:
(JSC::B3::compileProc):
(JSC::B3::compileAndRun):
(JSC::B3::testLoadAcq42):
(JSC::B3::testAddArgZeroImmZDef):
(JSC::B3::testAddLoadTwice):
(JSC::B3::testMulLoadTwice):
(JSC::B3::testMulAddArgsLeft):
(JSC::B3::testMulAddArgsRight):
(JSC::B3::testMulAddArgsLeft32):
(JSC::B3::testMulAddArgsRight32):
(JSC::B3::testMulSubArgsLeft):
(JSC::B3::testMulSubArgsRight):
(JSC::B3::testMulSubArgsLeft32):
(JSC::B3::testMulSubArgsRight32):
(JSC::B3::testMulNegArgs):
(JSC::B3::testMulNegArgs32):
(JSC::B3::testCompareFloatToDoubleThroughPhi):
(JSC::B3::testDoubleToFloatThroughPhi):
(JSC::B3::testReduceFloatToDoubleValidates):
(JSC::B3::testDoubleProducerPhiToFloatConversion):
(JSC::B3::testDoubleProducerPhiToFloatConversionWithDoubleConsumer):
(JSC::B3::testDoubleProducerPhiWithNonFloatConst):
(JSC::B3::testIToD64Arg):
(JSC::B3::testIToF64Arg):
(JSC::B3::testIToD32Arg):
(JSC::B3::testIToF32Arg):
(JSC::B3::testIToD64Mem):
(JSC::B3::testIToF64Mem):
(JSC::B3::testIToD32Mem):
(JSC::B3::testIToF32Mem):
(JSC::B3::testIToDReducedToIToF64Arg):
(JSC::B3::testIToDReducedToIToF32Arg):
(JSC::B3::testStoreRelAddLoadAcq32):
(JSC::B3::testStoreRelAddLoadAcq8):
(JSC::B3::testStoreRelAddFenceLoadAcq8):
(JSC::B3::testStoreRelAddLoadAcq16):
(JSC::B3::testStoreRelAddLoadAcq64):
(JSC::B3::testBranch):
(JSC::B3::testBranchPtr):
(JSC::B3::testDiamond):
(JSC::B3::testBranchNotEqual):
(JSC::B3::testBranchNotEqualCommute):
(JSC::B3::testBranchNotEqualNotEqual):
(JSC::B3::testBranchEqual):
(JSC::B3::testBranchEqualEqual):
(JSC::B3::testBranchEqualCommute):
(JSC::B3::testBranchEqualEqual1):
(JSC::B3::testBranchLoadPtr):
(JSC::B3::testBranchLoad32):
(JSC::B3::testBranchLoad8S):
(JSC::B3::testBranchLoad8Z):
(JSC::B3::testBranchLoad16S):
(JSC::B3::testBranchLoad16Z):
(JSC::B3::testBranch8WithLoad8ZIndex):
(JSC::B3::testComplex):
(JSC::B3::testSimpleCheck):
(JSC::B3::testCheckFalse):
(JSC::B3::testCheckTrue):
(JSC::B3::testCheckLessThan):
(JSC::B3::testCheckMegaCombo):
(JSC::B3::testCheckTrickyMegaCombo):
(JSC::B3::testCheckTwoMegaCombos):
(JSC::B3::testCheckTwoNonRedundantMegaCombos):
(JSC::B3::testCheckAddImm):
(JSC::B3::testCheckAddImmCommute):
(JSC::B3::testCheckAddImmSomeRegister):
(JSC::B3::testCheckAdd):
(JSC::B3::testCheckAdd64):
(JSC::B3::testCheckAddFold):
(JSC::B3::testCheckAddFoldFail):
(JSC::B3::testCheckAddSelfOverflow64):
(JSC::B3::testCheckAddSelfOverflow32):
(JSC::B3::testCheckSubImm):
(JSC::B3::testCheckSubBadImm):
(JSC::B3::testCheckSub):
(JSC::B3::testCheckSub64):
(JSC::B3::testCheckSubFold):
(JSC::B3::testCheckSubFoldFail):
(JSC::B3::testCheckNeg):
(JSC::B3::testCheckNeg64):
(JSC::B3::testCheckMul):
(JSC::B3::testCheckMulMemory):
(JSC::B3::testCheckMul2):
(JSC::B3::testCheckMul64):
(JSC::B3::testCheckMulFold):
(JSC::B3::testCheckMulFoldFail):
(JSC::B3::testCheckMul64SShr):
(JSC::B3::testSwitch):
(JSC::B3::testSwitchChillDiv):
(JSC::B3::testSwitchTargettingSameBlock):
(JSC::B3::testSwitchTargettingSameBlockFoldPathConstant):
(JSC::B3::testBasicSelect):
(JSC::B3::testSelectTest):
(JSC::B3::testSelectCompareDouble):
(JSC::B3::testSelectDouble):
(JSC::B3::testSelectDoubleTest):
(JSC::B3::testSelectDoubleCompareDouble):
(JSC::B3::testSelectFloatCompareFloat):
(JSC::B3::testSelectFold):
(JSC::B3::testSelectInvert):
(JSC::B3::testCheckSelect):
(JSC::B3::testCheckSelectCheckSelect):
(JSC::B3::testCheckSelectAndCSE):
(JSC::B3::testTrivialInfiniteLoop):
(JSC::B3::testFoldPathEqual):
(JSC::B3::testLShiftSelf32):
(JSC::B3::testRShiftSelf32):
(JSC::B3::testURShiftSelf32):
(JSC::B3::testLShiftSelf64):
(JSC::B3::testRShiftSelf64):
(JSC::B3::testURShiftSelf64):
(JSC::B3::testPatchpointDoubleRegs):
(JSC::B3::testSpillDefSmallerThanUse):
(JSC::B3::testSpillUseLargerThanDef):
(JSC::B3::testLateRegister):
(JSC::B3::testInterpreter):
(JSC::B3::testEntrySwitchSimple):
(JSC::B3::testEntrySwitchNoEntrySwitch):
(JSC::B3::testEntrySwitchWithCommonPaths):
(JSC::B3::testEntrySwitchWithCommonPathsAndNonTrivialEntrypoint):
(JSC::B3::testEntrySwitchLoop):
(JSC::B3::testSomeEarlyRegister):
(JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled):
(JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2):
(JSC::B3::testPatchpointTerminalReturnValue):
(JSC::B3::testMemoryFence):
(JSC::B3::testStoreFence):
(JSC::B3::testLoadFence):
(JSC::B3::testPCOriginMapDoesntInsertNops):
(JSC::B3::testPinRegisters):
(JSC::B3::testX86LeaAddAddShlLeft):
(JSC::B3::testX86LeaAddAddShlRight):
(JSC::B3::testX86LeaAddAdd):
(JSC::B3::testX86LeaAddShlRight):
(JSC::B3::testX86LeaAddShlLeftScale1):
(JSC::B3::testX86LeaAddShlLeftScale2):
(JSC::B3::testX86LeaAddShlLeftScale4):
(JSC::B3::testX86LeaAddShlLeftScale8):
(JSC::B3::testAddShl32):
(JSC::B3::testAddShl64):
(JSC::B3::testAddShl65):
(JSC::B3::testLoadBaseIndexShift2):
(JSC::B3::testLoadBaseIndexShift32):
(JSC::B3::testOptimizeMaterialization):
(JSC::B3::testAtomicWeakCAS):
(JSC::B3::testAtomicStrongCAS):
(JSC::B3::testAtomicXchg):
(JSC::B3::testDepend32):
(JSC::B3::testDepend64):
(JSC::B3::testWasmBoundsCheck):
(JSC::B3::testWasmAddress):
(JSC::B3::run):
(JSC::B3::compile): Deleted.
* bytecode/PolymorphicAccess.cpp:
(JSC::PolymorphicAccess::regenerate):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
* dfg/DFGLazyJSValue.cpp:
(JSC::DFG::LazyJSValue::emit):
* dfg/DFGOSRExitCompiler.cpp:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* dfg/DFGThunks.cpp:
(JSC::DFG::osrExitGenerationThunkGenerator):
(JSC::DFG::osrEntryThunkGenerator):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLLazySlowPath.cpp:
(JSC::FTL::LazySlowPath::generate):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
(JSC::FTL::DFG::LowerDFGToB3::compileCallEval):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* ftl/FTLOSRExitHandle.cpp:
(JSC::FTL::OSRExitHandle::emitExitThunk):
* ftl/FTLSlowPathCall.cpp:
(JSC::FTL::SlowPathCallContext::makeCall):
* ftl/FTLSlowPathCall.h:
(JSC::FTL::callOperation):
* ftl/FTLState.h:
* ftl/FTLThunks.cpp:
(JSC::FTL::genericGenerationThunkGenerator):
(JSC::FTL::slowPathCallThunkGenerator):
* ftl/FTLThunks.h:
(JSC::FTL::generateIfNecessary):
(JSC::FTL::Thunks::getSlowPathCallThunk):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitDumbVirtualCall):
* jit/AssemblyHelpers.h:
* jit/ExecutableAllocator.cpp:
(JSC::ExecutableAllocator::initializeAllocator):
(JSC::ExecutableAllocator::singleton):
(JSC::ExecutableAllocator::ExecutableAllocator):
(JSC::ExecutableAllocator::allocate):
* jit/ExecutableAllocator.h:
* jit/JIT.cpp:
(JSC::JIT::compileWithoutLinking):
* jit/JITCall.cpp:
(JSC::JIT::compileCallEvalSlowCase):
* jit/JITMathIC.h:
(JSC::JITMathIC::generateOutOfLine):
* jit/JITOpcodes.cpp:
(JSC::JIT::privateCompileHasIndexedProperty):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::privateCompileHasIndexedProperty):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::stringGetByValStubGenerator):
(JSC::JIT::privateCompileGetByVal):
(JSC::JIT::privateCompileGetByValWithCachedId):
(JSC::JIT::privateCompilePutByVal):
(JSC::JIT::privateCompilePutByValWithCachedId):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::stringGetByValStubGenerator):
* jit/JITStubRoutine.h:
* jit/Repatch.cpp:
(JSC::ftlThunkAwareRepatchCall):
(JSC::linkPolymorphicCall):
* jit/SpecializedThunkJIT.h:
(JSC::SpecializedThunkJIT::finalize):
* jit/ThunkGenerators.cpp:
(JSC::throwExceptionFromCallSlowPathGenerator):
(JSC::linkCallThunkGenerator):
(JSC::linkPolymorphicCallThunkGenerator):
(JSC::virtualThunkFor):
(JSC::nativeForGenerator):
(JSC::arityFixupGenerator):
(JSC::unreachableGenerator):
(JSC::boundThisNoArgsFunctionCallGenerator):
(JSC::throwExceptionFromWasmThunkGenerator):
* llint/LLIntThunks.cpp:
(JSC::LLInt::generateThunkWithJumpTo):
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::takeSample):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
* runtime/VMTraps.cpp:
(JSC::VMTraps::tryInstallTrapBreakpoints):
* tools/VMInspector.cpp:
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToJs):
(JSC::Wasm::wasmToWasm):
(JSC::Wasm::exitStubGenerator):
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::complete):
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::compile):
(JSC::Yarr::jitCompile):
2017-03-29 Keith Miller <keith_miller@apple.com>
WebAssembly: Worklist should periodically check in to see if there are higher priority jobs to do.
https://bugs.webkit.org/show_bug.cgi?id=170204
Reviewed by Saam Barati.
This patch makes it so that Wasm::Plan's compileFunctions method can return periodically
to its caller. The main use for this is if a user asynchronously compiles a wasm module
then later synchronously compiles another module. In this case we want to be able to pause
compilation of other worklists.
This patch also adds support for size_t Options.
* runtime/Options.cpp:
(JSC::parse):
(JSC::Option::dump):
(JSC::Option::operator==):
* runtime/Options.h:
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::moveToState):
(JSC::Wasm::Plan::ThreadCountHolder::~ThreadCountHolder):
(JSC::Wasm::Plan::compileFunctions):
* wasm/WasmPlan.h:
* wasm/WasmWorklist.cpp:
2017-03-29 Mark Lam <mark.lam@apple.com>
Remove obsolete references to HeapTimer in JavaScriptCore.order.
https://bugs.webkit.org/show_bug.cgi?id=170252
Reviewed by Saam Barati.
The HeapTimer was renamed to JSRunLoopTimer back in r214504. These HeapTimer
entries are now no longer meaningful.
* JavaScriptCore.order:
2017-03-29 JF Bastien <jfbastien@apple.com>
WebAssembly: add shell-only Memory mode helper
https://bugs.webkit.org/show_bug.cgi?id=170227
Reviewed by Mark Lam.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionWebAssemblyMemoryMode):
* wasm/WasmMemory.h:
* wasm/js/JSWebAssemblyInstance.h:
* wasm/js/JSWebAssemblyMemory.h:
2017-03-29 Keith Miller <keith_miller@apple.com>
WebAssembly: pack OpcodeOrigin to fit in a pointer
https://bugs.webkit.org/show_bug.cgi?id=170244
Reviewed by Michael Saboff.
This patch makes it so we don't have to have allocate the OpcodeOrigin and can just
pack all the data into the pointer B3::Origin already has.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::parseAndCompile):
* wasm/WasmOpcodeOrigin.cpp:
(JSC::Wasm::OpcodeOrigin::dump):
* wasm/WasmOpcodeOrigin.h:
(JSC::Wasm::OpcodeOrigin::OpcodeOrigin):
(JSC::Wasm::OpcodeOrigin::opcode):
(JSC::Wasm::OpcodeOrigin::location):
2017-03-29 JF Bastien <jfbastien@apple.com>
WebAssembly: NFC s/goto/lambda/g
https://bugs.webkit.org/show_bug.cgi?id=170242
Reviewed by Mark Lam.
Lambdas are more in-style than the goto I just used.
* wasm/WasmMemory.cpp:
(JSC::Wasm::tryGetFastMemory):
2017-03-28 Saam Barati <sbarati@apple.com>
AssemblyHelpers should not have a VM field
https://bugs.webkit.org/show_bug.cgi?id=170207
Reviewed by Yusuke Suzuki.
APIs that need VM should take one as a parameter. When doing position
independent code for Wasm, we can't tie code generation to a VM.
* b3/B3Compile.cpp:
(JSC::B3::compile):
* b3/air/testair.cpp:
* b3/testb3.cpp:
(JSC::B3::testEntrySwitchSimple):
(JSC::B3::testEntrySwitchNoEntrySwitch):
(JSC::B3::testEntrySwitchWithCommonPaths):
(JSC::B3::testEntrySwitchWithCommonPathsAndNonTrivialEntrypoint):
(JSC::B3::testEntrySwitchLoop):
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateWithGuard):
(JSC::AccessCase::generateImpl):
* bytecode/DOMJITAccessCasePatchpointParams.cpp:
(JSC::SlowPathCallGeneratorWithArguments::generateImpl):
* bytecode/InlineAccess.cpp:
(JSC::InlineAccess::dumpCacheSizesAndCrash):
(JSC::InlineAccess::generateSelfPropertyAccess):
(JSC::InlineAccess::generateSelfPropertyReplace):
(JSC::InlineAccess::generateArrayLength):
(JSC::InlineAccess::rewireStubAsJump):
* bytecode/InlineAccess.h:
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessGenerationState::emitExplicitExceptionHandler):
(JSC::PolymorphicAccess::regenerate):
* bytecode/PolymorphicAccess.h:
(JSC::AccessGenerationState::AccessGenerationState):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::JITCompiler):
(JSC::DFG::JITCompiler::compileExceptionHandlers):
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
(JSC::DFG::JITCompiler::exceptionCheck):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::exceptionCheckWithCallFrameRollback):
(JSC::DFG::JITCompiler::fastExceptionCheck):
(JSC::DFG::JITCompiler::vm):
* dfg/DFGOSRExitCompiler.cpp:
* dfg/DFGOSRExitCompiler.h:
* dfg/DFGOSRExitCompiler32_64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompiler64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::adjustAndJumpToTarget):
* dfg/DFGOSRExitCompilerCommon.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
(JSC::DFG::SpeculativeJIT::checkArray):
(JSC::DFG::SpeculativeJIT::compileCurrentBlock):
(JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
(JSC::DFG::SpeculativeJIT::compileMakeRope):
(JSC::DFG::SpeculativeJIT::compileGetGlobalObject):
(JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
(JSC::DFG::SpeculativeJIT::compileCreateActivation):
(JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
(JSC::DFG::SpeculativeJIT::compileSpread):
(JSC::DFG::SpeculativeJIT::compileArraySlice):
(JSC::DFG::SpeculativeJIT::compileNukeStructureAndSetButterfly):
(JSC::DFG::SpeculativeJIT::compileNewStringObject):
(JSC::DFG::SpeculativeJIT::compileNewTypedArray):
(JSC::DFG::SpeculativeJIT::compileStoreBarrier):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::emitAllocateJSObjectWithKnownSize):
(JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
(JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject):
(JSC::DFG::SpeculativeJIT::emitAllocateDestructibleObject):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
(JSC::DFG::SpeculativeJIT::compileLogicalNot):
(JSC::DFG::SpeculativeJIT::emitBranch):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined):
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNullOrUndefined):
(JSC::DFG::SpeculativeJIT::emitCall):
(JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
(JSC::DFG::SpeculativeJIT::compileLogicalNot):
(JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
(JSC::DFG::SpeculativeJIT::emitBranch):
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
* dfg/DFGThunks.cpp:
(JSC::DFG::osrEntryThunkGenerator):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLJITFinalizer.h:
* ftl/FTLLazySlowPath.cpp:
(JSC::FTL::LazySlowPath::generate):
* ftl/FTLLazySlowPathCall.h:
(JSC::FTL::createLazyCallGenerator):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::lower):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation):
(JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
(JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
(JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
(JSC::FTL::DFG::LowerDFGToB3::compileNotifyWrite):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
(JSC::FTL::DFG::LowerDFGToB3::compileCallEval):
(JSC::FTL::DFG::LowerDFGToB3::compileIsObjectOrNull):
(JSC::FTL::DFG::LowerDFGToB3::compileIsFunction):
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckTraps):
(JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl):
(JSC::FTL::DFG::LowerDFGToB3::allocateObject):
(JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
(JSC::FTL::DFG::LowerDFGToB3::buildTypeOf):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* ftl/FTLSlowPathCall.h:
(JSC::FTL::callOperation):
* ftl/FTLState.h:
(JSC::FTL::State::vm):
* ftl/FTLThunks.cpp:
(JSC::FTL::genericGenerationThunkGenerator):
(JSC::FTL::slowPathCallThunkGenerator):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::jitReleaseAssertNoException):
(JSC::AssemblyHelpers::callExceptionFuzz):
(JSC::AssemblyHelpers::emitJumpIfException):
(JSC::AssemblyHelpers::emitExceptionCheck):
(JSC::AssemblyHelpers::emitNonPatchableExceptionCheck):
(JSC::AssemblyHelpers::emitLoadStructure):
(JSC::AssemblyHelpers::emitRandomThunk):
(JSC::AssemblyHelpers::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
(JSC::AssemblyHelpers::emitConvertValueToBoolean):
(JSC::AssemblyHelpers::debugCall):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::AssemblyHelpers):
(JSC::AssemblyHelpers::codeBlock):
(JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
(JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToVMEntryFrameCalleeSavesBuffer):
(JSC::AssemblyHelpers::barrierBranch):
(JSC::AssemblyHelpers::barrierStoreLoadFence):
(JSC::AssemblyHelpers::mutatorFence):
(JSC::AssemblyHelpers::storeButterfly):
(JSC::AssemblyHelpers::nukeStructureAndStoreButterfly):
(JSC::AssemblyHelpers::jumpIfMutatorFenceNotNeeded):
(JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize):
(JSC::AssemblyHelpers::emitAllocateJSObject):
(JSC::AssemblyHelpers::emitAllocateVariableSizedCell):
(JSC::AssemblyHelpers::emitAllocateVariableSizedJSObject):
(JSC::AssemblyHelpers::emitAllocateDestructibleObject):
(JSC::AssemblyHelpers::vm): Deleted.
(JSC::AssemblyHelpers::debugCall): Deleted.
* jit/CCallHelpers.cpp:
(JSC::CCallHelpers::ensureShadowChickenPacket):
* jit/CCallHelpers.h:
(JSC::CCallHelpers::CCallHelpers):
(JSC::CCallHelpers::jumpToExceptionHandler):
* jit/JIT.cpp:
(JSC::JIT::emitEnterOptimizationCheck):
(JSC::JIT::privateCompileExceptionHandlers):
* jit/JIT.h:
(JSC::JIT::exceptionCheck):
(JSC::JIT::exceptionCheckWithCallFrameRollback):
* jit/JITMathIC.h:
(JSC::JITMathIC::generateOutOfLine):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_instanceof):
(JSC::JIT::emit_op_is_undefined):
(JSC::JIT::emit_op_jfalse):
(JSC::JIT::emit_op_jeq_null):
(JSC::JIT::emit_op_jneq_null):
(JSC::JIT::emit_op_jtrue):
(JSC::JIT::emit_op_throw):
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_eq_null):
(JSC::JIT::emit_op_neq_null):
(JSC::JIT::emitSlow_op_loop_hint):
(JSC::JIT::emit_op_log_shadow_chicken_prologue):
(JSC::JIT::emit_op_log_shadow_chicken_tail):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::privateCompileCTINativeCall):
(JSC::JIT::emit_op_new_object):
(JSC::JIT::emit_op_jfalse):
(JSC::JIT::emit_op_jtrue):
(JSC::JIT::emit_op_throw):
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_create_this):
(JSC::JIT::emit_op_log_shadow_chicken_prologue):
(JSC::JIT::emit_op_log_shadow_chicken_tail):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitWriteBarrier):
* jit/JSInterfaceJIT.h:
(JSC::JSInterfaceJIT::JSInterfaceJIT):
(JSC::JSInterfaceJIT::vm):
* jit/Repatch.cpp:
(JSC::tryCacheGetByID):
(JSC::tryCachePutByID):
(JSC::linkPolymorphicCall):
(JSC::resetGetByID):
(JSC::resetPutByID):
* jit/SetupVarargsFrame.cpp:
(JSC::emitSetupVarargsFrameFastCase):
* jit/SetupVarargsFrame.h:
* jit/SpecializedThunkJIT.h:
(JSC::SpecializedThunkJIT::loadArgumentWithSpecificClass):
* jit/ThunkGenerators.cpp:
(JSC::throwExceptionFromCallSlowPathGenerator):
(JSC::linkCallThunkGenerator):
(JSC::linkPolymorphicCallThunkGenerator):
(JSC::virtualThunkFor):
(JSC::nativeForGenerator):
(JSC::randomThunkGenerator):
(JSC::boundThisNoArgsFunctionCallGenerator):
(JSC::throwExceptionFromWasmThunkGenerator):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::parseAndCompile):
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToJs):
(JSC::Wasm::wasmToWasm):
2017-03-28 Keith Miller <keith_miller@apple.com>
WebAssembly: We should have Origins
https://bugs.webkit.org/show_bug.cgi?id=170217
Reviewed by Mark Lam.
This patch adds wasm origins for B3::Values, called OpcodeOrigin. Currently,
OpcodeOrigin just tracks the original opcode and the location of that opcode.
Here's a sample:
BB#0: ; frequency = 1.000000
Int64 @4 = Patchpoint(generator = 0x10f487fa8, earlyClobbered = [], lateClobbered = [], usedRegisters = [], resultConstraint = SomeRegister)
Int64 @5 = FramePointer()
Void @8 = Store(@4, @5, offset = 24, ControlDependent|Writes:Top)
Int64 @10 = Const64(0)
Void @12 = Store($0(@10), @5, offset = 16, ControlDependent|Writes:Top)
Int64 @13 = Patchpoint(generator = 0x10f4be7f0, earlyClobbered = [], lateClobbered = [], usedRegisters = [], resultConstraint = SomeRegister, ExitsSideways|ControlDependent|WritesPinned|ReadsPinned|Fence|Writes:Top|Reads:Top)
Int64 @16 = ArgumentReg(%rdi)
Int64 @18 = ArgumentReg(%rsi)
Int32 @22 = Trunc(@18, Wasm: {opcode: I64Rotl, location: 5})
Int64 @23 = RotL(@16, @22, Wasm: {opcode: I64Rotl, location: 5})
Void @27 = Return(@23, Terminal, Wasm: {opcode: End, location: 6})
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3Value.cpp:
(JSC::B3::Value::deepDump):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::setParser):
(JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
(JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
(JSC::Wasm::B3IRGenerator::emitLoadOp):
(JSC::Wasm::B3IRGenerator::emitStoreOp):
(JSC::Wasm::B3IRGenerator::addConstant):
(JSC::Wasm::B3IRGenerator::addLoop):
(JSC::Wasm::B3IRGenerator::unify):
(JSC::Wasm::parseAndCompile):
(JSC::Wasm::B3IRGenerator::emitChecksForModOrDiv):
(JSC::Wasm::getMemoryBaseAndSize): Deleted.
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser::currentOpcode):
(JSC::Wasm::FunctionParser::currentOpcodeStartingOffset):
(JSC::Wasm::FunctionParser<Context>::FunctionParser):
* wasm/WasmOpcodeOrigin.cpp: Added.
(JSC::Wasm::OpcodeOrigin::dump):
* wasm/WasmOpcodeOrigin.h: Added.
(JSC::Wasm::OpcodeOrigin::OpcodeOrigin):
* wasm/WasmValidate.cpp:
(JSC::Wasm::Validate::setParser):
* wasm/generateWasmB3IRGeneratorInlinesHeader.py:
(CodeGenerator.generate):
(generateB3OpCode):
(generateConstCode):
2017-03-28 JF Bastien <jfbastien@apple.com>
WebAssembly: option to crash if no fast memory is available
https://bugs.webkit.org/show_bug.cgi?id=170219
Reviewed by Mark Lam.
* runtime/Options.h:
* wasm/WasmMemory.cpp:
(JSC::Wasm::webAssemblyCouldntGetFastMemory):
(JSC::Wasm::tryGetFastMemory):
2017-03-28 Mark Lam <mark.lam@apple.com>
The Mutator should not be able to steal the conn if the Collector hasn't reached the NotRunning phase yet.
https://bugs.webkit.org/show_bug.cgi?id=170213
<rdar://problem/30755345>
Reviewed by Filip Pizlo.
The current condition for stealing the conn isn't tight enough. Restricting the
stealing to when m_currentPhase == NotRunning ensures that the Collector is
really done running.
No test because this issue only manifests with a race condition that is difficult
to reproduce on demand.
* heap/Heap.cpp:
(JSC::Heap::requestCollection):
2017-03-28 Keith Miller <keith_miller@apple.com>
WebAssembly: Make WebAssembly.instantiate/compile truly asynchronous
https://bugs.webkit.org/show_bug.cgi?id=169187
Reviewed by Saam Barati.
This patch allows WebAssembly compilations to happen asynchronously.
To do so, it refactors how much of the compilation happens and adds
new infrastructure for async promises.
First, there is a new class, PromiseDeferredTimer that lives on
the VM. PromiseDeferredTimer will manage the life-cycle of async
pending promises and any dependencies that promise
needs. PromiseDeferredTimer automagically releases the pending
promise and dependencies once the JSPromiseDeferred is resolved or
rejected. Additionally, PromiseDeferredTimer provides a mechanism
to poll the run-loop whenever the async task needs to synchronize
with the JS thread. Normally, that will be whenever the async task
finishes. In the case of Web Assembly we also use this feature for
the compile + instantiate case, where we might have more work
after the first async task completes (more on that later).
The next class is Wasm::Worklist, which is used to manage Wasm
compilation tasks. The worklist class works similarly to the
DFG/FTL Worklists. It has a pool of threads that it manages. One
interesting aspect of Wasm Worklist is that it can synchronously
compile a plan that is already potentially running
asynchronously. This can occur if a user calls
WebAssembly.instantiate() then new WebAssembly.instantiate() on
the same module. In that case the Wasm Worklist will bump the
priority of the running pending Plan and block the JS thread.
This patch also makes some of the Wasm Plan code cleaner. Since we
now defer all compilation to instantiation time, we no longer need
to guess at which memory we are going to get. Also, Wasm Plans now
track the work they have done with a state enum.
Finally, this patch makes renamed HeapTimer to JSRunLoopTimer. It
also adds changes test262AsyncTest to a more generic testing
infrastructure. Now, in addition to the old functionality, you can
call asyncTest() with the number of tests you expect. When the jsc
CLI exits, it will guarantee that asyncTestPassed() is called that
many times.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/GCActivityCallback.h:
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::scheduleTimer):
(JSC::IncrementalSweeper::IncrementalSweeper):
* heap/IncrementalSweeper.h:
* heap/StopIfNecessaryTimer.cpp:
(JSC::StopIfNecessaryTimer::StopIfNecessaryTimer):
* heap/StopIfNecessaryTimer.h:
* heap/StrongInlines.h:
* jsc.cpp:
(GlobalObject::finishCreation):
(printInternal):
(functionAsyncTestStart):
(functionAsyncTestPassed):
(functionTestWasmModuleFunctions):
(CommandLine::parseArguments):
(runJSC):
* runtime/JSPromiseDeferred.cpp:
(JSC::JSPromiseDeferred::resolve):
(JSC::JSPromiseDeferred::reject):
* runtime/JSPromiseDeferred.h:
(JSC::JSPromiseDeferred::promiseAsyncPending):
* runtime/JSRunLoopTimer.cpp: Renamed from Source/JavaScriptCore/heap/HeapTimer.cpp.
(JSC::JSRunLoopTimer::JSRunLoopTimer):
(JSC::JSRunLoopTimer::setRunLoop):
(JSC::JSRunLoopTimer::~JSRunLoopTimer):
(JSC::JSRunLoopTimer::timerDidFire):
(JSC::JSRunLoopTimer::scheduleTimer):
(JSC::JSRunLoopTimer::cancelTimer):
(JSC::JSRunLoopTimer::invalidate):
* runtime/JSRunLoopTimer.h: Copied from Source/JavaScriptCore/heap/HeapTimer.h.
* runtime/Options.h:
* runtime/PromiseDeferredTimer.cpp: Added.
(JSC::PromiseDeferredTimer::PromiseDeferredTimer):
(JSC::PromiseDeferredTimer::doWork):
(JSC::PromiseDeferredTimer::runRunLoop):
(JSC::PromiseDeferredTimer::addPendingPromise):
(JSC::PromiseDeferredTimer::cancelPendingPromise):
(JSC::PromiseDeferredTimer::scheduleWorkSoon):
(JSC::PromiseDeferredTimer::scheduleBlockedTask):
* runtime/PromiseDeferredTimer.h: Renamed from Source/JavaScriptCore/heap/HeapTimer.h.
(JSC::PromiseDeferredTimer::stopRunningTasks):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::~VM):
* runtime/VM.h:
* wasm/JSWebAssembly.cpp:
(JSC::reject):
(JSC::webAssemblyCompileFunc):
(JSC::resolve):
(JSC::instantiate):
(JSC::compileAndInstantiate):
(JSC::webAssemblyInstantiateFunc):
(JSC::webAssemblyValidateFunc):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
(JSC::Wasm::B3IRGenerator::memoryKind):
(JSC::Wasm::parseAndCompile):
* wasm/WasmB3IRGenerator.h:
* wasm/WasmFormat.h:
(JSC::Wasm::ModuleInformation::internalFunctionCount):
* wasm/WasmFunctionParser.h:
* wasm/WasmMemory.h:
* wasm/WasmMemoryInformation.cpp:
(JSC::Wasm::MemoryInformation::MemoryInformation):
* wasm/WasmMemoryInformation.h:
(JSC::Wasm::MemoryInformation::maximum):
(JSC::Wasm::MemoryInformation::hasReservedMemory): Deleted.
(JSC::Wasm::MemoryInformation::takeReservedMemory): Deleted.
(JSC::Wasm::MemoryInformation::mode): Deleted.
* wasm/WasmModuleParser.cpp:
* wasm/WasmModuleParser.h:
(JSC::Wasm::ModuleParser::ModuleParser):
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::Plan):
(JSC::Wasm::Plan::stateString):
(JSC::Wasm::Plan::moveToState):
(JSC::Wasm::Plan::fail):
(JSC::Wasm::Plan::parseAndValidateModule):
(JSC::Wasm::Plan::prepare):
(JSC::Wasm::Plan::ThreadCountHolder::ThreadCountHolder):
(JSC::Wasm::Plan::ThreadCountHolder::~ThreadCountHolder):
(JSC::Wasm::Plan::compileFunctions):
(JSC::Wasm::Plan::complete):
(JSC::Wasm::Plan::waitForCompletion):
(JSC::Wasm::Plan::cancel):
(JSC::Wasm::Plan::run): Deleted.
(JSC::Wasm::Plan::initializeCallees): Deleted.
* wasm/WasmPlan.h:
(JSC::Wasm::Plan::dontFinalize):
(JSC::Wasm::Plan::exports):
(JSC::Wasm::Plan::internalFunctionCount):
(JSC::Wasm::Plan::takeModuleInformation):
(JSC::Wasm::Plan::takeCallLinkInfos):
(JSC::Wasm::Plan::takeWasmExitStubs):
(JSC::Wasm::Plan::setModeAndPromise):
(JSC::Wasm::Plan::mode):
(JSC::Wasm::Plan::pendingPromise):
(JSC::Wasm::Plan::vm):
(JSC::Wasm::Plan::errorMessage):
(JSC::Wasm::Plan::failed):
(JSC::Wasm::Plan::hasWork):
(JSC::Wasm::Plan::hasBeenPrepared):
* wasm/WasmPlanInlines.h: Copied from Source/JavaScriptCore/wasm/WasmB3IRGenerator.h.
(JSC::Wasm::Plan::initializeCallees):
* wasm/WasmValidate.cpp:
* wasm/WasmWorklist.cpp: Added.
(JSC::Wasm::Worklist::priorityString):
(JSC::Wasm::Worklist::QueueElement::setToNextPriority):
(JSC::Wasm::Worklist::iterate):
(JSC::Wasm::Worklist::enqueue):
(JSC::Wasm::Worklist::completePlanSynchronously):
(JSC::Wasm::Worklist::stopAllPlansForVM):
(JSC::Wasm::Worklist::Worklist):
(JSC::Wasm::Worklist::~Worklist):
(JSC::Wasm::existingWorklistOrNull):
(JSC::Wasm::ensureWorklist):
* wasm/WasmWorklist.h: Added.
(JSC::Wasm::Worklist::nextTicket):
(JSC::Wasm::Worklist::Comparator::operator()):
* wasm/js/JSWebAssemblyCallee.h:
* wasm/js/JSWebAssemblyCodeBlock.cpp:
(JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
(JSC::JSWebAssemblyCodeBlock::initialize):
(JSC::JSWebAssemblyCodeBlock::isSafeToRun):
* wasm/js/JSWebAssemblyCodeBlock.h:
(JSC::JSWebAssemblyCodeBlock::create):
(JSC::JSWebAssemblyCodeBlock::initialized):
(JSC::JSWebAssemblyCodeBlock::plan):
(JSC::JSWebAssemblyCodeBlock::runnable):
(JSC::JSWebAssemblyCodeBlock::errorMessage):
(JSC::JSWebAssemblyCodeBlock::callees):
* wasm/js/JSWebAssemblyHelpers.h:
(JSC::createSourceBufferFromValue):
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::finishCreation):
(JSC::JSWebAssemblyInstance::visitChildren):
(JSC::JSWebAssemblyInstance::addUnitializedCodeBlock):
(JSC::JSWebAssemblyInstance::finalizeCreation):
(JSC::JSWebAssemblyInstance::create):
(JSC::JSWebAssemblyInstance::setMemory): Deleted.
* wasm/js/JSWebAssemblyInstance.h:
(JSC::JSWebAssemblyInstance::codeBlock):
(JSC::JSWebAssemblyInstance::initialized):
(JSC::JSWebAssemblyInstance::module):
(JSC::JSWebAssemblyInstance::importFunction):
(JSC::JSWebAssemblyInstance::setMemory):
(JSC::JSWebAssemblyInstance::table):
(JSC::JSWebAssemblyInstance::importFunctions):
(JSC::JSWebAssemblyInstance::setImportFunction): Deleted.
(JSC::JSWebAssemblyInstance::setTable): Deleted.
* wasm/js/JSWebAssemblyModule.cpp:
(JSC::JSWebAssemblyModule::createStub):
(JSC::JSWebAssemblyModule::JSWebAssemblyModule):
(JSC::JSWebAssemblyModule::finishCreation):
(JSC::JSWebAssemblyModule::setCodeBlock):
(JSC::JSWebAssemblyModule::buildCodeBlock): Deleted.
(JSC::JSWebAssemblyModule::create): Deleted.
(JSC::JSWebAssemblyModule::codeBlock): Deleted.
* wasm/js/JSWebAssemblyModule.h:
(JSC::JSWebAssemblyModule::moduleInformation):
(JSC::JSWebAssemblyModule::codeBlock):
(JSC::JSWebAssemblyModule::source):
(JSC::JSWebAssemblyModule::takeReservedMemory): Deleted.
(JSC::JSWebAssemblyModule::codeBlockFor): Deleted.
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance):
(JSC::WebAssemblyInstanceConstructor::createInstance): Deleted.
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::WebAssemblyModuleConstructor::createModule):
* wasm/js/WebAssemblyModulePrototype.cpp:
(JSC::webAssemblyModuleProtoImports):
(JSC::webAssemblyModuleProtoExports):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::finishCreation):
(JSC::WebAssemblyModuleRecord::link):
(JSC::WebAssemblyModuleRecord::evaluate):
* wasm/js/WebAssemblyModuleRecord.h:
2017-03-28 Yusuke Suzuki <utatane.tea@gmail.com>
WebAssembly: add fallback to use pinned register to load/store state
https://bugs.webkit.org/show_bug.cgi?id=169773
Reviewed by Saam Barati.
This patch adds a new pinned register to hold JSWebAssemblyInstance,
which is used to represent the context of running Wasm code.
While we use fast TLS to hold the context in macOS, we do not have
any system reserved fast TLS slot in the other systems. This pinned
register approach is used in these systems. These changes decouple
VM from Wasm module to make Wasm module position independent code.
While using fast TLS could be beneficial in x64 systems which number of
registers is relatively small, pinned register approach could be
beneficial in ARM64 which has plenty of registers. In macOS, we can
switch the implementation with the runtime flag. Thus macOS port can
compare the performance and decide which implementation is used after
landing this patch.
* heap/MarkedBlock.h:
(JSC::MarkedBlock::offsetOfVM):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::loadWasmContext):
(JSC::AssemblyHelpers::storeWasmContext):
(JSC::AssemblyHelpers::loadWasmContextNeedsMacroScratchRegister):
(JSC::AssemblyHelpers::storeWasmContextNeedsMacroScratchRegister):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::loadWasmContext): Deleted.
(JSC::AssemblyHelpers::storeWasmContext): Deleted.
(JSC::AssemblyHelpers::loadWasmContextNeedsMacroScratchRegister): Deleted.
(JSC::AssemblyHelpers::storeWasmContextNeedsMacroScratchRegister): Deleted.
* jit/Repatch.cpp:
(JSC::webAssemblyOwner):
(JSC::linkFor):
(JSC::linkPolymorphicCall):
(JSC::isWebAssemblyToJSCallee): Deleted.
* jit/ThunkGenerators.cpp:
(JSC::throwExceptionFromWasmThunkGenerator):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LowLevelInterpreter.asm:
* runtime/JSCell.cpp:
(JSC::JSCell::isAnyWasmCallee):
* runtime/JSCellInlines.h:
(JSC::isWebAssemblyToJSCallee):
* runtime/JSType.h:
* runtime/StackFrame.cpp:
(JSC::StackFrame::functionName):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
(JSC::VM::wasmContextOffset):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::materializeWasmContext):
(JSC::Wasm::B3IRGenerator::restoreWasmContext):
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::getMemoryBaseAndSize):
(JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
(JSC::Wasm::createJSToWasmWrapper):
(JSC::Wasm::loadWasmContext): Deleted.
(JSC::Wasm::storeWasmContext): Deleted.
(JSC::Wasm::restoreWebAssemblyGlobalState): Deleted.
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToJs):
* wasm/WasmContext.cpp:
(JSC::loadWasmContext):
(JSC::storeWasmContext):
* wasm/WasmContext.h:
* wasm/WasmMemoryInformation.cpp:
(JSC::Wasm::getPinnedRegisters):
(JSC::Wasm::PinnedRegisterInfo::get):
(JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
* wasm/WasmMemoryInformation.h:
(JSC::Wasm::PinnedRegisterInfo::toSave):
(JSC::Wasm::useFastTLS):
(JSC::Wasm::useFastTLSForWasmContext):
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::finishCreation):
(JSC::JSWebAssemblyInstance::visitChildren):
* wasm/js/JSWebAssemblyInstance.h:
(JSC::JSWebAssemblyInstance::offsetOfCallee):
* wasm/js/JSWebAssemblyModule.cpp:
(JSC::JSWebAssemblyModule::finishCreation):
(JSC::JSWebAssemblyModule::visitChildren):
* wasm/js/JSWebAssemblyModule.h:
(JSC::JSWebAssemblyModule::callee):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
(JSC::WebAssemblyFunction::create):
* wasm/js/WebAssemblyToJSCallee.cpp:
(JSC::WebAssemblyToJSCallee::create):
(JSC::WebAssemblyToJSCallee::createStructure):
(JSC::WebAssemblyToJSCallee::finishCreation):
(JSC::WebAssemblyToJSCallee::visitChildren):
(JSC::WebAssemblyToJSCallee::destroy): Deleted.
* wasm/js/WebAssemblyToJSCallee.h:
2017-03-28 Brian Burg <bburg@apple.com>
Web Inspector: Add "Disable Caches" option that only applies to the inspected page while Web Inspector is open
https://bugs.webkit.org/show_bug.cgi?id=169865
<rdar://problem/31250573>
Reviewed by Joseph Pecoraro.
* inspector/protocol/Network.json:
Rename the command for disabling resource caching to match the WebCore::Page
flag. This also removes the possibility that this could be confused for the old,
buggy command that this patch rips out.
2017-03-25 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Move platformThreadSignal to WTF
https://bugs.webkit.org/show_bug.cgi?id=170097
Reviewed by Mark Lam.
It is a small clean up towards https://bugs.webkit.org/show_bug.cgi?id=170027.
platformThreadSignal uses PlatformThread in JSC, but it can be implemented in
WTF ThreadIdentifier.
* runtime/JSLock.cpp:
(JSC::JSLock::lock):
* runtime/JSLock.h:
(JSC::JSLock::ownerThread):
(JSC::JSLock::currentThreadIsHoldingLock):
* runtime/PlatformThread.h:
(JSC::platformThreadSignal): Deleted.
* runtime/VM.h:
(JSC::VM::ownerThread):
* runtime/VMTraps.cpp:
(JSC::VMTraps::SignalSender::send):
2017-03-28 JF Bastien <jfbastien@apple.com>
WebAssembly: implement Module imports/exports
https://bugs.webkit.org/show_bug.cgi?id=166982
Reviewed by Saam Barati.
As defined in: https://github.com/WebAssembly/design/commit/18cbacb90cd3584dd5c9aa3d392e4e55f66af6ab
* wasm/WasmFormat.h:
(JSC::Wasm::makeString): use uppercase instead, it was only used
for diagnostic but is now used for the expected JS property's
capitalization
* wasm/js/WebAssemblyModulePrototype.cpp:
(JSC::webAssemblyModuleProtoImports):
(JSC::webAssemblyModuleProtoExports):
2017-03-27 JF Bastien <jfbastien@apple.com>
WebAssembly: JSWebAssemblyCodeBlock.h belongs in JavaScriptCore/wasm/js not JavaScriptCore/wasm
https://bugs.webkit.org/show_bug.cgi?id=170160
Reviewed by Mark Lam.
* JavaScriptCore.xcodeproj/project.pbxproj:
* wasm/js/JSWebAssemblyCodeBlock.h: Renamed from Source/JavaScriptCore/wasm/JSWebAssemblyCodeBlock.h.
2017-03-27 JF Bastien <jfbastien@apple.com>
WebAssembly: misc memory testing
https://bugs.webkit.org/show_bug.cgi?id=170137
Reviewed by Keith Miller.
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::WebAssemblyInstanceConstructor::createInstance): improve error messages
2017-03-27 Michael Saboff <msaboff@apple.com>
Add ARM64 system instructions to disassembler
https://bugs.webkit.org/show_bug.cgi?id=170084
Reviewed by Saam Barati.
This changes adds support for MRS and MSR instructions, and refactors the DMB
disassembly to handle all of the barrier instructions.
* disassembler/ARM64/A64DOpcode.cpp:
(JSC::ARM64Disassembler::A64DOpcodeMSRImmediate::format):
(JSC::ARM64Disassembler::A64DOpcodeMSROrMRSRegister::format):
(JSC::ARM64Disassembler::A64DOpcodeSystemSync::format):
(JSC::ARM64Disassembler::A64DOpcodeDmb::format): Deleted.
* disassembler/ARM64/A64DOpcode.h:
(JSC::ARM64Disassembler::A64DOpcodeSystem::lBit):
(JSC::ARM64Disassembler::A64DOpcodeSystem::op0):
(JSC::ARM64Disassembler::A64DOpcodeSystem::op1):
(JSC::ARM64Disassembler::A64DOpcodeSystem::crN):
(JSC::ARM64Disassembler::A64DOpcodeSystem::crM):
(JSC::ARM64Disassembler::A64DOpcodeSystem::op2):
(JSC::ARM64Disassembler::A64DOpcodeMSROrMRSRegister::opName):
(JSC::ARM64Disassembler::A64DOpcodeMSROrMRSRegister::systemRegister):
(JSC::ARM64Disassembler::A64DOpcodeSystemSync::opName):
(JSC::ARM64Disassembler::A64DOpcodeSystemSync::option):
(JSC::ARM64Disassembler::A64DOpcodeDmb::opName): Deleted.
(JSC::ARM64Disassembler::A64DOpcodeDmb::option): Deleted.
(JSC::ARM64Disassembler::A64DOpcodeDmb::crM): Deleted.
2017-03-26 Filip Pizlo <fpizlo@apple.com>
B3::fixSSA should do liveness pruning
https://bugs.webkit.org/show_bug.cgi?id=170111
Reviewed by Saam Barati.
This moves all of the logic of Air::Liveness<> to WTF::Liveness<> and then uses that to
create B3::VariableLiveness. Then this uses VariableLiveness::LiveAtHead to prune Phi
construction.
This makes B3::fixSSA run twice as fast. This is a 13% progression on WasmBench compile
times.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3BasicBlock.h:
(JSC::B3::BasicBlock::get):
* b3/B3FixSSA.cpp:
(JSC::B3::fixSSA):
* b3/B3VariableLiveness.cpp: Added.
(JSC::B3::VariableLiveness::VariableLiveness):
(JSC::B3::VariableLiveness::~VariableLiveness):
* b3/B3VariableLiveness.h: Added.
(JSC::B3::VariableLivenessAdapter::VariableLivenessAdapter):
(JSC::B3::VariableLivenessAdapter::numIndices):
(JSC::B3::VariableLivenessAdapter::valueToIndex):
(JSC::B3::VariableLivenessAdapter::indexToValue):
(JSC::B3::VariableLivenessAdapter::blockSize):
(JSC::B3::VariableLivenessAdapter::forEachEarlyUse):
(JSC::B3::VariableLivenessAdapter::forEachLateUse):
(JSC::B3::VariableLivenessAdapter::forEachEarlyDef):
(JSC::B3::VariableLivenessAdapter::forEachLateDef):
* b3/air/AirCFG.h: Added.
(JSC::B3::Air::CFG::CFG):
(JSC::B3::Air::CFG::root):
(JSC::B3::Air::CFG::newMap):
(JSC::B3::Air::CFG::successors):
(JSC::B3::Air::CFG::predecessors):
(JSC::B3::Air::CFG::index):
(JSC::B3::Air::CFG::node):
(JSC::B3::Air::CFG::numNodes):
(JSC::B3::Air::CFG::dump):
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::Code):
* b3/air/AirCode.h:
(JSC::B3::Air::Code::cfg):
* b3/air/AirLiveness.h:
(JSC::B3::Air::LivenessAdapter::LivenessAdapter):
(JSC::B3::Air::LivenessAdapter::blockSize):
(JSC::B3::Air::LivenessAdapter::forEachEarlyUse):
(JSC::B3::Air::LivenessAdapter::forEachLateUse):
(JSC::B3::Air::LivenessAdapter::forEachEarlyDef):
(JSC::B3::Air::LivenessAdapter::forEachLateDef):
(JSC::B3::Air::TmpLivenessAdapter::TmpLivenessAdapter):
(JSC::B3::Air::TmpLivenessAdapter::numIndices):
(JSC::B3::Air::StackSlotLivenessAdapter::StackSlotLivenessAdapter):
(JSC::B3::Air::StackSlotLivenessAdapter::numIndices):
(JSC::B3::Air::StackSlotLivenessAdapter::indexToValue):
(JSC::B3::Air::Liveness::Liveness):
(JSC::B3::Air::Liveness::LocalCalc::LocalCalc): Deleted.
(JSC::B3::Air::Liveness::LocalCalc::Iterable::Iterable): Deleted.
(JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::iterator): Deleted.
(JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator++): Deleted.
(JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator*): Deleted.
(JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator==): Deleted.
(JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator!=): Deleted.
(JSC::B3::Air::Liveness::LocalCalc::Iterable::begin): Deleted.
(JSC::B3::Air::Liveness::LocalCalc::Iterable::end): Deleted.
(JSC::B3::Air::Liveness::LocalCalc::Iterable::contains): Deleted.
(JSC::B3::Air::Liveness::LocalCalc::live): Deleted.
(JSC::B3::Air::Liveness::LocalCalc::isLive): Deleted.
(JSC::B3::Air::Liveness::LocalCalc::execute): Deleted.
(JSC::B3::Air::Liveness::rawLiveAtHead): Deleted.
(JSC::B3::Air::Liveness::Iterable::Iterable): Deleted.
(JSC::B3::Air::Liveness::Iterable::iterator::iterator): Deleted.
(JSC::B3::Air::Liveness::Iterable::iterator::operator*): Deleted.
(JSC::B3::Air::Liveness::Iterable::iterator::operator++): Deleted.
(JSC::B3::Air::Liveness::Iterable::iterator::operator==): Deleted.
(JSC::B3::Air::Liveness::Iterable::iterator::operator!=): Deleted.
(JSC::B3::Air::Liveness::Iterable::begin): Deleted.
(JSC::B3::Air::Liveness::Iterable::end): Deleted.
(JSC::B3::Air::Liveness::Iterable::contains): Deleted.
(JSC::B3::Air::Liveness::liveAtHead): Deleted.
(JSC::B3::Air::Liveness::liveAtTail): Deleted.
(JSC::B3::Air::Liveness::workset): Deleted.
2017-03-25 Filip Pizlo <fpizlo@apple.com>
Air::Liveness shouldn't need HashSets
https://bugs.webkit.org/show_bug.cgi?id=170102
Reviewed by Yusuke Suzuki.
This converts Air::Liveness<> to no longer use HashSets or BitVectors. This turns out to be
easy because it's cheap enough to do a sorted merge of the things being added to liveAtHead and
the things in the predecessors' liveAtTail. This turns out to be faster - it's a 2% overall
compile time progression on WasmBench.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower): Add a FIXME unrelated to this patch.
* b3/air/AirLiveness.h:
(JSC::B3::Air::AbstractLiveness::AbstractLiveness):
(JSC::B3::Air::AbstractLiveness::LocalCalc::LocalCalc):
(JSC::B3::Air::AbstractLiveness::rawLiveAtHead):
(JSC::B3::Air::AbstractLiveness::liveAtHead):
(JSC::B3::Air::AbstractLiveness::liveAtTail):
* b3/air/AirTmp.h:
(JSC::B3::Air::Tmp::bank):
(JSC::B3::Air::Tmp::tmpIndex):
* dfg/DFGStoreBarrierClusteringPhase.cpp:
2017-03-26 Filip Pizlo <fpizlo@apple.com>
Air should use RegisterSet for RegLiveness
https://bugs.webkit.org/show_bug.cgi?id=170108
Reviewed by Yusuke Suzuki.
The biggest change here is the introduction of the new RegLiveness class. This is a
drop-in replacement for the old RegLiveness, which was a specialization of
AbstractLiveness<>, but it's about 30% faster. It gets its speed boost from just using
sets everywhere, which is efficient for registers since RegisterSet is just two (on
x86-64) or three 32-bit (on ARM64) statically allocated words. This looks like a 1%
compile time progression on WasmBench.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3TimingScope.cpp: Records phase timing totals.
(JSC::B3::TimingScope::TimingScope):
(JSC::B3::TimingScope::~TimingScope):
* b3/B3TimingScope.h:
* b3/air/AirAllocateRegistersByGraphColoring.cpp:
(JSC::B3::Air::allocateRegistersByGraphColoring):
* b3/air/AirLiveness.h: Move code around and rename a bit to make it more like RegLiveness; in particular we want the `iterator` to be called `iterator` not `Iterator`, and we want it to be internal to its iterable. Also rename this template to Liveness, to match the header filename.
(JSC::B3::Air::Liveness::Liveness):
(JSC::B3::Air::Liveness::LocalCalc::LocalCalc):
(JSC::B3::Air::Liveness::LocalCalc::Iterable::Iterable):
(JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::iterator):
(JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator++):
(JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator*):
(JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator==):
(JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator!=):
(JSC::B3::Air::Liveness::LocalCalc::Iterable::begin):
(JSC::B3::Air::Liveness::LocalCalc::Iterable::end):
(JSC::B3::Air::Liveness::Iterable::Iterable):
(JSC::B3::Air::Liveness::Iterable::iterator::iterator):
(JSC::B3::Air::RegLivenessAdapter::RegLivenessAdapter): Deleted.
(JSC::B3::Air::RegLivenessAdapter::numIndices): Deleted.
(JSC::B3::Air::RegLivenessAdapter::acceptsBank): Deleted.
(JSC::B3::Air::RegLivenessAdapter::acceptsRole): Deleted.
(JSC::B3::Air::RegLivenessAdapter::valueToIndex): Deleted.
(JSC::B3::Air::RegLivenessAdapter::indexToValue): Deleted.
(JSC::B3::Air::AbstractLiveness::AbstractLiveness): Deleted.
(JSC::B3::Air::AbstractLiveness::LocalCalc::LocalCalc): Deleted.
(JSC::B3::Air::AbstractLiveness::LocalCalc::Iterator::Iterator): Deleted.
(JSC::B3::Air::AbstractLiveness::LocalCalc::Iterator::operator++): Deleted.
(JSC::B3::Air::AbstractLiveness::LocalCalc::Iterator::operator*): Deleted.
(JSC::B3::Air::AbstractLiveness::LocalCalc::Iterator::operator==): Deleted.
(JSC::B3::Air::AbstractLiveness::LocalCalc::Iterator::operator!=): Deleted.
(JSC::B3::Air::AbstractLiveness::LocalCalc::Iterable::Iterable): Deleted.
(JSC::B3::Air::AbstractLiveness::LocalCalc::Iterable::begin): Deleted.
(JSC::B3::Air::AbstractLiveness::LocalCalc::Iterable::end): Deleted.
(JSC::B3::Air::AbstractLiveness::LocalCalc::Iterable::contains): Deleted.
(JSC::B3::Air::AbstractLiveness::LocalCalc::live): Deleted.
(JSC::B3::Air::AbstractLiveness::LocalCalc::isLive): Deleted.
(JSC::B3::Air::AbstractLiveness::LocalCalc::execute): Deleted.
(JSC::B3::Air::AbstractLiveness::rawLiveAtHead): Deleted.
(JSC::B3::Air::AbstractLiveness::Iterable::Iterable): Deleted.
(JSC::B3::Air::AbstractLiveness::Iterable::iterator::iterator): Deleted.
(JSC::B3::Air::AbstractLiveness::Iterable::iterator::operator*): Deleted.
(JSC::B3::Air::AbstractLiveness::Iterable::iterator::operator++): Deleted.
(JSC::B3::Air::AbstractLiveness::Iterable::iterator::operator==): Deleted.
(JSC::B3::Air::AbstractLiveness::Iterable::iterator::operator!=): Deleted.
(JSC::B3::Air::AbstractLiveness::Iterable::begin): Deleted.
(JSC::B3::Air::AbstractLiveness::Iterable::end): Deleted.
(JSC::B3::Air::AbstractLiveness::Iterable::contains): Deleted.
(JSC::B3::Air::AbstractLiveness::liveAtHead): Deleted.
(JSC::B3::Air::AbstractLiveness::liveAtTail): Deleted.
(JSC::B3::Air::AbstractLiveness::workset): Deleted.
* b3/air/AirLogRegisterPressure.cpp:
* b3/air/AirLowerAfterRegAlloc.cpp:
* b3/air/AirRegLiveness.cpp: Added.
(JSC::B3::Air::RegLiveness::RegLiveness):
(JSC::B3::Air::RegLiveness::~RegLiveness):
(JSC::B3::Air::RegLiveness::LocalCalc::execute):
* b3/air/AirRegLiveness.h: Added.
(JSC::B3::Air::RegLiveness::LocalCalc::LocalCalc):
(JSC::B3::Air::RegLiveness::LocalCalc::live):
(JSC::B3::Air::RegLiveness::LocalCalc::isLive):
(JSC::B3::Air::RegLiveness::liveAtHead):
(JSC::B3::Air::RegLiveness::liveAtTail):
* b3/air/AirReportUsedRegisters.cpp:
* jit/RegisterSet.h:
(JSC::RegisterSet::add):
(JSC::RegisterSet::remove):
(JSC::RegisterSet::contains):
(JSC::RegisterSet::subsumes):
(JSC::RegisterSet::iterator::iterator):
(JSC::RegisterSet::iterator::operator*):
(JSC::RegisterSet::iterator::operator++):
(JSC::RegisterSet::iterator::operator==):
(JSC::RegisterSet::iterator::operator!=):
(JSC::RegisterSet::begin):
(JSC::RegisterSet::end):
2017-03-25 Filip Pizlo <fpizlo@apple.com>
Fix wasm by returning after we do TLS.
Rubber stamped by Keith Miller.
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::storeWasmContext):
2017-03-24 Mark Lam <mark.lam@apple.com>
Add some instrumentation in Heap::resumeThePeriphery() to help debug an issue.
https://bugs.webkit.org/show_bug.cgi?id=170086
<rdar://problem/31253673>
Reviewed by Saam Barati.
Adding some instrumentation in Heap::resumeThePeriphery() to dump some Heap state
just before we RELEASE_ASSERT_NOT_REACHED.
* heap/Heap.cpp:
(JSC::Heap::resumeThePeriphery):
2017-03-24 JF Bastien <jfbastien@apple.com>
WebAssembly: store state in TLS instead of on VM
https://bugs.webkit.org/show_bug.cgi?id=169611
Reviewed by Filip Pizlo.
Using thread-local storage instead of VM makes code more position
independent. We used to store the WebAssembly top Instance (the
latest one in the call stack) on VM, now we instead store it in
TLS. This top Instance is used to access a bunch of state such as
Memory location, size, table (for call_indirect), etc.
Instead of calling it "top", which is confusing, we now just call
it WasmContext.
Making the code PIC means future patches will be able to
postMessage and structured clone into IDB without having to
recompile the code. This wasn't possible before because we
hard-coded the address of VM at compilation time. That doesn't
work between workers, and doesn't work across reloads (which IDB
is intended to do).
It'll also potentially make code faster once we start tuning
what's in TLS, what's in which of the 4 free slots, and what's in
pinned registers. I'm leaving this tuning for later because
there's lower lying fruit for us to pick.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/AbstractMacroAssembler.h:
* assembler/AllowMacroScratchRegisterUsageIf.h: Copied from assembler/AllowMacroScratchRegisterUsage.h.
(JSC::AllowMacroScratchRegisterUsageIf::AllowMacroScratchRegisterUsageIf):
(JSC::AllowMacroScratchRegisterUsageIf::~AllowMacroScratchRegisterUsageIf):
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::storeToTLSPtr): we previously didn't have
the code required to store to TLS, only to load
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::loadFromTLSPtrNeedsMacroScratchRegister):
(JSC::MacroAssemblerARM64::storeToTLS32):
(JSC::MacroAssemblerARM64::storeToTLS64):
(JSC::MacroAssemblerARM64::storeToTLSPtrNeedsMacroScratchRegister):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::loadFromTLSPtrNeedsMacroScratchRegister):
(JSC::MacroAssemblerX86Common::storeToTLS32):
(JSC::MacroAssemblerX86Common::storeToTLSPtrNeedsMacroScratchRegister):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::loadFromTLS64): was loading 32-bit instead of 64-bit
(JSC::MacroAssemblerX86_64::storeToTLS64):
* assembler/X86Assembler.h:
(JSC::X86Assembler::movl_rm):
(JSC::X86Assembler::movq_rm):
* b3/testb3.cpp:
(JSC::B3::testFastTLSLoad):
(JSC::B3::testFastTLSStore):
(JSC::B3::run):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::loadWasmContext):
(JSC::AssemblyHelpers::storeWasmContext):
(JSC::AssemblyHelpers::loadWasmContextNeedsMacroScratchRegister):
(JSC::AssemblyHelpers::storeWasmContextNeedsMacroScratchRegister):
* jit/Repatch.cpp:
(JSC::webAssemblyOwner):
* jit/ThunkGenerators.cpp:
(JSC::throwExceptionFromWasmThunkGenerator):
* runtime/Options.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::loadWasmContext):
(JSC::Wasm::storeWasmContext):
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::getMemoryBaseAndSize):
(JSC::Wasm::restoreWebAssemblyGlobalState):
(JSC::Wasm::createJSToWasmWrapper):
(JSC::Wasm::parseAndCompile):
* wasm/WasmBinding.cpp:
(JSC::Wasm::materializeImportJSCell):
(JSC::Wasm::wasmToJs):
(JSC::Wasm::wasmToWasm):
* wasm/WasmContext.cpp: Added.
(JSC::loadWasmContext):
(JSC::storeWasmContext):
* wasm/WasmContext.h: Added. Replaces "top" JSWebAssemblyInstance.
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
* wasm/js/WebAssemblyInstanceConstructor.h:
2017-03-24 JF Bastien <jfbastien@apple.com>
WebAssembly: spec-tests/memory.wast.js fails in debug
https://bugs.webkit.org/show_bug.cgi?id=169794
Reviewed by Keith Miller.
The failure was due to empty memories (with maximum size 0). Those
only occur in tests and in code that's trying to trip us. This
patch adds memory mode "none" which represents no memory. It can
work with either bounds checked or signaling code because it never
contains loads and stores.
The spec tests which were failing did the following:
> (module (memory (data)) (func (export "memsize") (result i32) (current_memory)))
> (assert_return (invoke "memsize") (i32.const 0))
> (module (memory (data "")) (func (export "memsize") (result i32) (current_memory)))
> (assert_return (invoke "memsize") (i32.const 0))
> (module (memory (data "x")) (func (export "memsize") (result i32) (current_memory)))
> (assert_return (invoke "memsize") (i32.const 1))
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::memoryKind):
* wasm/WasmMemory.cpp:
(JSC::Wasm::tryGetFastMemory):
(JSC::Wasm::releaseFastMemory):
(JSC::Wasm::Memory::Memory):
(JSC::Wasm::Memory::createImpl):
(JSC::Wasm::Memory::create):
(JSC::Wasm::Memory::grow):
(JSC::Wasm::Memory::makeString):
* wasm/WasmMemory.h:
* wasm/WasmMemoryInformation.cpp:
(JSC::Wasm::MemoryInformation::MemoryInformation):
* wasm/js/JSWebAssemblyCodeBlock.cpp:
(JSC::JSWebAssemblyCodeBlock::isSafeToRun):
* wasm/js/JSWebAssemblyModule.cpp:
(JSC::JSWebAssemblyModule::codeBlock):
(JSC::JSWebAssemblyModule::finishCreation):
* wasm/js/JSWebAssemblyModule.h:
(JSC::JSWebAssemblyModule::codeBlock):
(JSC::JSWebAssemblyModule::codeBlockFor):
2017-03-24 Mark Lam <mark.lam@apple.com>
Array memcpy'ing fast paths should check if we're having a bad time if they cannot handle it.
https://bugs.webkit.org/show_bug.cgi?id=170064
<rdar://problem/31246098>
Reviewed by Geoffrey Garen.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoPrivateFuncConcatMemcpy):
* runtime/JSArray.cpp:
(JSC::JSArray::fastSlice):
2017-03-23 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Use jsNontrivialString agressively for ToString(Int52)
https://bugs.webkit.org/show_bug.cgi?id=170002
Reviewed by Sam Weinig.
We use the same logic used for Int32 to use jsNontvirialString.
After single character check, produced string is always longer than 1.
Thus, we can use jsNontrivialString.
* runtime/NumberPrototype.cpp:
(JSC::int52ToString):
2017-03-23 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Use WeakRandom for SamplingProfiler interval fluctuation
https://bugs.webkit.org/show_bug.cgi?id=170045
Reviewed by Mark Lam.
It is unnecessary to use cryptographicallyRandomNumber for SamplingProfiler
interval fluctuation. Use WeakRandom instead.
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::SamplingProfiler):
(JSC::SamplingProfiler::timerLoop):
* runtime/SamplingProfiler.h:
2017-03-23 Mark Lam <mark.lam@apple.com>
Array.prototype.splice behaves incorrectly when the VM is "having a bad time".
https://bugs.webkit.org/show_bug.cgi?id=170025
<rdar://problem/31228679>
Reviewed by Saam Barati.
* runtime/ArrayPrototype.cpp:
(JSC::copySplicedArrayElements):
(JSC::arrayProtoFuncSplice):
2017-03-23 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC][DFG] Make addShouldSpeculateAnyInt more conservative to avoid regression caused by Double <-> Int52 conversions
https://bugs.webkit.org/show_bug.cgi?id=169998
Reviewed by Saam Barati.
Double <-> Int52 and JSValue <-> Int52 conversions are not so cheap. Thus, Int52Rep is super carefully emitted.
We make addShouldSpeculateAnyInt more conservative to avoid regressions caused by the above conversions.
We select ArithAdd(Int52, Int52) only when this calculation is beneficial compared to added Int52Rep conversions.
This patch tighten the conditions of addShouldSpeculateAnyInt.
1. Honor DoubleConstant.
When executing imaging-darkroom, we have a thing like that,
132:< 2:loc36> DoubleConstant(Double|UseAsOther, AnyIntAsDouble, Double: 4607182418800017408, 1.000000, bc#114)
1320:< 1:loc38> Int52Rep(Check:Int32:@82, Int52|PureInt, Int32, Exits, bc#114)
1321:< 1:loc39> Int52Constant(Int52|PureInt, Boolint32Nonboolint32Int52, Double: 4607182418800017408, 1.000000, bc#114)
133:<!3:loc39> ArithSub(Int52Rep:@1320<Int52>, Int52Rep:@1321<Int52>, Int52|MustGen, Int52, CheckOverflow, Exits, bc#114)
The LHS of ArithSub says predicting Boolint32, and the rhs says AnyIntAsDouble. Thus we select ArithSub(Int52, Int52) instead
of ArithSub(Double, Double). However, it soon causes OSR exits. In imaging-darkroom, LHS's Int32 prediction will be broken.
While speculating Int32 in the above situation is reasonable approach since the given LHS says predicting Int32, this causes
severe performance regression.
Previously, we always select ArithSub(Double, Double). So accidentally, we do not encounter this misprediction issue.
One thing can be found that we have DoubleConstant in the RHS. It means that we have `1.0` instead of `1` in the code.
We can see the code like `lhs - 1.0` instead of `lhs - 1` in imaging-darkroom. It offers good information that lhs and
the resulting value would be double. Handling the above ArithSub in double seems more appropriate rather than handling
it in Int52.
So, in this patch, we honor DoubleConstant. If we find DoubleConstant on one operand, we give up selecting
Arith[Sub,Add](Int52, Int52). This change removes OSR exits occurr in imaging-darkroom right now.
2. Two Int52Rep(Double) conversions are not desirable.
We allow AnyInt ArithAdd only when the one operand of the binary operation should be speculated AnyInt. It is a bit conservative
decision. This is because Double to Int52 conversion is not so cheap. Frequent back-and-forth conversions between Double and Int52
rather hurt the performance. If the one operand of the operation is already Int52, the cost for constructing ArithAdd becomes
cheap since only one Double to Int52 conversion could be required.
This recovers some regression in assorted tests while keeping kraken crypto improvements.
3. Avoid frequent Int52 to JSValue conversions.
Int52 to JSValue conversion is not so cheap. Thus, we would like to avoid such situations. So, in this patch, we allow
Arith(Int52, Int52) with AnyIntAsDouble operand only when the node is used as number. By doing so, we avoid the case like,
converting Int52, performing ArithAdd, and soon converting back to JSValue.
The above 3 changes recover the regression measured in microbenchmarks/int52-back-and-forth.js and assorted benchmarks.
And still it keeps kraken crypto improvements.
baseline patched
imaging-darkroom 201.112+-3.192 ^ 189.532+-2.883 ^ definitely 1.0611x faster
stanford-crypto-pbkdf2 103.953+-2.325 100.926+-2.396 might be 1.0300x faster
stanford-crypto-sha256-iterative 35.103+-1.071 ? 36.049+-1.143 ? might be 1.0270x slower
* dfg/DFGGraph.h:
(JSC::DFG::Graph::addShouldSpeculateAnyInt):
== Rolled over to ChangeLog-2017-03-23 ==