ChangeLog-2015-11-21 [plain text]
2015-11-20 Andreas Kling <akling@apple.com>
REGRESSION(r192536): Null pointer dereference in JSPropertyNameEnumerator::visitChildren().
<https://webkit.org/b/151495>
Reviewed by Mark Lam.
The copied space allocation in JSPropertyNameEnumerator::finishCreation()
may end up triggering a GC, and so JSPropertyNameEnumerator::visitChildren()
would get called while m_propertyNames was still null.
This patch fixes that by having visitChildren() check for pointer nullity
instead of the number of names, since that is non-zero even before the
allocation is made.
Added a test that induces GC during JSPropertyNameEnumerator construction
to cover this bug.
Test: property-name-enumerator-gc-151495.js
* runtime/JSPropertyNameEnumerator.cpp:
(JSC::JSPropertyNameEnumerator::visitChildren):
2015-11-20 Andreas Kling <akling@apple.com>
GC timers should carry on gracefully when Heap claims it grew from GC.
<https://webkit.org/b/151521>
Reviewed by Mark Lam.
TL;DR the Heap "extra memory" reporting APIs are hard to use 100% correctly
and GC scheduling shouldn't break if someone makes a mistake with it.
The JSC::Heap allows you to report an extra memory cost for any GC object.
This is reported first when allocating the memory, and then each time the
object is visited during the marking phase.
When reporting an allocation, it's added to the Heap's "bytes allocated in
this cycle" counter. This contributes to the computed heap size at the start
of a collection.
When visiting a GC object that reports extra memory, it's added to the Heap's
"extra memory visited in this collection" counter. This contributes to the
computed heap size at the end of a collection.
As you can see, this means that visiting more memory than we said we allocated
can lead to the Heap thinking it's bigger after a collection than it was before.
Clients of this API do some sketchy things to compute costs, for instance
StringImpl cost is determined by dividing the number of bytes used for the
characters, and dividing it by the StringImpl's ref count. Since a JSString
could be backed by any StringImpl, any code that modifies a StringImpl's
ref count during collection will change the extra memory reported by all
JSString objects that wrap that StringImpl.
So anyways...
The object death rate, which is the basis for when to schedule the next
collection is computed like so:
deathRate = (sizeBeforeGC - sizeAfterGC) / sizeBeforeGC
This patch adds a safety mechanism that returns a zero death rate when the Heap
claims it grew from collection.
* heap/EdenGCActivityCallback.cpp:
(JSC::EdenGCActivityCallback::deathRate):
* heap/FullGCActivityCallback.cpp:
(JSC::FullGCActivityCallback::deathRate):
2015-11-20 Mark Lam <mark.lam@apple.com>
New JSC tests introduced in r192664 fail on ARM.
https://bugs.webkit.org/show_bug.cgi?id=151485
Reviewed by Geoffrey Garen.
The newly added tests are exposing some pre-existing bugs. The bugs are tracked here:
https://bugs.webkit.org/show_bug.cgi?id=151514
https://bugs.webkit.org/show_bug.cgi?id=151515
Skipping the tests for now.
* tests/stress/op_div.js:
* tests/stress/op_rshift.js:
* tests/stress/op_urshift.js:
2015-11-20 Filip Pizlo <fpizlo@apple.com>
B3 should have a Select opcode
https://bugs.webkit.org/show_bug.cgi?id=150762
Reviewed by Benjamin Poulain.
This cleans up our conditional move implementation - specifically so that it distinguishes between
comparing the low 32 bits of a GPR and all bits of a GPR - and fixes bugs with operand ordering. It
then adds a Select opcode to B3 and adds all of the strength reduction and lowering magic that it
needs. Finally this change implements FTL::Output::select() in terms of B3::Select.
This patch lets us run Kraken/imaging-gaussian-blur. Running that benchmark using FTL+B3 is a 17%
speed-up. The compile times go down dramatically (by about 7x) and code quality stays about the same.
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::moveDoubleConditionally32):
(JSC::MacroAssembler::moveDoubleConditionally64):
(JSC::MacroAssembler::moveDoubleConditionallyTest32):
(JSC::MacroAssembler::moveDoubleConditionallyTest64):
(JSC::MacroAssembler::moveDoubleConditionallyDouble):
(JSC::MacroAssembler::lea):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::move):
(JSC::MacroAssemblerX86Common::moveConditionallyDouble):
(JSC::MacroAssemblerX86Common::zeroExtend32ToPtr):
(JSC::MacroAssemblerX86Common::moveConditionally32):
(JSC::MacroAssemblerX86Common::moveConditionallyTest32):
(JSC::MacroAssemblerX86Common::set32):
(JSC::MacroAssemblerX86Common::cmov):
(JSC::MacroAssemblerX86Common::moveConditionally): Deleted.
(JSC::MacroAssemblerX86Common::moveConditionallyTest): Deleted.
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::branchNeg64):
(JSC::MacroAssemblerX86_64::moveConditionally64):
(JSC::MacroAssemblerX86_64::moveConditionallyTest64):
(JSC::MacroAssemblerX86_64::abortWithReason):
* assembler/X86Assembler.h:
(JSC::X86Assembler::cmovl_rr):
(JSC::X86Assembler::cmovl_mr):
(JSC::X86Assembler::cmovel_rr):
(JSC::X86Assembler::cmovnel_rr):
(JSC::X86Assembler::cmovpl_rr):
(JSC::X86Assembler::cmovnpl_rr):
(JSC::X86Assembler::cmovq_rr):
(JSC::X86Assembler::cmovq_mr):
(JSC::X86Assembler::cmoveq_rr):
(JSC::X86Assembler::cmovneq_rr):
(JSC::X86Assembler::cmovpq_rr):
(JSC::X86Assembler::cmovnpq_rr):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::createCompare):
(JSC::B3::Air::LowerToAir::createSelect):
(JSC::B3::Air::LowerToAir::marshallCCallArgument):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3MoveConstants.cpp:
* b3/B3Opcode.cpp:
(WTF::printInternal):
* b3/B3Opcode.h:
* b3/B3ReduceStrength.cpp:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::effects):
(JSC::B3::Value::key):
(JSC::B3::Value::checkOpcode):
(JSC::B3::Value::typeFor):
* b3/B3Value.h:
* b3/B3ValueKey.cpp:
(JSC::B3::ValueKey::dump):
(JSC::B3::ValueKey::materialize):
* b3/B3ValueKey.h:
(JSC::B3::ValueKey::ValueKey):
(JSC::B3::ValueKey::hash):
(JSC::B3::ValueKey::operator bool):
* b3/B3ValueKeyInlines.h:
(JSC::B3::ValueKey::ValueKey):
(JSC::B3::ValueKey::child):
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testTruncSExt32):
(JSC::B3::testBasicSelect):
(JSC::B3::testSelectTest):
(JSC::B3::testSelectCompareDouble):
(JSC::B3::testSelectDouble):
(JSC::B3::testSelectDoubleTest):
(JSC::B3::testSelectDoubleCompareDouble):
(JSC::B3::zero):
(JSC::B3::run):
* ftl/FTLB3Output.h:
(JSC::FTL::Output::testIsZeroPtr):
(JSC::FTL::Output::testNonZeroPtr):
(JSC::FTL::Output::select):
(JSC::FTL::Output::extractValue):
(JSC::FTL::Output::fence):
2015-11-20 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add Air lowering to BitNot() for Xor(value, -1)
https://bugs.webkit.org/show_bug.cgi?id=151474
Reviewed by Filip Pizlo.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::not32):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::not64):
* assembler/X86Assembler.h:
(JSC::X86Assembler::notq_r):
(JSC::X86Assembler::notq_m):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::createGenericCompare):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3ReduceStrength.cpp:
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testNegValueSubOne):
(JSC::B3::testNegValueSubOne32):
(JSC::B3::testBitNotArg):
(JSC::B3::testBitNotImm):
(JSC::B3::testBitNotMem):
(JSC::B3::testBitNotArg32):
(JSC::B3::testBitNotImm32):
(JSC::B3::testBitNotMem32):
(JSC::B3::testBitNotOnBooleanAndBranch32):
(JSC::B3::int64Operands):
(JSC::B3::int32Operands):
(JSC::B3::run):
* ftl/FTLB3Output.h:
(JSC::FTL::Output::bitNot):
2015-11-20 Yusuke Suzuki <utatane.tea@gmail.com>
Super use should be recorded in per-function scope
https://bugs.webkit.org/show_bug.cgi?id=151500
Reviewed by Geoffrey Garen.
"super" use is prohibited under the non-constructor / non-class-method-related functions.
This "super" use should be recorded in per-function scope to check its incorrect use after
parsing a function.
Currently, we accidentally record it to a lexical current scope. So when using "super" inside
a block scope, our "super" use guard miss it.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseMemberExpression):
* parser/Parser.h:
(JSC::Parser::currentVariableScope):
(JSC::Parser::currentFunctionScope):
(JSC::Parser::declareVariable):
* tests/stress/super-in-lexical-scope.js: Added.
(testSyntax):
(testSyntaxError):
(testSyntaxError.test):
2015-11-20 Chris Dumez <cdumez@apple.com>
Caching of properties on objects that have named property getters is sometimes incorrect
https://bugs.webkit.org/show_bug.cgi?id=151453
<rdar://problem/23049343>
Reviewed by Gavin Barraclough.
Add new GetOwnPropertySlotIsImpureForPropertyAbsence TypeInfo flag to be
used by objects that have a non-'OverrideBuiltins' named property getter.
This flag prevents caching of properties that are missing as a named
property with this name may later become available.
Objects with an 'OverrideBuiltins' named property getter will keep using
the GetOwnPropertySlotIsImpure TypeInfo flag, which prevents all property
caching since named properties can override own properties or properties
on the prototype.
* bytecode/ComplexGetStatus.cpp:
(JSC::ComplexGetStatus::computeFor):
* bytecode/PropertyCondition.cpp:
(JSC::PropertyCondition::isStillValid):
* jit/Repatch.cpp:
(JSC::tryCacheGetByID):
(JSC::tryRepatchIn):
* jsc.cpp:
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::getOwnPropertySlotIsImpure):
(JSC::TypeInfo::getOwnPropertySlotIsImpureForPropertyAbsence):
(JSC::TypeInfo::prohibitsPropertyCaching): Deleted.
* runtime/Structure.h:
2015-11-19 Joseph Pecoraro <pecoraro@apple.com>
REGRESSION(r189433) Web Inspector: JSContext inspection exceptions should include native call frames by default
https://bugs.webkit.org/show_bug.cgi?id=151479
Reviewed by Brian Burg.
* inspector/JSGlobalObjectInspectorController.h:
Value accidentally got flipped when moving to initializer syntax.
2015-11-19 Saam barati <sbarati@apple.com>
[ES6] Add support for rest parameters
https://bugs.webkit.org/show_bug.cgi?id=38408
Reviewed by Geoffrey Garen.
This patch implements rest parameters from the ES6 spec.
http://www.ecma-international.org/ecma-262/6.0/index.html#sec-function-definitions
We implement the rest parameter as a new AST node. This AST node
lowers to "op_new_array X, op_copy_rest X". Note
that the op_copy_rest opcode does not have a result.
The bulk of this patch is implementing op_copy_rest.
This patch implements this in all four tiers in a straight forward way.
The opcode is implemented as a C call that will read the pertinent
arguments from the call frame and fill them into the array.
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecode/Instruction.h:
(JSC::Instruction::Instruction):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
(JSC::BytecodeGenerator::invalidateForInContextForLocal):
(JSC::BytecodeGenerator::emitRestParameter):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::AssignmentElementNode::toString):
(JSC::RestParameterNode::collectBoundIdentifiers):
(JSC::RestParameterNode::toString):
(JSC::RestParameterNode::bindValue):
(JSC::RestParameterNode::emit):
(JSC::SpreadExpressionNode::emitBytecode):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::setEpoch):
(JSC::DFG::Node::numberOfArgumentsToSkip):
(JSC::DFG::Node::dumpChildren):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCreateClonedArguments):
(JSC::DFG::SpeculativeJIT::compileCopyRest):
(JSC::DFG::SpeculativeJIT::compileNotifyWrite):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLIntrinsicRepository.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCreateClonedArguments):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCopyRest):
(JSC::FTL::DFG::LowerDFGToLLVM::compileNewObject):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_create_out_of_band_arguments):
(JSC::JIT::emit_op_copy_rest):
* jit/JITOperations.h:
* llint/LowLevelInterpreter.asm:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createBindingLocation):
(JSC::ASTBuilder::createRestParameter):
(JSC::ASTBuilder::createAssignmentElement):
* parser/NodeConstructors.h:
(JSC::AssignmentElementNode::AssignmentElementNode):
(JSC::RestParameterNode::RestParameterNode):
(JSC::DestructuringAssignmentNode::DestructuringAssignmentNode):
* parser/Nodes.h:
(JSC::DestructuringPatternNode::isBindingNode):
(JSC::DestructuringPatternNode::isRestParameter):
(JSC::DestructuringPatternNode::emitDirectBinding):
(JSC::RestParameterNode::name):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseVariableDeclarationList):
(JSC::Parser<LexerType>::declareRestOrNormalParameter):
(JSC::Parser<LexerType>::createBindingPattern):
(JSC::Parser<LexerType>::parseFormalParameters):
* parser/Parser.h:
(JSC::Parser::strictMode):
(JSC::Parser::isValidStrictMode):
(JSC::Parser::declareParameter):
(JSC::Parser::breakIsValid):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::operatorStackPop):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* tests/es6.yaml:
* tests/stress/rest-parameter-and-default-arguments.js: Added.
(assert):
(shouldThrowTDZ):
(foo):
(baz):
(i.shouldThrowTDZ):
* tests/stress/rest-parameter-basics.js: Added.
(assert):
(foo):
(bar):
(capture):
(baz):
(jaz):
(kaz):
(raz):
(restLength):
(testArgumentsObject):
(strictModeLikeArgumentsObject):
* tests/stress/rest-parameter-inlined.js: Added.
(assert):
(bar):
(foo):
(baz):
(jaz):
2015-11-19 Filip Pizlo <fpizlo@apple.com>
B3 should have a story for Ext/Trunc strength reduction
https://bugs.webkit.org/show_bug.cgi?id=151464
Reviewed by Geoffrey Garen.
The LLVM shift operations require the shift amount to have the same type as the shift base. The B3
shift operations require the shift amount to be an Int32. DFG concurs with this. But the initial
lowering should involve pretending the FTLOutput's shift operations still take an LLVM-style shift
amount so that we don't regress FTL->LLVM performance. That means emitting an extra Trunc. That means
that we want to be able to constant fold Trunc and be able to fold Trunc(ZExt).
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/B3ReduceStrength.cpp:
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testSwitchChillDiv):
(JSC::B3::testTruncFold):
(JSC::B3::testZExt32):
(JSC::B3::testZExt32Fold):
(JSC::B3::testSExt32):
(JSC::B3::testSExt32Fold):
(JSC::B3::testTruncZExt32):
(JSC::B3::testTruncSExt32):
(JSC::B3::zero):
(JSC::B3::run):
* ftl/FTLB3Output.cpp:
(JSC::FTL::Output::store):
(JSC::FTL::Output::baseIndex):
(JSC::FTL::Output::branch):
* ftl/FTLB3Output.h:
(JSC::FTL::Output::bitAnd):
(JSC::FTL::Output::bitOr):
(JSC::FTL::Output::bitXor):
(JSC::FTL::Output::shl):
(JSC::FTL::Output::aShr):
(JSC::FTL::Output::lShr):
(JSC::FTL::Output::bitNot):
(JSC::FTL::Output::insertElement):
(JSC::FTL::Output::address):
(JSC::FTL::Output::baseIndex):
2015-11-19 Mark Lam <mark.lam@apple.com>
Create correctness tests for binary snippet operators.
https://bugs.webkit.org/show_bug.cgi?id=151465
Reviewed by Geoffrey Garen.
Implement a common infrastructure for generating and running tests on binary
operators. Also re-implemented the op_add, op_sub, and op_mul tests to be based
on this new infrastructure.
* tests/stress/op_add.js:
* tests/stress/op_mul.js:
* tests/stress/op_sub.js:
- These were reimplemented using binary-op-test.js.
* tests/stress/op_div.js: Added.
* tests/stress/op_mod.js: Added.
* tests/stress/op_bitand.js: Added.
* tests/stress/op_bitor.js: Added.
* tests/stress/op_bitxor.js: Added.
* tests/stress/op_lshift.js: Added.
* tests/stress/op_rshift.js: Added.
* tests/stress/op_urshift.js: Added.
* tests/stress/resources/binary-op-test.js: Added.
- Common code for generating and running tests.
2015-11-19 Caitlin Potter <caitp@igalia.com>
[JSC] Fix AssignmentElement parsing
https://bugs.webkit.org/show_bug.cgi?id=151026
Reviewed by Geoffrey Garen.
When parsing an AssignmentPattern, any LeftHandSideExpression which
is a valid assignment target is acceptable.
Additionally, this change minimizes the amount of time spent
re-parsing ObjectLiteral and ArrayLiterals, by parsing as an
Expression first (the common case), and re-parsing only if the
result is a valid ObjectLiteral or ArrayLiteral followed by an `=`,
or if an error specifically indicates that the expression could
have been parsed as an AssignmentPattern.
* bytecompiler/NodesCodegen.cpp:
(JSC::AssignmentElementNode::collectBoundIdentifiers):
(JSC::AssignmentElementNode::bindValue):
(JSC::AssignmentElementNode::toString):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::isAssignmentLocation):
(JSC::ASTBuilder::isObjectLiteral):
(JSC::ASTBuilder::isArrayLiteral):
(JSC::ASTBuilder::isObjectOrArrayLiteral):
(JSC::ASTBuilder::createAssignmentElement):
* parser/NodeConstructors.h:
(JSC::AssignmentElementNode::AssignmentElementNode):
* parser/Nodes.h:
(JSC::ExpressionNode::isObjectLiteral):
(JSC::ExpressionNode::isArrayLiteral):
(JSC::AssignmentElementNode::assignmentTarget):
(JSC::AssignmentElementNode::divotStart):
(JSC::AssignmentElementNode::divotEnd):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::Parser):
(JSC::Parser<LexerType>::createAssignmentElement):
(JSC::Parser<LexerType>::parseBindingOrAssignmentElement):
(JSC::Parser<LexerType>::parseAssignmentElement):
(JSC::Parser<LexerType>::parseDestructuringPattern):
(JSC::Parser<LexerType>::parseAssignmentExpression):
(JSC::Parser<LexerType>::parseProperty):
* parser/Parser.h:
(JSC::Parser::ExpressionErrorClassifier::ExpressionErrorClassifier):
(JSC::Parser::ExpressionErrorClassifier::~ExpressionErrorClassifier):
(JSC::Parser::ExpressionErrorClassifier::classifyExpressionError):
(JSC::Parser::ExpressionErrorClassifier::indicatesPossiblePattern):
(JSC::Parser::classifyExpressionError):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::operatorStackPop):
* tests/es6.yaml:
* tests/es6/destructuring_assignment_non_simple_target.js: Added.
(test.):
(test):
* tests/es6/destructuring_initializer_scoping.js: Added.
(test.tester):
* tests/stress/destructuring-assignment-syntax.js: Added.
(testSyntax):
(testSyntaxError):
* tests/stress/rest-elements.js:
(shouldThrow): Deleted.
2015-11-19 Filip Pizlo <fpizlo@apple.com>
FTL->B3 lowering should support integer comparisons with the opcode abstracted and a few other things
https://bugs.webkit.org/show_bug.cgi?id=151463
Reviewed by Geoffrey Garen.
* ftl/FTLB3Output.h:
(JSC::FTL::Output::signExt):
(JSC::FTL::Output::zeroExt):
(JSC::FTL::Output::zeroExtPtr):
(JSC::FTL::Output::fpToInt):
(JSC::FTL::Output::fpToUInt):
(JSC::FTL::Output::fpToInt32):
(JSC::FTL::Output::baseIndex):
(JSC::FTL::Output::absolute):
(JSC::FTL::Output::load32NonNegative):
(JSC::FTL::Output::equal):
(JSC::FTL::Output::notEqual):
(JSC::FTL::Output::above):
(JSC::FTL::Output::lessThan):
(JSC::FTL::Output::lessThanOrEqual):
(JSC::FTL::Output::doubleEqual):
(JSC::FTL::Output::doubleNotEqualOrUnordered):
(JSC::FTL::Output::doubleLessThan):
(JSC::FTL::Output::icmp): Deleted.
(JSC::FTL::Output::fcmp): Deleted.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileCompareEq):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCompareLess):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCompareLessEq):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCompareGreater):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCompareGreaterEq):
(JSC::FTL::DFG::LowerDFGToLLVM::compileLogicalNot):
(JSC::FTL::DFG::LowerDFGToLLVM::baseIndex):
(JSC::FTL::DFG::LowerDFGToLLVM::compare):
(JSC::FTL::DFG::LowerDFGToLLVM::speculateTruthyObject):
(JSC::FTL::DFG::LowerDFGToLLVM::nonSpeculativeCompare):
2015-11-19 Benjamin Poulain <bpoulain@apple.com>
[JSC] When the iterated allocator is forced to spill, nuke the Moves that were already proven to be useless
https://bugs.webkit.org/show_bug.cgi?id=151461
Reviewed by Filip Pizlo.
Previously, when we had to spill, we were just inserting new Spill() and Fill()
in code while everything else remained identical.
Coalescing moves is a big part of the algorithm and takes a non-trivial time.
Since we were never removing Moves until reaching a successful coloring, we were
paying that cost with every single iteration.
With this patch, I keep a copy of the coalescing aliases when we make the first
potential spill decision. Before doing that, we have only simplified and coalesced
vertices that are provably colorable regardless of the other vertices' colors
(because their degree is <K, potentially after other edges were removed by simplification).
If we end up actually spilling, I use the old aliases to simplify the blocks if possible.
This is a 5% progression on "testComplex(64, 384)".
* b3/air/AirIteratedRegisterCoalescing.cpp:
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::getAliasWhenSpilling):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::coalesce):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::selectSpill):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::assignColors):
(JSC::B3::Air::addSpillAndFillToProgram):
(JSC::B3::Air::iteratedRegisterCoalescingOnType):
(JSC::B3::Air::iteratedRegisterCoalescing):
2015-11-19 Filip Pizlo <fpizlo@apple.com>
Fix FTL->B3 lowering of Phi
https://bugs.webkit.org/show_bug.cgi?id=151460
Reviewed by Geoffrey Garen.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compilePhi):
2015-11-19 Filip Pizlo <fpizlo@apple.com>
FTL->B3 lowering should support lazy slow paths, patchpoints, all integer comparisons, and more load/stores
https://bugs.webkit.org/show_bug.cgi?id=151459
Reviewed by Benjamin Poulain.
* ftl/FTLB3Output.h:
(JSC::FTL::Output::absolute):
(JSC::FTL::Output::load8SignExt32):
(JSC::FTL::Output::load8ZeroExt32):
(JSC::FTL::Output::load16SignExt32):
(JSC::FTL::Output::load16ZeroExt32):
(JSC::FTL::Output::load32):
(JSC::FTL::Output::load64):
(JSC::FTL::Output::loadPtr):
(JSC::FTL::Output::loadDouble):
(JSC::FTL::Output::store32):
(JSC::FTL::Output::store64):
(JSC::FTL::Output::storePtr):
(JSC::FTL::Output::storeDouble):
(JSC::FTL::Output::ascribeRange):
(JSC::FTL::Output::nonNegative32):
(JSC::FTL::Output::load32NonNegative):
(JSC::FTL::Output::icmp):
(JSC::FTL::Output::equal):
(JSC::FTL::Output::notEqual):
(JSC::FTL::Output::above):
(JSC::FTL::Output::aboveOrEqual):
(JSC::FTL::Output::below):
(JSC::FTL::Output::belowOrEqual):
(JSC::FTL::Output::greaterThan):
(JSC::FTL::Output::greaterThanOrEqual):
(JSC::FTL::Output::lessThan):
(JSC::FTL::Output::lessThanOrEqual):
(JSC::FTL::Output::fcmp):
(JSC::FTL::Output::doubleEqual):
(JSC::FTL::Output::speculateMul):
(JSC::FTL::Output::patchpoint):
(JSC::FTL::Output::trap):
(JSC::FTL::Output::anchor):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
2015-11-19 Filip Pizlo <fpizlo@apple.com>
FTL->B3 lowering should support absolute(), double comparisons, and intToDouble()
https://bugs.webkit.org/show_bug.cgi?id=151457
Reviewed by Benjamin Poulain.
* ftl/FTLB3Output.h:
(JSC::FTL::Output::fpToInt32):
(JSC::FTL::Output::fpToUInt32):
(JSC::FTL::Output::intToFP):
(JSC::FTL::Output::intToDouble):
(JSC::FTL::Output::unsignedToFP):
(JSC::FTL::Output::unsignedToDouble):
(JSC::FTL::Output::intCast):
(JSC::FTL::Output::baseIndex):
(JSC::FTL::Output::absolute):
(JSC::FTL::Output::load8SignExt32):
(JSC::FTL::Output::load8ZeroExt32):
(JSC::FTL::Output::lessThanOrEqual):
(JSC::FTL::Output::fcmp):
(JSC::FTL::Output::doubleEqual):
(JSC::FTL::Output::doubleNotEqualOrUnordered):
(JSC::FTL::Output::doubleLessThan):
(JSC::FTL::Output::doubleLessThanOrEqual):
(JSC::FTL::Output::doubleGreaterThan):
(JSC::FTL::Output::doubleGreaterThanOrEqual):
(JSC::FTL::Output::doubleEqualOrUnordered):
(JSC::FTL::Output::doubleNotEqual):
(JSC::FTL::Output::doubleLessThanOrUnordered):
(JSC::FTL::Output::doubleLessThanOrEqualOrUnordered):
(JSC::FTL::Output::doubleGreaterThanOrUnordered):
(JSC::FTL::Output::doubleGreaterThanOrEqualOrUnordered):
(JSC::FTL::Output::isZero32):
(JSC::FTL::Output::notZero32):
2015-11-19 Filip Pizlo <fpizlo@apple.com>
FTL->B3 lowering should support checked int math
https://bugs.webkit.org/show_bug.cgi?id=151451
Reviewed by Saam Barati.
Adds lowering of ArithAdd/Sub/Mul to CheckAdd/Sub/Mul. Includes a nice refactoring of the OSR exit
code that made this a lot easier. Also needed to implement a few other ops in FTL::Output.
I ended up renaming "check" to "speculate" in FTL::Output, because it already had a thing called
"check". The FTL terminology for side-exit is "speculate", so I think that this is appropriate.
* ftl/FTLB3Output.h:
(JSC::FTL::Output::sensibleDoubleToInt):
(JSC::FTL::Output::signExt):
(JSC::FTL::Output::zeroExt):
(JSC::FTL::Output::zeroExtPtr):
(JSC::FTL::Output::fpToInt):
(JSC::FTL::Output::fpToUInt):
(JSC::FTL::Output::unsignedToFP):
(JSC::FTL::Output::unsignedToDouble):
(JSC::FTL::Output::intCast):
(JSC::FTL::Output::castToInt32):
(JSC::FTL::Output::fpCast):
(JSC::FTL::Output::intToPtr):
(JSC::FTL::Output::ptrToInt):
(JSC::FTL::Output::unreachable):
(JSC::FTL::Output::speculate):
(JSC::FTL::Output::speculateAdd):
(JSC::FTL::Output::speculateSub):
(JSC::FTL::Output::speculateMul):
(JSC::FTL::Output::trap):
(JSC::FTL::Output::check): Deleted.
* ftl/FTLJITFinalizer.cpp:
(JSC::FTL::JITFinalizer::finalizeFunction):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithMul):
(JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
(JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation):
(JSC::FTL::DFG::LowerDFGToLLVM::emitOSRExitCall):
(JSC::FTL::DFG::LowerDFGToLLVM::buildExitArguments):
2015-11-19 Mark Lam <mark.lam@apple.com>
JIT snippet generator JumpLists should be returned as references.
https://bugs.webkit.org/show_bug.cgi?id=151445
Reviewed by Gavin Barraclough.
The JumpLists were being returned by value. As a result, new jumps added to
them in the client are actually added to a temporary copy and promptly discarded.
Those jumps never get linked, resulting in infinite loops in DFG generated code
that used the snippets.
* jit/JITAddGenerator.h:
(JSC::JITAddGenerator::endJumpList):
(JSC::JITAddGenerator::slowPathJumpList):
* jit/JITMulGenerator.h:
(JSC::JITMulGenerator::endJumpList):
(JSC::JITMulGenerator::slowPathJumpList):
* jit/JITSubGenerator.h:
(JSC::JITSubGenerator::endJumpList):
(JSC::JITSubGenerator::slowPathJumpList):
2015-11-19 Csaba Osztrogonác <ossy@webkit.org>
Unreviewed CLOOP buildfix after r192624.
* runtime/MemoryStatistics.cpp:
(JSC::globalMemoryStatistics):
* runtime/MemoryStatistics.h:
2015-11-19 Csaba Osztrogonác <ossy@webkit.org>
Remove unused LLVM API functions
https://bugs.webkit.org/show_bug.cgi?id=151184
Reviewed by Filip Pizlo.
* ftl/FTLAbbreviations.h:
(JSC::FTL::typeOf): Deleted.
(JSC::FTL::getElementType): Deleted.
(JSC::FTL::getNamedFunction): Deleted.
(JSC::FTL::removeFunctionAttr): Deleted.
(JSC::FTL::getLinkage): Deleted.
(JSC::FTL::setVisibility): Deleted.
(JSC::FTL::isDeclaration): Deleted.
(JSC::FTL::linkModules): Deleted.
(JSC::FTL::getValueName): Deleted.
(JSC::FTL::getNamedGlobal): Deleted.
(JSC::FTL::getFirstGlobal): Deleted.
(JSC::FTL::getNextGlobal): Deleted.
(JSC::FTL::createMemoryBufferWithContentsOfFile): Deleted.
(JSC::FTL::parseBitcodeInContext): Deleted.
(JSC::FTL::disposeMemoryBuffer): Deleted.
(JSC::FTL::getParamTypes): Deleted.
(JSC::FTL::constIntToPtr): Deleted.
(JSC::FTL::constBitCast): Deleted.
* llvm/LLVMAPIFunctions.h:
2015-11-19 Gyuyoung Kim <gyuyoung.kim@webkit.org>
Remove unnecessary PLATFORM(EFL) macro in globalMemoryStatistics()
https://bugs.webkit.org/show_bug.cgi?id=151301
Reviewed by Csaba Osztrogonác.
EXECUTABLE_ALLOCATOR_FIXED is enabled on EFL port. So we don't need to keep
PLATFORM(EFL) macro anymore. Besides ENABLE(EXECUTABLE_ALLOCATOR_FIXED) guard
isn't related with ExecutableAllocator::committedByteCount() closely. So this patch
removes it as well.
* runtime/MemoryStatistics.cpp:
(JSC::globalMemoryStatistics):
2015-11-19 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add bitwise Double-Int conversion to B3
https://bugs.webkit.org/show_bug.cgi?id=151432
Reviewed by Filip Pizlo.
This is needed for boxing/unboxing doubles.
* b3/B3Const64Value.cpp:
(JSC::B3::Const64Value::bitwiseCastConstant):
* b3/B3Const64Value.h:
* b3/B3ConstDoubleValue.cpp:
(JSC::B3::ConstDoubleValue::bitwiseCastConstant):
* b3/B3ConstDoubleValue.h:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Opcode.cpp:
(WTF::printInternal):
* b3/B3Opcode.h:
* b3/B3ReduceStrength.cpp:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::bitwiseCastConstant):
(JSC::B3::Value::effects):
(JSC::B3::Value::typeFor):
* b3/B3Value.h:
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testDoubleArgToInt64BitwiseCast):
(JSC::B3::testDoubleImmToInt64BitwiseCast):
(JSC::B3::testTwoBitwiseCastOnDouble):
(JSC::B3::testBitwiseCastOnDoubleInMemory):
(JSC::B3::testInt64BArgToDoubleBitwiseCast):
(JSC::B3::testInt64BImmToDoubleBitwiseCast):
(JSC::B3::testTwoBitwiseCastOnInt64):
(JSC::B3::testBitwiseCastOnInt64InMemory):
(JSC::B3::int64Operands):
(JSC::B3::run):
* ftl/FTLB3Output.h:
(JSC::FTL::Output::bitCast):
2015-11-18 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add some missing load/store to FTLB3Output
https://bugs.webkit.org/show_bug.cgi?id=151427
Reviewed by Filip Pizlo.
* ftl/FTLB3Output.cpp:
(JSC::FTL::Output::load8SignExt32):
(JSC::FTL::Output::load8ZeroExt32):
(JSC::FTL::Output::load16SignExt32):
(JSC::FTL::Output::load16ZeroExt32):
(JSC::FTL::Output::loadFloatToDouble):
* ftl/FTLB3Output.h:
(JSC::FTL::Output::load32):
(JSC::FTL::Output::loadPtr):
(JSC::FTL::Output::loadDouble):
(JSC::FTL::Output::load8SignExt32): Deleted.
(JSC::FTL::Output::load8ZeroExt32): Deleted.
(JSC::FTL::Output::load16SignExt32): Deleted.
(JSC::FTL::Output::load16ZeroExt32): Deleted.
(JSC::FTL::Output::loadFloatToDouble): Deleted.
2015-11-18 Benjamin Poulain <benjamin@webkit.org>
Fix typos in r192605
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileUpsilon):
2015-11-18 Filip Pizlo <fpizlo@apple.com> and Benjamin Poulain <bpoulain@apple.com>
FTL should be able to compile a small function with B3
https://bugs.webkit.org/show_bug.cgi?id=151423
Reviewed by Filip Pizlo.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* ftl/FTLAbbreviatedTypes.h:
* ftl/FTLB3Output.cpp:
(JSC::FTL::Output::Output):
(JSC::FTL::Output::~Output):
(JSC::FTL::Output::initialize):
(JSC::FTL::Output::appendTo):
(JSC::FTL::Output::lockedStackSlot):
(JSC::FTL::Output::load):
(JSC::FTL::Output::store):
(JSC::FTL::Output::branch):
* ftl/FTLB3Output.h:
(JSC::FTL::Output::newBlock):
(JSC::FTL::Output::setOrigin):
(JSC::FTL::Output::origin):
(JSC::FTL::Output::framePointer):
(JSC::FTL::Output::constBool):
(JSC::FTL::Output::constInt32):
(JSC::FTL::Output::constIntPtr):
(JSC::FTL::Output::constInt64):
(JSC::FTL::Output::constDouble):
(JSC::FTL::Output::upsilon):
(JSC::FTL::Output::phi):
(JSC::FTL::Output::add):
(JSC::FTL::Output::sub):
(JSC::FTL::Output::mul):
(JSC::FTL::Output::neg):
(JSC::FTL::Output::doubleAdd):
(JSC::FTL::Output::doubleSub):
(JSC::FTL::Output::doubleMul):
(JSC::FTL::Output::doubleDiv):
(JSC::FTL::Output::doubleNeg):
(JSC::FTL::Output::bitAnd):
(JSC::FTL::Output::bitOr):
(JSC::FTL::Output::bitXor):
(JSC::FTL::Output::shl):
(JSC::FTL::Output::aShr):
(JSC::FTL::Output::lShr):
(JSC::FTL::Output::load64):
(JSC::FTL::Output::store32):
(JSC::FTL::Output::store64):
(JSC::FTL::Output::storePtr):
(JSC::FTL::Output::storeDouble):
(JSC::FTL::Output::addPtr):
(JSC::FTL::Output::address):
(JSC::FTL::Output::below):
(JSC::FTL::Output::isZero32):
(JSC::FTL::Output::notZero32):
(JSC::FTL::Output::isZero64):
(JSC::FTL::Output::notZero64):
(JSC::FTL::Output::isNull):
(JSC::FTL::Output::notNull):
(JSC::FTL::Output::testIsZero32):
(JSC::FTL::Output::testNonZero32):
(JSC::FTL::Output::testIsZero64):
(JSC::FTL::Output::testNonZero64):
(JSC::FTL::Output::testIsZeroPtr):
(JSC::FTL::Output::testNonZeroPtr):
(JSC::FTL::Output::call):
(JSC::FTL::Output::operation):
(JSC::FTL::Output::jump):
(JSC::FTL::Output::branch):
(JSC::FTL::Output::ret):
(JSC::FTL::Output::unreachable):
(JSC::FTL::Output::check):
(JSC::FTL::Output::anchor):
(JSC::FTL::Output::addIncomingToPhi):
(JSC::FTL::Output::~Output): Deleted.
(JSC::FTL::Output::appendTo): Deleted.
(JSC::FTL::Output::param): Deleted.
(JSC::FTL::Output::load): Deleted.
(JSC::FTL::Output::store): Deleted.
(JSC::FTL::Output::store16): Deleted.
* ftl/FTLCommonValues.cpp:
(JSC::FTL::CommonValues::CommonValues):
(JSC::FTL::CommonValues::initializeConstants):
* ftl/FTLCommonValues.h:
* ftl/FTLJITFinalizer.cpp:
(JSC::FTL::JITFinalizer::finalizeFunction):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::LowerDFGToLLVM):
(JSC::FTL::DFG::LowerDFGToLLVM::lower):
(JSC::FTL::DFG::LowerDFGToLLVM::createPhiVariables):
(JSC::FTL::DFG::LowerDFGToLLVM::compileBlock):
(JSC::FTL::DFG::LowerDFGToLLVM::safelyInvalidateAfterTermination):
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
(JSC::FTL::DFG::LowerDFGToLLVM::compileUpsilon):
(JSC::FTL::DFG::LowerDFGToLLVM::compilePhi):
(JSC::FTL::DFG::LowerDFGToLLVM::compileToThis):
(JSC::FTL::DFG::LowerDFGToLLVM::compileValueAdd):
(JSC::FTL::DFG::LowerDFGToLLVM::compileStrCat):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArrayifyToStructure):
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetById):
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetIndexedPropertyStorage):
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutByVal):
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutAccessorById):
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutGetterSetterById):
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutAccessorByVal):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArrayPush):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArrayPop):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCreateActivation):
(JSC::FTL::DFG::LowerDFGToLLVM::compileNewFunction):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCreateScopedArguments):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCreateClonedArguments):
(JSC::FTL::DFG::LowerDFGToLLVM::compileNewArray):
(JSC::FTL::DFG::LowerDFGToLLVM::compileNewArrayBuffer):
(JSC::FTL::DFG::LowerDFGToLLVM::compileNewArrayWithSize):
(JSC::FTL::DFG::LowerDFGToLLVM::compileToStringOrCallStringConstructor):
(JSC::FTL::DFG::LowerDFGToLLVM::compileToPrimitive):
(JSC::FTL::DFG::LowerDFGToLLVM::compileStringCharAt):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
(JSC::FTL::DFG::LowerDFGToLLVM::compileLoadVarargs):
(JSC::FTL::DFG::LowerDFGToLLVM::compileSwitch):
(JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
(JSC::FTL::DFG::LowerDFGToLLVM::compileIn):
(JSC::FTL::DFG::LowerDFGToLLVM::compileHasIndexedProperty):
(JSC::FTL::DFG::LowerDFGToLLVM::compileHasGenericProperty):
(JSC::FTL::DFG::LowerDFGToLLVM::compileHasStructureProperty):
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetDirectPname):
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetPropertyEnumerator):
(JSC::FTL::DFG::LowerDFGToLLVM::compileToIndexString):
(JSC::FTL::DFG::LowerDFGToLLVM::didOverflowStack):
(JSC::FTL::DFG::LowerDFGToLLVM::allocatePropertyStorage):
(JSC::FTL::DFG::LowerDFGToLLVM::reallocatePropertyStorage):
(JSC::FTL::DFG::LowerDFGToLLVM::getById):
(JSC::FTL::DFG::LowerDFGToLLVM::nonSpeculativeCompare):
(JSC::FTL::DFG::LowerDFGToLLVM::contiguousPutByValOutOfBounds):
(JSC::FTL::DFG::LowerDFGToLLVM::switchStringSlow):
(JSC::FTL::DFG::LowerDFGToLLVM::doubleToInt32):
(JSC::FTL::DFG::LowerDFGToLLVM::sensibleDoubleToInt32):
(JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
(JSC::FTL::DFG::LowerDFGToLLVM::jsValueToStrictInt52):
(JSC::FTL::DFG::LowerDFGToLLVM::doubleToStrictInt52):
(JSC::FTL::DFG::LowerDFGToLLVM::vmCall):
(JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
(JSC::FTL::DFG::LowerDFGToLLVM::lowBlock):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
(JSC::FTL::DFG::LowerDFGToLLVM::callStackmap):
(JSC::FTL::DFG::LowerDFGToLLVM::probe):
(JSC::FTL::DFG::LowerDFGToLLVM::crash):
(JSC::FTL::lowerDFGToLLVM):
(JSC::FTL::DFG::LowerDFGToLLVM::vmCallNoExceptions): Deleted.
* ftl/FTLOutput.cpp:
(JSC::FTL::Output::sensibleDoubleToInt):
* ftl/FTLOutput.h:
(JSC::FTL::Output::ceil64):
(JSC::FTL::Output::ctlz32):
(JSC::FTL::Output::addWithOverflow32):
(JSC::FTL::Output::subWithOverflow32):
(JSC::FTL::Output::mulWithOverflow32):
(JSC::FTL::Output::addWithOverflow64):
(JSC::FTL::Output::subWithOverflow64):
(JSC::FTL::Output::mulWithOverflow64):
(JSC::FTL::Output::doubleAbs):
(JSC::FTL::Output::doubleSin):
(JSC::FTL::Output::doubleCos):
(JSC::FTL::Output::doublePow):
(JSC::FTL::Output::doublePowi):
(JSC::FTL::Output::doubleSqrt):
(JSC::FTL::Output::doubleLog):
(JSC::FTL::Output::call):
(JSC::FTL::Output::trap):
* ftl/FTLState.cpp:
(JSC::FTL::State::State): Deleted.
* ftl/FTLState.h:
* ftl/FTLWeight.h:
(JSC::FTL::Weight::frequencyClass):
2015-11-18 Saam barati <sbarati@apple.com>
There is a bug when default parameter values are mixed with destructuring parameter values
https://bugs.webkit.org/show_bug.cgi?id=151369
Reviewed by Geoffrey Garen and Mark Lam.
Relanding this after a rollout.
This patch changes our parser to no longer declare destructuring
parameters as "var"s. This is a weird bug that just happened
to work in a world without default parameter values. In a world with
default parameter values this is just completely wrong. It would
incorrectly transform this program:
```function foo(a = function() { b = 40; }, {b}) { a(); return b; }; foo(undefined, {b: 42}); // Should return 40```
into
```function foo(a = function() { b = 40; }, {b}) { var b; a(); return b; }; foo(undefined, {b:42}); // Returns 42, not 40.```
Which is wrong because we end up with two distinct bindings of "b" when
there should only be one.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseVariableDeclarationList):
(JSC::Parser<LexerType>::createBindingPattern):
(JSC::Parser<LexerType>::parseDestructuringPattern):
* parser/Parser.h:
(JSC::Scope::declareParameter):
(JSC::Scope::getUsedVariables):
(JSC::Parser::strictMode):
(JSC::Parser::isValidStrictMode):
(JSC::Parser::declareParameter):
(JSC::Parser::breakIsValid):
(JSC::Scope::declareBoundParameter): Deleted.
(JSC::Parser::declareBoundParameter): Deleted.
* tests/stress/es6-default-parameters.js:
2015-11-18 Mark Lam <mark.lam@apple.com>
Snippefy op_mul for the baseline JIT.
https://bugs.webkit.org/show_bug.cgi?id=151393
Reviewed by Geoffrey Garen.
Benchmarks shows that perf is neutral on x86 and x86_64 with the DFG enabled.
With the DFG disabled (relying on the baseline JIT for perf), LongSpider
3d-morph shows a 7.6% regression. However, there are other benchmarks that shows
a progression e.g. on Kraken, audio-beat-detection and audio-fft.
Upon inspection of the generated code for 3d-morph, the only differences is the
added use of a scratch register for the result as well as a jump around the
code that handles double types. It does not look like we're generating bad code.
I'll consider the perf acceptable in aggregate.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generate):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::boxInt32):
* jit/IntrinsicEmitter.cpp:
(JSC::AccessCase::emitIntrinsicGetter):
- Changed AssemblyHelpers::boxInt32() to take a TagRegistersMode.
The pre-existing boxInt32() always assume that the tag registers are not
available. Since we should assume we have tag registers by default, I also
changed all the other clients to explicitly specify a more of
DoNotHaveTagRegisters. That is except for the snippet generators that do have
the tag registers.
* jit/JIT.h:
* jit/JITArithmetic.cpp:
(JSC::JIT::compileBinaryArithOpSlowCase):
(JSC::JIT::emit_op_div):
(JSC::JIT::emitSlow_op_add):
(JSC::JIT::emit_op_mul):
(JSC::JIT::emitSlow_op_mul):
(JSC::JIT::emit_op_sub):
(JSC::JIT::compileBinaryArithOp): Deleted.
* jit/JITArithmetic32_64.cpp:
(JSC::JIT::emitBinaryDoubleOp):
(JSC::JIT::emit_op_div):
(JSC::JIT::emit_op_mul): Deleted.
(JSC::JIT::emitSlow_op_mul): Deleted.
* jit/JITMulGenerator.cpp: Added.
(JSC::JITMulGenerator::generateFastPath):
* jit/JITMulGenerator.h: Added.
(JSC::JITMulGenerator::JITMulGenerator):
(JSC::JITMulGenerator::didEmitFastPath):
(JSC::JITMulGenerator::endJumpList):
(JSC::JITMulGenerator::slowPathJumpList):
* tests/stress/op_mul.js: Added.
(o1.valueOf):
(generateScenarios):
(printScenarios):
(testCases.func):
(func):
(initializeTestCases):
(stringifyIfNeeded):
(isIdentical):
(runTest):
- Tests that JIT op_mul results are equivalent to the expected values as
defined by the LLINT.
2015-11-18 Mark Lam <mark.lam@apple.com>
Remove some unnecessary jumps in snippet code.
https://bugs.webkit.org/show_bug.cgi?id=151415
Reviewed by Geoffrey Garen.
Previously, the snippet generators always emit a jump at the end of the fast
path. In the baseline JIT and FTL, this results in a jump to the very next
instruction. I've change it to assume that the fast path will just fall thru,
and let the client decide instead if it wants/needs a jump or not after the fast
path.
I also changed the generators to provide a didEmitFastPath() query explicitly
declare if they actually generated the fast path, instead of having the client
infer it from an empty endJumpList.
Benchmarks show that perf is neutral with this change (tested on x86_64).
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueAdd):
(JSC::DFG::SpeculativeJIT::compileArithSub):
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* jit/JITAddGenerator.cpp:
(JSC::JITAddGenerator::generateFastPath):
* jit/JITAddGenerator.h:
(JSC::JITAddGenerator::didEmitFastPath):
(JSC::JITAddGenerator::endJumpList):
(JSC::JITAddGenerator::slowPathJumpList):
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_add):
(JSC::JIT::emit_op_sub):
* jit/JITSubGenerator.cpp:
(JSC::JITSubGenerator::generateFastPath):
* jit/JITSubGenerator.h:
(JSC::JITSubGenerator::didEmitFastPath):
(JSC::JITSubGenerator::endJumpList):
(JSC::JITSubGenerator::slowPathJumpList):
2015-11-18 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r192436 and r192586.
https://bugs.webkit.org/show_bug.cgi?id=151417
Caused a hang in the inspector and a crash @ google.com.
(Requested by saamyjoon on #webkit).
Reverted changesets:
"Allow any LeftHandSideExpression as a valid
AssignmentElement"
https://bugs.webkit.org/show_bug.cgi?id=151026
http://trac.webkit.org/changeset/192436
"There is a bug when default parameter values are mixed with
destructuring parameter values"
https://bugs.webkit.org/show_bug.cgi?id=151369
http://trac.webkit.org/changeset/192586
2015-11-17 Keith Miller <keith_miller@apple.com>
[JSC] TailCalls should not trigger assertion failures when running with the jsc profiler on.
https://bugs.webkit.org/show_bug.cgi?id=151359
Reviewed by Geoffrey Garen.
If we have the profiler on when parsing tail calls in the dfg we would emit a CountExecutions node
following a TailCall node as our bytecode for tail calls always emits a op_ret following an op_tail_call.
This trips assertions that no nodes follow a terminal in a basic block. This patch fixes this issue by
not emiting a CountExecutions when we have a tail call that is terminal i.e. the tail caller is not
inlined into another function or the tail caller is inlined but is in tail position itself.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleCall):
(JSC::DFG::ByteCodeParser::handleVarargsCall):
(JSC::DFG::ByteCodeParser::parseBlock):
* tests/stress/tail-call-profiler.js: Added.
(tail):
(inlineTail):
(inlineTailVarArgs):
(inlineTailTernary):
(body):
2015-11-18 Benjamin Poulain <bpoulain@apple.com>
[JSC] Make LBasicBlock into an alias for B3::BasicBlock. #ifdef anything that does not compile
https://bugs.webkit.org/show_bug.cgi?id=151381
Reviewed by Filip Pizlo.
* JavaScriptCore.xcodeproj/project.pbxproj:
* ftl/FTLAbbreviatedTypes.h:
* ftl/FTLAbbreviations.h:
* ftl/FTLAbstractHeap.cpp:
(JSC::FTL::AbstractHeap::decorateInstruction):
(JSC::FTL::IndexedAbstractHeap::IndexedAbstractHeap):
* ftl/FTLAbstractHeap.h:
(JSC::FTL::AbstractHeap::AbstractHeap):
* ftl/FTLAbstractHeapRepository.cpp:
(JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLB3Output.h:
(JSC::FTL::Output::newBlock):
(JSC::FTL::Output::insertNewBlocksBefore):
(JSC::FTL::Output::addIncomingToPhi):
(JSC::FTL::Output::Output): Deleted.
(JSC::FTL::Output::initialize): Deleted.
* ftl/FTLCommonValues.cpp:
(JSC::FTL::CommonValues::CommonValues):
* ftl/FTLCommonValues.h:
* ftl/FTLIntrinsicRepository.cpp:
* ftl/FTLIntrinsicRepository.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::LowerDFGToLLVM):
(JSC::FTL::DFG::LowerDFGToLLVM::lower):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCreateDirectArguments):
(JSC::FTL::DFG::LowerDFGToLLVM::compileNewArrayWithSize):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
(JSC::FTL::DFG::LowerDFGToLLVM::compileForwardVarargs):
(JSC::FTL::DFG::LowerDFGToLLVM::compileIn):
(JSC::FTL::DFG::LowerDFGToLLVM::compileInstanceOf):
(JSC::FTL::DFG::LowerDFGToLLVM::getById):
(JSC::FTL::DFG::LowerDFGToLLVM::allocateCell):
(JSC::FTL::DFG::LowerDFGToLLVM::buildSwitch):
(JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
(JSC::FTL::DFG::LowerDFGToLLVM::crash):
* ftl/FTLOutput.cpp:
(JSC::FTL::Output::Output):
* ftl/FTLOutput.h:
(JSC::FTL::Output::addIncomingToPhi):
* ftl/FTLState.cpp:
(JSC::FTL::State::dumpState):
* ftl/FTLValueRange.cpp:
(JSC::FTL::ValueRange::decorateInstruction):
* ftl/FTLValueRange.h:
(JSC::FTL::ValueRange::ValueRange):
2015-11-18 Filip Pizlo <fpizlo@apple.com>
Implement the B3 equivalent of FTLCompile
https://bugs.webkit.org/show_bug.cgi?id=151370
Reviewed by Benjamin Poulain.
This adds a B3 version of FTLCompile and gets the data structures related to installing an FTL
compilation (i.e. the finalizer and JITCode) to be aware of B3. That requires stubbing a lot of stuff
out and also simplifying a lot of code around having everything inside a single contiguous chunk of
JIT code rather than some opaque JIT code handles plus miscellaneous side-codes. This compiles but
crashes because lowering isn't done yet.
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::addDataSection):
(JSC::B3::Procedure::calleeSaveRegisters):
(JSC::B3::Procedure::addValueIndex):
* b3/B3Procedure.h:
(JSC::B3::Procedure::code):
* ftl/FTLB3Compile.cpp: Added.
(JSC::FTL::compile):
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLExceptionHandlerManager.cpp:
(JSC::FTL::ExceptionHandlerManager::callOperationExceptionTarget):
(JSC::FTL::ExceptionHandlerManager::lazySlowPathExceptionTarget):
(JSC::FTL::ExceptionHandlerManager::getByIdOSRExit):
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::~JITCode):
(JSC::FTL::JITCode::initializeB3Code):
(JSC::FTL::JITCode::initializeExitThunks):
(JSC::FTL::JITCode::addDataSection):
(JSC::FTL::JITCode::initializeAddressForCall):
(JSC::FTL::JITCode::initializeArityCheckEntrypoint):
(JSC::FTL::JITCode::addressForCall):
(JSC::FTL::JITCode::contains):
(JSC::FTL::JITCode::exitThunks):
(JSC::FTL::JITCode::ftl):
* ftl/FTLJITCode.h:
(JSC::FTL::JITCode::b3Code):
(JSC::FTL::JITCode::handles):
(JSC::FTL::JITCode::dataSections):
* ftl/FTLJITFinalizer.cpp:
(JSC::FTL::JITFinalizer::codeSize):
(JSC::FTL::JITFinalizer::finalizeFunction):
* ftl/FTLJITFinalizer.h:
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLOSRExit.cpp:
(JSC::FTL::OSRExit::codeLocationForRepatch):
(JSC::FTL::OSRExit::gatherRegistersToSpillForCallIfException):
2015-11-18 Saam barati <sbarati@apple.com>
There is a bug when default parameter values are mixed with destructuring parameter values
https://bugs.webkit.org/show_bug.cgi?id=151369
Reviewed by Geoffrey Garen and Mark Lam.
This patch changes our parser to no longer declare destructuring
parameters as "var"s. This is a weird bug that just happened
to work in a world without default parameter values. In a world with
default parameter values this is just completely wrong. It would
incorrectly transform this program:
```function foo(a = function() { b = 40; }, {b}) { a(); return b; }; foo(undefined, {b: 42}); // Should return 40```
into
```function foo(a = function() { b = 40; }, {b}) { var b; a(); return b; }; foo(undefined, {b:42}); // Returns 42, not 40.```
Which is wrong because we end up with two distinct bindings of "b" when
there should only be one.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseVariableDeclarationList):
(JSC::Parser<LexerType>::createBindingPattern):
(JSC::Parser<LexerType>::parseDestructuringPattern):
* parser/Parser.h:
(JSC::Scope::declareParameter):
(JSC::Scope::getUsedVariables):
(JSC::Parser::strictMode):
(JSC::Parser::isValidStrictMode):
(JSC::Parser::declareParameter):
(JSC::Parser::breakIsValid):
(JSC::Scope::declareBoundParameter): Deleted.
(JSC::Parser::declareBoundParameter): Deleted.
* tests/stress/es6-default-parameters.js:
2015-11-17 Benjamin Poulain <bpoulain@apple.com>
[JSC] Untangle the dependencies on FTLAbbreviations a bit
https://bugs.webkit.org/show_bug.cgi?id=151375
Reviewed by Geoffrey Garen.
FTLAbbreviations was included in many places but in most cases
we just need the Abbreviated types. Update the #include accordingly.
Also remove the IntrinsicRepository dependency from the B3Output.
* ftl/FTLAbstractHeap.cpp:
* ftl/FTLAbstractHeap.h:
* ftl/FTLAbstractHeapRepository.cpp:
* ftl/FTLB3Output.h:
(JSC::FTL::Output::Output):
(JSC::FTL::Output::stackmapIntrinsic):
(JSC::FTL::Output::frameAddressIntrinsic):
(JSC::FTL::Output::patchpointInt64Intrinsic):
(JSC::FTL::Output::patchpointVoidIntrinsic):
* ftl/FTLCommonValues.cpp:
* ftl/FTLCommonValues.h:
* ftl/FTLFormattedValue.h:
* ftl/FTLIntrinsicRepository.cpp:
* ftl/FTLOSRExit.h:
* ftl/FTLOSRExitCompilationInfo.h:
* ftl/FTLStackmapArgumentList.h:
* ftl/FTLState.cpp:
* ftl/FTLState.h:
* ftl/FTLTypedPointer.h:
2015-11-17 Filip Pizlo <fpizlo@apple.com>
B3::generate should separate out the final Air codegen, so that it can be done outside the Graph safepoint
https://bugs.webkit.org/show_bug.cgi?id=151371
Reviewed by Benjamin Poulain.
One of the FTL optimizations is that while the expensive backend is running, we are at a "graph
safepoint" that allows the VM to do GCs and other dangerous and time-sensitive things without
waiting for the compilation thread. While in the safepoint, we cannot do anything that touches
anything other than the backend's state. That means, for example, that we wouldn't be able to run
any of the stackmap generation callbacks, since those need to mess with DFG state.
That means that we need to separate the B3 pipeline into "preparation" and "generation".
Preparation is all of the expensive stuff: all B3 phases, lowering to Air, all Air phases.
Generation is just the part where we turn fully lowered Air into machine code. Generation also
happens to be the part where we call stackmap generation callbacks. In other words, preparation
is exactly the stuff that should go into the graph safepoint, while generation is the stuff that
we want to do after we emerge from the safepoint.
Because the tests were using the higher-level Compilation API, I didn't have to change any test
code. The FTL will not use that high-level API.
* b3/B3Compilation.cpp:
(JSC::B3::Compilation::Compilation):
* b3/B3Generate.cpp:
(JSC::B3::prepareForGeneration):
(JSC::B3::generate):
(JSC::B3::generateToAir):
* b3/B3Generate.h:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::LowerToAir):
(JSC::B3::lowerToAir):
* b3/B3LowerToAir.h:
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::Procedure):
* b3/B3Procedure.h:
(JSC::B3::Procedure::takeByproducts):
(JSC::B3::Procedure::code):
* b3/air/AirCode.h:
(JSC::B3::Air::Code::proc):
(JSC::B3::Air::Code::lastPhaseName):
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::prepareForGeneration):
(JSC::B3::Air::generate):
* b3/air/AirGenerate.h:
2015-11-17 Filip Pizlo <fpizlo@apple.com>
FTL::State should be able to refer to B3::Procedure
Rubber stamped by Benjamin Poulain.
* ftl/FTLState.h:
2015-11-17 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add an empty FTLOutput for B3 that crashes on any operation
https://bugs.webkit.org/show_bug.cgi?id=151366
Reviewed by Filip Pizlo.
* JavaScriptCore.xcodeproj/project.pbxproj:
* ftl/FTLB3Output.h: Added.
* ftl/FTLAbbreviatedTypes.h:
* ftl/FTLAbstractHeap.cpp:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::createPhiVariables):
* ftl/FTLOutput.cpp:
* ftl/FTLOutput.h:
2015-11-17 Benjamin Poulain <bpoulain@apple.com>
[JSC] Do not copy the adjacency list when we just need to manipulate them
https://bugs.webkit.org/show_bug.cgi?id=151343
Reviewed by Geoffrey Garen.
* b3/air/AirIteratedRegisterCoalescing.cpp:
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::precoloredCoalescingHeuristic):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::conservativeHeuristic):
2015-11-17 Benjamin Poulain <bpoulain@apple.com>
[JSC] Remove FTLOutput operations that act directly on floats
https://bugs.webkit.org/show_bug.cgi?id=151342
Reviewed by Geoffrey Garen.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithFRound):
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutByVal):
* ftl/FTLOutput.cpp:
(JSC::FTL::Output::store):
* ftl/FTLOutput.h:
(JSC::FTL::Output::loadFloatToDouble):
(JSC::FTL::Output::fround):
(JSC::FTL::Output::loadFloat): Deleted.
2015-11-17 Filip Pizlo <fpizlo@apple.com>
Add a FTL_USES_B3 compile-time setting and set it to 0.
Rubber stamped by Benjamin Poulain.
* dfg/DFGCommon.h:
2015-11-17 Filip Pizlo <fpizlo@apple.com>
CheckAdd/Mul should have commutativity optimizations in B3->Air lowering
https://bugs.webkit.org/show_bug.cgi?id=151214
Reviewed by Geoffrey Garen.
This is an overhaul of CheckAdd/CheckSub/CheckMul that fixes bugs, improves codegen, and
simplifies the contract between B3 and its client.
Previously, the idea was that the operands to the Air BranchAdd/Sub/Mul matched the children of
the B3 CheckAdd/Sub/Mul, or at least, that's what the B3::CheckSpecial would make you believe.
This meant that B3/Air had to avoid optimizations that would break this protocol. This prevented
commutativity optimizations on CheckAdd/Mul and it also prevented strength reduction from
CheckMul(x, 2) to CheckAdd(x, x), for example. Those optimizations would break things because the
client's Stackmap generation callback was allowed to assume that the first entry in params.reps
was the first child. Also, there was a contract between B3 and its client that for CheckAdd/Sub,
the client would undo the operation by doing the opposite operation with the params.reps[0] as the
source and params.reps[1] as the destination.
This not only prevented commutativity optimizations, it also led to bugs. Here are two bugs that
we had:
- Add(x, x) would not work. The client would be told to undo the add using %x as both the source
and destination. The client would use a sub() instruction. The result would not be x - it would
be zero.
- Mul where the result got coalesced with one of the sources. You can't undo a multiplication, so
you need to keep the inputs alive until after the result is computed - i.e. the inputs are late
uses. I initially thought I worked around this by using a three-operand form of Mul, but of
course that doesn't actually fix the issue.
This patch fixes these issues comprehensively by introducing the following changes:
The params.reps corresponding to the first two children of CheckAdd/Sub/Mul and the first child of
Check are always garbage: if you want to know the values of those children in the slow path, pass
them as additional stackmap children. This makes it clear to the compiler whose values you
actually care about, and frees the compiler to reorder and commute the non-stackmap children.
The "undo" of an Add or Sub is handled internally by B3: the client doesn't have to know anything
about undoing. B3 does it. The contract is simply that if a B3::Value* is a stackmap child of a
CheckXYZ, then the corresponding entry in params.reps inside the stackmap generator callback will
contain the value of that Value*. For Add and Sub, B3 undoes the operation. For Add(x, x), the
undo uses the carry flag and some shift magic. For Mul, B3 uses LateUse:
A new kind of Arg::Role called Arg::LateUse is introduced: This kind of use means that the use
happens at the start of the execution of the next instruction. None of the built-in Air opcodes
use LateUse, but it is used by B3::CheckSpecial. We use it to implement CheckMul.
Finally, this change fixes testComplex to actually create many live variables. This revealed a
really dumb pathology in allocateStack(), and this patch fixes it. Basically, it's a bad idea to
build interference graphs by repeatedly recreating the same cliques.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::test32):
(JSC::MacroAssemblerX86Common::setCarry):
(JSC::MacroAssemblerX86Common::invert):
* b3/B3CheckSpecial.cpp:
(JSC::B3::Air::numB3Args):
(JSC::B3::CheckSpecial::Key::Key):
(JSC::B3::CheckSpecial::Key::dump):
(JSC::B3::CheckSpecial::CheckSpecial):
(JSC::B3::CheckSpecial::forEachArg):
(JSC::B3::CheckSpecial::isValid):
(JSC::B3::CheckSpecial::generate):
(JSC::B3::CheckSpecial::dumpImpl):
(JSC::B3::CheckSpecial::deepDumpImpl):
* b3/B3CheckSpecial.h:
(JSC::B3::CheckSpecial::Key::Key):
(JSC::B3::CheckSpecial::Key::operator==):
(JSC::B3::CheckSpecial::Key::operator!=):
(JSC::B3::CheckSpecial::Key::opcode):
(JSC::B3::CheckSpecial::Key::numArgs):
(JSC::B3::CheckSpecial::Key::stackmapRole):
(JSC::B3::CheckSpecial::Key::hash):
* b3/B3CheckValue.cpp:
(JSC::B3::CheckValue::~CheckValue):
(JSC::B3::CheckValue::convertToAdd):
(JSC::B3::CheckValue::CheckValue):
* b3/B3CheckValue.h:
* b3/B3Const32Value.cpp:
(JSC::B3::Const32Value::checkMulConstant):
(JSC::B3::Const32Value::checkNegConstant):
(JSC::B3::Const32Value::divConstant):
* b3/B3Const32Value.h:
* b3/B3Const64Value.cpp:
(JSC::B3::Const64Value::checkMulConstant):
(JSC::B3::Const64Value::checkNegConstant):
(JSC::B3::Const64Value::divConstant):
* b3/B3Const64Value.h:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::appendBinOp):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Opcode.h:
* b3/B3PatchpointSpecial.cpp:
(JSC::B3::PatchpointSpecial::~PatchpointSpecial):
(JSC::B3::PatchpointSpecial::forEachArg):
(JSC::B3::PatchpointSpecial::isValid):
* b3/B3ReduceStrength.cpp:
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::forEachArgImpl):
* b3/B3StackmapSpecial.h:
* b3/B3StackmapValue.cpp:
(JSC::B3::StackmapValue::append):
(JSC::B3::StackmapValue::appendSomeRegister):
(JSC::B3::StackmapValue::setConstrainedChild):
* b3/B3StackmapValue.h:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::checkMulConstant):
(JSC::B3::Value::checkNegConstant):
(JSC::B3::Value::divConstant):
* b3/B3Value.h:
* b3/air/AirAllocateStack.cpp:
(JSC::B3::Air::allocateStack):
* b3/air/AirArg.cpp:
(WTF::printInternal):
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::isAnyUse):
(JSC::B3::Air::Arg::isEarlyUse):
(JSC::B3::Air::Arg::isLateUse):
(JSC::B3::Air::Arg::isDef):
(JSC::B3::Air::Arg::forEachTmp):
(JSC::B3::Air::Arg::isUse): Deleted.
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::generate):
* b3/air/AirIteratedRegisterCoalescing.cpp:
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::build):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::allocate):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::InterferenceEdge::hash):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::InterferenceEdge::dump):
(JSC::B3::Air::addSpillAndFillToProgram):
(JSC::B3::Air::iteratedRegisterCoalescingOnType):
(JSC::B3::Air::iteratedRegisterCoalescing):
* b3/air/AirLiveness.h:
(JSC::B3::Air::Liveness::Liveness):
(JSC::B3::Air::Liveness::LocalCalc::LocalCalc):
(JSC::B3::Air::Liveness::LocalCalc::live):
(JSC::B3::Air::Liveness::LocalCalc::takeLive):
(JSC::B3::Air::Liveness::LocalCalc::execute):
* b3/air/AirOpcode.opcodes:
* b3/air/AirReportUsedRegisters.cpp:
(JSC::B3::Air::reportUsedRegisters):
* b3/air/AirSpillEverything.cpp:
(JSC::B3::Air::spillEverything):
* b3/testb3.cpp:
(JSC::B3::testMulArg):
(JSC::B3::testMulArgStore):
(JSC::B3::testMulAddArg):
(JSC::B3::testMulArgs):
(JSC::B3::testComplex):
(JSC::B3::testSimpleCheck):
(JSC::B3::testCheckLessThan):
(JSC::B3::testCheckMegaCombo):
(JSC::B3::testCheckAddImm):
(JSC::B3::testCheckAddImmCommute):
(JSC::B3::testCheckAddImmSomeRegister):
(JSC::B3::testCheckAdd):
(JSC::B3::testCheckAdd64):
(JSC::B3::testCheckSubImm):
(JSC::B3::testCheckSubBadImm):
(JSC::B3::testCheckSub):
(JSC::B3::testCheckSub64):
(JSC::B3::testCheckNeg):
(JSC::B3::testCheckNeg64):
(JSC::B3::testCheckMul):
(JSC::B3::testCheckMulMemory):
(JSC::B3::testCheckMul2):
(JSC::B3::testCheckMul64):
(JSC::B3::run):
2015-11-17 Filip Pizlo <fpizlo@apple.com>
Air should lay out code optimally
https://bugs.webkit.org/show_bug.cgi?id=150478
Reviewed by Geoffrey Garen.
This adds a phase that optimizes code layout using something that's worked well for me in the past.
Basically, it just forces pre-ordering on the CFG, except that:
- Blocks that are only reachable by Rare control flow are scheduled separately, all the way at the
end.
- Successors of the same frequency class are pushed in ascending order of frequency, so that the most
frequent successor is scheduled immediately after.
This also adds the requisite branch flipping, so that a branch's taken successor is not the
fall-through block. We want the fall-through to be the not-taken successor if at all possible.
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3BlockWorklist.h:
* b3/B3GenericFrequentedBlock.h:
(JSC::B3::GenericFrequentedBlock::frequency):
(JSC::B3::GenericFrequentedBlock::isRare):
(JSC::B3::GenericFrequentedBlock::dump):
* b3/B3Procedure.h:
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::isDoubleCond):
(JSC::B3::Air::Arg::isCondition):
(JSC::B3::Air::Arg::isSpecial):
(JSC::B3::Air::Arg::asDoubleCondition):
(JSC::B3::Air::Arg::isInvertible):
(JSC::B3::Air::Arg::inverted):
* b3/air/AirBasicBlock.h:
(JSC::B3::Air::BasicBlock::index):
(JSC::B3::Air::BasicBlock::setIndex):
(JSC::B3::Air::BasicBlock::size):
(JSC::B3::Air::BasicBlock::begin):
(JSC::B3::Air::BasicBlock::containsPredecessor):
(JSC::B3::Air::BasicBlock::frequency):
* b3/air/AirBlockWorklist.h: Added.
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::findNextBlock):
* b3/air/AirCode.h:
(JSC::B3::Air::Code::proc):
(JSC::B3::Air::Code::at):
(JSC::B3::Air::Code::operator[]):
(JSC::B3::Air::Code::blockList):
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::generate):
* b3/air/AirOpcode.opcodes:
* b3/air/AirOptimizeBlockOrder.cpp: Added.
(JSC::B3::Air::optimizeBlockOrder):
* b3/air/AirOptimizeBlockOrder.h: Added.
2015-11-17 Andreas Kling <akling@apple.com>
[JSC] JSPropertyNameEnumerator could be destructorless.
<https://webkit.org/b/151242>
Reviewed by Mark Lam.
Make JSPropertyNameEnumerator destructorless and have it store the property names
cache in CopiedSpace. This was the most popular occupant of 64-byte destructor cells
in MarkedSpace, so making it destructorless gets rid of some ill-filled MarkedBlocks.
This patch had two issues on 32-bit platforms when first landed:
- Copied space allocations are required to be 8-byte divisible in size.
- WriteBarrier<Unknown> and WriteBarrier<JSString> are not the same size on 32-bit;
the former is a 64-bit EncodedJSValue internally, and the latter is a 32-bit JSCell*.
My patch was reinterpret_cast'ing a WriteBarrier<JSString> to a WriteBarrier<Unknown>
when passing to SlotVisitor::appendValues(), which led to invalid addresses getting
marked and strings getting GC'd prematurely.
* heap/CopyToken.h:
* runtime/JSPropertyNameEnumerator.cpp:
(JSC::JSPropertyNameEnumerator::finishCreation):
(JSC::JSPropertyNameEnumerator::visitChildren):
(JSC::JSPropertyNameEnumerator::copyBackingStore):
(JSC::JSPropertyNameEnumerator::destroy): Deleted.
* runtime/JSPropertyNameEnumerator.h:
2015-11-17 Mark Lam <mark.lam@apple.com>
Refactoring: move branchMul32's imm arg to the 3rd argument to be consistent.
https://bugs.webkit.org/show_bug.cgi?id=151358
Reviewed by Saam Barati.
branch32, branchAdd32, and branchSub32 all have it as the 3rd argument.
branchMul32 is the odd man out. This patch makes branchMul32 consistent with
the others.
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::branchAdd32):
(JSC::MacroAssembler::branchMul32):
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::branchMul32):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::branchMul32):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::branchMul32):
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::branchMul32):
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::branchNeg32):
(JSC::MacroAssemblerSH4::branchMul32):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::branchMul32):
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_mul):
2015-11-17 Mark Lam <mark.lam@apple.com>
Use the JITAddGenerator snippet in the DFG.
https://bugs.webkit.org/show_bug.cgi?id=151266
Reviewed by Geoffrey Garen.
No tests added because the op_add.js stress test already tests for correctness
(using the LLINT as a reference).
Performance-wise, the difference from the pre-existing DFG implementation is
insignificant (at least as measured on x86 and x86_64). We're moving forward
with adopting this implementation because it unifies the 32-bit and 64-bit
implementations, as well as lays ground work for a repatching inline cache
implementation of op_add later.
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::resultType):
- Made an assertion less restrictive. For ValueAdd operands, the DFG thinks that
the operand can also be empty (though we should never see this in practice).
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
- Add fallback to unused type operands.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueAdd):
- Introduce a common function to compile the ValueAdd node.
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::JSValueOperand::JSValueOperand):
- Add the forwarding constructor so that we can use Optional<JSValueOperand>.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
- Changed to use the common compileValueAdd().
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::moveValue):
- Similar to moveTrustedValue() but used for untrusted constants.
* jit/JITAddGenerator.cpp:
(JSC::JITAddGenerator::generateFastPath):
* jit/JITAddGenerator.h:
(JSC::JITAddGenerator::JITAddGenerator):
- Updated to take the left or right operand as a constant. This is necessary
because the client should not be making assumptions about whether the snippet
will determine the operation to be commutative or not. Instead, the client
should just pass in the operands and let the snippet do any operand order
swapping if necessary.
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_add):
- Updated to use the new JITAddGenerator interface.
* tests/stress/op_add.js:
(stringifyIfNeeded):
(runTest):
- Made test output more clear about when string results are expected.
2015-11-17 Filip Pizlo <fpizlo@apple.com>
It's best for the DFG to always have some guess of basic block frequency
https://bugs.webkit.org/show_bug.cgi?id=151350
Reviewed by Geoffrey Garen.
It'll simplify things for B3 if we always have some estimate of block frequency, even if it's not
a great estimate. Using NaN as an estimate is probably worse than using any non-NaN number.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::inlineCall):
(JSC::DFG::ByteCodeParser::handleInlining):
(JSC::DFG::ByteCodeParser::parseCodeBlock):
* dfg/DFGCriticalEdgeBreakingPhase.cpp:
(JSC::DFG::CriticalEdgeBreakingPhase::breakCriticalEdge):
* dfg/DFGLoopPreHeaderCreationPhase.cpp:
(JSC::DFG::createPreHeader):
2015-11-17 Michael Saboff <msaboff@apple.com>
Reserved VM pool established in r187125 is likely too conservative
https://bugs.webkit.org/show_bug.cgi?id=151351
Reviewed by Filip Pizlo.
Reduce the VM allocation reserved pool from 25% to 15% for ARM32.
* jit/ExecutableAllocator.h:
2015-11-17 Saam barati <sbarati@apple.com>
FTLLazySlowPaths should be able to handle being passed the zero register as a location
https://bugs.webkit.org/show_bug.cgi?id=151193
Reviewed by Geoffrey Garen.
On arm64, SP and ZR are the same register number. The meaning
of the register number being SP or ZR is dependent on context of
the instruction and the register within the instruction. LLVM may
prove that a value is zero, or sometimes, we will lower a
value as a constant zero (for example, we might compile
CreateDirectArguments of an inlined call frame and we might know
that the arguments have a length of zero). LazySlowPaths should
be able to gracefully handle being passed a stackmap location
with a gpr value of SP by moving zero into another register
and replacing the location's register with the new register.
This way, no lazy slow path will ever have access to a location with a GPR
value of SP. This patch makes this work by using a scratch register
allocator when we need to do this maneuver of moving zero into a scratch
register. Inside FTLCompile, we track if we need to move zero into a register,
and if so, into which register. We actually emit the necessary
instructions to move zero into this register, and to spill reused
registers if necessary, while generating the code for the lazy slow
path itself.
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLDWARFRegister.cpp:
(JSC::FTL::DWARFRegister::reg):
* ftl/FTLLazySlowPath.cpp:
(JSC::FTL::LazySlowPath::LazySlowPath):
(JSC::FTL::LazySlowPath::generate):
* ftl/FTLLazySlowPath.h:
(JSC::FTL::LazySlowPath::createGenerator):
2015-11-17 Mark Lam <mark.lam@apple.com>
[JSC] Support Doubles with B3's Mul.
https://bugs.webkit.org/show_bug.cgi?id=151355
Reviewed by Filip Pizlo.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testMulLoadTwice):
(JSC::B3::testMulArgDouble):
(JSC::B3::testMulArgsDouble):
(JSC::B3::testMulArgImmDouble):
(JSC::B3::testMulImmArgDouble):
(JSC::B3::testMulImmsDouble):
(JSC::B3::testDivArgDouble):
(JSC::B3::run):
2015-11-17 Matthew Daiter <mdaiter8121@gmail.com>
Removed useless variable scriptResult from testExecutionTimeLimit
https://bugs.webkit.org/show_bug.cgi?id=151331
Reviewed by Alex Christensen.
* API/tests/ExecutionTimeLimitTest.cpp: Removed scriptResult
(testExecutionTimeLimit):
2015-11-16 Mark Lam <mark.lam@apple.com>
[JSC] Support Doubles with B3's Sub.
https://bugs.webkit.org/show_bug.cgi?id=151322
Reviewed by Filip Pizlo.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testSubImmArg32):
(JSC::B3::testSubArgDouble):
(JSC::B3::testSubArgsDouble):
(JSC::B3::testSubArgImmDouble):
(JSC::B3::testSubImmArgDouble):
(JSC::B3::testSubImmsDouble):
(JSC::B3::testBitAndArgs):
(JSC::B3::negativeZero):
(JSC::B3::posInfinity):
(JSC::B3::negInfinity):
(JSC::B3::doubleOperands):
(JSC::B3::run):
- Added RUN_UNARY and RUN_BINARY macros to auto generate permutations
of operands for the tests.
- Added SubDouble tests using the new macros.
2015-11-17 Benjamin Poulain <bpoulain@apple.com>
[JSC] IteratedRegisterCoalescingAllocator's freeze can add zombie Tmps to our coloring algorithm
https://bugs.webkit.org/show_bug.cgi?id=151345
Reviewed by Filip Pizlo.
The extended test of https://bugs.webkit.org/show_bug.cgi?id=151214 revealed a problem with
the Move freezing step of the iterated register allocator.
When freezing a move related Tmp, we go over all the move instructions and update the other
Tmp of the move as needed. If that Tmp is no longer Move related and is of low degree it can
be simplified too.
The problem arise when one of those Tmp was already coalesced. For example, say we have
1: move %tmp42, %tmp43
2: move %tmp42, %tmp44
The first move cannot be coalesced for some reason and is moved to the Active worklist.
The second move is coalesced and %tmp42 is now %tmp44.
When nothing can be simplified or coalesced, we look at freezing a Move-related Tmp.
Let's say we pick %tmp43. The code of freeze() was going to all the Move instructions
to update them. Here you would find @1 above, get %tmp42 as the other Tmp. Since %tmp42
is no longer move related, it is added to the simplify work list.
-> We just added a coalesced Tmp to our worklist!
To fix that, I get the alias of every other Tmp before updating its status.
There is still a problem: multiple Moves instructions may have been coalesced to the same
Tmp. We must not add a Tmp twice to a worklist.
To avoid duplicates, I rely on the fact that the freeze worklist should not contains
aliased Tmps. Before adding something to the simplify worklist, I check that it was
in the freeze worklist.
I cannot find how this problem would have been avoided in the original paper. I suspect
that may have been a bug in the pseudo-code.
* b3/air/AirIteratedRegisterCoalescing.cpp:
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::freeze):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::freezeMoves):
2015-11-16 Benjamin Poulain <bpoulain@apple.com>
[JSC] Make FTLOutput's load8() and load16() compatible with B3
https://bugs.webkit.org/show_bug.cgi?id=151336
Reviewed by Filip Pizlo.
B3 does not have 8bit and 16bit types. Make FTLOutput abstract enough
to handle LLVM IR and B3.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetArrayLength):
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToLLVM::compileStringCharAt):
(JSC::FTL::DFG::LowerDFGToLLVM::compileStringCharCodeAt):
(JSC::FTL::DFG::LowerDFGToLLVM::compileNotifyWrite):
(JSC::FTL::DFG::LowerDFGToLLVM::compileSwitch):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCheckHasInstance):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCheckWatchdogTimer):
(JSC::FTL::DFG::LowerDFGToLLVM::speculateTruthyObject):
(JSC::FTL::DFG::LowerDFGToLLVM::boolify):
(JSC::FTL::DFG::LowerDFGToLLVM::equalNullOrUndefined):
(JSC::FTL::DFG::LowerDFGToLLVM::switchStringRecurse):
(JSC::FTL::DFG::LowerDFGToLLVM::isObject):
(JSC::FTL::DFG::LowerDFGToLLVM::isNotObject):
(JSC::FTL::DFG::LowerDFGToLLVM::isArrayType):
(JSC::FTL::DFG::LowerDFGToLLVM::isExoticForTypeof):
(JSC::FTL::DFG::LowerDFGToLLVM::isType):
(JSC::FTL::DFG::LowerDFGToLLVM::speculateNonNullObject):
(JSC::FTL::DFG::LowerDFGToLLVM::loadCellState):
(JSC::FTL::DFG::LowerDFGToLLVM::emitStoreBarrier):
* ftl/FTLOutput.h:
(JSC::FTL::Output::load8SignExt32):
(JSC::FTL::Output::load8ZeroExt32):
(JSC::FTL::Output::load16SignExt32):
(JSC::FTL::Output::load16ZeroExt32):
(JSC::FTL::Output::constInt8): Deleted.
(JSC::FTL::Output::load8): Deleted.
(JSC::FTL::Output::load16): Deleted.
(JSC::FTL::Output::store8): Deleted.
(JSC::FTL::Output::storeFloat): Deleted.
(JSC::FTL::Output::isZero8): Deleted.
(JSC::FTL::Output::notZero8): Deleted.
(JSC::FTL::Output::testIsZero8): Deleted.
(JSC::FTL::Output::testNonZero8): Deleted.
2015-11-16 Benjamin Poulain <bpoulain@apple.com>
Fix a typo in AirIteratedRegisterCoalescing
I forgot to fix that review comment from Geoff.
* b3/air/AirIteratedRegisterCoalescing.cpp:
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::build):
2015-11-16 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add support for the extra registers that can be clobbered by Specials
https://bugs.webkit.org/show_bug.cgi?id=151246
Reviewed by Geoffrey Garen.
Specials can clobber arbitrary registers. This was not handled correctly by Air
and nothing was preventing us from re-allocating those registers.
This patch adds support for the extra clobbered registers in the two register allocators.
I also fixed the re-spilling FIXME of the iterated allocator because the test might
not always converge without it. Since we are at maximum register pressure at the patch point,
we could be always spilling the return value, which would loop forever.
To fix the re-spilling, I just kept a Set of every value spilled or filled so far. When selecting
a spill candidate, we never pick a Tmp from that set.
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::generate):
* b3/air/AirHandleCalleeSaves.cpp:
(JSC::B3::Air::handleCalleeSaves):
* b3/air/AirInst.h:
* b3/air/AirInstInlines.h:
(JSC::B3::Air::Inst::forEachDefAndExtraClobberedTmp):
* b3/air/AirIteratedRegisterCoalescing.cpp:
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::IteratedRegisterCoalescingAllocator):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::build):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::addEdges):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::selectSpill):
(JSC::B3::Air::addSpillAndFillToProgram):
(JSC::B3::Air::iteratedRegisterCoalescingOnType):
(JSC::B3::Air::iteratedRegisterCoalescing):
* b3/air/AirSpillEverything.cpp:
(JSC::B3::Air::spillEverything):
* b3/testb3.cpp:
(JSC::B3::testSimplePatchpointWithoutOuputClobbersGPArgs):
(JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs):
(JSC::B3::testSimplePatchpointWithoutOuputClobbersFPArgs):
(JSC::B3::testSimplePatchpointWithOuputClobbersFPArgs):
(JSC::B3::run):
* jit/RegisterSet.h:
2015-11-16 Benjamin Poulain <benjamin@webkit.org>
Build fix after r192492
Last second change broke the build.
* b3/air/AirIteratedRegisterCoalescing.cpp:
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::OrderedMoveSet::contains):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::OrderedMoveSet::takeMove):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::OrderedMoveSet::takeLastMove):
2015-11-16 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add trivial lowering for B3's Div with doubles
https://bugs.webkit.org/show_bug.cgi?id=151292
Reviewed by Geoffrey Garen.
Filip had already made the constant propagation for it.
The Air Opcode was all we had left.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testDivArgDouble):
(JSC::B3::testDivArgsDouble):
(JSC::B3::testDivArgImmDouble):
(JSC::B3::testDivImmArgDouble):
(JSC::B3::testDivImmsDouble):
(JSC::B3::run):
2015-11-16 Benjamin Poulain <bpoulain@apple.com>
[JSC] Speed up the coalescing-related operation of the iterated register allocator
https://bugs.webkit.org/show_bug.cgi?id=151290
Reviewed by Geoffrey Garen.
One step closer to removing the Hash structures:
For the coalescing operation, we need to keep track of Move instructions. We do not strictly
need those to be the Air Move, just any abstract operation that copy a Tmp into another Tmp.
In this patch, I exploit that to remove the Hash structure related to the Inst. Instead of
using the Move Inst, we just keep track of the Use() and Def() of the instructions.
Those are added in the global list m_coalescingCandidates and the index in that list represent
the move for the remaining of the algorithm.
With Moves transformed into dense indices, we can start using arrays to make fast sets.
The m_activeMoves Set is easy since we only need simple add/remove/contains. It is transformed
into a BitVector.
The bit vector is always fully allocated to allow for quick uniform access. The assumtion is that
activeMoves will contains a few values for non trivial cases.
The worklist m_worklistMoves is more complicated. I want it to be ordered to coalesce moves starting
at the top of blocks. Having a fast remove() operation is also useful for mass coalescing.
It also needs Set operations, especially a fast contains().
For m_worklistMoves, I created a new structure: OrderedMoveSet.
It contains a list of ordered values, and a map of each value to its position in the list.
This resembles Briggs' Sparse Set but it is not exactly the same. When removing a value,
I set a special marker in the map (UINT_MAX). The reason is that I want contains() to be fast
instead of remove(). The marker in the map allows contains() with a single memory operation instead of two.
* b3/air/AirIteratedRegisterCoalescing.cpp:
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::build):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::allocate):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::forEachNodeMoves):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::isMoveRelated):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::enableMovesOnValue):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::coalesce):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::combine):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::freezeMoves):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::dumpWorkLists):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::OrderedMoveSet::addMove):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::OrderedMoveSet::isEmpty):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::OrderedMoveSet::contains):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::OrderedMoveSet::takeMove):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::OrderedMoveSet::takeLastMove):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::OrderedMoveSet::returnMove):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::OrderedMoveSet::clear):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::assignColors): Deleted.
2015-11-16 Saam barati <sbarati@apple.com>
DFGEdge's dump method should print "Untyped:" for untyped uses.
https://bugs.webkit.org/show_bug.cgi?id=151314
Rubber stamped by Filip Pizlo.
* dfg/DFGEdge.cpp:
(JSC::DFG::Edge::dump):
2015-11-16 Filip Pizlo <fpizlo@apple.com>
Make sure that the address matcher correctly handles Shl(x, 1)
https://bugs.webkit.org/show_bug.cgi?id=151316
Reviewed by Geoffrey Garen.
This optimization isn't really that awesome, but the nicest part of the change is just the
testing. If we ever do more cleverness with shifts, these tests will come in handy.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::effectiveAddr):
* b3/testb3.cpp:
(JSC::B3::testLoadOffsetUsingAddNotConstant):
(JSC::B3::testLoadAddrShift):
(JSC::B3::testFramePointer):
(JSC::B3::run):
2015-11-16 Carlos Garcia Campos <cgarcia@igalia.com>
[GTK] Use FTL by default when LLVM 3.7 is available
https://bugs.webkit.org/show_bug.cgi?id=142128
Reviewed by Csaba Osztrogonác.
* PlatformGTK.cmake: Install libllvmForJSC.so.
* llvm/InitializeLLVMLinux.cpp:
(JSC::getLLVMInitializerFunction): For developer build try to load first
libllvmForJSC.so from standard paths since not installed binaries
have the RPATH set. If it fails try the installed one. For
production buils load always the installed one.
2015-11-15 Saam barati <sbarati@apple.com>
64-bit in the DFG: non tail Calls unnecessarily store the argument count twice on the callee frame and tails calls unnecessarily store it once
https://bugs.webkit.org/show_bug.cgi?id=151297
Reviewed by Geoffrey Garen.
Non tail calls only need to store the count once. Tail calls
never need to store the count on the callee frame because they
will be reusing the caller's frame.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
2015-11-15 Adam Bergkvist <adam.bergkvist@ericsson.com>
WebRTC: Update RTCPeerConnection API and introduce PeerConnectionBackend
https://bugs.webkit.org/show_bug.cgi?id=150166
Reviewed by Eric Carlson and Youenn Fablet
Added generic isDictionary() function to GlobalObject.js that tests if a
value can be interpreted as a dictionary.
* builtins/GlobalObject.js:
(isDictionary):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
2015-11-14 Michael Saboff <msaboff@apple.com>
REGRESSION (r190370): CrashTracer: [USER] com.apple.WebKit.WebContent at com.apple.JavaScriptCore: JSC::JITCode::execute + 158
https://bugs.webkit.org/show_bug.cgi?id=151279
Reviewed by Geoffrey Garen.
We need to restore callee saves even when we take the slow path in a polymorphic call stub.
Move the restoration to the top of the stub so that it is done for all paths.
* jit/Repatch.cpp:
(JSC::linkPolymorphicCall):
2015-11-13 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r192416 and r192443.
https://bugs.webkit.org/show_bug.cgi?id=151285
Broke 32-bit in some mysterious way I need to understand
(Requested by kling on #webkit).
Reverted changesets:
"[JSC] JSPropertyNameEnumerator could be destructorless."
https://bugs.webkit.org/show_bug.cgi?id=151242
http://trac.webkit.org/changeset/192416
"Follow-up for 32-bit test failures after..."
https://bugs.webkit.org/show_bug.cgi?id=151242
http://trac.webkit.org/changeset/192443
2015-11-13 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r192401.
https://bugs.webkit.org/show_bug.cgi?id=151282
"caused crashes on animometer" (Requested by thorton on
#webkit).
Reverted changeset:
"Restore CodeBlock jettison code I accidentally removed"
https://bugs.webkit.org/show_bug.cgi?id=151241
http://trac.webkit.org/changeset/192401
2015-11-13 Andreas Kling <akling@apple.com>
Follow-up for 32-bit test failures after...
[JSC] JSPropertyNameEnumerator could be destructorless.
<https://webkit.org/b/151242>
Reviewed by Mark Lam
Apparently copied space allocations need to be in multiples of 8 bytes.
Have JSPropertyNameEnumerator do what other copied space clients already do
and round the allocation size up to a multiple of 8.
Added a little helper function to compute the allocation size so this doesn't
have to be repeated everywhere.
* runtime/JSPropertyNameEnumerator.cpp:
(JSC::JSPropertyNameEnumerator::finishCreation):
(JSC::JSPropertyNameEnumerator::visitChildren):
(JSC::JSPropertyNameEnumerator::copyBackingStore):
* runtime/JSPropertyNameEnumerator.h:
2015-11-13 Saam barati <sbarati@apple.com>
sub IC does not properly handle exception handling now that try/catch is compiled in the FTL
https://bugs.webkit.org/show_bug.cgi?id=151080
Reviewed by Geoffrey Garen.
This patch implements proper exception handling for ArithSubs with binaryUseKind as
UntypedUse inside try/catch. We implement this in a very similar way as we implement
exception handling from GetById/PutById/LazySlowPaths callOperation calls. We do the needed
spilling if the result is the same register as the left/right register because in the event
of an exception, we don't want to do value recovery on the garbage result, we
want to do it on the original lhs/rhs of the operation.
This patch also does some refactoring. No longer does OSRExitDescriptor
have a long list of booleans that correspond to different OSR exit types.
It now just has an enum property called ExceptionType that tells us
what type of exception handler the OSR exit is. Then, we can just ask
interesting questions about the OSR exit and get answers based on its
ExceptionType property.
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLExceptionHandlerManager.cpp:
(JSC::FTL::ExceptionHandlerManager::addNewExit):
(JSC::FTL::ExceptionHandlerManager::callOperationExceptionTarget):
(JSC::FTL::ExceptionHandlerManager::lazySlowPathExceptionTarget):
(JSC::FTL::ExceptionHandlerManager::getByIdOSRExit):
(JSC::FTL::ExceptionHandlerManager::subOSRExit):
(JSC::FTL::ExceptionHandlerManager::getCallOSRExitCommon):
(JSC::FTL::ExceptionHandlerManager::getOrPutByIdCallOperationExceptionTarget): Deleted.
* ftl/FTLExceptionHandlerManager.h:
* ftl/FTLExitThunkGenerator.cpp:
(JSC::FTL::ExitThunkGenerator::emitThunk):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::lower):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
(JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
(JSC::FTL::DFG::LowerDFGToLLVM::getById):
(JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
(JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
(JSC::FTL::DFG::LowerDFGToLLVM::emitBranchToOSRExitIfWillCatchException):
(JSC::FTL::DFG::LowerDFGToLLVM::lowBlock):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitDescriptor):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
(JSC::FTL::DFG::LowerDFGToLLVM::buildExitArguments):
* ftl/FTLOSRExit.cpp:
(JSC::FTL::OSRExitDescriptor::OSRExitDescriptor):
(JSC::FTL::OSRExitDescriptor::willArriveAtExitFromIndirectExceptionCheck):
(JSC::FTL::OSRExitDescriptor::mightArriveAtOSRExitFromGenericUnwind):
(JSC::FTL::OSRExitDescriptor::mightArriveAtOSRExitFromCallOperation):
(JSC::FTL::OSRExitDescriptor::needsRegisterRecoveryOnGenericUnwindOSRExitPath):
(JSC::FTL::OSRExitDescriptor::isExceptionHandler):
(JSC::FTL::OSRExitDescriptor::validateReferences):
(JSC::FTL::OSRExit::OSRExit):
(JSC::FTL::OSRExit::codeLocationForRepatch):
(JSC::FTL::OSRExit::gatherRegistersToSpillForCallIfException):
(JSC::FTL::OSRExit::spillRegistersToSpillSlot):
(JSC::FTL::OSRExit::recoverRegistersFromSpillSlot):
* ftl/FTLOSRExit.h:
* ftl/FTLOSRExitCompilationInfo.h:
(JSC::FTL::OSRExitCompilationInfo::OSRExitCompilationInfo):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileFTLOSRExit):
* tests/stress/ftl-try-catch-arith-sub-exception.js: Added.
(assert):
(let.o.valueOf):
(baz):
(foo):
(bar):
2015-11-13 Caitlin Potter <caitpotter88@gmail.com>
Allow any LeftHandSideExpression as a valid AssignmentElement
https://bugs.webkit.org/show_bug.cgi?id=151026
Reviewed by Geoffrey Garen.
* bytecompiler/NodesCodegen.cpp:
(JSC::AssignmentElementNode::collectBoundIdentifiers):
(JSC::AssignmentElementNode::bindValue):
(JSC::AssignmentElementNode::toString):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::isAssignmentLocation):
(JSC::ASTBuilder::createAssignmentElement):
* parser/NodeConstructors.h:
(JSC::AssignmentElementNode::AssignmentElementNode):
* parser/Nodes.h:
(JSC::AssignmentElementNode::assignmentTarget):
(JSC::AssignmentElementNode::divotStart):
(JSC::AssignmentElementNode::divotEnd):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::createAssignmentElement):
(JSC::Parser<LexerType>::parseDestructuringPattern):
* parser/Parser.h:
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::operatorStackPop):
2015-11-13 Yusuke Suzuki <utatane.tea@gmail.com>
op_assert should declare that it uses the first register argument
https://bugs.webkit.org/show_bug.cgi?id=151183
Reviewed by Geoffrey Garen.
op_assert(conditionRegister, lineNumber) should declare that it
*uses* (in terms of use-def) the first `conditionRegister` and
it does not define any variables.
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
2015-11-13 Andreas Kling <akling@apple.com>
[JSC] JSPropertyNameEnumerator could be destructorless.
<https://webkit.org/b/151242>
Reviewed by Mark Lam.
Make JSPropertyNameEnumerator destructorless and have it store the property names
cache in CopiedSpace. This was the most popular occupant of 64-byte destructor cells
in MarkedSpace, so making it destructorless gets rid of some ill-filled MarkedBlocks.
* heap/CopyToken.h:
* runtime/JSPropertyNameEnumerator.cpp:
(JSC::JSPropertyNameEnumerator::finishCreation):
(JSC::JSPropertyNameEnumerator::visitChildren):
(JSC::JSPropertyNameEnumerator::copyBackingStore):
(JSC::JSPropertyNameEnumerator::destroy): Deleted.
* runtime/JSPropertyNameEnumerator.h:
2015-11-12 Benjamin Poulain <bpoulain@apple.com>
[JSC] Do not generate an Add when adding a zero immediate to something
https://bugs.webkit.org/show_bug.cgi?id=151171
Reviewed by Geoffrey Garen.
Avoid generating an add if one of arguments is a zero immediate.
On x86, the add32/64() were also used internally for branchAdd32/64.
I split the code that sets flag to add32AndSetFlags() to make sure
we always force the flags before testing.
I could have used CMp to set the flags but I would gain nothing from
that, cmp is just a SUB.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::add32):
(JSC::MacroAssemblerARM64::add64):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::add32):
* assembler/MacroAssemblerX86.h:
(JSC::MacroAssemblerX86::add32):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::add32):
(JSC::MacroAssemblerX86Common::branchAdd32):
(JSC::MacroAssemblerX86Common::add32AndSetFlags):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::add32):
(JSC::MacroAssemblerX86_64::add64):
(JSC::MacroAssemblerX86_64::branchAdd64):
(JSC::MacroAssemblerX86_64::add64AndSetFlags):
2015-11-12 Geoffrey Garen <ggaren@apple.com>
Restore CodeBlock jettison code I accidentally removed
https://bugs.webkit.org/show_bug.cgi?id=151241
Reviewed by Andreas Kling.
I meant to add this back in <http://trac.webkit.org/changeset/190827>
but I missed.
* bytecode/CodeBlock.cpp:
(JSC::timeToLive):
(JSC::CodeBlock::shouldJettisonDueToOldAge):
2015-11-12 Filip Pizlo <fpizlo@apple.com>
B3 should be able to compile programs with CheckAdd, CheckSub, and CheckMul
https://bugs.webkit.org/show_bug.cgi?id=151213
Reviewed by Benjamin Poulain.
This adds lowering code for CheckAdd, CheckSub, and CheckMul along with support for CheckNeg
(i.e. CheckSub with the left child being zero).
This adds tests for these things, by simulating what JS would do: if there is overflow, revert
to double math. To write the test, I needed support for IToD so I added that support.
This also fixes a memory corruption bug in the register allocator.
Also fixes a bug in opcode_generator.rb where we were emitting stray "return" statements inside
switch statements. I think this was benign, but I'm not sure, so I fixed it.
Note that I had to convert CheckMul handling to always use a three-operand form. That's because
there is no other way to tell Air that we need the original value alive. This means that on X86
we'll emit an extra Move just before the checked mul. That's probably fine since that's
necessary anyway.
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::branchMul64):
(JSC::MacroAssemblerX86_64::branchSub64):
* b3/B3CheckSpecial.cpp:
(JSC::B3::CheckSpecial::generate):
* b3/B3Const32Value.cpp:
(JSC::B3::Const32Value::mulConstant):
(JSC::B3::Const32Value::checkAddConstant):
(JSC::B3::Const32Value::checkSubConstant):
(JSC::B3::Const32Value::checkMulConstant):
(JSC::B3::Const32Value::divConstant):
* b3/B3Const32Value.h:
* b3/B3Const64Value.cpp:
(JSC::B3::Const64Value::mulConstant):
(JSC::B3::Const64Value::checkAddConstant):
(JSC::B3::Const64Value::checkSubConstant):
(JSC::B3::Const64Value::checkMulConstant):
(JSC::B3::Const64Value::divConstant):
* b3/B3Const64Value.h:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::appendUnOp):
(JSC::B3::Air::LowerToAir::ensureSpecial):
(JSC::B3::Air::LowerToAir::ensureCheckSpecial):
(JSC::B3::Air::LowerToAir::fillStackmap):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3ReduceStrength.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::mulConstant):
(JSC::B3::Value::checkAddConstant):
(JSC::B3::Value::checkSubConstant):
(JSC::B3::Value::checkMulConstant):
(JSC::B3::Value::divConstant):
* b3/B3Value.h:
* b3/air/AirIteratedRegisterCoalescing.cpp:
(JSC::B3::Air::iteratedRegisterCoalescing):
* b3/air/AirOpcode.opcodes:
* b3/air/opcode_generator.rb:
* b3/testb3.cpp:
(JSC::B3::testCheckMegaCombo):
(JSC::B3::testCheckAddImm):
(JSC::B3::testCheckAdd):
(JSC::B3::testCheckAdd64):
(JSC::B3::testCheckAddFold):
(JSC::B3::testCheckAddFoldFail):
(JSC::B3::testCheckSubImm):
(JSC::B3::testCheckSub):
(JSC::B3::doubleSub):
(JSC::B3::testCheckSub64):
(JSC::B3::testCheckSubFold):
(JSC::B3::testCheckSubFoldFail):
(JSC::B3::testCheckNeg):
(JSC::B3::testCheckNeg64):
(JSC::B3::testCheckMul):
(JSC::B3::testCheckMul64):
(JSC::B3::testCheckMulFold):
(JSC::B3::testCheckMulFoldFail):
(JSC::B3::genericTestCompare):
(JSC::B3::run):
2015-11-12 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Reduce list of saved console messages
https://bugs.webkit.org/show_bug.cgi?id=151225
Reviewed by Geoffrey Garen.
Inspector saves messages so that when an inspector frontend opens it can report
these messages to the frontend. However we were saving a rather large list of
1000 messages. Most pages do not produce a large number of console messages.
However pages that live for a long time can generate many errors over time,
especially periodic engine issues such as cross-origin access errors. This could
result in a lot of wasted memory for console messages that may never be used.
Likewise when an inspector first open sending all 1000 messages to the frontend
results in a poor experience.
Lets reduce the list of saved messages. Developer will still be able to see
all messages as long as they have Web Inspector open at the time the messages
are generated.
* inspector/agents/InspectorConsoleAgent.cpp:
Reduce the list from 1000 to 100. Also, when expiring
messages from this list, chunk in 10s instead of 100s.
2015-11-12 Mark Lam <mark.lam@apple.com>
Adjust timeout values in ExecutionTimeLimitTest.
https://bugs.webkit.org/show_bug.cgi?id=151223
Reviewed by Geoffrey Garen.
Some bots were not happy with the existing time out values. I adjusted them to give
the system a little more time to fire the timer events, and this made the bots happy.
* API/tests/ExecutionTimeLimitTest.cpp:
(testExecutionTimeLimit):
2015-11-12 Filip Pizlo <fpizlo@apple.com>
B3 should be able to compile Patchpoints with Register and Any constraints
https://bugs.webkit.org/show_bug.cgi?id=151209
Reviewed by Geoffrey Garen.
Most of this patch is about adding tests, since Register constraints already worked but
were untested, and almost all forms of the Any constraint worked.
One change that I'm making is that Patchpoints now default to forCall effects rather
than no effects. I think this is better because if a client of Patchpoint never supplies
any effects, it's best to assume the worst.
My testing uncovered only one real bug: moveConstants() would turn all non-zero double
constants into Loads, so the optimization to fold constants into a Stackmap would stop
working. Instead of telling the Stackmap that the double value it wanted is actually a
constant, we would tell it that it's a register and it would emit code to materialize
the double into that register. I worked around this by having moveConstants() create
ConstDoubleValue's just for the Stackmaps, which lowerToAir() recognizes and does the
right thing with (i.e. folds into the stackmap instead of materializing).
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::fillStackmap):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3MoveConstants.cpp:
* b3/B3PatchpointValue.cpp:
(JSC::B3::PatchpointValue::PatchpointValue):
* b3/testb3.cpp:
(JSC::B3::testPatchpointCallArg):
(JSC::B3::testPatchpointFixedRegister):
(JSC::B3::testPatchpointAny):
(JSC::B3::testPatchpointAnyImm):
(JSC::B3::testPatchpointManyImms):
(JSC::B3::testSimpleCheck):
(JSC::B3::run):
2015-11-12 Mark Lam <mark.lam@apple.com>
Move some prototypes to header files.
https://bugs.webkit.org/show_bug.cgi?id=151194
Reviewed by Michael Saboff.
* assembler/MacroAssemblerPrinter.cpp:
(JSC::printIndent):
* assembler/MacroAssemblerPrinter.h:
(JSC::MacroAssembler::print):
2015-11-12 Csaba Osztrogonác <ossy@webkit.org>
Remove ENABLE(SATURATED_LAYOUT_ARITHMETIC) guards
https://bugs.webkit.org/show_bug.cgi?id=150972
Reviewed by Darin Adler.
* Configurations/FeatureDefines.xcconfig:
2015-11-11 Benjamin Poulain <bpoulain@apple.com>
[JSC] Air: we have more register than what the allocator believed
https://bugs.webkit.org/show_bug.cgi?id=151182
Reviewed by Michael Saboff.
I was using GPRInfo/FPRInfo to get the number of register while coloring the interference graph.
The problem is, those classes are lying about register availability.
They don't report stuff reserved by the MacroAssembler and reserve some registers.
FPRInfo is the worst, reporting only 6 of the 15 registers we have.
The ground truth in our case is that we can color with all the registers returned
by regsInPriorityOrder(). I changed IteratedRegisterCoalescingAllocator to use that value.
The new test testSpillFP() covers simple spilling of doubles.
* b3/air/AirIteratedRegisterCoalescing.cpp:
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::IteratedRegisterCoalescingAllocator):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::makeWorkList):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::decrementDegree):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::precoloredCoalescingHeuristic):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::conservativeHeuristic):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::addWorkList):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::combine):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::freezeMoves):
* b3/testb3.cpp:
(JSC::B3::testSpillFP):
(JSC::B3::run):
2015-11-11 Mark Lam <mark.lam@apple.com>
The BinarySnippetRegisterContext needs to copy the result back from the scratch register.
https://bugs.webkit.org/show_bug.cgi?id=150712
Reviewed by Geoffrey Garen.
If the BinarySnippetRegisterContext had re-assigned the result register to a scratch
before emitting the snippet, it needs to copy the result back from the scratch after
the snippet is done.
This fixes the cdjs-tests.yaml/main.js.ftl failure reported in
https://bugs.webkit.org/show_bug.cgi?id=150687.
Also added an optimization to check for the case where any of the left, right,
or result registers are aliased together, and to map them to the corresponding
allocated scratch register for their alias instead of allocating separate ones.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
- Added JITSubGenerator.h to these project files for completeness.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
- Re-enable ArithSub handling of UntypedUse operands.
* ftl/FTLCompile.cpp:
* ftl/FTLInlineCacheSize.cpp:
(JSC::FTL::sizeOfArithSub):
- Adjusted IC sizes to account for the snippet changes.
2015-11-11 Mark Lam <mark.lam@apple.com>
Crash in sorting-benchmark.js on ARM64 with full op_sub FTL coverage.
https://bugs.webkit.org/show_bug.cgi?id=150936
Reviewed by Michael Saboff.
The OSR entry thunk does not currently restore the callee saved registers that the baseline
JIT saves but the DFG does not. As a result, sorting-benchmark.js was crashing with the
following scenario:
1. There exists 2 functions: benchmark() and bottom_up_merge_sort().
Let's call them A() and B() respectively for brevity.
2. A() is FTL compiled.
3. B() is FTL compiled.
4. FTL A() calls FTL B(). FTL B() trashes register x26.
5. FTL B() goes through an OSR exit, and deopts to baseline. The OSR exit off-ramp
puts x26's original value in the baseline B()'s stash location for x26 in its stack
frame. It expects baseline B() to restore x26 when it returns.
6. Baseline B() gets DFG optimized, and we OSR enter into DFG B().
The OSR entry thunk does nothing to restore x26's original value. Hence, x26 contains
whatever value FTL B() left in it.
7. DFG B() returns to FTL A().
x26 is not one of the callee saved registers used by DFG B(). Hence, it does nothing
to restore it.
8. FTL A() tries to use x26 and crashes, because x26 contains FTL B()'s value for it, and
not FTL A()'s.
This patch fixes this issue by having the OSR entry thunk restore all the callee saved
registers before running the DFG code.
No new test needed because this issue will be covered by sorting-benchmark.js as soon as
https://bugs.webkit.org/show_bug.cgi?id=150712 lands.
* dfg/DFGThunks.cpp:
(JSC::DFG::osrEntryThunkGenerator):
2015-11-11 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add a comment explaining the opcode suffixes on x86
https://bugs.webkit.org/show_bug.cgi?id=151176
Reviewed by Alex Christensen.
* assembler/X86Assembler.h:
I was always confused with the prefixes. Gavin pointed out the Intel documentation
explains everything.
I added a comment to help the next person confused about those suffixes.
2015-11-11 Benjamin Poulain <bpoulain@apple.com>
[JSC] Support Doubles with B3's Add
https://bugs.webkit.org/show_bug.cgi?id=151164
Reviewed by Filip Pizlo.
I tweaked ReduceStrength a bit to maintain correctness.
Nothing fancy otherwise.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/B3ReduceStrength.cpp:
* b3/B3Value.h:
* b3/B3ValueInlines.h:
(JSC::B3::Value::isInteger):
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::bitWiseEqual):
(JSC::B3::testAddArgDouble):
(JSC::B3::testAddArgsDouble):
(JSC::B3::testAddArgImmDouble):
(JSC::B3::testAddImmArgDouble):
(JSC::B3::testAddImmsDouble):
(JSC::B3::run):
2015-11-11 Filip Pizlo <fpizlo@apple.com>
B3 should be able to compile a program with Switch
https://bugs.webkit.org/show_bug.cgi?id=151115
Reviewed by Benjamin Poulain.
Adds lowering of Switch to a binary switch. This doesn't require any Air support.
* b3/B3BasicBlock.cpp:
(JSC::B3::BasicBlock::append):
(JSC::B3::BasicBlock::removeLast):
(JSC::B3::BasicBlock::replaceLast):
* b3/B3BasicBlock.h:
* b3/B3BlockInsertionSet.cpp:
(JSC::B3::BlockInsertionSet::insertBefore):
(JSC::B3::BlockInsertionSet::insertAfter):
(JSC::B3::BlockInsertionSet::splitForward):
* b3/B3BlockInsertionSet.h:
* b3/B3ControlValue.h:
* b3/B3Generate.cpp:
(JSC::B3::generateToAir):
* b3/B3LowerMacros.cpp:
* b3/B3SwitchValue.cpp:
(JSC::B3::SwitchValue::dumpMeta):
(JSC::B3::SwitchValue::SwitchValue):
* b3/B3SwitchValue.h:
* b3/testb3.cpp:
(JSC::B3::testChillDiv64):
(JSC::B3::testSwitch):
(JSC::B3::run):
2015-11-11 Filip Pizlo <fpizlo@apple.com>
Patchpoints with stackArgument constraints should work
https://bugs.webkit.org/show_bug.cgi?id=151177
Reviewed by Saam Barati.
The only thing broken was that StackmapSpecial's isValidForm would reject Arg::addr, so
validation would fail after allocateStack.
In order for StackmapSpecial to validate Arg::addr, it needs to know the frame size. To know
the frame size, it needs access to Code&. So, this changes Air::Special to always have a
pointer back to Code.
Other than this already worked.
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::isValidImpl):
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::addSpecial):
* b3/air/AirSpecial.cpp:
(JSC::B3::Air::Special::Special):
* b3/air/AirSpecial.h:
(JSC::B3::Air::Special::code):
* b3/testb3.cpp:
(JSC::B3::testSimplePatchpoint):
(JSC::B3::testPatchpointCallArg):
(JSC::B3::testSimpleCheck):
(JSC::B3::run):
2015-11-11 Mark Lam <mark.lam@apple.com>
Add ability to insert probes in LLVM IR that we generate.
https://bugs.webkit.org/show_bug.cgi?id=151159
Reviewed by Geoffrey Garen.
This is done by inserting a stackmap intrinsic and emitting the probe there.
We can now insert probes that take a lambda like so:
probe([] (CCallHelpers::ProbeContext*) {
dataLog("Hello FTL\n");
});
* ftl/FTLCompile.cpp:
* ftl/FTLInlineCacheDescriptor.h:
(JSC::FTL::ProbeDescriptor::ProbeDescriptor):
(JSC::FTL::ProbeDescriptor::probeFunction):
* ftl/FTLInlineCacheSize.cpp:
(JSC::FTL::sizeOfProbe):
* ftl/FTLInlineCacheSize.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::probe):
* ftl/FTLState.h:
2015-11-11 Mark Lam <mark.lam@apple.com>
Change probe CPUState gpr() and fpr() to return references.
https://bugs.webkit.org/show_bug.cgi?id=151154
Reviewed by Saam Barati.
This will allow us to set their values as well as reading them.
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::CPUState::gpr):
(JSC::AbstractMacroAssembler::CPUState::fpr):
(JSC::AbstractMacroAssembler::ProbeContext::gpr):
(JSC::AbstractMacroAssembler::ProbeContext::fpr):
2015-11-11 Mark Lam <mark.lam@apple.com>
Add convenience utility to support dataLogging opcodeIDs.
https://bugs.webkit.org/show_bug.cgi?id=151117
Reviewed by Saam Barati.
* bytecode/Opcode.cpp:
(WTF::printInternal):
* bytecode/Opcode.h:
2015-11-10 Keith Miller <keith_miller@apple.com>
Regression(r191815): 5.3% regression on Dromaeo JS Library Benchmark
https://bugs.webkit.org/show_bug.cgi?id=150945
Reviewed by Filip Pizlo.
This patch fixes a performance regression introduced by r191815. Before adding Symbol.toStringTag
we would cache the value of Object.prototype.toString() in the rareData of the structure.
In order to cache the result of Object.prototype.toString() we now need to ensure that the
value stored in Symbol.toStringTag is a known constant. Thus, in order to ensure the stored Symbol.toStringTag
value remains constant adaptive inferred value watchpoints have been re-factored to be generalizable and
a new version that clears the toString value cache when fired has been added.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp: Copied from Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp.
(JSC::AdaptiveInferredPropertyValueWatchpointBase::AdaptiveInferredPropertyValueWatchpointBase):
(JSC::AdaptiveInferredPropertyValueWatchpointBase::install):
(JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
(JSC::AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint::fireInternal):
(JSC::AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint::fireInternal):
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.h: Copied from Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h.
(JSC::AdaptiveInferredPropertyValueWatchpointBase::key):
(JSC::AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint::StructureWatchpoint):
(JSC::AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint::PropertyWatchpoint):
* dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::AdaptiveInferredPropertyValueWatchpoint):
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::handleFire):
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::install): Deleted.
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::fire): Deleted.
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::StructureWatchpoint::fireInternal): Deleted.
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::PropertyWatchpoint::fireInternal): Deleted.
* dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h:
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::key): Deleted.
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::StructureWatchpoint::StructureWatchpoint): Deleted.
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::PropertyWatchpoint::PropertyWatchpoint): Deleted.
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncToString):
* runtime/Structure.h:
* runtime/StructureInlines.h:
(JSC::Structure::setObjectToStringValue):
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::StructureRareData):
(JSC::StructureRareData::setObjectToStringValue):
(JSC::StructureRareData::clearObjectToStringValue):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
(JSC::ObjectToStringAdaptiveInferredPropertyValueWatchpoint::ObjectToStringAdaptiveInferredPropertyValueWatchpoint):
(JSC::ObjectToStringAdaptiveInferredPropertyValueWatchpoint::handleFire):
* runtime/StructureRareData.h:
* runtime/StructureRareDataInlines.h:
(JSC::StructureRareData::setObjectToStringValue): Deleted.
* tests/stress/symbol-tostringtag-watchpoints.js: Added.
(Base):
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp: Copied from Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp.
(JSC::AdaptiveInferredPropertyValueWatchpointBase::AdaptiveInferredPropertyValueWatchpointBase):
(JSC::AdaptiveInferredPropertyValueWatchpointBase::install):
(JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
(JSC::AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint::fireInternal):
(JSC::AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint::fireInternal):
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.h: Copied from Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h.
(JSC::AdaptiveInferredPropertyValueWatchpointBase::key):
(JSC::AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint::StructureWatchpoint):
(JSC::AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint::PropertyWatchpoint):
* dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::AdaptiveInferredPropertyValueWatchpoint):
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::handleFire):
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::install): Deleted.
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::fire): Deleted.
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::StructureWatchpoint::fireInternal): Deleted.
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::PropertyWatchpoint::fireInternal): Deleted.
* dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h:
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::key): Deleted.
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::StructureWatchpoint::StructureWatchpoint): Deleted.
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::PropertyWatchpoint::PropertyWatchpoint): Deleted.
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncToString):
* runtime/Structure.h:
* runtime/StructureInlines.h:
(JSC::Structure::setObjectToStringValue):
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::StructureRareData):
(JSC::StructureRareData::setObjectToStringValue):
(JSC::StructureRareData::clearObjectToStringValue):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
(JSC::ObjectToStringAdaptiveInferredPropertyValueWatchpoint::ObjectToStringAdaptiveInferredPropertyValueWatchpoint):
(JSC::ObjectToStringAdaptiveInferredPropertyValueWatchpoint::handleFire):
* runtime/StructureRareData.h:
* runtime/StructureRareDataInlines.h:
(JSC::StructureRareData::setObjectToStringValue): Deleted.
* tests/stress/symbol-tostringtag-watchpoints.js: Added.
(Base):
2015-11-11 Filip Pizlo <fpizlo@apple.com>
B3 should be able to compile and canonicalize Mul
https://bugs.webkit.org/show_bug.cgi?id=151124
Reviewed by Geoffrey Garen.
This was a strange trip. I wanted to do a quick patch to implement Mul. But then I realized
that our tradition when adding new lowerings was to also add the corresponding strength
reductions. So then I wrote the Mul->Shl strength reduction. But that reminded me that I needed
to canonicalize between Add(x, x) and Shl(x, 1). I decided that it would probably be better to
use Shl(x, 1), since that only has one use of x. But that means that we should compile
Shl(x, 1) to Add x, x in the backend, since that's what X86 wants. While doing that, I almost
introduced a bug where Shl(Load(x), 1) would cause the compiler to either crash or generate bad
code. That's because I was using Add(x, x) to handle Shl(x, 1), so we'd end up with
Add(Load(x), Load(x)) - i.e. we would try to duplicate the Load.
The instruction selector already defends against this, and the only reason why I would have
created the bug was by using the Add helper when compiling a Shl. Still, this was so close to
a bad bug that I added a ton of new tests that cover the Op(x, x) where x = Load case.
* b3/B3Compilation.cpp:
(JSC::B3::Compilation::Compilation):
* b3/B3Compilation.h:
(JSC::B3::Compilation::code):
* b3/B3Const32Value.cpp:
(JSC::B3::Const32Value::subConstant):
(JSC::B3::Const32Value::mulConstant):
(JSC::B3::Const32Value::bitAndConstant):
* b3/B3Const32Value.h:
* b3/B3Const64Value.cpp:
(JSC::B3::Const64Value::subConstant):
(JSC::B3::Const64Value::mulConstant):
(JSC::B3::Const64Value::bitAndConstant):
* b3/B3Const64Value.h:
* b3/B3ConstDoubleValue.cpp:
(JSC::B3::ConstDoubleValue::subConstant):
(JSC::B3::ConstDoubleValue::mulConstant):
(JSC::B3::ConstDoubleValue::equalConstant):
* b3/B3ConstDoubleValue.h:
* b3/B3Generate.cpp:
(JSC::B3::generate):
(JSC::B3::generateToAir):
* b3/B3Generate.h:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::appendBinOp):
(JSC::B3::Air::LowerToAir::createGenericCompare):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3ReduceStrength.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::subConstant):
(JSC::B3::Value::mulConstant):
(JSC::B3::Value::bitAndConstant):
* b3/B3Value.h:
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::compile):
(JSC::B3::testReturnConst64):
(JSC::B3::testAddArg):
(JSC::B3::testAddArgs):
(JSC::B3::testAddArgs32):
(JSC::B3::testAddLoadTwice):
(JSC::B3::testMulArg):
(JSC::B3::testMulArgs):
(JSC::B3::testMulArgImm):
(JSC::B3::testMulImmArg):
(JSC::B3::testMulArgs32):
(JSC::B3::testMulLoadTwice):
(JSC::B3::testSubArg):
(JSC::B3::testSubArgs):
(JSC::B3::testShlArgImm):
(JSC::B3::testShlArg32):
(JSC::B3::testShlArgs32):
(JSC::B3::testSShrArgImm):
(JSC::B3::testSShrArg32):
(JSC::B3::testSShrArgs32):
(JSC::B3::testZShrArgImm):
(JSC::B3::testZShrArg32):
(JSC::B3::testZShrArgs32):
(JSC::B3::genericTestCompare):
(JSC::B3::testCompareLoad):
(JSC::B3::testCompareImpl):
(JSC::B3::run):
2015-11-11 Yusuke Suzuki <utatane.tea@gmail.com>
Update ES6 Generators' status to "In Development"
https://bugs.webkit.org/show_bug.cgi?id=151142
Reviewed by Saam Barati.
Currently, features.json raises some linting errors.
This should be cleaned up in another patch.
* features.json:
2015-11-10 Filip Pizlo <fpizlo@apple.com>
B3 should be able to compile a program with ChillDiv
https://bugs.webkit.org/show_bug.cgi?id=151114
Reviewed by Benjamin Poulain.
This change is about a lot more than ChillDiv. I picked that as the next thing to lower
because I knew that it would force me to come up with a sensible idiom for doing
stepwise lowerings that require breaking basic blocks. The idea is that you want to
write a loop that iterates forward over the program, which turns some operations that
currently are just single Values into an entire little sub-CFGs. That requires splitting
the block that contained the original Value. That's tricky if you then want to keep
iterating: the index of the Value you were last looking at has now changed and your
InsertionSets are now invalid.
This introduces an idiom that handles this. It's BlockInsertionSet::splitBefore(). The
idea is that it uses the current block before the split as the continuation after the
split. When you call splitBefore(), you pass it your loop index and your InsertionSet
(if applicable). It makes sure that it changes those auxiliary things in such a way that
you can keep looping.
This uncovered some bugs, since this is the first time that we're compiling cross edges.
Because ChillDiv is really a division, I also had to write a bunch of code to support
the ordinary B3 Div. While doing that, I realized that there was asymmetry to that
constness of the Value constant folding methods, so I fixed that as well.
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::mul32):
(JSC::MacroAssemblerX86Common::x86ConvertToDoubleWord32):
(JSC::MacroAssemblerX86Common::x86Div32):
(JSC::MacroAssemblerX86Common::neg32):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::mul64):
(JSC::MacroAssemblerX86_64::x86ConvertToQuadWord64):
(JSC::MacroAssemblerX86_64::x86Div64):
(JSC::MacroAssemblerX86_64::neg64):
* assembler/X86Assembler.h:
(JSC::X86Assembler::idivl_r):
(JSC::X86Assembler::idivq_r):
(JSC::X86Assembler::cmpl_rr):
(JSC::X86Assembler::cdq):
(JSC::X86Assembler::cdqq):
(JSC::X86Assembler::fstps):
* b3/B3BasicBlock.cpp:
(JSC::B3::BasicBlock::append):
(JSC::B3::BasicBlock::replaceLast):
(JSC::B3::BasicBlock::appendIntConstant):
(JSC::B3::BasicBlock::replaceSuccessor):
(JSC::B3::BasicBlock::addPredecessor):
(JSC::B3::BasicBlock::replacePredecessor):
(JSC::B3::BasicBlock::updatePredecessors):
(JSC::B3::BasicBlock::dump):
* b3/B3BasicBlock.h:
(JSC::B3::BasicBlock::values):
(JSC::B3::BasicBlock::numPredecessors):
(JSC::B3::BasicBlock::predecessor):
(JSC::B3::BasicBlock::frequency):
* b3/B3BasicBlockInlines.h:
(JSC::B3::BasicBlock::appendNew):
(JSC::B3::BasicBlock::replaceLastWithNew):
(JSC::B3::BasicBlock::numSuccessors):
* b3/B3BasicBlockUtils.h:
(JSC::B3::replacePredecessor):
(JSC::B3::updatePredecessors):
(JSC::B3::resetReachability):
* b3/B3BlockInsertionSet.cpp: Added.
(JSC::B3::BlockInsertionSet::BlockInsertionSet):
(JSC::B3::BlockInsertionSet::~BlockInsertionSet):
(JSC::B3::BlockInsertionSet::insert):
(JSC::B3::BlockInsertionSet::insertBefore):
(JSC::B3::BlockInsertionSet::splitForward):
(JSC::B3::BlockInsertionSet::execute):
* b3/B3BlockInsertionSet.h: Added.
* b3/B3Common.h:
(JSC::B3::isRepresentableAs):
(JSC::B3::chillDiv):
* b3/B3Const32Value.cpp:
(JSC::B3::Const32Value::addConstant):
(JSC::B3::Const32Value::subConstant):
(JSC::B3::Const32Value::divConstant):
(JSC::B3::Const32Value::bitAndConstant):
(JSC::B3::Const32Value::bitOrConstant):
(JSC::B3::Const32Value::bitXorConstant):
(JSC::B3::Const32Value::shlConstant):
(JSC::B3::Const32Value::sShrConstant):
(JSC::B3::Const32Value::zShrConstant):
(JSC::B3::Const32Value::equalConstant):
(JSC::B3::Const32Value::notEqualConstant):
(JSC::B3::Const32Value::lessThanConstant):
(JSC::B3::Const32Value::greaterThanConstant):
(JSC::B3::Const32Value::lessEqualConstant):
(JSC::B3::Const32Value::greaterEqualConstant):
(JSC::B3::Const32Value::aboveConstant):
(JSC::B3::Const32Value::belowConstant):
(JSC::B3::Const32Value::aboveEqualConstant):
(JSC::B3::Const32Value::belowEqualConstant):
* b3/B3Const32Value.h:
* b3/B3Const64Value.cpp:
(JSC::B3::Const64Value::addConstant):
(JSC::B3::Const64Value::subConstant):
(JSC::B3::Const64Value::divConstant):
(JSC::B3::Const64Value::bitAndConstant):
(JSC::B3::Const64Value::bitOrConstant):
(JSC::B3::Const64Value::bitXorConstant):
(JSC::B3::Const64Value::shlConstant):
(JSC::B3::Const64Value::sShrConstant):
(JSC::B3::Const64Value::zShrConstant):
(JSC::B3::Const64Value::equalConstant):
(JSC::B3::Const64Value::notEqualConstant):
(JSC::B3::Const64Value::lessThanConstant):
(JSC::B3::Const64Value::greaterThanConstant):
(JSC::B3::Const64Value::lessEqualConstant):
(JSC::B3::Const64Value::greaterEqualConstant):
(JSC::B3::Const64Value::aboveConstant):
(JSC::B3::Const64Value::belowConstant):
(JSC::B3::Const64Value::aboveEqualConstant):
(JSC::B3::Const64Value::belowEqualConstant):
* b3/B3Const64Value.h:
* b3/B3ConstDoubleValue.cpp:
(JSC::B3::ConstDoubleValue::addConstant):
(JSC::B3::ConstDoubleValue::subConstant):
(JSC::B3::ConstDoubleValue::divConstant):
(JSC::B3::ConstDoubleValue::equalConstant):
(JSC::B3::ConstDoubleValue::notEqualConstant):
(JSC::B3::ConstDoubleValue::lessThanConstant):
(JSC::B3::ConstDoubleValue::greaterThanConstant):
(JSC::B3::ConstDoubleValue::lessEqualConstant):
(JSC::B3::ConstDoubleValue::greaterEqualConstant):
* b3/B3ConstDoubleValue.h:
* b3/B3ControlValue.cpp:
(JSC::B3::ControlValue::~ControlValue):
(JSC::B3::ControlValue::replaceSuccessor):
(JSC::B3::ControlValue::convertToJump):
* b3/B3ControlValue.h:
* b3/B3Generate.cpp:
(JSC::B3::generateToAir):
* b3/B3GenericFrequentedBlock.h:
(JSC::B3::GenericFrequentedBlock::block):
(JSC::B3::GenericFrequentedBlock::frequency):
(JSC::B3::GenericFrequentedBlock::dump):
* b3/B3InsertionSet.cpp:
(JSC::B3::InsertionSet::insertIntConstant):
(JSC::B3::InsertionSet::execute):
* b3/B3InsertionSet.h:
* b3/B3LowerMacros.cpp: Added.
(JSC::B3::lowerMacros):
* b3/B3LowerMacros.h: Added.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Opcode.h:
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::addBlock):
(JSC::B3::Procedure::addIntConstant):
(JSC::B3::Procedure::addBoolConstant):
(JSC::B3::Procedure::resetValueOwners):
* b3/B3Procedure.h:
(JSC::B3::Procedure::takeByproducts):
* b3/B3ReduceStrength.cpp:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::addConstant):
(JSC::B3::Value::subConstant):
(JSC::B3::Value::divConstant):
(JSC::B3::Value::bitAndConstant):
(JSC::B3::Value::bitOrConstant):
(JSC::B3::Value::bitXorConstant):
(JSC::B3::Value::shlConstant):
(JSC::B3::Value::sShrConstant):
(JSC::B3::Value::zShrConstant):
(JSC::B3::Value::equalConstant):
(JSC::B3::Value::notEqualConstant):
(JSC::B3::Value::lessThanConstant):
(JSC::B3::Value::greaterThanConstant):
(JSC::B3::Value::lessEqualConstant):
(JSC::B3::Value::greaterEqualConstant):
(JSC::B3::Value::aboveConstant):
(JSC::B3::Value::belowConstant):
(JSC::B3::Value::aboveEqualConstant):
(JSC::B3::Value::belowEqualConstant):
* b3/B3Value.h:
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::generate):
* b3/air/AirInstInlines.h:
(JSC::B3::Air::isUrshift64Valid):
(JSC::B3::Air::isX86DivHelperValid):
(JSC::B3::Air::isX86ConvertToDoubleWord32Valid):
(JSC::B3::Air::isX86ConvertToDoubleWord64Valid):
(JSC::B3::Air::isX86Div32Valid):
(JSC::B3::Air::isX86Div64Valid):
* b3/air/AirOpcode.opcodes:
* b3/air/AirSimplifyCFG.cpp:
(JSC::B3::Air::simplifyCFG):
* b3/testb3.cpp:
(JSC::B3::testCallFunctionWithHellaDoubleArguments):
(JSC::B3::testChillDiv):
(JSC::B3::testChillDivTwice):
(JSC::B3::testChillDiv64):
(JSC::B3::run):
* dfg/DFGBlockInsertionSet.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_mod):
* jit/JITArithmetic32_64.cpp:
(JSC::JIT::emit_op_mod):
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::buildBinaryI32):
2015-11-10 Benjamin Poulain <bpoulain@apple.com>
Air should allocate registers
https://bugs.webkit.org/show_bug.cgi?id=150457
Reviewed by Filip Pizlo.
This is a direct implementation of the Iterated Register Coalescing allocator.
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::generate):
* b3/air/AirInstInlines.h:
* b3/air/AirIteratedRegisterCoalescing.cpp: Added.
(JSC::B3::Air::MoveInstHelper<Arg::GP>::mayBeCoalescable):
(JSC::B3::Air::MoveInstHelper<Arg::FP>::mayBeCoalescable):
(JSC::B3::Air::AbsoluteTmpHelper<Arg::GP>::absoluteIndex):
(JSC::B3::Air::AbsoluteTmpHelper<Arg::GP>::tmpFromAbsoluteIndex):
(JSC::B3::Air::AbsoluteTmpHelper<Arg::FP>::absoluteIndex):
(JSC::B3::Air::AbsoluteTmpHelper<Arg::FP>::tmpFromAbsoluteIndex):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::IteratedRegisterCoalescingAllocator):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::build):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::allocate):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::getAlias):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::spilledTmp):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::allocatedReg):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::tmpArraySize):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::initializeDegrees):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::addEdges):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::addEdge):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::makeWorkList):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::simplify):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::forEachAdjacent):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::hasBeenSimplified):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::decrementDegree):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::forEachNodeMoves):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::isMoveRelated):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::enableMovesOnValue):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::enableMovesOnValueAndAdjacents):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::coalesce):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::canBeSafelyCoalesced):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::precoloredCoalescingHeuristic):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::conservativeHeuristic):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::addWorkList):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::combine):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::freeze):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::freezeMoves):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::selectSpill):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::assignColors):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::dumpInterferenceGraphInDot):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::dumpWorkLists):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::InterferenceEdge::InterferenceEdge):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::InterferenceEdge::first):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::InterferenceEdge::second):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::InterferenceEdge::operator==):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::InterferenceEdge::isHashTableDeletedValue):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::InterferenceEdge::hash):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::InterferenceEdgeHash::hash):
(JSC::B3::Air::IteratedRegisterCoalescingAllocator::InterferenceEdgeHash::equal):
(JSC::B3::Air::isUselessMoveInst):
(JSC::B3::Air::assignRegisterToTmpInProgram):
(JSC::B3::Air::addSpillAndFillToProgram):
(JSC::B3::Air::iteratedRegisterCoalescingOnType):
(JSC::B3::Air::iteratedRegisterCoalescing):
* b3/air/AirIteratedRegisterCoalescing.h: Added.
* b3/air/AirTmp.h:
(JSC::B3::Air::Tmp::internalValue):
(JSC::B3::Air::Tmp::tmpForInternalValue):
* b3/testb3.cpp:
(JSC::B3::testSpillGP):
(JSC::B3::run):
2015-11-10 Filip Pizlo <fpizlo@apple.com>
Unreviewed, add a FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=151128.
* b3/air/AirInstInlines.h:
2015-11-10 Saam barati <sbarati@apple.com>
Create an FTLExceptionHandlerManager abstraction
https://bugs.webkit.org/show_bug.cgi?id=151079
Reviewed by Mark Lam.
Before, we used to manage the {stackmapRecordIndex => OSRExit} relationship
for exception handlers with a locally allocated HashMap and a few different
lambdas and random checks. It's cleaner and more manageable to just create
a class that handles this abstraction for us. This class provides nice helper
functions for everything we need. This abstraction makes reading the code easier.
And it will also makes hacking on the code in the future easier.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGOSRExitBase.h:
(JSC::DFG::OSRExitBase::OSRExitBase):
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLExceptionHandlerManager.cpp: Added.
(JSC::FTL::ExceptionHandlerManager::ExceptionHandlerManager):
(JSC::FTL::ExceptionHandlerManager::addNewExit):
(JSC::FTL::ExceptionHandlerManager::getOrPutByIdCallOperationExceptionTarget):
(JSC::FTL::ExceptionHandlerManager::lazySlowPathExceptionTarget):
(JSC::FTL::ExceptionHandlerManager::getByIdOSRExit):
(JSC::FTL::ExceptionHandlerManager::getCallOSRExitCommon):
(JSC::FTL::ExceptionHandlerManager::getCallOSRExit):
(JSC::FTL::ExceptionHandlerManager::procureCallSiteIndex):
* ftl/FTLExceptionHandlerManager.h: Added.
2015-11-10 Michael Saboff <msaboff@apple.com>
X86_64 support for compareDouble(DoubleCondition, FPRegisterID left, FPRegisterID right, RegisterID dest)
https://bugs.webkit.org/show_bug.cgi?id=151009
Reviewed by Filip Pizlo.
Added compareDouble() macro assembler function and the supporting setnp_r() and setp_r() X86 assembler functions.
Hand tested.
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::compare64):
(JSC::MacroAssemblerX86_64::compareDouble):
(JSC::MacroAssemblerX86_64::branch64):
* assembler/X86Assembler.h:
(JSC::X86Assembler::setnz_r):
(JSC::X86Assembler::setnp_r):
(JSC::X86Assembler::setp_r):
(JSC::X86Assembler::cdq):
2015-11-10 Saam barati <sbarati@apple.com>
Rename FTL's ExitArgumentList to something more indicative of what it is
https://bugs.webkit.org/show_bug.cgi?id=151078
Reviewed by Geoffrey Garen.
New name is: StackmapArgumentList
We use this to build patchpoint and stackmap intrinsics in FTLLowerDFGToLLVM.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* ftl/FTLExitArgumentList.h: Removed.
* ftl/FTLJSTailCall.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
(JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
(JSC::FTL::DFG::LowerDFGToLLVM::getById):
(JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
(JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
(JSC::FTL::DFG::LowerDFGToLLVM::emitOSRExitCall):
(JSC::FTL::DFG::LowerDFGToLLVM::buildExitArguments):
(JSC::FTL::DFG::LowerDFGToLLVM::callStackmap):
(JSC::FTL::DFG::LowerDFGToLLVM::exitValueForAvailability):
(JSC::FTL::DFG::LowerDFGToLLVM::exitValueForNode):
(JSC::FTL::DFG::LowerDFGToLLVM::exitArgument):
(JSC::FTL::DFG::LowerDFGToLLVM::exitValueForTailCall):
* ftl/FTLOSRExit.cpp:
* ftl/FTLOSRExit.h:
* ftl/FTLStackmapArgumentList.h: Copied from Source/JavaScriptCore/ftl/FTLExitArgumentList.h.
2015-11-09 Filip Pizlo <fpizlo@apple.com>
[B3] Add more tests for Check and fix bugs this found
https://bugs.webkit.org/show_bug.cgi?id=151073
Reviewed by Saam Barati.
Adds tests for compare/Check fusion. The "MegaCombo" test found a bug in our implementation
of forEachArg: Air::spillEverything() was expecting that the Arg& to point to the actual Arg
so that it can mutate it. But this wasn't the case in B3::CheckSpecial. This fixes that bug.
* b3/B3CheckSpecial.cpp:
(JSC::B3::Air::numB3Args):
(JSC::B3::CheckSpecial::hiddenBranch):
(JSC::B3::CheckSpecial::commitHiddenBranch):
(JSC::B3::CheckSpecial::forEachArg):
* b3/B3CheckSpecial.h:
* b3/testb3.cpp:
(JSC::B3::testSimpleCheck):
(JSC::B3::testCheckLessThan):
(JSC::B3::testCheckMegaCombo):
(JSC::B3::genericTestCompare):
(JSC::B3::run):
2015-11-09 Filip Pizlo <fpizlo@apple.com>
[B3] Add a test for CCall with double arguments and results
https://bugs.webkit.org/show_bug.cgi?id=151064
Reviewed by Saam Barati.
The test already passed on trunk. But when looking at the disassembly, I realized that I had
made a rookie mistake in the call argument marshalling: the stores to the stack went after the
moves to argument registers! This means that arguments that go to stack would be made to
interfere with all argument registers. That's some severe register pressure right there. So,
this change fixes that as well, and adds a FIXME to do it in a more principled manner in Air.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
(JSC::B3::Air::LowerToAir::createStore):
(JSC::B3::Air::LowerToAir::appendStore):
(JSC::B3::Air::LowerToAir::moveForType):
(JSC::B3::Air::LowerToAir::marshallCCallArgument):
* b3/testb3.cpp:
(JSC::B3::testReturnDouble):
(JSC::B3::simpleFunctionDouble):
(JSC::B3::testCallSimpleDouble):
(JSC::B3::functionWithHellaDoubleArguments):
(JSC::B3::testCallFunctionWithHellaDoubleArguments):
(JSC::B3::run):
2015-11-10 Youenn Fablet <youenn.fablet@crf.canon.fr>
Remove create_hash_table options and simplify build system
https://bugs.webkit.org/show_bug.cgi?id=151081
Reviewed by Darin Adler.
* CMakeLists.txt: Merged native and builtin object sources and removed create_hash_table options.
* DerivedSources.make: Ditto.
* create_hash_table: Removed -b and -i options.
2015-11-10 Youenn Fablet <youenn.fablet@crf.canon.fr>
create_hash_table should know whether a function is JSBuiltin or not.
https://bugs.webkit.org/show_bug.cgi?id=151016
Reviewed by Darin Adler.
lut description information can explicitly state that a function is to be implemented as a JS built-in.
To do so, the field used to give the C++ function must be set to "JSBuiltin".
Updated create_hash_table script to handle that.
create_hash_table only includes JSCBuiltins.h if at least one function is set to "JSBuiltin".
Updated builtin generator to remove XX_BUILTIN_EXIST macro.
A further patch should simplify the build system by removing create_hash_table -b option.
Changes to the builtin generator are covered by rebased expectations.
Moved all lut information to using JSBuiltin whenever needed.
* Scripts/builtins/builtins_generate_combined_header.py:
(generate_section_for_object): Deleted.
(generate_section_for_code_table_macro): Deleted.
* Scripts/builtins/builtins_templates.py:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
* create_hash_table:
* runtime/ArrayConstructor.cpp:
* runtime/ArrayIteratorPrototype.cpp:
* runtime/InspectorInstrumentationObject.cpp:
* runtime/JSInternalPromiseConstructor.cpp:
* runtime/JSPromiseConstructor.cpp:
* runtime/JSPromisePrototype.cpp:
* runtime/ModuleLoaderObject.cpp:
* runtime/ObjectConstructor.cpp:
* runtime/ReflectObject.cpp:
* runtime/StringConstructor.cpp:
* runtime/StringIteratorPrototype.cpp:
2015-11-09 Saam barati <sbarati@apple.com>
Implement try/catch in the FTL
https://bugs.webkit.org/show_bug.cgi?id=149409
Reviewed by Filip Pizlo.
This patch implements try/catch in the FTL in a similar
way to how it's implemented in the DFG. The main idea is
this: anytime an exception is thrown in a try block,
we OSR exit into the baseline JIT's corresponding catch
block. We compile OSR exits in a few forms:
1) Explicit exception checks that check VM's exception
pointer. This is modeled explicitly in LLVM IR.
2) OSR exits that are arrived at from genericUnwind
caused by an exception being thrown in a JS call (including
getters and setters).
3) Exception from lazy slow paths.
4) Exception from when an IC misses and makes a slow path C Call.
All stackmaps associated with the above types of exits all
take arguments that correspond to variables that are
bytecode-live in the catch block.
1) Item 1 is the simplest implementation. When inside
a try block, exception checks will emit a branch to
an OSR exit stackmap intrinsic. This stackmap intrinsic
takes as arguments the live catch variables.
2) All forms of calls and GetByIds and PutByIds are implemented
as patchpoints in LLVM. As a patchpoint, they have a stackmap ID.
We use the same stackmap ID for the OSR exit. The OSR exit arguments
are appended to the end of the normal arguments for the patchpoint. These
types of OSR exits are only reached indirectly via genericUnwind.
Therefore, the LLVM IR we generate never has a direct branch to them.
These are the OSR exits we store in the CodeBlock's exception handling
table. The exception handlers' code locations point to the beginning
of the corresponding OSR exit. There is an interesting story here
about how we preserve registers. LLVM patchpoints assume late clobber,
i.e, they assume we use the patchpoint arguments before we clobber them.
Therefore, it's sound for LLVM to pass us arguments in volatile registers.
We must take care to store the arguments in volatile registers to the
stack before making a call. We ensure we have stack space for these
by using LLVM's alloca instruction. Then, when making a call inside
a try block, we spill the needed registers, and if that call throws,
we make sure the OSR exit fills the corresponding registers.
3) Exceptions from lazy slow paths are similar to (2) except they
don't go through generic unwind. These OSR Exits are arrived at from explicit
exception checks in the generated lazy slow path. Therefore, the callframe
is intact when arriving at the OSR exit. We make sure such lazy slow
paths exception check are linked to the OSR exit's code location.
4) This has a really interesting register preservation story.
We may have a GetById that has an IC miss and therefore goes
through the FTL's callOperation machinery. LLVM may also
ask for the result to be placed in the same register as the
base. Therefore, after the call, when storing to the result,
we overwrite the base. This can't fly with exceptions because
operationGetByIdOptimize may throw an exception and return "undefined". What
we really want is the original base value for OSR exit value
recovery. In this case, we take special care to flush the base
value to the stack before the callOperation GetById slow path.
Like call OSR exits, these types of exits will recover the base
value from the stack when necessary.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::newExceptionHandlingCallSiteIndex):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::canOptimizeStringObjectAccess):
(JSC::DFG::Graph::willCatchExceptionInMachineFrame):
* dfg/DFGGraph.h:
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::appendExceptionHandlingOSRExit):
(JSC::DFG::JITCompiler::exceptionCheck):
(JSC::DFG::JITCompiler::recordCallSiteAndGenerateExceptionHandlingOSRExitIfNeeded):
(JSC::DFG::JITCompiler::willCatchExceptionInMachineFrame): Deleted.
* dfg/DFGJITCompiler.h:
* dfg/DFGNodeOrigin.h:
(JSC::DFG::NodeOrigin::withSemantic):
(JSC::DFG::NodeOrigin::withForExitAndExitOK):
(JSC::DFG::NodeOrigin::withExitOK):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::OSRExit):
* dfg/DFGOSRExit.h:
(JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
* dfg/DFGOSRExitBase.h:
(JSC::DFG::OSRExitBase::OSRExitBase):
(JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSite):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
* dfg/DFGPutStackSinkingPhase.cpp:
* dfg/DFGTierUpCheckInjectionPhase.cpp:
(JSC::DFG::TierUpCheckInjectionPhase::run):
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLExitArgument.h:
(JSC::FTL::ExitArgument::withFormat):
(JSC::FTL::ExitArgument::representation):
* ftl/FTLExitThunkGenerator.cpp:
(JSC::FTL::ExitThunkGenerator::~ExitThunkGenerator):
(JSC::FTL::ExitThunkGenerator::emitThunk):
(JSC::FTL::ExitThunkGenerator::emitThunks):
* ftl/FTLExitThunkGenerator.h:
(JSC::FTL::ExitThunkGenerator::didThings):
* ftl/FTLExitValue.h:
(JSC::FTL::ExitValue::isArgument):
(JSC::FTL::ExitValue::isRecovery):
(JSC::FTL::ExitValue::isObjectMaterialization):
(JSC::FTL::ExitValue::hasIndexInStackmapLocations):
(JSC::FTL::ExitValue::exitArgument):
(JSC::FTL::ExitValue::rightRecoveryArgument):
(JSC::FTL::ExitValue::adjustStackmapLocationsIndexByOffset):
(JSC::FTL::ExitValue::recoveryFormat):
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::validateReferences):
(JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
* ftl/FTLJSCall.cpp:
(JSC::FTL::JSCall::JSCall):
(JSC::FTL::JSCall::emit):
* ftl/FTLJSCall.h:
(JSC::FTL::JSCall::stackmapID):
* ftl/FTLJSCallBase.cpp:
(JSC::FTL::JSCallBase::JSCallBase):
(JSC::FTL::JSCallBase::emit):
* ftl/FTLJSCallBase.h:
(JSC::FTL::JSCallBase::setCallSiteIndex):
(JSC::FTL::JSCallBase::callSiteDescriptionOrigin):
(JSC::FTL::JSCallBase::setCorrespondingGenericUnwindOSRExit):
* ftl/FTLJSCallVarargs.cpp:
(JSC::FTL::JSCallVarargs::numSpillSlotsNeeded):
(JSC::FTL::JSCallVarargs::emit):
* ftl/FTLJSCallVarargs.h:
(JSC::FTL::JSCallVarargs::stackmapID):
(JSC::FTL::JSCallVarargs::operator<):
(JSC::FTL::JSCallVarargs::setCallSiteIndex):
(JSC::FTL::JSCallVarargs::callSiteDescriptionOrigin):
(JSC::FTL::JSCallVarargs::setCorrespondingGenericUnwindOSRExit):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::lower):
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
(JSC::FTL::DFG::LowerDFGToLLVM::getById):
(JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
(JSC::FTL::DFG::LowerDFGToLLVM::speculate):
(JSC::FTL::DFG::LowerDFGToLLVM::terminate):
(JSC::FTL::DFG::LowerDFGToLLVM::appendTypeCheck):
(JSC::FTL::DFG::LowerDFGToLLVM::callPreflight):
(JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
(JSC::FTL::DFG::LowerDFGToLLVM::emitBranchToOSRExitIfWillCatchException):
(JSC::FTL::DFG::LowerDFGToLLVM::lowBlock):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitDescriptor):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
(JSC::FTL::DFG::LowerDFGToLLVM::exitValueForNode):
* ftl/FTLOSRExit.cpp:
(JSC::FTL::OSRExitDescriptor::OSRExitDescriptor):
(JSC::FTL::OSRExit::OSRExit):
(JSC::FTL::OSRExit::codeLocationForRepatch):
(JSC::FTL::OSRExit::gatherRegistersToSpillForCallIfException):
(JSC::FTL::OSRExit::spillRegistersToSpillSlot):
(JSC::FTL::OSRExit::recoverRegistersFromSpillSlot):
* ftl/FTLOSRExit.h:
(JSC::FTL::OSRExit::considerAddingAsFrequentExitSite):
* ftl/FTLOSRExitCompilationInfo.h:
(JSC::FTL::OSRExitCompilationInfo::OSRExitCompilationInfo):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
(JSC::FTL::compileFTLOSRExit):
* ftl/FTLState.cpp:
(JSC::FTL::State::State):
* ftl/FTLState.h:
* interpreter/Interpreter.cpp:
(JSC::findExceptionHandler):
* jit/RegisterSet.cpp:
(JSC::RegisterSet::specialRegisters):
(JSC::RegisterSet::volatileRegistersForJSCall):
(JSC::RegisterSet::stubUnavailableRegisters):
* jit/RegisterSet.h:
* tests/stress/ftl-try-catch-getter-ic-fail-to-call-operation-throw-error.js: Added.
(assert):
(let.oThrow.get f):
(let.o2.get f):
(foo):
(f):
* tests/stress/ftl-try-catch-getter-throw.js: Added.
(assert):
(random):
(foo):
(f):
(let.o2.get f):
* tests/stress/ftl-try-catch-oom-error-lazy-slow-path.js: Added.
(assert):
(a):
(b):
(c):
(d):
(e):
(f):
(g):
(foo):
(blah):
* tests/stress/ftl-try-catch-patchpoint-with-volatile-registers.js: Added.
(assert):
(o1.get f):
(a):
(b):
(c):
(d):
(e):
(f):
(g):
(o2.get f):
(foo):
* tests/stress/ftl-try-catch-setter-throw.js: Added.
(foo):
(assert):
(f):
(let.o2.set f):
* tests/stress/ftl-try-catch-tail-call-inilned-caller.js: Added.
(value):
(assert):
(validate):
(bar):
(baz):
(jaz):
* tests/stress/ftl-try-catch-varargs-call-throws.js: Added.
(foo):
(f):
* tests/stress/try-catch-stub-routine-replaced.js:
(hello):
(foo):
2015-11-09 Youenn Fablet <youenn.fablet@crf.canon.fr>
Built-in generator should check that there are no duplicate in JS built-in internal functions
https://bugs.webkit.org/show_bug.cgi?id=151018
Reviewed by Brian Burg.
Added @internal to corresponding JS built-in files.
Added check in built-in generator so that clashing names result in an error.
* Scripts/builtins/builtins_generate_combined_header.py:
(generate_section_for_code_name_macro):
* Scripts/builtins/builtins_model.py:
(BuiltinsCollection.all_internal_functions):
* builtins/GlobalObject.js:
* builtins/Operations.Promise.js:
* Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-error: Added.
* Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result: Added.
2015-11-09 Saam barati <sbarati@apple.com>
DFG::PutStackSinkingPhase should not treat the stack variables written by LoadVarargs/ForwardVarargs as being live
https://bugs.webkit.org/show_bug.cgi?id=145295
Reviewed by Filip Pizlo.
This patch fixes PutStackSinkingPhase to no longer escape the stack
locations that LoadVarargs and ForwardVarargs write to. We used
to consider sinking PutStacks right before a LoadVarargs/ForwardVarargs
because we considered them uses of such stack locations. They aren't
uses of those stack locations, they unconditionally write to those
stack locations. Sinking PutStacks to these nodes was not needed before,
but seemed mostly innocent. But I ran into a problem with this while implementing
FTL try/catch where we would end up having to generate a value for a sunken PutStack
right before a LoadVarargs. This would cause us to issue a GetStack that loaded garbage that
was then forwarded into a Phi that was used as the source as the PutStack. This caused the
abstract interpreter to confuse itself on type information for the garbage GetStack
that was fed into the Phi, which would cause the abstract interpreter to then claim
that the basic block with the PutStack in it would never be reached. This isn't true, the
block would indeed be reached. The solution here is to be more precise about the
liveness of locals w.r.t LoadVarargs and ForwardVarargs.
* dfg/DFGPreciseLocalClobberize.h:
(JSC::DFG::PreciseLocalClobberizeAdaptor::PreciseLocalClobberizeAdaptor):
(JSC::DFG::PreciseLocalClobberizeAdaptor::write):
* dfg/DFGPutStackSinkingPhase.cpp:
* dfg/DFGSSACalculator.h:
2015-11-09 Filip Pizlo <fpizlo@apple.com>
B3->Air lowering should support CCall
https://bugs.webkit.org/show_bug.cgi?id=151043
Reviewed by Geoffrey Garen.
Adds support for lowering CCall to Air, and adds a test that makes calls. I cannot test doubles
until https://bugs.webkit.org/show_bug.cgi?id=151002 lands, but this does test integer
arguments pretty thoroughly including a test for lots of arguments. That test ensures that the
arguments go to registers and the stack in the right order and such.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::createCompare):
(JSC::B3::Air::LowerToAir::marshallCCallArgument):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Opcode.h:
* b3/air/AirCCallSpecial.cpp:
(JSC::B3::Air::CCallSpecial::forEachArg):
(JSC::B3::Air::CCallSpecial::isValid):
(JSC::B3::Air::CCallSpecial::admitsStack):
(JSC::B3::Air::CCallSpecial::generate):
* b3/air/AirCCallSpecial.h:
* b3/testb3.cpp:
(JSC::B3::testCompare):
(JSC::B3::simpleFunction):
(JSC::B3::testCallSimple):
(JSC::B3::functionWithHellaArguments):
(JSC::B3::testCallFunctionWithHellaArguments):
(JSC::B3::run):
* jit/FPRInfo.h:
2015-11-09 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: $0 stops working after navigating to a different domain
https://bugs.webkit.org/show_bug.cgi?id=147962
Reviewed by Brian Burg.
Extract the per-GlobalObject cache of JSValue wrappers for
InjectedScriptHost objects to be reused by WebCore for its
CommandLineAPIHost objects injected into multiple contexts.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
Add new files.
* inspector/PerGlobalObjectWrapperWorld.h:
* inspector/PerGlobalObjectWrapperWorld.cpp:
(Inspector::PerGlobalObjectWrapperWorld::getWrapper):
(Inspector::PerGlobalObjectWrapperWorld::addWrapper):
(Inspector::PerGlobalObjectWrapperWorld::clearAllWrappers):
Hold a bunch of per-global-object wrappers for an object
that will outlive the global object. This inspector does this
for host objects that it exposes into scripts it injects into
each execution context created by the page.
* inspector/InjectedScriptHost.cpp:
(Inspector::InjectedScriptHost::wrapper):
(Inspector::InjectedScriptHost::clearAllWrappers):
(Inspector::InjectedScriptHost::jsWrapper): Deleted.
(Inspector::clearWrapperFromValue): Deleted.
(Inspector::InjectedScriptHost::clearWrapper): Deleted.
Extract and simplify the Per-GlobalObject wrapping into a class.
Simplify object construction as well.
* inspector/InjectedScriptHost.h:
* inspector/InjectedScriptManager.cpp:
(Inspector::InjectedScriptManager::createInjectedScript):
(Inspector::InjectedScriptManager::discardInjectedScripts):
Make discarding virtual so subclasses may also discard injected scripts.
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::JSInjectedScriptHost):
(Inspector::JSInjectedScriptHost::releaseImpl): Deleted.
(Inspector::JSInjectedScriptHost::~JSInjectedScriptHost): Deleted.
(Inspector::toJS): Deleted.
(Inspector::toJSInjectedScriptHost): Deleted.
* inspector/JSInjectedScriptHost.h:
(Inspector::JSInjectedScriptHost::create):
(Inspector::JSInjectedScriptHost::impl):
Update this code originally copied from older generated bindings to
be more like new generated bindings and remove some now unused code.
2015-11-08 Filip Pizlo <fpizlo@apple.com>
B3 should be able to compile a program with a double constant
https://bugs.webkit.org/show_bug.cgi?id=151002
Reviewed by Benjamin Poulain.
This implements a bunch of annoying stuff that is necessary to support constants that need a
data section, such as double constants on X86_64:
- B3::Procedure can now tell you what to keep alive in addition to the MacroAssemblerCodeRef.
We call this the B3::OpaqueByproducts. It's the client's responsibility to keep this alive
after calling B3::generate().
- Added a new helper for compiling B3 code, called B3::Compilation. Constructing a
Compilation runs the compiler. Then you can pass around a Compilation the way you would
have passed around a MacroAssemblerCodeRef.
- Added a constant motion phase, called moveConstants(). This does very simple constant
hoisting/sinking: it makes sure that each constant is only materialized in one place in
each basic block. It uses a DataSection, which is a kind of OpaqueByproduct, to store
double constants.
- The way I wanted to do constant motion is to basically track what constants are of interest
and then recreate them as needed, so the original Values become irrelevant in the process.
To do that, I needed an abstraction that is almost identical to the DFG PureValue
abstraction that we use for CSE. So, I created such a thing, and called it ValueKey. It
can be used to compare and hash pure Values, and to recreate them as needed.
- Fixed the lowering's handling of constants so that we don't perturb the placement of the
constant materializations.
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::branchConvertDoubleToInt32):
(JSC::MacroAssemblerX86Common::moveZeroToDouble):
(JSC::MacroAssemblerX86Common::branchDoubleNonZero):
* b3/B3Common.h:
(JSC::B3::isIdentical):
(JSC::B3::isRepresentableAsImpl):
* b3/B3Compilation.cpp: Added.
(JSC::B3::Compilation::Compilation):
(JSC::B3::Compilation::~Compilation):
* b3/B3Compilation.h: Added.
(JSC::B3::Compilation::code):
* b3/B3ConstDoubleValue.h:
(JSC::B3::ConstDoubleValue::accepts): Deleted.
* b3/B3DataSection.cpp: Added.
(JSC::B3::DataSection::DataSection):
(JSC::B3::DataSection::~DataSection):
(JSC::B3::DataSection::dump):
* b3/B3DataSection.h: Added.
(JSC::B3::DataSection::data):
(JSC::B3::DataSection::size):
* b3/B3Generate.cpp:
(JSC::B3::generate):
(JSC::B3::generateToAir):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::imm):
(JSC::B3::Air::LowerToAir::immOrTmp):
(JSC::B3::Air::LowerToAir::fillStackmap):
(JSC::B3::Air::LowerToAir::lower):
(JSC::B3::Air::LowerToAir::immForMove): Deleted.
(JSC::B3::Air::LowerToAir::immOrTmpForMove): Deleted.
* b3/B3MoveConstants.cpp: Added.
(JSC::B3::moveConstants):
* b3/B3MoveConstants.h: Added.
* b3/B3OpaqueByproduct.h: Added.
(JSC::B3::OpaqueByproduct::OpaqueByproduct):
(JSC::B3::OpaqueByproduct::~OpaqueByproduct):
* b3/B3OpaqueByproducts.cpp: Added.
(JSC::B3::OpaqueByproducts::OpaqueByproducts):
(JSC::B3::OpaqueByproducts::~OpaqueByproducts):
(JSC::B3::OpaqueByproducts::add):
(JSC::B3::OpaqueByproducts::dump):
* b3/B3OpaqueByproducts.h: Added.
(JSC::B3::OpaqueByproducts::count):
* b3/B3Opcode.h:
(JSC::B3::constPtrOpcode):
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::Procedure):
(JSC::B3::Procedure::dump):
(JSC::B3::Procedure::blocksInPreOrder):
(JSC::B3::Procedure::deleteValue):
(JSC::B3::Procedure::addDataSection):
(JSC::B3::Procedure::addValueIndex):
* b3/B3Procedure.h:
(JSC::B3::Procedure::lastPhaseName):
(JSC::B3::Procedure::byproducts):
(JSC::B3::Procedure::takeByproducts):
* b3/B3Type.h:
* b3/B3Value.cpp:
(JSC::B3::Value::effects):
(JSC::B3::Value::key):
(JSC::B3::Value::performSubstitution):
* b3/B3Value.h:
* b3/B3ValueKey.cpp: Added.
(JSC::B3::ValueKey::dump):
(JSC::B3::ValueKey::materialize):
* b3/B3ValueKey.h: Added.
(JSC::B3::ValueKey::ValueKey):
(JSC::B3::ValueKey::opcode):
(JSC::B3::ValueKey::type):
(JSC::B3::ValueKey::childIndex):
(JSC::B3::ValueKey::value):
(JSC::B3::ValueKey::doubleValue):
(JSC::B3::ValueKey::operator==):
(JSC::B3::ValueKey::operator!=):
(JSC::B3::ValueKey::hash):
(JSC::B3::ValueKey::operator bool):
(JSC::B3::ValueKey::canMaterialize):
(JSC::B3::ValueKey::isHashTableDeletedValue):
(JSC::B3::ValueKeyHash::hash):
(JSC::B3::ValueKeyHash::equal):
* b3/B3ValueKeyInlines.h: Added.
(JSC::B3::ValueKey::ValueKey):
(JSC::B3::ValueKey::child):
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::Code):
* b3/air/AirCode.h:
(JSC::B3::Air::Code::proc):
(JSC::B3::Air::Code::lastPhaseName):
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::compile):
(JSC::B3::invoke):
(JSC::B3::compileAndRun):
(JSC::B3::test42):
(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::testBranchFold):
(JSC::B3::testSimpleCheck):
(JSC::B3::testCompare):
(JSC::B3::testReturnDouble):
(JSC::B3::run):
2015-11-09 Michael Saboff <msaboff@apple.com>
Need a function that will provide Nth argument register
https://bugs.webkit.org/show_bug.cgi?id=151041
Reviewed by Filip Pizlo.
For 64 bit platforms, return the Nth architected argument register, otherwise InvalidGPRReg.
* jit/GPRInfo.h:
(JSC::argumentRegisterFor): Added to return the Nth architected argument register if defined
for a platform or InvalidGPRReg if not.
2015-11-09 Csaba Osztrogonác <ossy@webkit.org>
[FTL] Fix the build with LLVM 3.7
https://bugs.webkit.org/show_bug.cgi?id=150595
Reviewed by Darin Adler.
* llvm/LLVMAPIFunctions.h: Removed the unused BuildLandingPad function.
2015-11-09 Xabier Rodriguez Calvar <calvaris@igalia.com>
[Streams API] Shield implementation from mangling then and catch promise methods
https://bugs.webkit.org/show_bug.cgi?id=150934
Reviewed by Youenn Fablet.
Since the prototype is not deletable and readonly we only have to care about ensuring that it has the right
@then and @catch internal methods.
* runtime/JSPromisePrototype.h:
* runtime/JSPromisePrototype.cpp:
(JSC::JSPromisePrototype::addOwnInternalSlots): Added to create the proper @then and @catch internal slots.
(JSC::JSPromisePrototype::create): Call addOwnInternalSlots.
2015-11-09 Youenn Fablet <youenn.fablet@crf.canon.fr>
JS Built-ins functions should be able to assert
https://bugs.webkit.org/show_bug.cgi?id=150333
Reviewed by Yusuke Suzuki.
Introduced @assert to enable asserting in JS built-ins.
Adding a new bytecode 'assert' to implement it.
In debug builds, @assert generates 'assert' bytecodes.
In release builds, no byte code is produced for @assert.
In case assert is false, the JS built-in and the line number are dumped.
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitAssert):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp: Generating op_assert bytecode for @assert for Debug builds.
(JSC::BytecodeIntrinsicNode::emit_intrinsic_assert):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_assert):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_create_assert):
* llint/LowLevelInterpreter.asm:
* runtime/CommonIdentifiers.h: Adding @assert identifier as intrinsic.
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
2015-11-08 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Minimize ES6_CLASS_SYNTAX ifdefs
https://bugs.webkit.org/show_bug.cgi?id=151006
Reviewed by Darin Adler.
This patch minimizes ENABLE_ES6_CLASS_SYNTAX ifdefs.
It keeps several ENABLE_ES6_CLASS_SYNTAX ifdefs in Parser.cpp.
- super meta property
- class declaration parsing
- class expression parsing
- class with import declaration
This change makes difference minimal between the enabled and disabled configurations;
reducing accidental build breaks of the disabled configuration.
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::constructorKind): Deleted.
* bytecompiler/NodesCodegen.cpp:
* parser/ASTBuilder.h:
* parser/NodeConstructors.h:
* parser/Nodes.h:
* parser/Parser.cpp:
* parser/Parser.h:
(JSC::Scope::hasDirectSuper): Deleted.
(JSC::Scope::needsSuperBinding): Deleted.
* parser/ParserFunctionInfo.h:
* parser/ParserTokens.h:
* parser/SyntaxChecker.h:
2015-11-08 Sukolsak Sakshuwong <sukolsak@gmail.com>
Use StringView::upconvertedCharacters() to make a 16-bit copy in String.prototype.normalize
https://bugs.webkit.org/show_bug.cgi?id=151005
Reviewed by Michael Saboff.
The ICU's unorm_normalize function used by String.prototype.normalize
requires a 16-bit string. This patch uses StringView::upconvertedCharacters()
to make a 16-bit copy of a string.
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncNormalize):
2015-11-08 Youenn Fablet <youenn.fablet@crf.canon.fr>
generate-js-builtins.js should support @internal annotation
https://bugs.webkit.org/show_bug.cgi?id=150929
Reviewed by Darin Adler.
* Scripts/builtins/builtins_generate_separate_header.py:
(BuiltinsSeparateHeaderGenerator.generate_output): Generate internal boilerplate code only if @internal annotation is available.
* Scripts/builtins/builtins_templates.py: Split boilerplate in two templates (one that is used for all built-ins and one dedicated to internals).
* Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result: Removed internal boilerplate.
* Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result: Ditto.
* Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result: Ditto.
2015-11-08 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Minimize ENABLE_ES6_TEMPLATE_LITERAL_SYNTAX ifdefs
https://bugs.webkit.org/show_bug.cgi?id=150998
Reviewed by Geoffrey Garen.
This patch minimizes ENABLE_ES6_TEMPLATE_LITERAL_SYNTAX ifdefs.
It only keeps 2 ENABLE_ES6_TEMPLATE_LITERAL_SYNTAX in Parser.cpp, one for
template literals and one for tagged templates.
This change makes difference minimal between the enabled and disabled configurations;
reducing accidental build breaks of the disabled configuration.
* bytecompiler/BytecodeGenerator.cpp:
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
* parser/ASTBuilder.h:
* parser/Lexer.cpp:
(JSC::Lexer<T>::Lexer): Deleted.
(JSC::Lexer<T>::lex): Deleted.
* parser/Lexer.h:
* parser/NodeConstructors.h:
* parser/Nodes.h:
* parser/Parser.cpp:
* parser/Parser.h:
* parser/SyntaxChecker.h:
2015-11-06 Filip Pizlo <fpizlo@apple.com>
B3->Air lowering should do pattern matching the old fashioned way
https://bugs.webkit.org/show_bug.cgi?id=150994
Reviewed by Geoffrey Garen.
When I first wrote the B3->Air lowering prototype, I was convinced that the patterns would get
so gnarly that we'd want a pattern language to write them in. So I made one, and that's what
the lowering has used. But as we've worked with the IR, we've found that it's very easy to
pattern match in C++ using the B3 API, and we've also found that most of the patterns we wrote
using the pattern language were mostly trivial. So this change removes the pattern match code
generator and the patterns files, and redoes the lowering using good old fashioned switch
statements. This actually reduces the total code of the lowering.
I also took the opportunity to refactoring UnOp and BinOp lowering. We had a lot of repetetive
code for 32-vs-64-bit opcode selection, so I factored that out into a helper. This also saves a
lot of code.
* CMakeLists.txt:
* DerivedSources.make:
* b3/B3AddressMatcher.patterns: Removed.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::LowerToAir):
(JSC::B3::Air::LowerToAir::run):
(JSC::B3::Air::LowerToAir::highBitsAreZero):
(JSC::B3::Air::LowerToAir::tmp):
(JSC::B3::Air::LowerToAir::canBeInternal):
(JSC::B3::Air::LowerToAir::commitInternal):
(JSC::B3::Air::LowerToAir::crossesInterference):
(JSC::B3::Air::LowerToAir::effectiveAddr):
(JSC::B3::Air::LowerToAir::addr):
(JSC::B3::Air::LowerToAir::loadPromise):
(JSC::B3::Air::LowerToAir::imm):
(JSC::B3::Air::LowerToAir::immForMove):
(JSC::B3::Air::LowerToAir::immOrTmpForMove):
(JSC::B3::Air::LowerToAir::tryOpcodeForType):
(JSC::B3::Air::LowerToAir::opcodeForType):
(JSC::B3::Air::LowerToAir::appendUnOp):
(JSC::B3::Air::LowerToAir::appendBinOp):
(JSC::B3::Air::LowerToAir::appendShift):
(JSC::B3::Air::LowerToAir::tryAppendStoreUnOp):
(JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
(JSC::B3::Air::LowerToAir::append):
(JSC::B3::Air::LowerToAir::ensureSpecial):
(JSC::B3::Air::LowerToAir::fillStackmap):
(JSC::B3::Air::LowerToAir::createGenericCompare):
(JSC::B3::Air::LowerToAir::createBranch):
(JSC::B3::Air::LowerToAir::createCompare):
(JSC::B3::Air::LowerToAir::lower):
(JSC::B3::Air::LowerToAir::immOrTmp): Deleted.
(JSC::B3::Air::LowerToAir::AddressSelector::AddressSelector): Deleted.
(JSC::B3::Air::LowerToAir::AddressSelector::acceptRoot): Deleted.
(JSC::B3::Air::LowerToAir::AddressSelector::acceptRootLate): Deleted.
(JSC::B3::Air::LowerToAir::AddressSelector::acceptInternals): Deleted.
(JSC::B3::Air::LowerToAir::AddressSelector::acceptInternalsLate): Deleted.
(JSC::B3::Air::LowerToAir::AddressSelector::acceptOperands): Deleted.
(JSC::B3::Air::LowerToAir::AddressSelector::acceptOperandsLate): Deleted.
(JSC::B3::Air::LowerToAir::AddressSelector::tryAddShift1): Deleted.
(JSC::B3::Air::LowerToAir::AddressSelector::tryAddShift2): Deleted.
(JSC::B3::Air::LowerToAir::AddressSelector::tryAdd): Deleted.
(JSC::B3::Air::LowerToAir::AddressSelector::tryFramePointer): Deleted.
(JSC::B3::Air::LowerToAir::AddressSelector::tryStackSlot): Deleted.
(JSC::B3::Air::LowerToAir::AddressSelector::tryDirect): Deleted.
(JSC::B3::Air::LowerToAir::acceptRoot): Deleted.
(JSC::B3::Air::LowerToAir::acceptRootLate): Deleted.
(JSC::B3::Air::LowerToAir::acceptInternals): Deleted.
(JSC::B3::Air::LowerToAir::acceptInternalsLate): Deleted.
(JSC::B3::Air::LowerToAir::acceptOperands): Deleted.
(JSC::B3::Air::LowerToAir::acceptOperandsLate): Deleted.
(JSC::B3::Air::LowerToAir::tryLoad): Deleted.
(JSC::B3::Air::LowerToAir::tryLoad8S): Deleted.
(JSC::B3::Air::LowerToAir::tryLoad8Z): Deleted.
(JSC::B3::Air::LowerToAir::tryLoad16S): Deleted.
(JSC::B3::Air::LowerToAir::tryLoad16Z): Deleted.
(JSC::B3::Air::LowerToAir::tryAdd): Deleted.
(JSC::B3::Air::LowerToAir::trySub): Deleted.
(JSC::B3::Air::LowerToAir::tryAnd): Deleted.
(JSC::B3::Air::LowerToAir::tryOr): Deleted.
(JSC::B3::Air::LowerToAir::tryXor): Deleted.
(JSC::B3::Air::LowerToAir::tryShl): Deleted.
(JSC::B3::Air::LowerToAir::trySShr): Deleted.
(JSC::B3::Air::LowerToAir::tryZShr): Deleted.
(JSC::B3::Air::LowerToAir::tryStoreAddLoad): Deleted.
(JSC::B3::Air::LowerToAir::tryStoreSubLoad): Deleted.
(JSC::B3::Air::LowerToAir::tryStoreAndLoad): Deleted.
(JSC::B3::Air::LowerToAir::tryStore): Deleted.
(JSC::B3::Air::LowerToAir::tryTrunc): Deleted.
(JSC::B3::Air::LowerToAir::tryZExt32): Deleted.
(JSC::B3::Air::LowerToAir::tryArgumentReg): Deleted.
(JSC::B3::Air::LowerToAir::tryConst32): Deleted.
(JSC::B3::Air::LowerToAir::tryConst64): Deleted.
(JSC::B3::Air::LowerToAir::tryFramePointer): Deleted.
(JSC::B3::Air::LowerToAir::tryStackSlot): Deleted.
(JSC::B3::Air::LowerToAir::tryEqual): Deleted.
(JSC::B3::Air::LowerToAir::tryNotEqual): Deleted.
(JSC::B3::Air::LowerToAir::tryLessThan): Deleted.
(JSC::B3::Air::LowerToAir::tryGreaterThan): Deleted.
(JSC::B3::Air::LowerToAir::tryLessEqual): Deleted.
(JSC::B3::Air::LowerToAir::tryGreaterEqual): Deleted.
(JSC::B3::Air::LowerToAir::tryAbove): Deleted.
(JSC::B3::Air::LowerToAir::tryBelow): Deleted.
(JSC::B3::Air::LowerToAir::tryAboveEqual): Deleted.
(JSC::B3::Air::LowerToAir::tryBelowEqual): Deleted.
(JSC::B3::Air::LowerToAir::tryPatchpoint): Deleted.
(JSC::B3::Air::LowerToAir::tryCheck): Deleted.
(JSC::B3::Air::LowerToAir::tryUpsilon): Deleted.
(JSC::B3::Air::LowerToAir::tryPhi): Deleted.
(JSC::B3::Air::LowerToAir::tryBranch): Deleted.
(JSC::B3::Air::LowerToAir::tryJump): Deleted.
(JSC::B3::Air::LowerToAir::tryIdentity): Deleted.
(JSC::B3::Air::LowerToAir::tryReturn): Deleted.
* b3/B3LoweringMatcher.patterns: Removed.
* b3/generate_pattern_matcher.rb: Removed.
2015-11-07 Michael Saboff <msaboff@apple.com>
Add conditional moves to the MacroAssembler
https://bugs.webkit.org/show_bug.cgi?id=150761
Reviewed by Filip Pizlo.
Added moveConditionally, moveConditionallyTest & moveConditionallyDouble to X86 macro assemblers.
Bench tested correct opcodes and operations on X86-64 and X86 for a select number of comparisons.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::moveConditionally):
(JSC::MacroAssemblerX86Common::moveConditionallyTest):
(JSC::MacroAssemblerX86Common::moveConditionallyDouble):
* assembler/X86Assembler.h:
(JSC::X86Assembler::cmovcc):
(JSC::X86Assembler::cmovl_rr):
(JSC::X86Assembler::cmovl_mr):
(JSC::X86Assembler::cmovel_rr):
(JSC::X86Assembler::cmovnel_rr):
(JSC::X86Assembler::cmovpl_rr):
(JSC::X86Assembler::cmovnpl_rr):
(JSC::X86Assembler::cmovq_rr):
(JSC::X86Assembler::cmovq_mr):
(JSC::X86Assembler::cmoveq_rr):
(JSC::X86Assembler::cmovneq_rr):
(JSC::X86Assembler::cmovpq_rr):
(JSC::X86Assembler::cmovnpq_rr):
(JSC::X86Assembler::X86InstructionFormatter::twoByteOp64):
2015-11-06 Saam barati <sbarati@apple.com>
Control Flow Profiler should keep execution counts of basic blocks
https://bugs.webkit.org/show_bug.cgi?id=146099
Reviewed by Mark Lam.
This patch changes the control flow profiler to now
keep track of execution counts for each basic block
instead of a boolean indicating if the basic block has
executed at all. This has the consequence of us having to
always compile all op_profile_control_flows in the baseline and DFG.
This patch adds a new "executionCount" field to the inspector protocol
corresponding to the execution of a basic block. This patch, for now,
still maintains the previous field of "hasExecuted" even though this is
redundant with "executionCount".
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::getBasicBlocks):
* inspector/protocol/Runtime.json:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_profile_control_flow):
(JSC::JIT::emit_op_create_direct_arguments):
* jsc.cpp:
(GlobalObject::finishCreation):
(functionHasBasicBlockExecuted):
(functionBasicBlockExecutionCount):
(functionEnableExceptionFuzz):
(functionDrainMicrotasks):
(functionIs32BitPlatform):
(functionLoadWebAssembly):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/BasicBlockLocation.cpp:
(JSC::BasicBlockLocation::BasicBlockLocation):
(JSC::BasicBlockLocation::dumpData):
(JSC::BasicBlockLocation::emitExecuteCode):
* runtime/BasicBlockLocation.h:
(JSC::BasicBlockLocation::endOffset):
(JSC::BasicBlockLocation::setStartOffset):
(JSC::BasicBlockLocation::setEndOffset):
(JSC::BasicBlockLocation::hasExecuted):
(JSC::BasicBlockLocation::executionCount):
* runtime/ControlFlowProfiler.cpp:
(JSC::ControlFlowProfiler::getBasicBlocksForSourceID):
(JSC::findBasicBlockAtTextOffset):
(JSC::ControlFlowProfiler::hasBasicBlockAtTextOffsetBeenExecuted):
(JSC::ControlFlowProfiler::basicBlockExecutionCountAtTextOffset):
* runtime/ControlFlowProfiler.h:
(JSC::ControlFlowProfiler::dummyBasicBlock):
* tests/controlFlowProfiler/execution-count.js: Added.
(noop):
(foo):
(a):
(b):
(baz):
(jaz):
(testWhile):
(is32BitPlatform.testMax):
(is32BitPlatform):
2015-11-06 Filip Pizlo <fpizlo@apple.com>
B3 and Air should simplify CFGs
https://bugs.webkit.org/show_bug.cgi?id=150960
Reviewed by Geoffrey Garen.
This adds CFG simplification to both B3 and Air.
In B3, the simplification is done inside the B3::reduceStrength() fixpoint because we expect
that it will help to reveal more optimization opportunities. This is going to be particularly
true when we add Phi elimination.
In Air, the simplification is its own phase. We expect it to produce most of its benefits once
we have coalescing. Then, CFG simplification in Air will unbreak critial edges.
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/AbortReason.h:
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::oops): Reveal this as a method so that we can have an Oops instruction.
* b3/B3BasicBlock.h:
(JSC::B3::BasicBlock::predecessor):
(JSC::B3::BasicBlock::predecessors):
(JSC::B3::BasicBlock::containsPredecessor):
* b3/B3BasicBlockUtils.h: Bunch of fixes for blocks being killed.
(JSC::B3::replacePredecessor):
(JSC::B3::resetReachability):
* b3/B3ReduceStrength.cpp: Implement B3 CFG simplification.
* b3/B3ReduceStrength.h:
* b3/air/AirBasicBlock.h:
(JSC::B3::Air::BasicBlock::resize):
(JSC::B3::Air::BasicBlock::insts):
(JSC::B3::Air::BasicBlock::appendInst):
(JSC::B3::Air::BasicBlock::containsPredecessor):
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::generate):
* b3/air/AirInst.cpp:
(JSC::B3::Air::Inst::hasArgEffects):
(JSC::B3::Air::Inst::dump):
* b3/air/AirInst.h:
* b3/air/AirLiveness.h:
(JSC::B3::Air::Liveness::Liveness): Fix for when blocks were killed.
* b3/air/AirOpcode.opcodes:
* b3/air/AirSimplifyCFG.cpp: Added.
(JSC::B3::Air::simplifyCFG):
* b3/air/AirSimplifyCFG.h: Added.
2015-11-05 Nikos Andronikos <nikos.andronikos-webkit@cisra.canon.com.au>
Add runtime and compile time flags for enabling Web Animations API and model.
https://bugs.webkit.org/show_bug.cgi?id=150914
Reviewed by Benjamin Poulain.
Add ENABLE_WEB_ANIMATIONS compile time flag, runtime flag webAnimationsEnabled and Expose WK2 preference for runtime flag.
* Configurations/FeatureDefines.xcconfig:
2015-11-05 Sukolsak Sakshuwong <sukolsak@gmail.com>
Layout Test js/intl-collator.html is crashing on win 7 debug
https://bugs.webkit.org/show_bug.cgi?id=150943
Reviewed by Geoffrey Garen.
The string length returned by ICU's uenum_next seems to be unreliable
on an old version of ICU. Since uenum_next returns a null-terminated
string anyway, this patch removes the use of the length.
* runtime/IntlCollatorConstructor.cpp:
(JSC::sortLocaleData):
2015-11-05 Filip Pizlo <fpizlo@apple.com>
Unreviewed, add FIXMEs referencing https://bugs.webkit.org/show_bug.cgi?id=150958 and
https://bugs.webkit.org/show_bug.cgi?id=150954.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::createGenericCompare):
* b3/B3ReduceStrength.cpp:
2015-11-05 Aleksandr Skachkov <gskachkov@gmail.com>
Using emitResolveScope & emitGetFromScope with 'this' that is TDZ lead to segfault in DFG
https://bugs.webkit.org/show_bug.cgi?id=150902
Reviewed by Geoffrey Garen.
Tiny fix provided by Saam Barati. This fix prevent segfault error in arrow function,
when it uses in constructor of derived class, before 'super' is called.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2015-11-05 Filip Pizlo <fpizlo@apple.com>
B3->Air lowering should have a story for compare-branch fusion
https://bugs.webkit.org/show_bug.cgi?id=150721
Reviewed by Geoffrey Garen.
This adds comprehensive support for compares and compare/branch fusion to B3. The fusion is
super aggressive. It can even handle things like Branch(LessThan(Load8S(...), constant)). It
can even handle flipping the operands to the branch, and flipping the comparison condition,
if it enables a more efficient instruction. This happens when there is asymmetry in the
admitted argument kinds. For example, Branch32 will only accept an Imm as a second operand.
If we do a LessThan(constant, load) then we will generate it as:
Branch32 GreaterThan, (addr), $imm
This also supports compiling and fusing tests, and to some extent, compiling and fusing
double compares. Though we cannot test doubles yet because we don't have enough support for
that.
This also supports fusing compare/branches in Checks. We basically get that for free.
Because I wanted to fuse comparisons with sub-32-bit loads, I added support for those loads
directly, too.
The tests are now getting super big, so I made testb3 run tests in parallel.
Finally, this slightly changes the semantics of Branch and Check. Previously they would have
accepted a double to branch on. I found that this is awkward. It's especially awkward since
we want to be explicit about when a double zero constant is materialized. So, from now on, we
require that to branch on a double being non-zero, you have to do Branch(NotEqual(value, 0)).
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::invert):
(JSC::MacroAssembler::isInvertible):
(JSC::MacroAssembler::flip):
(JSC::MacroAssembler::isSigned):
(JSC::MacroAssembler::isUnsigned):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::test32):
(JSC::MacroAssemblerX86Common::invert):
* b3/B3CheckSpecial.cpp:
(JSC::B3::CheckSpecial::Key::Key):
(JSC::B3::CheckSpecial::Key::dump):
(JSC::B3::CheckSpecial::CheckSpecial):
(JSC::B3::CheckSpecial::~CheckSpecial):
* b3/B3CheckSpecial.h:
(JSC::B3::CheckSpecial::Key::Key):
(JSC::B3::CheckSpecial::Key::operator==):
(JSC::B3::CheckSpecial::Key::operator!=):
(JSC::B3::CheckSpecial::Key::operator bool):
(JSC::B3::CheckSpecial::Key::opcode):
(JSC::B3::CheckSpecial::Key::numArgs):
(JSC::B3::CheckSpecial::Key::isHashTableDeletedValue):
(JSC::B3::CheckSpecial::Key::hash):
(JSC::B3::CheckSpecialKeyHash::hash):
(JSC::B3::CheckSpecialKeyHash::equal):
* b3/B3Const32Value.cpp:
(JSC::B3::Const32Value::zShrConstant):
(JSC::B3::Const32Value::equalConstant):
(JSC::B3::Const32Value::notEqualConstant):
(JSC::B3::Const32Value::lessThanConstant):
(JSC::B3::Const32Value::greaterThanConstant):
(JSC::B3::Const32Value::lessEqualConstant):
(JSC::B3::Const32Value::greaterEqualConstant):
(JSC::B3::Const32Value::aboveConstant):
(JSC::B3::Const32Value::belowConstant):
(JSC::B3::Const32Value::aboveEqualConstant):
(JSC::B3::Const32Value::belowEqualConstant):
(JSC::B3::Const32Value::dumpMeta):
* b3/B3Const32Value.h:
* b3/B3Const64Value.cpp:
(JSC::B3::Const64Value::zShrConstant):
(JSC::B3::Const64Value::equalConstant):
(JSC::B3::Const64Value::notEqualConstant):
(JSC::B3::Const64Value::lessThanConstant):
(JSC::B3::Const64Value::greaterThanConstant):
(JSC::B3::Const64Value::lessEqualConstant):
(JSC::B3::Const64Value::greaterEqualConstant):
(JSC::B3::Const64Value::aboveConstant):
(JSC::B3::Const64Value::belowConstant):
(JSC::B3::Const64Value::aboveEqualConstant):
(JSC::B3::Const64Value::belowEqualConstant):
(JSC::B3::Const64Value::dumpMeta):
* b3/B3Const64Value.h:
* b3/B3ConstDoubleValue.cpp:
(JSC::B3::ConstDoubleValue::subConstant):
(JSC::B3::ConstDoubleValue::equalConstant):
(JSC::B3::ConstDoubleValue::notEqualConstant):
(JSC::B3::ConstDoubleValue::lessThanConstant):
(JSC::B3::ConstDoubleValue::greaterThanConstant):
(JSC::B3::ConstDoubleValue::lessEqualConstant):
(JSC::B3::ConstDoubleValue::greaterEqualConstant):
(JSC::B3::ConstDoubleValue::dumpMeta):
* b3/B3ConstDoubleValue.h:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::LowerToAir):
(JSC::B3::Air::LowerToAir::run):
(JSC::B3::Air::LowerToAir::shouldCopyPropagate):
(JSC::B3::Air::LowerToAir::ArgPromise::ArgPromise):
(JSC::B3::Air::LowerToAir::ArgPromise::tmp):
(JSC::B3::Air::LowerToAir::ArgPromise::operator bool):
(JSC::B3::Air::LowerToAir::ArgPromise::kind):
(JSC::B3::Air::LowerToAir::ArgPromise::peek):
(JSC::B3::Air::LowerToAir::ArgPromise::consume):
(JSC::B3::Air::LowerToAir::tmp):
(JSC::B3::Air::LowerToAir::tmpPromise):
(JSC::B3::Air::LowerToAir::canBeInternal):
(JSC::B3::Air::LowerToAir::addr):
(JSC::B3::Air::LowerToAir::loadPromise):
(JSC::B3::Air::LowerToAir::imm):
(JSC::B3::Air::LowerToAir::appendBinOp):
(JSC::B3::Air::LowerToAir::tryAppendStoreUnOp):
(JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
(JSC::B3::Air::LowerToAir::createGenericCompare):
(JSC::B3::Air::LowerToAir::createBranch):
(JSC::B3::Air::LowerToAir::createCompare):
(JSC::B3::Air::LowerToAir::tryLoad):
(JSC::B3::Air::LowerToAir::tryLoad8S):
(JSC::B3::Air::LowerToAir::tryLoad8Z):
(JSC::B3::Air::LowerToAir::tryLoad16S):
(JSC::B3::Air::LowerToAir::tryLoad16Z):
(JSC::B3::Air::LowerToAir::tryAdd):
(JSC::B3::Air::LowerToAir::tryStackSlot):
(JSC::B3::Air::LowerToAir::tryEqual):
(JSC::B3::Air::LowerToAir::tryNotEqual):
(JSC::B3::Air::LowerToAir::tryLessThan):
(JSC::B3::Air::LowerToAir::tryGreaterThan):
(JSC::B3::Air::LowerToAir::tryLessEqual):
(JSC::B3::Air::LowerToAir::tryGreaterEqual):
(JSC::B3::Air::LowerToAir::tryAbove):
(JSC::B3::Air::LowerToAir::tryBelow):
(JSC::B3::Air::LowerToAir::tryAboveEqual):
(JSC::B3::Air::LowerToAir::tryBelowEqual):
(JSC::B3::Air::LowerToAir::tryPatchpoint):
(JSC::B3::Air::LowerToAir::tryCheck):
(JSC::B3::Air::LowerToAir::tryBranch):
(JSC::B3::Air::LowerToAir::loadAddr): Deleted.
* b3/B3LoweringMatcher.patterns:
* b3/B3Opcode.cpp:
(JSC::B3::invertedCompare):
* b3/B3Opcode.h:
(JSC::B3::isCheckMath):
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::addBlock):
(JSC::B3::Procedure::addIntConstant):
(JSC::B3::Procedure::addBoolConstant):
(JSC::B3::Procedure::resetValueOwners):
* b3/B3Procedure.h:
* b3/B3ReduceStrength.cpp:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::zShrConstant):
(JSC::B3::Value::equalConstant):
(JSC::B3::Value::notEqualConstant):
(JSC::B3::Value::lessThanConstant):
(JSC::B3::Value::greaterThanConstant):
(JSC::B3::Value::lessEqualConstant):
(JSC::B3::Value::greaterEqualConstant):
(JSC::B3::Value::aboveConstant):
(JSC::B3::Value::belowConstant):
(JSC::B3::Value::aboveEqualConstant):
(JSC::B3::Value::belowEqualConstant):
(JSC::B3::Value::invertedCompare):
* b3/B3Value.h:
* b3/air/AirArg.cpp:
(JSC::B3::Air::Arg::isRepresentableAs):
(JSC::B3::Air::Arg::dump):
(WTF::printInternal):
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::isUse):
(JSC::B3::Air::Arg::typeForB3Type):
(JSC::B3::Air::Arg::widthForB3Type):
(JSC::B3::Air::Arg::Arg):
(JSC::B3::Air::Arg::value):
(JSC::B3::Air::Arg::isRepresentableAs):
(JSC::B3::Air::Arg::asNumber):
(JSC::B3::Air::Arg::pointerValue):
(JSC::B3::Air::Arg::asDoubleCondition):
(JSC::B3::Air::Arg::inverted):
(JSC::B3::Air::Arg::flipped):
(JSC::B3::Air::Arg::isSignedCond):
(JSC::B3::Air::Arg::isUnsignedCond):
* b3/air/AirInst.h:
(JSC::B3::Air::Inst::Inst):
(JSC::B3::Air::Inst::operator bool):
* b3/air/AirOpcode.opcodes:
* b3/air/opcode_generator.rb:
* b3/testb3.cpp:
(hiddenTruthBecauseNoReturnIsStupid):
(JSC::B3::testStoreLoadStackSlot):
(JSC::B3::modelLoad):
(JSC::B3::testLoad):
(JSC::B3::testBranch):
(JSC::B3::testComplex):
(JSC::B3::testSimplePatchpoint):
(JSC::B3::testSimpleCheck):
(JSC::B3::genericTestCompare):
(JSC::B3::modelCompare):
(JSC::B3::testCompareLoad):
(JSC::B3::testCompareImpl):
(JSC::B3::testCompare):
(JSC::B3::run):
(main):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithMod):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitIntTypedArrayGetByVal):
(JSC::JIT::emitIntTypedArrayPutByVal):
2015-11-05 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Clean up InjectedScript uses
https://bugs.webkit.org/show_bug.cgi?id=150921
Reviewed by Timothy Hatcher.
* inspector/InjectedScript.cpp:
(Inspector::InjectedScript::wrapCallFrames):
* inspector/InjectedScript.h:
* inspector/InjectedScriptBase.cpp:
(Inspector::InjectedScriptBase::initialize): Deleted.
* inspector/InjectedScriptBase.h:
* inspector/InjectedScriptManager.cpp:
(Inspector::InjectedScriptManager::didCreateInjectedScript):
* inspector/InjectedScriptManager.h:
* inspector/InjectedScriptModule.cpp:
(Inspector::InjectedScriptModule::ensureInjected):
* inspector/InjectedScriptModule.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::currentCallFrames):
* inspector/agents/InspectorDebuggerAgent.h:
2015-11-05 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Put ScriptDebugServer into InspectorEnvironment and cleanup duplicate references
https://bugs.webkit.org/show_bug.cgi?id=150869
Reviewed by Brian Burg.
ScriptDebugServer (JSC::Debugger) is being used by more and more agents
for instrumentation into JavaScriptCore. Currently the ScriptDebugServer
is owned by DebuggerAgent subclasses that make their own ScriptDebugServer
subclass. As more agents want to use it there was added boilerplate.
Instead, put the ScriptDebugServer in the InspectorEnvironment (Controllers).
Then each agent can access it during construction through the environment.
Do the same clean up for RuntimeAgent::globalVM, which is now just a
duplication of InspectorEnvironment::vm.
* inspector/InspectorEnvironment.h:
Add scriptDebugServer().
* inspector/JSGlobalObjectInspectorController.h:
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
(Inspector::JSGlobalObjectInspectorController::scriptDebugServer):
Own the JSGlobalObjectScriptDebugServer.
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::InspectorDebuggerAgent):
(Inspector::InspectorDebuggerAgent::enable):
(Inspector::InspectorDebuggerAgent::disable):
(Inspector::InspectorDebuggerAgent::setBreakpointsActive):
(Inspector::InspectorDebuggerAgent::isPaused):
(Inspector::InspectorDebuggerAgent::setSuppressAllPauses):
(Inspector::InspectorDebuggerAgent::handleConsoleAssert):
(Inspector::InspectorDebuggerAgent::removeBreakpoint):
(Inspector::InspectorDebuggerAgent::continueToLocation):
(Inspector::InspectorDebuggerAgent::resolveBreakpoint):
(Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement):
(Inspector::InspectorDebuggerAgent::cancelPauseOnNextStatement):
(Inspector::InspectorDebuggerAgent::resume):
(Inspector::InspectorDebuggerAgent::stepOver):
(Inspector::InspectorDebuggerAgent::stepInto):
(Inspector::InspectorDebuggerAgent::stepOut):
(Inspector::InspectorDebuggerAgent::setPauseOnExceptions):
(Inspector::InspectorDebuggerAgent::evaluateOnCallFrame):
(Inspector::InspectorDebuggerAgent::scriptExecutionBlockedByCSP):
(Inspector::InspectorDebuggerAgent::didPause):
(Inspector::InspectorDebuggerAgent::breakProgram):
(Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
* inspector/agents/InspectorRuntimeAgent.h:
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::InspectorRuntimeAgent):
(Inspector::setPauseOnExceptionsState):
(Inspector::InspectorRuntimeAgent::parse):
(Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
(Inspector::InspectorRuntimeAgent::setTypeProfilerEnabledState):
(Inspector::InspectorRuntimeAgent::getBasicBlocks):
Use VM and ScriptDebugServer passed during construction.
* inspector/agents/JSGlobalObjectDebuggerAgent.h:
* inspector/agents/JSGlobalObjectDebuggerAgent.cpp:
(Inspector::JSGlobalObjectDebuggerAgent::injectedScriptForEval):
(Inspector::JSGlobalObjectDebuggerAgent::JSGlobalObjectDebuggerAgent): Deleted.
One special case needed by this subclass as a convenience to access the global object.
* inspector/agents/JSGlobalObjectRuntimeAgent.h:
* inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
(Inspector::JSGlobalObjectRuntimeAgent::globalVM): Deleted.
This virtual method is no longer needed, the base class has everything now.
2015-11-05 Xabier Rodriguez Calvar <calvaris@igalia.com>
[Streams API] Shield implementation from user mangling Promise.reject and resolve methods
https://bugs.webkit.org/show_bug.cgi?id=150895
Reviewed by Youenn Fablet.
Keep Promise.resolve and reject also as internal slots for the Promise constructor given that there is no way to
retrieve the former implementation if the user decides to replace it. This allows to safely create vended
promises even if the user changes the constructor methods.
* runtime/JSPromiseConstructor.h:
* runtime/JSPromiseConstructor.cpp:
(JSC::JSPromiseConstructor::addOwnInternalSlots): Added to include @reject and @resolve.
(JSC::JSPromiseConstructor::create): Call addOwnInternalSlots.
2015-11-04 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add B3-to-Air lowering for the shift opcodes
https://bugs.webkit.org/show_bug.cgi?id=150919
Reviewed by Filip Pizlo.
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::rshift64):
(JSC::MacroAssemblerX86_64::urshift64):
* assembler/X86Assembler.h:
(JSC::X86Assembler::shrq_CLr):
* b3/B3Const32Value.cpp:
(JSC::B3::Const32Value::shlConstant):
(JSC::B3::Const32Value::sShrConstant):
(JSC::B3::Const32Value::zShrConstant):
* b3/B3Const32Value.h:
* b3/B3Const64Value.cpp:
(JSC::B3::Const64Value::shlConstant):
(JSC::B3::Const64Value::sShrConstant):
(JSC::B3::Const64Value::zShrConstant):
* b3/B3Const64Value.h:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::appendShift):
(JSC::B3::Air::LowerToAir::tryShl):
(JSC::B3::Air::LowerToAir::trySShr):
(JSC::B3::Air::LowerToAir::tryZShr):
* b3/B3LoweringMatcher.patterns:
* b3/B3Opcode.h:
* b3/B3ReduceStrength.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::shlConstant):
(JSC::B3::Value::sShrConstant):
(JSC::B3::Value::zShrConstant):
* b3/B3Value.h:
* b3/air/AirInstInlines.h:
(JSC::B3::Air::isShiftValid):
(JSC::B3::Air::isRshift32Valid):
(JSC::B3::Air::isRshift64Valid):
(JSC::B3::Air::isUrshift32Valid):
(JSC::B3::Air::isUrshift64Valid):
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testShlArgs):
(JSC::B3::testShlImms):
(JSC::B3::testShlArgImm):
(JSC::B3::testShlArgs32):
(JSC::B3::testShlImms32):
(JSC::B3::testShlArgImm32):
(JSC::B3::testSShrArgs):
(JSC::B3::testSShrImms):
(JSC::B3::testSShrArgImm):
(JSC::B3::testSShrArgs32):
(JSC::B3::testSShrImms32):
(JSC::B3::testSShrArgImm32):
(JSC::B3::testZShrArgs):
(JSC::B3::testZShrImms):
(JSC::B3::testZShrArgImm):
(JSC::B3::testZShrArgs32):
(JSC::B3::testZShrImms32):
(JSC::B3::testZShrArgImm32):
(JSC::B3::run):
2015-11-03 Filip Pizlo <fpizlo@apple.com>
B3 should be able to compile a Check
https://bugs.webkit.org/show_bug.cgi?id=150878
Reviewed by Saam Barati.
The Check opcode in B3 is going to be our main OSR exit mechanism. It is a stackmap
value, so you can pass it any number of additional arguments, and you will get to find
out how those arguments are represented at the point that the value lands in the machine
code. Unlike a Patchpoint, a Check branches on a value, with the goal of supporting full
compare/branch fusion. The stackmap's generator runs in an out-of-line path to which
that branch is linked.
This change fills in the glue necessary to compile a Check and it includes a simple
test of this functionality. That test also happens to check that such simple code will
never use callee-saves, which I think is sensible.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::append):
(JSC::B3::Air::LowerToAir::ensureSpecial):
(JSC::B3::Air::LowerToAir::fillStackmap):
(JSC::B3::Air::LowerToAir::tryStackSlot):
(JSC::B3::Air::LowerToAir::tryPatchpoint):
(JSC::B3::Air::LowerToAir::tryCheck):
(JSC::B3::Air::LowerToAir::tryUpsilon):
* b3/B3LoweringMatcher.patterns:
* b3/testb3.cpp:
(JSC::B3::testSimplePatchpoint):
(JSC::B3::testSimpleCheck):
(JSC::B3::run):
2015-10-30 Keith Miller <keith_miller@apple.com>
Fix endless OSR exits when creating a rope that contains an object that ToPrimitive's to a number.
https://bugs.webkit.org/show_bug.cgi?id=150583
Reviewed by Benjamin Poulain.
Before we assumed that the result of ToPrimitive on any object was a string.
This had a couple of negative effects. First, the result ToPrimitive on an
object can be overridden to be any primitive type. In fact, as of ES6, ToPrimitive,
when part of a addition expression, will type hint a number value. Second, even after
repeatedly exiting with a bad type we would continue to think that the result
of ToPrimitive would be a string so we continue to convert StrCats into MakeRope.
The fix is to make Prediction Propagation match the behavior of Fixup and move
canOptimizeStringObjectAccess to DFGGraph.
* bytecode/SpeculatedType.h:
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::attemptToForceStringArrayModeByToStringConversion):
(JSC::DFG::FixupPhase::fixupToPrimitive):
(JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor):
(JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
(JSC::DFG::FixupPhase::isStringPrototypeMethodSane): Deleted.
(JSC::DFG::FixupPhase::canOptimizeStringObjectAccess): Deleted.
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::isStringPrototypeMethodSane):
(JSC::DFG::Graph::canOptimizeStringObjectAccess):
* dfg/DFGGraph.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::resultOfToPrimitive):
(JSC::DFG::resultOfToPrimitive): Deleted.
* bytecode/SpeculatedType.h:
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::attemptToForceStringArrayModeByToStringConversion):
(JSC::DFG::FixupPhase::fixupToPrimitive):
(JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor):
(JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
(JSC::DFG::FixupPhase::isStringPrototypeMethodSane): Deleted.
(JSC::DFG::FixupPhase::canOptimizeStringObjectAccess): Deleted.
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::isStringPrototypeMethodSane):
(JSC::DFG::Graph::canOptimizeStringObjectAccess):
* dfg/DFGGraph.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::resultOfToPrimitive):
(JSC::DFG::resultOfToPrimitive): Deleted.
* tests/stress/string-rope-with-custom-valueof.js: Added.
(catNumber):
(number.valueOf):
(catBool):
(bool.valueOf):
(catUndefined):
(undef.valueOf):
(catRandom):
(random.valueOf):
2015-11-04 Xabier Rodriguez Calvar <calvaris@igalia.com>
Remove bogus global internal functions for properties and prototype retrieval
https://bugs.webkit.org/show_bug.cgi?id=150892
Reviewed by Darin Adler.
Global @getOwnPropertyNames and @getPrototypeOf point to the floor function, so it is bogus dead code.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init): Removed global @getOwnPropertyNames and @getPrototypeOf.
2015-11-03 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add B3-to-Air lowering for BitXor
https://bugs.webkit.org/show_bug.cgi?id=150872
Reviewed by Filip Pizlo.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::xor32):
Fix the indentation.
* b3/B3Const32Value.cpp:
(JSC::B3::Const32Value::bitXorConstant):
* b3/B3Const32Value.h:
* b3/B3Const64Value.cpp:
(JSC::B3::Const64Value::bitXorConstant):
* b3/B3Const64Value.h:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::tryXor):
* b3/B3LoweringMatcher.patterns:
* b3/B3ReduceStrength.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::bitXorConstant):
* b3/B3Value.h:
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testBitXorArgs):
(JSC::B3::testBitXorSameArg):
(JSC::B3::testBitXorImms):
(JSC::B3::testBitXorArgImm):
(JSC::B3::testBitXorImmArg):
(JSC::B3::testBitXorBitXorArgImmImm):
(JSC::B3::testBitXorImmBitXorArgImm):
(JSC::B3::testBitXorArgs32):
(JSC::B3::testBitXorSameArg32):
(JSC::B3::testBitXorImms32):
(JSC::B3::testBitXorArgImm32):
(JSC::B3::testBitXorImmArg32):
(JSC::B3::testBitXorBitXorArgImmImm32):
(JSC::B3::testBitXorImmBitXorArgImm32):
(JSC::B3::run):
2015-11-03 Mark Lam <mark.lam@apple.com>
Add op_add tests to compare behavior of JIT generated code to the LLINT's.
https://bugs.webkit.org/show_bug.cgi?id=150864
Reviewed by Saam Barati.
* tests/stress/op_add.js: Added.
(o1.valueOf):
(generateScenarios):
(printScenarios):
(testCases.func):
(func):
(initializeTestCases):
(runTest):
2015-11-03 Mark Lam <mark.lam@apple.com>
Rename DFG's compileAdd to compileArithAdd.
https://bugs.webkit.org/show_bug.cgi?id=150866
Reviewed by Benjamin Poulain.
The function is only supposed to generate code to do arithmetic addition on
numeric types. Naming it compileArithAdd() is more accurate, and is consistent
with the name of the node it emits code for (i.e. ArithAdd) as well as other
compiler functions for analogous operations e.g. compileArithSub.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileInstanceOf):
(JSC::DFG::SpeculativeJIT::compileArithAdd):
(JSC::DFG::SpeculativeJIT::compileAdd): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
2015-11-03 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Remove duplication among ScriptDebugServer subclasses
https://bugs.webkit.org/show_bug.cgi?id=150860
Reviewed by Timothy Hatcher.
ScriptDebugServer expects a list of listeners to dispatch events to.
However each of its subclasses had their own implementation of the
list because of different handling when the first was added or when
the last was removed. Extract common code into ScriptDebugServer
which simplifies things.
Subclasses now only implement a virtual methods "attachDebugger"
and "detachDebugger" which is the unique work done when the first
listener is added or last is removed.
* inspector/JSGlobalObjectScriptDebugServer.cpp:
(Inspector::JSGlobalObjectScriptDebugServer::attachDebugger):
(Inspector::JSGlobalObjectScriptDebugServer::detachDebugger):
(Inspector::JSGlobalObjectScriptDebugServer::addListener): Deleted.
(Inspector::JSGlobalObjectScriptDebugServer::removeListener): Deleted.
* inspector/JSGlobalObjectScriptDebugServer.h:
* inspector/ScriptDebugServer.cpp:
(Inspector::ScriptDebugServer::dispatchBreakpointActionLog):
(Inspector::ScriptDebugServer::dispatchBreakpointActionSound):
(Inspector::ScriptDebugServer::dispatchBreakpointActionProbe):
(Inspector::ScriptDebugServer::sourceParsed):
(Inspector::ScriptDebugServer::dispatchFunctionToListeners):
(Inspector::ScriptDebugServer::addListener):
(Inspector::ScriptDebugServer::removeListener):
* inspector/ScriptDebugServer.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::enable):
(Inspector::InspectorDebuggerAgent::disable):
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/JSGlobalObjectDebuggerAgent.cpp:
(Inspector::JSGlobalObjectDebuggerAgent::startListeningScriptDebugServer): Deleted.
(Inspector::JSGlobalObjectDebuggerAgent::stopListeningScriptDebugServer): Deleted.
* inspector/agents/JSGlobalObjectDebuggerAgent.h:
* inspector/ScriptDebugListener.h:
(Inspector::ScriptDebugListener::Script::Script):
Drive-by convert Script to a struct, it has public fields and is used as such.
2015-11-03 Filip Pizlo <fpizlo@apple.com>
B3::LowerToAir should recognize Neg (i.e. Sub($0, value))
https://bugs.webkit.org/show_bug.cgi?id=150759
Reviewed by Benjamin Poulain.
Adds various forms of Sub(0, value) and compiles them as Neg. Also fixes a bug in
StoreSubLoad. This bug was correctness-benign, so I couldn't add a test for it.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::immOrTmp):
(JSC::B3::Air::LowerToAir::appendUnOp):
(JSC::B3::Air::LowerToAir::appendBinOp):
(JSC::B3::Air::LowerToAir::tryAppendStoreUnOp):
(JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
(JSC::B3::Air::LowerToAir::trySub):
(JSC::B3::Air::LowerToAir::tryStoreSubLoad):
* b3/B3LoweringMatcher.patterns:
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testAdd1Ptr):
(JSC::B3::testNeg32):
(JSC::B3::testNegPtr):
(JSC::B3::testStoreAddLoad):
(JSC::B3::testStoreAddAndLoad):
(JSC::B3::testStoreNegLoad32):
(JSC::B3::testStoreNegLoadPtr):
(JSC::B3::testAdd1Uncommuted):
(JSC::B3::run):
2015-11-03 Filip Pizlo <fpizlo@apple.com>
B3::Values that have effects should allow specification of custom HeapRanges
https://bugs.webkit.org/show_bug.cgi?id=150535
Reviewed by Benjamin Poulain.
Add a Effects field to calls and patchpoints. Add a HeapRange to MemoryValues.
In the process, I created a class for the CCall opcode, so that it has somewhere to put
the Effects field.
While doing this, I realized that we didn't have a good way of ensuring that an opcode
that requires a specific subclass was actually created with that subclass. So, I added
assertions for this.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3ArgumentRegValue.h:
* b3/B3CCallValue.cpp: Added.
* b3/B3CCallValue.h: Added.
* b3/B3CheckValue.h:
* b3/B3Const32Value.h:
* b3/B3Const64Value.h:
* b3/B3ConstDoubleValue.h:
(JSC::B3::ConstDoubleValue::ConstDoubleValue):
* b3/B3ControlValue.h:
* b3/B3Effects.h:
(JSC::B3::Effects::forCall):
(JSC::B3::Effects::mustExecute):
* b3/B3MemoryValue.h:
* b3/B3PatchpointValue.h:
* b3/B3StackSlotValue.h:
* b3/B3UpsilonValue.h:
* b3/B3Value.cpp:
(JSC::B3::Value::effects):
(JSC::B3::Value::dumpMeta):
(JSC::B3::Value::checkOpcode):
(JSC::B3::Value::typeFor):
* b3/B3Value.h:
2015-11-03 Filip Pizlo <fpizlo@apple.com>
B3::Stackmap should be a superclass of B3::PatchpointValue and B3::CheckValue rather than being one of their members
https://bugs.webkit.org/show_bug.cgi?id=150831
Rubber stamped by Benjamin Poulain.
Previously, Stackmap was a value that PatchpointValue and CheckValue would hold as a field.
We'd have convenient ways of getting this field, like via Value::stackmap(). But this was a
bit ridiculous, since Stackmap is logically just a common supertype for Patchpointvalue and
CheckValue. This patch makes this reality by replacing Stackmap with StackmapValue. This makes
the code a lot more reasonable.
I also needed to make dumping a bit more customizable, so I changed dumpMeta() to take a
CommaPrinter&. This gives subclasses better control over whether or not to emit a comma. Also
it's now possible for subclasses of Value to customize how children are printed. StackmapValue
uses this to print the children and their reps together like:
Int32 @2 = Patchpoint(@0:SomeRegister, @1:SomeRegister, generator = 0x1107ec010, clobbered = [], usedRegisters = [], ExitsSideways|ControlDependent|Writes:Top|Reads:Top)
This has no behavior change, it's just a big refactoring. You can see how much simpler this
makes things by looking at the testSimplePatchpoint() test.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3ArgumentRegValue.cpp:
(JSC::B3::ArgumentRegValue::~ArgumentRegValue):
(JSC::B3::ArgumentRegValue::dumpMeta):
* b3/B3ArgumentRegValue.h:
* b3/B3CheckSpecial.cpp:
(JSC::B3::CheckSpecial::generate):
* b3/B3CheckValue.cpp:
(JSC::B3::CheckValue::~CheckValue):
(JSC::B3::CheckValue::CheckValue):
(JSC::B3::CheckValue::dumpMeta): Deleted.
* b3/B3CheckValue.h:
(JSC::B3::CheckValue::accepts):
* b3/B3Const32Value.cpp:
(JSC::B3::Const32Value::notEqualConstant):
(JSC::B3::Const32Value::dumpMeta):
* b3/B3Const32Value.h:
* b3/B3Const64Value.cpp:
(JSC::B3::Const64Value::notEqualConstant):
(JSC::B3::Const64Value::dumpMeta):
* b3/B3Const64Value.h:
* b3/B3ConstDoubleValue.cpp:
(JSC::B3::ConstDoubleValue::notEqualConstant):
(JSC::B3::ConstDoubleValue::dumpMeta):
* b3/B3ConstDoubleValue.h:
* b3/B3ConstrainedValue.cpp: Added.
(JSC::B3::ConstrainedValue::dump):
* b3/B3ConstrainedValue.h: Added.
(JSC::B3::ConstrainedValue::ConstrainedValue):
(JSC::B3::ConstrainedValue::operator bool):
(JSC::B3::ConstrainedValue::value):
(JSC::B3::ConstrainedValue::rep):
* b3/B3ControlValue.cpp:
(JSC::B3::ControlValue::convertToJump):
(JSC::B3::ControlValue::dumpMeta):
* b3/B3ControlValue.h:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::tryPatchpoint):
* b3/B3MemoryValue.cpp:
(JSC::B3::MemoryValue::accessByteSize):
(JSC::B3::MemoryValue::dumpMeta):
* b3/B3MemoryValue.h:
* b3/B3PatchpointSpecial.cpp:
(JSC::B3::PatchpointSpecial::generate):
* b3/B3PatchpointValue.cpp:
(JSC::B3::PatchpointValue::~PatchpointValue):
(JSC::B3::PatchpointValue::PatchpointValue):
(JSC::B3::PatchpointValue::dumpMeta): Deleted.
* b3/B3PatchpointValue.h:
(JSC::B3::PatchpointValue::accepts):
* b3/B3StackSlotValue.cpp:
(JSC::B3::StackSlotValue::~StackSlotValue):
(JSC::B3::StackSlotValue::dumpMeta):
* b3/B3StackSlotValue.h:
* b3/B3Stackmap.cpp: Removed.
* b3/B3Stackmap.h: Removed.
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::reportUsedRegisters):
(JSC::B3::StackmapSpecial::extraClobberedRegs):
(JSC::B3::StackmapSpecial::forEachArgImpl):
(JSC::B3::StackmapSpecial::isValidImpl):
(JSC::B3::StackmapSpecial::admitsStackImpl):
* b3/B3StackmapSpecial.h:
* b3/B3StackmapValue.cpp: Added.
(JSC::B3::StackmapValue::~StackmapValue):
(JSC::B3::StackmapValue::append):
(JSC::B3::StackmapValue::setConstrainedChild):
(JSC::B3::StackmapValue::setConstraint):
(JSC::B3::StackmapValue::dumpChildren):
(JSC::B3::StackmapValue::dumpMeta):
(JSC::B3::StackmapValue::StackmapValue):
* b3/B3StackmapValue.h: Added.
* b3/B3SwitchValue.cpp:
(JSC::B3::SwitchValue::appendCase):
(JSC::B3::SwitchValue::dumpMeta):
(JSC::B3::SwitchValue::SwitchValue):
* b3/B3SwitchValue.h:
* b3/B3UpsilonValue.cpp:
(JSC::B3::UpsilonValue::~UpsilonValue):
(JSC::B3::UpsilonValue::dumpMeta):
* b3/B3UpsilonValue.h:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::dump):
(JSC::B3::Value::dumpChildren):
(JSC::B3::Value::deepDump):
(JSC::B3::Value::performSubstitution):
(JSC::B3::Value::dumpMeta):
* b3/B3Value.h:
* b3/B3ValueInlines.h:
(JSC::B3::Value::asNumber):
(JSC::B3::Value::stackmap): Deleted.
* b3/B3ValueRep.h:
(JSC::B3::ValueRep::kind):
(JSC::B3::ValueRep::operator==):
(JSC::B3::ValueRep::operator!=):
(JSC::B3::ValueRep::operator bool):
(JSC::B3::ValueRep::isAny):
* b3/air/AirInstInlines.h:
* b3/testb3.cpp:
(JSC::B3::testSimplePatchpoint):
2015-11-03 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add Air lowering for BitOr and impove BitAnd
https://bugs.webkit.org/show_bug.cgi?id=150827
Reviewed by Filip Pizlo.
In this patch:
-B3 to Air lowering for BirOr.
-Codegen for BitOr.
-Strength reduction for BitOr and BitAnd.
-Tests for BitAnd and BitOr.
-Bug fix: Move64 with a negative value was destroying the top bits.
* b3/B3Const32Value.cpp:
(JSC::B3::Const32Value::bitAndConstant):
(JSC::B3::Const32Value::bitOrConstant):
* b3/B3Const32Value.h:
* b3/B3Const64Value.cpp:
(JSC::B3::Const64Value::bitAndConstant):
(JSC::B3::Const64Value::bitOrConstant):
* b3/B3Const64Value.h:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::immForMove):
(JSC::B3::Air::LowerToAir::immOrTmpForMove):
(JSC::B3::Air::LowerToAir::tryOr):
(JSC::B3::Air::LowerToAir::tryConst64):
(JSC::B3::Air::LowerToAir::tryUpsilon):
(JSC::B3::Air::LowerToAir::tryIdentity):
(JSC::B3::Air::LowerToAir::tryReturn):
(JSC::B3::Air::LowerToAir::immOrTmp): Deleted.
* b3/B3LoweringMatcher.patterns:
* b3/B3ReduceStrength.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::bitAndConstant):
(JSC::B3::Value::bitOrConstant):
* b3/B3Value.h:
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testReturnConst64):
(JSC::B3::testBitAndArgs):
(JSC::B3::testBitAndSameArg):
(JSC::B3::testBitAndImms):
(JSC::B3::testBitAndArgImm):
(JSC::B3::testBitAndImmArg):
(JSC::B3::testBitAndBitAndArgImmImm):
(JSC::B3::testBitAndImmBitAndArgImm):
(JSC::B3::testBitAndArgs32):
(JSC::B3::testBitAndSameArg32):
(JSC::B3::testBitAndImms32):
(JSC::B3::testBitAndArgImm32):
(JSC::B3::testBitAndImmArg32):
(JSC::B3::testBitAndBitAndArgImmImm32):
(JSC::B3::testBitAndImmBitAndArgImm32):
(JSC::B3::testBitOrArgs):
(JSC::B3::testBitOrSameArg):
(JSC::B3::testBitOrImms):
(JSC::B3::testBitOrArgImm):
(JSC::B3::testBitOrImmArg):
(JSC::B3::testBitOrBitOrArgImmImm):
(JSC::B3::testBitOrImmBitOrArgImm):
(JSC::B3::testBitOrArgs32):
(JSC::B3::testBitOrSameArg32):
(JSC::B3::testBitOrImms32):
(JSC::B3::testBitOrArgImm32):
(JSC::B3::testBitOrImmArg32):
(JSC::B3::testBitOrBitOrArgImmImm32):
(JSC::B3::testBitOrImmBitOrArgImm32):
(JSC::B3::run):
2015-11-03 Saam barati <sbarati@apple.com>
Rewrite "const" as "var" for iTunes/iBooks on the Mac
https://bugs.webkit.org/show_bug.cgi?id=150852
Reviewed by Geoffrey Garen.
VM now has a setting indicating if we should treat
"const" variables as "var" to more closely match
JSC's previous implementation of "const" before ES6.
* parser/Parser.h:
(JSC::Parser::next):
(JSC::Parser::nextExpectIdentifier):
* runtime/VM.h:
(JSC::VM::setShouldRewriteConstAsVar):
(JSC::VM::shouldRewriteConstAsVar):
2015-11-03 Mark Lam <mark.lam@apple.com>
Fix some inefficiencies in the baseline usage of JITAddGenerator.
https://bugs.webkit.org/show_bug.cgi?id=150850
Reviewed by Michael Saboff.
1. emit_op_add() was loading the operands twice. Removed the redundant load.
2. The snippet may decide that it wants to go the slow path route all the time.
In that case, emit_op_add will end up emitting a branch to an out of line
slow path followed by some dead code to store the result of the fast path
on to the stack.
We now check if the snippet determined that there's no fast path, and just
emit the slow path inline, and skip the dead store of the fast path result.
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_add):
2015-11-03 Filip Pizlo <fpizlo@apple.com>
B3::LowerToAir should do copy propagation
https://bugs.webkit.org/show_bug.cgi?id=150775
Reviewed by Geoffrey Garen.
What we are trying to do is remove the unnecessary Move's and Move32's from Trunc and ZExt32.
You could think of this as an Air optimization, and indeed, Air is powerful enough that we
could write a phase that does copy propagation through Move's and Move32's. For Move32's it
would only copy-propagate if it proved that the value was already zero-extended. We could
know this by just adding a Def32 role to Air.
But this patch takes a different approach: we ensure that we don't generate such redundant
Move's and Move32's to begin with. The reason is that it's much cheaper to do analysis over
B3 than over Air. So, whenever possible, and optimization should be implemented in B3. In
this case the optimization can't quite be implemented in B3 because you cannot remove a Trunc
or ZExt32 without violating the B3 type system. So, the best place to do this optimization is
during lowering: we can use B3 for our analysis and we can use Air to express the
transformation.
Copy propagating during B3->Air lowering is natural because we are creating "SSA-like" Tmps
from the B3 Values. They are SSA-like in the sense that except the tmp for a Phi, we know
that the Tmp will be assigned once and that the assignment will dominate all uses. So, if we
see an operation like Trunc that is semantically just a Move, we can skip the Move and just
claim that the Trunc has the same Tmp as its child. We do something similar for ZExt32,
except with that one we have to analyze IR to ensure that the value will actually be zero
extended. Note that this kind of reasoning about how Tmps work in Air is only possible in the
B3->Air lowering, since at that point we know for sure which Tmps behave this way. If we
wanted to do anything like this as a later Air phase, we'd have to do more analysis to first
prove that Tmps behave in this way.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::run):
(JSC::B3::Air::LowerToAir::highBitsAreZero):
(JSC::B3::Air::LowerToAir::shouldCopyPropagate):
(JSC::B3::Air::LowerToAir::tmp):
(JSC::B3::Air::LowerToAir::tryStore):
(JSC::B3::Air::LowerToAir::tryTrunc):
(JSC::B3::Air::LowerToAir::tryZExt32):
(JSC::B3::Air::LowerToAir::tryIdentity):
(JSC::B3::Air::LowerToAir::tryTruncArgumentReg): Deleted.
* b3/B3LoweringMatcher.patterns:
2015-11-03 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Move ScriptDebugServer::Task to WorkerScriptDebugServer where it is actually used
https://bugs.webkit.org/show_bug.cgi?id=150847
Reviewed by Timothy Hatcher.
* inspector/ScriptDebugServer.h:
Remove Task from here, it isn't needed in the general case.
* parser/SourceProvider.h:
Remove unimplemented method.
2015-11-03 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Handle or Remove ParseHTML Timeline Event Records
https://bugs.webkit.org/show_bug.cgi?id=150689
Reviewed by Timothy Hatcher.
* inspector/protocol/Timeline.json:
2015-11-03 Michael Saboff <msaboff@apple.com>
Rename InlineCallFrame:: getCallerSkippingDeadFrames to something more descriptive
https://bugs.webkit.org/show_bug.cgi?id=150832
Reviewed by Geoffrey Garen.
Renamed InlineCallFrame::getCallerSkippingDeadFrames() to getCallerSkippingTailCalls().
Did similar renaming to helper InlineCallFrame::computeCallerSkippingTailCalls() and
InlineCallFrame::getCallerInlineFrameSkippingTailCalls().
* bytecode/InlineCallFrame.h:
(JSC::InlineCallFrame::computeCallerSkippingTailCalls):
(JSC::InlineCallFrame::getCallerSkippingTailCalls):
(JSC::InlineCallFrame::getCallerInlineFrameSkippingTailCalls):
(JSC::InlineCallFrame::computeCallerSkippingDeadFrames): Deleted.
(JSC::InlineCallFrame::getCallerSkippingDeadFrames): Deleted.
(JSC::InlineCallFrame::getCallerInlineFrameSkippingDeadFrames): Deleted.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::allInlineFramesAreTailCalls):
(JSC::DFG::ByteCodeParser::currentCodeOrigin):
(JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::isLiveInBytecode):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::forAllLocalsLiveInBytecode):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
* dfg/DFGPreciseLocalClobberize.h:
(JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::codeOriginDescriptionOfCallSite):
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::gotoNextFrame):
2015-11-02 Filip Pizlo <fpizlo@apple.com>
B3/Air should use bubble sort for their insertion sets, because it's faster than std::stable_sort
https://bugs.webkit.org/show_bug.cgi?id=150828
Reviewed by Geoffrey Garen.
Undo the 2% compile time regression caused by http://trac.webkit.org/changeset/191913.
* b3/B3InsertionSet.cpp:
(JSC::B3::InsertionSet::execute): Switch to bubble sort.
* b3/air/AirInsertionSet.cpp:
(JSC::B3::Air::InsertionSet::execute): Switch to bubble sort.
* dfg/DFGBlockInsertionSet.cpp:
(JSC::DFG::BlockInsertionSet::execute): Switch back to quicksort.
2015-11-03 Csaba Osztrogonác <ossy@webkit.org>
Unreviewed, partially revert r191952.
Removed GCC compiler workarounds (unreachable returns).
* b3/B3Type.h:
(JSC::B3::sizeofType):
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::isUse):
(JSC::B3::Air::Arg::isDef):
(JSC::B3::Air::Arg::isGP):
(JSC::B3::Air::Arg::isFP):
(JSC::B3::Air::Arg::isType):
* b3/air/AirCode.h:
(JSC::B3::Air::Code::newTmp):
(JSC::B3::Air::Code::numTmps):
2015-11-03 Csaba Osztrogonác <ossy@webkit.org>
Fix the ENABLE(B3_JIT) build on Linux
https://bugs.webkit.org/show_bug.cgi?id=150794
Reviewed by Darin Adler.
* CMakeLists.txt:
* b3/B3HeapRange.h:
* b3/B3IndexSet.h:
(JSC::B3::IndexSet::Iterable::iterator::operator++):
* b3/B3Type.h:
(JSC::B3::sizeofType):
* b3/air/AirArg.cpp:
(JSC::B3::Air::Arg::dump):
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::isUse):
(JSC::B3::Air::Arg::isDef):
(JSC::B3::Air::Arg::isGP):
(JSC::B3::Air::Arg::isFP):
(JSC::B3::Air::Arg::isType):
* b3/air/AirCode.h:
(JSC::B3::Air::Code::newTmp):
(JSC::B3::Air::Code::numTmps):
* b3/air/AirSpecial.cpp:
2015-11-03 Yusuke Suzuki <utatane.tea@gmail.com>
Clean up ENABLE(ES6_ARROWFUNCTION_SYNTAX) ifdefs and keep minimal set of them
https://bugs.webkit.org/show_bug.cgi?id=150793
Reviewed by Darin Adler.
Fix the !ENABLE(ES6_ARROWFUNCTION_SYNTAX) build after r191875.
This patch drops many ENABLE(ES6_ARROWFUNCTION_SYNTAX) ifdefs and keep only one of them;
the ifdef in parseAssignmentExpression.
This prevents functionality of parsing arrow function syntax.
* parser/Lexer.cpp:
(JSC::Lexer<T>::lex):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner): Deleted.
* parser/Parser.h:
(JSC::Parser::isArrowFunctionParamters): Deleted.
* parser/ParserTokens.h:
2015-11-02 Michael Saboff <msaboff@apple.com>
WebInspector crashed while viewing Timeline when refreshing cnn.com while it was already loading
https://bugs.webkit.org/show_bug.cgi?id=150745
Reviewed by Geoffrey Garen.
During OSR exit, reifyInlinedCallFrames() was using the call kind from a tail call to
find the CallLinkInfo / StubInfo to find the return PC. Instead we need to get the call
type of the true caller, that is the function we'll be returning to.
This can be found by remembering the last call type we find while walking up the inlined
frames in InlineCallFrame::getCallerSkippingDeadFrames().
We can also return directly back to a getter or setter callsite without using a thunk.
* bytecode/InlineCallFrame.h:
(JSC::InlineCallFrame::computeCallerSkippingDeadFrames):
(JSC::InlineCallFrame::getCallerSkippingDeadFrames):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_get_by_id): Need to eliminate the stack pointer check, as it is wrong
for reified inlined frames created during OSR exit.
* jit/ThunkGenerators.cpp:
(JSC::baselineGetterReturnThunkGenerator): Deleted.
(JSC::baselineSetterReturnThunkGenerator): Deleted.
* jit/ThunkGenerators.h:
2015-11-02 Saam barati <sbarati@apple.com>
Wrong value recovery for DFG try/catch with a getter that throws during an IC miss
https://bugs.webkit.org/show_bug.cgi?id=150760
Reviewed by Geoffrey Garen.
This is related to using PhantomLocal instead of Flush as
the liveness preservation mechanism for live catch variables.
I'm temporarily switching things back to Flush. This will be a
performance hit for try/catch in the DFG. Landing this patch,
though, will allow me to land try/catch in the FTL. It also
makes try/catch in the DFG sound. I have opened another
bug to further investigate using PhantomLocal as the
liveness preservation mechanism: https://bugs.webkit.org/show_bug.cgi?id=150824
* dfg/DFGLiveCatchVariablePreservationPhase.cpp:
(JSC::DFG::LiveCatchVariablePreservationPhase::handleBlock):
* tests/stress/dfg-try-catch-wrong-value-recovery-on-ic-miss.js: Added.
(assert):
(let.oThrow.get f):
(let.o2.get f):
(foo):
(f):
2015-11-02 Andy Estes <aestes@apple.com>
[Cocoa] Add tvOS and watchOS to SUPPORTED_PLATFORMS
https://bugs.webkit.org/show_bug.cgi?id=150819
Reviewed by Dan Bernstein.
This tells Xcode to include these platforms in its Devices dropdown, making it possible to build in the IDE.
* Configurations/Base.xcconfig:
2015-11-02 Brent Fulgham <bfulgham@apple.com>
[Win] MiniBrowser unable to use WebInspector
https://bugs.webkit.org/show_bug.cgi?id=150810
<rdar://problem/23358514>
Reviewed by Timothy Hatcher.
The CMakeList rule for creating the InjectedScriptSource.min.js was improperly including
the quote characters in the text prepended to InjectedScriptSource.min.js. This caused a
parsing error in the JS file.
The solution was to switch from using "COMMAND echo" to use the more cross-platform
compatible command "COMMAND ${CMAKE_COMMAND} -E echo ...", which handles the string
escaping properly on all platforms.
* CMakeLists.txt: Switch the 'echo' command syntax to be more cross-platform.
2015-11-02 Filip Pizlo <fpizlo@apple.com>
B3 should be able to compile a Patchpoint
https://bugs.webkit.org/show_bug.cgi?id=150750
Reviewed by Geoffrey Garen.
This adds the glue in B3::LowerToAir that turns a B3::PatchpointValue into an Air::Patch
with a B3::PatchpointSpecial.
Along the way, I found some bugs. For starters, it became clear that I wanted to be able
to append constraints to a Stackmap, and I wanted to have more flexibility in how I
created a PatchpointValue. I also wanted more helper methods in ValueRep, since
otherwise I would have had to write a lot of boilerplate.
I discovered, and fixed, a minor goof in Air::Code dumping when there are specials.
There were a ton of indexing bugs in B3StackmapSpecial.
The spiller was broken in case the Def was not the last Arg, since it was adding things
to the insertion set both at instIndex and instIndex + 1, and the two types of additions
could occur in the wrong (i.e. the +1 case first) order with an early Def. We often have
bugs like this. In the DFG, we were paranoid about performance so we only admit out-of-
order insertions as a rare case. I think that we don't really need to be so paranoid.
So, I made the new insertion sets use a stable_sort to ensure that everything happens in
the right order. I changed DFG::BlockInsertionSet to also use stable_sort; it previously
used sort, which is slightly wrong.
This adds a new test that uses Patchpoint to implement a 32-bit add. It works!
* b3/B3InsertionSet.cpp:
(JSC::B3::InsertionSet::execute):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
(JSC::B3::Air::LowerToAir::appendStore):
(JSC::B3::Air::LowerToAir::moveForType):
(JSC::B3::Air::LowerToAir::append):
(JSC::B3::Air::LowerToAir::ensureSpecial):
(JSC::B3::Air::LowerToAir::tryStore):
(JSC::B3::Air::LowerToAir::tryStackSlot):
(JSC::B3::Air::LowerToAir::tryPatchpoint):
(JSC::B3::Air::LowerToAir::tryUpsilon):
* b3/B3LoweringMatcher.patterns:
* b3/B3PatchpointValue.h:
(JSC::B3::PatchpointValue::accepts): Deleted.
(JSC::B3::PatchpointValue::PatchpointValue): Deleted.
* b3/B3Stackmap.h:
(JSC::B3::Stackmap::constrain):
(JSC::B3::Stackmap::appendConstraint):
(JSC::B3::Stackmap::reps):
(JSC::B3::Stackmap::clobber):
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::forEachArgImpl):
(JSC::B3::StackmapSpecial::isValidImpl):
* b3/B3Value.h:
* b3/B3ValueRep.h:
(JSC::B3::ValueRep::ValueRep):
(JSC::B3::ValueRep::reg):
(JSC::B3::ValueRep::operator bool):
(JSC::B3::ValueRep::isAny):
(JSC::B3::ValueRep::isSomeRegister):
(JSC::B3::ValueRep::isReg):
(JSC::B3::ValueRep::isGPR):
(JSC::B3::ValueRep::isFPR):
(JSC::B3::ValueRep::gpr):
(JSC::B3::ValueRep::fpr):
(JSC::B3::ValueRep::isStack):
(JSC::B3::ValueRep::offsetFromFP):
(JSC::B3::ValueRep::isStackArgument):
(JSC::B3::ValueRep::offsetFromSP):
(JSC::B3::ValueRep::isConstant):
(JSC::B3::ValueRep::value):
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::dump):
* b3/air/AirInsertionSet.cpp:
(JSC::B3::Air::InsertionSet::execute):
* b3/testb3.cpp:
(JSC::B3::testComplex):
(JSC::B3::testSimplePatchpoint):
(JSC::B3::run):
* dfg/DFGBlockInsertionSet.cpp:
(JSC::DFG::BlockInsertionSet::execute):
2015-11-02 Mark Lam <mark.lam@apple.com>
Snippefy op_add for the baseline JIT.
https://bugs.webkit.org/show_bug.cgi?id=150129
Reviewed by Geoffrey Garen and Saam Barati.
Performance is neutral for both 32-bit and 64-bit on X86_64.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* jit/JIT.h:
(JSC::JIT::getOperandConstantInt):
- Move getOperandConstantInt() from the JSVALUE64 section to the common section
because the snippet needs it.
* jit/JITAddGenerator.cpp: Added.
(JSC::JITAddGenerator::generateFastPath):
* jit/JITAddGenerator.h: Added.
(JSC::JITAddGenerator::JITAddGenerator):
(JSC::JITAddGenerator::endJumpList):
(JSC::JITAddGenerator::slowPathJumpList):
- JITAddGenerator implements an optimization for the case where 1 of the 2 operands
is a constant int32_t. It does not implement an optimization for the case where
both operands are constant int32_t. This is because:
1. For the baseline JIT, the ASTBuilder will fold the 2 constants together.
2. For the DFG, the AbstractInterpreter will also fold the 2 constants.
Hence, such an optimization path (for 2 constant int32_t operands) would never
be taken, and is why we won't implement it.
* jit/JITArithmetic.cpp:
(JSC::JIT::compileBinaryArithOp):
(JSC::JIT::compileBinaryArithOpSlowCase):
- Removed op_add cases. These are no longer used by the op_add emitters.
(JSC::JIT::emit_op_add):
(JSC::JIT::emitSlow_op_add):
- Moved out from the JSVALUE64 section to the common section, and reimplemented
using the snippet.
* jit/JITArithmetic32_64.cpp:
(JSC::JIT::emitBinaryDoubleOp):
(JSC::JIT::emit_op_add): Deleted.
(JSC::JIT::emitAdd32Constant): Deleted.
(JSC::JIT::emitSlow_op_add): Deleted.
- Remove 32-bit specific version of op_add. The snippet serves both 32-bit
and 64-bit implementations.
* jit/JITInlines.h:
(JSC::JIT::getOperandConstantInt):
- Move getOperandConstantInt() from the JSVALUE64 section to the common section
because the snippet needs it.
2015-11-02 Brian Burg <bburg@apple.com>
Run sort-Xcode-project-file for the JavaScriptCore project.
Unreviewed. Many things were out of order following recent B3 commits.
* JavaScriptCore.xcodeproj/project.pbxproj:
2015-11-02 Yusuke Suzuki <utatane.tea@gmail.com>
Rename op_put_getter_setter to op_put_getter_setter_by_id
https://bugs.webkit.org/show_bug.cgi?id=150773
Reviewed by Mark Lam.
Renaming op_put_getter_setter to op_put_getter_setter_by_id makes this op name consistent with
the other ops' names like op_put_getter_by_id etc.
And to fix build dependencies in Xcode, we added LLIntAssembly.h into Xcode project file.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitPutGetterSetter):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_put_getter_setter_by_id):
(JSC::JIT::emit_op_put_getter_setter): Deleted.
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_put_getter_setter_by_id):
(JSC::JIT::emit_op_put_getter_setter): Deleted.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
2015-11-02 Csaba Osztrogonác <ossy@webkit.org>
Fix the FTL JIT build with system LLVM on Linux
https://bugs.webkit.org/show_bug.cgi?id=150795
Reviewed by Filip Pizlo.
* CMakeLists.txt:
2015-11-01 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Support Generator Syntax
https://bugs.webkit.org/show_bug.cgi?id=150769
Reviewed by Geoffrey Garen.
This patch implements syntax part of ES6 Generators.
1. Add ENABLE_ES6_GENERATORS compile time flag. It is disabled by default, and will be enabled once ES6 generator functionality is implemented.
2. Add lexer support for YIELD. It changes "yield" from reserved-if-strict word to keyword. And it is correct under the ES6 spec.
3. Implement parsing functionality and YieldExprNode stub. YieldExprNode does not emit meaningful bytecodes yet. This should be implemented in the future patch.
4. Accept "yield" Identifier as an label etc. under sloppy mode && non-generator code. http://ecma-international.org/ecma-262/6.0/#sec-generator-function-definitions-static-semantics-early-errors
* Configurations/FeatureDefines.xcconfig:
* bytecompiler/NodesCodegen.cpp:
(JSC::YieldExprNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createYield):
* parser/Keywords.table:
* parser/NodeConstructors.h:
(JSC::YieldExprNode::YieldExprNode):
* parser/Nodes.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::Parser):
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseStatementListItem):
(JSC::Parser<LexerType>::parseVariableDeclarationList):
(JSC::Parser<LexerType>::parseDestructuringPattern):
(JSC::Parser<LexerType>::parseBreakStatement):
(JSC::Parser<LexerType>::parseContinueStatement):
(JSC::Parser<LexerType>::parseTryStatement):
(JSC::Parser<LexerType>::parseStatement):
(JSC::stringForFunctionMode):
(JSC::Parser<LexerType>::parseFunctionParameters):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
(JSC::Parser<LexerType>::parseExportDeclaration):
(JSC::Parser<LexerType>::parseAssignmentExpression):
(JSC::Parser<LexerType>::parseYieldExpression):
(JSC::Parser<LexerType>::parseProperty):
(JSC::Parser<LexerType>::parsePropertyMethod):
(JSC::Parser<LexerType>::parseGetterSetter):
(JSC::Parser<LexerType>::parseFunctionExpression):
(JSC::Parser<LexerType>::parsePrimaryExpression):
(JSC::Parser<LexerType>::parseArrowFunctionExpression):
* parser/Parser.h:
(JSC::Scope::Scope):
(JSC::Scope::setSourceParseMode):
(JSC::Scope::isGenerator):
(JSC::Scope::setIsFunction):
(JSC::Scope::setIsGenerator):
(JSC::Scope::setIsModule):
(JSC::Parser::pushScope):
(JSC::Parser::isYIELDMaskedAsIDENT):
(JSC::Parser::matchSpecIdentifier):
(JSC::Parser::saveState):
(JSC::Parser::restoreState):
* parser/ParserModes.h:
(JSC::isFunctionParseMode):
(JSC::isModuleParseMode):
(JSC::isProgramParseMode):
* parser/ParserTokens.h:
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createYield):
* tests/stress/generator-methods.js: Added.
(Hello.prototype.gen):
(Hello.gen):
(Hello):
(Hello.prototype.set get string_appeared_here):
(Hello.string_appeared_here):
(Hello.prototype.20):
(Hello.20):
(Hello.prototype.42):
(Hello.42):
(let.object.gen):
(let.object.set get string_appeared_here):
(let.object.20):
(let.object.42):
* tests/stress/generator-syntax.js: Added.
(testSyntax):
(testSyntaxError):
(testSyntaxError.Hello.prototype.get gen):
(testSyntaxError.Hello):
(SyntaxError.Unexpected.token.string_appeared_here.Expected.an.opening.string_appeared_here.before.a.method.testSyntaxError.Hello.prototype.set gen):
(SyntaxError.Unexpected.token.string_appeared_here.Expected.an.opening.string_appeared_here.before.a.method.testSyntaxError.Hello):
(SyntaxError.Unexpected.token.string_appeared_here.Expected.an.opening.string_appeared_here.before.a.method.testSyntaxError.gen):
(testSyntaxError.value):
(testSyntaxError.gen.ng):
(testSyntaxError.gen):
(testSyntax.gen):
* tests/stress/yield-and-line-terminator.js: Added.
(testSyntax):
(testSyntaxError):
(testSyntax.gen):
(testSyntaxError.gen):
* tests/stress/yield-label-generator.js: Added.
(testSyntax):
(testSyntaxError):
(testSyntaxError.test):
(SyntaxError.Unexpected.keyword.string_appeared_here.Expected.an.identifier.as.the.target.a.continue.statement.testSyntax.test):
* tests/stress/yield-label.js: Added.
(yield):
(testSyntaxError):
(testSyntaxError.test):
* tests/stress/yield-named-accessors-generator.js: Added.
(t1.let.object.get yield):
(t1.let.object.set yield):
(t1):
(t2.let.object.get yield):
(t2.let.object.set yield):
(t2):
* tests/stress/yield-named-accessors.js: Added.
(t1.let.object.get yield):
(t1.let.object.set yield):
(t1):
(t2.let.object.get yield):
(t2.let.object.set yield):
(t2):
* tests/stress/yield-named-variable-generator.js: Added.
(testSyntax):
(testSyntaxError):
(testSyntaxError.t1):
(testSyntaxError.t1.yield):
(testSyntax.t1.yield):
(testSyntax.t1):
* tests/stress/yield-named-variable.js: Added.
(testSyntax):
(testSyntaxError):
(testSyntax.t1):
(testSyntaxError.t1):
(testSyntax.t1.yield):
(testSyntaxError.t1.yield):
* tests/stress/yield-out-of-generator.js: Added.
(testSyntax):
(testSyntaxError):
(testSyntaxError.hello):
(testSyntaxError.gen.hello):
(testSyntaxError.gen):
(testSyntax.gen):
(testSyntax.gen.ok):
(testSyntaxError.gen.ok):
2015-11-01 Filip Pizlo <fpizlo@apple.com>
Dominators should be factored out of the DFG
https://bugs.webkit.org/show_bug.cgi?id=150764
Reviewed by Geoffrey Garen.
Factored DFGDominators.h/DFGDominators.cpp into WTF. To do this, I made two changes to the
DFG:
1) DFG now has a CFG abstraction called DFG::CFG. The cool thing about this is that in the
future if we wanted to support inverted dominators, we could do it by just creating a
DFG::BackwardCFG.
2) Got rid of DFG::Analysis. From now on, an Analysis being invalidated is expressed by the
DFG::Graph having a null pointer for that analysis. When we "run" the analysis, we
just instantiate it. This makes it much more natural to integrate WTF::Dominators into
the DFG.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAnalysis.h: Removed.
* dfg/DFGCFG.h: Added.
(JSC::DFG::CFG::CFG):
(JSC::DFG::CFG::root):
(JSC::DFG::CFG::newMap<T>):
(JSC::DFG::CFG::successors):
(JSC::DFG::CFG::predecessors):
(JSC::DFG::CFG::index):
(JSC::DFG::CFG::node):
(JSC::DFG::CFG::numNodes):
(JSC::DFG::CFG::dump):
* dfg/DFGCSEPhase.cpp:
* dfg/DFGDisassembler.cpp:
(JSC::DFG::Disassembler::createDumpList):
* dfg/DFGDominators.cpp: Removed.
* dfg/DFGDominators.h:
(JSC::DFG::Dominators::Dominators):
(JSC::DFG::Dominators::strictlyDominates): Deleted.
(JSC::DFG::Dominators::dominates): Deleted.
(JSC::DFG::Dominators::immediateDominatorOf): Deleted.
(JSC::DFG::Dominators::forAllStrictDominatorsOf): Deleted.
(JSC::DFG::Dominators::forAllDominatorsOf): Deleted.
(JSC::DFG::Dominators::forAllBlocksStrictlyDominatedBy): Deleted.
(JSC::DFG::Dominators::forAllBlocksDominatedBy): Deleted.
(JSC::DFG::Dominators::forAllBlocksInDominanceFrontierOf): Deleted.
(JSC::DFG::Dominators::forAllBlocksInIteratedDominanceFrontierOf): Deleted.
(JSC::DFG::Dominators::forAllBlocksInPrunedIteratedDominanceFrontierOf): Deleted.
(JSC::DFG::Dominators::forAllBlocksInDominanceFrontierOfImpl): Deleted.
(JSC::DFG::Dominators::forAllBlocksInIteratedDominanceFrontierOfImpl): Deleted.
(JSC::DFG::Dominators::BlockData::BlockData): Deleted.
* dfg/DFGEdgeDominates.h:
(JSC::DFG::EdgeDominates::operator()):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::Graph):
(JSC::DFG::Graph::dumpBlockHeader):
(JSC::DFG::Graph::invalidateCFG):
(JSC::DFG::Graph::substituteGetLocal):
(JSC::DFG::Graph::handleAssertionFailure):
(JSC::DFG::Graph::ensureDominators):
(JSC::DFG::Graph::ensurePrePostNumbering):
(JSC::DFG::Graph::ensureNaturalLoops):
(JSC::DFG::Graph::valueProfileFor):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::hasDebuggerEnabled):
* dfg/DFGLICMPhase.cpp:
(JSC::DFG::LICMPhase::run):
(JSC::DFG::LICMPhase::attemptHoist):
* dfg/DFGLoopPreHeaderCreationPhase.cpp:
(JSC::DFG::createPreHeader):
(JSC::DFG::LoopPreHeaderCreationPhase::run):
* dfg/DFGNaturalLoops.cpp:
(JSC::DFG::NaturalLoop::dump):
(JSC::DFG::NaturalLoops::NaturalLoops):
(JSC::DFG::NaturalLoops::~NaturalLoops):
(JSC::DFG::NaturalLoops::loopsOf):
(JSC::DFG::NaturalLoops::computeDependencies): Deleted.
(JSC::DFG::NaturalLoops::compute): Deleted.
* dfg/DFGNaturalLoops.h:
(JSC::DFG::NaturalLoops::numLoops):
* dfg/DFGNode.h:
(JSC::DFG::Node::SuccessorsIterable::end):
(JSC::DFG::Node::SuccessorsIterable::size):
(JSC::DFG::Node::SuccessorsIterable::at):
(JSC::DFG::Node::SuccessorsIterable::operator[]):
* dfg/DFGOSREntrypointCreationPhase.cpp:
(JSC::DFG::OSREntrypointCreationPhase::run):
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGPrePostNumbering.cpp:
(JSC::DFG::PrePostNumbering::PrePostNumbering):
(JSC::DFG::PrePostNumbering::~PrePostNumbering):
(JSC::DFG::PrePostNumbering::compute): Deleted.
* dfg/DFGPrePostNumbering.h:
(JSC::DFG::PrePostNumbering::preNumber):
(JSC::DFG::PrePostNumbering::postNumber):
* dfg/DFGPutStackSinkingPhase.cpp:
* dfg/DFGSSACalculator.cpp:
(JSC::DFG::SSACalculator::nonLocalReachingDef):
(JSC::DFG::SSACalculator::reachingDefAtTail):
* dfg/DFGSSACalculator.h:
(JSC::DFG::SSACalculator::computePhis):
* dfg/DFGSSAConversionPhase.cpp:
(JSC::DFG::SSAConversionPhase::run):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::lower):
(JSC::FTL::DFG::LowerDFGToLLVM::safelyInvalidateAfterTermination):
(JSC::FTL::DFG::LowerDFGToLLVM::isValid):
2015-10-31 Filip Pizlo <fpizlo@apple.com>
B3::reduceStrength's DCE should be more agro and less wrong
https://bugs.webkit.org/show_bug.cgi?id=150748
Reviewed by Geoffrey Garen.
First of all, our DCE had a bug where it would keep Upsilons after it deleted the Phis that
they referenced. But our B3 DCE was also not aggressive enough. It would not eliminate
cycles. It was also probably slower than it needed to be, since it would eliminate all
never-referenced things on each fixpoint.
This adds a presume-everyone-is-dead-and-find-live-things style DCE. This is very natural to
write, except for Upsilons. For everything but Upsilons, it's just a worklist algorithm. For
Upsilons, it's a fixpoint. It works fine in the end.
I kept finding bugs in this algorithm when I tested it against my "Complex" test that I was
writing as a compile time benchmark. So, I include that test in this change. I also include
the small lowering extensions that it needed - shifting and zero extending.
This change also adds an LLVM version of the Complex test. Though the LLVM version feels
more natural to write because LLVM has traditional Phi's rather than our quirky Phi's, in
the end LLVM ends up performing very badly - 10x to 20x worse than B3. Some of that gap will
close once we give B3 a register allocator, but still, that's pretty good news for our B3
strategy.
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::lshift64):
(JSC::MacroAssemblerX86_64::rshift64):
* assembler/X86Assembler.h:
(JSC::X86Assembler::shlq_i8r):
(JSC::X86Assembler::shlq_CLr):
(JSC::X86Assembler::imull_rr):
* b3/B3BasicBlock.cpp:
(JSC::B3::BasicBlock::replacePredecessor):
(JSC::B3::BasicBlock::dump):
(JSC::B3::BasicBlock::removeNops): Deleted.
* b3/B3BasicBlock.h:
(JSC::B3::BasicBlock::frequency):
* b3/B3Common.cpp:
(JSC::B3::shouldSaveIRBeforePhase):
(JSC::B3::shouldMeasurePhaseTiming):
* b3/B3Common.h:
(JSC::B3::isRepresentableAsImpl):
* b3/B3Generate.cpp:
(JSC::B3::generate):
(JSC::B3::generateToAir):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::tryAnd):
(JSC::B3::Air::LowerToAir::tryShl):
(JSC::B3::Air::LowerToAir::tryStoreAddLoad):
(JSC::B3::Air::LowerToAir::tryTrunc):
(JSC::B3::Air::LowerToAir::tryZExt32):
(JSC::B3::Air::LowerToAir::tryArgumentReg):
* b3/B3LoweringMatcher.patterns:
* b3/B3PhaseScope.cpp:
(JSC::B3::PhaseScope::PhaseScope):
* b3/B3PhaseScope.h:
* b3/B3ReduceStrength.cpp:
* b3/B3TimingScope.cpp: Added.
(JSC::B3::TimingScope::TimingScope):
(JSC::B3::TimingScope::~TimingScope):
* b3/B3TimingScope.h: Added.
* b3/B3Validate.cpp:
* b3/air/AirAllocateStack.cpp:
(JSC::B3::Air::allocateStack):
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::generate):
* b3/air/AirInstInlines.h:
(JSC::B3::Air::ForEach<Arg>::forEach):
(JSC::B3::Air::Inst::forEach):
(JSC::B3::Air::isLshift32Valid):
(JSC::B3::Air::isLshift64Valid):
* b3/air/AirLiveness.h:
(JSC::B3::Air::Liveness::isAlive):
(JSC::B3::Air::Liveness::Liveness):
(JSC::B3::Air::Liveness::LocalCalc::execute):
* b3/air/AirOpcode.opcodes:
* b3/air/AirPhaseScope.cpp:
(JSC::B3::Air::PhaseScope::PhaseScope):
* b3/air/AirPhaseScope.h:
* b3/testb3.cpp:
(JSC::B3::testBranchEqualFoldPtr):
(JSC::B3::testComplex):
(JSC::B3::run):
* runtime/Options.h:
2015-11-01 Alexey Proskuryakov <ap@apple.com>
[ES6] Add support for toStringTag
https://bugs.webkit.org/show_bug.cgi?id=150696
Re-landing, as this wasn't the culprit.
* runtime/ArrayIteratorPrototype.cpp:
(JSC::ArrayIteratorPrototype::finishCreation):
* runtime/CommonIdentifiers.h:
* runtime/JSArrayBufferPrototype.cpp:
(JSC::JSArrayBufferPrototype::finishCreation):
(JSC::JSArrayBufferPrototype::create):
* runtime/JSDataViewPrototype.cpp:
(JSC::JSDataViewPrototype::create):
(JSC::JSDataViewPrototype::finishCreation):
(JSC::JSDataViewPrototype::createStructure):
* runtime/JSDataViewPrototype.h:
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::finishCreation):
* runtime/JSONObject.cpp:
(JSC::JSONObject::finishCreation):
* runtime/JSPromisePrototype.cpp:
(JSC::JSPromisePrototype::finishCreation):
(JSC::JSPromisePrototype::getOwnPropertySlot):
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::typedArrayViewProtoFuncValues):
(JSC::typedArrayViewProtoGetterFuncToStringTag):
(JSC::JSTypedArrayViewPrototype::JSTypedArrayViewPrototype):
(JSC::JSTypedArrayViewPrototype::finishCreation):
* runtime/MapIteratorPrototype.cpp:
(JSC::MapIteratorPrototype::finishCreation):
(JSC::MapIteratorPrototypeFuncNext):
* runtime/MapPrototype.cpp:
(JSC::MapPrototype::finishCreation):
* runtime/MathObject.cpp:
(JSC::MathObject::finishCreation):
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncToString):
* runtime/SetIteratorPrototype.cpp:
(JSC::SetIteratorPrototype::finishCreation):
(JSC::SetIteratorPrototypeFuncNext):
* runtime/SetPrototype.cpp:
(JSC::SetPrototype::finishCreation):
* runtime/SmallStrings.cpp:
(JSC::SmallStrings::SmallStrings):
(JSC::SmallStrings::initializeCommonStrings):
(JSC::SmallStrings::visitStrongReferences):
* runtime/SmallStrings.h:
(JSC::SmallStrings::typeString):
(JSC::SmallStrings::objectStringStart):
(JSC::SmallStrings::nullObjectString):
(JSC::SmallStrings::undefinedObjectString):
* runtime/StringIteratorPrototype.cpp:
(JSC::StringIteratorPrototype::finishCreation):
* runtime/SymbolPrototype.cpp:
(JSC::SymbolPrototype::finishCreation):
* runtime/WeakMapPrototype.cpp:
(JSC::WeakMapPrototype::finishCreation):
(JSC::getWeakMapData):
* runtime/WeakSetPrototype.cpp:
(JSC::WeakSetPrototype::finishCreation):
(JSC::getWeakMapData):
* tests/es6.yaml:
* tests/modules/namespace.js:
* tests/stress/symbol-tostringtag.js: Copied from Source/JavaScriptCore/tests/stress/symbol-tostringtag.js.
2015-11-01 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r191815 and r191821.
https://bugs.webkit.org/show_bug.cgi?id=150781
Seems to have broken JSC API tests on some platforms
(Requested by ap on #webkit).
Reverted changesets:
"[ES6] Add support for toStringTag"
https://bugs.webkit.org/show_bug.cgi?id=150696
http://trac.webkit.org/changeset/191815
"Unreviewed, forgot to mark tests as passing for new feature."
http://trac.webkit.org/changeset/191821
2015-11-01 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r191858.
https://bugs.webkit.org/show_bug.cgi?id=150780
Broke the build (Requested by ap on #webkit).
Reverted changeset:
"Rename op_put_getter_setter to op_put_getter_setter_by_id"
https://bugs.webkit.org/show_bug.cgi?id=150773
http://trac.webkit.org/changeset/191858
2015-11-01 Filip Pizlo <fpizlo@apple.com>
Unreviewed, add a FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=150777.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::AddressSelector::acceptRoot):
2015-11-01 Filip Pizlo <fpizlo@apple.com>
Unreviewed, add a FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=150775.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::tryTrunc):
2015-11-01 Yusuke Suzuki <utatane.tea@gmail.com>
Rename op_put_getter_setter to op_put_getter_setter_by_id
https://bugs.webkit.org/show_bug.cgi?id=150773
Reviewed by Mark Lam.
Renaming op_put_getter_setter to op_put_getter_setter_by_id makes this op name consistent with
the other ops' names like op_put_getter_by_id etc.
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitPutGetterSetter):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_put_getter_setter_by_id):
(JSC::JIT::emit_op_put_getter_setter): Deleted.
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_put_getter_setter_by_id):
(JSC::JIT::emit_op_put_getter_setter): Deleted.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
2015-10-31 Andreas Kling <akling@apple.com>
Add a debug overlay with information about web process resource usage.
<https://webkit.org/b/150599>
Reviewed by Darin Adler.
Have Heap track the exact number of bytes allocated in CopiedBlock, MarkedBlock and
WeakBlock objects, keeping them in a single location that can be sampled by the
resource usage overlay thread.
The bulk of these changes is threading a Heap& through from sites where blocks are
allocated or freed.
* heap/CopiedBlock.cpp:
(JSC::CopiedBlock::createNoZeroFill):
(JSC::CopiedBlock::destroy):
(JSC::CopiedBlock::create):
* heap/CopiedBlock.h:
* heap/CopiedSpace.cpp:
(JSC::CopiedSpace::~CopiedSpace):
(JSC::CopiedSpace::tryAllocateOversize):
(JSC::CopiedSpace::tryReallocateOversize):
* heap/CopiedSpaceInlines.h:
(JSC::CopiedSpace::recycleEvacuatedBlock):
(JSC::CopiedSpace::recycleBorrowedBlock):
(JSC::CopiedSpace::allocateBlockForCopyingPhase):
(JSC::CopiedSpace::allocateBlock):
(JSC::CopiedSpace::startedCopying):
* heap/Heap.cpp:
(JSC::Heap::~Heap):
(JSC::Heap::sweepNextLogicallyEmptyWeakBlock):
* heap/Heap.h:
(JSC::Heap::blockBytesAllocated):
* heap/HeapInlines.h:
(JSC::Heap::didAllocateBlock):
(JSC::Heap::didFreeBlock):
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::allocateBlock):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::create):
(JSC::MarkedBlock::destroy):
* heap/MarkedBlock.h:
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::freeBlock):
* heap/WeakBlock.cpp:
(JSC::WeakBlock::create):
(JSC::WeakBlock::destroy):
* heap/WeakBlock.h:
* heap/WeakSet.cpp:
(JSC::WeakSet::~WeakSet):
(JSC::WeakSet::addAllocator):
(JSC::WeakSet::removeAllocator):
2015-10-30 Filip Pizlo <fpizlo@apple.com>
Air should eliminate dead code
https://bugs.webkit.org/show_bug.cgi?id=150746
Reviewed by Geoffrey Garen.
This adds a very simple dead code elimination to Air. It simply looks at whether a Tmp or
StackSlot has ever been used by a live instruction. An instruction is live if it has non-arg
effects (branching, returning, calling, etc) or if it stores to a live Arg. An Arg is live if
it references a live Tmp or StackSlot, or if it is neither a Tmp nor a StackSlot. The phase
runs these rules to fixpoint, and then removes the dead instructions.
This also changes the AirOpcodes parser to handle multiple attributes per opcode, so that we
could conceivably say things like "FooBar /branch /effects". It also adds the /effects
attribute, which we currently use for Breakpoint and nothing else. C calls, patchpoints, and
checks are all Specials, and the Special base class by default always claims that the
instruction has effects. In the future, we could have B3 use a Patch in Air to implement
exotic math constructs; then the Special associated with that thing would claim that there
are no effects.
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/air/AirBasicBlock.h:
(JSC::B3::Air::BasicBlock::begin):
(JSC::B3::Air::BasicBlock::end):
(JSC::B3::Air::BasicBlock::at):
(JSC::B3::Air::BasicBlock::last):
(JSC::B3::Air::BasicBlock::resize):
(JSC::B3::Air::BasicBlock::appendInst):
* b3/air/AirEliminateDeadCode.cpp: Added.
(JSC::B3::Air::eliminateDeadCode):
* b3/air/AirEliminateDeadCode.h: Added.
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::generate):
* b3/air/AirInst.h:
* b3/air/AirOpcode.opcodes:
* b3/air/AirSpecial.cpp:
(JSC::B3::Air::Special::name):
(JSC::B3::Air::Special::hasNonArgNonControlEffects):
(JSC::B3::Air::Special::dump):
* b3/air/AirSpecial.h:
* b3/air/opcode_generator.rb:
2015-10-31 Filip Pizlo <fpizlo@apple.com>
Air needs a late register liveness phase that calls Special::reportUsedRegisters()
https://bugs.webkit.org/show_bug.cgi?id=150511
Reviewed by Saam Barati.
This change adds such a phase. In the process of writing it, I was reminded about the
glaring efficiency bugs in Air::Liveness and so I filed a bug and added FIXMEs.
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/air/AirAllocateStack.cpp:
(JSC::B3::Air::allocateStack):
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::generate):
* b3/air/AirReportUsedRegisters.cpp: Added.
(JSC::B3::Air::reportUsedRegisters):
* b3/air/AirReportUsedRegisters.h: Added.
2015-10-31 Brian Burg <bburg@apple.com>
Builtins generator should put WebCore-only wrappers in the per-builtin header
https://bugs.webkit.org/show_bug.cgi?id=150539
Reviewed by Youenn Fablet.
If generating for WebCore, put the XXXWrapper and related boilerplate
in the per-builtin header instead of making a separate XXXWrapper.h.
Rebaseline the tests.
* CMakeLists.txt:
* DerivedSources.make:
* Scripts/builtins/builtins.py:
* Scripts/builtins/builtins_generate_separate_header.py:
(BuiltinsSeparateHeaderGenerator.generate_output):
(generate_header_includes):
* Scripts/builtins/builtins_generate_separate_wrapper.py: Deleted.
* Scripts/builtins/builtins_templates.py: Be consistent with variables.
* Scripts/generate-js-builtins.py:
* Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
2015-10-31 Saam barati <sbarati@apple.com>
JSC should have a forceGCSlowPaths option
https://bugs.webkit.org/show_bug.cgi?id=150744
Reviewed by Filip Pizlo.
This patch implements the forceGCSlowPaths option.
It defaults to false, but when it is set to true,
the JITs will always allocate objects along the slow
path. This will be helpful for writing a certain class
of tests. This may also come in handy for debugging
later.
This patch also adds the "forceGCSlowPaths" function
in jsc.cpp which sets the option to true. If you
use this function in a jsc stress test, it's best
to call it as the first thing in the program before
we JIT anything.
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::emitAllocateJSCell):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::allocateCell):
* jit/JITInlines.h:
(JSC::JIT::emitAllocateJSObject):
* jsc.cpp:
(GlobalObject::finishCreation):
(functionEdenGC):
(functionForceGCSlowPaths):
(functionHeapSize):
* runtime/Options.h:
2015-10-30 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Test Debugger.scriptParsed events received after opening inspector frontend
https://bugs.webkit.org/show_bug.cgi?id=150753
Reviewed by Timothy Hatcher.
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
Only set the directives on the SourceProvider if we were parsing the
entire file (Program or Module), not if we are in function parsing mode.
This was inadvertently clearing the directives stored on the
SourceProvider when the function parse didn't see directives and reset
the values on the source provider.
2015-10-30 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add lowering for B3's Sub operation with integers
https://bugs.webkit.org/show_bug.cgi?id=150749
Reviewed by Filip Pizlo.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::trySub):
(JSC::B3::Air::LowerToAir::tryStoreSubLoad):
* b3/B3LoweringMatcher.patterns:
Identical to Add but obviously NotCommutative.
* b3/B3ReduceStrength.cpp:
Turn Add/Sub with zero into an identity. I only added for
Add since Sub with a constant is always turned into an Add.
Also switched the Sub optimizations to put the strongest first.
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testAddArgImm):
(JSC::B3::testAddImmArg):
(JSC::B3::testSubArgs):
(JSC::B3::testSubArgImm):
(JSC::B3::testSubImmArg):
(JSC::B3::testSubArgs32):
(JSC::B3::testSubArgImm32):
(JSC::B3::testSubImmArg32):
(JSC::B3::testStoreSubLoad):
(JSC::B3::run):
2015-10-30 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add the Air Opcode definitions to the Xcode project file
https://bugs.webkit.org/show_bug.cgi?id=150701
Reviewed by Geoffrey Garen.
* JavaScriptCore.xcodeproj/project.pbxproj:
Easier for those who use Xcode :)
2015-10-30 Filip Pizlo <fpizlo@apple.com>
Unreviewed, removing FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=150540.
* b3/B3ValueRep.h:
2015-10-30 Michael Saboff <msaboff@apple.com>
Windows X86-64 change for Crash making a tail call from a getter to a host function
https://bugs.webkit.org/show_bug.cgi?id=150737
Reviewed by Geoffrey Garen.
Need to make the same change for Windows X86-64 as was made in change set
http://trac.webkit.org/changeset/191765.
* jit/JITStubsMSVC64.asm:
2015-10-30 Keith Miller <keith_miller@apple.com>
Unreviewed, forgot to mark tests as passing for new feature.
* tests/es6.yaml:
2015-10-30 Filip Pizlo <fpizlo@apple.com>
B3 should be able to compile a control flow diamond
https://bugs.webkit.org/show_bug.cgi?id=150720
Reviewed by Benjamin Poulain.
Adds support for Branch, Jump, Upsilon, and Phi. Adds some basic strength reduction for
comparisons and boolean-like operations.
* assembler/MacroAssembler.cpp:
(WTF::printInternal):
* assembler/MacroAssembler.h:
* b3/B3BasicBlockUtils.h:
(JSC::B3::replacePredecessor):
(JSC::B3::resetReachability):
* b3/B3CheckValue.h:
* b3/B3Common.h:
(JSC::B3::isRepresentableAsImpl):
(JSC::B3::isRepresentableAs):
* b3/B3Const32Value.cpp:
(JSC::B3::Const32Value::subConstant):
(JSC::B3::Const32Value::equalConstant):
(JSC::B3::Const32Value::notEqualConstant):
(JSC::B3::Const32Value::dumpMeta):
* b3/B3Const32Value.h:
* b3/B3Const64Value.cpp:
(JSC::B3::Const64Value::subConstant):
(JSC::B3::Const64Value::equalConstant):
(JSC::B3::Const64Value::notEqualConstant):
(JSC::B3::Const64Value::dumpMeta):
* b3/B3Const64Value.h:
* b3/B3ConstDoubleValue.cpp:
(JSC::B3::ConstDoubleValue::subConstant):
(JSC::B3::ConstDoubleValue::equalConstant):
(JSC::B3::ConstDoubleValue::notEqualConstant):
(JSC::B3::ConstDoubleValue::dumpMeta):
* b3/B3ConstDoubleValue.h:
* b3/B3ControlValue.cpp:
(JSC::B3::ControlValue::~ControlValue):
(JSC::B3::ControlValue::convertToJump):
(JSC::B3::ControlValue::dumpMeta):
* b3/B3ControlValue.h:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::imm):
(JSC::B3::Air::LowerToAir::tryStackSlot):
(JSC::B3::Air::LowerToAir::tryUpsilon):
(JSC::B3::Air::LowerToAir::tryPhi):
(JSC::B3::Air::LowerToAir::tryBranch):
(JSC::B3::Air::LowerToAir::tryJump):
(JSC::B3::Air::LowerToAir::tryIdentity):
* b3/B3LoweringMatcher.patterns:
* b3/B3Opcode.h:
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::resetReachability):
(JSC::B3::Procedure::dump):
* b3/B3ReduceStrength.cpp:
* b3/B3UpsilonValue.cpp:
(JSC::B3::UpsilonValue::dumpMeta):
* b3/B3UpsilonValue.h:
(JSC::B3::UpsilonValue::accepts): Deleted.
(JSC::B3::UpsilonValue::phi): Deleted.
(JSC::B3::UpsilonValue::UpsilonValue): Deleted.
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::subConstant):
(JSC::B3::Value::equalConstant):
(JSC::B3::Value::notEqualConstant):
(JSC::B3::Value::returnsBool):
(JSC::B3::Value::asTriState):
(JSC::B3::Value::effects):
* b3/B3Value.h:
* b3/B3ValueInlines.h:
(JSC::B3::Value::asInt32):
(JSC::B3::Value::isInt32):
(JSC::B3::Value::hasInt64):
(JSC::B3::Value::asInt64):
(JSC::B3::Value::isInt64):
(JSC::B3::Value::hasInt):
(JSC::B3::Value::asIntPtr):
(JSC::B3::Value::isIntPtr):
(JSC::B3::Value::hasDouble):
(JSC::B3::Value::asDouble):
(JSC::B3::Value::isEqualToDouble):
(JSC::B3::Value::hasNumber):
(JSC::B3::Value::representableAs):
(JSC::B3::Value::asNumber):
(JSC::B3::Value::stackmap):
* b3/air/AirArg.cpp:
(JSC::B3::Air::Arg::dump):
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::resCond):
(JSC::B3::Air::Arg::doubleCond):
(JSC::B3::Air::Arg::special):
(JSC::B3::Air::Arg::isResCond):
(JSC::B3::Air::Arg::isDoubleCond):
(JSC::B3::Air::Arg::isSpecial):
(JSC::B3::Air::Arg::isGP):
(JSC::B3::Air::Arg::isFP):
(JSC::B3::Air::Arg::asResultCondition):
(JSC::B3::Air::Arg::asDoubleCondition):
(JSC::B3::Air::Arg::Arg):
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::resetReachability):
(JSC::B3::Air::Code::dump):
* b3/air/AirOpcode.opcodes:
* b3/air/opcode_generator.rb:
* b3/testb3.cpp:
(hiddenTruthBecauseNoReturnIsStupid):
(usage):
(JSC::B3::compile):
(JSC::B3::invoke):
(JSC::B3::compileAndRun):
(JSC::B3::test42):
(JSC::B3::testStoreLoadStackSlot):
(JSC::B3::testBranch):
(JSC::B3::testDiamond):
(JSC::B3::testBranchNotEqual):
(JSC::B3::testBranchFold):
(JSC::B3::testDiamondFold):
(JSC::B3::run):
(run):
(main):
2015-10-30 Keith Miller <keith_miller@apple.com>
[ES6] Add support for toStringTag
https://bugs.webkit.org/show_bug.cgi?id=150696
Reviewed by Geoffrey Garen.
This patch adds support for Symbol.toStringTag. This is a simple
feature, if an object passed to Object.prototype.toString() has a
toStringTag we use the tag in the string rather than the class info.
Added a test that checks this works for all the default supported classes
along with the corresponding prototype and custom cases.
* runtime/ArrayIteratorPrototype.cpp:
(JSC::ArrayIteratorPrototype::finishCreation):
* runtime/CommonIdentifiers.h:
* runtime/JSArrayBufferPrototype.cpp:
(JSC::JSArrayBufferPrototype::finishCreation):
* runtime/JSDataViewPrototype.cpp:
(JSC::JSDataViewPrototype::finishCreation):
* runtime/JSDataViewPrototype.h:
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::finishCreation):
* runtime/JSONObject.cpp:
(JSC::JSONObject::finishCreation):
* runtime/JSPromisePrototype.cpp:
(JSC::JSPromisePrototype::finishCreation):
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::typedArrayViewProtoGetterFuncToStringTag):
(JSC::JSTypedArrayViewPrototype::finishCreation):
* runtime/MapIteratorPrototype.cpp:
(JSC::MapIteratorPrototype::finishCreation):
* runtime/MapPrototype.cpp:
(JSC::MapPrototype::finishCreation):
* runtime/MathObject.cpp:
(JSC::MathObject::finishCreation):
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncToString):
* runtime/SetIteratorPrototype.cpp:
(JSC::SetIteratorPrototype::finishCreation):
* runtime/SetPrototype.cpp:
(JSC::SetPrototype::finishCreation):
* runtime/SmallStrings.cpp:
(JSC::SmallStrings::SmallStrings):
(JSC::SmallStrings::initializeCommonStrings):
(JSC::SmallStrings::visitStrongReferences):
* runtime/SmallStrings.h:
(JSC::SmallStrings::objectStringStart):
* runtime/StringIteratorPrototype.cpp:
(JSC::StringIteratorPrototype::finishCreation):
* runtime/SymbolPrototype.cpp:
(JSC::SymbolPrototype::finishCreation):
* runtime/WeakMapPrototype.cpp:
(JSC::WeakMapPrototype::finishCreation):
* runtime/WeakSetPrototype.cpp:
(JSC::WeakSetPrototype::finishCreation):
* tests/modules/namespace.js:
* tests/stress/symbol-tostringtag.js: Added.
(toStr):
(strName):
(classes.string_appeared_here):
2015-10-29 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Do not show JavaScriptCore builtins in inspector
https://bugs.webkit.org/show_bug.cgi?id=146049
Reviewed by Geoffrey Garen.
* debugger/Debugger.cpp:
When gathering scripts to notify the inspector / debuggers about
skip over sources containing host / built-in functions as those
for those won't contain source code developers expect to see.
2015-10-29 Joseph Pecoraro <pecoraro@apple.com>
Fix typo in "use strict" in TypedArray builtins
https://bugs.webkit.org/show_bug.cgi?id=150709
Reviewed by Geoffrey Garen.
* builtins/TypedArray.prototype.js:
(toLocaleString):
2015-10-29 Philippe Normand <pnormand@igalia.com>
[GTK][Mac] disable OBJC JSC API
https://bugs.webkit.org/show_bug.cgi?id=150500
Reviewed by Alex Christensen.
* API/JSBase.h: Disable the Objective-C API on Mac for the GTK port.
2015-10-29 Filip Pizlo <fpizlo@apple.com>
Air::handleCalleeSaves shouldn't save/restore the frame pointer
https://bugs.webkit.org/show_bug.cgi?id=150688
Reviewed by Michael Saboff.
We save/restore the FP inside Air::generate().
* b3/air/AirHandleCalleeSaves.cpp:
(JSC::B3::Air::handleCalleeSaves):
2015-10-29 Michael Saboff <msaboff@apple.com>
Crash making a tail call from a getter to a host function
https://bugs.webkit.org/show_bug.cgi?id=150663
Reviewed by Geoffrey Garen.
Change the inline assembly versions of getHostCallReturnValue() to pass the location of the callee
call frame to getHostCallReturnValueWithExecState(). We were passing the caller's frame address.
* jit/JITOperations.cpp:
2015-10-29 Filip Pizlo <fpizlo@apple.com>
B3::LowerToAir::imm() should work for both 32-bit and 64-bit immediates
https://bugs.webkit.org/show_bug.cgi?id=150685
Reviewed by Geoffrey Garen.
In B3, a constant must match the type of its use. In Air, immediates don't have type, they
only have representation. A 32-bit immediate (i.e. Arg::imm) can be used either for 32-bit
operations or for 64-bit operations. The only difference from a Arg::imm64 is that it
requires fewer bits.
In the B3->Air lowering, we have a lot of code that is effectively polymorphic over integer
type. That code should still be able to use Arg::imm, and it should work even for 64-bit
immediates - so long as they are representable as 32-bit immediates. Therefore, the imm()
helper should happily accept either Const32Value or Const64Value.
We already sort of had this with immAnyType(), but it just turns out that anyone using
immAnyType() should really be using imm().
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::imm):
(JSC::B3::Air::LowerToAir::tryStore):
(JSC::B3::Air::LowerToAir::tryConst64):
(JSC::B3::Air::LowerToAir::immAnyInt): Deleted.
* b3/testb3.cpp:
(JSC::B3::testAdd1):
(JSC::B3::testAdd1Ptr):
(JSC::B3::testStoreAddLoad):
(JSC::B3::run):
2015-10-29 Filip Pizlo <fpizlo@apple.com>
StoreOpLoad pattern matching should check effects between the Store and Load
https://bugs.webkit.org/show_bug.cgi?id=150534
Reviewed by Geoffrey Garen.
If we turn:
a = Load(addr)
b = Add(a, 42)
Store(b, addr)
Into:
Add $42, (addr)
Then we must make sure that we didn't really have this to begin with:
a = Load(addr)
Store(666, addr)
b = Add(a, 42)
Store(b, addr)
That's because pattern matching doesn't care about control flow, and it finds the Load
just using data flow. This patch fleshes out B3's aliasing analysis, and makes it powerful
enough to broadly ask questions about whether such a code motion of the Load is legal.
* b3/B3Effects.cpp:
(JSC::B3::Effects::interferes):
(JSC::B3::Effects::dump):
* b3/B3Effects.h:
(JSC::B3::Effects::mustExecute):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::run):
(JSC::B3::Air::LowerToAir::commitInternal):
(JSC::B3::Air::LowerToAir::crossesInterference):
(JSC::B3::Air::LowerToAir::effectiveAddr):
(JSC::B3::Air::LowerToAir::loadAddr):
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::addBlock):
(JSC::B3::Procedure::resetValueOwners):
(JSC::B3::Procedure::resetReachability):
* b3/B3Procedure.h:
* b3/B3Value.cpp:
(JSC::B3::Value::effects):
* b3/B3Value.h:
* b3/testb3.cpp:
(JSC::B3::testStoreAddLoad):
(JSC::B3::testStoreAddLoadInterference):
(JSC::B3::testStoreAddAndLoad):
(JSC::B3::testLoadOffsetUsingAdd):
(JSC::B3::testLoadOffsetUsingAddInterference):
(JSC::B3::testLoadOffsetUsingAddNotConstant):
(JSC::B3::run):
2015-10-29 Brady Eidson <beidson@apple.com>
Modern IDB: deleteObjectStore support.
https://bugs.webkit.org/show_bug.cgi?id=150673
Reviewed by Alex Christensen.
* runtime/VM.h:
2015-10-29 Mark Lam <mark.lam@apple.com>
cdjs-tests.yaml/main.js.ftl fails due to FTL ArithSub code for supporting UntypedUse operands.
https://bugs.webkit.org/show_bug.cgi?id=150687
Unreviewed.
Disabling the feature while it is being debugged. I'm doing this by effectively
rolling out only the changes in FTLCapabilities.cpp.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
2015-10-29 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix iOS build.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::store64):
2015-10-29 Alex Christensen <achristensen@webkit.org>
Fix Mac CMake build
https://bugs.webkit.org/show_bug.cgi?id=150686
Reviewed by Filip Pizlo.
* API/ObjCCallbackFunction.mm:
* CMakeLists.txt:
* PlatformMac.cmake:
2015-10-29 Filip Pizlo <fpizlo@apple.com>
Air needs syntax for escaping StackSlots
https://bugs.webkit.org/show_bug.cgi?id=150430
Reviewed by Geoffrey Garen.
This adds lowering for FramePointer and StackSlot, and to enable this, it adds the Lea
instruction for getting the value of an address. This is necessary to support arbitrary
lowerings of StackSlot, since the only way to get the "value" of a StackSlot in Air is with
this new instruction.
Lea uses a new Role, called UseAddr. This describes exactly what the Intel-style LEA opcode
would do: it evaluates an address, but does not load from it or store to it.
Lea is also the only way to escape a StackSlot. Well, more accurately, UseAddr is the only
way to escape and UseAddr is only used by Lea. The stack allocation phase now understands
that StackSlots may escape, and factors this into its analysis.
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::lea):
* b3/B3AddressMatcher.patterns:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::run):
(JSC::B3::Air::LowerToAir::addr):
(JSC::B3::Air::LowerToAir::loadAddr):
(JSC::B3::Air::LowerToAir::AddressSelector::tryAdd):
(JSC::B3::Air::LowerToAir::AddressSelector::tryFramePointer):
(JSC::B3::Air::LowerToAir::AddressSelector::tryStackSlot):
(JSC::B3::Air::LowerToAir::AddressSelector::tryDirect):
(JSC::B3::Air::LowerToAir::tryConst64):
(JSC::B3::Air::LowerToAir::tryFramePointer):
(JSC::B3::Air::LowerToAir::tryStackSlot):
(JSC::B3::Air::LowerToAir::tryIdentity):
* b3/B3LoweringMatcher.patterns:
* b3/B3MemoryValue.cpp:
(JSC::B3::MemoryValue::~MemoryValue):
(JSC::B3::MemoryValue::accessByteSize):
(JSC::B3::MemoryValue::dumpMeta):
* b3/B3MemoryValue.h:
* b3/B3ReduceStrength.cpp:
* b3/B3StackSlotValue.h:
(JSC::B3::StackSlotValue::accepts): Deleted.
* b3/B3Type.h:
(JSC::B3::pointerType):
(JSC::B3::sizeofType):
* b3/B3Validate.cpp:
* b3/B3Value.h:
* b3/air/AirAllocateStack.cpp:
(JSC::B3::Air::allocateStack):
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::isUse):
(JSC::B3::Air::Arg::isDef):
(JSC::B3::Air::Arg::forEachTmp):
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::addStackSlot):
(JSC::B3::Air::Code::addSpecial):
* b3/air/AirCode.h:
* b3/air/AirOpcode.opcodes:
* b3/air/AirSpillEverything.cpp:
(JSC::B3::Air::spillEverything):
* b3/air/AirStackSlot.h:
(JSC::B3::Air::StackSlot::byteSize):
(JSC::B3::Air::StackSlot::kind):
(JSC::B3::Air::StackSlot::isLocked):
(JSC::B3::Air::StackSlot::index):
(JSC::B3::Air::StackSlot::alignment):
* b3/air/opcode_generator.rb:
* b3/testb3.cpp:
(JSC::B3::testLoadOffsetUsingAddNotConstant):
(JSC::B3::testFramePointer):
(JSC::B3::testStackSlot):
(JSC::B3::testLoadFromFramePointer):
(JSC::B3::testStoreLoadStackSlot):
(JSC::B3::run):
2015-10-29 Saam barati <sbarati@apple.com>
we're incorrectly adjusting a stack location with respect to the localsOffset in FTLCompile
https://bugs.webkit.org/show_bug.cgi?id=150655
Reviewed by Filip Pizlo.
We're recomputing this value for an *OSRExitDescriptor* for every one
of its corresponding *OSRExits*. This is having a multiplicative
effect on offsets because each computation is relative to the previous
value. We must do this computation just once per OSRExitDescriptor.
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
2015-10-28 Filip Pizlo <fpizlo@apple.com>
Air::spillEverything() should try to replace tmps with spill slots without using registers whenever possible
https://bugs.webkit.org/show_bug.cgi?id=150657
Reviewed by Geoffrey Garen.
Also added the ability to store an immediate to memory.
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::storePtr):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::store64):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::store64):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::imm):
(JSC::B3::Air::LowerToAir::immAnyInt):
(JSC::B3::Air::LowerToAir::immOrTmp):
(JSC::B3::Air::LowerToAir::tryStore):
* b3/air/AirOpcode.opcodes:
* b3/air/AirSpillEverything.cpp:
(JSC::B3::Air::spillEverything):
* b3/testb3.cpp:
(JSC::B3::testStore):
(JSC::B3::testStoreConstant):
(JSC::B3::testStoreConstantPtr):
(JSC::B3::testTrunc):
(JSC::B3::run):
2015-10-28 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Rename InspectorResourceAgent to InspectorNetworkAgent
https://bugs.webkit.org/show_bug.cgi?id=150654
Reviewed by Geoffrey Garen.
* inspector/scripts/codegen/generator.py:
2015-10-28 Filip Pizlo <fpizlo@apple.com>
B3::reduceStrength() should do DCE
https://bugs.webkit.org/show_bug.cgi?id=150656
Reviewed by Saam Barati.
* b3/B3BasicBlock.cpp:
(JSC::B3::BasicBlock::removeNops): This now deletes the values from the procedure, to preserve the invariant that valuesInProc == valuesInBlocks.
* b3/B3BasicBlock.h:
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::deleteValue): Add a utility used by removeNops().
(JSC::B3::Procedure::addValueIndex): Make sure that we reuse Value indices so that m_values doesn't get too sparse.
* b3/B3Procedure.h:
(JSC::B3::Procedure::ValuesCollection::iterator::iterator): Teach this that m_values can be slightly sparse.
(JSC::B3::Procedure::ValuesCollection::iterator::operator++):
(JSC::B3::Procedure::ValuesCollection::iterator::operator!=):
(JSC::B3::Procedure::ValuesCollection::iterator::findNext):
(JSC::B3::Procedure::values):
* b3/B3ProcedureInlines.h:
(JSC::B3::Procedure::add): Use addValueIndex() instead of always creating a new index.
* b3/B3ReduceStrength.cpp: Implement the optimization using UseCounts and Effects.
2015-10-28 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Remove unused / duplicate WebSocket timeline records
https://bugs.webkit.org/show_bug.cgi?id=150647
Reviewed by Timothy Hatcher.
* inspector/protocol/Timeline.json:
2015-10-28 Filip Pizlo <fpizlo@apple.com>
B3::LowerToAir should not duplicate Loads
https://bugs.webkit.org/show_bug.cgi?id=150651
Reviewed by Benjamin Poulain.
The instruction selector may decide to fuse two Values into one. This ordinarily only happens
if we haven't already emitted code that uses the Value and the Value has only one direct
user. Once we have emitted such code, we ensure that everyone knows that we have "locked" the
Value: we won't emit any more code for it in the future.
The optimization to fuse Loads was forgetting to do all of these things, and so generated
code would have a lot of duplicated Loads. That's bad and this change fixes that.
Ordinarily, this is far less tricky because the pattern matcher does this for us via
acceptInternals() and acceptInternalsLate(). I added a comment to this effect. I hope that we
won't need to do this manually very often.
Also found an uninitialized value bug in UseCounts. That was making all of this super hard to
debug.
* b3/B3IndexMap.h:
(JSC::B3::IndexMap::IndexMap):
(JSC::B3::IndexMap::resize):
(JSC::B3::IndexMap::operator[]):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::tmp):
(JSC::B3::Air::LowerToAir::canBeInternal):
(JSC::B3::Air::LowerToAir::commitInternal):
(JSC::B3::Air::LowerToAir::effectiveAddr):
(JSC::B3::Air::LowerToAir::loadAddr):
(JSC::B3::Air::LowerToAir::appendBinOp):
(JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
(JSC::B3::Air::LowerToAir::acceptInternals):
* b3/B3UseCounts.cpp:
(JSC::B3::UseCounts::UseCounts):
2015-10-28 Mark Lam <mark.lam@apple.com>
JITSubGenerator::generateFastPath() does not need to be inlined.
https://bugs.webkit.org/show_bug.cgi?id=150645
Reviewed by Geoffrey Garen.
Moving it to a .cpp file to reduce code size. Benchmarks shows this to be
perf neutral.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* ftl/FTLCompile.cpp:
* jit/JITSubGenerator.cpp: Added.
(JSC::JITSubGenerator::generateFastPath):
* jit/JITSubGenerator.h:
(JSC::JITSubGenerator::JITSubGenerator):
(JSC::JITSubGenerator::endJumpList):
(JSC::JITSubGenerator::slowPathJumpList):
(JSC::JITSubGenerator::generateFastPath): Deleted.
2015-10-28 Filip Pizlo <fpizlo@apple.com>
[B3] handleCommutativity should canonicalize commutative operations over non-constants
https://bugs.webkit.org/show_bug.cgi?id=150649
Reviewed by Saam Barati.
Turn this: Add(value1, value2)
Into this: Add(value2, value1)
But ony if value2 should come before value1 according to our total ordering. This will allow
CSE to observe the equality between commuted versions of the same operation, since we will
first canonicalize them into the same order.
* b3/B3ReduceStrength.cpp:
2015-10-28 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix the build for case sensitive file systems.
* b3/air/AirBasicBlock.h:
* b3/air/AirStackSlot.h:
2015-10-28 Filip Pizlo <fpizlo@apple.com>
Create a super rough prototype of B3
https://bugs.webkit.org/show_bug.cgi?id=150280
Reviewed by Benjamin Poulain.
This changeset adds the basic scaffolding of the B3 compiler. B3 stands for Bare Bones
Backend. It's a low-level SSA-based language-agnostic compiler. The basic structure allows
for aggressive C-level optimizations and an awesome portable backend. The backend, called
Air (Assembly IR), is a reflective abstraction over our MacroAssembler. The abstraction is
defined using a spec file (AirOpcode.opcodes) which describes the various kinds of
instructions that we wish to support. Then, the B3::LowerToAir phase, which does our
instruction selection, reflectively selects Air opcodes by querying which instruction forms
are possible. Air allows for optimal register allocation and stack layout. Currently the
register allocator isn't written, but the stack layout is.
Of course this isn't done yet. It can only compile simple programs, seen in the "test suite"
called "testb3.cpp". There's a lot of optimizations that have to be written and a lot of
stuff added to the instruction selector. But it's a neat start.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/MacroAssembler.cpp:
(WTF::printInternal):
* assembler/MacroAssembler.h:
* b3: Added.
* b3/B3AddressMatcher.patterns: Added.
* b3/B3ArgumentRegValue.cpp: Added.
(JSC::B3::ArgumentRegValue::~ArgumentRegValue):
(JSC::B3::ArgumentRegValue::dumpMeta):
* b3/B3ArgumentRegValue.h: Added.
* b3/B3BasicBlock.cpp: Added.
(JSC::B3::BasicBlock::BasicBlock):
(JSC::B3::BasicBlock::~BasicBlock):
(JSC::B3::BasicBlock::append):
(JSC::B3::BasicBlock::addPredecessor):
(JSC::B3::BasicBlock::removePredecessor):
(JSC::B3::BasicBlock::replacePredecessor):
(JSC::B3::BasicBlock::removeNops):
(JSC::B3::BasicBlock::dump):
(JSC::B3::BasicBlock::deepDump):
* b3/B3BasicBlock.h: Added.
(JSC::B3::BasicBlock::index):
(JSC::B3::BasicBlock::begin):
(JSC::B3::BasicBlock::end):
(JSC::B3::BasicBlock::size):
(JSC::B3::BasicBlock::at):
(JSC::B3::BasicBlock::last):
(JSC::B3::BasicBlock::values):
(JSC::B3::BasicBlock::numPredecessors):
(JSC::B3::BasicBlock::predecessor):
(JSC::B3::BasicBlock::predecessors):
(JSC::B3::BasicBlock::frequency):
(JSC::B3::DeepBasicBlockDump::DeepBasicBlockDump):
(JSC::B3::DeepBasicBlockDump::dump):
(JSC::B3::deepDump):
* b3/B3BasicBlockInlines.h: Added.
(JSC::B3::BasicBlock::appendNew):
(JSC::B3::BasicBlock::numSuccessors):
(JSC::B3::BasicBlock::successor):
(JSC::B3::BasicBlock::successors):
(JSC::B3::BasicBlock::successorBlock):
(JSC::B3::BasicBlock::successorBlocks):
* b3/B3BasicBlockUtils.h: Added.
(JSC::B3::addPredecessor):
(JSC::B3::removePredecessor):
(JSC::B3::replacePredecessor):
(JSC::B3::resetReachability):
(JSC::B3::blocksInPreOrder):
(JSC::B3::blocksInPostOrder):
* b3/B3BlockWorklist.h: Added.
* b3/B3CheckSpecial.cpp: Added.
(JSC::B3::Air::numB3Args):
(JSC::B3::CheckSpecial::CheckSpecial):
(JSC::B3::CheckSpecial::~CheckSpecial):
(JSC::B3::CheckSpecial::hiddenBranch):
(JSC::B3::CheckSpecial::forEachArg):
(JSC::B3::CheckSpecial::isValid):
(JSC::B3::CheckSpecial::admitsStack):
(JSC::B3::CheckSpecial::generate):
(JSC::B3::CheckSpecial::dumpImpl):
(JSC::B3::CheckSpecial::deepDumpImpl):
* b3/B3CheckSpecial.h: Added.
* b3/B3CheckValue.cpp: Added.
(JSC::B3::CheckValue::~CheckValue):
(JSC::B3::CheckValue::dumpMeta):
* b3/B3CheckValue.h: Added.
* b3/B3Common.cpp: Added.
(JSC::B3::shouldDumpIR):
(JSC::B3::shouldDumpIRAtEachPhase):
(JSC::B3::shouldValidateIR):
(JSC::B3::shouldValidateIRAtEachPhase):
(JSC::B3::shouldSaveIRBeforePhase):
* b3/B3Common.h: Added.
(JSC::B3::is64Bit):
(JSC::B3::is32Bit):
* b3/B3Commutativity.cpp: Added.
(WTF::printInternal):
* b3/B3Commutativity.h: Added.
* b3/B3Const32Value.cpp: Added.
(JSC::B3::Const32Value::~Const32Value):
(JSC::B3::Const32Value::negConstant):
(JSC::B3::Const32Value::addConstant):
(JSC::B3::Const32Value::subConstant):
(JSC::B3::Const32Value::dumpMeta):
* b3/B3Const32Value.h: Added.
* b3/B3Const64Value.cpp: Added.
(JSC::B3::Const64Value::~Const64Value):
(JSC::B3::Const64Value::negConstant):
(JSC::B3::Const64Value::addConstant):
(JSC::B3::Const64Value::subConstant):
(JSC::B3::Const64Value::dumpMeta):
* b3/B3Const64Value.h: Added.
* b3/B3ConstDoubleValue.cpp: Added.
(JSC::B3::ConstDoubleValue::~ConstDoubleValue):
(JSC::B3::ConstDoubleValue::negConstant):
(JSC::B3::ConstDoubleValue::addConstant):
(JSC::B3::ConstDoubleValue::subConstant):
(JSC::B3::ConstDoubleValue::dumpMeta):
* b3/B3ConstDoubleValue.h: Added.
(JSC::B3::ConstDoubleValue::accepts):
(JSC::B3::ConstDoubleValue::value):
(JSC::B3::ConstDoubleValue::ConstDoubleValue):
* b3/B3ConstPtrValue.h: Added.
(JSC::B3::ConstPtrValue::value):
(JSC::B3::ConstPtrValue::ConstPtrValue):
* b3/B3ControlValue.cpp: Added.
(JSC::B3::ControlValue::~ControlValue):
(JSC::B3::ControlValue::dumpMeta):
* b3/B3ControlValue.h: Added.
* b3/B3Effects.cpp: Added.
(JSC::B3::Effects::dump):
* b3/B3Effects.h: Added.
(JSC::B3::Effects::mustExecute):
* b3/B3FrequencyClass.cpp: Added.
(WTF::printInternal):
* b3/B3FrequencyClass.h: Added.
* b3/B3FrequentedBlock.h: Added.
* b3/B3Generate.cpp: Added.
(JSC::B3::generate):
(JSC::B3::generateToAir):
* b3/B3Generate.h: Added.
* b3/B3GenericFrequentedBlock.h: Added.
(JSC::B3::GenericFrequentedBlock::GenericFrequentedBlock):
(JSC::B3::GenericFrequentedBlock::operator==):
(JSC::B3::GenericFrequentedBlock::operator!=):
(JSC::B3::GenericFrequentedBlock::operator bool):
(JSC::B3::GenericFrequentedBlock::block):
(JSC::B3::GenericFrequentedBlock::frequency):
(JSC::B3::GenericFrequentedBlock::dump):
* b3/B3HeapRange.cpp: Added.
(JSC::B3::HeapRange::dump):
* b3/B3HeapRange.h: Added.
(JSC::B3::HeapRange::HeapRange):
(JSC::B3::HeapRange::top):
(JSC::B3::HeapRange::operator==):
(JSC::B3::HeapRange::operator!=):
(JSC::B3::HeapRange::operator bool):
(JSC::B3::HeapRange::begin):
(JSC::B3::HeapRange::end):
(JSC::B3::HeapRange::overlaps):
* b3/B3IndexMap.h: Added.
(JSC::B3::IndexMap::IndexMap):
(JSC::B3::IndexMap::resize):
(JSC::B3::IndexMap::operator[]):
* b3/B3IndexSet.h: Added.
(JSC::B3::IndexSet::IndexSet):
(JSC::B3::IndexSet::add):
(JSC::B3::IndexSet::contains):
(JSC::B3::IndexSet::Iterable::Iterable):
(JSC::B3::IndexSet::Iterable::iterator::iterator):
(JSC::B3::IndexSet::Iterable::iterator::operator*):
(JSC::B3::IndexSet::Iterable::iterator::operator++):
(JSC::B3::IndexSet::Iterable::iterator::operator==):
(JSC::B3::IndexSet::Iterable::iterator::operator!=):
(JSC::B3::IndexSet::Iterable::begin):
(JSC::B3::IndexSet::Iterable::end):
(JSC::B3::IndexSet::values):
(JSC::B3::IndexSet::indices):
(JSC::B3::IndexSet::dump):
* b3/B3InsertionSet.cpp: Added.
(JSC::B3::InsertionSet::execute):
* b3/B3InsertionSet.h: Added.
(JSC::B3::InsertionSet::InsertionSet):
(JSC::B3::InsertionSet::code):
(JSC::B3::InsertionSet::appendInsertion):
(JSC::B3::InsertionSet::insertValue):
* b3/B3InsertionSetInlines.h: Added.
(JSC::B3::InsertionSet::insert):
* b3/B3LowerToAir.cpp: Added.
(JSC::B3::Air::LowerToAir::LowerToAir):
(JSC::B3::Air::LowerToAir::run):
(JSC::B3::Air::LowerToAir::tmp):
(JSC::B3::Air::LowerToAir::effectiveAddr):
(JSC::B3::Air::LowerToAir::addr):
(JSC::B3::Air::LowerToAir::loadAddr):
(JSC::B3::Air::LowerToAir::imm):
(JSC::B3::Air::LowerToAir::immOrTmp):
(JSC::B3::Air::LowerToAir::appendBinOp):
(JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
(JSC::B3::Air::LowerToAir::moveForType):
(JSC::B3::Air::LowerToAir::relaxedMoveForType):
(JSC::B3::Air::LowerToAir::append):
(JSC::B3::Air::LowerToAir::AddressSelector::AddressSelector):
(JSC::B3::Air::LowerToAir::AddressSelector::acceptRoot):
(JSC::B3::Air::LowerToAir::AddressSelector::acceptRootLate):
(JSC::B3::Air::LowerToAir::AddressSelector::acceptInternals):
(JSC::B3::Air::LowerToAir::AddressSelector::acceptInternalsLate):
(JSC::B3::Air::LowerToAir::AddressSelector::acceptOperands):
(JSC::B3::Air::LowerToAir::AddressSelector::acceptOperandsLate):
(JSC::B3::Air::LowerToAir::AddressSelector::tryAddShift1):
(JSC::B3::Air::LowerToAir::AddressSelector::tryAddShift2):
(JSC::B3::Air::LowerToAir::AddressSelector::tryAdd):
(JSC::B3::Air::LowerToAir::AddressSelector::tryDirect):
(JSC::B3::Air::LowerToAir::acceptRoot):
(JSC::B3::Air::LowerToAir::acceptRootLate):
(JSC::B3::Air::LowerToAir::acceptInternals):
(JSC::B3::Air::LowerToAir::acceptInternalsLate):
(JSC::B3::Air::LowerToAir::acceptOperands):
(JSC::B3::Air::LowerToAir::acceptOperandsLate):
(JSC::B3::Air::LowerToAir::tryLoad):
(JSC::B3::Air::LowerToAir::tryAdd):
(JSC::B3::Air::LowerToAir::tryAnd):
(JSC::B3::Air::LowerToAir::tryStoreAddLoad):
(JSC::B3::Air::LowerToAir::tryStoreAndLoad):
(JSC::B3::Air::LowerToAir::tryStore):
(JSC::B3::Air::LowerToAir::tryTruncArgumentReg):
(JSC::B3::Air::LowerToAir::tryTrunc):
(JSC::B3::Air::LowerToAir::tryArgumentReg):
(JSC::B3::Air::LowerToAir::tryConst32):
(JSC::B3::Air::LowerToAir::tryConst64):
(JSC::B3::Air::LowerToAir::tryIdentity):
(JSC::B3::Air::LowerToAir::tryReturn):
(JSC::B3::lowerToAir):
* b3/B3LowerToAir.h: Added.
* b3/B3LoweringMatcher.patterns: Added.
* b3/B3MemoryValue.cpp: Added.
(JSC::B3::MemoryValue::~MemoryValue):
(JSC::B3::MemoryValue::dumpMeta):
* b3/B3MemoryValue.h: Added.
* b3/B3Opcode.cpp: Added.
(WTF::printInternal):
* b3/B3Opcode.h: Added.
(JSC::B3::isCheckMath):
* b3/B3Origin.cpp: Added.
(JSC::B3::Origin::dump):
* b3/B3Origin.h: Added.
(JSC::B3::Origin::Origin):
(JSC::B3::Origin::operator bool):
(JSC::B3::Origin::data):
* b3/B3PatchpointSpecial.cpp: Added.
(JSC::B3::PatchpointSpecial::PatchpointSpecial):
(JSC::B3::PatchpointSpecial::~PatchpointSpecial):
(JSC::B3::PatchpointSpecial::forEachArg):
(JSC::B3::PatchpointSpecial::isValid):
(JSC::B3::PatchpointSpecial::admitsStack):
(JSC::B3::PatchpointSpecial::generate):
(JSC::B3::PatchpointSpecial::dumpImpl):
(JSC::B3::PatchpointSpecial::deepDumpImpl):
* b3/B3PatchpointSpecial.h: Added.
* b3/B3PatchpointValue.cpp: Added.
(JSC::B3::PatchpointValue::~PatchpointValue):
(JSC::B3::PatchpointValue::dumpMeta):
* b3/B3PatchpointValue.h: Added.
(JSC::B3::PatchpointValue::accepts):
(JSC::B3::PatchpointValue::PatchpointValue):
* b3/B3PhaseScope.cpp: Added.
(JSC::B3::PhaseScope::PhaseScope):
(JSC::B3::PhaseScope::~PhaseScope):
* b3/B3PhaseScope.h: Added.
* b3/B3Procedure.cpp: Added.
(JSC::B3::Procedure::Procedure):
(JSC::B3::Procedure::~Procedure):
(JSC::B3::Procedure::addBlock):
(JSC::B3::Procedure::resetReachability):
(JSC::B3::Procedure::dump):
(JSC::B3::Procedure::blocksInPreOrder):
(JSC::B3::Procedure::blocksInPostOrder):
* b3/B3Procedure.h: Added.
(JSC::B3::Procedure::size):
(JSC::B3::Procedure::at):
(JSC::B3::Procedure::operator[]):
(JSC::B3::Procedure::iterator::iterator):
(JSC::B3::Procedure::iterator::operator*):
(JSC::B3::Procedure::iterator::operator++):
(JSC::B3::Procedure::iterator::operator==):
(JSC::B3::Procedure::iterator::operator!=):
(JSC::B3::Procedure::iterator::findNext):
(JSC::B3::Procedure::begin):
(JSC::B3::Procedure::end):
(JSC::B3::Procedure::ValuesCollection::ValuesCollection):
(JSC::B3::Procedure::ValuesCollection::iterator::iterator):
(JSC::B3::Procedure::ValuesCollection::iterator::operator*):
(JSC::B3::Procedure::ValuesCollection::iterator::operator++):
(JSC::B3::Procedure::ValuesCollection::iterator::operator==):
(JSC::B3::Procedure::ValuesCollection::iterator::operator!=):
(JSC::B3::Procedure::ValuesCollection::begin):
(JSC::B3::Procedure::ValuesCollection::end):
(JSC::B3::Procedure::ValuesCollection::size):
(JSC::B3::Procedure::ValuesCollection::at):
(JSC::B3::Procedure::ValuesCollection::operator[]):
(JSC::B3::Procedure::values):
(JSC::B3::Procedure::setLastPhaseName):
(JSC::B3::Procedure::lastPhaseName):
* b3/B3ProcedureInlines.h: Added.
(JSC::B3::Procedure::add):
* b3/B3ReduceStrength.cpp: Added.
(JSC::B3::reduceStrength):
* b3/B3ReduceStrength.h: Added.
* b3/B3StackSlotKind.cpp: Added.
(WTF::printInternal):
* b3/B3StackSlotKind.h: Added.
* b3/B3StackSlotValue.cpp: Added.
(JSC::B3::StackSlotValue::~StackSlotValue):
(JSC::B3::StackSlotValue::dumpMeta):
* b3/B3StackSlotValue.h: Added.
(JSC::B3::StackSlotValue::accepts):
(JSC::B3::StackSlotValue::byteSize):
(JSC::B3::StackSlotValue::kind):
(JSC::B3::StackSlotValue::offsetFromFP):
(JSC::B3::StackSlotValue::setOffsetFromFP):
(JSC::B3::StackSlotValue::StackSlotValue):
* b3/B3Stackmap.cpp: Added.
(JSC::B3::Stackmap::Stackmap):
(JSC::B3::Stackmap::~Stackmap):
(JSC::B3::Stackmap::dump):
* b3/B3Stackmap.h: Added.
(JSC::B3::Stackmap::constrain):
(JSC::B3::Stackmap::reps):
(JSC::B3::Stackmap::clobber):
(JSC::B3::Stackmap::clobbered):
(JSC::B3::Stackmap::setGenerator):
* b3/B3StackmapSpecial.cpp: Added.
(JSC::B3::StackmapSpecial::StackmapSpecial):
(JSC::B3::StackmapSpecial::~StackmapSpecial):
(JSC::B3::StackmapSpecial::reportUsedRegisters):
(JSC::B3::StackmapSpecial::extraClobberedRegs):
(JSC::B3::StackmapSpecial::forEachArgImpl):
(JSC::B3::StackmapSpecial::isValidImpl):
(JSC::B3::StackmapSpecial::admitsStackImpl):
(JSC::B3::StackmapSpecial::appendRepsImpl):
(JSC::B3::StackmapSpecial::repForArg):
* b3/B3StackmapSpecial.h: Added.
* b3/B3SuccessorCollection.h: Added.
(JSC::B3::SuccessorCollection::SuccessorCollection):
(JSC::B3::SuccessorCollection::size):
(JSC::B3::SuccessorCollection::at):
(JSC::B3::SuccessorCollection::operator[]):
(JSC::B3::SuccessorCollection::iterator::iterator):
(JSC::B3::SuccessorCollection::iterator::operator*):
(JSC::B3::SuccessorCollection::iterator::operator++):
(JSC::B3::SuccessorCollection::iterator::operator==):
(JSC::B3::SuccessorCollection::iterator::operator!=):
(JSC::B3::SuccessorCollection::begin):
(JSC::B3::SuccessorCollection::end):
* b3/B3SwitchCase.cpp: Added.
(JSC::B3::SwitchCase::dump):
* b3/B3SwitchCase.h: Added.
(JSC::B3::SwitchCase::SwitchCase):
(JSC::B3::SwitchCase::operator bool):
(JSC::B3::SwitchCase::caseValue):
(JSC::B3::SwitchCase::target):
(JSC::B3::SwitchCase::targetBlock):
* b3/B3SwitchValue.cpp: Added.
(JSC::B3::SwitchValue::~SwitchValue):
(JSC::B3::SwitchValue::removeCase):
(JSC::B3::SwitchValue::appendCase):
(JSC::B3::SwitchValue::dumpMeta):
(JSC::B3::SwitchValue::SwitchValue):
* b3/B3SwitchValue.h: Added.
(JSC::B3::SwitchValue::accepts):
(JSC::B3::SwitchValue::numCaseValues):
(JSC::B3::SwitchValue::caseValue):
(JSC::B3::SwitchValue::caseValues):
(JSC::B3::SwitchValue::fallThrough):
(JSC::B3::SwitchValue::size):
(JSC::B3::SwitchValue::at):
(JSC::B3::SwitchValue::operator[]):
(JSC::B3::SwitchValue::iterator::iterator):
(JSC::B3::SwitchValue::iterator::operator*):
(JSC::B3::SwitchValue::iterator::operator++):
(JSC::B3::SwitchValue::iterator::operator==):
(JSC::B3::SwitchValue::iterator::operator!=):
(JSC::B3::SwitchValue::begin):
(JSC::B3::SwitchValue::end):
* b3/B3Type.cpp: Added.
(WTF::printInternal):
* b3/B3Type.h: Added.
(JSC::B3::isInt):
(JSC::B3::isFloat):
(JSC::B3::pointerType):
* b3/B3UpsilonValue.cpp: Added.
(JSC::B3::UpsilonValue::~UpsilonValue):
(JSC::B3::UpsilonValue::dumpMeta):
* b3/B3UpsilonValue.h: Added.
(JSC::B3::UpsilonValue::accepts):
(JSC::B3::UpsilonValue::phi):
(JSC::B3::UpsilonValue::UpsilonValue):
* b3/B3UseCounts.cpp: Added.
(JSC::B3::UseCounts::UseCounts):
(JSC::B3::UseCounts::~UseCounts):
* b3/B3UseCounts.h: Added.
(JSC::B3::UseCounts::operator[]):
* b3/B3Validate.cpp: Added.
(JSC::B3::validate):
* b3/B3Validate.h: Added.
* b3/B3Value.cpp: Added.
(JSC::B3::Value::~Value):
(JSC::B3::Value::replaceWithIdentity):
(JSC::B3::Value::replaceWithNop):
(JSC::B3::Value::dump):
(JSC::B3::Value::deepDump):
(JSC::B3::Value::negConstant):
(JSC::B3::Value::addConstant):
(JSC::B3::Value::subConstant):
(JSC::B3::Value::effects):
(JSC::B3::Value::performSubstitution):
(JSC::B3::Value::dumpMeta):
(JSC::B3::Value::typeFor):
* b3/B3Value.h: Added.
(JSC::B3::DeepValueDump::DeepValueDump):
(JSC::B3::DeepValueDump::dump):
(JSC::B3::deepDump):
* b3/B3ValueInlines.h: Added.
(JSC::B3::Value::as):
(JSC::B3::Value::isConstant):
(JSC::B3::Value::hasInt32):
(JSC::B3::Value::asInt32):
(JSC::B3::Value::hasInt64):
(JSC::B3::Value::asInt64):
(JSC::B3::Value::hasInt):
(JSC::B3::Value::asInt):
(JSC::B3::Value::isInt):
(JSC::B3::Value::hasIntPtr):
(JSC::B3::Value::asIntPtr):
(JSC::B3::Value::hasDouble):
(JSC::B3::Value::asDouble):
(JSC::B3::Value::stackmap):
* b3/B3ValueRep.cpp: Added.
(JSC::B3::ValueRep::dump):
(WTF::printInternal):
* b3/B3ValueRep.h: Added.
(JSC::B3::ValueRep::ValueRep):
(JSC::B3::ValueRep::reg):
(JSC::B3::ValueRep::stack):
(JSC::B3::ValueRep::stackArgument):
(JSC::B3::ValueRep::constant):
(JSC::B3::ValueRep::constantDouble):
(JSC::B3::ValueRep::kind):
(JSC::B3::ValueRep::operator bool):
(JSC::B3::ValueRep::offsetFromFP):
(JSC::B3::ValueRep::offsetFromSP):
(JSC::B3::ValueRep::value):
(JSC::B3::ValueRep::doubleValue):
* b3/air: Added.
* b3/air/AirAllocateStack.cpp: Added.
(JSC::B3::Air::allocateStack):
* b3/air/AirAllocateStack.h: Added.
* b3/air/AirArg.cpp: Added.
(JSC::B3::Air::Arg::dump):
* b3/air/AirArg.h: Added.
(JSC::B3::Air::Arg::isUse):
(JSC::B3::Air::Arg::isDef):
(JSC::B3::Air::Arg::typeForB3Type):
(JSC::B3::Air::Arg::Arg):
(JSC::B3::Air::Arg::imm):
(JSC::B3::Air::Arg::imm64):
(JSC::B3::Air::Arg::addr):
(JSC::B3::Air::Arg::stack):
(JSC::B3::Air::Arg::callArg):
(JSC::B3::Air::Arg::isValidScale):
(JSC::B3::Air::Arg::logScale):
(JSC::B3::Air::Arg::index):
(JSC::B3::Air::Arg::relCond):
(JSC::B3::Air::Arg::resCond):
(JSC::B3::Air::Arg::special):
(JSC::B3::Air::Arg::operator==):
(JSC::B3::Air::Arg::operator!=):
(JSC::B3::Air::Arg::operator bool):
(JSC::B3::Air::Arg::kind):
(JSC::B3::Air::Arg::isTmp):
(JSC::B3::Air::Arg::isImm):
(JSC::B3::Air::Arg::isImm64):
(JSC::B3::Air::Arg::isAddr):
(JSC::B3::Air::Arg::isStack):
(JSC::B3::Air::Arg::isCallArg):
(JSC::B3::Air::Arg::isIndex):
(JSC::B3::Air::Arg::isRelCond):
(JSC::B3::Air::Arg::isResCond):
(JSC::B3::Air::Arg::isSpecial):
(JSC::B3::Air::Arg::isAlive):
(JSC::B3::Air::Arg::tmp):
(JSC::B3::Air::Arg::value):
(JSC::B3::Air::Arg::pointerValue):
(JSC::B3::Air::Arg::base):
(JSC::B3::Air::Arg::hasOffset):
(JSC::B3::Air::Arg::offset):
(JSC::B3::Air::Arg::stackSlot):
(JSC::B3::Air::Arg::scale):
(JSC::B3::Air::Arg::isGPTmp):
(JSC::B3::Air::Arg::isFPTmp):
(JSC::B3::Air::Arg::isGP):
(JSC::B3::Air::Arg::isFP):
(JSC::B3::Air::Arg::hasType):
(JSC::B3::Air::Arg::type):
(JSC::B3::Air::Arg::isType):
(JSC::B3::Air::Arg::isGPR):
(JSC::B3::Air::Arg::gpr):
(JSC::B3::Air::Arg::isFPR):
(JSC::B3::Air::Arg::fpr):
(JSC::B3::Air::Arg::isReg):
(JSC::B3::Air::Arg::reg):
(JSC::B3::Air::Arg::gpTmpIndex):
(JSC::B3::Air::Arg::fpTmpIndex):
(JSC::B3::Air::Arg::tmpIndex):
(JSC::B3::Air::Arg::withOffset):
(JSC::B3::Air::Arg::forEachTmpFast):
(JSC::B3::Air::Arg::forEachTmp):
(JSC::B3::Air::Arg::asTrustedImm32):
(JSC::B3::Air::Arg::asTrustedImm64):
(JSC::B3::Air::Arg::asTrustedImmPtr):
(JSC::B3::Air::Arg::asAddress):
(JSC::B3::Air::Arg::asBaseIndex):
(JSC::B3::Air::Arg::asRelationalCondition):
(JSC::B3::Air::Arg::asResultCondition):
(JSC::B3::Air::Arg::isHashTableDeletedValue):
(JSC::B3::Air::Arg::hash):
(JSC::B3::Air::ArgHash::hash):
(JSC::B3::Air::ArgHash::equal):
* b3/air/AirBasicBlock.cpp: Added.
(JSC::B3::Air::BasicBlock::addPredecessor):
(JSC::B3::Air::BasicBlock::removePredecessor):
(JSC::B3::Air::BasicBlock::replacePredecessor):
(JSC::B3::Air::BasicBlock::dump):
(JSC::B3::Air::BasicBlock::deepDump):
(JSC::B3::Air::BasicBlock::BasicBlock):
* b3/air/AirBasicBlock.h: Added.
(JSC::B3::Air::BasicBlock::index):
(JSC::B3::Air::BasicBlock::size):
(JSC::B3::Air::BasicBlock::begin):
(JSC::B3::Air::BasicBlock::end):
(JSC::B3::Air::BasicBlock::at):
(JSC::B3::Air::BasicBlock::last):
(JSC::B3::Air::BasicBlock::appendInst):
(JSC::B3::Air::BasicBlock::append):
(JSC::B3::Air::BasicBlock::numSuccessors):
(JSC::B3::Air::BasicBlock::successor):
(JSC::B3::Air::BasicBlock::successors):
(JSC::B3::Air::BasicBlock::successorBlock):
(JSC::B3::Air::BasicBlock::successorBlocks):
(JSC::B3::Air::BasicBlock::numPredecessors):
(JSC::B3::Air::BasicBlock::predecessor):
(JSC::B3::Air::BasicBlock::predecessors):
(JSC::B3::Air::DeepBasicBlockDump::DeepBasicBlockDump):
(JSC::B3::Air::DeepBasicBlockDump::dump):
(JSC::B3::Air::deepDump):
* b3/air/AirCCallSpecial.cpp: Added.
(JSC::B3::Air::CCallSpecial::CCallSpecial):
(JSC::B3::Air::CCallSpecial::~CCallSpecial):
(JSC::B3::Air::CCallSpecial::forEachArg):
(JSC::B3::Air::CCallSpecial::isValid):
(JSC::B3::Air::CCallSpecial::admitsStack):
(JSC::B3::Air::CCallSpecial::reportUsedRegisters):
(JSC::B3::Air::CCallSpecial::generate):
(JSC::B3::Air::CCallSpecial::extraClobberedRegs):
(JSC::B3::Air::CCallSpecial::dumpImpl):
(JSC::B3::Air::CCallSpecial::deepDumpImpl):
* b3/air/AirCCallSpecial.h: Added.
* b3/air/AirCode.cpp: Added.
(JSC::B3::Air::Code::Code):
(JSC::B3::Air::Code::~Code):
(JSC::B3::Air::Code::addBlock):
(JSC::B3::Air::Code::addStackSlot):
(JSC::B3::Air::Code::addSpecial):
(JSC::B3::Air::Code::cCallSpecial):
(JSC::B3::Air::Code::resetReachability):
(JSC::B3::Air::Code::dump):
(JSC::B3::Air::Code::findFirstBlockIndex):
(JSC::B3::Air::Code::findNextBlockIndex):
(JSC::B3::Air::Code::findNextBlock):
* b3/air/AirCode.h: Added.
(JSC::B3::Air::Code::newTmp):
(JSC::B3::Air::Code::numTmps):
(JSC::B3::Air::Code::callArgAreaSize):
(JSC::B3::Air::Code::requestCallArgAreaSize):
(JSC::B3::Air::Code::frameSize):
(JSC::B3::Air::Code::setFrameSize):
(JSC::B3::Air::Code::calleeSaveRegisters):
(JSC::B3::Air::Code::size):
(JSC::B3::Air::Code::at):
(JSC::B3::Air::Code::operator[]):
(JSC::B3::Air::Code::iterator::iterator):
(JSC::B3::Air::Code::iterator::operator*):
(JSC::B3::Air::Code::iterator::operator++):
(JSC::B3::Air::Code::iterator::operator==):
(JSC::B3::Air::Code::iterator::operator!=):
(JSC::B3::Air::Code::begin):
(JSC::B3::Air::Code::end):
(JSC::B3::Air::Code::StackSlotsCollection::StackSlotsCollection):
(JSC::B3::Air::Code::StackSlotsCollection::size):
(JSC::B3::Air::Code::StackSlotsCollection::at):
(JSC::B3::Air::Code::StackSlotsCollection::operator[]):
(JSC::B3::Air::Code::StackSlotsCollection::iterator::iterator):
(JSC::B3::Air::Code::StackSlotsCollection::iterator::operator*):
(JSC::B3::Air::Code::StackSlotsCollection::iterator::operator++):
(JSC::B3::Air::Code::StackSlotsCollection::iterator::operator==):
(JSC::B3::Air::Code::StackSlotsCollection::iterator::operator!=):
(JSC::B3::Air::Code::StackSlotsCollection::begin):
(JSC::B3::Air::Code::StackSlotsCollection::end):
(JSC::B3::Air::Code::stackSlots):
(JSC::B3::Air::Code::SpecialsCollection::SpecialsCollection):
(JSC::B3::Air::Code::SpecialsCollection::size):
(JSC::B3::Air::Code::SpecialsCollection::at):
(JSC::B3::Air::Code::SpecialsCollection::operator[]):
(JSC::B3::Air::Code::SpecialsCollection::iterator::iterator):
(JSC::B3::Air::Code::SpecialsCollection::iterator::operator*):
(JSC::B3::Air::Code::SpecialsCollection::iterator::operator++):
(JSC::B3::Air::Code::SpecialsCollection::iterator::operator==):
(JSC::B3::Air::Code::SpecialsCollection::iterator::operator!=):
(JSC::B3::Air::Code::SpecialsCollection::begin):
(JSC::B3::Air::Code::SpecialsCollection::end):
(JSC::B3::Air::Code::specials):
(JSC::B3::Air::Code::setLastPhaseName):
(JSC::B3::Air::Code::lastPhaseName):
* b3/air/AirFrequentedBlock.h: Added.
* b3/air/AirGenerate.cpp: Added.
(JSC::B3::Air::generate):
* b3/air/AirGenerate.h: Added.
* b3/air/AirGenerated.cpp: Added.
* b3/air/AirGenerationContext.h: Added.
* b3/air/AirHandleCalleeSaves.cpp: Added.
(JSC::B3::Air::handleCalleeSaves):
* b3/air/AirHandleCalleeSaves.h: Added.
* b3/air/AirInsertionSet.cpp: Added.
(JSC::B3::Air::InsertionSet::execute):
* b3/air/AirInsertionSet.h: Added.
(JSC::B3::Air::InsertionSet::InsertionSet):
(JSC::B3::Air::InsertionSet::code):
(JSC::B3::Air::InsertionSet::appendInsertion):
(JSC::B3::Air::InsertionSet::insertInst):
(JSC::B3::Air::InsertionSet::insert):
* b3/air/AirInst.cpp: Added.
(JSC::B3::Air::Inst::dump):
* b3/air/AirInst.h: Added.
(JSC::B3::Air::Inst::Inst):
(JSC::B3::Air::Inst::opcode):
(JSC::B3::Air::Inst::forEachTmpFast):
(JSC::B3::Air::Inst::forEachTmp):
* b3/air/AirInstInlines.h: Added.
(JSC::B3::Air::ForEach<Tmp>::forEach):
(JSC::B3::Air::ForEach<Arg>::forEach):
(JSC::B3::Air::Inst::forEach):
(JSC::B3::Air::Inst::hasSpecial):
(JSC::B3::Air::Inst::extraClobberedRegs):
(JSC::B3::Air::Inst::reportUsedRegisters):
(JSC::B3::Air::isShiftValid):
(JSC::B3::Air::isLshift32Valid):
* b3/air/AirLiveness.h: Added.
(JSC::B3::Air::Liveness::Liveness):
(JSC::B3::Air::Liveness::liveAtHead):
(JSC::B3::Air::Liveness::liveAtTail):
(JSC::B3::Air::Liveness::LocalCalc::LocalCalc):
(JSC::B3::Air::Liveness::LocalCalc::live):
(JSC::B3::Air::Liveness::LocalCalc::takeLive):
(JSC::B3::Air::Liveness::LocalCalc::execute):
* b3/air/AirOpcode.opcodes: Added.
* b3/air/AirPhaseScope.cpp: Added.
(JSC::B3::Air::PhaseScope::PhaseScope):
(JSC::B3::Air::PhaseScope::~PhaseScope):
* b3/air/AirPhaseScope.h: Added.
* b3/air/AirRegisterPriority.cpp: Added.
(JSC::B3::Air::gprsInPriorityOrder):
(JSC::B3::Air::fprsInPriorityOrder):
(JSC::B3::Air::regsInPriorityOrder):
* b3/air/AirRegisterPriority.h: Added.
(JSC::B3::Air::RegistersInPriorityOrder<GPRInfo>::inPriorityOrder):
(JSC::B3::Air::RegistersInPriorityOrder<FPRInfo>::inPriorityOrder):
(JSC::B3::Air::regsInPriorityOrder):
* b3/air/AirSpecial.cpp: Added.
(JSC::B3::Air::Special::Special):
(JSC::B3::Air::Special::~Special):
(JSC::B3::Air::Special::name):
(JSC::B3::Air::Special::dump):
(JSC::B3::Air::Special::deepDump):
* b3/air/AirSpecial.h: Added.
(JSC::B3::Air::DeepSpecialDump::DeepSpecialDump):
(JSC::B3::Air::DeepSpecialDump::dump):
(JSC::B3::Air::deepDump):
* b3/air/AirSpillEverything.cpp: Added.
(JSC::B3::Air::spillEverything):
* b3/air/AirSpillEverything.h: Added.
* b3/air/AirStackSlot.cpp: Added.
(JSC::B3::Air::StackSlot::setOffsetFromFP):
(JSC::B3::Air::StackSlot::dump):
(JSC::B3::Air::StackSlot::deepDump):
(JSC::B3::Air::StackSlot::StackSlot):
* b3/air/AirStackSlot.h: Added.
(JSC::B3::Air::StackSlot::byteSize):
(JSC::B3::Air::StackSlot::kind):
(JSC::B3::Air::StackSlot::index):
(JSC::B3::Air::StackSlot::alignment):
(JSC::B3::Air::StackSlot::value):
(JSC::B3::Air::StackSlot::offsetFromFP):
(JSC::B3::Air::DeepStackSlotDump::DeepStackSlotDump):
(JSC::B3::Air::DeepStackSlotDump::dump):
(JSC::B3::Air::deepDump):
* b3/air/AirTmp.cpp: Added.
(JSC::B3::Air::Tmp::dump):
* b3/air/AirTmp.h: Added.
(JSC::B3::Air::Tmp::Tmp):
(JSC::B3::Air::Tmp::gpTmpForIndex):
(JSC::B3::Air::Tmp::fpTmpForIndex):
(JSC::B3::Air::Tmp::operator bool):
(JSC::B3::Air::Tmp::isGP):
(JSC::B3::Air::Tmp::isFP):
(JSC::B3::Air::Tmp::isGPR):
(JSC::B3::Air::Tmp::isFPR):
(JSC::B3::Air::Tmp::isReg):
(JSC::B3::Air::Tmp::gpr):
(JSC::B3::Air::Tmp::fpr):
(JSC::B3::Air::Tmp::reg):
(JSC::B3::Air::Tmp::hasTmpIndex):
(JSC::B3::Air::Tmp::gpTmpIndex):
(JSC::B3::Air::Tmp::fpTmpIndex):
(JSC::B3::Air::Tmp::tmpIndex):
(JSC::B3::Air::Tmp::isAlive):
(JSC::B3::Air::Tmp::operator==):
(JSC::B3::Air::Tmp::operator!=):
(JSC::B3::Air::Tmp::isHashTableDeletedValue):
(JSC::B3::Air::Tmp::hash):
(JSC::B3::Air::Tmp::encodeGP):
(JSC::B3::Air::Tmp::encodeFP):
(JSC::B3::Air::Tmp::encodeGPR):
(JSC::B3::Air::Tmp::encodeFPR):
(JSC::B3::Air::Tmp::encodeGPTmp):
(JSC::B3::Air::Tmp::encodeFPTmp):
(JSC::B3::Air::Tmp::isEncodedGP):
(JSC::B3::Air::Tmp::isEncodedFP):
(JSC::B3::Air::Tmp::isEncodedGPR):
(JSC::B3::Air::Tmp::isEncodedFPR):
(JSC::B3::Air::Tmp::isEncodedGPTmp):
(JSC::B3::Air::Tmp::isEncodedFPTmp):
(JSC::B3::Air::Tmp::decodeGPR):
(JSC::B3::Air::Tmp::decodeFPR):
(JSC::B3::Air::Tmp::decodeGPTmp):
(JSC::B3::Air::Tmp::decodeFPTmp):
(JSC::B3::Air::TmpHash::hash):
(JSC::B3::Air::TmpHash::equal):
* b3/air/AirTmpInlines.h: Added.
(JSC::B3::Air::Tmp::Tmp):
* b3/air/AirValidate.cpp: Added.
(JSC::B3::Air::validate):
* b3/air/AirValidate.h: Added.
* b3/air/opcode_generator.rb: Added.
* b3/generate_pattern_matcher.rb: Added.
* b3/testb3.cpp: Added.
(JSC::B3::compileAndRun):
(JSC::B3::test42):
(JSC::B3::testLoad42):
(JSC::B3::testArg):
(JSC::B3::testAddArgs):
(JSC::B3::testAddArgs32):
(JSC::B3::testStore):
(JSC::B3::testTrunc):
(JSC::B3::testAdd1):
(JSC::B3::testStoreAddLoad):
(JSC::B3::testStoreAddAndLoad):
(JSC::B3::testAdd1Uncommuted):
(JSC::B3::testLoadOffset):
(JSC::B3::testLoadOffsetNotConstant):
(JSC::B3::testLoadOffsetUsingAdd):
(JSC::B3::testLoadOffsetUsingAddNotConstant):
(JSC::B3::run):
(run):
(main):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::specializationKind):
* jit/Reg.h:
(JSC::Reg::index):
(JSC::Reg::isSet):
(JSC::Reg::operator bool):
(JSC::Reg::isHashTableDeletedValue):
(JSC::Reg::AllRegsIterable::iterator::iterator):
(JSC::Reg::AllRegsIterable::iterator::operator*):
(JSC::Reg::AllRegsIterable::iterator::operator++):
(JSC::Reg::AllRegsIterable::iterator::operator==):
(JSC::Reg::AllRegsIterable::iterator::operator!=):
(JSC::Reg::AllRegsIterable::begin):
(JSC::Reg::AllRegsIterable::end):
(JSC::Reg::all):
(JSC::Reg::invalid):
(JSC::Reg::operator!): Deleted.
* jit/RegisterAtOffsetList.cpp:
(JSC::RegisterAtOffsetList::RegisterAtOffsetList):
* jit/RegisterAtOffsetList.h:
(JSC::RegisterAtOffsetList::clear):
(JSC::RegisterAtOffsetList::size):
(JSC::RegisterAtOffsetList::begin):
(JSC::RegisterAtOffsetList::end):
* jit/RegisterSet.h:
(JSC::RegisterSet::operator==):
(JSC::RegisterSet::hash):
(JSC::RegisterSet::forEach):
(JSC::RegisterSet::setAny):
2015-10-28 Mark Lam <mark.lam@apple.com>
Rename MacroAssembler::callProbe() to probe().
https://bugs.webkit.org/show_bug.cgi?id=150641
Reviewed by Saam Barati.
To do this, I needed to disambiguate between the low-level probe() from the
high-level version that takes a std::function. I did this by changing the low-
level version to not take default args anymore.
* assembler/AbstractMacroAssembler.h:
* assembler/MacroAssembler.cpp:
(JSC::stdFunctionCallback):
(JSC::MacroAssembler::probe):
(JSC::MacroAssembler::callProbe): Deleted.
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::urshift32):
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::repatchCall):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::repatchCall):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::repatchCall):
* assembler/MacroAssemblerPrinter.h:
(JSC::MacroAssemblerPrinter::print):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::maxJumpReplacementSize):
2015-10-28 Timothy Hatcher <timothy@apple.com>
Web Inspector: jsmin.py mistakenly removes whitespace from template literal strings
https://bugs.webkit.org/show_bug.cgi?id=148728
Reviewed by Joseph Pecoraro.
* Scripts/jsmin.py:
(JavascriptMinify.minify): Make backtick a quoting character.
2015-10-28 Brian Burg <bburg@apple.com>
Builtins generator should emit ENABLE(FEATURE) guards based on @conditional annotation
https://bugs.webkit.org/show_bug.cgi?id=150536
Reviewed by Yusuke Suzuki.
Scan JS builtin files for @key=value and @flag annotations in single-line comments.
For @conditional=CONDITIONAL, emit CONDITIONAL guards around the relevant object's code.
Generate primary header includes separately from secondary header includes so we can
put the guard between the two header groups, as is customary in WebKit C++ code.
New tests:
Scripts/tests/builtins/WebCore-ArbitraryConditionalGuard-Separate.js
Scripts/tests/builtins/WebCore-DuplicateFlagAnnotation-Separate.js
Scripts/tests/builtins/WebCore-DuplicateKeyValueAnnotation-Separate.js
* Scripts/builtins/builtins_generate_combined_implementation.py:
(BuiltinsCombinedImplementationGenerator.generate_output):
(BuiltinsCombinedImplementationGenerator.generate_secondary_header_includes):
(BuiltinsCombinedImplementationGenerator.generate_header_includes): Deleted.
* Scripts/builtins/builtins_generate_separate_header.py:
(BuiltinsSeparateHeaderGenerator.generate_output):
(generate_secondary_header_includes):
(generate_header_includes): Deleted.
* Scripts/builtins/builtins_generate_separate_implementation.py:
(BuiltinsSeparateImplementationGenerator.generate_output):
(BuiltinsSeparateImplementationGenerator.generate_secondary_header_includes):
(BuiltinsSeparateImplementationGenerator.generate_header_includes): Deleted.
* Scripts/builtins/builtins_generate_separate_wrapper.py:
(BuiltinsSeparateWrapperGenerator.generate_output):
(BuiltinsSeparateWrapperGenerator.generate_secondary_header_includes):
(BuiltinsSeparateWrapperGenerator.generate_header_includes): Deleted.
* Scripts/builtins/builtins_generator.py:
(BuiltinsGenerator.generate_includes_from_entries):
(BuiltinsGenerator):
(BuiltinsGenerator.generate_primary_header_includes):
* Scripts/builtins/builtins_model.py:
(BuiltinObject.__init__):
(BuiltinsCollection.parse_builtins_file):
(BuiltinsCollection._parse_annotations):
* Scripts/tests/builtins/WebCore-ArbitraryConditionalGuard-Separate.js: Added.
* Scripts/tests/builtins/WebCore-DuplicateFlagAnnotation-Separate.js: Added.
* Scripts/tests/builtins/WebCore-DuplicateKeyValueAnnotation-Separate.js: Added.
* Scripts/tests/builtins/WebCore-GuardedBuiltin-Separate.js: Simplify.
* Scripts/tests/builtins/WebCore-GuardedInternalBuiltin-Separate.js: Simplify.
* Scripts/tests/builtins/WebCore-UnguardedBuiltin-Separate.js: Simplify.
* Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result: Added.
* Scripts/tests/builtins/expected/WebCore-DuplicateFlagAnnotation-Separate.js-error: Added.
* Scripts/tests/builtins/expected/WebCore-DuplicateKeyValueAnnotation-Separate.js-error: Added.
* Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
2015-10-28 Mark Lam <mark.lam@apple.com>
Update FTL to support UntypedUse operands for op_sub.
https://bugs.webkit.org/show_bug.cgi?id=150562
Reviewed by Geoffrey Garen.
* assembler/MacroAssemblerARM64.h:
- make the dataTempRegister and memoryTempRegister public so that we can
move input registers out of them if needed.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
- We can now compile ArithSub.
* ftl/FTLCompile.cpp:
- Added BinaryArithGenerationContext to shuffle registers into a state that is
expected by the baseline snippet generator. This includes:
1. Making sure that the input and output registers are not in the tag or
scratch registers.
2. Loading the tag registers with expected values.
3. Restoring the registers to their original value on return.
- Added code to implement the ArithSub inline cache.
* ftl/FTLInlineCacheDescriptor.h:
(JSC::FTL::ArithSubDescriptor::ArithSubDescriptor):
(JSC::FTL::ArithSubDescriptor::leftType):
(JSC::FTL::ArithSubDescriptor::rightType):
* ftl/FTLInlineCacheSize.cpp:
(JSC::FTL::sizeOfArithSub):
* ftl/FTLInlineCacheSize.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
- Added handling for UnusedType for the ArithSub case.
* ftl/FTLState.h:
* jit/GPRInfo.h:
(JSC::GPRInfo::reservedRegisters):
* jit/JITSubGenerator.h:
(JSC::JITSubGenerator::generateFastPath):
- When the result is in the same as one of the input registers, we'll end up
corrupting the input in fast path even if we determine that we need to go to
the slow path. We now move the input into the scratch register and operate
on that instead and only move the result into the result register only after
the fast path has succeeded.
* tests/stress/op_sub.js:
(o1.valueOf):
(runTest):
- Added some debugging tools: flags for verbose logging, and eager abort on fail.
2015-10-28 Mark Lam <mark.lam@apple.com>
Fix a typo in ProbeContext::fpr().
https://bugs.webkit.org/show_bug.cgi?id=150629
Reviewed by Yusuke Suzuki.
ProbeContext::fpr() should be calling CPUState::fpr(), not CPUState::gpr().
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::ProbeContext::fpr):
2015-10-28 Mark Lam <mark.lam@apple.com>
Add ability to print the PC register from JIT'ed code.
https://bugs.webkit.org/show_bug.cgi?id=150561
Reviewed by Geoffrey Garen.
* assembler/MacroAssemblerPrinter.cpp:
(JSC::printPC):
(JSC::MacroAssemblerPrinter::printCallback):
* assembler/MacroAssemblerPrinter.h:
(JSC::MacroAssemblerPrinter::PrintArg::PrintArg):
2015-10-27 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Remove Timeline MarkDOMContent and MarkLoad, data is already available
https://bugs.webkit.org/show_bug.cgi?id=150615
Reviewed by Timothy Hatcher.
* inspector/protocol/Timeline.json:
2015-10-27 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Remove unused / duplicated XHR timeline instrumentation
https://bugs.webkit.org/show_bug.cgi?id=150605
Reviewed by Timothy Hatcher.
* inspector/protocol/Timeline.json:
2015-10-27 Michael Saboff <msaboff@apple.com>
REGRESSION (r191360): Crash: com.apple.WebKit.WebContent at com.apple.JavaScriptCore: JSC::FTL:: + 386
https://bugs.webkit.org/show_bug.cgi?id=150580
Reviewed by Mark Lam.
Changed code to box 32 bit integers and booleans arguments when generating the call instead of boxing
them in the shuffler.
The ASSERT in CallFrameShuffler::extendFrameIfNeeded is wrong when called from CallFrameShuffler::spill(),
as we could be making space to spill a register so that we have a spare that we can use for the new
frame's base pointer.
* ftl/FTLJSTailCall.cpp:
(JSC::FTL::DFG::recoveryFor): Added RELEASE_ASSERT to check that we never see unboxed 32 bit
arguments stored in the stack.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::exitValueForTailCall):
* jit/CallFrameShuffler.cpp:
(JSC::CallFrameShuffler::extendFrameIfNeeded): Removed unneeded ASSERT.
2015-10-26 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Add DFG/FTL support for accessor put operations
https://bugs.webkit.org/show_bug.cgi?id=148860
Reviewed by Geoffrey Garen.
This patch introduces accessor defining ops into DFG and FTL.
The following DFG nodes are introduced.
op_put_getter_by_id => PutGetterById
op_put_setter_by_id => PutSetterById
op_put_getter_setter => PutGetterSetterById
op_put_getter_by_val => PutGetterByVal
op_put_setter_by_val => PutSetterByVal
These DFG nodes just call operations. But it does not prevent compiling in DFG/FTL.
To use operations defined for baseline JIT, we clean up existing operations.
And reuse these operations in DFG and FTL.
* 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):
(JSC::DFG::Node::hasAccessorAttributes):
(JSC::DFG::Node::accessorAttributes):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePutAccessorById):
(JSC::DFG::SpeculativeJIT::compilePutGetterSetterById):
(JSC::DFG::SpeculativeJIT::compilePutAccessorByVal):
We should fill all GPRs before calling flushRegisters().
* 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/FTLIntrinsicRepository.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutAccessorById):
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutGetterSetterById):
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutAccessorByVal):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_put_getter_by_id):
(JSC::JIT::emit_op_put_setter_by_id):
(JSC::JIT::emit_op_put_getter_setter):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_put_getter_by_id):
(JSC::JIT::emit_op_put_setter_by_id):
(JSC::JIT::emit_op_put_getter_setter):
* tests/stress/dfg-put-accessors-by-id-class.js: Added.
(shouldBe):
(testAttribute):
(getter.Cocoa.prototype.get hello):
(getter.Cocoa):
(getter):
(setter.Cocoa):
(setter.Cocoa.prototype.set hello):
(setter):
(accessors.Cocoa):
(accessors.Cocoa.prototype.get hello):
(accessors.Cocoa.prototype.set hello):
(accessors):
* tests/stress/dfg-put-accessors-by-id.js: Added.
(shouldBe):
(testAttribute):
(getter.object.get hello):
(getter):
(setter.object.set hello):
(setter):
(accessors.object.get hello):
(accessors.object.set hello):
(accessors):
* tests/stress/dfg-put-getter-by-id-class.js: Added.
(shouldBe):
(testAttribute):
(getter.Cocoa):
(getter.Cocoa.prototype.get hello):
(getter.Cocoa.prototype.get name):
(getter):
* tests/stress/dfg-put-getter-by-id.js: Added.
(shouldBe):
(testAttribute):
(getter.object.get hello):
(getter):
* tests/stress/dfg-put-getter-by-val-class.js: Added.
(shouldBe):
(testAttribute):
(getter.Cocoa):
(getter.Cocoa.prototype.get name):
(getter):
* tests/stress/dfg-put-getter-by-val.js: Added.
(shouldBe):
(testAttribute):
(getter.object.get name):
(getter):
* tests/stress/dfg-put-setter-by-id-class.js: Added.
(shouldBe):
(testAttribute):
(getter.Cocoa):
(getter.Cocoa.prototype.set hello):
(getter.Cocoa.prototype.get name):
(getter):
* tests/stress/dfg-put-setter-by-id.js: Added.
(shouldBe):
(testAttribute):
(setter.object.set hello):
(setter):
* tests/stress/dfg-put-setter-by-val-class.js: Added.
(shouldBe):
(testAttribute):
(setter.Cocoa):
(setter.Cocoa.prototype.set name):
(setter):
* tests/stress/dfg-put-setter-by-val.js: Added.
(shouldBe):
(testAttribute):
(setter.object.set name):
(setter):
2015-10-26 Mark Lam <mark.lam@apple.com>
Add logging to warn about under-estimated FTL inline cache sizes.
https://bugs.webkit.org/show_bug.cgi?id=150570
Reviewed by Geoffrey Garen.
Added 2 options:
1. JSC_dumpFailedICSizing - dumps an error message if the FTL encounters IC size
estimates that are less than the actual needed code size.
This option is useful for when we add a new IC and want to compute an
estimated size for the IC. To do this:
1. Build jsc for the target port with a very small IC size (enough to
store the jump instruction needed for the out of line fallback
implementation).
2. Implement a test suite with scenarios that exercise all the code paths in
the IC generator.
3. Run jsc with JSC_dumpFailedICSizing=true on the test suite.
4. The max value reported by the dumps will be the worst case size needed to
store the IC. We should use this value for our estimate.
5. Update the IC's estimated size and rebuild jsc.
6. Re-run (3) and confirm that there are no more error messages about the
IC sizing.
2. JSC_assertICSizing - same as JSC_dumpFailedICSizing except that it also
crashes the VM each time it encounters an inadequate IC size estimate.
This option is useful for regression testing to ensure that our estimates
do not regress.
* ftl/FTLCompile.cpp:
(JSC::FTL::generateInlineIfPossibleOutOfLineIfNot):
* runtime/Options.h:
2015-10-26 Saam barati <sbarati@apple.com>
r190735 Caused us to maybe trample the base's tag-GPR on 32-bit inline cache when the cache allocates a scratch register and then jumps to the slow path
https://bugs.webkit.org/show_bug.cgi?id=150532
Reviewed by Geoffrey Garen.
The base's tag register used to show up in the used register set
before r190735 because of how the DFG kept track of used register. I changed this
in my work on inline caching because we don't want to spill these registers
when we have a GetByIdFlush/PutByIdFlush and we use the used register set
as the metric of what to spill. That said, these registers should be locked
and not used as scratch registers by the scratch register allocator. The
reason is that our inline cache may fail and jump to the slow path. The slow
path then uses the base's tag register. If the inline cache used the base's tag
register as a scratch and the inline cache fails and jumps to the slow path, we
have a problem because the tag may now be trampled.
Note that this doesn't mean that we can't trample the base's tag register when making
a call. We can totally trample the register as long as the inline cache succeeds in a GetByIdFlush/PutByIdFlush.
The problem is only when we trample it and then jump to the slow path.
This patch fixes this bug by making StructureStubInfo keep track of the base's
tag GPR. PolymorphicAccess then locks this register when using the ScratchRegisterAllocator.
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generate):
(JSC::PolymorphicAccess::regenerate):
* bytecode/StructureStubInfo.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileIn):
* jit/JITInlineCacheGenerator.cpp:
(JSC::JITByIdGenerator::JITByIdGenerator):
* tests/stress/regress-150532.js: Added.
(assert):
(randomFunction):
(foo):
(i.switch):
2015-10-24 Brian Burg <bburg@apple.com>
Teach create_hash_table to omit builtins macros when generating tables for native-only objects
https://bugs.webkit.org/show_bug.cgi?id=150491
Reviewed by Yusuke Suzuki.
In order to support separate compilation for generated builtins files, we need to be able to
include specific builtins headers from generated .lut.h files. However, the create_hash_table
script isn't smart enough to figure out when a generated file might actually contain a builtin.
Without further help, we'd have to include an all-in-one header, mostly defeating the point of
generating separate .h and .cpp files for every builtin.
This patch segregates the pure native and partially builtin sources in the build system, and
gives hints to create_hash_table so that it doesn't even generate checks for builtins if the
input file has no builtin method implementations. Also do some modernization and code cleanup.
* CMakeLists.txt:
Generate each group with different flags to create_hash_table. Change the macro to take
flags through the variable LUT_GENERATOR_FLAGS. Set this as necessary before calling macro.
Add an additional hint to CMake that the .cpp source file depends on the generated file.
* DerivedSources.make:
Generate each group with different flags to create_hash_table. Clean up the 'all' target
so that static dependencies are listed first. Use static patterns to decide which .lut.h
files require which flags. Reduce fragile usages of implicit variables.
* JavaScriptCore.xcodeproj/project.pbxproj:
Add some missing .lut.h files to the Derived Sources group. Sort the project.
* create_hash_table:
Parse options in a sane way using GetOpt::Long. Remove ability to specify a custom namespace
since this isn't actually used anywhere. Normalize placement of newlines in quoted strings.
Only generate builtins macros and includes if the source file is known to have some builtins.
2015-10-23 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Remove unused ScrollLayer Timeline EventType
https://bugs.webkit.org/show_bug.cgi?id=150518
Reviewed by Timothy Hatcher.
* inspector/protocol/Timeline.json:
2015-10-23 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Clean up InspectorInstrumentation includes
https://bugs.webkit.org/show_bug.cgi?id=150523
Reviewed by Timothy Hatcher.
* inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::consoleMessageArgumentCounts): Deleted.
* inspector/agents/InspectorConsoleAgent.h:
2015-10-23 Michael Saboff <msaboff@apple.com>
REGRESSION (r179357-r179359): WebContent Crash using AOL Mail @ com.apple.JavascriptCore JSC::linkPolymorphicCall(JSC::ExecState*, JSC::CallLinkInfo&, JSC::CallVariant, JSC::RegisterPreservationMode) + 1584
https://bugs.webkit.org/show_bug.cgi?id=150513
Reviewed by Saam Barati.
Add check in linkPolymorphicCall() to make sure we have a CodeBlock for the newly added variant.
If not, we turn the call into a virtual call.
The bug was caused by a stack overflow when preparing the function for execution. This properly
threw an exception, however linkPolymorphicCall() didn't check for this error case.
Added a new test function "failNextNewCodeBlock()" to test tools to simplify the testing.
* API/JSCTestRunnerUtils.cpp:
(JSC::failNextNewCodeBlock):
(JSC::numberOfDFGCompiles):
* API/JSCTestRunnerUtils.h:
* jit/Repatch.cpp:
(JSC::linkPolymorphicCall):
* jsc.cpp:
(GlobalObject::finishCreation):
(functionTransferArrayBuffer):
(functionFailNextNewCodeBlock):
(functionQuit):
* runtime/Executable.cpp:
(JSC::ScriptExecutable::prepareForExecutionImpl):
* runtime/TestRunnerUtils.cpp:
(JSC::optimizeNextInvocation):
(JSC::failNextNewCodeBlock):
(JSC::numberOfDFGCompiles):
* runtime/TestRunnerUtils.h:
* runtime/VM.h:
(JSC::VM::setFailNextNewCodeBlock):
(JSC::VM::getAndClearFailNextNewCodeBlock):
(JSC::VM::stackPointerAtVMEntry):
2015-10-23 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r191500.
https://bugs.webkit.org/show_bug.cgi?id=150526
Broke two JSC regression tests (Requested by msaboff on
#webkit).
Reverted changeset:
"[ES6] Add DFG/FTL support for accessor put operations"
https://bugs.webkit.org/show_bug.cgi?id=148860
http://trac.webkit.org/changeset/191500
2015-10-23 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Add DFG/FTL support for accessor put operations
https://bugs.webkit.org/show_bug.cgi?id=148860
Reviewed by Geoffrey Garen.
This patch introduces accessor defining ops into DFG and FTL.
The following DFG nodes are introduced.
op_put_getter_by_id => PutGetterById
op_put_setter_by_id => PutSetterById
op_put_getter_setter => PutGetterSetterById
op_put_getter_by_val => PutGetterByVal
op_put_setter_by_val => PutSetterByVal
These DFG nodes just call operations. But it does not prevent compiling in DFG/FTL.
To use operations defined for baseline JIT, we clean up existing operations.
And reuse these operations in DFG and FTL.
* 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):
(JSC::DFG::Node::hasAccessorAttributes):
(JSC::DFG::Node::accessorAttributes):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePutAccessorById):
(JSC::DFG::SpeculativeJIT::compilePutGetterSetterById):
(JSC::DFG::SpeculativeJIT::compilePutAccessorByVal):
* 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/FTLIntrinsicRepository.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutAccessorById):
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutGetterSetterById):
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutAccessorByVal):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_put_getter_by_id):
(JSC::JIT::emit_op_put_setter_by_id):
(JSC::JIT::emit_op_put_getter_setter):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_put_getter_by_id):
(JSC::JIT::emit_op_put_setter_by_id):
(JSC::JIT::emit_op_put_getter_setter):
* tests/stress/dfg-put-accessors-by-id-class.js: Added.
(shouldBe):
(testAttribute):
(getter.Cocoa.prototype.get hello):
(getter.Cocoa):
(getter):
(setter.Cocoa):
(setter.Cocoa.prototype.set hello):
(setter):
(accessors.Cocoa):
(accessors.Cocoa.prototype.get hello):
(accessors.Cocoa.prototype.set hello):
(accessors):
* tests/stress/dfg-put-accessors-by-id.js: Added.
(shouldBe):
(testAttribute):
(getter.object.get hello):
(getter):
(setter.object.set hello):
(setter):
(accessors.object.get hello):
(accessors.object.set hello):
(accessors):
* tests/stress/dfg-put-getter-by-id-class.js: Added.
(shouldBe):
(testAttribute):
(getter.Cocoa):
(getter.Cocoa.prototype.get hello):
(getter.Cocoa.prototype.get name):
(getter):
* tests/stress/dfg-put-getter-by-id.js: Added.
(shouldBe):
(testAttribute):
(getter.object.get hello):
(getter):
* tests/stress/dfg-put-getter-by-val-class.js: Added.
(shouldBe):
(testAttribute):
(getter.Cocoa):
(getter.Cocoa.prototype.get name):
(getter):
* tests/stress/dfg-put-getter-by-val.js: Added.
(shouldBe):
(testAttribute):
(getter.object.get name):
(getter):
* tests/stress/dfg-put-setter-by-id-class.js: Added.
(shouldBe):
(testAttribute):
(getter.Cocoa):
(getter.Cocoa.prototype.set hello):
(getter.Cocoa.prototype.get name):
(getter):
* tests/stress/dfg-put-setter-by-id.js: Added.
(shouldBe):
(testAttribute):
(setter.object.set hello):
(setter):
* tests/stress/dfg-put-setter-by-val-class.js: Added.
(shouldBe):
(testAttribute):
(setter.Cocoa):
(setter.Cocoa.prototype.set name):
(setter):
* tests/stress/dfg-put-setter-by-val.js: Added.
(shouldBe):
(testAttribute):
(setter.object.set name):
(setter):
2015-10-22 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Remove unused Timeline GCEvent Record type
https://bugs.webkit.org/show_bug.cgi?id=150477
Reviewed by Timothy Hatcher.
Garbage Collection events go through the Heap domain, not the
Timeline domain (long time ago for Chromium).
* inspector/protocol/Timeline.json:
2015-10-22 Michael Saboff <msaboff@apple.com>
REGRESSION(r191360): Repro Crash: com.apple.WebKit.WebContent at JavaScriptCore:JSC::ExecState::bytecodeOffset + 174
https://bugs.webkit.org/show_bug.cgi?id=150434
Reviewed by Mark Lam.
Pass the current frame instead of the caller frame to operationVMHandleException when processing an
exception in one of the native thunks.
* jit/JITExceptions.cpp:
(JSC::genericUnwind): Made debug printing of CodeBlock safe for call frames without one.
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::privateCompileCTINativeCall):
* jit/ThunkGenerators.cpp:
(JSC::nativeForGenerator):
2015-10-21 Brian Burg <bburg@apple.com>
Restructure generate-js-bindings script to be modular and testable
https://bugs.webkit.org/show_bug.cgi?id=149929
Reviewed by Alex Christensen.
This is a new code generator, based on the replay inputs code generator and
the inspector protocol code generator, which produces various files for JS
builtins.
Relative to the generator it replaces, this one consolidates two scripts in
JavaScriptCore and WebCore into a single script with multiple files. Parsed
information about the builtins file is stored in backend-independent model
objects. Each output file has its own code generator that uses the model to
produce resulting code. Generators are additionally parameterized by the target
framework (to choose correct macros and includes) and output mode (one
header/implementation file per builtin or per framework).
It includes a few simple tests of the generator's functionality. These result-
based tests will become increasingly more important as we start to add support
for builtins annotation such as @optional, @internal, etc. to the code generator.
Some of these complexities, such as having two output modes, will be removed in
subsequent patches. This patch is intended to exactly replace the existing
functionality with a unified script that makes additional cleanups straightforward.
Additional cleanup and consolidation between inspector code generator scripts
and this script will be pursued in followup patches.
New tests:
Scripts/tests/builtins/JavaScriptCore-Builtin.Promise-Combined.js
Scripts/tests/builtins/JavaScriptCore-Builtin.Promise-Separate.js
Scripts/tests/builtins/JavaScriptCore-Builtin.prototype-Combined.js
Scripts/tests/builtins/JavaScriptCore-Builtin.prototype-Separate.js
Scripts/tests/builtins/JavaScriptCore-BuiltinConstructor-Combined.js
Scripts/tests/builtins/JavaScriptCore-BuiltinConstructor-Separate.js
Scripts/tests/builtins/WebCore-GuardedBuiltin-Separate.js
Scripts/tests/builtins/WebCore-GuardedInternalBuiltin-Separate.js
Scripts/tests/builtins/WebCore-UnguardedBuiltin-Separate.js
Scripts/tests/builtins/WebCore-xmlCasingTest-Separate.js
* CMakeLists.txt:
Copy the scripts that are used by other targets to a staging directory inside
${DERIVED_SOURCES_DIR}/ForwardingHeaders/JavaScriptCore/Scripts.
Define JavaScriptCore_SCRIPTS_DIR to point here so that the add_custom_command
and shared file lists are identical between JavaScriptCore and WebCore. The staged
scripts are a dependency of the main JavaScriptCore target so that they are
always staged, even if JavaScriptCore itself does not use a particular script.
The output files additionally depend on all builtin generator script files
and input files that are combined into the single header/implementation file.
* DerivedSources.make:
Define JavaScriptCore_SCRIPTS_DIR explicitly so the rule for code generation and
shared file lists are identical between JavaScriptCore and WebCore.
The output files additionally depend on all builtin generator script files
and input files that are combined into the single header/implementation file.
* JavaScriptCore.xcodeproj/project.pbxproj:
Mark the new builtins generator files as private headers so we can use them from
WebCore.
* Scripts/UpdateContents.py: Renamed from Source/JavaScriptCore/UpdateContents.py.
* Scripts/builtins/__init__.py: Added.
* Scripts/builtins/builtins.py: Added.
* Scripts/builtins/builtins_generator.py: Added. This file contains the base generator.
(WK_lcfirst):
(WK_ucfirst):
(BuiltinsGenerator):
(BuiltinsGenerator.__init__):
(BuiltinsGenerator.model):
(BuiltinsGenerator.generate_license):
(BuiltinsGenerator.generate_includes_from_entries):
(BuiltinsGenerator.generate_output):
(BuiltinsGenerator.output_filename):
(BuiltinsGenerator.mangledNameForFunction):
(BuiltinsGenerator.mangledNameForFunction.toCamel):
(BuiltinsGenerator.generate_embedded_code_string_section_for_function):
* Scripts/builtins/builtins_model.py: Added. This file contains builtins model objects.
(ParseException):
(Framework):
(Framework.__init__):
(Framework.setting):
(Framework.fromString):
(Frameworks):
(BuiltinObject):
(BuiltinObject.__init__):
(BuiltinFunction):
(BuiltinFunction.__init__):
(BuiltinFunction.fromString):
(BuiltinFunction.__str__):
(BuiltinsCollection):
(BuiltinsCollection.__init__):
(BuiltinsCollection.parse_builtins_file):
(BuiltinsCollection.copyrights):
(BuiltinsCollection.all_functions):
(BuiltinsCollection._parse_copyright_lines):
(BuiltinsCollection._parse_functions):
* Scripts/builtins/builtins_templates.py: Added.
(BuiltinsGeneratorTemplates):
* Scripts/builtins/builtins_generate_combined_header.py: Added.
(BuiltinsCombinedHeaderGenerator):
(BuiltinsCombinedHeaderGenerator.__init__):
(BuiltinsCombinedHeaderGenerator.output_filename):
(BuiltinsCombinedHeaderGenerator.generate_output):
(BuiltinsCombinedHeaderGenerator.generate_forward_declarations):
(FunctionExecutable):
(VM):
(ConstructAbility):
(generate_section_for_object):
(generate_externs_for_object):
(generate_macros_for_object):
(generate_defines_for_object):
(generate_section_for_code_table_macro):
(generate_section_for_code_name_macro):
* Scripts/builtins/builtins_generate_combined_implementation.py: Added.
(BuiltinsCombinedImplementationGenerator):
(BuiltinsCombinedImplementationGenerator.__init__):
(BuiltinsCombinedImplementationGenerator.output_filename):
(BuiltinsCombinedImplementationGenerator.generate_output):
(BuiltinsCombinedImplementationGenerator.generate_header_includes):
* Scripts/builtins/builtins_generate_separate_header.py: Added.
(BuiltinsSeparateHeaderGenerator):
(BuiltinsSeparateHeaderGenerator.__init__):
(BuiltinsSeparateHeaderGenerator.output_filename):
(BuiltinsSeparateHeaderGenerator.macro_prefix):
(BuiltinsSeparateHeaderGenerator.generate_output):
(BuiltinsSeparateHeaderGenerator.generate_forward_declarations):
(FunctionExecutable):
(generate_header_includes):
(generate_section_for_object):
(generate_externs_for_object):
(generate_macros_for_object):
(generate_defines_for_object):
(generate_section_for_code_table_macro):
(generate_section_for_code_name_macro):
* Scripts/builtins/builtins_generate_separate_implementation.py: Added.
(BuiltinsSeparateImplementationGenerator):
(BuiltinsSeparateImplementationGenerator.__init__):
(BuiltinsSeparateImplementationGenerator.output_filename):
(BuiltinsSeparateImplementationGenerator.macro_prefix):
(BuiltinsSeparateImplementationGenerator.generate_output):
(BuiltinsSeparateImplementationGenerator.generate_header_includes):
* Scripts/builtins/builtins_generate_separate_wrapper.py: Added.
(BuiltinsSeparateWrapperGenerator):
(BuiltinsSeparateWrapperGenerator.__init__):
(BuiltinsSeparateWrapperGenerator.output_filename):
(BuiltinsSeparateWrapperGenerator.macro_prefix):
(BuiltinsSeparateWrapperGenerator.generate_output):
(BuiltinsSeparateWrapperGenerator.generate_header_includes):
* Scripts/generate-js-builtins.py: Added.
Parse command line options, decide which generators and output modes to use.
(generate_bindings_for_builtins_files):
* Scripts/lazywriter.py: Copied from the inspector protocol generator.
(LazyFileWriter):
(LazyFileWriter.__init__):
(LazyFileWriter.write):
(LazyFileWriter.close):
* Scripts/tests/builtins/JavaScriptCore-Builtin.Promise-Combined.js: Added.
* Scripts/tests/builtins/JavaScriptCore-Builtin.Promise-Separate.js: Added.
* Scripts/tests/builtins/JavaScriptCore-Builtin.prototype-Combined.js: Added.
* Scripts/tests/builtins/JavaScriptCore-Builtin.prototype-Separate.js: Added.
* Scripts/tests/builtins/JavaScriptCore-BuiltinConstructor-Combined.js: Added.
* Scripts/tests/builtins/JavaScriptCore-BuiltinConstructor-Separate.js: Added.
* Scripts/tests/builtins/WebCore-GuardedBuiltin-Separate.js: Added.
* Scripts/tests/builtins/WebCore-GuardedInternalBuiltin-Separate.js: Added.
* Scripts/tests/builtins/WebCore-UnguardedBuiltin-Separate.js: Added.
* Scripts/tests/builtins/WebCore-xmlCasingTest-Separate.js: Added.
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result: Added.
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result: Added.
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result: Added.
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result: Added.
* Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result: Added.
* Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result: Added.
* Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result: Added.
* Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result: Added.
* Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result: Added.
* Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result: Added.
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::BuiltinExecutables):
* builtins/BuiltinExecutables.h:
* create_hash_table:
Update the generated builtin macro names.
* generate-js-builtins: Removed.
2015-10-21 Benjamin Poulain <bpoulain@apple.com>
[JSC] Remove FTL Native Inlining, it is dead code
https://bugs.webkit.org/show_bug.cgi?id=150429
Reviewed by Filip Pizlo.
The code is not used and it is in the way of other changes.
* ftl/FTLAbbreviations.h:
(JSC::FTL::getFirstInstruction): Deleted.
(JSC::FTL::getNextInstruction): Deleted.
(JSC::FTL::getFirstBasicBlock): Deleted.
(JSC::FTL::getNextBasicBlock): Deleted.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::isInlinableSize): Deleted.
* runtime/Options.h:
2015-10-21 Benjamin Poulain <bpoulain@apple.com>
[JSC] Remove two useless temporaries from the PutByOffset codegen
https://bugs.webkit.org/show_bug.cgi?id=150421
Reviewed by Geoffrey Garen.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile): Deleted.
Looks like they were added by accident in r160796.
2015-10-21 Filip Pizlo <fpizlo@apple.com>
Factor out the graph node worklists from DFG into WTF
https://bugs.webkit.org/show_bug.cgi?id=150411
Reviewed by Geoffrey Garen.
Rewrite the DFGBlockWorklist.h file as a bunch of typedefs and aliases for things in
wtf/GraphNodeWorklist.h. Most users won't notice, except that some small things got
renamed. For example PreOrder becomes VisitOrder::Pre and item.block becomes item.node.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGBlockWorklist.cpp: Removed.
* dfg/DFGBlockWorklist.h:
(JSC::DFG::BlockWorklist::notEmpty): Deleted.
(JSC::DFG::BlockWith::BlockWith): Deleted.
(JSC::DFG::BlockWith::operator bool): Deleted.
(JSC::DFG::ExtendedBlockWorklist::ExtendedBlockWorklist): Deleted.
(JSC::DFG::ExtendedBlockWorklist::forcePush): Deleted.
(JSC::DFG::ExtendedBlockWorklist::push): Deleted.
(JSC::DFG::ExtendedBlockWorklist::notEmpty): Deleted.
(JSC::DFG::ExtendedBlockWorklist::pop): Deleted.
(JSC::DFG::BlockWithOrder::BlockWithOrder): Deleted.
(JSC::DFG::BlockWithOrder::operator bool): Deleted.
(JSC::DFG::PostOrderBlockWorklist::push): Deleted.
(JSC::DFG::PostOrderBlockWorklist::notEmpty): Deleted.
* dfg/DFGDominators.cpp:
(JSC::DFG::Dominators::compute):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::blocksInPostOrder):
* dfg/DFGPrePostNumbering.cpp:
(JSC::DFG::PrePostNumbering::compute):
2015-10-21 Sukolsak Sakshuwong <sukolsak@gmail.com>
[INTL] Implement Intl.Collator.prototype.resolvedOptions ()
https://bugs.webkit.org/show_bug.cgi?id=147601
Reviewed by Benjamin Poulain.
This patch implements Intl.Collator.prototype.resolvedOptions() according
to the ECMAScript 2015 Internationalization API spec (ECMA-402 2nd edition.)
It also implements the abstract operations InitializeCollator, ResolveLocale,
LookupMatcher, and BestFitMatcher.
* runtime/CommonIdentifiers.h:
* runtime/IntlCollator.h:
(JSC::IntlCollator::usage):
(JSC::IntlCollator::setUsage):
(JSC::IntlCollator::locale):
(JSC::IntlCollator::setLocale):
(JSC::IntlCollator::collation):
(JSC::IntlCollator::setCollation):
(JSC::IntlCollator::numeric):
(JSC::IntlCollator::setNumeric):
(JSC::IntlCollator::sensitivity):
(JSC::IntlCollator::setSensitivity):
(JSC::IntlCollator::ignorePunctuation):
(JSC::IntlCollator::setIgnorePunctuation):
* runtime/IntlCollatorConstructor.cpp:
(JSC::sortLocaleData):
(JSC::searchLocaleData):
(JSC::initializeCollator):
(JSC::constructIntlCollator):
(JSC::callIntlCollator):
* runtime/IntlCollatorPrototype.cpp:
(JSC::IntlCollatorPrototypeFuncResolvedOptions):
* runtime/IntlObject.cpp:
(JSC::defaultLocale):
(JSC::getIntlBooleanOption):
(JSC::getIntlStringOption):
(JSC::removeUnicodeLocaleExtension):
(JSC::lookupMatcher):
(JSC::bestFitMatcher):
(JSC::resolveLocale):
(JSC::lookupSupportedLocales):
* runtime/IntlObject.h:
2015-10-21 Saam barati <sbarati@apple.com>
C calls in PolymorphicAccess shouldn't assume that the top of the stack looks like a JSC JIT frame and enable *ByIdFlush in FTL
https://bugs.webkit.org/show_bug.cgi?id=125711
Reviewed by Filip Pizlo.
This patch ensures that anytime we need to make a C call inside
PolymorphicAccess, we ensure there is enough space on the stack to do so.
This patch also enables GetByIdFlush/PutByIdFlush inside the FTL.
Because PolymorphicAccess now spills the necessary registers
before making a JS/C call, any registers that LLVM report as
being in use for the patchpoint will be spilled before making
a call by PolymorphicAccess.
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessGenerationState::restoreScratch):
(JSC::AccessGenerationState::succeed):
(JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
(JSC::AccessCase::generate):
(JSC::PolymorphicAccess::regenerate):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetById):
(JSC::FTL::DFG::LowerDFGToLLVM::emitStoreBarrier):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitTypeOf):
(JSC::AssemblyHelpers::makeSpaceOnStackForCCall):
(JSC::AssemblyHelpers::reclaimSpaceOnStackForCCall):
* jit/RegisterSet.cpp:
(JSC::RegisterSet::webAssemblyCalleeSaveRegisters):
(JSC::RegisterSet::registersToNotSaveForJSCall):
(JSC::RegisterSet::registersToNotSaveForCCall):
(JSC::RegisterSet::allGPRs):
(JSC::RegisterSet::registersToNotSaveForCall): Deleted.
* jit/RegisterSet.h:
(JSC::RegisterSet::set):
* jit/ScratchRegisterAllocator.cpp:
(JSC::ScratchRegisterAllocator::allocateScratchGPR):
(JSC::ScratchRegisterAllocator::allocateScratchFPR):
(JSC::ScratchRegisterAllocator::preserveReusedRegistersByPushing):
(JSC::ScratchRegisterAllocator::restoreReusedRegistersByPopping):
These methods now take an extra parameter indicating if they
should create space for a C call at the top of the stack if
there are any reused registers to spill.
(JSC::ScratchRegisterAllocator::usedRegistersForCall):
* jit/ScratchRegisterAllocator.h:
(JSC::ScratchRegisterAllocator::usedRegisters):
2015-10-21 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Array previews with Symbol objects have too few preview values
https://bugs.webkit.org/show_bug.cgi?id=150404
Reviewed by Timothy Hatcher.
* inspector/InjectedScriptSource.js:
(InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
We should be continuing inside this loop not returning.
2015-10-21 Filip Pizlo <fpizlo@apple.com>
Failures in PutStackSinkingPhase should be less severe
https://bugs.webkit.org/show_bug.cgi?id=150400
Reviewed by Geoffrey Garen.
Make the PutStackSinkingPhase abort instead of asserting. To test that it's OK to not have
PutStackSinkingPhase run, this adds a test mode where we run without PutStackSinkingPhase.
* dfg/DFGPlan.cpp: Make it possible to not run PutStackSinkingPhase for tests.
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGPutStackSinkingPhase.cpp: PutStackSinkingPhase should abort instead of asserting, except when validation is enabled.
* runtime/Options.h: Add an option for disabling PutStackSinkingPhase.
2015-10-21 Saam barati <sbarati@apple.com>
The FTL should place the CallSiteIndex on the call frame for JS calls when it fills in the patchpoint
https://bugs.webkit.org/show_bug.cgi?id=150104
Reviewed by Filip Pizlo.
We lower JS Calls to patchpoints in LLVM. LLVM may decide to duplicate
these patchpoints (or remove them). We eagerly store the CallSiteIndex on the
call frame when lowering DFG to LLVM. But, because the patchpoint we lower to may
be duplicated, we really don't know the unique CallSiteIndex until we've
actually seen the resulting patchpoints after LLVM has completed its transformations.
To solve this, we now store the unique CallSiteIndex on the call frame header
when generating code to fill into the patchpoint.
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLJSCall.cpp:
(JSC::FTL::JSCall::JSCall):
(JSC::FTL::JSCall::emit):
* ftl/FTLJSCall.h:
(JSC::FTL::JSCall::stackmapID):
* ftl/FTLJSCallBase.cpp:
(JSC::FTL::JSCallBase::JSCallBase):
(JSC::FTL::JSCallBase::emit):
(JSC::FTL::JSCallBase::link):
* ftl/FTLJSCallBase.h:
* ftl/FTLJSCallVarargs.cpp:
(JSC::FTL::JSCallVarargs::JSCallVarargs):
(JSC::FTL::JSCallVarargs::numSpillSlotsNeeded):
(JSC::FTL::JSCallVarargs::emit):
* ftl/FTLJSCallVarargs.h:
(JSC::FTL::JSCallVarargs::node):
(JSC::FTL::JSCallVarargs::stackmapID):
* ftl/FTLJSTailCall.cpp:
(JSC::FTL::JSTailCall::JSTailCall):
(JSC::FTL::m_instructionOffset):
(JSC::FTL::JSTailCall::emit):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
(JSC::FTL::DFG::LowerDFGToLLVM::callPreflight):
(JSC::FTL::DFG::LowerDFGToLLVM::codeOriginDescriptionOfCallSite):
(JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
2015-10-21 Geoffrey Garen <ggaren@apple.com>
Date creation should share a little code
https://bugs.webkit.org/show_bug.cgi?id=150399
Reviewed by Filip Pizlo.
I want to fix a bug in this code, but I don't want to fix it in two
different places. (See https://bugs.webkit.org/show_bug.cgi?id=150386.)
* runtime/DateConstructor.cpp:
(JSC::DateConstructor::getOwnPropertySlot):
(JSC::milliseconds): Factored out a shared helper function. If you look
closely, you'll see that one copy of this code previously checked isfinite
while the other checked isnan. isnan returning nan was obviously a no-op,
so I removed it. isfinite, it turns out, is also a no-op -- but less
obviously so, so I kept it for now.
(JSC::constructDate):
(JSC::dateUTC): Use the helper function.
2015-10-21 Guillaume Emont <guijemont@igalia.com>
llint: align stack pointer on mips too
[MIPS] LLInt: align stack pointer on MIPS too
https://bugs.webkit.org/show_bug.cgi?id=150380
Reviewed by Michael Saboff.
* llint/LowLevelInterpreter32_64.asm:
2015-10-20 Mark Lam <mark.lam@apple.com>
YarrPatternConstructor::containsCapturingTerms() should not assume that its terms.size() is greater than 0.
https://bugs.webkit.org/show_bug.cgi?id=150372
Reviewed by Geoffrey Garen.
* yarr/YarrPattern.cpp:
(JSC::Yarr::CharacterClassConstructor::CharacterClassConstructor):
(JSC::Yarr::YarrPatternConstructor::optimizeBOL):
(JSC::Yarr::YarrPatternConstructor::containsCapturingTerms):
(JSC::Yarr::YarrPatternConstructor::optimizeDotStarWrappedExpressions):
2015-10-20 Michael Saboff <msaboff@apple.com>
REGRESSION (r191175): OSR Exit from an inlined tail callee trashes callee save registers
https://bugs.webkit.org/show_bug.cgi?id=150336
Reviewed by Mark Lam.
During OSR exit, we need to restore and transform the active stack into what the baseline
JIT expects. Inlined call frames become true call frames. When we reify an inlined call
frame and it is a tail call which we will be continuing from, we need to restore the tag
constant callee save registers with what was saved by the outermost caller.
Re-enabled tail calls and restored tests for tail calls.
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames): Select whether or not we use the callee save tag register
contents or what was saved by the inlining caller when populating an inlined callee's
callee save registers.
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitSaveCalleeSavesFor): This function no longer needs a stack offset.
(JSC::AssemblyHelpers::emitSaveOrCopyCalleeSavesFor): New helper.
* runtime/Options.h: Turned tail calls back on.
* tests/es6.yaml:
* tests/stress/dfg-tail-calls.js:
(nonInlinedTailCall.callee):
* tests/stress/mutual-tail-call-no-stack-overflow.js:
(shouldThrow):
* tests/stress/tail-call-in-inline-cache.js:
(tail):
* tests/stress/tail-call-no-stack-overflow.js:
(shouldThrow):
* tests/stress/tail-call-recognize.js:
(callerMustBeRun):
* tests/stress/tail-call-varargs-no-stack-overflow.js:
(shouldThrow):
2015-10-20 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: JavaScriptCore should parse sourceURL and sourceMappingURL directives
https://bugs.webkit.org/show_bug.cgi?id=150096
Reviewed by Geoffrey Garen.
* inspector/ContentSearchUtilities.cpp:
(Inspector::ContentSearchUtilities::scriptCommentPattern): Deleted.
(Inspector::ContentSearchUtilities::findScriptSourceURL): Deleted.
(Inspector::ContentSearchUtilities::findScriptSourceMapURL): Deleted.
* inspector/ContentSearchUtilities.h:
No longer need to search script content.
* inspector/ScriptDebugServer.cpp:
(Inspector::ScriptDebugServer::dispatchDidParseSource):
Carry over the sourceURL and sourceMappingURL from the SourceProvider.
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::sourceMapURLForScript):
(Inspector::InspectorDebuggerAgent::didParseSource):
No longer do content searching.
* parser/Lexer.cpp:
(JSC::Lexer<T>::setCode):
(JSC::Lexer<T>::skipWhitespace):
(JSC::Lexer<T>::parseCommentDirective):
(JSC::Lexer<T>::parseCommentDirectiveValue):
(JSC::Lexer<T>::consume):
(JSC::Lexer<T>::lex):
* parser/Lexer.h:
(JSC::Lexer::sourceURL):
(JSC::Lexer::sourceMappingURL):
(JSC::Lexer::sourceProvider): Deleted.
Give lexer the ability to detect script comment directives.
This just consumes characters in single line comments and
ultimately sets the sourceURL or sourceMappingURL found.
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
* parser/SourceProvider.h:
(JSC::SourceProvider::url):
(JSC::SourceProvider::sourceURL):
(JSC::SourceProvider::sourceMappingURL):
(JSC::SourceProvider::setSourceURL):
(JSC::SourceProvider::setSourceMappingURL):
After parsing a script, update the Source Provider with the
value of directives that may have been found in the script.
2015-10-20 Saam barati <sbarati@apple.com>
GCAwareJITStubRoutineWithExceptionHandler has a stale CodeBlock pointer in its destructor
https://bugs.webkit.org/show_bug.cgi?id=150351
Reviewed by Mark Lam.
We may regenerate many GCAwareJITStubRoutineWithExceptionHandler stubs per one PolymorphicAccess.
Only the last GCAwareJITStubRoutineWithExceptionHandler stub that was generated will get the CodeBlock's aboutToDie()
notification. All other GCAwareJITStubRoutineWithExceptionHandler stubs will still be holding a stale CodeBlock pointer
that they will use in their destructor. The solution is to have GCAwareJITStubRoutineWithExceptionHandler remove its
exception handler in observeZeroRefCount() instead of its destructor. observeZeroRefCount() will run when a PolymorphicAccess
replaces its m_stubRoutine.
* jit/GCAwareJITStubRoutine.cpp:
(JSC::GCAwareJITStubRoutineWithExceptionHandler::aboutToDie):
(JSC::GCAwareJITStubRoutineWithExceptionHandler::observeZeroRefCount):
(JSC::createJITStubRoutine):
(JSC::GCAwareJITStubRoutineWithExceptionHandler::~GCAwareJITStubRoutineWithExceptionHandler): Deleted.
* jit/GCAwareJITStubRoutine.h:
2015-10-20 Tim Horton <timothy_horton@apple.com>
Try to fix the build by disabling MAC_GESTURE_EVENTS on 10.9 and 10.10
* Configurations/FeatureDefines.xcconfig:
2015-10-20 Xabier Rodriguez Calvar <calvaris@igalia.com>
[Streams API] Rework some readable stream internals that can be common to writable streams
https://bugs.webkit.org/show_bug.cgi?id=150133
Reviewed by Darin Adler.
* runtime/CommonIdentifiers.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init): Added RangeError also as native functions.
2015-10-20 Yoav Weiss <yoav@yoav.ws>
Rename the PICTURE_SIZES flag to CURRENTSRC
https://bugs.webkit.org/show_bug.cgi?id=150275
Reviewed by Dean Jackson.
* Configurations/FeatureDefines.xcconfig:
2015-10-19 Saam barati <sbarati@apple.com>
FTL should generate a unique OSR exit for each duplicated OSR exit stackmap intrinsic.
https://bugs.webkit.org/show_bug.cgi?id=149970
Reviewed by Filip Pizlo.
When we lower DFG to LLVM, we generate a stackmap intrnsic for OSR
exits. We also recorded the OSR exit inside FTL::JITCode during lowering.
This stackmap intrinsic may be duplicated or even removed by LLVM.
When the stackmap intrinsic is duplicated, we used to generate just
a single OSR exit data structure. Then, when we compiled an OSR exit, we
would look for the first record in the record list that had the same stackmap ID
as what the OSR exit data structure had. We did this even when the OSR exit
stackmap intrinsic was duplicated. This would lead us to grab the wrong FTL::StackMaps::Record.
Now, each OSR exit knows exactly which FTL::StackMaps::Record it corresponds to.
We accomplish this by having an OSRExitDescriptor that is recorded during
lowering. Each descriptor may be referenced my zero, one, or more OSRExits.
Now, no more than one stackmap intrinsic corresponds to the same index inside
JITCode's OSRExit Vector. Also, each OSRExit jump now jumps to a code location.
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::validateReferences):
(JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
* ftl/FTLJITCode.h:
* ftl/FTLJITFinalizer.cpp:
(JSC::FTL::JITFinalizer::finalizeFunction):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
(JSC::FTL::DFG::LowerDFGToLLVM::compileIsUndefined):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
(JSC::FTL::DFG::LowerDFGToLLVM::emitOSRExitCall):
(JSC::FTL::DFG::LowerDFGToLLVM::buildExitArguments):
(JSC::FTL::DFG::LowerDFGToLLVM::callStackmap):
* ftl/FTLOSRExit.cpp:
(JSC::FTL::OSRExitDescriptor::OSRExitDescriptor):
(JSC::FTL::OSRExitDescriptor::validateReferences):
(JSC::FTL::OSRExit::OSRExit):
(JSC::FTL::OSRExit::codeLocationForRepatch):
(JSC::FTL::OSRExit::validateReferences): Deleted.
* ftl/FTLOSRExit.h:
(JSC::FTL::OSRExit::considerAddingAsFrequentExitSite):
* ftl/FTLOSRExitCompilationInfo.h:
(JSC::FTL::OSRExitCompilationInfo::OSRExitCompilationInfo):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
(JSC::FTL::compileFTLOSRExit):
* ftl/FTLStackMaps.cpp:
(JSC::FTL::StackMaps::computeRecordMap):
* ftl/FTLStackMaps.h:
2015-10-16 Brian Burg <bburg@apple.com>
Unify handling of JavaScriptCore scripts that are used in WebCore
https://bugs.webkit.org/show_bug.cgi?id=150245
Reviewed by Alex Christensen.
Move all standalone JavaScriptCore scripts that are used by WebCore into the
JavaScriptCore/Scripts directory. Use JavaScriptCore_SCRIPTS_DIR to refer
to the path for these scripts.
* DerivedSources.make:
Define and use JavaScriptCore_SCRIPTS_DIR.
* JavaScriptCore.xcodeproj/project.pbxproj:
Make a new group in the Xcode project and clean up references.
* PlatformWin.cmake:
For Windows, copy these scripts over to ForwardingHeaders/Scripts since they
cannot be used directly from JAVASCRIPTCORE_DIR in AppleWin builds. Do the same
thing for both Windows variants to be consistent about it.
* Scripts/cssmin.py: Renamed from Source/JavaScriptCore/inspector/scripts/cssmin.py.
* Scripts/generate-combined-inspector-json.py: Renamed from Source/JavaScriptCore/inspector/scripts/generate-combined-inspector-json.py.
* Scripts/generate-js-builtins: Renamed from Source/JavaScriptCore/generate-js-builtins.
* Scripts/inline-and-minify-stylesheets-and-scripts.py: Renamed from Source/JavaScriptCore/inspector/scripts/inline-and-minify-stylesheets-and-scripts.py.
* Scripts/jsmin.py: Renamed from Source/JavaScriptCore/inspector/scripts/jsmin.py.
* Scripts/xxd.pl: Renamed from Source/JavaScriptCore/inspector/scripts/xxd.pl.
2015-10-19 Tim Horton <timothy_horton@apple.com>
Try to fix the iOS build
* Configurations/FeatureDefines.xcconfig:
2015-10-17 Keith Miller <keith_miller@apple.com>
Add regression tests for TypedArray.prototype functions' error messages.
https://bugs.webkit.org/show_bug.cgi?id=150288
Reviewed by Darin Adler.
Fix a typo in the text passed by TypedArrray.prototype.filter type error message.
Add tests that check the actual error message text for all the TypeArray.prototype
functions that throw.
* builtins/TypedArray.prototype.js:
(filter):
* tests/stress/typedarray-every.js:
* tests/stress/typedarray-filter.js:
* tests/stress/typedarray-find.js:
* tests/stress/typedarray-findIndex.js:
* tests/stress/typedarray-forEach.js:
* tests/stress/typedarray-map.js:
* tests/stress/typedarray-reduce.js:
* tests/stress/typedarray-reduceRight.js:
* tests/stress/typedarray-some.js:
2015-10-19 Tim Horton <timothy_horton@apple.com>
Add magnify and rotate gesture event support for Mac
https://bugs.webkit.org/show_bug.cgi?id=150179
<rdar://problem/8036240>
Reviewed by Darin Adler.
* Configurations/FeatureDefines.xcconfig:
New feature flag.
2015-10-19 Csaba Osztrogonác <ossy@webkit.org>
Fix the ENABLE(WEBASSEMBLY) build after r190827
https://bugs.webkit.org/show_bug.cgi?id=150330
Reviewed by Geoffrey Garen.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock): Removed the duplicated VM argument.
* bytecode/CodeBlock.h:
(JSC::WebAssemblyCodeBlock::create): Added new parameters to finishCreation() calls.
(JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock): Change VM parameter to pointer to match *CodeBlock classes.
* runtime/Executable.cpp:
(JSC::WebAssemblyExecutable::prepareForExecution): Removed extra ")" and pass pointer as it is expected.
2015-10-19 Mark Lam <mark.lam@apple.com>
DoubleRep fails to convert SpecBoolean values.
https://bugs.webkit.org/show_bug.cgi?id=150313
Reviewed by Geoffrey Garen.
This was uncovered by the op_sub stress test on 32-bit builds. On 32-bit builds,
DoubleRep will erroneously convert 'true' to a 'NaN' instead of a double 1.
On 64-bit, the same issue exists but is masked by another bug in DoubleRep where
boolean values will always erroneously trigger a BadType OSR exit.
The erroneous conversion of 'true' to 'NaN' is because the 'true' case in
compileDoubleRep() is missing a jump to the "done" destination. Instead, it
fall through to the "isUndefined" case where it produces a NaN.
The 64-bit erroneous BadType OSR exit is due to the boolean type check being
implemented incorrectly. It was checking if any bits other than bit 0 were set.
However, boolean JS values always have TagBitBool (the 3rd bit) set. Hence, the
check will always fail if we have a boolean value.
This patch fixes both of these issues.
No new test is needed because these issues are already covered by scenarios in
the op_sub.js stress test. This patch also fixes the op_sub.js test to throw an
exception if any failures are encountered (as expected by the stress test
harness). This patch also re-worked the test code to provide more accurate
descriptions of each test scenario for error reporting.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileDoubleRep):
* tests/stress/op_sub.js:
(generateScenarios):
(func):
(initializeTestCases):
(runTest):
(stringify): Deleted.
2015-10-19 Yusuke Suzuki <utatane.tea@gmail.com>
Drop !newTarget check since it always becomes true
https://bugs.webkit.org/show_bug.cgi?id=150308
Reviewed by Geoffrey Garen.
In a context of calling a constructor, `newTarget` should not become JSEmpty.
So `!newTarget` always becomes true. This patch drops this unneccessary check.
And to ensure the implementation of the constructor is only called under
the context of calling it as a constructor, we change these functions to
static and only use them for constructor implementations of InternalFunction.
* runtime/IntlCollatorConstructor.cpp:
(JSC::constructIntlCollator):
(JSC::callIntlCollator):
* runtime/IntlCollatorConstructor.h:
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::constructIntlDateTimeFormat):
(JSC::callIntlDateTimeFormat):
* runtime/IntlDateTimeFormatConstructor.h:
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::constructIntlNumberFormat):
(JSC::callIntlNumberFormat):
* runtime/IntlNumberFormatConstructor.h:
* runtime/JSPromiseConstructor.cpp:
(JSC::constructPromise):
2015-10-18 Yusuke Suzuki <utatane.tea@gmail.com>
Promise constructor should throw when not called with "new"
https://bugs.webkit.org/show_bug.cgi?id=149380
Reviewed by Darin Adler.
Implement handling new.target in Promise constructor. And
prohibiting Promise constructor call without "new".
* runtime/JSPromiseConstructor.cpp:
(JSC::constructPromise):
(JSC::callPromise):
(JSC::JSPromiseConstructor::getCallData):
* tests/es6.yaml:
* tests/stress/promise-cannot-be-called.js: Added.
(shouldBe):
(shouldThrow):
(Deferred):
(super):
2015-10-18 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Handle asynchronous tests in tests/es6
https://bugs.webkit.org/show_bug.cgi?id=150293
Reviewed by Darin Adler.
Since JSC can handle microtasks, some of ES6 Promise tests can be executed under the JSC shell.
Some of them still fail because it uses setTimeout that invokes macrotasks with explicit delay.
* tests/es6.yaml:
* tests/es6/Promise_Promise.all.js:
(test.asyncTestPassed):
(test):
* tests/es6/Promise_Promise.all_generic_iterables.js:
(test.asyncTestPassed):
(test):
* tests/es6/Promise_Promise.race.js:
(test.asyncTestPassed):
(test):
* tests/es6/Promise_Promise.race_generic_iterables.js:
(test.asyncTestPassed):
(test):
* tests/es6/Promise_basic_functionality.js:
(test.asyncTestPassed):
(test):
* tests/es6/Promise_is_subclassable_Promise.all.js:
(test.asyncTestPassed):
(test):
* tests/es6/Promise_is_subclassable_Promise.race.js:
(test.asyncTestPassed):
(test):
* tests/es6/Promise_is_subclassable_basic_functionality.js:
(test.asyncTestPassed):
(test):
2015-10-18 Sungmann Cho <sungmann.cho@navercorp.com>
[Win] Fix the Windows builds.
https://bugs.webkit.org/show_bug.cgi?id=150300
Reviewed by Darin Adler.
Add missing files to JavaScriptCore.vcxproj.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2015-10-17 Filip Pizlo <fpizlo@apple.com>
Fix some generational heap growth pathologies
https://bugs.webkit.org/show_bug.cgi?id=150270
Reviewed by Andreas Kling.
When doing generational copying, we would pretend that the size of old space was increased
just by the amount of bytes we copied. In reality, it would be increased by the number of
bytes used by the copied blocks we created. This is a larger number, and in some simple
pathological programs, the difference can be huge.
Fixing this bug was relatively easy, and the only really meaningful change here is in
Heap::updateAllocationLimits(). But to convince myself that the change was valid, I had to
add some debugging code and I had to refactor some stuff so that it made more sense.
This change does obviate the need for m_totalBytesCopied, because we no longer use it in
release builds to decide how much heap we are using at the end of collection. But I added a
FIXME about how we could restore our use of m_totalBytesCopied. So, I kept the logic, for
now. The FIXME references https://bugs.webkit.org/show_bug.cgi?id=150268.
Relanding with build fix.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/CopiedBlock.cpp: Added.
(JSC::CopiedBlock::createNoZeroFill):
(JSC::CopiedBlock::destroy):
(JSC::CopiedBlock::create):
(JSC::CopiedBlock::zeroFillWilderness):
(JSC::CopiedBlock::CopiedBlock):
* heap/CopiedBlock.h:
(JSC::CopiedBlock::didSurviveGC):
(JSC::CopiedBlock::createNoZeroFill): Deleted.
(JSC::CopiedBlock::destroy): Deleted.
(JSC::CopiedBlock::create): Deleted.
(JSC::CopiedBlock::zeroFillWilderness): Deleted.
(JSC::CopiedBlock::CopiedBlock): Deleted.
* heap/CopiedSpaceInlines.h:
(JSC::CopiedSpace::startedCopying):
* heap/Heap.cpp:
(JSC::Heap::updateObjectCounts):
(JSC::Heap::resetVisitors):
(JSC::Heap::capacity):
(JSC::Heap::protectedGlobalObjectCount):
(JSC::Heap::collectImpl):
(JSC::Heap::willStartCollection):
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::didFinishCollection):
(JSC::Heap::sizeAfterCollect): Deleted.
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::shouldCollect):
(JSC::Heap::isBusy):
(JSC::Heap::collectIfNecessaryOrDefer):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::create):
(JSC::MarkedBlock::destroy):
2015-10-17 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r191240.
https://bugs.webkit.org/show_bug.cgi?id=150281
Broke 32-bit builds (Requested by smfr on #webkit).
Reverted changeset:
"Fix some generational heap growth pathologies"
https://bugs.webkit.org/show_bug.cgi?id=150270
http://trac.webkit.org/changeset/191240
2015-10-17 Sungmann Cho <sungmann.cho@navercorp.com>
[Win] Fix the Windows build.
https://bugs.webkit.org/show_bug.cgi?id=150278
Reviewed by Brent Fulgham.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2015-10-17 Mark Lam <mark.lam@apple.com>
Fixed typos from r191224.
Not reviewed.
* jit/JITSubGenerator.h:
(JSC::JITSubGenerator::generateFastPath):
2015-10-17 Filip Pizlo <fpizlo@apple.com>
Fix some generational heap growth pathologies
https://bugs.webkit.org/show_bug.cgi?id=150270
Reviewed by Andreas Kling.
When doing generational copying, we would pretend that the size of old space was increased
just by the amount of bytes we copied. In reality, it would be increased by the number of
bytes used by the copied blocks we created. This is a larger number, and in some simple
pathological programs, the difference can be huge.
Fixing this bug was relatively easy, and the only really meaningful change here is in
Heap::updateAllocationLimits(). But to convince myself that the change was valid, I had to
add some debugging code and I had to refactor some stuff so that it made more sense.
This change does obviate the need for m_totalBytesCopied, because we no longer use it in
release builds to decide how much heap we are using at the end of collection. But I added a
FIXME about how we could restore our use of m_totalBytesCopied. So, I kept the logic, for
now. The FIXME references https://bugs.webkit.org/show_bug.cgi?id=150268.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/CopiedBlock.cpp: Added.
(JSC::CopiedBlock::createNoZeroFill):
(JSC::CopiedBlock::destroy):
(JSC::CopiedBlock::create):
(JSC::CopiedBlock::zeroFillWilderness):
(JSC::CopiedBlock::CopiedBlock):
* heap/CopiedBlock.h:
(JSC::CopiedBlock::didSurviveGC):
(JSC::CopiedBlock::createNoZeroFill): Deleted.
(JSC::CopiedBlock::destroy): Deleted.
(JSC::CopiedBlock::create): Deleted.
(JSC::CopiedBlock::zeroFillWilderness): Deleted.
(JSC::CopiedBlock::CopiedBlock): Deleted.
* heap/CopiedSpaceInlines.h:
(JSC::CopiedSpace::startedCopying):
* heap/Heap.cpp:
(JSC::Heap::updateObjectCounts):
(JSC::Heap::resetVisitors):
(JSC::Heap::capacity):
(JSC::Heap::protectedGlobalObjectCount):
(JSC::Heap::collectImpl):
(JSC::Heap::willStartCollection):
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::didFinishCollection):
(JSC::Heap::sizeAfterCollect): Deleted.
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::shouldCollect):
(JSC::Heap::isBusy):
(JSC::Heap::collectIfNecessaryOrDefer):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::create):
(JSC::MarkedBlock::destroy):
2015-10-16 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement String.prototype.normalize
https://bugs.webkit.org/show_bug.cgi?id=150094
Reviewed by Geoffrey Garen.
This patch implements String.prototype.normalize leveraging ICU.
It can provide the feature applying {NFC, NFD, NFKC, NFKD} normalization to a given string.
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
(JSC::normalize):
(JSC::stringProtoFuncNormalize):
* tests/es6.yaml:
* tests/stress/string-normalize.js: Added.
(unicode):
(shouldBe):
(shouldThrow):
(normalizeTest):
2015-10-16 Geoffrey Garen <ggaren@apple.com>
Update JavaScriptCore API docs
https://bugs.webkit.org/show_bug.cgi?id=150262
Reviewed by Mark Lam.
Apply some edits for clarity. These came out of a docs review.
* API/JSContext.h:
* API/JSExport.h:
* API/JSManagedValue.h:
* API/JSValue.h:
2015-10-16 Keith Miller <keith_miller@apple.com>
Unreviewed. Fix typo in TypeError messages in TypedArray.prototype.forEach/filter.
* builtins/TypedArray.prototype.js:
(forEach):
(filter):
2015-10-16 Mark Lam <mark.lam@apple.com>
Use JITSubGenerator to support UntypedUse operands for op_sub in the DFG.
https://bugs.webkit.org/show_bug.cgi?id=150038
Reviewed by Geoffrey Garen.
* bytecode/SpeculatedType.h:
(JSC::isUntypedSpeculationForArithmetic): Added
- Also fixed some comments.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::resultType):
* dfg/DFGAbstractValue.h:
- Added function to compute the ResultType of an operand from its SpeculatedType.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
- Fix up ArithSub to speculate its operands to be numbers. But if an OSR exit
due to a BadType was seen at this node, we'll fix it up to expect UntypedUse
operands. This gives the generated code a change to run fast if it only
receives numeric operands.
* dfg/DFGNode.h:
(JSC::DFG::Node::shouldSpeculateUntypedForArithmetic):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
- Add the C++ runtime function to implement op_sub when we really encounter the
hard types in the operands.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithSub):
- Added support for UntypedUse operands using the JITSubGenerator.
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::silentSpillAllRegisters):
(JSC::DFG::SpeculativeJIT::pickCanTrample):
(JSC::DFG::SpeculativeJIT::callOperation):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
- Just refuse to FTL compile functions with UntypedUse op_sub operands for now.
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::boxDouble):
(JSC::AssemblyHelpers::unboxDoubleNonDestructive):
(JSC::AssemblyHelpers::unboxDouble):
(JSC::AssemblyHelpers::boxBooleanPayload):
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_sub):
* jit/JITSubGenerator.h:
(JSC::JITSubGenerator::generateFastPath):
(JSC::JITSubGenerator::endJumpList):
- Added some asserts to document the contract that this generator expects in
terms of its incoming registers.
Also fixed the generated code to not be destructive with regards to incoming
registers. The DFG expects this.
Also added an endJumpList so that we don't have to jump twice for the fast
path where both operands are ints.
* parser/ResultType.h:
(JSC::ResultType::ResultType):
- Make the internal Type bits and the constructor private. Clients should only
create ResultType values using one of the provided factory methods.
* tests/stress/op_sub.js: Added.
(o1.valueOf):
(stringify):
(generateScenarios):
(printScenarios):
(testCases.func):
(func):
(initializeTestCases):
(runTest):
- test op_sub results by comparing one LLINT result against the output of
multiple LLINT, and JIT runs. This test assume that we'll at least get the
right result some of the time (if not all the time), and confirms that the
various engines produce consistent results for all the various value pairs
being tested.
2015-10-15 Filip Pizlo <fpizlo@apple.com>
CopyBarrier must be avoided for slow TypedArrays
https://bugs.webkit.org/show_bug.cgi?id=150217
rdar://problem/23128791
Reviewed by Michael Saboff.
Change how we access array buffer views so that we don't fire the barrier slow path, and
don't mask off the spaceBits, if the view is not FastTypedArray. That's because in that case
m_vector could be misaligned and so have meaningful non-space data in the spaceBits. Also in
that case, m_vector does not point into copied space.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
(JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::loadVectorWithBarrier):
(JSC::FTL::DFG::LowerDFGToLLVM::copyBarrier):
(JSC::FTL::DFG::LowerDFGToLLVM::isInToSpace):
(JSC::FTL::DFG::LowerDFGToLLVM::loadButterflyReadOnly):
(JSC::FTL::DFG::LowerDFGToLLVM::loadVectorReadOnly):
(JSC::FTL::DFG::LowerDFGToLLVM::removeSpaceBits):
(JSC::FTL::DFG::LowerDFGToLLVM::isFastTypedArray):
(JSC::FTL::DFG::LowerDFGToLLVM::baseIndex):
* heap/CopyBarrier.h:
(JSC::CopyBarrierBase::getWithoutBarrier):
(JSC::CopyBarrierBase::getPredicated):
(JSC::CopyBarrierBase::get):
(JSC::CopyBarrierBase::copyState):
(JSC::CopyBarrier::get):
(JSC::CopyBarrier::getPredicated):
(JSC::CopyBarrier::set):
* heap/Heap.cpp:
(JSC::Heap::copyBarrier):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::branchIfNotType):
(JSC::AssemblyHelpers::branchIfFastTypedArray):
(JSC::AssemblyHelpers::branchIfNotFastTypedArray):
(JSC::AssemblyHelpers::loadTypedArrayVector):
(JSC::AssemblyHelpers::purifyNaN):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::branchStructure):
(JSC::AssemblyHelpers::branchIfToSpace):
(JSC::AssemblyHelpers::branchIfNotToSpace):
(JSC::AssemblyHelpers::removeSpaceBits):
(JSC::AssemblyHelpers::addressForByteOffset):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitIntTypedArrayGetByVal):
(JSC::JIT::emitFloatTypedArrayGetByVal):
(JSC::JIT::emitIntTypedArrayPutByVal):
(JSC::JIT::emitFloatTypedArrayPutByVal):
* runtime/JSArrayBufferView.h:
(JSC::JSArrayBufferView::vector):
(JSC::JSArrayBufferView::length):
* runtime/JSArrayBufferViewInlines.h:
(JSC::JSArrayBufferView::byteOffset):
* runtime/JSGenericTypedArrayView.h:
(JSC::JSGenericTypedArrayView::typedVector):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::copyBackingStore):
(JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory):
* tests/stress/misaligned-int8-view-byte-offset.js: Added.
* tests/stress/misaligned-int8-view-read.js: Added.
* tests/stress/misaligned-int8-view-write.js: Added.
2015-10-16 Keith Miller <keith_miller@apple.com>
Unreviewed. Build fix for 191215.
* jit/IntrinsicEmitter.cpp:
2015-10-16 Keith Miller <keith@Keiths-MacBook-Pro-5.local>
Add Intrinsic Getters and use them to fix performance on the getters of TypedArray properties.
https://bugs.webkit.org/show_bug.cgi?id=149687
Reviewed by Geoffrey Garen.
Add the ability to create intrinsic getters in both the inline cache and the DFG/FTL. When the
getter fetched by a GetById has an intrinsic we know about we add a new intrinsic access case.
Once we get to the DFG, we observe that the access case was an intrinsic and add an appropriate
GetByIdVariant. We then parse the intrinsic into an appropriate DFG node.
The first intrinsics are the new TypedArray prototype getters length, byteLength, and byteOffset.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::GetByIdStatus::computeFor):
* bytecode/GetByIdVariant.cpp:
(JSC::GetByIdVariant::GetByIdVariant):
(JSC::GetByIdVariant::operator=):
(JSC::GetByIdVariant::canMergeIntrinsicStructures):
(JSC::GetByIdVariant::attemptToMerge):
(JSC::GetByIdVariant::dumpInContext):
* bytecode/GetByIdVariant.h:
(JSC::GetByIdVariant::intrinsicFunction):
(JSC::GetByIdVariant::intrinsic):
(JSC::GetByIdVariant::callLinkStatus): Deleted.
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessGenerationState::addWatchpoint):
(JSC::AccessGenerationState::restoreScratch):
(JSC::AccessGenerationState::succeed):
(JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
(JSC::AccessGenerationState::preserveLiveRegistersToStackForCall):
(JSC::AccessGenerationState::restoreLiveRegistersFromStackForCall):
(JSC::AccessGenerationState::restoreLiveRegistersFromStackForCallWithThrownException):
(JSC::AccessGenerationState::callSiteIndexForExceptionHandlingOrOriginal):
(JSC::AccessGenerationState::originalExceptionHandler):
(JSC::AccessGenerationState::originalCallSiteIndex):
(JSC::AccessCase::getIntrinsic):
(JSC::AccessCase::clone):
(JSC::AccessCase::visitWeak):
(JSC::AccessCase::generate):
(WTF::printInternal):
(JSC::AccessCase::AccessCase): Deleted.
(JSC::AccessCase::get): Deleted.
(JSC::AccessCase::replace): Deleted.
(JSC::AccessCase::transition): Deleted.
* bytecode/PolymorphicAccess.h:
(JSC::AccessCase::isGet):
(JSC::AccessCase::isPut):
(JSC::AccessCase::isIn):
(JSC::AccessCase::intrinsicFunction):
(JSC::AccessCase::intrinsic):
(JSC::AccessGenerationState::AccessGenerationState):
(JSC::AccessGenerationState::liveRegistersForCall):
(JSC::AccessGenerationState::callSiteIndexForExceptionHandling):
(JSC::AccessGenerationState::numberOfStackBytesUsedForRegisterPreservation):
(JSC::AccessGenerationState::needsToRestoreRegistersIfException):
(JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite):
* bytecode/PutByIdVariant.h:
(JSC::PutByIdVariant::intrinsic):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGArrayMode.cpp:
(JSC::DFG::ArrayMode::alreadyChecked):
(JSC::DFG::arrayTypeToString):
(JSC::DFG::toTypedArrayType):
(JSC::DFG::refineTypedArrayType):
(JSC::DFG::permitsBoundsCheckLowering):
* dfg/DFGArrayMode.h:
(JSC::DFG::ArrayMode::supportsLength):
(JSC::DFG::ArrayMode::isSomeTypedArrayView):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::attemptToInlineCall):
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
(JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
(JSC::DFG::ByteCodeParser::load):
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::presenceLike): Deleted.
(JSC::DFG::ByteCodeParser::store): Deleted.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::convertToGetArrayLength): Deleted.
(JSC::DFG::FixupPhase::prependGetArrayLength): Deleted.
(JSC::DFG::FixupPhase::fixupChecksInBlock): Deleted.
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::tryGetFoldableView):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::checkArray):
(JSC::DFG::SpeculativeJIT::compileGetArrayLength):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetArrayLength):
* jit/IntrinsicEmitter.cpp: Added.
(JSC::AccessCase::canEmitIntrinsicGetter):
(JSC::AccessCase::emitIntrinsicGetter):
* jit/Repatch.cpp:
(JSC::tryCacheGetByID):
* runtime/Intrinsic.h:
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::put):
(JSC::JSArrayBufferView::defineOwnProperty):
(JSC::JSArrayBufferView::deleteProperty):
(JSC::JSArrayBufferView::getOwnNonIndexPropertyNames):
(JSC::JSArrayBufferView::getOwnPropertySlot): Deleted.
(JSC::JSArrayBufferView::finalize): Deleted.
* runtime/JSDataView.cpp:
(JSC::JSDataView::getOwnPropertySlot):
(JSC::JSDataView::put):
(JSC::JSDataView::defineOwnProperty):
(JSC::JSDataView::deleteProperty):
(JSC::JSDataView::getOwnNonIndexPropertyNames):
* runtime/JSDataView.h:
* runtime/JSFunction.h:
* runtime/JSFunctionInlines.h:
(JSC::JSFunction::intrinsic):
* runtime/JSGenericTypedArrayView.h:
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
(JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
(JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
(JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex): Deleted.
(JSC::JSGenericTypedArrayView<Adaptor>::visitChildren): Deleted.
* runtime/JSObject.cpp:
(JSC::JSObject::putDirectNativeIntrinsicGetter):
* runtime/JSObject.h:
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::JSTypedArrayViewPrototype::finishCreation):
* tests/stress/typedarray-add-property-to-base-object.js: Added.
(body.foo):
(body):
* tests/stress/typedarray-bad-getter.js: Added.
(body.foo):
(body.get Bar):
(body):
* tests/stress/typedarray-getter-on-self.js: Added.
(body.foo):
(body.bar):
(body.baz):
(body.get for):
(body):
* tests/stress/typedarray-intrinsic-getters-change-prototype.js: Added.
(body.foo):
(body.bar):
(body.baz):
(body):
2015-10-16 Keith Miller <keith_miller@apple.com>
Fix some issues with TypedArrays
https://bugs.webkit.org/show_bug.cgi?id=150216
Reviewed by Geoffrey Garen.
This fixes a couple of issues:
1) The DFG had a separate case for creating new typedarrays in the dfg when the first argument is an object.
Since the code for creating a Typedarray in the dfg is almost the same as the code in Baseline/LLInt
the two cases have been merged.
2) If the length property on an object was unset then the construction could crash.
3) The TypedArray.prototype.set function and the TypedArray constructor should not call [[Get]] for the
length of the source object when the source object is a TypedArray.
4) The conditions that were used to decide if the iterator could be skipped were incorrect.
Instead of checking for have a bad time we should have checked the Indexing type did not allow for
indexed accessors.
* dfg/DFGOperations.cpp:
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayViewWithArguments):
(JSC::constructGenericTypedArrayView):
(JSC::constructGenericTypedArrayViewWithFirstArgument): Deleted.
2015-10-16 Anders Carlsson <andersca@apple.com>
Fix Windows build.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2015-10-16 Michael Saboff <msaboff@apple.com>
REGRESSION (r191175): Still crashing when clicking back button on netflix.com
https://bugs.webkit.org/show_bug.cgi?id=150251
Rubber stamped by Filip Pizlo.
Turning off Tail Calls and disabling tests until the crash is fixed.
* runtime/Options.h:
* tests/es6.yaml:
* tests/stress/dfg-tail-calls.js:
(nonInlinedTailCall.callee):
* tests/stress/mutual-tail-call-no-stack-overflow.js:
(shouldThrow):
* tests/stress/tail-call-in-inline-cache.js:
(tail):
* tests/stress/tail-call-no-stack-overflow.js:
(shouldThrow):
* tests/stress/tail-call-recognize.js:
(callerMustBeRun):
* tests/stress/tail-call-varargs-no-stack-overflow.js:
(shouldThrow):
2015-10-16 Mark Lam <mark.lam@apple.com>
Add MacroAssembler::callProbe() for supporting lambda JIT probes.
https://bugs.webkit.org/show_bug.cgi?id=150186
Reviewed by Geoffrey Garen.
With callProbe(), we can now make probes that are lambdas. For example, we can
now conveniently add probes like so:
// When you know exactly which register you want to inspect:
jit.callProbe([] (MacroAssembler::ProbeContext* context) {
intptr_t value = reinterpret_cast<intptr_t>(context->cpu.eax);
dataLogF("eax %p\n", context->cpu.eax); // Inspect the register.
ASSERT(value > 10); // Add test code for debugging.
});
// When you want to inspect whichever register the JIT allocated:
auto reg = op1.gpr();
jit.callProbe([reg] (MacroAssembler::ProbeContext* context) {
intptr_t value = reinterpret_cast<intptr_t>(context->gpr(reg));
dataLogF("reg %s: %ld\n", context->gprName(reg), value);
ASSERT(value > 10);
});
callProbe() is only meant to be used for debugging sessions. It is not
appropriate to use it in permanent code (even for debug builds).
This is because:
1. The probe mechanism saves and restores all (and I really mean "all")
registers, and is inherently slow.
2. callProbe() currently works by allocating (via new) a std::function to
guarantee that it is persisted for the duration that the JIT generated code is
live. We don't currently delete it ever i.e. it leaks a bit of memory each
time the JIT generates code that contains such a lambda probe.
These limitations are acceptable for a debugging session (assuming you're not
debugging a memory leak), but not for deployment code. If there's a need, we can
plug that leak in another patch.
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::CPUState::fpr):
- Removed an unnecessary empty line.
(JSC::AbstractMacroAssembler::ProbeContext::gpr):
(JSC::AbstractMacroAssembler::ProbeContext::fpr):
(JSC::AbstractMacroAssembler::ProbeContext::gprName):
(JSC::AbstractMacroAssembler::ProbeContext::fprName):
- Added some convenience functions that will make using the probe mechanism
easier.
* assembler/MacroAssembler.cpp:
(JSC::StdFunctionData::StdFunctionData):
(JSC::stdFunctionCallback):
(JSC::MacroAssembler::callProbe):
* assembler/MacroAssembler.h:
2015-10-16 Andreas Kling <akling@apple.com>
Remove unused StructureRareData::m_cachedGenericPropertyNameEnumerator.
<https://webkit.org/b/150244>
Reviewed by Geoffrey Garen.
Remove an unused field from StructureRareData.
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::visitChildren): Deleted.
* runtime/StructureRareData.h:
2015-10-16 Keith Miller <keith_miller@apple.com>
Unreviewed, rolling out r191190.
Patch needs some design changes.
Reverted changeset:
"Fix some issues with TypedArrays"
https://bugs.webkit.org/show_bug.cgi?id=150216
http://trac.webkit.org/changeset/191190
2015-10-16 Mark Lam <mark.lam@apple.com>
Move all the probe trampolines into their respective MacroAssembler files.
https://bugs.webkit.org/show_bug.cgi?id=150239
Reviewed by Saam Barati.
This patch does not introduce any behavior changes. It only moves the
ctiMasmProbeTrampoline implementations from the respective JITStubs<CPU>.h
files to the corresponding MacroAssembler<CPU>.cpp files.
I also had to make some minor changes to get the code to build after this move:
1. Added #include <wtf/InlineASM.h> in the MacroAssembler<CPU>.cpp files
because the ctiMasmProbeTrampoline is an inline assembly blob.
2. In the moved code, convert MacroAssembler:: qualifiers to the CPU specific
MacroAssembler equivalent. The referenced entities were always defined in
the CPU specific MacroAssembler anyway, and indirectly referenced through
the generic MacroAssembler.
With this, we can get rid of all the JITStubs<CPU>.cpp files. There is one
exception: JITStubsMSVC64.asm. However, that one is unrelated to the probe
mechanism. So, I'll leave it as is.
We can also remove JITStubs.cpp and JITStubs.h which are now empty except for
some stale unused code.
This patch has been build tested for x86, x86_64, armv7, and arm64.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/MacroAssemblerARM.cpp:
(JSC::MacroAssemblerARM::probe):
* assembler/MacroAssemblerARM64.cpp:
(JSC::arm64ProbeTrampoline):
(JSC::MacroAssemblerARM64::probe):
* assembler/MacroAssemblerARMv7.cpp:
(JSC::MacroAssemblerARMv7::probe):
* assembler/MacroAssemblerX86Common.cpp:
* bytecode/CodeBlock.cpp:
* ftl/FTLCompile.cpp:
* ftl/FTLLink.cpp:
* jit/JITArithmetic.cpp:
* jit/JITArithmetic32_64.cpp:
* jit/JITCode.h:
* jit/JITExceptions.cpp:
* jit/JITStubs.cpp: Removed.
* jit/JITStubs.h: Removed.
* jit/JITStubsARM.h: Removed.
* jit/JITStubsARM64.h: Removed.
* jit/JITStubsARMv7.h: Removed.
* jit/JITStubsX86.h: Removed.
* jit/JITStubsX86Common.h: Removed.
* jit/JITStubsX86_64.h: Removed.
* jit/JSInterfaceJIT.h:
* llint/LLIntOffsetsExtractor.cpp:
* runtime/CommonSlowPaths.cpp:
2015-10-16 Keith Miller <keith_miller@apple.com>
Fix some issues with TypedArrays
https://bugs.webkit.org/show_bug.cgi?id=150216
Reviewed by Michael Saboff.
This fixes a couple of issues:
1) The DFG had a separate case for creating new typedarrays in the dfg when the first argument is an object.
Since the code for creating a Typedarray in the dfg is almost the same as the code in Baseline/LLInt
the two cases have been merged.
2) If the length property on an object was unset then the construction could crash.
3) The TypedArray.prototype.set function and the TypedArray constructor should not call [[Get]] for the
length of the source object when the source object is a TypedArray.
4) The conditions that were used to decide if the iterator could be skipped were incorrect.
Instead of checking for have a bad time we should have checked the Indexing type did not allow for
indexed accessors.
* dfg/DFGOperations.cpp:
(JSC::DFG::newTypedArrayWithOneArgument): Deleted.
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayViewFromIterator):
(JSC::constructGenericTypedArrayViewWithFirstArgument):
(JSC::constructGenericTypedArrayView):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewProtoFuncSet):
* tests/stress/typedarray-construct-iterator.js: Added.
(iterator.return.next):
(iterator):
(body):
2015-10-15 Michael Saboff <msaboff@apple.com>
REGRESSION (r190289): Repro crash clicking back button on netflix.com
https://bugs.webkit.org/show_bug.cgi?id=150220
Reviewed by Geoffrey Garen.
Since constructors check for a valid new "this" object and return it, we can't make
a tail call to another function from within a constructor.
Re-enabled the tail calls and the related tail call tests.
Did some other miscellaneous clean up in the tail call code as part of the debugging.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::callPreflight):
* interpreter/Interpreter.h:
(JSC::calleeFrameForVarargs):
* runtime/Options.h:
* tests/es6.yaml:
* tests/stress/dfg-tail-calls.js:
(nonInlinedTailCall.callee):
* tests/stress/mutual-tail-call-no-stack-overflow.js:
(shouldThrow):
* tests/stress/tail-call-in-inline-cache.js:
(tail):
* tests/stress/tail-call-no-stack-overflow.js:
(shouldThrow):
* tests/stress/tail-call-recognize.js:
(callerMustBeRun):
* tests/stress/tail-call-varargs-no-stack-overflow.js:
(shouldThrow):
2015-10-15 Joseph Pecoraro <pecoraro@apple.com>
Unreviewed. Attempted EFL build fix 2 after r191159.
* PlatformEfl.cmake:
2015-10-15 Joseph Pecoraro <pecoraro@apple.com>
Unreviewed. Attempted EFL build fix after r191159.
* PlatformEfl.cmake:
2015-10-15 Joseph Pecoraro <pecoraro@apple.com>
Unreviewed. Build fix after r191160.
* inspector/agents/InspectorHeapAgent.cpp:
(Inspector::InspectorHeapAgent::didGarbageCollect):
2015-10-15 Joseph Pecoraro <pecoraro@apple.com>
Unreviewed. Revert part of r191159 which caused ASSERTs.
A review comment suggested using WeakPtr. It is not suitable
here and causes ASSERTs across threads. Will address separately.
* inspector/agents/InspectorHeapAgent.h:
* inspector/agents/InspectorHeapAgent.cpp:
(Inspector::InspectorHeapAgent::didGarbageCollect):
(Inspector::InspectorHeapAgent::InspectorHeapAgent): Deleted.
2015-10-14 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Include Garbage Collection Event in Timeline
https://bugs.webkit.org/show_bug.cgi?id=142510
Reviewed by Geoffrey Garen and Brian Burg.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
Include new files in the build.
* heap/HeapObserver.h:
(JSC::HeapObserver::~HeapObserver):
* heap/Heap.cpp:
(JSC::Heap::willStartCollection):
(JSC::Heap::didFinishCollection):
* heap/Heap.h:
(JSC::Heap::addObserver):
(JSC::Heap::removeObserver):
Allow observers on heap to add hooks for starting / ending garbage collection.
* inspector/InspectorEnvironment.h:
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
(Inspector::JSGlobalObjectInspectorController::vm):
* inspector/JSGlobalObjectInspectorController.h:
Access the VM through the InspectorEnvironment as it won't change.
* inspector/agents/InspectorHeapAgent.cpp: Added.
(Inspector::InspectorHeapAgent::InspectorHeapAgent):
(Inspector::InspectorHeapAgent::~InspectorHeapAgent):
(Inspector::InspectorHeapAgent::didCreateFrontendAndBackend):
(Inspector::InspectorHeapAgent::willDestroyFrontendAndBackend):
(Inspector::InspectorHeapAgent::enable):
(Inspector::InspectorHeapAgent::disable):
(Inspector::InspectorHeapAgent::gc):
(Inspector::protocolTypeForHeapOperation):
(Inspector::InspectorHeapAgent::willGarbageCollect):
(Inspector::InspectorHeapAgent::didGarbageCollect):
* inspector/agents/InspectorHeapAgent.h: Added.
* inspector/protocol/Heap.json: Added.
New domain and agent to handle tasks related to the JavaScriptCore heap.
2015-10-15 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r191135.
https://bugs.webkit.org/show_bug.cgi?id=150197
This patch causes 50+ LayoutTest crashes related to the
inspector (Requested by ryanhaddad on #webkit).
Reverted changeset:
"Web Inspector: JavaScriptCore should parse sourceURL and
sourceMappingURL directives"
https://bugs.webkit.org/show_bug.cgi?id=150096
http://trac.webkit.org/changeset/191135
2015-10-15 Geoffrey Garen <ggaren@apple.com>
Unreviewed, rolling out r191003.
https://bugs.webkit.org/show_bug.cgi?id=150042
We're seeing some crashes in GC beneath speculationFromCell. Maybe this
patch caused them?
Reverted changeset:
CodeBlock write barriers should be precise
https://bugs.webkit.org/show_bug.cgi?id=150042
http://trac.webkit.org/changeset/191003
2015-10-15 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: JavaScriptCore should parse sourceURL and sourceMappingURL directives
https://bugs.webkit.org/show_bug.cgi?id=150096
Reviewed by Geoffrey Garen.
* inspector/ContentSearchUtilities.cpp:
(Inspector::ContentSearchUtilities::scriptCommentPattern): Deleted.
(Inspector::ContentSearchUtilities::findScriptSourceURL): Deleted.
(Inspector::ContentSearchUtilities::findScriptSourceMapURL): Deleted.
* inspector/ContentSearchUtilities.h:
No longer need to search script content.
* inspector/ScriptDebugServer.cpp:
(Inspector::ScriptDebugServer::dispatchDidParseSource):
Carry over the sourceURL and sourceMappingURL from the SourceProvider.
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::sourceMapURLForScript):
(Inspector::InspectorDebuggerAgent::didParseSource):
No longer do content searching.
* parser/Lexer.cpp:
(JSC::Lexer<T>::setCode):
(JSC::Lexer<T>::skipWhitespace):
(JSC::Lexer<T>::parseCommentDirective):
(JSC::Lexer<T>::parseCommentDirectiveValue):
(JSC::Lexer<T>::consume):
(JSC::Lexer<T>::lex):
* parser/Lexer.h:
(JSC::Lexer::sourceURL):
(JSC::Lexer::sourceMappingURL):
(JSC::Lexer::sourceProvider): Deleted.
Give lexer the ability to detect script comment directives.
This just consumes characters in single line comments and
ultimately sets the sourceURL or sourceMappingURL found.
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
* parser/SourceProvider.h:
(JSC::SourceProvider::url):
(JSC::SourceProvider::sourceURL):
(JSC::SourceProvider::sourceMappingURL):
(JSC::SourceProvider::setSourceURL):
(JSC::SourceProvider::setSourceMappingURL):
After parsing a script, update the Source Provider with the
value of directives that may have been found in the script.
2015-10-15 Filip Pizlo <fpizlo@apple.com>
InferredTypeTable should ref its keys
https://bugs.webkit.org/show_bug.cgi?id=150138
rdar://problem/23080555
Reviewed by Michael Saboff.
InferredTypeTable was incorrectly using a key hash traits that caused the underlying HashTable to
store keys as UniquedStringImpl* rather than RefPtr<UniquedStringImpl>, even though the HashMap's
nominal key type was RefPtr<UniquedStringImpl>. This arose because I copy-pasted the HashMap type
instantiation from other places and then made random changes to adapt it to my needs, rather than
actually thinking about what I was doing. The solution is to remove the key hash traits argument,
since all it accomplishes is to produce this bug.
The way this bug manifested is probably best described in http://webkit.org/b/150008. After a while
the InferredTypeTable would have dangling references to its strings, if some recompilation or other
thing caused us to drop all other references to those strings. InferredTypeTable is particularly
susceptible to this because it is designed to know about a superset of the property names that its
client Structures know about. The debug assert would then happen when we rehashed the
InferredTypeTable's HashMap, because we'd try to get the hashes of strings that were already
deleted. AFAICT, we didn't have release crashes arising from those strings' memory being returned
to the OS - but it's totally possible that this could have happened. So, we definitely should treat
this bug as more than just a debug issue.
Interestingly, we could have also solved this problem by changing the hash function to use PtrHash.
In all other ways, it's OK for InferredTypeTable to hold dangling references, since it uses the
address of the UniquedStringImpl as a way to name an abstract heap. It's fine if the name of an
abstract heap is a bogus memory address, and it's also fine if that name referred to an entirely
different UniquedStringImpl at some point in the past. That's a nice benefit of any data structure
that keys by abstract heap - if two of them get unified then it's no big deal. I've filed another
bug, http://webkit.org/b/150137 about changing all of our UniquedStringImpl* hashing to use
PtrHash.
* runtime/Identifier.h: Add a comment about http://webkit.org/b/150137.
* runtime/InferredTypeTable.h: Fix the bug.
* tests/stress/inferred-type-table-stale-identifiers.js: Added. I couldn't get this to cause a crash before my change, but it's an interesting test nonetheless.
2015-10-15 Mark Lam <mark.lam@apple.com>
Add MASM_PROBE support for ARM64.
https://bugs.webkit.org/show_bug.cgi?id=150128
Reviewed by Michael Saboff.
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/ARM64Assembler.h:
- Convert the ARM64 registers enum list into a macro list so that we can use
it elsewhere e.g. to declare fields in the probe CPUState.
Also de-tabbed the contents of the ARM64Registers namespace since the enum
list change touches almost all of it anyway. This reduces the amount of
complaints from the style checker.
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::CPUState::registerName):
(JSC::AbstractMacroAssembler::CPUState::registerValue):
- Change CPUState methods to allow for registers ID that do not map to one of
its fields. This is needed because ARM64's registers include aliases for some
register names. The CPUState will not allocate separate storage for the
aliases.
* assembler/MacroAssemblerARM64.cpp: Added.
(JSC::arm64ProbeTrampoline):
- Unlike the probe mechanism for other CPUs, the ARM64 implementation does not
allow the probe function to modify the sp and pc registers. We insert this
wrapper function between ctiMasmProbeTrampoline() and the user's probe function
so that we can check if the user tried to modify sp and pc. If so, we will
print an error message so that we can alert the user that we don't support
that on ARM64.
See the comment in ctiMasmProbeTrampoline() in JITStubsARM64.h for details
on why we cannot support sp and pc modifications by the probe function.
(JSC::MacroAssemblerARM64::probe):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::repatchCall):
(JSC::MacroAssemblerARM64::makeBranch):
* jit/JITStubs.cpp:
* jit/JITStubsARM64.h: Added.
2015-10-15 Mark Lam <mark.lam@apple.com>
Fix some typos in comments.
https://bugs.webkit.org/show_bug.cgi?id=150181
Rubber stamped by Michael Saboff.
* jit/JITStubsARM.h:
* jit/JITStubsARMv7.h:
2015-10-15 Mark Lam <mark.lam@apple.com>
Refactoring: give the MASM probe CPUState methods shorter names.
https://bugs.webkit.org/show_bug.cgi?id=150177
Reviewed by Michael Saboff.
The existing names are longer than they need to be. Renaming them as follows:
For GPR, registerName ==> gprName
For GPR, registerValue ==> gpr
For FPR, registerName ==> fprName
For FPR, registerValue ==> fpr
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::CPUState::gprName):
(JSC::AbstractMacroAssembler::CPUState::fprName):
(JSC::AbstractMacroAssembler::CPUState::gpr):
(JSC::AbstractMacroAssembler::CPUState::fpr):
(JSC::AbstractMacroAssembler::CPUState::registerName): Deleted.
(JSC::AbstractMacroAssembler::CPUState::registerValue): Deleted.
* assembler/MacroAssemblerPrinter.cpp:
(JSC::printRegister):
(JSC::printMemory):
- Updated to use the new names.
2015-10-15 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Class expression should have lexical environment that has itself as an imutable binding
https://bugs.webkit.org/show_bug.cgi?id=150089
Reviewed by Geoffrey Garen.
According to ES6 spec, class expression has its own lexical environment that holds itself
as an immutable binding[1] (section 14.5.14 step 2, 3, 4, 23)
As a result, even if the binding declared in the outer scope is overridden, methods inside
class expression can refer its class by the class name.
[1]: http://ecma-international.org/ecma-262/6.0/#sec-runtime-semantics-classdefinitionevaluation
* bytecompiler/NodesCodegen.cpp:
(JSC::ClassExprNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createClassExpr):
* parser/NodeConstructors.h:
(JSC::ClassExprNode::ClassExprNode):
* parser/Nodes.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createClassExpr):
* tests/es6.yaml:
* tests/stress/class-expression-generates-environment.js: Added.
(shouldBe):
(shouldThrow):
(prototype.method):
(staticMethod):
(A.prototype.method):
(A.staticMethod):
(A):
* tests/stress/class-expression-should-be-tdz-in-heritage.js: Added.
(shouldThrow):
(shouldThrow.A):
2015-10-14 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Class method should not declare any variables to upper scope.
https://bugs.webkit.org/show_bug.cgi?id=150115
Reviewed by Geoffrey Garen.
In the current implementation, class methods attempt to declare variables to an upper scope with their method names.
But this is not specified behavior in the ES6 spec.
And as a result, previously, we attempted to declare variables with invalid identifiers.
For example, `class A { 1() { } }` attempt to declare a variable with name `1`.
This (declaring variables with incorrect names) is not allowed in the lexical environment.
And it fires assertions in https://bugs.webkit.org/show_bug.cgi?id=150089.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass): Deleted.
* tests/stress/class-method-does-not-declare-variable-to-upper-scope.js: Added.
(shouldBe):
(A.prototype.method):
(A.staticMethod):
(A):
2015-10-14 Joseph Pecoraro <pecoraro@apple.com>
REGRESSION: Web Inspector hangs for many seconds when trying to reload page
https://bugs.webkit.org/show_bug.cgi?id=150065
Reviewed by Mark Lam.
When debugging Web Pages, the same Debugger (PageScriptDebugServer) is
attached to each of the different JSGlobalObjects on the page. This could
mean multiple frames or isolated scripting contexts. Therefore we should
only need to send sourceParsed events to the frontend for scripts within
this new JSGlobalObject, not any JSGlobalObject that has this debugger.
* debugger/Debugger.cpp:
(JSC::Debugger::attach):
Only send sourceParsed events for Scripts in this JSGlobalObject.
2015-10-14 Joseph Pecoraro <pecoraro@apple.com>
Remove unimplemented methods in CopiedSpace
https://bugs.webkit.org/show_bug.cgi?id=150143
Reviewed by Andreas Kling.
* heap/CopiedSpace.h:
2015-10-14 Brent Fulgham <bfulgham@apple.com>
[Win] Enforce launcher/library naming scheme
https://bugs.webkit.org/show_bug.cgi?id=150124
Reviewed by Alex Christensen.
* JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp: Look for
{name}Lib.dll instead of {name}.dll.
(wWinMain):
* shell/PlatformWin.cmake: Add 'Lib' suffix to DLLs.
2015-10-14 Keith Miller <keith_miller@apple.com>
ES6 Fix TypedArray constructors.
https://bugs.webkit.org/show_bug.cgi?id=149975
Reviewed by Geoffrey Garen.
The ES6 spec requires that any object argument passed to a TypedArray constructor that is not a TypedArray
and has an iterator should use the iterator to construct the TypedArray. To avoid performance regressions related
to iterating we check if the iterator attached to the object points to the generic array iterator and length is a value.
If so, we do not use the iterator since there should be no observable difference. Another other interesting note is
that the ES6 spec has the of and from functions on a shared constructor between all the TypedArray constructors.
When the TypedArray is constructed the expectation is to crawl the prototype chain of the this value
passed to the function. If the function finds a known TypedArray constructor (Int32Array, Float64Array,...) then
it creates a TypedArray of that type. This is implemented by adding a private function (@allocateTypedArray) to each
of the constructors that can be called in order to construct the array. By using the private functions the JIT should
hopefully be able to optimize this to a direct call.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/TypedArrayConstructor.js: Added.
(of):
(from):
(allocateInt8Array):
(allocateInt16Array):
(allocateInt32Array):
(allocateUint32Array):
(allocateUint16Array):
(allocateUint8Array):
(allocateUint8ClampedArray):
(allocateFloat32Array):
(allocateFloat64Array):
* runtime/CommonIdentifiers.h:
* runtime/JSDataView.cpp:
(JSC::JSDataView::setIndex):
* runtime/JSDataView.h:
* runtime/JSGenericTypedArrayView.h:
(JSC::JSGenericTypedArrayView::toAdaptorNativeFromValue):
* runtime/JSGenericTypedArrayViewConstructor.h:
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
(JSC::JSGenericTypedArrayViewConstructor<ViewClass>::create):
(JSC::constructGenericTypedArrayViewFromIterator):
(JSC::constructGenericTypedArrayView):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewProtoFuncIndexOf):
(JSC::genericTypedArrayViewProtoFuncLastIndexOf):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSTypedArrayViewConstructor.cpp: Added.
(JSC::JSTypedArrayViewConstructor::JSTypedArrayViewConstructor):
(JSC::JSTypedArrayViewConstructor::finishCreation):
(JSC::JSTypedArrayViewConstructor::create):
(JSC::JSTypedArrayViewConstructor::createStructure):
(JSC::constructTypedArrayView):
(JSC::JSTypedArrayViewConstructor::getConstructData):
(JSC::JSTypedArrayViewConstructor::getCallData):
* runtime/JSTypedArrayViewConstructor.h: Copied from Source/JavaScriptCore/runtime/JSGenericTypedArrayViewConstructor.h.
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::JSTypedArrayViewPrototype::create):
* tests/es6.yaml:
* tests/stress/resources/typedarray-constructor-helper-functions.js: Added.
(forEachTypedArray):
(hasSameValues):
(foo):
(testConstructorFunction):
(testConstructor):
* tests/stress/typedarray-constructor.js: Added.
(A):
(iterator.return.next):
(iterator):
(obj.valueOf):
(iterator2.return.next):
(iterator2):
* tests/stress/typedarray-from.js: Added.
(even):
(isBigEnoughAndException):
* tests/stress/typedarray-of.js: Added.
2015-10-14 Mark Lam <mark.lam@apple.com>
Rename some JSC option names to be more uniform.
https://bugs.webkit.org/show_bug.cgi?id=150127
Reviewed by Geoffrey Garen.
Renaming JSC_enableXXX options to JSC_useXXX, and JSC_showXXX options to JSC_dumpXXX.
Also will renaming a few other miscellaneous to options, to abide by this scheme.
Also renaming some functions to match the option names where relevant.
* API/tests/ExecutionTimeLimitTest.cpp:
(testExecutionTimeLimit):
* assembler/AbstractMacroAssembler.h:
(JSC::optimizeForARMv7IDIVSupported):
(JSC::optimizeForARM64):
(JSC::optimizeForX86):
* assembler/LinkBuffer.cpp:
(JSC::shouldDumpDisassemblyFor):
(JSC::LinkBuffer::finalizeCodeWithoutDisassembly):
(JSC::shouldShowDisassemblyFor): Deleted.
* assembler/LinkBuffer.h:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::jettison):
* bytecode/CodeBlockJettisoningWatchpoint.cpp:
(JSC::CodeBlockJettisoningWatchpoint::fireInternal):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
* dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::fire):
* dfg/DFGAdaptiveStructureWatchpoint.cpp:
(JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleInlining):
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::handlePutById):
(JSC::DFG::ByteCodeParser::parse):
* dfg/DFGCommon.h:
(JSC::DFG::leastUpperBound):
(JSC::DFG::shouldDumpDisassembly):
(JSC::DFG::shouldShowDisassembly): Deleted.
* dfg/DFGDriver.cpp:
(JSC::DFG::compileImpl):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::JITCompiler):
(JSC::DFG::JITCompiler::disassemble):
* dfg/DFGJumpReplacement.cpp:
(JSC::DFG::JumpReplacement::fire):
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareOSREntry):
* dfg/DFGOSRExitCompiler.cpp:
* dfg/DFGOSRExitFuzz.h:
(JSC::DFG::doOSRExitFuzzing):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithSqrt):
* dfg/DFGTierUpCheckInjectionPhase.cpp:
(JSC::DFG::TierUpCheckInjectionPhase::run):
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::~JITCode):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
(JSC::FTL::compileFTLOSRExit):
* ftl/FTLState.h:
(JSC::FTL::verboseCompilationEnabled):
(JSC::FTL::shouldDumpDisassembly):
(JSC::FTL::shouldShowDisassembly): Deleted.
* heap/Heap.cpp:
(JSC::Heap::addToRememberedSet):
(JSC::Heap::didFinishCollection):
(JSC::Heap::shouldDoFullCollection):
* heap/Heap.h:
(JSC::Heap::isDeferred):
(JSC::Heap::structureIDTable):
* heap/HeapStatistics.cpp:
(JSC::StorageStatistics::storageCapacity):
(JSC::HeapStatistics::dumpObjectStatistics):
(JSC::HeapStatistics::showObjectStatistics): Deleted.
* heap/HeapStatistics.h:
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::createArguments):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::callExceptionFuzz):
* jit/ExecutableAllocationFuzz.cpp:
(JSC::doExecutableAllocationFuzzing):
* jit/ExecutableAllocationFuzz.h:
(JSC::doExecutableAllocationFuzzingIfEnabled):
* jit/JIT.cpp:
(JSC::JIT::privateCompile):
* jit/JITCode.cpp:
(JSC::JITCodeWithCodeRef::~JITCodeWithCodeRef):
* jit/PolymorphicCallStubRoutine.cpp:
(JSC::PolymorphicCallNode::unlink):
(JSC::PolymorphicCallNode::clearCallLinkInfo):
(JSC::PolymorphicCallStubRoutine::PolymorphicCallStubRoutine):
* jit/Repatch.cpp:
(JSC::linkFor):
(JSC::unlinkFor):
(JSC::linkVirtualFor):
* jsc.cpp:
(functionEnableExceptionFuzz):
(jscmain):
* llvm/InitializeLLVM.cpp:
(JSC::initializeLLVMImpl):
* runtime/ExceptionFuzz.cpp:
(JSC::doExceptionFuzzing):
* runtime/ExceptionFuzz.h:
(JSC::doExceptionFuzzingIfEnabled):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
(JSC::Options::initialize):
(JSC::Options::dumpOptionsIfNeeded):
(JSC::Options::setOption):
(JSC::Options::dumpAllOptions):
(JSC::Options::dumpAllOptionsInALine):
(JSC::Options::dumpOption):
* runtime/Options.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
(JSC::VM::exceptionFuzzingBuffer):
* runtime/WriteBarrierInlines.h:
(JSC::WriteBarrierBase<T>::set):
(JSC::WriteBarrierBase<Unknown>::set):
* tests/executableAllocationFuzz.yaml:
* tests/stress/arrowfunction-typeof.js:
* tests/stress/disable-function-dot-arguments.js:
(foo):
* tests/stress/math-sqrt-basics-disable-architecture-specific-optimizations.js:
(sqrtOnInteger):
* tests/stress/regress-148564.js:
2015-10-14 Mark Lam <mark.lam@apple.com>
Speculative build fix: the CallSiteIndex constructor is explicit and requires an uint32_t.
Not Reviewed.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::newExceptionHandlingCallSiteIndex):
2015-10-14 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r191030.
https://bugs.webkit.org/show_bug.cgi?id=150116
caused js/class-syntax-method-names.html to crash on debug
builds (Requested by alexchristensen_ on #webkit).
Reverted changeset:
"[ES6] Class expression should have lexical environment that
has itself as an imutable binding"
https://bugs.webkit.org/show_bug.cgi?id=150089
http://trac.webkit.org/changeset/191030
2015-10-13 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Class expression should have lexical environment that has itself as an imutable binding
https://bugs.webkit.org/show_bug.cgi?id=150089
Reviewed by Geoffrey Garen.
According to ES6 spec, class expression has its own lexical environment that holds itself
as an immutable binding[1] (section 14.5.14 step 2, 3, 4, 23)
As a result, even if the binding declared in the outer scope is overridden, methods inside
class expression can refer its class by the class name.
[1]: http://ecma-international.org/ecma-262/6.0/#sec-runtime-semantics-classdefinitionevaluation
* bytecompiler/NodesCodegen.cpp:
(JSC::ClassExprNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createClassExpr):
* parser/NodeConstructors.h:
(JSC::ClassExprNode::ClassExprNode):
* parser/Nodes.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createClassExpr):
* tests/es6.yaml:
* tests/stress/class-expression-generates-environment.js: Added.
(shouldBe):
(shouldThrow):
(prototype.method):
(staticMethod):
(A.prototype.method):
(A.staticMethod):
(A):
* tests/stress/class-expression-should-be-tdz-in-heritage.js: Added.
(shouldThrow):
(shouldThrow.A):
2015-10-13 Saam barati <sbarati@apple.com>
We were creating a GCAwareJITStubRoutineWithExceptionHandler when we didn't actually have an exception handler in the CodeBlock's exception handler table
https://bugs.webkit.org/show_bug.cgi?id=150016
Reviewed by Geoffrey Garen.
There was a bug where we created a GCAwareJITStubRoutineWithExceptionHandler
for inline caches that were custom setters/getters (but not JS getters/setters).
This is wrong; we only create GCAwareJITStubRoutineWithExceptionHandler when we have
an inline cache with a JS getter/setter call which causes the inline cache to add itself
to the CodeBlock's exception handling table. The problem was that we created
a GCAwareJITStubRoutineWithExceptionHandler that tried to remove itself from
the exception handler table only to find out that it didn't have an entry in the table.
* bytecode/PolymorphicAccess.cpp:
(JSC::PolymorphicAccess::regenerate):
2015-10-13 Joseph Pecoraro <pecoraro@apple.com>
Simplify WeakBlock visit and reap phases
https://bugs.webkit.org/show_bug.cgi?id=150045
Reviewed by Geoffrey Garen.
WeakBlock visiting and reaping both happen after MarkedBlock marking.
All the MarkedBlocks we encounter should be either Marked or Retired.
* heap/MarkedBlock.h:
(JSC::MarkedBlock::isMarkedOrRetired):
* heap/WeakBlock.cpp:
(JSC::WeakBlock::visit):
(JSC::WeakBlock::reap):
* heap/WeakBlock.h:
2015-10-12 Geoffrey Garen <ggaren@apple.com>
CodeBlock write barriers should be precise
https://bugs.webkit.org/show_bug.cgi?id=150042
Reviewed by Saam Barati.
CodeBlock performs lots of unnecessary write barriers. This wastes
performance and makes the code a bit harder to follow, and it might mask
important bugs. Now is a good time to unmask important bugs.
* bytecode/CodeBlock.h:
(JSC::CodeBlockSet::mark): Don't write barrier all CodeBlocks on the
stack. Only CodeBlocks that do value profiling need write barriers, and
they do those themselves.
In steady state, when most of our CodeBlocks are old and FTL-compiled,
and we're doing eden GC's, we should almost never visit a CodeBlock.
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::osrWriteBarrier):
(JSC::DFG::adjustAndJumpToTarget): Don't write barrier all inlined
CodeBlocks on exit. That's not necessary. Instead, write barrier the
CodeBlock(s) we will exit to, along with the one we will write a value
profile to.
2015-10-13 Yusuke Suzuki <utatane.tea@gmail.com>
REGRESSION: ASSERT (impl->isAtomic()) @ facebook.com
https://bugs.webkit.org/show_bug.cgi?id=149965
Reviewed by Geoffrey Garen.
Edge filtering for CheckIdent ensures that a given value is either Symbol or StringIdent.
However, this filtering is not applied to CheckIdent when propagating a constant value in
the constant folding phase. As a result, it is not guaranteeed that a constant value
propagated in constant folding is Symbol or StringIdent.
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
2015-10-12 Yusuke Suzuki <utatane.tea@gmail.com>
Unreviewed, register symbol structure to fix Debug build
https://bugs.webkit.org/show_bug.cgi?id=149622
Since InferredTypes for String or Symbol claim that they don't have any structure,
`registerInferredType` does not register the structure for Symbol.
We take the similar way to String to fix this issue; Registering Symbol structure
explicitly in DFGStructureRegisterationPhase. Because,
1. InferredType::structure is only allowed for ObjectWithStructure / ObjectWithStructureOrOther.
It looks clear to me that only ObjectWithStructure has structure.
2. Symbol is similar primitive value to String. So handling its structure in similar way to String is nice.
* dfg/DFGStructureRegistrationPhase.cpp:
(JSC::DFG::StructureRegistrationPhase::run):
2015-10-12 Yusuke Suzuki <utatane.tea@gmail.com>
Iterator loops over key twice after delete
https://bugs.webkit.org/show_bug.cgi?id=149811
Reviewed by Geoffrey Garen.
When an object is the dictionary mode, JSPropertyNameEnumerator collects property names through generic property name enumeration `getPropertyNames`.
The result vector contains indexed property names. But in this case, `publicLength()` may not be 0.
So without disabling indexed names enumeration phase explicitly, JSPropertyNameEnumerator produces indexed property names twice.
One in indexed name enumeration phase, and another in generic property name enumeration phase.
This patch disables indexed names enumeration by setting `indexedLength` to 0 when collecting names through generic property name enumeration.
* runtime/JSPropertyNameEnumerator.h:
(JSC::propertyNameEnumerator):
* tests/stress/property-name-enumerator-should-not-look-into-indexed-values-when-it-is-a-dictionary.js: Added.
(shouldBe):
(col2.of.Reflect.enumerate):
2015-10-12 Yusuke Suzuki <utatane.tea@gmail.com>
Introduce Symbol type for property type inference
https://bugs.webkit.org/show_bug.cgi?id=149622
Reviewed by Geoffrey Garen.
This patch introduces Symbol type into property type inference.
One of the use cases of ES6 Symbol is enum value. In this case,
we may hold different symbols as the same property of the same structure.
Current property type inference does not support Symbol type, so in the
above case, the property will be inferred as Top type.
* bytecode/PutByIdFlags.h:
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::set):
* dfg/DFGInferredTypeCheck.cpp:
(JSC::DFG::insertInferredTypeCheck):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::checkInferredType):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::branchIfNotType):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/InferredType.cpp:
(JSC::InferredType::kindForFlags):
(JSC::InferredType::Descriptor::forValue):
(JSC::InferredType::Descriptor::putByIdFlags):
(JSC::InferredType::Descriptor::merge):
(WTF::printInternal):
* runtime/InferredType.h:
* tests/stress/prop-type-symbol-then-object.js: Added.
(foo):
(bar):
(toString):
* tests/stress/prop-type-symbol-then-string.js: Added.
(foo):
(bar):
2015-10-12 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Rebaseline Inspector generator tests and make better use of RWIProtocol constant
https://bugs.webkit.org/show_bug.cgi?id=150044
Reviewed by Brian Burg.
* inspector/scripts/codegen/generate_objc_configuration_header.py:
(ObjCConfigurationHeaderGenerator.generate_output):
(ObjCConfigurationHeaderGenerator._generate_configuration_interface_for_domains):
* inspector/scripts/codegen/generate_objc_configuration_implementation.py:
(ObjCBackendDispatcherImplementationGenerator._generate_configuration_implementation_for_domains):
* inspector/scripts/codegen/generate_objc_header.py:
(ObjCHeaderGenerator.generate_output):
* inspector/scripts/codegen/generate_objc_internal_header.py:
(ObjCInternalHeaderGenerator.generate_output):
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2015-10-12 Myles C. Maxfield <mmaxfield@apple.com>
Unreviewed build fix
* runtime/JSObject.cpp:
(JSC::JSObject::reallocateAndShrinkButterfly):
2015-10-08 Filip Pizlo <fpizlo@apple.com>
GC should have a Baker barrier for concurrent copying
https://bugs.webkit.org/show_bug.cgi?id=149852
Reviewed by Geoffrey Garen.
This adds a Baker-style read barrier [1] to copied space accesses. This barrier incurs some
overhead (0%-2% depending on benchmark suite), but what it buys is the ability to make the GC copy
phase concurrent.
The barrier relies on copied space pointers having two "space bits" in the low pointer bits. The
space bits indicate whether the backing store is being copied right now or not, and if it is being
copied, what stage of copying it's in. Two barrier variants are supported:
Read only barrier: if you load a backing store and immediately load from it without doing anything
else, you can just mask off the bits. In the worst case, you'll get the old backing store while
some copying thread is already allocating and populating the new version of the backing store. But
in that case, forwarding to the new backing store will not enable you to load a more up-to-date
value from the backing store. So, just masking the bits is enough. The read-only barrier is only
used in ICs where we know that we are only reading, and opportunistically within the DFG and FTL
thanks to the CopyBarrierOptimizationPhase. We never explicitly emit a read-only barrier in those
compilers; instead the phase will turn a GetButterfly into GetButterflyReadOnly if it proves that a
bunch of requirements are met.
Normal barrier: if the space bits are non-zero, call a slow path. The slow path will either do
nothing (if the copy phase hasn't started yet), or it will copy the backing store and update the
pointer (if the copy phase hasn't gotten around to copying this particular backing store), or it
will wait for the copying thread to finish (if some thread is copying this backing store right
now), or it will do nothing (if by the time we called into the slow path the backing store was
already copied). This is just like Baker's CAR/CDR barrier, but with a lock thrown in to handle
concurrent execution.
This is a 1% slow-down on SunSpider, a 1.5% slow-down on Octane, a 1.5% slow-down on Kraken, and a
0% slow-down on AsmBench. Note that the Octane slow-down is excluding the SplayLatency benchmark.
That benchmark will eventually speed up a lot once we finish doing all of this stuff. Probably, the
JetStream splay-latency will see an even larger speed-up, since our version of the latency tests do
a better job of punishing bad worst-case behavior.
[1] http://dspace.mit.edu/bitstream/handle/1721.1/41976/AI_WP_139.pdf, look for the CAR and CDR
procedures on page 9.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generate):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGCopyBarrierOptimizationPhase.cpp: Added.
(JSC::DFG::performCopyBarrierOptimization):
* dfg/DFGCopyBarrierOptimizationPhase.h: Added.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGHeapLocation.h:
* dfg/DFGLICMPhase.cpp:
(JSC::DFG::LICMPhase::run):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
(JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
(JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
(JSC::DFG::SpeculativeJIT::compileGetButterfly):
(JSC::DFG::SpeculativeJIT::temporaryRegisterForPutByVal):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetButterfly):
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetButterflyReadOnly):
(JSC::FTL::DFG::LowerDFGToLLVM::compileConstantStoragePointer):
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetIndexedPropertyStorage):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCheckArray):
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetTypedArrayByteOffset):
(JSC::FTL::DFG::LowerDFGToLLVM::compileMultiGetByOffset):
(JSC::FTL::DFG::LowerDFGToLLVM::compileMultiPutByOffset):
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetDirectPname):
(JSC::FTL::DFG::LowerDFGToLLVM::storageForTransition):
(JSC::FTL::DFG::LowerDFGToLLVM::getById):
(JSC::FTL::DFG::LowerDFGToLLVM::loadButterflyWithBarrier):
(JSC::FTL::DFG::LowerDFGToLLVM::loadVectorWithBarrier):
(JSC::FTL::DFG::LowerDFGToLLVM::copyBarrier):
(JSC::FTL::DFG::LowerDFGToLLVM::loadButterflyReadOnly):
(JSC::FTL::DFG::LowerDFGToLLVM::loadVectorReadOnly):
(JSC::FTL::DFG::LowerDFGToLLVM::removeSpaceBits):
(JSC::FTL::DFG::LowerDFGToLLVM::baseIndex):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationNewObjectWithButterfly):
(JSC::FTL::operationPopulateObjectInOSR):
* ftl/FTLOutput.h:
(JSC::FTL::Output::testNonZero32):
(JSC::FTL::Output::testIsZero64):
(JSC::FTL::Output::testNonZero64):
(JSC::FTL::Output::testIsZeroPtr):
(JSC::FTL::Output::testNonZeroPtr):
(JSC::FTL::Output::select):
(JSC::FTL::Output::extractValue):
* heap/CopyBarrier.h: Copied from Source/JavaScriptCore/heap/CopyWriteBarrier.h.
(JSC::CopyBarrierBase::CopyBarrierBase):
(JSC::CopyBarrierBase::operator!):
(JSC::CopyBarrierBase::operator bool):
(JSC::CopyBarrierBase::getWithoutBarrier):
(JSC::CopyBarrierBase::get):
(JSC::CopyBarrierBase::copyState):
(JSC::CopyBarrierBase::setCopyState):
(JSC::CopyBarrierBase::clear):
(JSC::CopyBarrierBase::set):
(JSC::CopyBarrierBase::setWithoutBarrier):
(JSC::CopyBarrierBase::weakCASWithoutBarrier):
(JSC::CopyBarrier::CopyBarrier):
(JSC::CopyBarrier::getWithoutBarrier):
(JSC::CopyBarrier::get):
(JSC::CopyBarrier::set):
(JSC::CopyBarrier::setWithoutBarrier):
(JSC::CopyBarrier::weakCASWithoutBarrier):
(JSC::CopyWriteBarrier::CopyWriteBarrier): Deleted.
(JSC::CopyWriteBarrier::operator!): Deleted.
(JSC::CopyWriteBarrier::operator bool): Deleted.
(JSC::CopyWriteBarrier::get): Deleted.
(JSC::CopyWriteBarrier::operator*): Deleted.
(JSC::CopyWriteBarrier::operator->): Deleted.
(JSC::CopyWriteBarrier::set): Deleted.
(JSC::CopyWriteBarrier::setWithoutWriteBarrier): Deleted.
(JSC::CopyWriteBarrier::clear): Deleted.
* heap/CopyVisitorInlines.h:
(JSC::CopyVisitor::checkIfShouldCopy):
* heap/CopyWriteBarrier.h: Removed.
* heap/Heap.cpp:
(JSC::Heap::addToRememberedSet):
(JSC::Heap::copyBarrier):
(JSC::Heap::collectAndSweep):
* heap/Heap.h:
(JSC::Heap::writeBarrierBuffer):
* heap/HeapInlines.h:
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::branchStructure):
(JSC::AssemblyHelpers::branchIfNotToSpace):
(JSC::AssemblyHelpers::removeSpaceBits):
(JSC::AssemblyHelpers::addressForByteOffset):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JITOpcodes.cpp:
(JSC::JIT::emitSlow_op_has_indexed_property):
(JSC::JIT::emit_op_get_direct_pname):
(JSC::JIT::emitSlow_op_get_direct_pname):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_get_direct_pname):
(JSC::JIT::emitSlow_op_get_direct_pname):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitDoubleLoad):
(JSC::JIT::emitContiguousLoad):
(JSC::JIT::emitArrayStorageLoad):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emitGenericContiguousPutByVal):
(JSC::JIT::emitArrayStoragePutByVal):
(JSC::JIT::emitSlow_op_put_by_val):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emitSlow_op_get_from_scope):
(JSC::JIT::emit_op_put_to_scope):
(JSC::JIT::emitSlow_op_put_to_scope):
(JSC::JIT::emitIntTypedArrayGetByVal):
(JSC::JIT::emitFloatTypedArrayGetByVal):
(JSC::JIT::emitIntTypedArrayPutByVal):
(JSC::JIT::emitFloatTypedArrayPutByVal):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/DirectArguments.cpp:
(JSC::DirectArguments::visitChildren):
(JSC::DirectArguments::copyBackingStore):
(JSC::DirectArguments::overrideThings):
(JSC::DirectArguments::overrideThingsIfNecessary):
(JSC::DirectArguments::overrideArgument):
(JSC::DirectArguments::copyToArguments):
* runtime/DirectArguments.h:
(JSC::DirectArguments::canAccessIndexQuickly):
(JSC::DirectArguments::canAccessArgumentIndexQuicklyInDFG):
* runtime/JSArray.cpp:
(JSC::JSArray::setLength):
(JSC::JSArray::pop):
(JSC::JSArray::push):
(JSC::JSArray::fastSlice):
(JSC::JSArray::fastConcatWith):
(JSC::JSArray::shiftCountWithArrayStorage):
(JSC::JSArray::shiftCountWithAnyIndexingType):
(JSC::JSArray::unshiftCountWithAnyIndexingType):
(JSC::JSArray::fillArgList):
(JSC::JSArray::copyToArguments):
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
(JSC::JSArrayBufferView::JSArrayBufferView):
(JSC::JSArrayBufferView::finishCreation):
(JSC::JSArrayBufferView::finalize):
* runtime/JSArrayBufferView.h:
(JSC::JSArrayBufferView::vector):
(JSC::JSArrayBufferView::length):
* runtime/JSArrayBufferViewInlines.h:
(JSC::JSArrayBufferView::neuter):
(JSC::JSArrayBufferView::byteOffset):
* runtime/JSGenericTypedArrayView.h:
(JSC::JSGenericTypedArrayView::typedVector):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
(JSC::JSGenericTypedArrayView<Adaptor>::copyBackingStore):
(JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory):
* runtime/JSMap.h:
(JSC::JSMap::JSMap):
* runtime/JSObject.cpp:
(JSC::JSObject::copyButterfly):
(JSC::JSObject::visitChildren):
(JSC::JSObject::copyBackingStore):
(JSC::JSObject::getOwnPropertySlotByIndex):
(JSC::JSObject::putByIndex):
(JSC::JSObject::enterDictionaryIndexingMode):
(JSC::JSObject::createInitialIndexedStorage):
(JSC::JSObject::createArrayStorage):
(JSC::JSObject::convertUndecidedToInt32):
(JSC::JSObject::convertUndecidedToDouble):
(JSC::JSObject::convertUndecidedToContiguous):
(JSC::JSObject::constructConvertedArrayStorageWithoutCopyingElements):
(JSC::JSObject::convertUndecidedToArrayStorage):
(JSC::JSObject::convertInt32ToDouble):
(JSC::JSObject::convertInt32ToContiguous):
(JSC::JSObject::convertInt32ToArrayStorage):
(JSC::JSObject::convertDoubleToContiguous):
(JSC::JSObject::convertDoubleToArrayStorage):
(JSC::JSObject::convertContiguousToArrayStorage):
(JSC::JSObject::setIndexQuicklyToUndecided):
(JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode):
(JSC::JSObject::deletePropertyByIndex):
(JSC::JSObject::getOwnPropertyNames):
(JSC::JSObject::putIndexedDescriptor):
(JSC::JSObject::defineOwnIndexedProperty):
(JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
(JSC::JSObject::putDirectIndexBeyondVectorLength):
(JSC::JSObject::getNewVectorLength):
(JSC::JSObject::ensureLengthSlow):
(JSC::JSObject::reallocateAndShrinkButterfly):
(JSC::JSObject::growOutOfLineStorage):
(JSC::JSObject::getOwnPropertyDescriptor):
(JSC::JSObject::getEnumerableLength):
* runtime/JSObject.h:
(JSC::JSObject::getArrayLength):
(JSC::JSObject::getVectorLength):
(JSC::JSObject::canGetIndexQuickly):
(JSC::JSObject::getIndexQuickly):
(JSC::JSObject::tryGetIndexQuickly):
(JSC::JSObject::canSetIndexQuickly):
(JSC::JSObject::canSetIndexQuicklyForPutDirect):
(JSC::JSObject::setIndexQuickly):
(JSC::JSObject::initializeIndex):
(JSC::JSObject::hasSparseMap):
(JSC::JSObject::inSparseIndexingMode):
(JSC::JSObject::inlineStorage):
(JSC::JSObject::butterfly):
(JSC::JSObject::outOfLineStorage):
(JSC::JSObject::locationForOffset):
(JSC::JSObject::ensureInt32):
(JSC::JSObject::ensureDouble):
(JSC::JSObject::ensureContiguous):
(JSC::JSObject::ensureArrayStorage):
(JSC::JSObject::arrayStorage):
(JSC::JSObject::arrayStorageOrNull):
(JSC::JSObject::ensureLength):
(JSC::JSObject::putDirectWithoutTransition):
* runtime/JSSet.h:
(JSC::JSSet::JSSet):
* runtime/MapData.h:
(JSC::JSIterator>::MapDataImpl):
(JSC::JSIterator>::IteratorData::next):
(JSC::JSIterator>::IteratorData::refreshCursor):
* runtime/MapDataInlines.h:
(JSC::JSIterator>::clear):
(JSC::JSIterator>::find):
(JSC::JSIterator>::add):
(JSC::JSIterator>::remove):
(JSC::JSIterator>::replaceAndPackBackingStore):
(JSC::JSIterator>::replaceBackingStore):
(JSC::JSIterator>::ensureSpaceForAppend):
(JSC::JSIterator>::visitChildren):
(JSC::JSIterator>::copyBackingStore):
* runtime/Options.h:
2015-10-12 Saam barati <sbarati@apple.com>
Update JSC features.json
https://bugs.webkit.org/show_bug.cgi?id=150043
Reviewed by Mark Lam.
There were a lot of things implemented that weren't in
the list. We should be better about updating the list
as we land patches for new ES6 features.
* features.json:
2015-10-12 Joseph Pecoraro <pecoraro@apple.com>
Cleanup Heap.h and some related headers
https://bugs.webkit.org/show_bug.cgi?id=149981
Reviewed by Geoffrey Garen.
* heap/Heap.h:
- Some functions did not need export.
- threadDupStrings never had an implementation.
* heap/ConservativeRoots.cpp:
* heap/ConservativeRoots.h:
* heap/Heap.cpp:
* heap/ListableHandler.h:
* heap/WeakReferenceHarvester.h:
* jit/Repatch.cpp:
* runtime/JSONObject.h:
* runtime/VM.h:
- Stale forward declarations / includes.
2015-10-12 Saam barati <sbarati@apple.com>
Each *ById inline cache in the FTL must have its own CallSiteIndex
https://bugs.webkit.org/show_bug.cgi?id=150039
Reviewed by Geoffrey Garen and Filip Pizlo.
When lowering to LLVM, we create a patchpoint intrinsic for each
*ById in DFG IR. LLVM may choose to duplicate these patchpoints.
Therefore, we want each resulting inline cache to have a unique
CallSiteIndex because each inline cache will have its own set of
used registers. This change is necessary when we implement try/catch
in the FTL because an inline cache will ask for the set of used
registers it will need to restore in the event of an exception
being thrown. It asks for this set of registers by giving JITCode
a CallSiteIndex. Because each corresponding inline cache that results
from a duplicated patchpoint may all ask this for this set of registers,
we must assign each inline cache a unique CallSiteIndex.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::newExceptionHandlingCallSiteIndex):
* dfg/DFGCommonData.cpp:
(JSC::DFG::CommonData::addCodeOrigin):
(JSC::DFG::CommonData::addUniqueCallSiteIndex):
(JSC::DFG::CommonData::addCodeOriginUnconditionally): Deleted.
* dfg/DFGCommonData.h:
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLInlineCacheDescriptor.h:
(JSC::FTL::InlineCacheDescriptor::InlineCacheDescriptor):
(JSC::FTL::InlineCacheDescriptor::stackmapID):
(JSC::FTL::InlineCacheDescriptor::codeOrigin):
(JSC::FTL::InlineCacheDescriptor::uid):
(JSC::FTL::GetByIdDescriptor::GetByIdDescriptor):
(JSC::FTL::PutByIdDescriptor::PutByIdDescriptor):
(JSC::FTL::CheckInDescriptor::CheckInDescriptor):
(JSC::FTL::LazySlowPathDescriptor::LazySlowPathDescriptor):
(JSC::FTL::InlineCacheDescriptor::callSiteIndex): Deleted.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
(JSC::FTL::DFG::LowerDFGToLLVM::compileIn):
(JSC::FTL::DFG::LowerDFGToLLVM::getById):
(JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
2015-10-12 Andreas Kling <akling@apple.com>
"A + B" with strings shouldn't copy if A or B is empty.
<https://webkit.org/b/150034>
Reviewed by Anders Carlsson.
* runtime/JSStringBuilder.h:
(JSC::jsMakeNontrivialString):
* runtime/Lookup.cpp:
(JSC::reifyStaticAccessor):
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncToString):
2015-10-12 Joseph Pecoraro <pecoraro@apple.com>
VisitedValueCount GC Counter misses parallel SlotVisitors
https://bugs.webkit.org/show_bug.cgi?id=149980
Reviewed by Geoffrey Garen.
* heap/Heap.cpp:
(JSC::Heap::updateObjectCounts):
Include threaded slot visitor's object counts in the debugging value.
2015-10-12 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix non-FTL build for real.
* ftl/FTLLazySlowPath.h:
2015-10-12 Filip Pizlo <fpizlo@apple.com>
Unreviewed, clarify a comment. The example code had a bug.
* ftl/FTLLowerDFGToLLVM.cpp:
2015-10-12 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix no-FTL build.
* ftl/FTLLazySlowPath.cpp:
2015-10-12 Philip Chimento <philip.chimento@gmail.com>
webkit-gtk 2.3.3 fails to build on OS X - Conflicting type "Fixed"
https://bugs.webkit.org/show_bug.cgi?id=126433
Reviewed by Philippe Normand
Don't include CoreFoundation.h when building the GTK port.
* Source/JavaScriptCore/API/WebKitAvailability.h: Add !defined(BUILDING_GTK__) to defined(__APPLE__).
2015-10-10 Filip Pizlo <fpizlo@apple.com>
FTL should generate code to call slow paths lazily
https://bugs.webkit.org/show_bug.cgi?id=149936
Reviewed by Saam Barati.
We often have complex slow paths in FTL-generated code. Those slow paths may never run. Even
if they do run, they don't need stellar performance. So, it doesn't make sense to have LLVM
worry about compiling such slow path code.
This patch enables us to use our own MacroAssembler for compiling the slow path inside FTL
code. It does this by using a crazy lambda thingy (see FTLLowerDFGToLLVM.cpp's lazySlowPath()
and its documentation). The result is quite natural to use.
Even for straight slow path calls via something like vmCall(), the lazySlowPath offers the
benefit that the call marshalling and the exception checking are not expressed using LLVM IR
and do not require LLVM to think about it. It also has the benefit that we never generate the
code if it never runs. That's great, since function calls usually involve ~10 instructions
total (move arguments to argument registers, make the call, check exception, etc.).
This patch adds the lazy slow path abstraction and uses it for some slow paths in the FTL.
The code we generate with lazy slow paths is worse than the code that LLVM would have
generated. Therefore, a lazy slow path only makes sense when we have strong evidence that
the slow path will execute infrequently relative to the fast path. This completely precludes
the use of lazy slow paths for out-of-line Nodes that unconditionally call a C++ function.
It also precludes their use for the GetByVal out-of-bounds handler, since when we generate
a GetByVal with an out-of-bounds handler it means that we only know that the out-of-bounds
case executed at least once. So, for all we know, it may actually be the common case. So,
this patch just deployed the lazy slow path for GC slow paths and masquerades-as-undefined
slow paths. It makes sense for GC slow paths because those have a statistical guarantee of
slow path frequency - probably bounded at less than 1/10. It makes sense for masquerades-as-
undefined because we can say quite confidently that this is an uncommon scenario on the
modern Web.
Something that's always been challenging about abstractions involving the MacroAssembler is
that linking is a separate phase, and there is no way for someone who is just given access to
the MacroAssembler& to emit code that requires linking, since linking happens once we have
emitted all code and we are creating the LinkBuffer. Moreover, the FTL requires that the
final parts of linking happen on the main thread. This patch ran into this issue, and solved
it comprehensively, by introducing MacroAssembler::addLinkTask(). This takes a lambda and
runs it at the bitter end of linking - when performFinalization() is called. This ensure that
the task added by addLinkTask() runs on the main thread. This patch doesn't replace all of
the previously existing idioms for dealing with this issue; we can do that later.
This shows small speed-ups on a bunch of things. No big win on any benchmark aggregate. But
mainly this is done for https://bugs.webkit.org/show_bug.cgi?id=149852, where we found that
outlining the slow path in this way was a significant speed boost.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::replaceWithAddressComputation):
(JSC::AbstractMacroAssembler::addLinkTask):
(JSC::AbstractMacroAssembler::AbstractMacroAssembler):
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::linkCode):
(JSC::LinkBuffer::allocate):
(JSC::LinkBuffer::performFinalization):
* assembler/LinkBuffer.h:
(JSC::LinkBuffer::wasAlreadyDisassembled):
(JSC::LinkBuffer::didAlreadyDisassemble):
(JSC::LinkBuffer::vm):
(JSC::LinkBuffer::executableOffsetFor):
* bytecode/CodeOrigin.h:
(JSC::CodeOrigin::CodeOrigin):
(JSC::CodeOrigin::isSet):
(JSC::CodeOrigin::operator bool):
(JSC::CodeOrigin::isHashTableDeletedValue):
(JSC::CodeOrigin::operator!): Deleted.
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLInlineCacheDescriptor.h:
(JSC::FTL::InlineCacheDescriptor::InlineCacheDescriptor):
(JSC::FTL::CheckInDescriptor::CheckInDescriptor):
(JSC::FTL::LazySlowPathDescriptor::LazySlowPathDescriptor):
* ftl/FTLJITCode.h:
* ftl/FTLJITFinalizer.cpp:
(JSC::FTL::JITFinalizer::finalizeFunction):
* ftl/FTLJITFinalizer.h:
* ftl/FTLLazySlowPath.cpp: Added.
(JSC::FTL::LazySlowPath::LazySlowPath):
(JSC::FTL::LazySlowPath::~LazySlowPath):
(JSC::FTL::LazySlowPath::generate):
* ftl/FTLLazySlowPath.h: Added.
(JSC::FTL::LazySlowPath::createGenerator):
(JSC::FTL::LazySlowPath::patchpoint):
(JSC::FTL::LazySlowPath::usedRegisters):
(JSC::FTL::LazySlowPath::callSiteIndex):
(JSC::FTL::LazySlowPath::stub):
* ftl/FTLLazySlowPathCall.h: Added.
(JSC::FTL::createLazyCallGenerator):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileCreateActivation):
(JSC::FTL::DFG::LowerDFGToLLVM::compileNewFunction):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCreateDirectArguments):
(JSC::FTL::DFG::LowerDFGToLLVM::compileNewArrayWithSize):
(JSC::FTL::DFG::LowerDFGToLLVM::compileMakeRope):
(JSC::FTL::DFG::LowerDFGToLLVM::compileNotifyWrite):
(JSC::FTL::DFG::LowerDFGToLLVM::compileIsObjectOrNull):
(JSC::FTL::DFG::LowerDFGToLLVM::compileIsFunction):
(JSC::FTL::DFG::LowerDFGToLLVM::compileIn):
(JSC::FTL::DFG::LowerDFGToLLVM::compileMaterializeNewObject):
(JSC::FTL::DFG::LowerDFGToLLVM::compileMaterializeCreateActivation):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCheckWatchdogTimer):
(JSC::FTL::DFG::LowerDFGToLLVM::allocatePropertyStorageWithSizeImpl):
(JSC::FTL::DFG::LowerDFGToLLVM::allocateObject):
(JSC::FTL::DFG::LowerDFGToLLVM::allocateJSArray):
(JSC::FTL::DFG::LowerDFGToLLVM::buildTypeOf):
(JSC::FTL::DFG::LowerDFGToLLVM::sensibleDoubleToInt32):
(JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
(JSC::FTL::DFG::LowerDFGToLLVM::speculate):
(JSC::FTL::DFG::LowerDFGToLLVM::emitStoreBarrier):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
(JSC::FTL::compileFTLLazySlowPath):
* ftl/FTLOperations.h:
* ftl/FTLSlowPathCall.cpp:
(JSC::FTL::SlowPathCallContext::SlowPathCallContext):
(JSC::FTL::SlowPathCallContext::~SlowPathCallContext):
(JSC::FTL::SlowPathCallContext::keyWithTarget):
(JSC::FTL::SlowPathCallContext::makeCall):
(JSC::FTL::callSiteIndexForCodeOrigin):
(JSC::FTL::storeCodeOrigin): Deleted.
(JSC::FTL::callOperation): Deleted.
* ftl/FTLSlowPathCall.h:
(JSC::FTL::callOperation):
* ftl/FTLState.h:
* ftl/FTLThunks.cpp:
(JSC::FTL::genericGenerationThunkGenerator):
(JSC::FTL::osrExitGenerationThunkGenerator):
(JSC::FTL::lazySlowPathGenerationThunkGenerator):
(JSC::FTL::registerClobberCheck):
* ftl/FTLThunks.h:
* interpreter/CallFrame.h:
(JSC::CallSiteIndex::CallSiteIndex):
(JSC::CallSiteIndex::operator bool):
(JSC::CallSiteIndex::bits):
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgument):
(JSC::CCallHelpers::setupArgumentsWithExecState):
* jit/JITOperations.cpp:
2015-10-12 Philip Chimento <philip.chimento@gmail.com>
webkit-gtk-2.3.4 fails to link JavaScriptCore, missing symbols add_history and readline
https://bugs.webkit.org/show_bug.cgi?id=127059
Reviewed by Philippe Normand.
* shell/CMakeLists.txt: Link JSC with -ledit on Mac OSX.
2015-10-11 Yusuke Suzuki <utatane.tea@gmail.com>
ES6 classes: When a class extends B, super() invokes B.prototype.constructor() instead of B()
https://bugs.webkit.org/show_bug.cgi?id=149001
Reviewed by Saam Barati.
This patch matches the `super()` call in the constructor to the latest spec.
Before this patch, when calling `super()`, it loads `callee.[[HomeObject]].__proto__.constructor`
as a super constructor. But after this patch, it loads `callee.__proto__` as a super constructor.
This behavior corresponds to the section 12.3.5.2[1].
[1]: http://www.ecma-international.org/ecma-262/6.0/#sec-getsuperconstructor
* bytecompiler/NodesCodegen.cpp:
(JSC::SuperNode::emitBytecode):
* tests/stress/super-call-does-not-look-up-constructor.js: Added.
(shouldBe):
(B):
(C):
(B.prototype):
2015-10-10 Andreas Kling <akling@apple.com>
Reduce pointless malloc traffic in CodeBlock construction.
<https://webkit.org/b/149999>
Reviewed by Antti Koivisto.
Create the RefCountedArray<Instruction> for CodeBlock's m_instructions directly
instead of first creating a Vector<Instruction> and then creating a RefCountedArray
from that. None of the Vector functionality is needed here anyway.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
* bytecode/CodeBlock.h:
2015-10-10 Dan Bernstein <mitz@apple.com>
[iOS] Remove unnecessary iOS version checks
https://bugs.webkit.org/show_bug.cgi?id=150002
Reviewed by Alexey Proskuryakov.
* llvm/library/LLVMExports.cpp:
(initializeAndGetJSCLLVMAPI):
2015-10-10 Dan Bernstein <mitz@apple.com>
[iOS] Remove project support for iOS 8
https://bugs.webkit.org/show_bug.cgi?id=149993
Reviewed by Alexey Proskuryakov.
* Configurations/Base.xcconfig:
* Configurations/JSC.xcconfig:
* Configurations/JavaScriptCore.xcconfig:
* Configurations/LLVMForJSC.xcconfig:
* Configurations/ToolExecutable.xcconfig:
2015-10-09 Joseph Pecoraro <pecoraro@apple.com>
Modernize and cleanup an NSNumber constant
https://bugs.webkit.org/show_bug.cgi?id=149962
Reviewed by Andreas Kling.
* API/JSVirtualMachine.mm:
(-[JSVirtualMachine addExternalRememberedObject:]):
2015-10-09 Joseph Pecoraro <pecoraro@apple.com>
No need to keep setting needsVisit flag in SmallStrings
https://bugs.webkit.org/show_bug.cgi?id=149961
Reviewed by Andreas Kling.
SmallStrings are all initialized at once privately before the VM
enables Garbage Collection. There is no need to keep updating
this flag, as it couldn't have changed.
* runtime/SmallStrings.cpp:
(JSC::SmallStrings::createEmptyString):
(JSC::SmallStrings::createSingleCharacterString):
(JSC::SmallStrings::initialize):
* runtime/SmallStrings.h:
2015-10-09 Geoffrey Garen <ggaren@apple.com>
Unreviewed, rolling back in r190694
https://bugs.webkit.org/show_bug.cgi?id=149727
This time for double sure?
The cause of the crash was an incorrect write barrier.
OSR exit was barriering the baseline codeblock for the top of the stack
twice, missing the baseline codeblock for the bottom of the stack.
Restored changesets:
"CodeBlock should be a GC object"
https://bugs.webkit.org/show_bug.cgi?id=149727
http://trac.webkit.org/changeset/r190694
2015-10-09 Joseph Pecoraro <pecoraro@apple.com>
Remove unused RecursiveAllocationScope
https://bugs.webkit.org/show_bug.cgi?id=149967
Reviewed by Csaba Osztrogonác.
RecursiveAllocationScope has been unused since r163691.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/Heap.cpp:
* heap/Heap.h:
* heap/RecursiveAllocationScope.h: Removed.
* runtime/VM.h:
2015-10-09 Geoffrey Garen <ggaren@apple.com>
Unreviewed, rolling out r190694
https://bugs.webkit.org/show_bug.cgi?id=148560
Crashes seen on PLT bots and facebook.com.
Reverted changesets:
"CodeBlock should be a GC object"
https://bugs.webkit.org/show_bug.cgi?id=149727
http://trac.webkit.org/changeset/190694
2015-10-09 Xabier Rodriguez Calvar <calvaris@igalia.com> and Youenn Fablet <youenn.fablet@crf.canon.fr>
Automate WebCore JS builtins generation and build system
https://bugs.webkit.org/show_bug.cgi?id=149751
Reviewed by Darin Adler.
* generate-js-builtins: updating the part related to WebCore JS binding.
2015-10-08 Filip Pizlo <fpizlo@apple.com>
DFG SSA should remove unreachable code
https://bugs.webkit.org/show_bug.cgi?id=149931
Reviewed by Geoffrey Garen.
Rolled back in with a call to m_state.reset(), which fixes the debug asserts.
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::run): Remove unreachable code.
* dfg/DFGObjectAllocationSinkingPhase.cpp: Deal with the CFG changing.
* dfg/DFGPutStackSinkingPhase.cpp: Deal with the CFG changing.
2015-10-08 Daniel Bates <dabates@apple.com>
Add LLVM binaries for iOS 9 device
https://bugs.webkit.org/show_bug.cgi?id=149913
Reviewed by Filip Pizlo.
Look for locally built/binary dropped LLVM headers and libraries when building for iOS device
in WebKitBuild/usr/local.
Currently Mac and iOS look for the locally built/binary dropped LLVM in different directories:
WebKitBuild/usr/local and /usr/local/LLVMForJavaScriptCore, respectively. This difference is
due to dependencies with the Apple internal build system. We should look to resolve the
Apple internal dependencies and standardize on one location for both platforms.
* Configurations/Base.xcconfig:
2015-10-08 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r190749.
https://bugs.webkit.org/show_bug.cgi?id=149938
Caused 50+ layout test failures
https://build.webkit.org/results/Apple%20El%20Capitan%20Debug%20WK1%20(Tests)/r190749%20(213)/results.html
(Requested by litherum1 on #webkit).
Reverted changeset:
"DFG SSA should remove unreachable code"
https://bugs.webkit.org/show_bug.cgi?id=149931
http://trac.webkit.org/changeset/190749
2015-10-08 Filip Pizlo <fpizlo@apple.com>
DFG SSA should remove unreachable code
https://bugs.webkit.org/show_bug.cgi?id=149931
Reviewed by Geoffrey Garen.
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::run): Remove unreachable code.
* dfg/DFGObjectAllocationSinkingPhase.cpp: Deal with the CFG changing.
* dfg/DFGPutStackSinkingPhase.cpp: Deal with the CFG changing.
2015-10-08 Joseph Pecoraro <pecoraro@apple.com>
Unreviewed build fix. Missing forward declaration.
* heap/Heap.h:
2015-10-08 Saam barati <sbarati@apple.com>
Unreviewed Cloop build fix after bug: https://bugs.webkit.org/show_bug.cgi?id=149601
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::newExceptionHandlingCallSiteIndex):
* jit/JITCode.cpp:
(JSC::NativeJITCode::addressForCall):
(JSC::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
* jit/JITCode.h:
2015-10-08 Joseph Pecoraro <pecoraro@apple.com>
Clean up Marked classes
https://bugs.webkit.org/show_bug.cgi?id=149853
Reviewed by Darin Adler.
* heap/Heap.h:
Move include here where it is really needed.
* heap/HeapStatistics.cpp:
* heap/HeapStatistics.h:
Simplify includes.
* heap/MarkedAllocator.h:
Add missing copyright header.
* heap/MarkedBlock.cpp:
* heap/MarkedBlock.h:
(JSC::MarkedBlock::needsSweeping):
Remove unused constants. Add some static asserts. Add some `const` ness.
* heap/MarkedSpace.h:
(JSC::MarkedSpace::isIterating):
Update comments to better reflect actual values.
Remove unimplemented method (moved to Heap).
* heap/MarkedSpace.cpp:
(JSC::Free::Free):
(JSC::Free::operator()):
(JSC::Free::returnValue): Deleted.
(JSC::FreeOrShrink::FreeOrShrink):
(JSC::FreeOrShrink::operator()):
(JSC::MarkedSpace::~MarkedSpace):
(JSC::MarkedSpace::shrink):
Replace conditional Functor that was not using return value
with simplified targeted VoidFunctors.
(JSC::Shrink::operator()): Deleted.
Remove unused functor.
* heap/WeakBlock.cpp:
* heap/WeakBlock.h:
* runtime/Options.cpp:
Remove dead code.
2015-10-08 Saam barati <sbarati@apple.com>
We should be able to inline getter/setter calls inside an inline cache even when the SpillRegistersMode is NeedsToSpill
https://bugs.webkit.org/show_bug.cgi?id=149601
Reviewed by Filip Pizlo.
Before, if we had a PolymorphicAccess with and a StructureStubInfo
with a NeedToSpill spillMode, we wouldn't generate getter/setter
calls. This patch changes it such that we will generate the
getter/setter call and do the necessary register spilling/filling
around the getter/setter call to preserve any "usedRegisters".
This has an interesting story with how it relates to exception handling
inside the DFG. Because the GetById variants are considered a throwing call
site, we must make sure that we properly restore the registers spilled to the stack
in case of an exception being thrown inside the getter/setter call. We do
this by having the inline cache register itself as a new exception handling
call site. When the inline cache "catches" the exception (i.e, genericUnwind
will jump to this code), it will restore the registers it spilled that are
live inside the original catch handler, and then jump to the original catch
handler. We make sure to only generate this makeshift catch handler when we
actually need to do any cleanup. If we determine that we don't need to restore
any registers, we don't bother generating this makeshift catch handler.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::~CodeBlock):
(JSC::CodeBlock::handlerForIndex):
(JSC::CodeBlock::newExceptionHandlingCallSiteIndex):
(JSC::CodeBlock::removeExceptionHandlerForCallSite):
(JSC::CodeBlock::lineNumberForBytecodeOffset):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::appendExceptionHandler):
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessGenerationState::AccessGenerationState):
(JSC::AccessGenerationState::restoreScratch):
(JSC::AccessGenerationState::succeed):
(JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
(JSC::AccessGenerationState::preserveLiveRegistersToStackForCall):
(JSC::AccessGenerationState::restoreLiveRegistersFromStackForCall):
(JSC::AccessGenerationState::restoreLiveRegistersFromStackForCallWithThrownException):
(JSC::AccessGenerationState::liveRegistersForCall):
(JSC::AccessGenerationState::callSiteIndexForExceptionHandlingOrOriginal):
(JSC::AccessGenerationState::callSiteIndexForExceptionHandling):
(JSC::AccessGenerationState::originalExceptionHandler):
(JSC::AccessGenerationState::numberOfStackBytesUsedForRegisterPreservation):
(JSC::AccessGenerationState::needsToRestoreRegistersIfException):
(JSC::AccessGenerationState::originalCallSiteIndex):
(JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite):
(JSC::AccessCase::AccessCase):
(JSC::AccessCase::generate):
(JSC::PolymorphicAccess::regenerateWithCases):
(JSC::PolymorphicAccess::regenerate):
(JSC::PolymorphicAccess::aboutToDie):
* bytecode/PolymorphicAccess.h:
(JSC::AccessCase::doesCalls):
(JSC::AccessCase::isGetter):
(JSC::AccessCase::callLinkInfo):
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::deref):
(JSC::StructureStubInfo::aboutToDie):
(JSC::StructureStubInfo::addAccessCase):
* bytecode/StructureStubInfo.h:
* bytecode/ValueRecovery.h:
(JSC::ValueRecovery::isInJSValueRegs):
(JSC::ValueRecovery::fpr):
* dfg/DFGCommonData.cpp:
(JSC::DFG::CommonData::addCodeOrigin):
(JSC::DFG::CommonData::addCodeOriginUnconditionally):
(JSC::DFG::CommonData::lastCallSite):
(JSC::DFG::CommonData::removeCallSiteIndex):
(JSC::DFG::CommonData::shrinkToFit):
* dfg/DFGCommonData.h:
* dfg/DFGJITCode.cpp:
(JSC::DFG::JITCode::reconstruct):
(JSC::DFG::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
(JSC::DFG::JITCode::checkIfOptimizationThresholdReached):
* dfg/DFGJITCode.h:
(JSC::DFG::JITCode::osrEntryBlock):
(JSC::DFG::JITCode::setOSREntryBlock):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::appendExceptionHandlingOSRExit):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::OSRExit):
* dfg/DFGOSRExit.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileIn):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetById):
(JSC::DFG::SpeculativeJIT::cachedPutById):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetById):
(JSC::DFG::SpeculativeJIT::cachedPutById):
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::validateReferences):
(JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
* ftl/FTLJITCode.h:
(JSC::FTL::JITCode::handles):
(JSC::FTL::JITCode::dataSections):
* jit/GCAwareJITStubRoutine.cpp:
(JSC::GCAwareJITStubRoutine::GCAwareJITStubRoutine):
(JSC::GCAwareJITStubRoutine::~GCAwareJITStubRoutine):
(JSC::GCAwareJITStubRoutine::observeZeroRefCount):
(JSC::MarkingGCAwareJITStubRoutineWithOneObject::markRequiredObjectsInternal):
(JSC::GCAwareJITStubRoutineWithExceptionHandler::GCAwareJITStubRoutineWithExceptionHandler):
(JSC::GCAwareJITStubRoutineWithExceptionHandler::aboutToDie):
(JSC::GCAwareJITStubRoutineWithExceptionHandler::~GCAwareJITStubRoutineWithExceptionHandler):
(JSC::createJITStubRoutine):
* jit/GCAwareJITStubRoutine.h:
* jit/JITCode.cpp:
(JSC::NativeJITCode::addressForCall):
(JSC::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
* jit/JITCode.h:
* jit/JITInlineCacheGenerator.cpp:
(JSC::JITByIdGenerator::JITByIdGenerator):
(JSC::JITGetByIdGenerator::JITGetByIdGenerator):
(JSC::JITPutByIdGenerator::JITPutByIdGenerator):
* jit/JITInlineCacheGenerator.h:
(JSC::JITByIdGenerator::reportSlowPathCall):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitGetByValWithCachedId):
(JSC::JIT::emitPutByValWithCachedId):
(JSC::JIT::emit_op_get_by_id):
(JSC::JIT::emit_op_put_by_id):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emitGetByValWithCachedId):
(JSC::JIT::emitPutByValWithCachedId):
(JSC::JIT::emit_op_get_by_id):
(JSC::JIT::emit_op_put_by_id):
* jit/JITStubRoutine.h:
(JSC::JITStubRoutine::createSelfManagedRoutine):
(JSC::JITStubRoutine::aboutToDie):
* jit/RegisterSet.cpp:
(JSC::RegisterSet::webAssemblyCalleeSaveRegisters):
(JSC::RegisterSet::registersToNotSaveForCall):
(JSC::RegisterSet::allGPRs):
* jit/RegisterSet.h:
(JSC::RegisterSet::set):
(JSC::RegisterSet::clear):
* jit/ScratchRegisterAllocator.cpp:
(JSC::ScratchRegisterAllocator::allocateScratchGPR):
(JSC::ScratchRegisterAllocator::allocateScratchFPR):
(JSC::ScratchRegisterAllocator::preserveReusedRegistersByPushing):
(JSC::ScratchRegisterAllocator::restoreReusedRegistersByPopping):
(JSC::ScratchRegisterAllocator::usedRegistersForCall):
(JSC::ScratchRegisterAllocator::preserveUsedRegistersToScratchBufferForCall):
(JSC::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBufferForCall):
(JSC::ScratchRegisterAllocator::preserveRegistersToStackForCall):
(JSC::ScratchRegisterAllocator::restoreRegistersFromStackForCall):
* jit/ScratchRegisterAllocator.h:
(JSC::ScratchRegisterAllocator::numberOfReusedRegisters):
(JSC::ScratchRegisterAllocator::usedRegisters):
* jsc.cpp:
(WTF::CustomGetter::CustomGetter):
(WTF::CustomGetter::createStructure):
(WTF::CustomGetter::create):
(WTF::CustomGetter::getOwnPropertySlot):
(WTF::CustomGetter::customGetter):
(WTF::Element::handleOwner):
(GlobalObject::finishCreation):
(functionCreateImpureGetter):
(functionCreateCustomGetterObject):
(functionSetImpureGetterDelegate):
* tests/stress/try-catch-custom-getter-as-get-by-id.js: Added.
(assert):
(bar):
(foo):
* tests/stress/try-catch-getter-as-get-by-id-register-restoration.js: Added.
(assert):
(o1.get f):
(bar):
(foo):
* tests/stress/try-catch-getter-as-get-by-id.js: Added.
(assert):
(o1.get f):
(bar):
(foo):
* tests/stress/try-catch-setter-as-put-by-id.js: Added.
(assert):
(o1.set f):
(bar):
(foo):
* tests/stress/try-catch-stub-routine-replaced.js: Added.
(assert):
(arr):
(hello):
(foo):
(objChain.get f):
(fakeOut.get f):
(o.get f):
2015-10-08 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r190716.
https://bugs.webkit.org/show_bug.cgi?id=149924
broke mac build from time to time (Requested by youenn on
#webkit).
Reverted changeset:
"Automate WebCore JS builtins generation and build system"
https://bugs.webkit.org/show_bug.cgi?id=149751
http://trac.webkit.org/changeset/190716
2015-10-08 Csaba Osztrogonác <ossy@webkit.org>
Fix the WASM build on Linux
https://bugs.webkit.org/show_bug.cgi?id=149919
Reviewed by Mark Lam.
* inspector/ScriptCallStackFactory.cpp:
* wasm/JSWASMModule.cpp:
* wasm/WASMFunctionCompiler.h:
(JSC::sizeOfMemoryType):
* wasm/WASMFunctionLLVMIRGenerator.h:
2015-10-08 Csaba Osztrogonác <ossy@webkit.org>
Unreviewed CLOOP buildfix after r190718.
* jit/Repatch.h:
(JSC::resetGetByID): Deleted.
(JSC::resetPutByID): Deleted.
(JSC::resetIn): Deleted.
2015-10-08 Joseph Pecoraro <pecoraro@apple.com>
Remove references to removed class RepatchBuffer
https://bugs.webkit.org/show_bug.cgi?id=149909
Reviewed by Csaba Osztrogonác.
* assembler/AbstractMacroAssembler.h:
* assembler/MacroAssemblerARM.h:
* assembler/MacroAssemblerARM64.h:
* assembler/MacroAssemblerARMv7.h:
* assembler/MacroAssemblerMIPS.h:
* assembler/MacroAssemblerSH4.h:
* assembler/MacroAssemblerX86.h:
* assembler/MacroAssemblerX86_64.h:
* jit/JITStubRoutine.h:
* jit/Repatch.h:
2015-10-08 Xabier Rodriguez Calvar <calvaris@igalia.com> and Youenn Fablet <youenn.fablet@crf.canon.fr>
Automate WebCore JS builtins generation and build system
https://bugs.webkit.org/show_bug.cgi?id=149751
Reviewed by Darin Adler.
* generate-js-builtins: updating the part related to WebCore JS binding.
2015-10-07 Joseph Pecoraro <pecoraro@apple.com>
Clean up Copied classes
https://bugs.webkit.org/show_bug.cgi?id=149863
Reviewed by Saam Barati.
* heap/CopiedAllocator.h:
(JSC::CopiedAllocator::isValid):
* heap/CopiedBlock.h:
* heap/CopiedBlockInlines.h:
* heap/CopiedSpace.cpp:
* heap/CopiedSpace.h:
(JSC::CopiedSpace::isInCopyPhase):
(JSC::CopiedSpace::shouldDoCopyPhase):
* heap/CopiedSpaceInlines.h:
* heap/CopyToken.h:
* heap/CopyVisitor.cpp:
* heap/CopyVisitor.h:
* heap/CopyVisitorInlines.h:
* heap/CopyWorkList.h:
* heap/HandleBlock.h:
* heap/HandleSet.h:
* heap/HeapHelperPool.cpp:
* heap/HeapHelperPool.h:
2015-10-07 Mark Lam <mark.lam@apple.com>
[Follow up 2] Disable tail calls because it is breaking some sites.
https://bugs.webkit.org/show_bug.cgi?id=149900
Rubber stamped by Saam Barati.
Also need to surpress JSC tail call tests.
* tests/es6.yaml:
* tests/stress/dfg-tail-calls.js:
(nonInlinedTailCall.callee):
* tests/stress/mutual-tail-call-no-stack-overflow.js:
(shouldThrow):
* tests/stress/tail-call-in-inline-cache.js:
(tail):
* tests/stress/tail-call-no-stack-overflow.js:
(shouldThrow):
* tests/stress/tail-call-recognize.js:
(callerMustBeRun):
* tests/stress/tail-call-varargs-no-stack-overflow.js:
(shouldThrow):
2015-10-07 Geoffrey Garen <ggaren@apple.com>
Unreviewed, rolling back in r190450
https://bugs.webkit.org/show_bug.cgi?id=149727
This time for sure?
The cause of the leak was an invalidated compilation.
There was vestigial manual memory management code that eagerly removed
a CodeBlock from the set of CodeBlocks if compilation was invalidated.
That's not cool since we rely on the set of CodeBlocks when we run
destructors.
The fix is to remove the vestigial code.
I ran the leaks, correctness, and performance tests locally and did not
see any problems.
Restored changesets:
"CodeBlock should be a GC object"
https://bugs.webkit.org/show_bug.cgi?id=149727
http://trac.webkit.org/changeset/190450
2015-10-07 Mark Lam <mark.lam@apple.com>
Disable tail calls because it is breaking some sites.
https://bugs.webkit.org/show_bug.cgi?id=149900
Reviewed by Saam Barati.
This is until we fix whatever the breakage is.
* runtime/Options.h:
2015-10-07 Sukolsak Sakshuwong <sukolsak@gmail.com>
Add an LLVM IR generator for WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=149486
Reviewed by Mark Lam.
This patch adds initial support for an LLVM IR generator in WebAssembly
(polyfill-prototype-1 format). All the methods will be implemented in
subsequent patches.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* wasm/WASMFunctionLLVMIRGenerator.h: Added.
(JSC::WASMFunctionLLVMIRGenerator::MemoryAddress::MemoryAddress):
(JSC::WASMFunctionLLVMIRGenerator::startFunction):
(JSC::WASMFunctionLLVMIRGenerator::endFunction):
(JSC::WASMFunctionLLVMIRGenerator::buildSetLocal):
(JSC::WASMFunctionLLVMIRGenerator::buildSetGlobal):
(JSC::WASMFunctionLLVMIRGenerator::buildReturn):
(JSC::WASMFunctionLLVMIRGenerator::buildImmediateI32):
(JSC::WASMFunctionLLVMIRGenerator::buildImmediateF32):
(JSC::WASMFunctionLLVMIRGenerator::buildImmediateF64):
(JSC::WASMFunctionLLVMIRGenerator::buildGetLocal):
(JSC::WASMFunctionLLVMIRGenerator::buildGetGlobal):
(JSC::WASMFunctionLLVMIRGenerator::buildConvertType):
(JSC::WASMFunctionLLVMIRGenerator::buildLoad):
(JSC::WASMFunctionLLVMIRGenerator::buildStore):
(JSC::WASMFunctionLLVMIRGenerator::buildUnaryI32):
(JSC::WASMFunctionLLVMIRGenerator::buildUnaryF32):
(JSC::WASMFunctionLLVMIRGenerator::buildUnaryF64):
(JSC::WASMFunctionLLVMIRGenerator::buildBinaryI32):
(JSC::WASMFunctionLLVMIRGenerator::buildBinaryF32):
(JSC::WASMFunctionLLVMIRGenerator::buildBinaryF64):
(JSC::WASMFunctionLLVMIRGenerator::buildRelationalI32):
(JSC::WASMFunctionLLVMIRGenerator::buildRelationalF32):
(JSC::WASMFunctionLLVMIRGenerator::buildRelationalF64):
(JSC::WASMFunctionLLVMIRGenerator::buildMinOrMaxI32):
(JSC::WASMFunctionLLVMIRGenerator::buildMinOrMaxF64):
(JSC::WASMFunctionLLVMIRGenerator::buildCallInternal):
(JSC::WASMFunctionLLVMIRGenerator::buildCallIndirect):
(JSC::WASMFunctionLLVMIRGenerator::buildCallImport):
(JSC::WASMFunctionLLVMIRGenerator::appendExpressionList):
(JSC::WASMFunctionLLVMIRGenerator::discard):
(JSC::WASMFunctionLLVMIRGenerator::linkTarget):
(JSC::WASMFunctionLLVMIRGenerator::jumpToTarget):
(JSC::WASMFunctionLLVMIRGenerator::jumpToTargetIf):
(JSC::WASMFunctionLLVMIRGenerator::startLoop):
(JSC::WASMFunctionLLVMIRGenerator::endLoop):
(JSC::WASMFunctionLLVMIRGenerator::startSwitch):
(JSC::WASMFunctionLLVMIRGenerator::endSwitch):
(JSC::WASMFunctionLLVMIRGenerator::startLabel):
(JSC::WASMFunctionLLVMIRGenerator::endLabel):
(JSC::WASMFunctionLLVMIRGenerator::breakTarget):
(JSC::WASMFunctionLLVMIRGenerator::continueTarget):
(JSC::WASMFunctionLLVMIRGenerator::breakLabelTarget):
(JSC::WASMFunctionLLVMIRGenerator::continueLabelTarget):
(JSC::WASMFunctionLLVMIRGenerator::buildSwitch):
* wasm/WASMFunctionParser.cpp:
2015-10-07 Filip Pizlo <fpizlo@apple.com>
Get rid of LLInt inline/out-of-line storage helpers, they are unused
https://bugs.webkit.org/show_bug.cgi?id=149892
Reviewed by Mark Lam.
Just killing dead code.
* llint/LowLevelInterpreter.asm:
2015-10-07 Filip Pizlo <fpizlo@apple.com>
Don't setOutOfBounds in JIT code for PutByVal, since the C++ slow path already does it
https://bugs.webkit.org/show_bug.cgi?id=149885
Reviewed by Geoffrey Garen.
This simplifies the slow path code, which will make it easier to put read barriers on all of
the butterflies.
* jit/JITOperations.cpp:
(JSC::getByVal):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitSlow_op_put_by_val):
2015-10-07 Filip Pizlo <fpizlo@apple.com>
Get rid of JIT::compilePutDirectOffset
https://bugs.webkit.org/show_bug.cgi?id=149884
Reviewed by Andreas Kling.
I'm finding more dead code.
* jit/JIT.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitSlow_op_put_by_id):
(JSC::JIT::emitVarInjectionCheck):
(JSC::JIT::compilePutDirectOffset): Deleted.
2015-10-07 Joseph Pecoraro <pecoraro@apple.com>
Heap::isWriteBarrierEnabled is unused
https://bugs.webkit.org/show_bug.cgi?id=149881
Reviewed by Geoffrey Garen.
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::isWriteBarrierEnabled): Deleted.
2015-10-07 Filip Pizlo <fpizlo@apple.com>
JIT::emitGetGlobalProperty/emitPutGlobalProperty are only called from one place
https://bugs.webkit.org/show_bug.cgi?id=149879
Reviewed by Saam Barati.
To simplify my work to insert barriers on loads of the butterfly, I want to reduce the amount
of abstraction we have around code that loads the butterfly.
* jit/JIT.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitLoadWithStructureCheck):
(JSC::JIT::emitGetVarFromPointer):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emitSlow_op_get_from_scope):
(JSC::JIT::emitPutGlobalVariable):
(JSC::JIT::emit_op_put_to_scope):
(JSC::JIT::emitGetGlobalProperty): Deleted.
(JSC::JIT::emitPutGlobalProperty): Deleted.
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emitLoadWithStructureCheck):
(JSC::JIT::emitGetVarFromPointer):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emitSlow_op_get_from_scope):
(JSC::JIT::emitPutGlobalVariable):
(JSC::JIT::emit_op_put_to_scope):
(JSC::JIT::emitGetGlobalProperty): Deleted.
(JSC::JIT::emitPutGlobalProperty): Deleted.
2015-10-07 Filip Pizlo <fpizlo@apple.com>
JIT::compileGetDirectOffset is useless
https://bugs.webkit.org/show_bug.cgi?id=149878
Reviewed by Mark Lam.
Two of the overloads of this method were never called. The other was called only from one
place, in a manner that rendered most of its code dead. This change removes the dead code and
folds the method into its one caller.
* jit/JIT.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emit_op_put_by_val):
(JSC::JIT::compilePutDirectOffset):
(JSC::JIT::emitVarInjectionCheck):
(JSC::JIT::emitGetGlobalProperty):
(JSC::JIT::emitGetVarFromPointer):
(JSC::JIT::compileGetDirectOffset): Deleted.
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::compilePutDirectOffset):
(JSC::JIT::emitVarInjectionCheck):
(JSC::JIT::emitGetGlobalProperty):
(JSC::JIT::emitGetVarFromPointer):
(JSC::JIT::compileGetDirectOffset): Deleted.
2015-10-06 Filip Pizlo <fpizlo@apple.com>
Inline caches should handle out-of-line offsets out-of-line
https://bugs.webkit.org/show_bug.cgi?id=149869
Reviewed by Saam Barati.
If we want to have a concurrent copying GC, then we need a read barrier on copied space
pointers. That makes the convertible load portion of the get_by_id/put_by_id inline caches
rather challenging. Currently we have a load instruction that we can turn into an add
instruction - the add case is when we have an inline offset, and the load case is when we
have an out-of-line offset and we need to load a copied space pointer. But if the load from
copied space requires a barrier, then there is no easy way to convert that back to the inline
case.
This patch removes the convertible load. The inline path of get_by_id/put_by_id only handles
the inline offsets. Out-of-line offsets are now handled using out-of-line stubs.
* bytecode/StructureStubInfo.h:
* ftl/FTLInlineCacheSize.cpp:
(JSC::FTL::sizeOfGetById):
(JSC::FTL::sizeOfPutById):
* jit/JITInlineCacheGenerator.cpp:
(JSC::JITByIdGenerator::finalize):
(JSC::JITByIdGenerator::generateFastPathChecks):
(JSC::JITGetByIdGenerator::JITGetByIdGenerator):
(JSC::JITGetByIdGenerator::generateFastPath):
(JSC::JITPutByIdGenerator::JITPutByIdGenerator):
(JSC::JITPutByIdGenerator::generateFastPath):
* jit/JITInlineCacheGenerator.h:
* jit/Repatch.cpp:
(JSC::repatchByIdSelfAccess):
(JSC::tryCacheGetByID):
(JSC::tryCachePutByID):
* runtime/JSObject.h:
(JSC::JSObject::butterflyTotalSize):
(JSC::indexRelativeToBase):
(JSC::offsetRelativeToBase):
(JSC::maxOffsetRelativeToBase):
(JSC::makeIdentifier):
(JSC::offsetRelativeToPatchedStorage): Deleted.
(JSC::maxOffsetRelativeToPatchedStorage): Deleted.
2015-10-07 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r190664.
https://bugs.webkit.org/show_bug.cgi?id=149877
mac build is sometimes borken due to missing generated header
file (Requested by youenn on #webkit).
Reverted changeset:
"Automate WebCore JS builtins generation and build system"
https://bugs.webkit.org/show_bug.cgi?id=149751
http://trac.webkit.org/changeset/190664
2015-10-07 Xabier Rodriguez Calvar <calvaris@igalia.com> and Youenn Fablet <youenn.fablet@crf.canon.fr>
Automate WebCore JS builtins generation and build system
https://bugs.webkit.org/show_bug.cgi?id=149751
Reviewed by Darin Adler.
* generate-js-builtins: updating the part related to WebCore JS binding.
2015-10-06 Mark Lam <mark.lam@apple.com>
Factoring out op_sub baseline code generation into JITSubGenerator.
https://bugs.webkit.org/show_bug.cgi?id=149600
Reviewed by Geoffrey Garen.
We're going to factor out baseline code generation into snippet generators so
that we can later use them in the DFG and FTL to emit code for to perform the
JS operations where the operand types are predicted to be polymorphic.
We are starting in this patch with the implementation of op_sub.
What was done in this patch:
1. Created JITSubGenerator based on the baseline implementation of op_sub as
expressed in compileBinaryArithOp() and compileBinaryArithOpSlowCase().
I did not attempt to do write a more optimal version of op_sub. I'll
leave that to a later patch.
2. Convert the 32-bit op_sub baseline implementation to use the same
JITSubGenerator which was based on the 64-bit implementation. The
pre-existing 32-bit baseline op_sub had handling for more optimization cases.
However, a benchmark run shows that simply going with the 64-bit version
(foregoing those extra optimizations) did not change the performance.
Also, previously, the 32-bit version was able to move double results directly
into the result location on the stack directly. By using JITSubGenerator,
we now always move that result into a pair of GPRs before storing it into
the stack location.
3. Add some needed emitters to AssemblyHelpers that play nice with JSValueRegs.
* JavaScriptCore.xcodeproj/project.pbxproj:
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::boxDouble):
(JSC::AssemblyHelpers::unboxDouble):
(JSC::AssemblyHelpers::boxBooleanPayload):
* jit/JIT.h:
(JSC::JIT::linkDummySlowCase):
* jit/JITArithmetic.cpp:
(JSC::JIT::compileBinaryArithOp):
(JSC::JIT::compileBinaryArithOpSlowCase):
(JSC::JIT::emitSlow_op_div):
(JSC::JIT::emit_op_sub):
(JSC::JIT::emitSlow_op_sub):
* jit/JITArithmetic32_64.cpp:
(JSC::JIT::emitBinaryDoubleOp):
(JSC::JIT::emit_op_sub): Deleted.
(JSC::JIT::emitSub32Constant): Deleted.
(JSC::JIT::emitSlow_op_sub): Deleted.
* jit/JITInlines.h:
(JSC::JIT::linkSlowCaseIfNotJSCell):
(JSC::JIT::linkAllSlowCasesForBytecodeOffset):
(JSC::JIT::addSlowCase):
(JSC::JIT::emitLoad):
(JSC::JIT::emitGetVirtualRegister):
(JSC::JIT::emitPutVirtualRegister):
* jit/JITSubGenerator.h: Added.
(JSC::JITSubGenerator::JITSubGenerator):
(JSC::JITSubGenerator::generateFastPath):
(JSC::JITSubGenerator::slowPathJumpList):
2015-10-06 Daniel Bates <dbates@webkit.org>
Enable XSLT when building WebKit for iOS using the public iOS SDK
https://bugs.webkit.org/show_bug.cgi?id=149827
Reviewed by Alexey Proskuryakov.
* Configurations/FeatureDefines.xcconfig:
2015-10-05 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r190599.
https://bugs.webkit.org/show_bug.cgi?id=149836
Made perf tests randomly crash (Requested by ap on #webkit).
Reverted changeset:
"GC shouldn't cancel every FTL compilation"
https://bugs.webkit.org/show_bug.cgi?id=149821
http://trac.webkit.org/changeset/190599
2015-10-05 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r190589.
https://bugs.webkit.org/show_bug.cgi?id=149833
Caused lots of leaks, and possibly crashes (Requested by ap on
#webkit).
Reverted changeset:
"Unreviewed, rolling back in r190450"
https://bugs.webkit.org/show_bug.cgi?id=149727
http://trac.webkit.org/changeset/190589
2015-10-05 Geoffrey Garen <ggaren@apple.com>
Remove a few includes from JSGlobalObject.h
https://bugs.webkit.org/show_bug.cgi?id=148004
Reviewed by Saam Barati.
* parser/VariableEnvironment.cpp:
* parser/VariableEnvironment.h:
* runtime/JSGlobalObject.h:
* runtime/JSString.cpp:
(JSC::JSString::createStructure):
(JSC::JSRopeString::RopeBuilder::expand):
* runtime/JSString.h:
(JSC::JSString::canGetIndex):
(JSC::JSString::offsetOfLength):
(JSC::JSString::offsetOfFlags):
(JSC::JSString::createStructure): Deleted.
* runtime/Structure.h:
* runtime/StructureInlines.h:
* runtime/StructureRareDataInlines.h:
2015-10-05 Filip Pizlo <fpizlo@apple.com>
GC shouldn't cancel every FTL compilation
https://bugs.webkit.org/show_bug.cgi?id=149821
Reviewed by Saam Barati.
During one of the CodeBlock GC refactorings, we messed up the GC's compilation cancellation
code. The GC should be able to cancel compilation plans if it determines that the plan will
be DOA. But, prior to this fix, that code was killing every FTL compilation. This happened
because the meaning of CodeBlock::isKnownToBeLiveDuringGC() changed.
It's funny that this didn't show up as a bigger slow-down. Basically, those benchmarks that
GC a lot usually don't rely on good compilation, while those benchmarks that do rely on good
compilation usually don't GC a lot. That's probably why this wasn't super obvious when we
broke it.
This change just changes the cancellation logic so that it only cancels plans if the owning
executable is dead. This is safe; in fact the relevant method would be correct even if it
always returned true. It would also be correct if it always returned false. So, compared to
what we had before we changed isKnownToBeLiveDuringGC(), this new code will cancel fewer
compilations. But, that's better than cancelling every compilation. I've filed a bug and
written a FIXME for investigating ways to resurrect the old behavior:
https://bugs.webkit.org/show_bug.cgi?id=149823
Nonetheless, this change looks like it might be a 1% speed-up on Octane. It improves earley
and gbemu.
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::isKnownToBeLiveDuringGC):
2015-10-05 Sukolsak Sakshuwong <sukolsak@gmail.com>
[Intl] Change the return type of canonicalizeLocaleList() from JSArray* to Vector<String>
https://bugs.webkit.org/show_bug.cgi?id=149807
Reviewed by Benjamin Poulain.
From ECMA-402, 9.2.1, the abstract operation CanonicalizeLocaleList
returns a List of Strings. From the spec, we never modify the result
from CanonicalizeLocaleList(). We never expose it to the user either.
This patch changes the return type of canonicalizeLocaleList() from
JSArray* to Vector<String>. This should ease the workload of the GC and
make the code a bit easier to read.
* runtime/IntlCollatorConstructor.cpp:
(JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
* runtime/IntlObject.cpp:
(JSC::canonicalizeLocaleList):
(JSC::lookupSupportedLocales):
(JSC::bestFitSupportedLocales):
(JSC::supportedLocales):
* runtime/IntlObject.h:
2015-10-01 Geoffrey Garen <ggaren@apple.com>
Unreviewed, rolling back in r190450
https://bugs.webkit.org/show_bug.cgi?id=149727
The cause of the leak was VM shutdown, which happens in workers.
The fix is for CodeBlockSet to participate in lastChanceToFinalize,
since it's responsible for running CodeBlock destructors.
I ran the leaks tests locally and did not see any CodeBlock-related leaks.
Restored changesets:
"CodeBlock should be a GC object"
https://bugs.webkit.org/show_bug.cgi?id=149727
http://trac.webkit.org/changeset/190450
2015-10-03 Filip Pizlo <fpizlo@apple.com>
Allow an object's marking state to track The Three Colors
https://bugs.webkit.org/show_bug.cgi?id=149654
Reviewed by Geoffrey Garen.
I want to make GC marking concurrent (see https://bugs.webkit.org/show_bug.cgi?id=149432).
Concurrent GC require barriers to be executed during certain heap operations. We already have a
generational GC. Generational GCs also need barriers, and we already have those. The generational
GC barrier that we use is the "sticky mark bit" barrier. Ordinarily, mark bits get reset after a
collection. In our collector, there is a secondary mark bit that "sticks" - i.e. it does not get
reset. If the sticky mark bit is set in between two collections, then we know that the object is in
old space. This is sufficient to determine when to put things into remembered sets. Additionally,
the sticky mark bit is actually a tri-state that can also tell us if the object has been placed on
a remembered set.
This is awfully similar to what you want in a concurrent GC. Concurrent GCs typically want writes
to the heap that change the object graph to do different things depending on an object's marking
state, which is usually referred to as its color. White means that the object has never been seen
by the collector. All white objects are presumed dead at the flip. Grey objects are those that are
known to the collector but have not been scanned. Black objects are those that have been scanned,
and will not be scanned again. White is exactly just "not being marked", and both grey and black
mean "marked" - with "black" meaning "marked but not on any worklist". That's quite a bit like the
current "Marked" and "MarkedAndRemembered" states that we have for generational GC.
"MarkedAndRemembered" is a lot like "grey", and "Marked" is a lot like "black".
I want to make a concurrent GC that unifies the generational and concurrent barriers into a single
fast path check. Even better if the two barriers are entirely identical. You can do this using
Pirinen's technique #2 [1], originally due to Guy Steele [2]: when doing o.f=v where o is black and
v is white, turn o grey again. This is like remembering an object, in the sense that our gen GC
"rememberes" o when o is old and v is new. It remembers objects by putting them on the mark stack,
setting the generational state to MarkedAndRemembered, and doing nothing to the primary mark bit.
This makes our concurrent GC approach pretty obvious. We want to use one barrier for concurrent and
generational, and we want to basically keep our current barriers unchanged. The only things missing
are just some small changes to allow the concurrent GC to know precisely when an object is black,
and to know during object visiting if we are visiting the object for the first time during a
collection or a subsequent time due to barrier re-greying (concurrent GC) or barrier remembering
(generational GC). So, this patch does the following:
- Changes the terminology used for the gcData header byte in JSCell. This changes the name of this
to cellState, and introduces a new enumeration called CellState. This new enumeration behaves a
lot like the old GCData did. It has the following members, with the following correspondence to
the old GCData:
OldBlack: this is like Marked, with the exception that we ensure that an object becomes OldBlack
as soon as the object starts to be scanned. Previously, an object might be
MarkedAndRemembered during scanning and we'd turn all MarkedAndRemembered objects into Marked
objects during a post-processing step at the end of GC. This patch gets rid of that
post-processing. The act of visiting an object unconditionally makes it OldBlack. Note that
our definition of "black" is not that the object is done being scanned, but that it is either
being scanned right now or it has already been scanned. This is like a combination of
Siebert's anthracite and black states [3].
NewWhite: this is exactly NotMarked. It's the state that objects get when they are allocated.
It's impossible for an object to return to this state.
OldGrey: the object is on the mark stack and will be scanned at some point in the future. This
also means that this isn't the first time in this cycle that the object has been grey. In an
eden collection, an old object that has been remembered is thought of as being OldGrey, even
if this is the first time during this eden collection that it is grey. That's because an eden
collection must behave "as if" the grey->black transition for old objects magically happened
at the start of GC. Remembered objects are like old objects that underwent a concurrent
barrier re-greying just after the magical old object grey->black transition at the start of
GC. This state is almost exactly like MarkedAndRemembered, except that an object now
transitions from OldGrey to OldBlack at the beginning of visiting, rather than how previously
we transitioned from MarkedAndRemembered to Marked at the bitter end of GC.
NewGray: the object is on the mark stack and will be scanned at some point in the future. This
state has no clear relative in the old state system. It means that the object became grey due
to ordinary marking. Previously, ordinary marking would make the object Marked.
- Removal of the post-processing phase that "clears" the remembered set by moving all remembered
objects to the Marked state. This now happens magically during visiting, as described above.
- SlotVisitor now remembers the state that the object did have just before visiting. While visiting
that object, it's possible to query what the state was. This is used for copy space decisions and
for extra memory usage accounting. We don't want to put the backing store on the copy worklist,
and we don't want to count extra memory usage, if the object was OldGrey at the start of
visiting. Previously, we would be able to just ask if the object was MarkedAndRemembered since
that state wouldn't get cleared until after all marking finished. This change also simplifies
some APIs, because there is no need to pass the JSCell* pointer, since these SlotVisitor methods
no longer ask the cell for its state - instead they use the saved pre-visiting state.
- Removal of a bunch of helpers and abstractions. Previously we had various methods for asking if
an object was "marked" and if an object was "remembered". We had helpers for adjusting these
states, and those helpers would assert that they were being used the right way. This is not very
useful for concurrent GC, since now the set of possible state transitions is much larger. Also,
the previous use of the word "marked" was pretty bad - for example in Heap, "marked" refers to
the primary mark bit (that gets cleared at the flip), while in JSCell, "marked" refers to the
sticky mark bit (that does not get cleared, ever). This change gets rid of a lot of those helpers
and inlines their logic. This actually makes the code easier and more fun to read, since you can
now look at the marking and barrier code and see how that code uses the four CellStates. For
example, it's fun to see that the barrier gets fired for o.f=v exactly when o is OldBlack and v
is NewWhite.
This change shouldn't have any effect on performance or GC behavior. It does put our code in a
weird state where we now have states and comments referencing a concurrent GC that doesn't exist
yet.
Finally, some thoughts about the concurrent GC barrier and its implications for performance. This
barrier exhibits very poor guarantees about collector progress, but maximizes throughput by just
reusing the existing barrier code we already emit and optimize. I believe that even our epoch-based
barrier insertion DFG phase is correct for the concurrent interpretation of our existing barrier.
But, the barrier can regress the progress that the collector has made for two reasons:
Incremental update: you don't want to use this barrier with a black stack, since that would mean
that heap loads of white objects will have to explicitly re-grey the stack. The way you implement
this kind of collector is that collector termination will rescan the stack. Termination is reached
only if the at-termination re-scan greys no objects. This means that the collector is a fixpoint.
Luckily, our collector is already a fixpoint because of opaque roots and structure transitions.
Marking ain't monotonic: normally, once an object is black, it stays that way. In this collector,
black objects may become grey again. I don't have personal experience with such concurrent GCs, but
I suspect that this will basically be fine. Concurrent collections finish pretty quickly, and the
mutator usually touches only a subset of the heap. Only that subset of the heap that the mutator is
touching could be re-greyed. Probably, the GC will have to be hybrid incremental and concurrent,
and towards the end of GC when we do the termination stack re-scan, we can ensure that the
collector does some minimal amount of marking. If the minimal amount of marking done by the
collector is large enough, we can ensure that we reach termination before the mutator can regress
progress. The barrier cannot un-terminate the collector; if the collector reaches termination and
the barrier re-greys an object then it's actually doing a generational remembering rather than a
concurrent re-greying.
That's sort of the cute thing about the barrier - it is exactly a re-greying barrier during GC and
it is exactly a remembering barrier in between GCs.
[1] http://www.cs.utexas.edu/ftp/garbage/submit/readable/ppirinen11.ps
[2] http://dl.acm.org/citation.cfm?id=361005
[3] http://www.aicas.com/papers/ISMM132-siebert.pdf
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::visitChildren):
* ftl/FTLAbstractHeapRepository.cpp:
(JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::masqueradesAsUndefinedWatchpointIsStillValid):
(JSC::FTL::DFG::LowerDFGToLLVM::loadCellState):
(JSC::FTL::DFG::LowerDFGToLLVM::emitStoreBarrier):
(JSC::FTL::DFG::LowerDFGToLLVM::loadMarkByte): Deleted.
* heap/CellState.h: Added.
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
* heap/CopiedBlock.h:
* heap/CopiedBlockInlines.h:
(JSC::CopiedBlock::reportLiveBytes):
(JSC::CopiedBlock::shouldReportLiveBytes): Deleted.
* heap/GCLogging.cpp:
(JSC::LoggingFunctor::reviveCells):
* heap/Heap.cpp:
(JSC::Heap::markRoots):
(JSC::Heap::visitWeakHandles):
(JSC::Heap::updateObjectCounts):
(JSC::Heap::addToRememberedSet):
(JSC::Heap::clearRememberedSet): Deleted.
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::isLive):
(JSC::Heap::isMarked):
(JSC::Heap::writeBarrier):
(JSC::Heap::reportExtraMemoryAllocated):
(JSC::Heap::reportExtraMemoryVisited):
(JSC::Heap::isRemembered): Deleted.
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::append):
(JSC::SlotVisitor::visitChildren):
(JSC::SlotVisitor::donateKnownParallel):
(JSC::SlotVisitor::drain):
(JSC::visitChildren): Deleted.
* heap/SlotVisitor.h:
(JSC::SlotVisitor::childCount):
(JSC::SlotVisitor::incrementChildCount):
(JSC::SlotVisitor::dataBeforeVisitingCurrentObject):
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::internalAppend):
(JSC::SlotVisitor::copyLater):
(JSC::SlotVisitor::reportExtraMemoryVisited):
(JSC::SlotVisitor::heap):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::jumpIfIsRememberedOrInEden):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/JSCell.h:
(JSC::JSCell::cellState):
(JSC::JSCell::setCellState):
(JSC::JSCell::structureIDOffset):
(JSC::JSCell::indexingTypeOffset):
(JSC::JSCell::cellStateOffset):
(JSC::JSCell::setMarked): Deleted.
(JSC::JSCell::setRemembered): Deleted.
(JSC::JSCell::isMarked): Deleted.
(JSC::JSCell::isRemembered): Deleted.
(JSC::JSCell::gcDataOffset): Deleted.
* runtime/JSCellInlines.h:
(JSC::JSCell::JSCell):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
* runtime/JSObject.cpp:
(JSC::JSObject::copyBackingStore):
* runtime/JSString.cpp:
(JSC::JSString::visitChildren):
* runtime/StructureIDBlob.h:
(JSC::StructureIDBlob::StructureIDBlob):
(JSC::StructureIDBlob::operator=):
* runtime/WeakMapData.cpp:
(JSC::WeakMapData::visitChildren):
(JSC::WeakMapData::set):
* tests/stress/basic-eden-gc-test.js: Added.
Hilariously, an earlier version of this patch that didn't have the NewGrey/OldGrey distinction
would only crash super-big tests that GCd twice but it didn't crash any small focused test. All
it took to show the need for the NewGrey/OldGrey distinction was this super simple test.
2015-10-05 Geoffrey Garen <ggaren@apple.com>
JSC::SlotVisitor should not be a hot mess
https://bugs.webkit.org/show_bug.cgi?id=149798
Reviewed by Andreas Kling.
I had to debug JSC::SlotVisitor the other day. It was hard to follow.
Let's make it easy to follow.
* heap/Heap.cpp:
(JSC::Heap::markRoots):
(JSC::Heap::resetVisitors):
(JSC::Heap::objectCount):
(JSC::Heap::addToRememberedSet):
(JSC::Heap::collectAndSweep):
* heap/Heap.h: Deleted the string hash-consing code. It
was dead code.
Since no benchmark noticed the commit that broke this feature, perhaps
it's not worth having.
Either way, the best thing to do with dead code is to delete it.
It's still there in svn if we ever want to pick it up again.
* heap/HeapRootVisitor.h:
(JSC::HeapRootVisitor::visit):
(JSC::HeapRootVisitor::visitor): Removed the private append functions
for unsafe pointers and switched HeapRootVisitor over to the public
specially named functions for unsafe pointers.
In future, we should either remove the public specially named functions
or remove HeapRootVisitor, since they serve the same purpose. At least
for now we don't have pairs of functions on SlotVisitor that do the
exact same thing.
* heap/SlotVisitor.cpp:
(JSC::validate): Moved this static function to the top of the file.
(JSC::SlotVisitor::SlotVisitor):
(JSC::SlotVisitor::didStartMarking):
(JSC::SlotVisitor::reset): More hash cons removal.
(JSC::SlotVisitor::append):
(JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
(JSC::SlotVisitor::appendToMarkStack): Renamed these functions to
distinguish them from the up-front helper functions that just do type
conversions. These are the functions that actually do stuff.
Moved these functions out of line to make it easier to set breakpoints,
and to enable code changes for debugging, like printf and synchronous
marking, without recompiling the world.
setMarkedAndAppendToMarkStack is roughly 258 bytes long (not including
function prologue and epilogue), so inlining it was probably not a
great idea in the first place.
(JSC::SlotVisitor::donateKnownParallel):
(JSC::SlotVisitor::drain):
(JSC::SlotVisitor::drainFromShared): Removed some stack probing code.
It was also dead.
(JSC::SlotVisitor::addOpaqueRoot):
(JSC::SlotVisitor::containsOpaqueRoot):
(JSC::SlotVisitor::containsOpaqueRootTriState):
(JSC::SlotVisitor::opaqueRootCount):
(JSC::SlotVisitor::mergeOpaqueRootsIfNecessary):
(JSC::SlotVisitor::mergeOpaqueRootsIfProfitable):
(JSC::SlotVisitor::donate):
(JSC::SlotVisitor::donateAndDrain):
(JSC::SlotVisitor::copyLater):
(JSC::SlotVisitor::mergeOpaqueRoots):
(JSC::SlotVisitor::harvestWeakReferences):
(JSC::SlotVisitor::finalizeUnconditionalFinalizers):
(JSC::SlotVisitor::dump): Moved more code out-of-line. These code paths
are not hot and/or not small, so we need more evidence before we inline
them. The SlotVisitor headers are included everywhere, so we should
make them include less.
Removed "internal" from all function names because it wasn't applied in
any consistent way that would mean anything.
(JSC::JSString::tryHashConsLock): Deleted.
(JSC::JSString::releaseHashConsLock): Deleted.
(JSC::JSString::shouldTryHashCons): Deleted.
(JSC::SlotVisitor::internalAppend): Deleted.
(JSC::SlotVisitor::validate): Deleted.
* heap/SlotVisitor.h:
(JSC::SlotVisitor::resetChildCount): Deleted.
(JSC::SlotVisitor::childCount): Deleted.
(JSC::SlotVisitor::incrementChildCount): Deleted. Removed this child
count thing. It was dead code.
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::appendUnbarrieredPointer):
(JSC::SlotVisitor::appendUnbarrieredReadOnlyPointer):
(JSC::SlotVisitor::appendUnbarrieredValue):
(JSC::SlotVisitor::appendUnbarrieredReadOnlyValue): Some renaming and un-inlining.
(JSC::SlotVisitor::appendUnbarrieredWeak): Don't null check our input.
The one true place where null checking happens is our out-of-line
code. All inline functions do only type conversions.
(JSC::SlotVisitor::append):
(JSC::SlotVisitor::appendValues):
(JSC::SlotVisitor::addWeakReferenceHarvester):
(JSC::SlotVisitor::addUnconditionalFinalizer):
(JSC::SlotVisitor::reportExtraMemoryVisited): Some renaming and un-inlining.
(JSC::SlotVisitor::internalAppend): Deleted.
(JSC::SlotVisitor::unconditionallyAppend): Deleted.
(JSC::SlotVisitor::addOpaqueRoot): Deleted.
(JSC::SlotVisitor::containsOpaqueRoot): Deleted.
(JSC::SlotVisitor::containsOpaqueRootTriState): Deleted.
(JSC::SlotVisitor::opaqueRootCount): Deleted.
(JSC::SlotVisitor::mergeOpaqueRootsIfNecessary): Deleted.
(JSC::SlotVisitor::mergeOpaqueRootsIfProfitable): Deleted.
(JSC::SlotVisitor::donate): Deleted.
(JSC::SlotVisitor::donateAndDrain): Deleted.
(JSC::SlotVisitor::copyLater): Deleted.
* runtime/JSString.h:
(JSC::JSString::finishCreation):
(JSC::JSString::setIs8Bit):
(JSC::JSString::isHashConsSingleton): Deleted.
(JSC::JSString::clearHashConsSingleton): Deleted.
(JSC::JSString::setHashConsSingleton): Deleted. More hash cons removal.
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
(JSC::VM::currentThreadIsHoldingAPILock):
(JSC::VM::apiLock):
(JSC::VM::haveEnoughNewStringsToHashCons): Deleted.
(JSC::VM::resetNewStringsSinceLastHashCons): Deleted. More hash cons removal.
2015-10-04 Filip Pizlo <fpizlo@apple.com>
Inline cache repatching should be throttled if it happens a lot
https://bugs.webkit.org/show_bug.cgi?id=149796
rdar://problem/22674436
Reviewed by Saam Barati.
We noticed a slight PLT regression from http://trac.webkit.org/changeset/189586. It's because
some pages do things that our inline caches mishandle, in the sense that some ICs end up
repatching themselves very frequently. The cost of repatching outweighs the speed-up on those
pages. There are probably super smart things we could do to tune the IC heuristics to make the
ICs do the right thing on those pages. But more fundamentally, we should ensure that our ICs
back off from continuous repatching if they repatch a lot. That's what this change does.
With this change, StructureStubInfo counts the number of repatchings. If that exceeds a
threshold, we put the IC into a cool-down mode, where some number of future repatch events do
nothing but decrement the cool-down counter. The duration of cool-down increases exponentially
every time we have to do it.
This change also outlines a lot of code. The fact that StructureStubInfo had a lot of inline
methods was starting to get on my nerves. Now it only has inline methods for things that need
to be inlined. Also, I changed StructureStubInfo to be a class rather than a struct. Maybe
with enough such incremental changes, eventually StructureStubInfo will actually behave like a
proper class.
This has no effect on JSC benchmarks. It progresses one of the pages that was hit by the
regression by 15%. It's hard to see if this totally fixes the entire PLT regression since the
geomean regression was very close to noise.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::printGetByIdCacheStatus):
(JSC::CodeBlock::printPutByIdCacheStatus):
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::checkIfOptimizationThresholdReached):
* bytecode/CodeBlock.h:
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::GetByIdStatus::computeFor):
* bytecode/PolymorphicAccess.cpp:
(JSC::PolymorphicAccess::regenerate):
* bytecode/PolymorphicAccess.h:
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeForStubInfo):
* bytecode/StructureStubClearingWatchpoint.h:
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::StructureStubInfo):
(JSC::StructureStubInfo::~StructureStubInfo):
(JSC::StructureStubInfo::initGetByIdSelf):
(JSC::StructureStubInfo::initPutByIdReplace):
(JSC::StructureStubInfo::initStub):
(JSC::StructureStubInfo::deref):
(JSC::StructureStubInfo::addAccessCase):
* bytecode/StructureStubInfo.h:
(JSC::StructureStubInfo::considerCaching):
(JSC::StructureStubInfo::willRepatch):
(JSC::StructureStubInfo::willCoolDown):
(JSC::getStructureStubInfoCodeOrigin):
(JSC::StructureStubInfo::StructureStubInfo): Deleted.
(JSC::StructureStubInfo::initGetByIdSelf): Deleted.
(JSC::StructureStubInfo::initPutByIdReplace): Deleted.
(JSC::StructureStubInfo::initStub): Deleted.
(JSC::StructureStubInfo::seenOnce): Deleted.
(JSC::StructureStubInfo::setSeen): Deleted.
* jit/JIT.h:
* jit/JITOperations.cpp:
* jit/Repatch.cpp:
(JSC::tryCacheGetByID):
(JSC::tryCachePutByID):
(JSC::tryRepatchIn):
* runtime/Options.h:
2015-10-04 Filip Pizlo <fpizlo@apple.com>
CodeBlock.h shouldn't be included from everywhere
https://bugs.webkit.org/show_bug.cgi?id=149785
Reviewed by Andreas Kling.
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:
* dfg/DFGAdaptiveStructureWatchpoint.cpp:
* interpreter/CallFrame.cpp:
(JSC::CallFrame::callSiteBitsAreBytecodeOffset):
(JSC::CallFrame::callSiteBitsAreCodeOriginIndex):
(JSC::CallFrame::callSiteAsRawBits):
(JSC::CallFrame::callSiteIndex):
(JSC::CallFrame::hasActivation):
(JSC::CallFrame::uncheckedActivation):
(JSC::CallFrame::stack):
* interpreter/CallFrameInlines.h: Removed.
* interpreter/Interpreter.cpp:
* interpreter/StackVisitor.cpp:
* runtime/DirectArguments.cpp:
* runtime/ErrorInstance.cpp:
* runtime/JSArray.cpp:
* runtime/JSCInlines.h:
* runtime/LiteralParser.cpp:
* runtime/NullSetterFunction.cpp:
* tools/JSDollarVMPrototype.cpp:
2015-10-03 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r190522.
https://bugs.webkit.org/show_bug.cgi?id=149787
Caused a lot of leaks (Requested by ap on #webkit).
Reverted changeset:
"Unreviewed, rolling back in r190450"
https://bugs.webkit.org/show_bug.cgi?id=149727
http://trac.webkit.org/changeset/190522
2015-10-02 Matt Baker <mattbaker@apple.com>
Web Inspector: Add breakpoint option to ignore n times before stopping
https://bugs.webkit.org/show_bug.cgi?id=147664
Reviewed by Timothy Hatcher.
* debugger/Breakpoint.h:
(JSC::Breakpoint::Breakpoint):
Added ignoreCount and hitCount fields. Cleaned up initializers.
* debugger/Debugger.cpp:
(JSC::Debugger::hasBreakpoint):
If a breakpoint matches the current text position, increment breakpoint hit count and
compare with ignore count before testing the breakpoint condition.
* inspector/ScriptBreakpoint.h:
(Inspector::ScriptBreakpoint::ScriptBreakpoint):
Added ignoreCount field. Cleaned up initializers.
* inspector/ScriptDebugServer.cpp:
(Inspector::ScriptDebugServer::setBreakpoint):
Added ignoreCount field.
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::buildObjectForBreakpointCookie):
(Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
(Inspector::InspectorDebuggerAgent::setBreakpoint):
(Inspector::InspectorDebuggerAgent::continueToLocation):
(Inspector::InspectorDebuggerAgent::didParseSource):
Plumbing for ignoreCount property.
* inspector/protocol/Debugger.json:
Added optional ignoreCount property to BreakpointOptions object.
2015-10-02 Filip Pizlo <fpizlo@apple.com> and Mark Lam <mark.lam@apple.com>
We should not add InferredTypeTables to old Structures
https://bugs.webkit.org/show_bug.cgi?id=149767
rdar://problem/22825526
Reviewed by Saam Barati.
Our property type inference has an optimization where the absence of an InferredTypeTable is
taken to mean that all properties are TOP. This is great because most Structures come into
existence through reflective stores, and we don't want to waste time inferring types for
those.
But our code was not obeying this rule properly. If we were doing a transition, we would
assume that this meant that we were creating a new structure, and so we would give it an
InferredTypeTable if we were doing a non-reflective store (i.e. context = PutById). But that
same structure could already have been in use prior to us giving it an InferredTypeTable. At
that point bad things will start to happen because the objects created before we created the
table, and the inline caches compiled before then, will have types that disagree with the new
objects and inline caches despite them sharing the same structure and property names.
* runtime/JSObject.h:
(JSC::JSObject::putDirectInternal):
(JSC::JSObject::putDirectWithoutTransition):
* runtime/Structure.h:
* tests/stress/add-inferred-type-table-to-existing-structure.js: Added.
(foo):
(bar):
(baz):
2015-10-02 Joseph Pecoraro <pecoraro@apple.com>
Unreviewed, rolling out r190520, some tests assert / crash.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/Heap.cpp:
(JSC::Heap::willStartCollection): Deleted.
(JSC::Heap::didFinishCollection): Deleted.
* heap/Heap.h:
(JSC::Heap::addObserver): Deleted.
(JSC::Heap::removeObserver): Deleted.
* heap/HeapObserver.h: Removed.
* heap/MarkedSpace.h:
* inspector/InspectorEnvironment.h:
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
(Inspector::JSGlobalObjectInspectorController::vm): Deleted.
* inspector/JSGlobalObjectInspectorController.h:
* inspector/agents/InspectorHeapAgent.cpp: Removed.
* inspector/agents/InspectorHeapAgent.h: Removed.
* inspector/protocol/Heap.json: Removed.
2015-10-01 Geoffrey Garen <ggaren@apple.com>
Unreviewed, rolling back in r190450
https://bugs.webkit.org/show_bug.cgi?id=149727
The cause of the crash was a CodeBlock, after surviving a call to
deleteAllCode by virtue of being in the remembered set, trying to mark
its inlined CodeBlocks via pointers from its inlined executables.
Since deleteAllCode clears those pointers, the CodeBlock would ASSERT.
(Any other choice to retain a CodeBlock after deleteAllCode -- for
example, conservative marking -- could trigger the same bug.)
The fix is for InlineCallFrame to point directly to its inlined CodeBlock
instead of pointing indirectly via an executable. This guarantees that
CodeBlocks are GC safe regardless of whether we've called deleteAllCode.
Restored changesets:
"CodeBlock should be a GC object"
https://bugs.webkit.org/show_bug.cgi?id=149727
http://trac.webkit.org/changeset/190450
2015-10-02 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Include Garbage Collection Event in Timeline
https://bugs.webkit.org/show_bug.cgi?id=142510
Reviewed by Geoffrey Garen.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/HeapObserver.h:
* heap/Heap.cpp:
(JSC::Heap::willStartCollection):
(JSC::Heap::didFinishCollection):
* heap/Heap.h:
(JSC::Heap::addObserver):
(JSC::Heap::removeObserver):
Allow observers on heap to add hooks for starting / ending garbage collection.
* inspector/InspectorEnvironment.h:
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
(Inspector::JSGlobalObjectInspectorController::vm):
* inspector/JSGlobalObjectInspectorController.h:
Access the VM through the InspectorEnvironment as it won't change.
* inspector/agents/InspectorHeapAgent.cpp: Added.
(Inspector::InspectorHeapAgent::InspectorHeapAgent):
(Inspector::InspectorHeapAgent::~InspectorHeapAgent):
(Inspector::InspectorHeapAgent::didCreateFrontendAndBackend):
(Inspector::InspectorHeapAgent::willDestroyFrontendAndBackend):
(Inspector::InspectorHeapAgent::enable):
(Inspector::InspectorHeapAgent::disable):
(Inspector::InspectorHeapAgent::gc):
(Inspector::protocolTypeForHeapOperation):
(Inspector::InspectorHeapAgent::willGarbageCollect):
(Inspector::InspectorHeapAgent::didGarbageCollect):
* inspector/agents/InspectorHeapAgent.h: Added.
* inspector/protocol/Heap.json: Added.
New domain and agent to handle tasks related to the JavaScriptCore heap.
2015-10-01 Geoffrey Garen <ggaren@apple.com>
Unreviewed, rolling out r190450
https://bugs.webkit.org/show_bug.cgi?id=148560
Crashes seen on el cap wk1 bots.
Reverted changesets:
"CodeBlock should be a GC object"
https://bugs.webkit.org/show_bug.cgi?id=149727
http://trac.webkit.org/changeset/190450
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::inferredName):
(JSC::CodeBlock::dumpAssumingJITType):
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::~CodeBlock):
(JSC::CodeBlock::setNumParameters):
(JSC::CodeBlock::specialOSREntryBlockOrNull):
(JSC::CodeBlock::visitStrongly):
(JSC::CodeBlock::visitAggregate):
(JSC::CodeBlock::shouldVisitStrongly):
(JSC::CodeBlock::isKnownToBeLiveDuringGC):
(JSC::CodeBlock::shouldJettisonDueToWeakReference):
(JSC::CodeBlock::shouldJettisonDueToOldAge):
(JSC::CodeBlock::determineLiveness):
(JSC::CodeBlock::visitWeakReferences):
(JSC::CodeBlock::finalizeLLIntInlineCaches):
(JSC::CodeBlock::finalizeBaselineJITInlineCaches):
(JSC::CodeBlock::finalizeUnconditionally):
(JSC::CodeBlock::visitOSRExitTargets):
(JSC::CodeBlock::unlinkIncomingCalls):
(JSC::CodeBlock::linkIncomingCall):
(JSC::CodeBlock::newReplacement):
(JSC::ProgramCodeBlock::replacement):
(JSC::ModuleProgramCodeBlock::replacement):
(JSC::EvalCodeBlock::replacement):
(JSC::FunctionCodeBlock::replacement):
(JSC::ProgramCodeBlock::capabilityLevelInternal):
(JSC::ModuleProgramCodeBlock::capabilityLevelInternal):
(JSC::EvalCodeBlock::capabilityLevelInternal):
(JSC::FunctionCodeBlock::capabilityLevelInternal):
(JSC::WebAssemblyCodeBlock::replacement):
(JSC::WebAssemblyCodeBlock::capabilityLevelInternal):
(JSC::CodeBlock::jettison):
(JSC::CodeBlock::capabilityLevel):
(JSC::FunctionCodeBlock::destroy): Deleted.
(JSC::WebAssemblyCodeBlock::destroy): Deleted.
(JSC::ProgramCodeBlock::destroy): Deleted.
(JSC::ModuleProgramCodeBlock::destroy): Deleted.
(JSC::EvalCodeBlock::destroy): Deleted.
(JSC::CodeBlock::finishCreation): Deleted.
(JSC::CodeBlock::setAlternative): Deleted.
(JSC::CodeBlock::visitWeakly): Deleted.
(JSC::CodeBlock::visitChildren): Deleted.
(JSC::timeToLive): Deleted.
(JSC::CodeBlock::WeakReferenceHarvester::visitWeakReferences): Deleted.
(JSC::CodeBlock::UnconditionalFinalizer::finalizeUnconditionally): Deleted.
(JSC::CodeBlock::replacement): Deleted.
(JSC::CodeBlock::computeCapabilityLevel): Deleted.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::unlinkedCodeBlock):
(JSC::CodeBlock::addressOfNumParameters):
(JSC::CodeBlock::offsetOfNumParameters):
(JSC::CodeBlock::alternative):
(JSC::CodeBlock::setAlternative):
(JSC::CodeBlock::forEachRelatedCodeBlock):
(JSC::CodeBlock::specializationKind):
(JSC::CodeBlock::instructionCount):
(JSC::CodeBlock::setJITCode):
(JSC::CodeBlock::hasBaselineJITProfiling):
(JSC::CodeBlock::capabilityLevelState):
(JSC::CodeBlock::addConstant):
(JSC::CodeBlock::appendExceptionHandler):
(JSC::CodeBlock::setConstantRegisters):
(JSC::CodeBlock::replaceConstant):
(JSC::GlobalCodeBlock::GlobalCodeBlock):
(JSC::ProgramCodeBlock::ProgramCodeBlock):
(JSC::ModuleProgramCodeBlock::ModuleProgramCodeBlock):
(JSC::EvalCodeBlock::EvalCodeBlock):
(JSC::EvalCodeBlock::variable):
(JSC::EvalCodeBlock::numVariables):
(JSC::EvalCodeBlock::unlinkedEvalCodeBlock):
(JSC::FunctionCodeBlock::FunctionCodeBlock):
(JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock):
(JSC::ExecState::uncheckedR):
(JSC::CodeBlock::clearMarks):
(JSC::CodeBlockSet::mark):
(JSC::ScriptExecutable::forEachCodeBlock):
(JSC::ProgramCodeBlock::create): Deleted.
(JSC::ProgramCodeBlock::createStructure): Deleted.
(JSC::ModuleProgramCodeBlock::create): Deleted.
(JSC::ModuleProgramCodeBlock::createStructure): Deleted.
(JSC::EvalCodeBlock::create): Deleted.
(JSC::EvalCodeBlock::createStructure): Deleted.
(JSC::FunctionCodeBlock::create): Deleted.
(JSC::FunctionCodeBlock::createStructure): Deleted.
(JSC::WebAssemblyCodeBlock::create): Deleted.
(JSC::WebAssemblyCodeBlock::createStructure): Deleted.
(JSC::CodeBlock::clearVisitWeaklyHasBeenCalled): Deleted.
* bytecode/DeferredCompilationCallback.cpp:
(JSC::DeferredCompilationCallback::DeferredCompilationCallback):
(JSC::DeferredCompilationCallback::~DeferredCompilationCallback):
(JSC::DeferredCompilationCallback::compilationDidComplete):
* bytecode/DeferredCompilationCallback.h:
* bytecode/EvalCodeCache.h:
(JSC::EvalCodeCache::tryGet):
(JSC::EvalCodeCache::getSlow):
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generate):
(JSC::PolymorphicAccess::regenerate):
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::addAccessCase):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parse):
* dfg/DFGDesiredTransitions.cpp:
(JSC::DFG::DesiredTransition::reallyAdd):
* dfg/DFGDesiredWeakReferences.cpp:
(JSC::DFG::DesiredWeakReferences::reallyAdd):
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::Graph):
* dfg/DFGJITCode.h:
(JSC::DFG::JITCode::osrEntryBlock): Deleted.
(JSC::DFG::JITCode::setOSREntryBlock): Deleted.
(JSC::DFG::JITCode::clearOSREntryBlock): Deleted.
* dfg/DFGJITFinalizer.cpp:
(JSC::DFG::JITFinalizer::finalize):
(JSC::DFG::JITFinalizer::finalizeFunction):
(JSC::DFG::JITFinalizer::finalizeCommon):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::adjustAndJumpToTarget):
* dfg/DFGOperations.cpp:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::Plan):
(JSC::DFG::Plan::reallyAdd):
(JSC::DFG::Plan::notifyReady):
(JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
(JSC::DFG::Plan::finalizeAndNotifyCallback):
(JSC::DFG::Plan::key):
(JSC::DFG::Plan::clearCodeBlockMarks):
(JSC::DFG::Plan::checkLivenessAndVisitChildren):
(JSC::DFG::Plan::rememberCodeBlocks): Deleted.
* dfg/DFGPlan.h:
* dfg/DFGToFTLDeferredCompilationCallback.cpp:
(JSC::DFG::ToFTLDeferredCompilationCallback::ToFTLDeferredCompilationCallback):
(JSC::DFG::ToFTLDeferredCompilationCallback::~ToFTLDeferredCompilationCallback):
(JSC::DFG::ToFTLDeferredCompilationCallback::create):
(JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
(JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidComplete):
* dfg/DFGToFTLDeferredCompilationCallback.h:
* dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
(JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::ToFTLForOSREntryDeferredCompilationCallback):
(JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::~ToFTLForOSREntryDeferredCompilationCallback):
(JSC::DFG::Ref<ToFTLForOSREntryDeferredCompilationCallback>ToFTLForOSREntryDeferredCompilationCallback::create):
(JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
(JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete):
* dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h:
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::completeAllPlansForVM):
(JSC::DFG::Worklist::clearCodeBlockMarks):
(JSC::DFG::completeAllPlansForVM):
(JSC::DFG::clearCodeBlockMarks):
(JSC::DFG::Worklist::rememberCodeBlocks): Deleted.
(JSC::DFG::rememberCodeBlocks): Deleted.
* dfg/DFGWorklist.h:
(JSC::DFG::worklistForIndexOrNull):
* ftl/FTLJITFinalizer.cpp:
(JSC::FTL::JITFinalizer::finalizeFunction):
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::~CodeBlockSet):
(JSC::CodeBlockSet::add):
(JSC::CodeBlockSet::clearMarksForFullCollection):
(JSC::CodeBlockSet::clearMarksForEdenCollection):
(JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
(JSC::CodeBlockSet::remove):
(JSC::CodeBlockSet::traceMarked):
(JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
(JSC::CodeBlockSet::dump):
* heap/CodeBlockSet.h:
* heap/Heap.cpp:
(JSC::Heap::markRoots):
(JSC::Heap::clearLivenessData):
(JSC::Heap::traceCodeBlocksAndJITStubRoutines):
(JSC::Heap::deleteAllCodeBlocks):
(JSC::Heap::deleteAllUnlinkedCodeBlocks):
(JSC::Heap::clearUnmarkedExecutables):
(JSC::Heap::willStartCollection):
* interpreter/Interpreter.cpp:
(JSC::eval):
* jit/GCAwareJITStubRoutine.h:
* jit/JITCode.h:
(JSC::JITCode::isJIT):
(JSC::JITCode::timeToLive):
(JSC::JITCode::isLowerTier):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_enter):
* jit/JITOperations.cpp:
* jit/JITToDFGDeferredCompilationCallback.cpp:
(JSC::JITToDFGDeferredCompilationCallback::create):
(JSC::JITToDFGDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
(JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
* jit/JITToDFGDeferredCompilationCallback.h:
* jit/Repatch.cpp:
(JSC::tryCacheGetByID):
(JSC::tryCachePutByID):
(JSC::tryRepatchIn):
(JSC::linkFor):
(JSC::linkPolymorphicCall):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::setUpCall):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
(JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
* runtime/Executable.cpp:
(JSC::ExecutableBase::clearCode):
(JSC::ScriptExecutable::installCode):
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::ScriptExecutable::newReplacementCodeBlockFor):
(JSC::ScriptExecutable::prepareForExecutionImpl):
(JSC::EvalExecutable::visitChildren):
(JSC::EvalExecutable::clearCode):
(JSC::ProgramExecutable::checkSyntax):
(JSC::ProgramExecutable::visitChildren):
(JSC::ProgramExecutable::clearCode):
(JSC::ModuleProgramExecutable::visitChildren):
(JSC::ModuleProgramExecutable::clearCode):
(JSC::FunctionExecutable::baselineCodeBlockFor):
(JSC::FunctionExecutable::visitChildren):
(JSC::FunctionExecutable::clearCode):
(JSC::FunctionExecutable::fromGlobalCode):
(JSC::WebAssemblyExecutable::visitChildren):
(JSC::WebAssemblyExecutable::clearCode):
(JSC::WebAssemblyExecutable::prepareForExecution):
* runtime/Executable.h:
(JSC::ExecutableBase::generatedJITCodeForCall):
(JSC::ScriptExecutable::prepareForExecution):
(JSC::ExecutableBase::clearCodeVirtual):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2015-10-01 Geoffrey Garen <ggaren@apple.com>
CodeBlock should be a GC object
https://bugs.webkit.org/show_bug.cgi?id=149727
Reviewed by Filip Pizlo.
We want CodeBlock to be a GC object:
(1) Sane write barriers. Because CodeBlock wasn't a GC object, we couldn't
execute a write barrier on it. This caused us to do weird things that
were hard to reason about, like executing a barrier on a related executable
(even though the executable might stop pointing to the CodeBlock before
the next GC), or pretending that an object had written to itself. Now,
when we write to a CodeBlock, we barrier the CodeBlock, and that's that.
(2) Simpler marking and destruction logic. There's no need to have a
custom remembered set or a destruction fixpoint if we just obey normal
GC rules.
* bytecode/CodeBlock.cpp:
(JSC::FunctionCodeBlock::destroy):
(JSC::WebAssemblyCodeBlock::destroy):
(JSC::ProgramCodeBlock::destroy):
(JSC::ModuleProgramCodeBlock::destroy):
(JSC::EvalCodeBlock::destroy): Add ClassInfo and destroy functions
because our GC object model requires them.
Note that we do not set the needsDestruction flag. Since CodeBlock needs
eager destruction, it runs its destructors through CodeBlockSet,
and not through normal object sweeping.
(JSC::CodeBlock::finishCreation): Factor out finishCreation from the
constructor because our GC object model requires it. Change write
barriers to note the CodeBlock as the owner.
(JSC::CodeBlock::~CodeBlock): Refactor to use the shared
unlinkIncomingCalls() function instead of rolling a copy by hand.
(JSC::CodeBlock::visitWeakly): New helper function for owner executables
to do weak marking that might jettison a CodeBlock. Our new GC logic
says that a CodeBlock pointer is a strong reference by default, and
clients need to opt in if they want to allow a CodeBlock to jettison.
This is easier to get right because it means that only those
specific owners that want jettison behavior need to worry about it,
while all other pointers are valid by default.
(JSC::CodeBlock::visitChildren): The default visit function keeps
everything alive.
(JSC::CodeBlock::shouldVisitStrongly):
(JSC::CodeBlock::isKnownToBeLiveDuringGC): No need to keep special state
anymore. If we're marked, we're live -- just like any other object.
(JSC::timeToLive): Move this code into CodeBlock.cpp so you can mess
with it without recompiling, and also because it's really a CodeBlock
policy.
(JSC::CodeBlock::WeakReferenceHarvester::visitWeakReferences):
(JSC::CodeBlock::UnconditionalFinalizer::finalizeUnconditionally): Use
internal objects for virtual callbacks because GC objects can't have
vtables.
(JSC::CodeBlock::unlinkIncomingCalls): Remove a fast path check that does
not exist in the copy of this code in ~CodeBlock because it is not
actually an optimization.
(JSC::CodeBlock::replacement):
(JSC::CodeBlock::computeCapabilityLevel): Make these functions generic
instead of virtual because GC objects can't have vtables.
(JSC::CodeBlock::visitStrongly): Deleted.
(JSC::CodeBlock::visitAggregate): Deleted.
(JSC::CodeBlock::visitWeakReferences): Deleted.
(JSC::CodeBlock::finalizeUnconditionally): Deleted.
(JSC::ProgramCodeBlock::replacement): Deleted.
(JSC::ModuleProgramCodeBlock::replacement): Deleted.
(JSC::EvalCodeBlock::replacement): Deleted.
(JSC::FunctionCodeBlock::replacement): Deleted.
(JSC::ProgramCodeBlock::capabilityLevelInternal): Deleted.
(JSC::ModuleProgramCodeBlock::capabilityLevelInternal): Deleted.
(JSC::EvalCodeBlock::capabilityLevelInternal): Deleted.
(JSC::FunctionCodeBlock::capabilityLevelInternal): Deleted.
(JSC::WebAssemblyCodeBlock::replacement): Deleted.
(JSC::WebAssemblyCodeBlock::capabilityLevelInternal): Deleted.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::unlinkedCodeBlock):
(JSC::CodeBlock::addressOfNumParameters):
(JSC::CodeBlock::offsetOfNumParameters):
(JSC::CodeBlock::alternative):
(JSC::CodeBlock::forEachRelatedCodeBlock):
(JSC::CodeBlock::specializationKind):
(JSC::CodeBlock::instructionCount):
(JSC::CodeBlock::setJITCode):
(JSC::CodeBlock::hasBaselineJITProfiling):
(JSC::CodeBlock::capabilityLevelState):
(JSC::CodeBlock::addConstant):
(JSC::CodeBlock::appendExceptionHandler):
(JSC::CodeBlock::setConstantRegisters):
(JSC::CodeBlock::replaceConstant):
(JSC::GlobalCodeBlock::GlobalCodeBlock):
(JSC::ProgramCodeBlock::create):
(JSC::ProgramCodeBlock::createStructure):
(JSC::ProgramCodeBlock::ProgramCodeBlock):
(JSC::ModuleProgramCodeBlock::create):
(JSC::ModuleProgramCodeBlock::createStructure):
(JSC::ModuleProgramCodeBlock::ModuleProgramCodeBlock):
(JSC::EvalCodeBlock::create):
(JSC::EvalCodeBlock::createStructure):
(JSC::EvalCodeBlock::variable):
(JSC::EvalCodeBlock::numVariables):
(JSC::EvalCodeBlock::EvalCodeBlock):
(JSC::EvalCodeBlock::unlinkedEvalCodeBlock):
(JSC::FunctionCodeBlock::create):
(JSC::FunctionCodeBlock::createStructure):
(JSC::FunctionCodeBlock::FunctionCodeBlock):
(JSC::WebAssemblyCodeBlock::create):
(JSC::WebAssemblyCodeBlock::createStructure):
(JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock):
(JSC::ExecState::uncheckedR):
(JSC::CodeBlock::clearVisitWeaklyHasBeenCalled):
(JSC::CodeBlockSet::mark):
(JSC::ScriptExecutable::forEachCodeBlock):
(JSC::CodeBlock::setAlternative): Deleted.
(JSC::CodeBlock::clearMarks): Deleted. Lots of mechanical changes to
match the logic changes above.
* bytecode/DeferredCompilationCallback.cpp:
(JSC::DeferredCompilationCallback::DeferredCompilationCallback):
(JSC::DeferredCompilationCallback::~DeferredCompilationCallback):
(JSC::DeferredCompilationCallback::compilationDidComplete):
* bytecode/DeferredCompilationCallback.h: Provide a profiledDFGCodeBlock
to all compilation callbacks instead of requiring the callback to
store the profiledDFGCodeBlock. This is how the rest of compilation
around the callback works anyway, and it is easier to do things this
way than to think about how a non-GC malloc'd object should keep its
CodeBlock alive.
* bytecode/EvalCodeCache.h:
(JSC::EvalCodeCache::tryGet):
(JSC::EvalCodeCache::getSlow):
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generate):
(JSC::PolymorphicAccess::regenerate):
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::addAccessCase): Change the owner for write
barrier purposes to CodeBlock.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parse):
* dfg/DFGDesiredTransitions.cpp:
(JSC::DFG::DesiredTransition::reallyAdd):
* dfg/DFGDesiredWeakReferences.cpp:
(JSC::DFG::DesiredWeakReferences::reallyAdd):
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::Graph): Ditto.
* dfg/DFGJITCode.h:
(JSC::DFG::JITCode::osrEntryBlock):
(JSC::DFG::JITCode::setOSREntryBlock):
(JSC::DFG::JITCode::clearOSREntryBlock): Use helper functions for
accessing osrEntryBlock to help with write barrier stuff.
* dfg/DFGJITFinalizer.cpp:
(JSC::DFG::JITFinalizer::finalize):
(JSC::DFG::JITFinalizer::finalizeFunction):
(JSC::DFG::JITFinalizer::finalizeCommon):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::adjustAndJumpToTarget): Use CodeBlock as owner instead of
executable.
* dfg/DFGOperations.cpp:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::Plan):
(JSC::DFG::Plan::reallyAdd):
(JSC::DFG::Plan::notifyReady):
(JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
(JSC::DFG::Plan::finalizeAndNotifyCallback):
(JSC::DFG::Plan::key):
(JSC::DFG::Plan::rememberCodeBlocks):
(JSC::DFG::Plan::checkLivenessAndVisitChildren):
(JSC::DFG::Plan::clearCodeBlockMarks): Deleted.
* dfg/DFGPlan.h: Use normal GC write barrier concepts to model the fact
that the compiler writes to CodeBlocks.
* dfg/DFGToFTLDeferredCompilationCallback.cpp:
(JSC::DFG::ToFTLDeferredCompilationCallback::ToFTLDeferredCompilationCallback):
(JSC::DFG::ToFTLDeferredCompilationCallback::~ToFTLDeferredCompilationCallback):
(JSC::DFG::ToFTLDeferredCompilationCallback::create):
(JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
(JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidComplete):
* dfg/DFGToFTLDeferredCompilationCallback.h:
* dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
(JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::ToFTLForOSREntryDeferredCompilationCallback):
(JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::~ToFTLForOSREntryDeferredCompilationCallback):
(JSC::DFG::Ref<ToFTLForOSREntryDeferredCompilationCallback>ToFTLForOSREntryDeferredCompilationCallback::create):
(JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
(JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete):
* dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h: We always have
a profiledDFGCodeBlock passed to use -- see above.
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::completeAllPlansForVM):
(JSC::DFG::Worklist::rememberCodeBlocks):
(JSC::DFG::completeAllPlansForVM):
(JSC::DFG::rememberCodeBlocks):
(JSC::DFG::Worklist::clearCodeBlockMarks): Deleted.
(JSC::DFG::clearCodeBlockMarks): Deleted.
* dfg/DFGWorklist.h:
(JSC::DFG::worklistForIndexOrNull): Renamed to use remembered set terminology.
* ftl/FTLJITFinalizer.cpp:
(JSC::FTL::JITFinalizer::finalizeFunction):
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::~CodeBlockSet):
(JSC::CodeBlockSet::add):
(JSC::CodeBlockSet::clearMarksForFullCollection):
(JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced): No need for a fixpoint
anymore since the GC can tell us if we are live.
(JSC::CodeBlockSet::remove):
(JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
(JSC::CodeBlockSet::dump):
(JSC::CodeBlockSet::clearMarksForEdenCollection): Deleted. No need for
this logic anymore since the GC will clear our mark bit.
(JSC::CodeBlockSet::traceMarked): Deleted. No need for this marking
fixpoint anymore either.
* heap/CodeBlockSet.h:
* heap/Heap.cpp:
(JSC::Heap::markRoots): Moved some of this logic around to make the
algorithm clearer.
(JSC::Heap::deleteAllCodeBlocks): Deleting CodeBlocks can only clear
pointers immediately; they won't fully delete until the next GC and sweep.
* interpreter/Interpreter.cpp:
(JSC::eval):
* jit/GCAwareJITStubRoutine.h: CodeBlock is owner now.
* jit/JITCode.h:
(JSC::JITCode::isJIT):
(JSC::JITCode::isLowerTier):
(JSC::JITCode::timeToLive): Deleted.
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_enter): CodeBlock is owner now.
* jit/JITOperations.cpp:
* jit/JITToDFGDeferredCompilationCallback.cpp:
(JSC::JITToDFGDeferredCompilationCallback::create):
(JSC::JITToDFGDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
(JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
* jit/JITToDFGDeferredCompilationCallback.h:
* jit/Repatch.cpp:
(JSC::tryCacheGetByID):
(JSC::tryCachePutByID):
(JSC::tryRepatchIn):
(JSC::linkFor):
(JSC::linkPolymorphicCall):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::setUpCall):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
(JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal): CodeBlock is owner now.
* runtime/Executable.cpp:
(JSC::ExecutableBase::clearCode): Provide a generic clearCode() so that
it can be used on any Executable. This fixes a very subtle bug where
deleteAllCode() does not remove CodeBlocks from non-function executables
that have been saved in stack traces.
(JSC::ScriptExecutable::installCode): WriteBarrier requires special
handling for pointers that may be null.
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::ScriptExecutable::newReplacementCodeBlockFor):
(JSC::ScriptExecutable::prepareForExecutionImpl): Update for interface
changes.
(JSC::EvalExecutable::visitChildren):
(JSC::ProgramExecutable::visitChildren):
(JSC::ModuleProgramExecutable::visitChildren):
(JSC::FunctionExecutable::visitChildren):
(JSC::WebAssemblyExecutable::visitChildren): Visit weakly because we want
to participate in jettisoning.
(JSC::WebAssemblyExecutable::prepareForExecution):
(JSC::EvalExecutable::clearCode): Deleted.
(JSC::ProgramExecutable::clearCode): Deleted.
(JSC::ModuleProgramExecutable::clearCode): Deleted.
(JSC::FunctionExecutable::clearCode): Deleted.
(JSC::WebAssemblyExecutable::clearCode): Deleted.
* runtime/Executable.h:
(JSC::ExecutableBase::generatedJITCodeForCall):
(JSC::ScriptExecutable::prepareForExecution):
(JSC::ExecutableBase::clearCodeVirtual): Deleted.
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h: Provide structures because our GC requires it.
2015-10-01 Mark Lam <mark.lam@apple.com>
Remove unnecessary SpecialFastCaseProfiles.
https://bugs.webkit.org/show_bug.cgi?id=149729
Reviewed by Saam Barati.
The current baseline code creates special fast case profiles records for
bytecodes that don't need them. This was done to keep the DFG from crashing when
it searches for such a profile and don't find one. Instead, we will fix the code
to check for the existence of the profile before dereferencing it to get a count.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset):
(JSC::CodeBlock::couldTakeSpecialFastCase):
(JSC::CodeBlock::likelyToTakeDeepestSlowCase):
(JSC::CodeBlock::numberOfArrayProfiles):
(JSC::CodeBlock::arrayProfiles):
(JSC::CodeBlock::addArrayProfile):
(JSC::CodeBlock::likelyToTakeSpecialFastCase): Deleted. Not used.
(JSC::CodeBlock::likelyToTakeAnySlowCase): Deleted. Not used.
* jit/JITArithmetic.cpp:
(JSC::JIT::compileBinaryArithOp):
- Only op_mul needs the profile. So, only allocate it in the op_mul case.
(JSC::JIT::emit_op_mul):
- These op_mul cases create the profile but never increments its counter.
Hence, we can get rid of these.
2015-10-01 Keith Miller <keith_miller@apple.com>
[ES6] Add TypedArray.prototype functionality.
https://bugs.webkit.org/show_bug.cgi?id=148035
Reviewed by Geoffrey Garen.
This patch should add most of the functionality for
the prototype properties of TypedArray objects in ES6.
There are a few exceptions to this, which will be added
in upcoming patches:
1) First we do not use the species constructor for some
of the TypedArray prototype functions (namely: map, filter,
slice, and subarray). That will need to be added when
species constructors are finished.
2) TypedArrays still have a length, byteOffset, byteLength,
and buffer are still attached to the TypedArray instance (in
the spec they are on the TypedArray.prototype instance object)
since the JIT currently assumes those properties are fixed.
3) The TypedArray.constructor property is not added yet
as it should point to the TypedArray instance object,
which will be added in a future patch.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/TypedArray.prototype.js: Added.
(every):
(find):
(findIndex):
(forEach):
(some):
(sort.min):
(sort.merge):
(sort.mergeSort):
(sort):
(reduce):
(reduceRight):
(map):
(filter):
(toLocaleString):
* runtime/ArrayPrototype.cpp:
* runtime/ArrayPrototype.h:
* runtime/CommonIdentifiers.h:
* runtime/JSGenericTypedArrayView.h:
(JSC::JSGenericTypedArrayView::toAdaptorNativeFromValue):
(JSC::JSGenericTypedArrayView::setRangeToValue):
(JSC::JSGenericTypedArrayView::sort):
(JSC::JSGenericTypedArrayView::purifyArray):
(JSC::JSGenericTypedArrayView::sortComparison):
(JSC::JSGenericTypedArrayView::sortFloat):
* runtime/JSGenericTypedArrayViewInlines.h:
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h: Added.
(JSC::argumentClampedIndexFromStartOrEnd):
(JSC::genericTypedArrayViewProtoFuncSet):
(JSC::genericTypedArrayViewProtoFuncEntries):
(JSC::genericTypedArrayViewProtoFuncCopyWithin):
(JSC::genericTypedArrayViewProtoFuncFill):
(JSC::genericTypedArrayViewProtoFuncIndexOf):
(JSC::genericTypedArrayViewProtoFuncJoin):
(JSC::genericTypedArrayViewProtoFuncKeys):
(JSC::genericTypedArrayViewProtoFuncLastIndexOf):
(JSC::genericTypedArrayViewProtoGetterFuncLength):
(JSC::genericTypedArrayViewProtoGetterFuncByteLength):
(JSC::genericTypedArrayViewProtoGetterFuncByteOffset):
(JSC::genericTypedArrayViewProtoFuncReverse):
(JSC::genericTypedArrayViewPrivateFuncSort):
(JSC::genericTypedArrayViewProtoFuncSlice):
(JSC::genericTypedArrayViewProtoFuncSubarray):
(JSC::typedArrayViewProtoFuncValues):
* runtime/JSGenericTypedArrayViewPrototypeInlines.h:
(JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
(JSC::genericTypedArrayViewProtoFuncSet): Deleted.
(JSC::genericTypedArrayViewProtoFuncSubarray): Deleted.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSObject.h:
* runtime/JSTypedArrayPrototypes.cpp:
* runtime/JSTypedArrayPrototypes.h:
* runtime/JSTypedArrayViewPrototype.cpp: Added.
(JSC::typedArrayViewPrivateFuncLength):
(JSC::typedArrayViewPrivateFuncSort):
(JSC::typedArrayViewProtoFuncSet):
(JSC::typedArrayViewProtoFuncEntries):
(JSC::typedArrayViewProtoFuncCopyWithin):
(JSC::typedArrayViewProtoFuncFill):
(JSC::typedArrayViewProtoFuncLastIndexOf):
(JSC::typedArrayViewProtoFuncIndexOf):
(JSC::typedArrayViewProtoFuncJoin):
(JSC::typedArrayViewProtoFuncKeys):
(JSC::typedArrayViewProtoGetterFuncLength):
(JSC::typedArrayViewProtoGetterFuncByteLength):
(JSC::typedArrayViewProtoGetterFuncByteOffset):
(JSC::typedArrayViewProtoFuncReverse):
(JSC::typedArrayViewProtoFuncSubarray):
(JSC::typedArrayViewProtoFuncSlice):
(JSC::typedArrayViewProtoFuncValues):
(JSC::JSTypedArrayViewPrototype::JSTypedArrayViewPrototype):
(JSC::JSTypedArrayViewPrototype::finishCreation):
(JSC::JSTypedArrayViewPrototype::create):
(JSC::JSTypedArrayViewPrototype::createStructure):
* runtime/JSTypedArrayViewPrototype.h: Copied from Source/JavaScriptCore/runtime/JSTypedArrayPrototypes.cpp.
* tests/es6.yaml:
* tests/stress/resources/standalone-pre.js: Added.
(description):
(debug):
(escapeString):
(testPassed):
(testFailed):
(areNumbersEqual):
(areArraysEqual):
(isMinusZero):
(isTypedArray):
(isResultCorrect):
(stringify):
(shouldBe):
(dfgShouldBe):
(shouldBeType):
(shouldBeTrue):
(shouldBeFalse):
(shouldBeNaN):
(shouldBeNull):
(shouldBeEqualToString):
(shouldBeUndefined):
(shouldNotThrow):
(shouldThrow):
(dfgCompiled):
(dfgIncrement):
(noInline):
(finishJSTest):
* tests/stress/resources/typedarray-test-helper-functions.js: Added.
(forEachTypedArray):
(isSameFunctionForEachTypedArrayPrototype.eq):
(isSameFunctionForEachTypedArrayPrototype):
(hasSameValues):
(foo):
(testPrototypeFunctionHelper):
(testPrototypeFunctionOnSigned):
(testPrototypeFunctionOnFloat):
(testPrototypeFunction):
(tester):
(testPrototypeReceivesArray):
* tests/stress/typedarray-copyWithin.js: Added.
* tests/stress/typedarray-every.js: Added.
(isBigEnough):
(isBigEnoughAndChange):
(isBigEnoughAndException):
* tests/stress/typedarray-fill.js: Added.
* tests/stress/typedarray-filter.js: Added.
(keepEven):
(keepEvenAndChange):
(isBigEnoughAndException):
* tests/stress/typedarray-find.js: Added.
(keepEven):
(keepEvenAndChange):
(isBigEnoughAndException):
* tests/stress/typedarray-findIndex.js: Added.
(keepEven):
(keepEvenAndChange):
(isBigEnoughAndException):
* tests/stress/typedarray-forEach.js: Added.
(checkCorrect.let.list):
(checkCorrect):
(createChecker):
(foo):
(changeArray):
(isBigEnoughAndException):
* tests/stress/typedarray-indexOf.js: Added.
(keepEven):
* tests/stress/typedarray-lastIndexOf.js: Added.
* tests/stress/typedarray-map.js: Added.
(even):
(evenAndChange):
(isBigEnoughAndException):
* tests/stress/typedarray-reduce.js: Added.
(createArray):
(sum):
(createArrayAndChange):
(isBigEnoughAndException):
* tests/stress/typedarray-reduceRight.js: Added.
(createArray):
(sum):
(createArrayAndChange):
(isBigEnoughAndException):
* tests/stress/typedarray-slice.js: Added.
* tests/stress/typedarray-some.js: Added.
(isBigEnough):
(isBigEnoughAndChange):
(isBigEnoughAndException):
* tests/stress/typedarray-sort.js: Added.
(sortBackwards):
(compareException):
2015-10-01 Yusuke Suzuki <utatane.tea@gmail.com>
Introduce SymbolUse optimization into CompareEq and CompareStrictEq
https://bugs.webkit.org/show_bug.cgi?id=149616
Reviewed by Saam Barati.
Since ES6 Symbols are used as an enum value[1] (And WebKit inspector do so for Esprima's type of nodes),
optimizing equality comparison for symbols makes much sense.
This patch leverages SymbolUse for CompareEq and CompareStrictEq.
Optimizations for both DFG and FTL are implemented.
[1]: http://www.2ality.com/2014/12/es6-symbols.html
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::shouldSpeculateSymbol):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
(JSC::DFG::SpeculativeJIT::compare):
(JSC::DFG::SpeculativeJIT::compileStrictEq):
(JSC::DFG::SpeculativeJIT::extractStringImplFromBinarySymbols):
(JSC::DFG::SpeculativeJIT::compileSymbolEquality):
(JSC::DFG::SpeculativeJIT::compilePeepHoleSymbolEquality):
* dfg/DFGSpeculativeJIT.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileCompareEq):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCompareStrictEq):
* tests/stress/symbol-equality.js: Added.
(shouldBe):
(equal):
(strictEqual):
(list.forEach.result.set 1):
2015-10-01 Youenn Fablet <youenn.fablet@crf.canon.fr>
[Streams API] Add support for private WebCore JS builtins functions
https://bugs.webkit.org/show_bug.cgi?id=149518
Reviewed by Darin Adler.
Adding API to add private identifiers on the fly.
This is used to support private JS Builtin functions/private JS Builtin names in WebCore.
* builtins/BuiltinNames.h:
(JSC::BuiltinNames::appendExternalName):
* runtime/CommonIdentifiers.cpp:
(JSC::CommonIdentifiers::appendExternalName):
* runtime/CommonIdentifiers.h:
2015-09-30 Jaehun Lim <ljaehun.lim@samsung.com>
Unreviewed, cleanup after r190385
TypedArray.prototype.js is removed at r190385.
Remove it from CMakeLists.txt as well.
* CMakeLists.txt:
2015-09-30 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r190367 and r190373.
https://bugs.webkit.org/show_bug.cgi?id=149694
Windows build broken (Requested by smfr on #webkit).
Reverted changesets:
"[ES6] Add TypedArray.prototype functionality."
https://bugs.webkit.org/show_bug.cgi?id=148035
http://trac.webkit.org/changeset/190367
"Unreviewed Windows buildfix."
http://trac.webkit.org/changeset/190373
2015-09-30 Keith Miller <keith_miller@apple.com>
Unreviewed Windows buildfix.
* CMakeLists.txt:
2015-09-30 Michael Saboff <msaboff@apple.com>
Relanding r190289 with the following two fixes:
1. REGRESSION(r190289): It made Speedometer/Full.html performance test fail
https://bugs.webkit.org/show_bug.cgi?id=149621
Reviewed by Saam Barati.
We need to restore callee saves for both the fast and slow paths before making a
tail call in the FTL.
* ftl/FTLJSCallBase.cpp:
(JSC::FTL::JSCallBase::emit):
2. [ARM] REGRESSION(r190289): It made 374 tests crash on 32 bit ARM Linux
https://bugs.webkit.org/show_bug.cgi?id=149619
Reviewed by Filip Pizlo.
Need to check for ARMv7_TRADITIONAL and ARMv7 in addition to ARM in "if"
statement to handle platforms with a link register.
* llint/LowLevelInterpreter.asm:
(prepareForTailCall):
2015-09-30 Keith Miller <keith_miller@apple.com>
[ES6] Add TypedArray.prototype functionality.
https://bugs.webkit.org/show_bug.cgi?id=148035
Reviewed by Geoffrey Garen.
This patch should add most of the functionality for
the prototype properties of TypedArray objects in ES6.
There are a few exceptions to this, which will be added
in upcoming patches:
1) First we do not use the species constructor for some
of the TypedArray prototype functions (namely: map, filter,
slice, and subarray). That will need to be added when
species constructors are finished.
2) TypedArrays still have a length, byteOffset, byteLength,
and buffer are still attached to the TypedArray instance (in
the spec they are on the TypedArray.prototype instance object)
since the JIT currently assumes those properties are fixed.
3) The TypedArray.constructor property is not added yet
as it should point to the TypedArray instance object,
which will be added in a future patch.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/TypedArray.prototype.js: Added.
(every):
(find):
(findIndex):
(forEach):
(some):
(sort.min):
(sort.merge):
(sort.mergeSort):
(sort):
(reduce):
(reduceRight):
(map):
(filter):
(toLocaleString):
* runtime/ArrayPrototype.cpp:
* runtime/ArrayPrototype.h:
* runtime/CommonIdentifiers.h:
* runtime/JSGenericTypedArrayView.h:
(JSC::JSGenericTypedArrayView::toAdaptorNativeFromValue):
(JSC::JSGenericTypedArrayView::setRangeToValue):
(JSC::JSGenericTypedArrayView::sort):
(JSC::JSGenericTypedArrayView::purifyArray):
(JSC::JSGenericTypedArrayView::sortComparison):
(JSC::JSGenericTypedArrayView::sortFloat):
* runtime/JSGenericTypedArrayViewInlines.h:
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h: Added.
(JSC::argumentClampedIndexFromStartOrEnd):
(JSC::genericTypedArrayViewProtoFuncSet):
(JSC::genericTypedArrayViewProtoFuncEntries):
(JSC::genericTypedArrayViewProtoFuncCopyWithin):
(JSC::genericTypedArrayViewProtoFuncFill):
(JSC::genericTypedArrayViewProtoFuncIndexOf):
(JSC::genericTypedArrayViewProtoFuncJoin):
(JSC::genericTypedArrayViewProtoFuncKeys):
(JSC::genericTypedArrayViewProtoFuncLastIndexOf):
(JSC::genericTypedArrayViewProtoGetterFuncLength):
(JSC::genericTypedArrayViewProtoGetterFuncByteLength):
(JSC::genericTypedArrayViewProtoGetterFuncByteOffset):
(JSC::genericTypedArrayViewProtoFuncReverse):
(JSC::genericTypedArrayViewPrivateFuncSort):
(JSC::genericTypedArrayViewProtoFuncSlice):
(JSC::genericTypedArrayViewProtoFuncSubarray):
(JSC::typedArrayViewProtoFuncValues):
* runtime/JSGenericTypedArrayViewPrototypeInlines.h:
(JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
(JSC::genericTypedArrayViewProtoFuncSet): Deleted.
(JSC::genericTypedArrayViewProtoFuncSubarray): Deleted.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSObject.h:
* runtime/JSTypedArrayPrototypes.cpp:
* runtime/JSTypedArrayPrototypes.h:
* runtime/JSTypedArrayViewPrototype.cpp: Added.
(JSC::typedArrayViewPrivateFuncLength):
(JSC::typedArrayViewPrivateFuncSort):
(JSC::typedArrayViewProtoFuncSet):
(JSC::typedArrayViewProtoFuncEntries):
(JSC::typedArrayViewProtoFuncCopyWithin):
(JSC::typedArrayViewProtoFuncFill):
(JSC::typedArrayViewProtoFuncLastIndexOf):
(JSC::typedArrayViewProtoFuncIndexOf):
(JSC::typedArrayViewProtoFuncJoin):
(JSC::typedArrayViewProtoFuncKeys):
(JSC::typedArrayViewProtoGetterFuncLength):
(JSC::typedArrayViewProtoGetterFuncByteLength):
(JSC::typedArrayViewProtoGetterFuncByteOffset):
(JSC::typedArrayViewProtoFuncReverse):
(JSC::typedArrayViewProtoFuncSubarray):
(JSC::typedArrayViewProtoFuncSlice):
(JSC::typedArrayViewProtoFuncValues):
(JSC::JSTypedArrayViewPrototype::JSTypedArrayViewPrototype):
(JSC::JSTypedArrayViewPrototype::finishCreation):
(JSC::JSTypedArrayViewPrototype::create):
(JSC::JSTypedArrayViewPrototype::createStructure):
* runtime/JSTypedArrayViewPrototype.h: Copied from Source/JavaScriptCore/runtime/JSTypedArrayPrototypes.cpp.
* tests/stress/resources/standalone-pre.js: Added.
(description):
(debug):
(escapeString):
(testPassed):
(testFailed):
(areNumbersEqual):
(areArraysEqual):
(isMinusZero):
(isTypedArray):
(isResultCorrect):
(stringify):
(shouldBe):
(dfgShouldBe):
(shouldBeType):
(shouldBeTrue):
(shouldBeFalse):
(shouldBeNaN):
(shouldBeNull):
(shouldBeEqualToString):
(shouldBeUndefined):
(shouldNotThrow):
(shouldThrow):
(dfgCompiled):
(dfgIncrement):
(noInline):
(finishJSTest):
* tests/stress/resources/typedarray-test-helper-functions.js: Added.
(forEachTypedArray):
(isSameFunctionForEachTypedArrayPrototype.eq):
(isSameFunctionForEachTypedArrayPrototype):
(hasSameValues):
(.foo):
(testPrototypeFunctionHelper):
(testPrototypeFunctionOnSigned):
(testPrototypeFunctionOnFloat):
(testPrototypeFunction):
(.tester):
(testPrototypeReceivesArray):
* tests/stress/typedarray-copyWithin.js: Added.
* tests/stress/typedarray-every.js: Added.
(isBigEnough):
(isBigEnoughAndChange):
(isBigEnoughAndException):
* tests/stress/typedarray-fill.js: Added.
* tests/stress/typedarray-filter.js: Added.
(keepEven):
(keepEvenAndChange):
(isBigEnoughAndException):
* tests/stress/typedarray-find.js: Added.
(keepEven):
(keepEvenAndChange):
(isBigEnoughAndException):
* tests/stress/typedarray-findIndex.js: Added.
(keepEven):
(keepEvenAndChange):
(isBigEnoughAndException):
* tests/stress/typedarray-forEach.js: Added.
(.checkCorrect.let.list):
(.checkCorrect):
(createChecker):
(foo):
(changeArray):
(isBigEnoughAndException):
* tests/stress/typedarray-indexOf.js: Added.
(keepEven):
* tests/stress/typedarray-lastIndexOf.js: Added.
* tests/stress/typedarray-map.js: Added.
(even):
(evenAndChange):
(isBigEnoughAndException):
* tests/stress/typedarray-reduce.js: Added.
(createArray):
(sum):
(createArrayAndChange):
(isBigEnoughAndException):
* tests/stress/typedarray-reduceRight.js: Added.
(createArray):
(sum):
(createArrayAndChange):
(isBigEnoughAndException):
* tests/stress/typedarray-slice.js: Added.
* tests/stress/typedarray-some.js: Added.
(isBigEnough):
(isBigEnoughAndChange):
(isBigEnoughAndException):
* tests/stress/typedarray-sort.js: Added.
(sortBackwards):
(compareException):
2015-09-30 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r190324.
https://bugs.webkit.org/show_bug.cgi?id=149671
Caused flaky crashes, rdar://problem/22916304 (Requested by ap
on #webkit).
Reverted changeset:
"ParallelHelperPool::runFunctionInParallel() shouldn't
allocate, and ParallelHelperPool.h shouldn't be included
everywhere"
https://bugs.webkit.org/show_bug.cgi?id=149635
http://trac.webkit.org/changeset/190324
2015-09-29 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r190289.
https://bugs.webkit.org/show_bug.cgi?id=149647
Crashing speedometer and some ARM32 tests (Requested by
msaboff on #webkit).
Reverted changeset:
"[ES6] Implement tail calls in the FTL"
https://bugs.webkit.org/show_bug.cgi?id=148664
http://trac.webkit.org/changeset/190289
2015-09-29 Filip Pizlo <fpizlo@apple.com>
ParallelHelperPool::runFunctionInParallel() shouldn't allocate, and ParallelHelperPool.h shouldn't be included everywhere
https://bugs.webkit.org/show_bug.cgi?id=149635
Reviewed by Saam Barati.
It bugged me that this change caused a whole-world recompile. So, I changed the code so
that ParallelHelperPool.h is only included by Heap.cpp and not by Heap.h.
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::markRoots):
(JSC::Heap::copyBackingStores):
* heap/Heap.h:
2015-09-29 Filip Pizlo <fpizlo@apple.com>
GC copy phase spans too many files
https://bugs.webkit.org/show_bug.cgi?id=149586
Reviewed by Andreas Kling.
This puts the core logic of the copy phase into Heap::copyBackingStores(). Now, instead of
using many helpers in many places, the actual algorithm is all in one place.
This lets me do a lot of simplification.
- CopyVisitor no longer requires that you call startCopying() before, and doneCopying() and
WTF::releaseFastMallocFreeMemoryForThisThread() after. The constructor and destructor now
do this for you.
- CopyVisitor no longer contains the algorithm that drives copying. That's all in
Heap::copyBackingStores() now. Basically, copyBackingStores() glues together the new
WTF::ParallelVectorIterator with the copying algorithm that we used to have in
CopyVisitor::copyFromShared().
- Lots of stuff that was in headers is now in .cpp files. That includes all non-hot-path
code in CopyVisitor. Also, the code for copying in HeapInlines.h is now in
ParallelVectorVisotor, and it's only included by Heap.cpp.
Overall, I like this direction for the GC. I don't think it's useful for Heap.cpp to have
calls to algorithms in some other file, unless those algorithms are either reusable or just
very dense. That's not actually true for the copy phase, and it's probably not true for
some other stuff like marking. I'll probably do the same refactoring for marking in another
bug.
This should have no effect on performance.
* heap/CopyVisitor.cpp:
(JSC::CopyVisitor::CopyVisitor):
(JSC::CopyVisitor::~CopyVisitor):
(JSC::CopyVisitor::copyFromShared): Deleted.
* heap/CopyVisitor.h:
* heap/CopyVisitorInlines.h:
(JSC::CopyVisitor::checkIfShouldCopy):
(JSC::CopyVisitor::allocateNewSpaceSlow):
(JSC::CopyVisitor::didCopy):
(JSC::CopyVisitor::visitItem): Deleted.
(JSC::CopyVisitor::startCopying): Deleted.
(JSC::CopyVisitor::doneCopying): Deleted.
* heap/Heap.cpp:
(JSC::Heap::copyBackingStores):
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::unregisterWeakGCMap):
(JSC::Heap::getNextBlocksToCopy): Deleted.
2015-09-29 Youenn Fablet <youenn.fablet@crf.canon.fr>
Add support for WebIDL JSBuiltin attributes
https://bugs.webkit.org/show_bug.cgi?id=149554
Reviewed by Darin Adler.
* runtime/Lookup.cpp:
(JSC::reifyStaticAccessor): Adding support for creating attribute getter from JS builtin functions.
* runtime/Lookup.h:
(JSC::HashTableValue::builtinAccessorGetterGenerator):
(JSC::HashTableValue::builtinAccessorSetterGenerator):
(JSC::reifyStaticProperties): Ensuring that builtin attributes are not treated as Builtin functions.
2015-09-28 Joseph Pecoraro <pecoraro@apple.com>
Remove unused parseMemoryAmount
https://bugs.webkit.org/show_bug.cgi?id=149611
Reviewed by Mark Lam.
* heap/HeapStatistics.cpp:
(JSC::HeapStatistics::parseMemoryAmount): Deleted.
* heap/HeapStatistics.h:
2015-09-28 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: JSGlobalRuntimeAgent unintentionally overrides InspectorRuntimeAgent destruction handling
https://bugs.webkit.org/show_bug.cgi?id=149537
Reviewed by Darin Adler.
* inspector/agents/JSGlobalObjectRuntimeAgent.h:
* inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
(Inspector::JSGlobalObjectRuntimeAgent::willDestroyFrontendAndBackend): Deleted.
Do not override method, super class implementation is sufficient.
* JavaScriptCore.xcodeproj/project.pbxproj:
Fix file ordering.
* inspector/agents/InspectorDebuggerAgent.h:
Remove unused member variable.
2015-09-28 basile_clement@apple.com <basile_clement@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
[ES6] Implement tail calls in the FTL
https://bugs.webkit.org/show_bug.cgi?id=148664
Reviewed by Filip Pizlo.
This patch implements the tail call opcodes in the FTL, making tail
calls available through all tiers. The changes are relatively
straightforward, although the frame shuffler had to be extended to
handle the possibility of running out of stack when spilling or
building a slow path frame. The other tiers always ensure that we have
enough stack space to build the new frame at the bottom of the old one,
but that is not true for the FTL.
Moreover, for efficiency, this adds to the shuffler the ability to
record the state of the TagTypeNumber, and to re-use the same register
when doing several consecutive integer boxings with no spilling in
between.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/ValueRecovery.h:
(JSC::ValueRecovery::inRegister):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleInlining):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGNode.h:
(JSC::DFG::Node::isFunctionTerminal):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* dfg/DFGTierUpCheckInjectionPhase.cpp:
(JSC::DFG::TierUpCheckInjectionPhase::run):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLInlineCacheSize.cpp:
(JSC::FTL::sizeOfTailCallVarargs):
(JSC::FTL::sizeOfTailCallForwardVarargs):
(JSC::FTL::sizeOfICFor):
* ftl/FTLInlineCacheSize.h:
* ftl/FTLJSCall.cpp:
(JSC::FTL::JSCall::JSCall):
* ftl/FTLJSCallBase.cpp:
(JSC::FTL::JSCallBase::emit):
(JSC::FTL::JSCallBase::link):
* ftl/FTLJSCallBase.h:
* ftl/FTLJSCallVarargs.cpp:
(JSC::FTL::JSCallVarargs::JSCallVarargs):
(JSC::FTL::JSCallVarargs::emit):
* ftl/FTLJSTailCall.cpp: Added.
(JSC::FTL::getRegisterWithAddend):
(JSC::FTL::recoveryFor):
(JSC::FTL::sizeFor):
(JSC::FTL::JSTailCall::JSTailCall):
(JSC::FTL::m_instructionOffset):
(JSC::FTL::JSTailCall::emit):
* ftl/FTLJSTailCall.h: Copied from Source/JavaScriptCore/ftl/FTLJSCallBase.h.
(JSC::FTL::JSTailCall::stackmapID):
(JSC::FTL::JSTailCall::estimatedSize):
(JSC::FTL::JSTailCall::numArguments):
(JSC::FTL::JSTailCall::operator<):
* ftl/FTLLocation.h:
(JSC::FTL::Location::operator bool):
(JSC::FTL::Location::operator!):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::lower):
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
(JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
(JSC::FTL::DFG::LowerDFGToLLVM::callPreflight):
(JSC::FTL::DFG::LowerDFGToLLVM::exitValueForTailCall):
* ftl/FTLState.h:
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitExceptionCheck):
* jit/CallFrameShuffleData.h:
* jit/CallFrameShuffler.cpp:
(JSC::CallFrameShuffler::CallFrameShuffler):
(JSC::CallFrameShuffler::dump):
(JSC::CallFrameShuffler::spill):
(JSC::CallFrameShuffler::extendFrameIfNeeded):
(JSC::CallFrameShuffler::prepareForSlowPath):
(JSC::CallFrameShuffler::prepareAny):
* jit/CallFrameShuffler.h:
(JSC::CallFrameShuffler::restoreGPR):
(JSC::CallFrameShuffler::getFreeRegister):
(JSC::CallFrameShuffler::getFreeTempGPR):
(JSC::CallFrameShuffler::ensureTempGPR):
(JSC::CallFrameShuffler::addNew):
* jit/CallFrameShuffler64.cpp:
(JSC::CallFrameShuffler::emitBox):
(JSC::CallFrameShuffler::tryAcquireTagTypeNumber):
* jit/JITCall.cpp:
(JSC::JIT::compileOpCall):
* jit/Reg.h:
(JSC::Reg::Reg):
(JSC::Reg::isHashTableDeletedValue):
(JSC::Reg::deleted):
(JSC::RegHash::hash):
(JSC::RegHash::equal):
* test/es6.yaml:
2015-09-28 Keith Miller <keith_miller@apple.com>
ObjectPropertyConditionSet::mergedWith does not produce a minimal intersection.
https://bugs.webkit.org/show_bug.cgi?id=149598
Reviewed by Michael Saboff.
mergedWith sometimes creates duplicates of an ObjectPropertyCondition, which causes GetByIdVariant
in believe that the condition has more than one slotBaseCondition when only one was necessary.
* bytecode/ObjectPropertyConditionSet.cpp:
(JSC::ObjectPropertyConditionSet::mergedWith):
2015-09-26 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix debug tests. Before marking, we need to call registerGCThreads().
* heap/Heap.cpp:
(JSC::Heap::markRoots):
2015-09-24 Filip Pizlo <fpizlo@apple.com>
VMs should share GC threads
https://bugs.webkit.org/show_bug.cgi?id=149433
rdar://problem/12859344
Reviewed by Geoffrey Garen.
This changes the GC to use a new WTF abstraction for parallelism called ParallelHelperPool.
This allows us to remove GCThread and all of the GCPhase machinery. This kills a lot of
code and also gives our GC magical thread sharing powers. If two GCs in two different VMs
fire at the same time, then they will both get a random subset of the available shared GC
threads. If one GC happens before the other, then it will probably get all of the available
threads. If a GC happens while another VM already started GCing, then it will probably not
get any helper threads. This is probably fine, since in multi-VM scenarios we have no
reason to optimize for anything other than total throughput.
The GC has one static helper pool. This pool is available via JSC::heapHelperPool(). It
would be OK for other parts of JSC to use it in the future for parallel tasks. Each Heap
instance has a helper client attached to the pool.
The marking phase tells the ParallelHelperClient to asynchronously run a function that
joins parallel marking and finishes once marking reaches termination. It uses the
client.setFunction() idiom where the threads share work with each other using a specialized
worklist. The ParallelHelperPool is not involved in deciding when threads should terminate.
The copying phase tells the ParallelHelperClient to run a copying function in parallel. It
uses the client.runFunctionInParallel() idiom. The copying function gets work from the
m_blocksToCopy worklist inside Heap.
To test that multiple VMs work properly, this adds a multi-VM test to testapi.mm. This test
creates five concurrent VMs and has each of them allocate about 30MB of memory before doing
a full GC. I've confirmed that this tests uses only 6 total GC threads on my 8-core
computer (this is correct since we are currently configured for 7-way parallelism).
This shouldn't affect performance on benchmarks, but it will sure help apps with a lot of
VM instances.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/AbstractMacroAssembler.h:
* heap/GCThread.cpp: Removed.
* heap/GCThread.h: Removed.
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::~Heap):
(JSC::Heap::isPagedOut):
(JSC::Heap::markRoots):
(JSC::Heap::copyBackingStores):
(JSC::Heap::resetVisitors):
(JSC::Heap::threadVisitCount):
(JSC::Heap::threadBytesVisited):
(JSC::Heap::threadBytesCopied):
(JSC::Heap::startNextPhase): Deleted.
(JSC::Heap::endCurrentPhase): Deleted.
* heap/Heap.h:
* heap/HeapHelperPool.cpp: Added.
(JSC::heapHelperPool):
* heap/HeapHelperPool.h: Added.
* heap/MarkStack.cpp:
(JSC::MarkStackArray::stealSomeCellsFrom):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::didStartMarking):
(JSC::SlotVisitor::reset):
(JSC::SlotVisitor::drainFromShared):
* jit/BinarySwitch.h:
* runtime/CodeCache.h:
* runtime/VM.h:
* runtime/WeakRandom.h: Removed.
* API/tests/testapi.mm:
2015-09-25 Saam barati <sbarati@apple.com>
DFG should use PhantomLocal instead of Flush as liveness preservation mechanism in LiveCatchVariablesPreservationPhase
https://bugs.webkit.org/show_bug.cgi?id=149575
Reviewed by Geoffrey Garen.
LiveCatchVariablesPreservationPhase is no longer forcing all live-at-catch
variables to be flushed to the stack. They are now kept alive to OSR exit
through PhantomLocal. This gives us a speed improvement for try-catch
programs (especially those that don't throw errors very often) because
we can keep locals in registers instead of forcing them onto the stack.
* dfg/DFGLiveCatchVariablePreservationPhase.cpp:
(JSC::DFG::LiveCatchVariablePreservationPhase::LiveCatchVariablePreservationPhase):
(JSC::DFG::LiveCatchVariablePreservationPhase::handleBlock):
(JSC::DFG::performLiveCatchVariablePreservationPhase):
(JSC::DFG::FlushLiveCatchVariablesInsertionPhase::FlushLiveCatchVariablesInsertionPhase): Deleted.
(JSC::DFG::FlushLiveCatchVariablesInsertionPhase::handleBlock): Deleted.
2015-09-25 Michael Saboff <msaboff@apple.com>
FTLOSRExitCompiler incorrectly excludes FPR registers in callee saves loop
https://bugs.webkit.org/show_bug.cgi?id=149540
Reviewed by Saam Barati.
Eliminated the incorrect check that callee saves registers are only GPRs.
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
2015-09-25 Alex Christensen <achristensen@webkit.org>
[Win] Switch to CMake
https://bugs.webkit.org/show_bug.cgi?id=148111
Reviewed by Brent Fulgham.
* JavaScriptCore.vcxproj/JavaScriptCore.proj:
2015-09-24 Mark Lam <mark.lam@apple.com>
Remove the use of "Immediate" in JIT function names.
https://bugs.webkit.org/show_bug.cgi?id=149542
Reviewed by Geoffrey Garen.
We will rename the following:
isOperandConstantImmediateDouble => isOperandConstantDouble
isOperandConstantImmediateInt => isOperandConstantInt
isOperandConstantImmediateChar => isOperandConstantChar
getOperandConstantImmediateInt => getOperandConstantInt
getConstantOperandImmediateInt => getOperandConstantInt
emitJumpIfImmediateInteger => emitJumpIfInt
emitJumpIfNotImmediateInteger => emitJumpIfNotInt
emitJumpIfNotImmediateIntegers => emitJumpIfNotInt
emitPatchableJumpIfNotImmediateInteger => emitPatchableJumpIfNotInt
emitJumpSlowCaseIfNotImmediateInteger => emitJumpSlowCaseIfNotInt
emitJumpSlowCaseIfNotImmediateNumber => emitJumpSlowCaseIfNotNumber
emitJumpSlowCaseIfNotImmediateIntegers => emitJumpSlowCaseIfNotInt
emitFastArithReTagImmediate => emitTagInt
emitTagAsBoolImmediate => emitTagBool
emitJumpIfImmediateNumber => emitJumpIfNumber
emitJumpIfNotImmediateNumber => emitJumpIfNotNumber
emitFastArithImmToInt - Deleted because this is an empty function.
emitFastArithIntToImmNoCheck => emitTagInt
emitPutImmediateToCallFrameHeader => emitPutToCallFrameHeader
This is purely a refactoring patch to do the renaming. There is no behavior
change.
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compileEntry):
(JSC::DFG::JITCompiler::compileSetupRegistersForEntry):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitPutToCallFrameHeader):
(JSC::AssemblyHelpers::emitPutImmediateToCallFrameHeader): Deleted.
* jit/JIT.cpp:
(JSC::JIT::privateCompile):
* jit/JIT.h:
(JSC::JIT::emitStoreCell):
(JSC::JIT::getSlowCase):
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_negate):
(JSC::JIT::emit_op_lshift):
(JSC::JIT::emit_op_rshift):
(JSC::JIT::emitSlow_op_rshift):
(JSC::JIT::emit_op_urshift):
(JSC::JIT::emitSlow_op_urshift):
(JSC::JIT::emit_op_unsigned):
(JSC::JIT::emit_compareAndJump):
(JSC::JIT::emit_compareAndJumpSlow):
(JSC::JIT::emit_op_bitand):
(JSC::JIT::emit_op_inc):
(JSC::JIT::emit_op_dec):
(JSC::JIT::emit_op_mod):
(JSC::JIT::compileBinaryArithOp):
(JSC::JIT::compileBinaryArithOpSlowCase):
(JSC::JIT::emit_op_add):
(JSC::JIT::emitSlow_op_add):
(JSC::JIT::emit_op_mul):
(JSC::JIT::emitSlow_op_mul):
(JSC::JIT::emit_op_div):
(JSC::JIT::emitSlow_op_div):
* jit/JITArithmetic32_64.cpp:
(JSC::JIT::emit_compareAndJump):
(JSC::JIT::emit_compareAndJumpSlow):
(JSC::JIT::emit_op_lshift):
(JSC::JIT::emitSlow_op_lshift):
(JSC::JIT::emitRightShift):
(JSC::JIT::emitRightShiftSlowCase):
(JSC::JIT::emit_op_bitand):
(JSC::JIT::emitSlow_op_bitand):
(JSC::JIT::emit_op_bitor):
(JSC::JIT::emitSlow_op_bitor):
(JSC::JIT::emit_op_bitxor):
(JSC::JIT::emitSlow_op_bitxor):
(JSC::JIT::emit_op_add):
(JSC::JIT::emitSlow_op_add):
(JSC::JIT::emit_op_sub):
(JSC::JIT::emitSlow_op_sub):
* jit/JITInlines.h:
(JSC::JIT::emitArrayStorageGetByVal):
(JSC::JIT::isOperandConstantDouble):
(JSC::JIT::isOperandConstantChar):
(JSC::JIT::emitJumpSlowCaseIfNotJSCell):
(JSC::JIT::isOperandConstantInt):
(JSC::JIT::getOperandConstantInt):
(JSC::JIT::emitGetVirtualRegisters):
(JSC::JIT::emitLoadInt32ToDouble):
(JSC::JIT::emitJumpIfInt):
(JSC::JIT::emitJumpIfNotInt):
(JSC::JIT::emitPatchableJumpIfNotInt):
(JSC::JIT::emitJumpSlowCaseIfNotInt):
(JSC::JIT::emitJumpSlowCaseIfNotNumber):
(JSC::JIT::emitTagBool):
(JSC::JIT::isOperandConstantImmediateDouble): Deleted.
(JSC::JIT::isOperandConstantImmediateChar): Deleted.
(JSC::JIT::isOperandConstantImmediateInt): Deleted.
(JSC::JIT::getOperandConstantImmediateInt): Deleted.
(JSC::JIT::getConstantOperandImmediateInt): Deleted.
(JSC::JIT::emitJumpIfImmediateInteger): Deleted.
(JSC::JIT::emitJumpIfNotImmediateInteger): Deleted.
(JSC::JIT::emitPatchableJumpIfNotImmediateInteger): Deleted.
(JSC::JIT::emitJumpIfNotImmediateIntegers): Deleted.
(JSC::JIT::emitJumpSlowCaseIfNotImmediateInteger): Deleted.
(JSC::JIT::emitJumpSlowCaseIfNotImmediateIntegers): Deleted.
(JSC::JIT::emitJumpSlowCaseIfNotImmediateNumber): Deleted.
(JSC::JIT::emitFastArithReTagImmediate): Deleted.
(JSC::JIT::emitTagAsBoolImmediate): Deleted.
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_is_undefined):
(JSC::JIT::emit_op_is_boolean):
(JSC::JIT::emit_op_is_number):
(JSC::JIT::emit_op_is_string):
(JSC::JIT::emit_op_is_object):
(JSC::JIT::emit_op_jfalse):
(JSC::JIT::emit_op_eq):
(JSC::JIT::emit_op_jtrue):
(JSC::JIT::emit_op_neq):
(JSC::JIT::emit_op_bitxor):
(JSC::JIT::emit_op_bitor):
(JSC::JIT::compileOpStrictEq):
(JSC::JIT::emit_op_to_number):
(JSC::JIT::emit_op_eq_null):
(JSC::JIT::emit_op_neq_null):
(JSC::JIT::emitSlow_op_eq):
(JSC::JIT::emitSlow_op_neq):
(JSC::JIT::emit_op_profile_type):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::privateCompileCTINativeCall):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emit_op_put_by_val):
(JSC::JIT::emitGenericContiguousPutByVal):
(JSC::JIT::emit_op_put_by_id):
(JSC::JIT::emitIntTypedArrayPutByVal):
(JSC::JIT::emitFloatTypedArrayPutByVal):
* jit/JSInterfaceJIT.h:
(JSC::JSInterfaceJIT::emitJumpIfNotJSCell):
(JSC::JSInterfaceJIT::emitJumpIfNumber):
(JSC::JSInterfaceJIT::emitJumpIfNotNumber):
(JSC::JSInterfaceJIT::emitLoadDouble):
(JSC::JSInterfaceJIT::emitTagInt):
(JSC::JSInterfaceJIT::emitPutToCallFrameHeader):
(JSC::JSInterfaceJIT::emitJumpIfImmediateNumber): Deleted.
(JSC::JSInterfaceJIT::emitJumpIfNotImmediateNumber): Deleted.
(JSC::JSInterfaceJIT::emitFastArithImmToInt): Deleted.
(JSC::JSInterfaceJIT::emitFastArithIntToImmNoCheck): Deleted.
(JSC::JSInterfaceJIT::emitPutImmediateToCallFrameHeader): Deleted.
* jit/ThunkGenerators.cpp:
(JSC::nativeForGenerator):
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::startFunction):
(JSC::WASMFunctionCompiler::endFunction):
2015-09-24 Michael Saboff <msaboff@apple.com>
[ES6] Implement tail calls in the DFG
https://bugs.webkit.org/show_bug.cgi?id=148663
Reviewed by Filip Pizlo.
jsc-tailcall: Implement the tail call opcodes in the DFG
https://bugs.webkit.org/show_bug.cgi?id=146850
This patch adds support for tail calls in the DFG. This requires a slightly high number of nodes:
- TailCall and TailCallVarargs are straightforward. They are terminal
nodes and have the semantics of an actual tail call.
- TailCallInlinedCaller and TailCallVarargsInlinedCaller are here to perform a
tail call inside an inlined function. They are non terminal nodes,
and are performing the call as a regular call after popping an
appropriate number of inlined tail call frames.
- TailCallForwardVarargs and TailCallForwardVarargsInlinedCaller are the
extension of TailCallVarargs and TailCallVarargsInlinedCaller to enable
the varargs forwarding optimization so that we don't lose
performance with a tail call instead of a regular call.
This also required two broad kind of changes:
- Changes in the JIT itself (DFGSpeculativeJIT) are pretty
straightforward since they are just an extension of the baseline JIT
changes introduced previously.
- Changes in the runtime are mostly related with handling inline call
frames. The idea here is that we have a special TailCall type for
call frames that indicates to the various pieces of code walking the
inline call frame that they should (recursively) skip the caller in
their analysis.
* bytecode/CallMode.h:
(JSC::specializationKindFor):
* bytecode/CodeOrigin.cpp:
(JSC::CodeOrigin::inlineDepthForCallFrame):
(JSC::CodeOrigin::isApproximatelyEqualTo):
(JSC::CodeOrigin::approximateHash):
(JSC::CodeOrigin::inlineStack):
* bytecode/CodeOrigin.h:
* bytecode/InlineCallFrame.cpp:
(JSC::InlineCallFrame::dumpInContext):
(WTF::printInternal):
* bytecode/InlineCallFrame.h:
(JSC::InlineCallFrame::callModeFor):
(JSC::InlineCallFrame::kindFor):
(JSC::InlineCallFrame::varargsKindFor):
(JSC::InlineCallFrame::specializationKindFor):
(JSC::InlineCallFrame::isVarargs):
(JSC::InlineCallFrame::isTail):
(JSC::InlineCallFrame::computeCallerSkippingDeadFrames):
(JSC::InlineCallFrame::getCallerSkippingDeadFrames):
(JSC::InlineCallFrame::getCallerInlineFrameSkippingDeadFrames):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGBasicBlock.h:
(JSC::DFG::BasicBlock::findTerminal):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::inlineCallFrame):
(JSC::DFG::ByteCodeParser::allInlineFramesAreTailCalls):
(JSC::DFG::ByteCodeParser::currentCodeOrigin):
(JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
(JSC::DFG::ByteCodeParser::addCall):
(JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
(JSC::DFG::ByteCodeParser::getPrediction):
(JSC::DFG::ByteCodeParser::handleCall):
(JSC::DFG::ByteCodeParser::handleVarargsCall):
(JSC::DFG::ByteCodeParser::emitArgumentPhantoms):
(JSC::DFG::ByteCodeParser::inliningCost):
(JSC::DFG::ByteCodeParser::inlineCall):
(JSC::DFG::ByteCodeParser::attemptToInlineCall):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
(JSC::DFG::ByteCodeParser::parseCodeBlock):
* 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/DFGGraph.cpp:
(JSC::DFG::Graph::isLiveInBytecode):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::forAllLocalsLiveInBytecode):
* dfg/DFGInPlaceAbstractState.cpp:
(JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::willCatchExceptionInMachineFrame):
* dfg/DFGLiveCatchVariablePreservationPhase.cpp:
(JSC::DFG::FlushLiveCatchVariablesInsertionPhase::willCatchException):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasCallVarargsData):
(JSC::DFG::Node::isTerminal):
(JSC::DFG::Node::hasHeapPrediction):
* dfg/DFGNodeType.h:
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::handleExitCounts):
(JSC::DFG::reifyInlinedCallFrames):
(JSC::DFG::osrWriteBarrier):
* dfg/DFGOSRExitPreparation.cpp:
(JSC::DFG::prepareCodeOriginForOSRExit):
* dfg/DFGOperations.cpp:
* dfg/DFGPreciseLocalClobberize.h:
(JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::validateSSA):
* dfg/DFGVarargsForwardingPhase.cpp:
* interpreter/CallFrame.cpp:
(JSC::CallFrame::bytecodeOffset):
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::gotoNextFrame):
2015-09-23 Filip Pizlo <fpizlo@apple.com>
Remove special case code for the no-parallel-GC case
https://bugs.webkit.org/show_bug.cgi?id=149512
Reviewed by Mark Lam.
Make serial GC just a parallel GC where the helper threads don't do anything. Also make the
idle thread calculation a bit more explicit.
The main outcome is that we no longer use Options::numberOfGCMarkers() as much, so the code is
resilient against the number of GC markers changing.
* heap/Heap.h:
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::donateKnownParallel):
(JSC::SlotVisitor::drain):
(JSC::SlotVisitor::drainFromShared):
2015-09-23 Filip Pizlo <fpizlo@apple.com>
PolymorphicAccess should remember that it checked an ObjectPropertyCondition with a check on some structure
https://bugs.webkit.org/show_bug.cgi?id=149514
Reviewed by Oliver Hunt.
When we checked an ObjectPropertyCondition using an explicit structure check, we would forget to
note the structure in any weak reference table and we would attempt to regenerate the condition
check even if the condition became invalid.
We need to account for this better and we need to prune AccessCases that have an invalid condition
set. This change does both.
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessGenerationState::addWatchpoint):
(JSC::AccessCase::alternateBase):
(JSC::AccessCase::couldStillSucceed):
(JSC::AccessCase::canReplace):
(JSC::AccessCase::generate):
(JSC::PolymorphicAccess::regenerateWithCases):
(JSC::PolymorphicAccess::visitWeak):
(JSC::PolymorphicAccess::regenerate):
* bytecode/PolymorphicAccess.h:
(JSC::AccessCase::callLinkInfo):
* tests/stress/make-dictionary-repatch.js: Added. This used to crash on a release assert. If we removed the release assert, this would return bad results.
2015-09-24 Mark Lam <mark.lam@apple.com>
We should only expect a RareCaseProfile to exist if the rare case actually exists.
https://bugs.webkit.org/show_bug.cgi?id=149531
Reviewed by Saam Barati.
The current code that calls rareCaseProfileForBytecodeOffset() assumes that it
will always return a non-null RareCaseProfile. As a result, op_add in the
baseline JIT is forced to add a dummy slow case that will never be taken, only to
ensure that the RareCaseProfile for that bytecode is created. This profile will
always produce a counter value of 0 (since that path will never be taken).
Instead, we'll make the callers of rareCaseProfileForBytecodeOffset() check if
the profile actually exist before dereferencing it.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::rareCaseProfileForBytecodeOffset):
(JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset):
(JSC::CodeBlock::capabilityLevel):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::addRareCaseProfile):
(JSC::CodeBlock::numberOfRareCaseProfiles):
(JSC::CodeBlock::likelyToTakeSlowCase):
(JSC::CodeBlock::couldTakeSlowCase):
(JSC::CodeBlock::likelyToTakeDeepestSlowCase):
(JSC::CodeBlock::likelyToTakeAnySlowCase):
(JSC::CodeBlock::rareCaseProfile): Deleted.
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_add):
(JSC::JIT::emitSlow_op_add):
* jit/JITArithmetic32_64.cpp:
(JSC::JIT::emit_op_add):
(JSC::JIT::emitSlow_op_add):
2015-09-24 Ryosuke Niwa <rniwa@webkit.org>
Ran sort-Xcode-project-file.
* JavaScriptCore.xcodeproj/project.pbxproj:
2015-09-24 Youenn Fablet <youenn.fablet@crf.canon.fr>
[Streams API] Add support for JS builtins constructor
https://bugs.webkit.org/show_bug.cgi?id=149497
Reviewed by Darin Adler.
* runtime/JSFunction.h: exporting createBuiltinFunction.
2015-09-23 Saam barati <sbarati@apple.com>
JSC allows invalid var declarations when the declared name is the same as a let/const variable
https://bugs.webkit.org/show_bug.cgi?id=147600
Reviewed by Yusuke Suzuki.
We had an ordering bug where if you first declared a "let"
variable then a "var" variable with the same name, you wouldn't
get a syntax error. But, if you did it in the reverse order,
you would. This patch fixes this syntax error to be order independent.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseVariableDeclarationList):
(JSC::Parser<LexerType>::createBindingPattern):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
* parser/Parser.h:
(JSC::Scope::declareVariable):
2015-09-23 Filip Pizlo <fpizlo@apple.com>
Parallel copy phase synchronization should be simplified
https://bugs.webkit.org/show_bug.cgi?id=149509
Reviewed by Mark Lam.
Before this change, we didn't wait for the copy phase to finish before starting to do things to
copied space that presumed that copying was done. Copied space would "detect" that nobody was
copying anymore by waiting for all loaned blocks to be returned. But that would succeed if some
thread had not yet started copying. So, we had weird hacks to ensure that a block was loaned
before any threads started. It also meant that we had two separate mechanisms for waiting for
copying threads to finish - one mechanism in the Heap phase logic and another in the
CopiedSpace::doneCopying() method.
We can get rid of a lot of the weirdness by just having a sound shutdown sequence:
1) Threads concur on when there is no more work. We already have this; once
Heap::getNextBlocksToCopy() returns no work in any thread, it will also return no work in
any other thread that asks for work.
2) Main thread waits for the threads to not be copying anymore.
3) Do whatever we need to do after copying finishes.
Currently, we do (3) before (2) and so we have weird problems. This just changes the code to do
(3) after (2), and so we can get rid of the synchronization in doneCopying() and we can safely
call startCopying() inside GCThread. This also means that we don't need to make CopyVisitor a
property of GCThread. Instead, GCThread just instantiates its own CopyVisitor when it needs to.
* heap/CopiedSpace.cpp:
(JSC::CopiedSpace::doneCopying):
* heap/GCThread.cpp:
(JSC::GCThread::GCThread):
(JSC::GCThread::slotVisitor):
(JSC::GCThread::waitForNextPhase):
(JSC::GCThread::gcThreadMain):
(JSC::GCThread::copyVisitor): Deleted.
* heap/GCThread.h:
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::copyBackingStores):
(JSC::Heap::gatherStackRoots):
2015-09-23 Joseph Pecoraro <pecoraro@apple.com>
Remove unimplemented method Heap::showStatistics
https://bugs.webkit.org/show_bug.cgi?id=149507
Reviewed by Darin Adler.
* heap/Heap.h:
2015-09-23 Tim Horton <timothy_horton@apple.com>
Hopefully fix the production build.
* JavaScriptCore.xcodeproj/project.pbxproj:
* PlatformWin.cmake:
2015-09-23 Youenn Fablet <youenn.fablet@crf.canon.fr>
[Streams API] Implement ReadableStream pipeThrough
https://bugs.webkit.org/show_bug.cgi?id=147556
Reviewed by Darin Adler.
Updating BuiltIns infrastructure to make it reusable from WebCore.
Extracting macros from BuiltinNames and createBuiltinExecutable from BuiltinExecutables.
Updated generate-js-builtins to allow generating builtin CPP/H files in WebCore namespace.
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createDefaultConstructor):
(JSC::BuiltinExecutables::createBuiltinExecutable):
(JSC::createBuiltinExecutable):
(JSC::createExecutableInternal):
* builtins/BuiltinExecutables.h:
* builtins/BuiltinNames.h:
(JSC::BuiltinNames::BuiltinNames): Deleted.
* builtins/BuiltinUtils.h: Extracting code from BuiltinNames and BuiltinExecutables.h.
* bytecode/UnlinkedFunctionExecutable.h:
* generate-js-builtins:
(getFunctions):
(writeIncludeDirectives):
2015-09-22 Mark Lam <mark.lam@apple.com>
Gardening: speculative non-JIT build fix after r189999.
Not reviewed.
* bytecode/ValueRecovery.h:
(JSC::ValueRecovery::jsValueRegs):
2015-09-22 Filip Pizlo <fpizlo@apple.com>
GCThreadSharedData is just a bad way of saying Heap
https://bugs.webkit.org/show_bug.cgi?id=149435
Reviewed by Mark Lam.
This removes the GCThreadSharedData class and moves its members into Heap. This is a net
simplification since GCThreadSharedData had a 1-to-1 mapping to Heap and the two classes had a
vast contract with a lot of interdependencies. Heap would call a lot of GCThreadSharedData
methods; now a lot of those are inlined since they were only called from the one place in Heap.
This makes it a lot easier to see what is going on. For example, you no longer have to look at
code in two places (Heap and GCThreadSharedData) to figure out the timing and synchronization
of GC phases - all of that code is in Heap now.
This also removes weird indirections in other places. It used to be that a lot of GC helper
classes woud have a pointer to GCThreadSharedData, and then would use that to get to Heap, VM,
and the visitors. Now these helpers just point to Heap.
I think that GCThreadSharedData was only useful for defining the set of things that we need to
know to collect garbage. That's how we decided if something would go into GCThreadSharedData
instead of Heap. But I think that separating things into multiple classes usually makes the
code less hackable, so there should be a very high bar for doing this in a way that produces a
1-to-1 mapping between two classes - where one instance of one of the classes is always paired
with exactly one instance of the other class and vice-versa.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/CopiedSpace.h:
* heap/CopyVisitor.cpp:
(JSC::CopyVisitor::CopyVisitor):
(JSC::CopyVisitor::copyFromShared):
* heap/CopyVisitor.h:
* heap/CopyVisitorInlines.h:
(JSC::CopyVisitor::allocateNewSpaceSlow):
(JSC::CopyVisitor::startCopying):
(JSC::CopyVisitor::doneCopying):
(JSC::CopyVisitor::didCopy):
* heap/GCThread.cpp:
(JSC::GCThread::GCThread):
(JSC::GCThread::waitForNextPhase):
(JSC::GCThread::gcThreadMain):
* heap/GCThread.h:
* heap/GCThreadSharedData.cpp: Removed.
* heap/GCThreadSharedData.h: Removed.
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::~Heap):
(JSC::Heap::isPagedOut):
(JSC::Heap::markRoots):
(JSC::Heap::copyBackingStores):
(JSC::Heap::updateObjectCounts):
(JSC::Heap::resetVisitors):
(JSC::Heap::objectCount):
(JSC::Heap::sweepNextLogicallyEmptyWeakBlock):
(JSC::Heap::threadVisitCount):
(JSC::Heap::threadBytesVisited):
(JSC::Heap::threadBytesCopied):
(JSC::Heap::startNextPhase):
(JSC::Heap::endCurrentPhase):
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::unregisterWeakGCMap):
(JSC::Heap::getNextBlocksToCopy):
* heap/ListableHandler.h:
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::SlotVisitor):
(JSC::SlotVisitor::didStartMarking):
(JSC::SlotVisitor::reset):
(JSC::SlotVisitor::donateKnownParallel):
(JSC::SlotVisitor::drain):
(JSC::SlotVisitor::drainFromShared):
(JSC::SlotVisitor::mergeOpaqueRoots):
(JSC::SlotVisitor::harvestWeakReferences):
(JSC::SlotVisitor::finalizeUnconditionalFinalizers):
* heap/SlotVisitor.h:
(JSC::SlotVisitor::markStack):
(JSC::SlotVisitor::isEmpty):
(JSC::SlotVisitor::sharedData): Deleted.
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::addWeakReferenceHarvester):
(JSC::SlotVisitor::addUnconditionalFinalizer):
(JSC::SlotVisitor::addOpaqueRoot):
(JSC::SlotVisitor::containsOpaqueRoot):
(JSC::SlotVisitor::containsOpaqueRootTriState):
(JSC::SlotVisitor::opaqueRootCount):
(JSC::SlotVisitor::mergeOpaqueRootsIfNecessary):
(JSC::SlotVisitor::copyLater):
(JSC::SlotVisitor::heap):
(JSC::SlotVisitor::vm):
2015-09-22 Saam barati <sbarati@apple.com>
Web Inspector: [ES6] Improve Type Profiler Support for Arrow Functions
https://bugs.webkit.org/show_bug.cgi?id=143171
Reviewed by Joseph Pecoraro.
We now need to take into account TypeProfilerSearchDescriptor when
hashing results for type profiler queries. Before, we've gotten
away with not doing this because before we would never have a text
collision between a return type text offset and a normal expression text
offset. But, with arrow functions, we will have collisions when
the arrow function doesn't have parens around its single parameter.
I.e: "param => { ... };"
* runtime/TypeProfiler.cpp:
(JSC::TypeProfiler::findLocation):
* runtime/TypeProfiler.h:
(JSC::QueryKey::QueryKey):
(JSC::QueryKey::isHashTableDeletedValue):
(JSC::QueryKey::operator==):
(JSC::QueryKey::hash):
* tests/typeProfiler/arrow-functions.js: Added.
2015-09-22 Filip Pizlo <fpizlo@apple.com>
Get rid of ENABLE(PARALLEL_GC)
https://bugs.webkit.org/show_bug.cgi?id=149436
Reviewed by Mark Lam.
We always enable parallel GC everywhere but Windows, and it doesn't look like it was disabled
there for any good reason. So, get rid of the flag.
The only effect of this change is that parallel GC will now be enabled on Windows, provided
that the CPU detection finds more than one.
* heap/GCThread.cpp:
(JSC::GCThread::gcThreadMain):
* heap/GCThreadSharedData.cpp:
(JSC::GCThreadSharedData::resetChildren):
(JSC::GCThreadSharedData::childBytesCopied):
(JSC::GCThreadSharedData::GCThreadSharedData):
(JSC::GCThreadSharedData::~GCThreadSharedData):
(JSC::GCThreadSharedData::reset):
(JSC::GCThreadSharedData::didStartMarking):
* heap/Heap.cpp:
(JSC::Heap::converge):
(JSC::Heap::visitWeakHandles):
(JSC::Heap::updateObjectCounts):
(JSC::Heap::resetVisitors):
* heap/MarkedBlock.h:
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::didStartMarking):
(JSC::SlotVisitor::reset):
(JSC::SlotVisitor::drain):
(JSC::SlotVisitor::drainFromShared):
(JSC::SlotVisitor::mergeOpaqueRoots):
(JSC::JSString::tryHashConsLock):
(JSC::JSString::releaseHashConsLock):
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::addOpaqueRoot):
(JSC::SlotVisitor::containsOpaqueRoot):
(JSC::SlotVisitor::containsOpaqueRootTriState):
(JSC::SlotVisitor::opaqueRootCount):
(JSC::SlotVisitor::mergeOpaqueRootsIfNecessary):
* runtime/Options.cpp:
(JSC::computeNumberOfGCMarkers):
2015-09-22 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement min and max instructions in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=149454
Reviewed by Geoffrey Garen.
This patch implements min and max instructions in WebAssembly.
* tests/stress/wasm-arithmetic-float64.js:
* tests/stress/wasm-arithmetic-int32.js:
* tests/stress/wasm/arithmetic-float64.wasm:
* tests/stress/wasm/arithmetic-int32.wasm:
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::buildMinOrMaxI32):
(JSC::WASMFunctionCompiler::buildMinOrMaxF64):
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseExpressionI32):
(JSC::WASMFunctionParser::parseMinOrMaxExpressionI32):
(JSC::WASMFunctionParser::parseExpressionF64):
(JSC::WASMFunctionParser::parseMinOrMaxExpressionF64):
* wasm/WASMFunctionParser.h:
* wasm/WASMFunctionSyntaxChecker.h:
(JSC::WASMFunctionSyntaxChecker::buildMinOrMaxI32):
(JSC::WASMFunctionSyntaxChecker::buildMinOrMaxF64):
2015-09-22 Filip Pizlo <fpizlo@apple.com>
Get rid of ENABLE(GGC)
https://bugs.webkit.org/show_bug.cgi?id=149472
Reviewed by Mark Hahnenberg and Mark Lam.
Getting rid of this feature flag allows us to remove a lot of yuck.
* bytecode/CodeBlock.h:
(JSC::CodeBlockSet::mark):
(JSC::ScriptExecutable::forEachCodeBlock):
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generate):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
(JSC::DFG::osrWriteBarrier):
(JSC::DFG::adjustAndJumpToTarget):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::linkBranches):
(JSC::DFG::SpeculativeJIT::compileStoreBarrier):
(JSC::DFG::SpeculativeJIT::writeBarrier):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::masqueradesAsUndefinedWatchpointIsStillValid):
(JSC::DFG::SpeculativeJIT::selectScratchGPR):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier):
(JSC::DFG::SpeculativeJIT::compileObjectEquality):
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::writeBarrier):
(JSC::DFG::SpeculativeJIT::moveTrueTo):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier):
(JSC::DFG::SpeculativeJIT::compileObjectEquality):
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::writeBarrier):
(JSC::DFG::SpeculativeJIT::moveTrueTo):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::emitStoreBarrier):
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
(JSC::CodeBlockSet::dump):
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::markRoots):
(JSC::Heap::clearRememberedSet):
(JSC::Heap::updateObjectCounts):
(JSC::Heap::flushWriteBarrierBuffer):
(JSC::Heap::shouldDoFullCollection):
(JSC::Heap::addLogicallyEmptyWeakBlock):
* heap/HeapInlines.h:
(JSC::Heap::isWriteBarrierEnabled):
(JSC::Heap::writeBarrier):
(JSC::Heap::reportExtraMemoryAllocated):
(JSC::Heap::reportExtraMemoryVisited):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::clearMarks):
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::resetAllocators):
(JSC::MarkedSpace::visitWeakSets):
* heap/MarkedSpace.h:
(JSC::MarkedSpace::didAllocateInBlock):
(JSC::MarkedSpace::objectCount):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitWriteBarrier):
(JSC::JIT::emitIdentifierCheck):
(JSC::JIT::privateCompilePutByVal):
* llint/LLIntOfflineAsmConfig.h:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2015-09-22 Saam barati <sbarati@apple.com>
the toInt32 operation inside DFGSpeculativeJIT.cpp can't throw so we shouldn't emit an exceptionCheck after it.
https://bugs.webkit.org/show_bug.cgi?id=149467
Reviewed by Mark Lam.
The callOperation for toInt32 won't store a call site index in the call frame.
Therefore, if this is the first callOperation in the current compilation,
and we emit an exception check inside a try block, we will hit an assertion
saying that we must have DFGCommonData::codeOrigins.size() be > 0 inside
DFGCommonData::lastCallSite(). Therefore, it is imperative that we don't
emit exception checks for callOperations that don't throw exceptions and
don't store a call site index in the call frame.
* dfg/DFGCommonData.cpp:
(JSC::DFG::CommonData::lastCallSite):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueToInt32):
(JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
2015-09-22 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement the conditional instruction in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=149451
Reviewed by Geoffrey Garen.
This patch implements the conditional (ternary) instruction in WebAssembly.
This is basically "condition ? exp1 : exp2" in JavaScript.
The use of context.discard() in WASMFunctionParser::parseConditional()
is not ideal. We don't discard anything. We just use it to decrement the
stack top in the WebAssembly baseline JIT. When we optimize the JIT by
storing results directly into the destination like the JavaScript
baseline JIT, the code will look like this:
ContextExpression temp = context.newTemporary();
ContextExpression condition = parseExpressionI32(context);
context.jumpToTargetIf(Context::JumpCondition::Zero, condition, elseTarget);
parseExpression(context, temp, expressionType);
context.jumpToTarget(end);
context.linkTarget(elseTarget);
parseExpression(context, temp, expressionType);
context.linkTarget(end);
return temp;
which looks cleaner than using discard().
* tests/stress/wasm-control-flow.js:
* tests/stress/wasm/control-flow.wasm:
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseExpressionI32):
(JSC::WASMFunctionParser::parseExpressionF32):
(JSC::WASMFunctionParser::parseExpressionF64):
(JSC::WASMFunctionParser::parseConditional):
* wasm/WASMFunctionParser.h:
2015-09-22 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r189616.
https://bugs.webkit.org/show_bug.cgi?id=149456
suspected cause of multiple regressions (Requested by kling on
#webkit).
Reverted changeset:
"[JSC] Weak should only accept cell pointees."
https://bugs.webkit.org/show_bug.cgi?id=148955
http://trac.webkit.org/changeset/189616
2015-09-22 Saam barati <sbarati@apple.com>
Web Inspector: Basic Block Annotations and Type Profiler annotations wrong for script with "class" with default constructor
https://bugs.webkit.org/show_bug.cgi?id=149248
Reviewed by Mark Lam.
We keep track of which functions have and have not
executed so we can show visually, inside the inspector,
which functions have and have not executed. With a default
constructor, our parser parses code that isn't in the actual
JavaScript source code of the user. Our parser would then
give us a range of starting at "1" to "1 + default constructor length"
as being the text range of a function. But, this would then pollute
actual source code that was at these ranges.
Therefore, we should treat these default constructor source
codes as having "invalid" ranges. We use [UINT_MAX, UINT_MAX]
as the invalid range. This range has the effect of not polluting
valid ranges inside the source code.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
(JSC::UnlinkedFunctionExecutable::setInvalidTypeProfilingOffsets):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitNewDefaultConstructor):
2015-09-21 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement the comma instruction in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=149425
Reviewed by Geoffrey Garen.
This patch implements the comma instruction in WebAssembly. The comma
instruction evaluates the left operand and then the right operand and
returns the value of the right operand.
* tests/stress/wasm-comma.js: Added.
(shouldBe):
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::discard):
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseExpressionI32):
(JSC::WASMFunctionParser::parseExpressionF32):
(JSC::WASMFunctionParser::parseExpressionF64):
(JSC::WASMFunctionParser::parseComma):
* wasm/WASMFunctionParser.h:
* wasm/WASMFunctionSyntaxChecker.h:
(JSC::WASMFunctionSyntaxChecker::discard):
2015-09-21 Filip Pizlo <fpizlo@apple.com>
Always use the compiler's CAS implementation and get rid of ENABLE(COMPARE_AND_SWAP)
https://bugs.webkit.org/show_bug.cgi?id=149438
Reviewed by Mark Lam.
* heap/HeapInlines.h:
(JSC::Heap::reportExtraMemoryVisited):
(JSC::Heap::deprecatedReportExtraMemory):
2015-09-21 Saam barati <sbarati@apple.com>
functionProtoFuncToString should not rely on typeProfilingEndOffset()
https://bugs.webkit.org/show_bug.cgi?id=149429
Reviewed by Geoffrey Garen.
We should be able to freely change typeProfilingEndOffset()
without worrying we will break Function.prototype.toString.
* runtime/FunctionPrototype.cpp:
(JSC::functionProtoFuncToString):
2015-09-21 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r190086.
https://bugs.webkit.org/show_bug.cgi?id=149427
Broke LayoutTests/inspector/model/remote-object.htm (Requested
by saamyjoon on #webkit).
Reverted changeset:
"Web Inspector: Basic Block Annotations and Type Profiler
annotations wrong for script with "class" with default
constructor"
https://bugs.webkit.org/show_bug.cgi?id=149248
http://trac.webkit.org/changeset/190086
2015-09-21 Saam barati <sbarati@apple.com>
Web Inspector: Basic Block Annotations and Type Profiler annotations wrong for script with "class" with default constructor
https://bugs.webkit.org/show_bug.cgi?id=149248
Reviewed by Mark Lam.
We keep track of which functions have and have not
executed so we can show visually, inside the inspector,
which functions have and have not executed. With a default
constructor, our parser parses code that isn't in the actual
JavaScript source code of the user. Our parser would then
give us a range of starting at "1" to "1 + default constructor length"
as being the text range of a function. But, this would then pollute
actual source code that was at these ranges.
Therefore, we should treat these default constructor source
codes as having "invalid" ranges. We use [UINT_MAX, UINT_MAX]
as the invalid range. This range has the effect of not polluting
valid ranges inside the source code.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
(JSC::UnlinkedFunctionExecutable::setInvalidTypeProfilingOffsets):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitNewDefaultConstructor):
2015-09-21 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement call statements and call expressions of type void in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=149411
Reviewed by Mark Lam.
Call instructions in WebAssembly can be both statements and expressions.
This patch implements call statements. It also implements call
expressions of type void. The only place where call expressions of type
void can occur is the left-hand side of the comma (,) operator, which
will be implemented in a subsequent patch. The comma operator requires
both of its operands to be expressions.
* tests/stress/wasm-calls.js:
* tests/stress/wasm/calls.wasm:
* wasm/WASMConstants.h:
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseStatement):
(JSC::WASMFunctionParser::parseExpression):
(JSC::WASMFunctionParser::parseExpressionI32):
(JSC::WASMFunctionParser::parseExpressionF32):
(JSC::WASMFunctionParser::parseExpressionF64):
(JSC::WASMFunctionParser::parseExpressionVoid):
(JSC::WASMFunctionParser::parseCallInternal):
(JSC::WASMFunctionParser::parseCallIndirect):
(JSC::WASMFunctionParser::parseCallImport):
* wasm/WASMFunctionParser.h:
* wasm/WASMReader.cpp:
(JSC::WASMReader::readOpExpressionVoid):
* wasm/WASMReader.h:
2015-09-21 Filip Pizlo <fpizlo@apple.com>
JSC should infer property types
https://bugs.webkit.org/show_bug.cgi?id=148610
Reviewed by Geoffrey Garen.
This change brings recursive type inference to JavaScript object properties in JSC. We check that a
value being stored into a property obeys a property's type before we do the store. If it doesn't,
we broaden the property's type to include the new value. If optimized code was relying on the old
type, we deoptimize that code.
The type system that this supports includes important primitive types like Int32 and Boolean. But
it goes further and also includes a type kind called ObjectWithStructure, which means that we
expect the property to always point to objects with a particular structure. This only works for
leaf structures (i.e. structures that have a valid transition watchpoint set). Invalidation of the
transition set causes the property type to become Object (meaning an object with any structure).
This capability gives us recursive type inference. It's possible for an expression like "o.f.g.h"
to execute without any type checks if .f and .g are both ObjectWithStructure.
The type inference of a property is tracked by an InferredType instance, which is a JSCell. This
means that it manages its own memory. That's convenient. For example, when the DFG is interested in
one of these, it can just list the InferredType as a weak reference in addition to setting a
watchpoint. This ensures that even if the InferredType is dropped by the owning structure, the DFG
won't read a dangling pointer. A mapping from property name to InferredType is implemented by
InferredTypeTable, which is also a JSCell. Each Structure may point to some InferredTypeTable.
This feature causes programs to be happier (run faster without otherwise doing bad things like
using lots of memory) when four conditions hold:
1) A property converges to one of the types that we support.
2) The property is loaded from more frequently than it is stored to.
3) The stores are all cached, so that we statically emit a type check.
4) We don't allocate a lot of meta-data for the property's type.
We maximize the likelihood of (1) by having a rich type system. But having a rich type system means
that a reflective put to a property has to have a large switch over the inferred type to decide how
to do the type check. That's why we need (3). We ensure (3) by having every reflective property
store (i.e. putDirectInternal in any context that isn't PutById) force the inferred type to become
Top. We don't really worry about ensuring (2); this is statistically true for most programs
already.
Probably the most subtle trickery goes into (4). Logically we'd like to say that each
(Structure, Property) maps to its own InferredType. If structure S1 has a transition edge to S2,
then we could ensure that the InferredType I1 where (S1, Property)->I1 has a data flow constraint
to I2 where (S2, Property)->I2. That would work, but it would involve a lot of memory. And when I1
gets invalidated in some way, it would have to tell I2 about it, and then I2 might tell other
InferredType objects downstream. That's madness. So, the first major compromise that we make here
is to say that if some property has some InferredType at some Structure, then anytime we
transition from that Structure, the new Structure shares the same InferredType for that property.
This unifies the type of the property over the entire transition tree starting at the Structure at
which the property was added. But this would still mean that each Structure would have its own
InferredTypeTable. We don't want that because experience with PropertyTable shows that this can be
a major memory hog. So, we don't create an InferredTypeTable until someone adds a property that is
subject to type inference (i.e. it was added non-reflectively), and we share that InferredTypeTable
with the entire structure transition tree rooted at the Structure that had the first inferred
property. We also drop the InferredTypeTable anytime that we do a dictionary transition, and we
don't allow further property type inference if a structure had ever been a dictionary.
This is a 3% speed-up on Octane and a 12% speed-up on Kraken on my setup. It's not a significant
slow-down on any benchmark I ran.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::branchTest64):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::branchTest64):
(JSC::MacroAssemblerX86_64::test64):
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generate):
* bytecode/PutByIdFlags.cpp:
(WTF::printInternal):
* bytecode/PutByIdFlags.h:
(JSC::encodeStructureID):
(JSC::decodeStructureID):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
(JSC::PutByIdStatus::computeFor):
(JSC::PutByIdStatus::computeForStubInfo):
* bytecode/PutByIdVariant.cpp:
(JSC::PutByIdVariant::operator=):
(JSC::PutByIdVariant::replace):
(JSC::PutByIdVariant::transition):
(JSC::PutByIdVariant::setter):
(JSC::PutByIdVariant::attemptToMerge):
(JSC::PutByIdVariant::dumpInContext):
* bytecode/PutByIdVariant.h:
(JSC::PutByIdVariant::newStructure):
(JSC::PutByIdVariant::requiredType):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedInstruction::UnlinkedInstruction):
* bytecode/Watchpoint.h:
(JSC::InlineWatchpointSet::touch):
(JSC::InlineWatchpointSet::isBeingWatched):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::addConstantValue):
(JSC::BytecodeGenerator::emitPutById):
(JSC::BytecodeGenerator::emitDirectPutById):
* dfg/DFGAbstractInterpreter.h:
(JSC::DFG::AbstractInterpreter::filter):
(JSC::DFG::AbstractInterpreter::filterByValue):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
(JSC::DFG::AbstractInterpreter<AbstractStateType>::filter):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::setType):
(JSC::DFG::AbstractValue::set):
(JSC::DFG::AbstractValue::fixTypeForRepresentation):
(JSC::DFG::AbstractValue::mergeOSREntryValue):
(JSC::DFG::AbstractValue::isType):
(JSC::DFG::AbstractValue::filter):
(JSC::DFG::AbstractValue::filterValueByType):
* dfg/DFGAbstractValue.h:
(JSC::DFG::AbstractValue::setType):
(JSC::DFG::AbstractValue::isType):
(JSC::DFG::AbstractValue::validate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
(JSC::DFG::ByteCodeParser::handleGetByOffset):
(JSC::DFG::ByteCodeParser::handlePutByOffset):
(JSC::DFG::ByteCodeParser::load):
(JSC::DFG::ByteCodeParser::store):
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::handlePutById):
* dfg/DFGClobbersExitState.cpp:
(JSC::DFG::clobbersExitState):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
(JSC::DFG::ConstantFoldingPhase::emitGetByOffset):
(JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
(JSC::DFG::ConstantFoldingPhase::addBaseCheck):
* dfg/DFGDesiredInferredType.h: Added.
(JSC::DFG::DesiredInferredType::DesiredInferredType):
(JSC::DFG::DesiredInferredType::operator bool):
(JSC::DFG::DesiredInferredType::object):
(JSC::DFG::DesiredInferredType::expected):
(JSC::DFG::DesiredInferredType::isStillValid):
(JSC::DFG::DesiredInferredType::add):
(JSC::DFG::DesiredInferredType::operator==):
(JSC::DFG::DesiredInferredType::operator!=):
(JSC::DFG::DesiredInferredType::isHashTableDeletedValue):
(JSC::DFG::DesiredInferredType::hash):
(JSC::DFG::DesiredInferredType::dumpInContext):
(JSC::DFG::DesiredInferredType::dump):
(JSC::DFG::DesiredInferredTypeHash::hash):
(JSC::DFG::DesiredInferredTypeHash::equal):
* dfg/DFGDesiredWatchpoints.cpp:
(JSC::DFG::AdaptiveStructureWatchpointAdaptor::add):
(JSC::DFG::InferredTypeAdaptor::add):
(JSC::DFG::DesiredWatchpoints::DesiredWatchpoints):
(JSC::DFG::DesiredWatchpoints::~DesiredWatchpoints):
(JSC::DFG::DesiredWatchpoints::addLazily):
(JSC::DFG::DesiredWatchpoints::consider):
(JSC::DFG::DesiredWatchpoints::reallyAdd):
(JSC::DFG::DesiredWatchpoints::areStillValid):
(JSC::DFG::DesiredWatchpoints::dumpInContext):
* dfg/DFGDesiredWatchpoints.h:
(JSC::DFG::AdaptiveStructureWatchpointAdaptor::dumpInContext):
(JSC::DFG::InferredTypeAdaptor::hasBeenInvalidated):
(JSC::DFG::InferredTypeAdaptor::dumpInContext):
(JSC::DFG::DesiredWatchpoints::isWatched):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
(JSC::DFG::Graph::isSafeToLoad):
(JSC::DFG::Graph::inferredTypeFor):
(JSC::DFG::Graph::livenessFor):
(JSC::DFG::Graph::tryGetConstantProperty):
(JSC::DFG::Graph::inferredValueForProperty):
(JSC::DFG::Graph::tryGetConstantClosureVar):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::registerInferredType):
(JSC::DFG::Graph::inferredTypeForProperty):
* dfg/DFGInferredTypeCheck.cpp: Added.
(JSC::DFG::insertInferredTypeCheck):
* dfg/DFGInferredTypeCheck.h: Added.
* dfg/DFGNode.h:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* dfg/DFGPropertyTypeKey.h: Added.
(JSC::DFG::PropertyTypeKey::PropertyTypeKey):
(JSC::DFG::PropertyTypeKey::operator bool):
(JSC::DFG::PropertyTypeKey::structure):
(JSC::DFG::PropertyTypeKey::uid):
(JSC::DFG::PropertyTypeKey::operator==):
(JSC::DFG::PropertyTypeKey::operator!=):
(JSC::DFG::PropertyTypeKey::hash):
(JSC::DFG::PropertyTypeKey::isHashTableDeletedValue):
(JSC::DFG::PropertyTypeKey::dumpInContext):
(JSC::DFG::PropertyTypeKey::dump):
(JSC::DFG::PropertyTypeKey::deletedUID):
(JSC::DFG::PropertyTypeKeyHash::hash):
(JSC::DFG::PropertyTypeKeyHash::equal):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::SafeToExecuteEdge::operator()):
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileTypeOf):
(JSC::DFG::SpeculativeJIT::compileCheckStructure):
(JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
(JSC::DFG::SpeculativeJIT::speculateCell):
(JSC::DFG::SpeculativeJIT::speculateCellOrOther):
(JSC::DFG::SpeculativeJIT::speculateObject):
(JSC::DFG::SpeculativeJIT::speculate):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStoreBarrierInsertionPhase.cpp:
* dfg/DFGStructureAbstractValue.h:
(JSC::DFG::StructureAbstractValue::at):
(JSC::DFG::StructureAbstractValue::operator[]):
(JSC::DFG::StructureAbstractValue::onlyStructure):
(JSC::DFG::StructureAbstractValue::forEach):
* dfg/DFGUseKind.cpp:
(WTF::printInternal):
* dfg/DFGUseKind.h:
(JSC::DFG::typeFilterFor):
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::validate):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileCheckStructure):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCheckCell):
(JSC::FTL::DFG::LowerDFGToLLVM::compileMultiPutByOffset):
(JSC::FTL::DFG::LowerDFGToLLVM::numberOrNotCellToInt32):
(JSC::FTL::DFG::LowerDFGToLLVM::checkInferredType):
(JSC::FTL::DFG::LowerDFGToLLVM::loadProperty):
(JSC::FTL::DFG::LowerDFGToLLVM::speculate):
(JSC::FTL::DFG::LowerDFGToLLVM::speculateCell):
(JSC::FTL::DFG::LowerDFGToLLVM::speculateCellOrOther):
(JSC::FTL::DFG::LowerDFGToLLVM::speculateMachineInt):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::decodedCodeMapFor):
(JSC::AssemblyHelpers::branchIfNotType):
(JSC::AssemblyHelpers::purifyNaN):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::branchIfEqual):
(JSC::AssemblyHelpers::branchIfNotCell):
(JSC::AssemblyHelpers::branchIfCell):
(JSC::AssemblyHelpers::branchIfNotOther):
(JSC::AssemblyHelpers::branchIfInt32):
(JSC::AssemblyHelpers::branchIfNotInt32):
(JSC::AssemblyHelpers::branchIfNumber):
(JSC::AssemblyHelpers::branchIfNotNumber):
(JSC::AssemblyHelpers::branchIfEmpty):
(JSC::AssemblyHelpers::branchStructure):
* jit/Repatch.cpp:
(JSC::tryCachePutByID):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/InferredType.cpp: Added.
(JSC::InferredType::create):
(JSC::InferredType::destroy):
(JSC::InferredType::createStructure):
(JSC::InferredType::visitChildren):
(JSC::InferredType::kindForFlags):
(JSC::InferredType::Descriptor::forValue):
(JSC::InferredType::Descriptor::forFlags):
(JSC::InferredType::Descriptor::putByIdFlags):
(JSC::InferredType::Descriptor::merge):
(JSC::InferredType::Descriptor::removeStructure):
(JSC::InferredType::Descriptor::subsumes):
(JSC::InferredType::Descriptor::dumpInContext):
(JSC::InferredType::Descriptor::dump):
(JSC::InferredType::InferredType):
(JSC::InferredType::~InferredType):
(JSC::InferredType::canWatch):
(JSC::InferredType::addWatchpoint):
(JSC::InferredType::dump):
(JSC::InferredType::willStoreValueSlow):
(JSC::InferredType::makeTopSlow):
(JSC::InferredType::set):
(JSC::InferredType::removeStructure):
(JSC::InferredType::InferredStructureWatchpoint::fireInternal):
(JSC::InferredType::InferredStructureFinalizer::finalizeUnconditionally):
(JSC::InferredType::InferredStructure::InferredStructure):
(WTF::printInternal):
* runtime/InferredType.h: Added.
* runtime/InferredTypeTable.cpp: Added.
(JSC::InferredTypeTable::create):
(JSC::InferredTypeTable::destroy):
(JSC::InferredTypeTable::createStructure):
(JSC::InferredTypeTable::visitChildren):
(JSC::InferredTypeTable::get):
(JSC::InferredTypeTable::willStoreValue):
(JSC::InferredTypeTable::makeTop):
(JSC::InferredTypeTable::InferredTypeTable):
(JSC::InferredTypeTable::~InferredTypeTable):
* runtime/InferredTypeTable.h: Added.
* runtime/JSObject.h:
(JSC::JSObject::putDirectInternal):
(JSC::JSObject::putDirectWithoutTransition):
* runtime/Structure.cpp:
(JSC::Structure::materializePropertyMap):
(JSC::Structure::addPropertyTransition):
(JSC::Structure::removePropertyTransition):
(JSC::Structure::startWatchingInternalProperties):
(JSC::Structure::willStoreValueSlow):
(JSC::Structure::visitChildren):
(JSC::Structure::prototypeChainMayInterceptStoreTo):
* runtime/Structure.h:
(JSC::PropertyMapEntry::PropertyMapEntry):
* runtime/StructureInlines.h:
(JSC::Structure::get):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
* tests/stress/prop-type-boolean-then-string.js: Added.
* tests/stress/prop-type-int32-then-string.js: Added.
* tests/stress/prop-type-number-then-string.js: Added.
* tests/stress/prop-type-object-or-other-then-string.js: Added.
* tests/stress/prop-type-object-then-string.js: Added.
* tests/stress/prop-type-other-then-string.js: Added.
* tests/stress/prop-type-string-then-object.js: Added.
* tests/stress/prop-type-struct-or-other-then-string.js: Added.
* tests/stress/prop-type-struct-then-object.js: Added.
* tests/stress/prop-type-struct-then-object-opt.js: Added.
* tests/stress/prop-type-struct-then-object-opt-fold.js: Added.
* tests/stress/prop-type-struct-then-object-opt-multi.js: Added.
2015-09-21 Filip Pizlo <fpizlo@apple.com>
WebCore shouldn't have to include DFG headers
https://bugs.webkit.org/show_bug.cgi?id=149337
Reviewed by Michael Saboff.
This does some simple rewiring and outlining of CodeBlock/Heap functionality so that
those headers don't have to include DFG headers. As a result, WebCore no longer includes
DFG headers, except for two fairly innocent ones (DFGCommon.h and DFGCompilationMode.h).
This also changes the Xcode project file so that all but those two headers are Project
rather than Private. So, if WebCore accidentally includes any of them, we'll get a build
error.
The main group of headers that this prevents WebCore from including are the DFGDesired*.h
files and whatever those include. Those headers used to be fairly simple, but now they
are growing in complexity (especially with things like http://webkit.org/b/148610). So,
it makes sense to make sure they don't leak out of JSC.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::CallLinkInfo):
(JSC::CallLinkInfo::~CallLinkInfo):
(JSC::CallLinkInfo::clearStub):
(JSC::CallLinkInfo::visitWeak):
(JSC::CallLinkInfo::setFrameShuffleData):
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::isVarargsCallType):
(JSC::CallLinkInfo::specializationKindFor):
(JSC::CallLinkInfo::frameShuffleData):
(JSC::CallLinkInfo::CallLinkInfo): Deleted.
(JSC::CallLinkInfo::~CallLinkInfo): Deleted.
(JSC::CallLinkInfo::setFrameShuffleData): Deleted.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::getOrAddArrayProfile):
(JSC::CodeBlock::codeOrigins):
(JSC::CodeBlock::numberOfDFGIdentifiers):
(JSC::CodeBlock::identifier):
(JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::hasExpressionInfo):
(JSC::CodeBlock::hasCodeOrigins):
(JSC::CodeBlock::numberOfIdentifiers):
(JSC::CodeBlock::identifier):
(JSC::CodeBlock::codeOrigins): Deleted.
(JSC::CodeBlock::numberOfDFGIdentifiers): Deleted.
* bytecode/CodeOrigin.h:
* dfg/DFGDesiredIdentifiers.cpp:
* heap/Heap.cpp:
(JSC::Heap::didFinishIterating):
(JSC::Heap::completeAllDFGPlans):
(JSC::Heap::markRoots):
(JSC::Heap::deleteAllCodeBlocks):
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::deprecatedReportExtraMemory):
(JSC::Heap::forEachCodeBlock):
(JSC::Heap::forEachProtectedCell):
* runtime/Executable.h:
* runtime/JSCInlines.h:
(JSC::Heap::forEachCodeBlock): Deleted.
2015-09-21 Aleksandr Skachkov <gskachkov@gmail.com>
Web Inspector: arrow function names are never inferred, call frames are labeled (anonymous function)
https://bugs.webkit.org/show_bug.cgi?id=148318
Reviewed by Saam Barati.
Tiny change to support of the inferred name in arrow function
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createAssignResolve):
2015-09-19 Aleksandr Skachkov <gskachkov@gmail.com>
New tests introduced in r188545 fail on 32 bit ARM
https://bugs.webkit.org/show_bug.cgi?id=148376
Reviewed by Saam Barati.
Added correct support of the ARM CPU in JIT functions that are related to arrow function.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewFunction):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* jit/JITOpcodes.cpp:
(JSC::JIT::emitNewFuncExprCommon):
2015-09-21 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement Store expressions in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=149395
Reviewed by Geoffrey Garen.
The Store instruction in WebAssembly stores a value in the linear memory
at the given index. It can be both a statement and an expression. When
it is an expression, it returns the assigned value. This patch
implements Store as an expression.
Since Store uses two operands, which are the index and the value, we
need to pop the two operands from the stack and push the value back to
the stack. We can simply implement this by copying the value to where
the index is in the stack.
* tests/stress/wasm-linear-memory.js:
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::buildStore):
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseStatement):
(JSC::WASMFunctionParser::parseExpressionI32):
(JSC::WASMFunctionParser::parseExpressionF32):
(JSC::WASMFunctionParser::parseExpressionF64):
(JSC::WASMFunctionParser::parseStore):
* wasm/WASMFunctionParser.h:
* wasm/WASMFunctionSyntaxChecker.h:
(JSC::WASMFunctionSyntaxChecker::buildStore):
2015-09-20 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement SetLocal and SetGlobal expressions in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=149383
Reviewed by Saam Barati.
SetLocal and SetGlobal in WebAssembly can be both statements and
expressions. We have implemented the statement version. This patch
implements the expression version.
SetLocal and SetGlobal expressions return the assigned value.
Since SetLocal and SetGlobal use only one operand, which is the assigned
value, we can simply implement them by not removing the value from the
top of the stack.
* tests/stress/wasm-globals.js:
* tests/stress/wasm-locals.js:
* tests/stress/wasm/globals.wasm:
* tests/stress/wasm/locals.wasm:
* wasm/WASMConstants.h:
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::buildSetLocal):
(JSC::WASMFunctionCompiler::buildSetGlobal):
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseStatement):
(JSC::WASMFunctionParser::parseExpressionI32):
(JSC::WASMFunctionParser::parseExpressionF32):
(JSC::WASMFunctionParser::parseExpressionF64):
(JSC::WASMFunctionParser::parseSetLocal):
(JSC::WASMFunctionParser::parseSetGlobal):
(JSC::WASMFunctionParser::parseSetLocalStatement): Deleted.
(JSC::WASMFunctionParser::parseSetGlobalStatement): Deleted.
* wasm/WASMFunctionParser.h:
* wasm/WASMFunctionSyntaxChecker.h:
(JSC::WASMFunctionSyntaxChecker::buildSetLocal):
(JSC::WASMFunctionSyntaxChecker::buildSetGlobal):
2015-09-19 Aleksandr Skachkov <gskachkov@gmail.com>
[ES6] Added controlFlowProfiler test for arrow function
https://bugs.webkit.org/show_bug.cgi?id=145638
Reviewed by Saam Barati.
* Source/JavaScriptCore/tests/controlFlowProfiler/arrowfunction-expression.js: added
2015-09-20 Youenn Fablet <youenn.fablet@crf.canon.fr>
Remove XHR_TIMEOUT compilation guard
https://bugs.webkit.org/show_bug.cgi?id=149260
Reviewed by Benjamin Poulain.
* Configurations/FeatureDefines.xcconfig:
2015-09-19 Yusuke Suzuki <utatane.tea@gmail.com>
[GTK] Unreviewed, should check the result of fread
https://bugs.webkit.org/show_bug.cgi?id=148917
Suppress the build warning on GTK with GCC.
* jsc.cpp:
(fillBufferWithContentsOfFile):
(fetchModuleFromLocalFileSystem):
2015-09-19 Saam barati <sbarati@apple.com>
VariableEnvironmentNode should inherit from ParserArenaDeletable because VariableEnvironment's must have their destructors run
https://bugs.webkit.org/show_bug.cgi?id=149359
Reviewed by Andreas Kling.
VariableEnvironment must have its destructor run.
Therefore, VariableEnvironmentNode should inherit from ParserArenaDeletable.
Also, anything that inherits from VariableEnvironmentNode must use
ParserArenaDeletable's operator new. Also, any other nodes that own
a VariableEnvironment must also have their destructors run.
* parser/Nodes.h:
(JSC::VariableEnvironmentNode::VariableEnvironmentNode):
2015-09-18 Sukolsak Sakshuwong <sukolsak@gmail.com>
Remove duplicate code in the WebAssembly parser
https://bugs.webkit.org/show_bug.cgi?id=149361
Reviewed by Saam Barati.
Refactor the methods for parsing GetLocal and GetGlobal in WebAssembly
to remove duplicate code.
* wasm/WASMFunctionParser.cpp:
(JSC::nameOfType):
(JSC::WASMFunctionParser::parseExpressionI32):
(JSC::WASMFunctionParser::parseExpressionF32):
(JSC::WASMFunctionParser::parseExpressionF64):
(JSC::WASMFunctionParser::parseUnaryExpressionF64):
(JSC::WASMFunctionParser::parseBinaryExpressionF64):
(JSC::WASMFunctionParser::parseGetLocalExpression):
(JSC::WASMFunctionParser::parseGetGlobalExpression):
(JSC::WASMFunctionParser::parseGetLocalExpressionI32): Deleted.
(JSC::WASMFunctionParser::parseGetGlobalExpressionI32): Deleted.
(JSC::WASMFunctionParser::parseGetLocalExpressionF32): Deleted.
(JSC::WASMFunctionParser::parseGetGlobalExpressionF32): Deleted.
(JSC::WASMFunctionParser::parseGetLocalExpressionF64): Deleted.
(JSC::WASMFunctionParser::parseGetGlobalExpressionF64): Deleted.
* wasm/WASMFunctionParser.h:
2015-09-18 Saam barati <sbarati@apple.com>
Refactor common code between GetCatchHandlerFunctor and UnwindFunctor
https://bugs.webkit.org/show_bug.cgi?id=149276
Reviewed by Mark Lam.
There is currently code copy-pasted between these
two functors. Lets not do that. It's better to write
a function, even if the function is small.
I also did a bit of renaming to make the intent of the
unwindCallFrame function clear. The name of the function
didn't really indicate what it did. It decided if it was
okay to unwind further, and it also notified the debugger.
I've renamed the function to notifyDebuggerOfUnwinding.
And I've inlined the logic of deciding if it's okay
to unwind further into UnwindFunctor itself.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::isOpcode):
(JSC::getStackFrameCodeType):
(JSC::Interpreter::stackTraceAsString):
(JSC::findExceptionHandler):
(JSC::GetCatchHandlerFunctor::GetCatchHandlerFunctor):
(JSC::GetCatchHandlerFunctor::operator()):
(JSC::notifyDebuggerOfUnwinding):
(JSC::UnwindFunctor::UnwindFunctor):
(JSC::UnwindFunctor::operator()):
(JSC::Interpreter::notifyDebuggerOfExceptionToBeThrown):
(JSC::unwindCallFrame): Deleted.
2015-09-18 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement the arithmetic instructions for doubles in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=148945
Reviewed by Geoffrey Garen.
This patch implements the arithmetic instructions for doubles (float64)
in WebAssembly.
* tests/stress/wasm-arithmetic-float64.js:
* tests/stress/wasm/arithmetic-float64.wasm:
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::buildUnaryF64):
(JSC::WASMFunctionCompiler::buildBinaryF64):
(JSC::WASMFunctionCompiler::callOperation):
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseExpressionF64):
(JSC::WASMFunctionParser::parseUnaryExpressionF64):
(JSC::WASMFunctionParser::parseBinaryExpressionF64):
* wasm/WASMFunctionParser.h:
* wasm/WASMFunctionSyntaxChecker.h:
(JSC::WASMFunctionSyntaxChecker::buildUnaryF64):
(JSC::WASMFunctionSyntaxChecker::buildBinaryF32):
(JSC::WASMFunctionSyntaxChecker::buildBinaryF64):
2015-09-18 Basile Clement <basile_clement@apple.com>
[ES6] Tail call fast path should efficiently reuse the frame's stack space
https://bugs.webkit.org/show_bug.cgi?id=148662
Reviewed by Geoffrey Garen.
This introduces a new class (CallFrameShuffler) that is responsible for
efficiently building the new frames when performing a tail call. In
order for Repatch to know about the position of arguments on the
stack/registers (e.g. for polymorphic call inline caches), we store a
CallFrameShuffleData in the CallLinkInfo. Otherwise, the JIT and DFG
compiler are now using CallFrameShuffler instead of
CCallHelpers::prepareForTailCallSlow() to build the frame for a tail
call.
When taking a slow path, we still build the frame as if doing a regular
call, because we could throw an exception and need the caller's frame
at that point. This means that for virtual calls, we don't benefit from
the efficient frame move for now.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::firstRegister):
(JSC::ARMv7Assembler::lastRegister):
(JSC::ARMv7Assembler::firstFPRegister):
(JSC::ARMv7Assembler::lastFPRegister):
* assembler/AbortReason.h:
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::setFrameShuffleData):
(JSC::CallLinkInfo::frameShuffleData):
* bytecode/ValueRecovery.h:
(JSC::ValueRecovery::inRegister):
* dfg/DFGGenerationInfo.h:
(JSC::DFG::GenerationInfo::recovery):
* jit/CachedRecovery.cpp: Added.
(JSC::CachedRecovery::loadsIntoFPR):
(JSC::CachedRecovery::loadsIntoGPR):
* jit/CachedRecovery.h: Added.
(JSC::CachedRecovery::CachedRecovery):
(JSC::CachedRecovery::targets):
(JSC::CachedRecovery::addTarget):
(JSC::CachedRecovery::removeTarget):
(JSC::CachedRecovery::clearTargets):
(JSC::CachedRecovery::setWantedJSValueRegs):
(JSC::CachedRecovery::setWantedFPR):
(JSC::CachedRecovery::boxingRequiresGPR):
(JSC::CachedRecovery::boxingRequiresFPR):
(JSC::CachedRecovery::recovery):
(JSC::CachedRecovery::setRecovery):
(JSC::CachedRecovery::wantedJSValueRegs):
(JSC::CachedRecovery::wantedFPR):
* jit/CallFrameShuffleData.cpp: Added.
(JSC::CallFrameShuffleData::setupCalleeSaveRegisters):
* jit/CallFrameShuffleData.h: Added.
* jit/CallFrameShuffler.cpp: Added.
(JSC::CallFrameShuffler::CallFrameShuffler):
(JSC::CallFrameShuffler::dump):
(JSC::CallFrameShuffler::getCachedRecovery):
(JSC::CallFrameShuffler::setCachedRecovery):
(JSC::CallFrameShuffler::spill):
(JSC::CallFrameShuffler::emitDeltaCheck):
(JSC::CallFrameShuffler::prepareForSlowPath):
(JSC::CallFrameShuffler::prepareForTailCall):
(JSC::CallFrameShuffler::tryWrites):
(JSC::CallFrameShuffler::performSafeWrites):
(JSC::CallFrameShuffler::prepareAny):
* jit/CallFrameShuffler.h: Added.
(JSC::CallFrameShuffler::lockGPR):
(JSC::CallFrameShuffler::acquireGPR):
(JSC::CallFrameShuffler::releaseGPR):
(JSC::CallFrameShuffler::snapshot):
(JSC::CallFrameShuffler::setCalleeJSValueRegs):
(JSC::CallFrameShuffler::assumeCalleeIsCell):
(JSC::CallFrameShuffler::canBox):
(JSC::CallFrameShuffler::ensureBox):
(JSC::CallFrameShuffler::ensureLoad):
(JSC::CallFrameShuffler::canLoadAndBox):
(JSC::CallFrameShuffler::updateRecovery):
(JSC::CallFrameShuffler::clearCachedRecovery):
(JSC::CallFrameShuffler::addCachedRecovery):
(JSC::CallFrameShuffler::numLocals):
(JSC::CallFrameShuffler::getOld):
(JSC::CallFrameShuffler::setOld):
(JSC::CallFrameShuffler::firstOld):
(JSC::CallFrameShuffler::lastOld):
(JSC::CallFrameShuffler::isValidOld):
(JSC::CallFrameShuffler::argCount):
(JSC::CallFrameShuffler::getNew):
(JSC::CallFrameShuffler::setNew):
(JSC::CallFrameShuffler::addNew):
(JSC::CallFrameShuffler::firstNew):
(JSC::CallFrameShuffler::lastNew):
(JSC::CallFrameShuffler::isValidNew):
(JSC::CallFrameShuffler::newAsOld):
(JSC::CallFrameShuffler::getFreeRegister):
(JSC::CallFrameShuffler::getFreeGPR):
(JSC::CallFrameShuffler::getFreeFPR):
(JSC::CallFrameShuffler::hasFreeRegister):
(JSC::CallFrameShuffler::ensureRegister):
(JSC::CallFrameShuffler::ensureGPR):
(JSC::CallFrameShuffler::ensureFPR):
(JSC::CallFrameShuffler::addressForOld):
(JSC::CallFrameShuffler::isUndecided):
(JSC::CallFrameShuffler::isSlowPath):
(JSC::CallFrameShuffler::addressForNew):
(JSC::CallFrameShuffler::dangerFrontier):
(JSC::CallFrameShuffler::isDangerNew):
(JSC::CallFrameShuffler::updateDangerFrontier):
(JSC::CallFrameShuffler::hasOnlySafeWrites):
* jit/CallFrameShuffler32_64.cpp: Added.
(JSC::CallFrameShuffler::emitStore):
(JSC::CallFrameShuffler::emitBox):
(JSC::CallFrameShuffler::emitLoad):
(JSC::CallFrameShuffler::canLoad):
(JSC::CallFrameShuffler::emitDisplace):
* jit/CallFrameShuffler64.cpp: Added.
(JSC::CallFrameShuffler::emitStore):
(JSC::CallFrameShuffler::emitBox):
(JSC::CallFrameShuffler::emitLoad):
(JSC::CallFrameShuffler::canLoad):
(JSC::CallFrameShuffler::emitDisplace):
* jit/JITCall.cpp:
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
* jit/RegisterMap.cpp:
(JSC::RegisterMap::RegisterMap):
(JSC::GPRMap::GPRMap):
(JSC::FPRMap::FPRMap):
* jit/Repatch.cpp:
(JSC::linkPolymorphicCall):
2015-09-18 Saam barati <sbarati@apple.com>
Implement try/catch in the DFG.
https://bugs.webkit.org/show_bug.cgi?id=147374
Reviewed by Filip Pizlo.
This patch implements try/catch inside the DFG JIT.
It also prevents tier up to the FTL for any functions
that have an op_catch in them that are DFG compiled.
This patch accomplishes implementing try/catch inside
the DFG by OSR exiting to op_catch when an exception is thrown.
We can OSR exit from an exception inside the DFG in two ways:
1) We have a JS call (can also be via implicit getter/setter in GetById/PutById)
2) We have an exception when returing from a callOperation
In the case of (1), we get to the OSR exit from genericUnwind because
the exception was thrown in a child call frame. This means these
OSR exits must act as defacto op_catches (even though we will still OSR
exit to a baseline op_catch). That means they must restore the stack pointer
and call frame.
In the case of (2), we can skip genericUnwind because we know the exception
check will take us to a particular OSR exit. Instead, we link these
exception checks as jumps to a particular OSR exit.
Both types of OSR exits will exit into op_catch inside the baseline JIT.
Because they exit to op_catch, these OSR exits must set callFrameForCatch
to the proper call frame pointer.
We "handle" all exceptions inside the machine frame of the DFG code
block. This means the machine code block is responsible for "catching"
exceptions of any inlined frames' try/catch. OSR exit will then exit to
the proper baseline CodeBlock after reifying the inlined frames
(DFG::OSRExit::m_codeOrigin corresponds to the op_catch we will exit to).
Also, genericUnwind will never consult an inlined call frame's CodeBlock to
see if they can catch the exception because they can't. We always unwind to the
next machine code block frame. The DFG CodeBlock changes how the exception
handler table is keyed: it is now keyed by CallSiteIndex for DFG code blocks.
So, when consulting call sites that throw, we keep track of the CallSiteIndex,
and the HandlerInfo for the corresponding baseline exception handler for
that particular CallSiteIndex (if an exception at that call site will be caught).
Then, when we're inside DFG::JITCompiler::link(), we install new HandlerInfo's
inside the DFG CodeBlock and key it by the corresponding CallSiteIndex.
(The CodeBlock only has HandlerInfos for the OSR exits that are to be arrived
at from genericUnwind).
Also, each OSR exit will know if it acting as an exception handler, and
whether or not it will be arrived at from genericUnwind. When we know we
will arrive at an OSR exit from genericUnwind, we set the corresponding
HandlerInfo's nativeCode CodeLocationLabel field to be the OSR exit.
This patch also introduces a new Phase inside the DFG that ensures
that DFG CodeBlocks that handle exceptions take the necessary
steps to keep live variables at "op_catch" live according the
OSR exit value recovery machinery. We accomplish this by flushing
all live op_catch variables to the stack when inside a "try" block.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::handlerForBytecodeOffset):
(JSC::CodeBlock::handlerForIndex):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::clearExceptionHandlers):
(JSC::CodeBlock::appendExceptionHandler):
* bytecode/PreciseJumpTargets.cpp:
(JSC::computePreciseJumpTargets):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::getLocal):
(JSC::DFG::ByteCodeParser::setLocal):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGCommonData.cpp:
(JSC::DFG::CommonData::addCodeOrigin):
(JSC::DFG::CommonData::lastCallSite):
(JSC::DFG::CommonData::shrinkToFit):
* dfg/DFGCommonData.h:
* dfg/DFGGraph.h:
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::linkOSRExits):
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::noticeOSREntry):
(JSC::DFG::JITCompiler::appendExceptionHandlingOSRExit):
(JSC::DFG::JITCompiler::willCatchExceptionInMachineFrame):
(JSC::DFG::JITCompiler::exceptionCheck):
(JSC::DFG::JITCompiler::recordCallSiteAndGenerateExceptionHandlingOSRExitIfNeeded):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::emitStoreCodeOrigin):
(JSC::DFG::JITCompiler::emitStoreCallSiteIndex):
(JSC::DFG::JITCompiler::appendCall):
(JSC::DFG::JITCompiler::exceptionCheckWithCallFrameRollback):
(JSC::DFG::JITCompiler::blockHeads):
(JSC::DFG::JITCompiler::exceptionCheck): Deleted.
* dfg/DFGLiveCatchVariablePreservationPhase.cpp: Added.
(JSC::DFG::FlushLiveCatchVariablesInsertionPhase::FlushLiveCatchVariablesInsertionPhase):
(JSC::DFG::FlushLiveCatchVariablesInsertionPhase::run):
(JSC::DFG::FlushLiveCatchVariablesInsertionPhase::willCatchException):
(JSC::DFG::FlushLiveCatchVariablesInsertionPhase::handleBlock):
(JSC::DFG::FlushLiveCatchVariablesInsertionPhase::newVariableAccessData):
(JSC::DFG::performLiveCatchVariablePreservationPhase):
* dfg/DFGLiveCatchVariablePreservationPhase.h: Added.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::OSRExit):
(JSC::DFG::OSRExit::setPatchableCodeOffset):
* dfg/DFGOSRExit.h:
(JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
* dfg/DFGOSRExitCompiler.cpp:
* dfg/DFGOSRExitCompiler32_64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompiler64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::osrWriteBarrier):
(JSC::DFG::adjustAndJumpToTarget):
* dfg/DFGOSRExitCompilerCommon.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGSlowPathGenerator.h:
(JSC::DFG::SlowPathGenerator::SlowPathGenerator):
(JSC::DFG::SlowPathGenerator::~SlowPathGenerator):
(JSC::DFG::SlowPathGenerator::generate):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetById):
(JSC::DFG::SpeculativeJIT::cachedPutById):
(JSC::DFG::SpeculativeJIT::emitCall):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetById):
(JSC::DFG::SpeculativeJIT::cachedPutById):
(JSC::DFG::SpeculativeJIT::emitCall):
* dfg/DFGTierUpCheckInjectionPhase.cpp:
(JSC::DFG::TierUpCheckInjectionPhase::run):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* interpreter/Interpreter.cpp:
(JSC::GetCatchHandlerFunctor::operator()):
(JSC::UnwindFunctor::operator()):
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::gotoNextFrame):
(JSC::StackVisitor::unwindToMachineCodeBlockFrame):
(JSC::StackVisitor::readFrame):
* interpreter/StackVisitor.h:
(JSC::StackVisitor::operator*):
(JSC::StackVisitor::operator->):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitExceptionCheck):
(JSC::AssemblyHelpers::emitNonPatchableExceptionCheck):
(JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitCount):
* jit/JITExceptions.cpp:
(JSC::genericUnwind):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_catch):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_catch):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
(JSC::VM::clearException):
(JSC::VM::clearLastException):
(JSC::VM::addressOfCallFrameForCatch):
(JSC::VM::exception):
(JSC::VM::addressOfException):
* tests/stress/dfg-exception-try-catch-in-constructor-with-inlined-throw.js: Added.
(f):
(bar):
(Foo):
* tests/stress/es6-for-of-loop-exception.js: Added.
(assert):
(shouldThrowInvalidConstAssignment):
(baz):
(foo):
* tests/stress/exception-dfg-inlined-frame-not-strict-equal.js: Added.
(assert):
(o.valueOf):
(o.toString):
(read):
(bar):
(foo):
* tests/stress/exception-dfg-not-strict-equal.js: Added.
(foo):
(o.valueOf):
(o.toString):
(assert):
(shouldDoSomethingInFinally):
(catch):
* tests/stress/exception-dfg-operation-read-value.js: Added.
(assert):
(o.valueOf):
(o.toString):
(read):
(foo):
* tests/stress/exception-dfg-throw-from-catch-block.js: Added.
(assert):
(baz):
(bar):
(foo):
2015-09-18 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement linear memory instructions in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=149326
Reviewed by Geoffrey Garen.
This patch implements linear memory instructions in WebAssembly.[1] To
use the linear memory, an ArrayBuffer must be passed to loadWebAssembly().
Notes:
- We limit the ArrayBuffer's byte length to 2^31 - 1. This enables us to
use only one comparison (unsigned greater than) to check for
out-of-bounds access.
- There is no consensus yet on what should happen when an out-of-bounds
access occurs.[2] For now, we throw an error when that happens.
- In asm.js, a heap access looks like this: int32Array[i >> 2]. Note
that ">> 2" is part of the syntax and is required. pack-asmjs will
produce bytecodes that look something like "LoadI32, i" (not
"LoadI32, ShiftRightI32, i, 2"). The requirement of the shift operator
prevents unaligned accesses in asm.js. (There is a proposal to support
unaligned accesses in the future version of asm.js using DataView.[3])
The WebAssembly spec allows unaligned accesses.[4] But since we use
asm.js for testing, we follow asm.js's behaviors for now.
[1]: https://github.com/WebAssembly/design/blob/master/AstSemantics.md#linear-memory
[2]: https://github.com/WebAssembly/design/blob/master/AstSemantics.md#out-of-bounds
[3]: https://wiki.mozilla.org/Javascript:SpiderMonkey:OdinMonkey#Possible_asm.js_extensions_that_don.27t_require_new_JS_features
[4]: https://github.com/WebAssembly/design/blob/master/AstSemantics.md#alignment
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jsc.cpp:
(GlobalObject::finishCreation):
(functionLoadWebAssembly):
* tests/stress/wasm-linear-memory.js: Added.
(shouldBe):
(shouldThrow):
* tests/stress/wasm/linear-memory.wasm: Added.
* wasm/JSWASMModule.cpp:
(JSC::JSWASMModule::JSWASMModule):
(JSC::JSWASMModule::visitChildren):
* wasm/JSWASMModule.h:
(JSC::JSWASMModule::create):
(JSC::JSWASMModule::arrayBuffer):
(JSC::JSWASMModule::JSWASMModule): Deleted.
* wasm/WASMConstants.h:
* wasm/WASMFunctionCompiler.h:
(JSC::sizeOfMemoryType):
(JSC::WASMFunctionCompiler::MemoryAddress::MemoryAddress):
(JSC::WASMFunctionCompiler::endFunction):
(JSC::WASMFunctionCompiler::buildLoad):
(JSC::WASMFunctionCompiler::buildStore):
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseStatement):
(JSC::WASMFunctionParser::parseExpressionI32):
(JSC::WASMFunctionParser::parseExpressionF32):
(JSC::WASMFunctionParser::parseExpressionF64):
(JSC::WASMFunctionParser::parseMemoryAddress):
(JSC::WASMFunctionParser::parseLoad):
(JSC::WASMFunctionParser::parseStore):
* wasm/WASMFunctionParser.h:
* wasm/WASMFunctionSyntaxChecker.h:
(JSC::WASMFunctionSyntaxChecker::MemoryAddress::MemoryAddress):
(JSC::WASMFunctionSyntaxChecker::buildLoad):
(JSC::WASMFunctionSyntaxChecker::buildStore):
* wasm/WASMModuleParser.cpp:
(JSC::WASMModuleParser::WASMModuleParser):
(JSC::WASMModuleParser::parseModule):
(JSC::parseWebAssembly):
(JSC::WASMModuleParser::parse): Deleted.
* wasm/WASMModuleParser.h:
2015-09-18 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement type conversion instructions in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=149340
Reviewed by Mark Lam.
This patch implements some type conversion instructions in WebAssembly.
The WebAssembly spec has a lot more type conversion instructions than
what are available in asm.js.[1] We only implement the ones that are in
asm.js for now because we can only test those.
[1]: https://github.com/WebAssembly/design/blob/master/AstSemantics.md
* tests/stress/wasm-type-conversion.js:
* tests/stress/wasm/type-conversion.wasm:
* wasm/WASMConstants.h:
* wasm/WASMFunctionCompiler.h:
(JSC::operationConvertUnsignedInt32ToDouble):
(JSC::WASMFunctionCompiler::buildConvertType):
(JSC::WASMFunctionCompiler::callOperation):
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseExpressionI32):
(JSC::WASMFunctionParser::parseExpressionF32):
(JSC::WASMFunctionParser::parseExpressionF64):
(JSC::WASMFunctionParser::parseConvertType):
* wasm/WASMFunctionParser.h:
* wasm/WASMFunctionSyntaxChecker.h:
(JSC::WASMFunctionSyntaxChecker::buildConvertType):
2015-09-18 Alex Christensen <achristensen@webkit.org>
Fix tests on Windows after switching to CMake.
https://bugs.webkit.org/show_bug.cgi?id=149339
Reviewed by Brent Fulgham.
* shell/PlatformWin.cmake:
Build testapi and testRegExp (which doesn't seem to be used any more).
2015-09-17 Brian Burg <bburg@apple.com>
ASSERT(!m_frontendRouter->hasLocalFrontend()) when running Web Inspector tests
https://bugs.webkit.org/show_bug.cgi?id=149006
Reviewed by Joseph Pecoraro.
Prior to disconnecting, we need to know how many frontends remain connected.
* inspector/InspectorFrontendRouter.h: Add frontendCount().
2015-09-18 Yusuke Suzuki <utatane.tea@gmail.com>
Explicitly specify builtin JS files dependency
https://bugs.webkit.org/show_bug.cgi?id=149323
Reviewed by Alex Christensen.
JSCBuiltins.{h,cpp} in CMakeLists.txt and DerivedSources.make just depend on the builtins directory.
As a result, even if we modify builtins/*.js code, regenerating JSCBuiltins.{h,cpp} does not occur.
As the same to the cpp sources, let's list up the JS files explicitly.
* CMakeLists.txt:
* DerivedSources.make:
2015-09-18 Michael Saboff <msaboff@apple.com>
Remove register preservation and restoration stub code
https://bugs.webkit.org/show_bug.cgi?id=149335
Reviewed by Mark Lam.
Delete the register preservation and restoration thunks and related plumbing.
Much of this change is removing the unneeded RegisterPreservationMode parameter
from various functions.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::isVarargsCallType):
(JSC::CallLinkInfo::CallLinkInfo):
(JSC::CallLinkInfo::isVarargs):
(JSC::CallLinkInfo::isLinked):
(JSC::CallLinkInfo::setUpCallFromFTL):
(JSC::CallLinkInfo::registerPreservationMode): Deleted.
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::initializeAddressForCall):
(JSC::FTL::JITCode::addressForCall):
* ftl/FTLJITCode.h:
* ftl/FTLOSREntry.cpp:
(JSC::FTL::prepareOSREntry):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* jit/JITCode.cpp:
(JSC::JITCode::execute):
(JSC::DirectJITCode::initializeCodeRef):
(JSC::DirectJITCode::addressForCall):
(JSC::NativeJITCode::initializeCodeRef):
(JSC::NativeJITCode::addressForCall):
(JSC::DirectJITCode::ensureWrappers): Deleted.
* jit/JITCode.h:
(JSC::JITCode::jitTypeFor):
(JSC::JITCode::executableAddress):
* jit/JITOperations.cpp:
* jit/RegisterPreservationWrapperGenerator.cpp: Removed.
* jit/RegisterPreservationWrapperGenerator.h: Removed.
* jit/Repatch.cpp:
(JSC::linkPolymorphicCall):
* jit/ThunkGenerators.cpp:
(JSC::virtualThunkFor):
* jit/ThunkGenerators.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::entryOSR):
(JSC::LLInt::setUpCall):
* runtime/Executable.cpp:
(JSC::ExecutableBase::clearCode):
(JSC::ScriptExecutable::installCode):
(JSC::WebAssemblyExecutable::prepareForExecution):
* runtime/Executable.h:
(JSC::ExecutableBase::generatedJITCodeFor):
(JSC::ExecutableBase::entrypointFor):
(JSC::ExecutableBase::offsetOfJITCodeWithArityCheckFor):
* runtime/RegisterPreservationMode.h: Removed.
2015-09-17 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Remove unused canClearBrowserCookies / canClearBrowserCache protocol methods
https://bugs.webkit.org/show_bug.cgi?id=149307
Reviewed by Brian Burg.
* inspector/protocol/Network.json:
Remove unused protocol methods.
2015-09-17 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r189938, r189952, and r189956.
https://bugs.webkit.org/show_bug.cgi?id=149329
Broke Web Workers (Requested by ap on #webkit).
Reverted changesets:
"Implement try/catch in the DFG."
https://bugs.webkit.org/show_bug.cgi?id=147374
http://trac.webkit.org/changeset/189938
"CLoop build fix after r189938."
http://trac.webkit.org/changeset/189952
"add a regress test for richards with try/catch."
https://bugs.webkit.org/show_bug.cgi?id=149301
http://trac.webkit.org/changeset/189956
2015-09-17 Ryosuke Niwa <rniwa@webkit.org>
CLoop build fix after r189938.
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::unwindToMachineCodeBlockFrame):
2015-09-17 Sukolsak Sakshuwong <sukolsak@gmail.com>
Convert return values from JavaScript functions to the expected types in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=149200
Reviewed by Mark Lam.
When a WebAssembly function calls a JavaScript function, there is no
guarantee that the JavaScript function will always return values of the
type we expect. This patch converts the return values to the expected
types.
(The reverse is also true: When a WebAssembly function is called from a
JavaScript function, there is no guarantee that the arguments to the
WebAssembly function will always be of the types we expect. We have
fixed this in Bug 149033.)
We don't need to type check the return values if the callee is a
WebAssembly function. We don't need to type check the arguments if the
caller is a WebAssembly function. This optimization will be
implemented in the future. See https://bugs.webkit.org/show_bug.cgi?id=149310
* tests/stress/wasm-type-conversion.js:
* tests/stress/wasm/type-conversion.wasm:
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::startFunction):
(JSC::WASMFunctionCompiler::buildReturn):
(JSC::WASMFunctionCompiler::boxArgumentsAndAdjustStackPointer):
(JSC::WASMFunctionCompiler::callAndUnboxResult):
(JSC::WASMFunctionCompiler::convertValueToInt32):
(JSC::WASMFunctionCompiler::convertValueToDouble):
(JSC::WASMFunctionCompiler::convertDoubleToValue):
(JSC::WASMFunctionCompiler::loadValueAndConvertToInt32): Deleted.
(JSC::WASMFunctionCompiler::loadValueAndConvertToDouble): Deleted.
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseExpressionI32):
(JSC::WASMFunctionParser::parseExpressionF32):
(JSC::WASMFunctionParser::parseExpressionF64):
(JSC::WASMFunctionParser::parseCallInternalExpressionI32): Deleted.
* wasm/WASMFunctionParser.h:
2015-09-17 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Add more fine-grained APIs and additional hooks to control module loader from WebCore
https://bugs.webkit.org/show_bug.cgi?id=149129
Reviewed by Saam Barati.
No behavior change.
Module tag `<script type="module>` will be executed asynchronously.
But we would like to fetch the resources before when the postTask-ed task is performed.
So instead of 1 API that fetch, instantiate and execute the module,
we need 2 fine-grained APIs.
1. Fetch and initialize a module, but not execute it yet.
2. Link and execute a module specified by the key (this will be invoked asynchronously).
And to instrument the script execution (like reporting the execution time of the module to
the inspector), we need a hook to inject code around an execution of a module body.
* builtins/ModuleLoaderObject.js:
(moduleEvaluation):
(loadAndEvaluateModule):
(loadModule):
(linkAndEvaluateModule):
* jsc.cpp:
(functionLoadModule):
(runWithScripts):
* runtime/Completion.cpp:
(JSC::identifierToJSValue):
(JSC::createSymbolForEntryPointModule):
(JSC::rejectPromise):
(JSC::loadAndEvaluateModule):
(JSC::loadModule):
(JSC::linkAndEvaluateModule):
(JSC::evaluateModule): Deleted.
* runtime/Completion.h:
* runtime/JSGlobalObject.cpp:
* runtime/JSGlobalObject.h:
* runtime/JSModuleRecord.cpp:
(JSC::JSModuleRecord::evaluate):
(JSC::JSModuleRecord::execute): Deleted.
* runtime/JSModuleRecord.h:
* runtime/ModuleLoaderObject.cpp:
(JSC::ModuleLoaderObject::loadAndEvaluateModule):
(JSC::ModuleLoaderObject::linkAndEvaluateModule):
(JSC::ModuleLoaderObject::evaluate):
(JSC::moduleLoaderObjectEvaluate):
* runtime/ModuleLoaderObject.h:
2015-09-17 Saam barati <sbarati@apple.com>
Implement try/catch in the DFG.
https://bugs.webkit.org/show_bug.cgi?id=147374
Reviewed by Filip Pizlo.
This patch implements try/catch inside the DFG JIT.
It also prevents tier up to the FTL for any functions
that have an op_catch in them that are DFG compiled.
This patch accomplishes implementing try/catch inside
the DFG by OSR exiting to op_catch when an exception is thrown.
We can OSR exit from an exception inside the DFG in two ways:
1) We have a JS call (can also be via implicit getter/setter in GetById/PutById)
2) We have an exception when returing from a callOperation
In the case of (1), we get to the OSR exit from genericUnwind because
the exception was thrown in a child call frame. This means these
OSR exits must act as defacto op_catches (even though we will still OSR
exit to a baseline op_catch). That means they must restore the stack pointer
and call frame.
In the case of (2), we can skip genericUnwind because we know the exception
check will take us to a particular OSR exit. Instead, we link these
exception checks as jumps to a particular OSR exit.
Both types of OSR exits will exit into op_catch inside the baseline JIT.
Because they exit to op_catch, these OSR exits must set callFrameForCatch
to the proper call frame pointer.
We "handle" all exceptions inside the machine frame of the DFG code
block. This means the machine code block is responsible for "catching"
exceptions of any inlined frames' try/catch. OSR exit will then exit to
the proper baseline CodeBlock after reifying the inlined frames
(DFG::OSRExit::m_codeOrigin corresponds to the op_catch we will exit to).
Also, genericUnwind will never consult an inlined call frame's CodeBlock to
see if they can catch the exception because they can't. We always unwind to the
next machine code block frame. The DFG CodeBlock changes how the exception
handler table is keyed: it is now keyed by CallSiteIndex for DFG code blocks.
So, when consulting call sites that throw, we keep track of the CallSiteIndex,
and the HandlerInfo for the corresponding baseline exception handler for
that particular CallSiteIndex (if an exception at that call site will be caught).
Then, when we're inside DFG::JITCompiler::link(), we install new HandlerInfo's
inside the DFG CodeBlock and key it by the corresponding CallSiteIndex.
(The CodeBlock only has HandlerInfos for the OSR exits that are to be arrived
at from genericUnwind).
Also, each OSR exit will know if it acting as an exception handler, and
whether or not it will be arrived at from genericUnwind. When we know we
will arrive at an OSR exit from genericUnwind, we set the corresponding
HandlerInfo's nativeCode CodeLocationLabel field to be the OSR exit.
This patch also introduces a new Phase inside the DFG that ensures
that DFG CodeBlocks that handle exceptions take the necessary
steps to keep live variables at "op_catch" live according the
OSR exit value recovery machinery. We accomplish this by flushing
all live op_catch variables to the stack when inside a "try" block.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::handlerForBytecodeOffset):
(JSC::CodeBlock::handlerForIndex):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::clearExceptionHandlers):
(JSC::CodeBlock::appendExceptionHandler):
* bytecode/PreciseJumpTargets.cpp:
(JSC::computePreciseJumpTargets):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::getLocal):
(JSC::DFG::ByteCodeParser::setLocal):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGCommonData.cpp:
(JSC::DFG::CommonData::addCodeOrigin):
(JSC::DFG::CommonData::lastCallSite):
(JSC::DFG::CommonData::shrinkToFit):
* dfg/DFGCommonData.h:
* dfg/DFGGraph.h:
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::linkOSRExits):
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::noticeOSREntry):
(JSC::DFG::JITCompiler::appendExceptionHandlingOSRExit):
(JSC::DFG::JITCompiler::willCatchExceptionInMachineFrame):
(JSC::DFG::JITCompiler::exceptionCheck):
(JSC::DFG::JITCompiler::recordCallSiteAndGenerateExceptionHandlingOSRExitIfNeeded):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::emitStoreCodeOrigin):
(JSC::DFG::JITCompiler::emitStoreCallSiteIndex):
(JSC::DFG::JITCompiler::appendCall):
(JSC::DFG::JITCompiler::exceptionCheckWithCallFrameRollback):
(JSC::DFG::JITCompiler::blockHeads):
(JSC::DFG::JITCompiler::exceptionCheck): Deleted.
* dfg/DFGLiveCatchVariablePreservationPhase.cpp: Added.
(JSC::DFG::FlushLiveCatchVariablesInsertionPhase::FlushLiveCatchVariablesInsertionPhase):
(JSC::DFG::FlushLiveCatchVariablesInsertionPhase::run):
(JSC::DFG::FlushLiveCatchVariablesInsertionPhase::willCatchException):
(JSC::DFG::FlushLiveCatchVariablesInsertionPhase::handleBlock):
(JSC::DFG::FlushLiveCatchVariablesInsertionPhase::newVariableAccessData):
(JSC::DFG::performLiveCatchVariablePreservationPhase):
* dfg/DFGLiveCatchVariablePreservationPhase.h: Added.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::OSRExit):
(JSC::DFG::OSRExit::setPatchableCodeOffset):
* dfg/DFGOSRExit.h:
(JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
* dfg/DFGOSRExitCompiler.cpp:
* dfg/DFGOSRExitCompiler32_64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompiler64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::osrWriteBarrier):
(JSC::DFG::adjustAndJumpToTarget):
* dfg/DFGOSRExitCompilerCommon.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGSlowPathGenerator.h:
(JSC::DFG::SlowPathGenerator::SlowPathGenerator):
(JSC::DFG::SlowPathGenerator::~SlowPathGenerator):
(JSC::DFG::SlowPathGenerator::generate):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetById):
(JSC::DFG::SpeculativeJIT::cachedPutById):
(JSC::DFG::SpeculativeJIT::emitCall):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetById):
(JSC::DFG::SpeculativeJIT::cachedPutById):
(JSC::DFG::SpeculativeJIT::emitCall):
* dfg/DFGTierUpCheckInjectionPhase.cpp:
(JSC::DFG::TierUpCheckInjectionPhase::run):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* interpreter/Interpreter.cpp:
(JSC::GetCatchHandlerFunctor::operator()):
(JSC::UnwindFunctor::operator()):
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::gotoNextFrame):
(JSC::StackVisitor::unwindToMachineCodeBlockFrame):
(JSC::StackVisitor::readFrame):
* interpreter/StackVisitor.h:
(JSC::StackVisitor::operator*):
(JSC::StackVisitor::operator->):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitExceptionCheck):
(JSC::AssemblyHelpers::emitNonPatchableExceptionCheck):
(JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitCount):
* jit/JITExceptions.cpp:
(JSC::genericUnwind):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_catch):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_catch):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/VM.h:
(JSC::VM::clearException):
(JSC::VM::clearLastException):
(JSC::VM::addressOfCallFrameForCatch):
(JSC::VM::exception):
(JSC::VM::addressOfException):
* tests/stress/dfg-exception-try-catch-in-constructor-with-inlined-throw.js: Added.
(f):
(bar):
(Foo):
* tests/stress/es6-for-of-loop-exception.js: Added.
(assert):
(shouldThrowInvalidConstAssignment):
(baz):
(foo):
* tests/stress/exception-dfg-inlined-frame-not-strict-equal.js: Added.
(assert):
(o.valueOf):
(o.toString):
(read):
(bar):
(foo):
* tests/stress/exception-dfg-not-strict-equal.js: Added.
(foo):
(o.valueOf):
(o.toString):
(assert):
(shouldDoSomethingInFinally):
(catch):
* tests/stress/exception-dfg-operation-read-value.js: Added.
(assert):
(o.valueOf):
(o.toString):
(read):
(foo):
* tests/stress/exception-dfg-throw-from-catch-block.js: Added.
(assert):
(baz):
(bar):
(foo):
2015-09-17 Filip Pizlo <fpizlo@apple.com>
0.0 should really be 0.0
https://bugs.webkit.org/show_bug.cgi?id=149283
Reviewed by Mark Lam.
A while ago (http://trac.webkit.org/changeset/180813) we introduced the idea that if the
user wrote a number with a decimal point (like "0.0") then we should treat that number as
a double. That's probably a pretty good idea. But, we ended up doing it inconsistently.
The DFG would indeed treat such a number as a double by consulting the
SourceCodeRepresentation, but the other execution engines would still see Int32:0.
This patch makes it consistent.
This is necessary for property type inference to perform well. Otherwise, a store of a
constant would change type from the baseline engine to the DFG, which would then cause
a storm of property type invalidations and recompilations.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::addConstantValue):
2015-09-17 Filip Pizlo <fpizlo@apple.com>
stress/exit-from-getter.js.ftl-eager occasionally traps in debug
https://bugs.webkit.org/show_bug.cgi?id=149096
Reviewed by Geoffrey Garen.
JS calls to getters/setters in get/put inline caches need to reset SP after the call, as our
calling convention requires.
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generate): Fix the bug.
* ftl/FTLLink.cpp:
(JSC::FTL::link): Adds some verbiage about why the FTL stack offset logic is correct.
* tests/stress/getter-arity.js: Added. Other tests would flaky crash before the patch. This test instacrashes before the patch.
2015-09-17 Saam barati <sbarati@apple.com>
Interpreter::unwind() shouldn't be responsible for filtering out uncatchable exceptions
https://bugs.webkit.org/show_bug.cgi?id=149228
Reviewed by Mark Lam.
op_catch is now responsible for filtering exceptions that
aren't catchable. When op_catch encounters an uncatchable
exception, it will call back into genericUnwind and throw
the exception further down the call stack. This is necessary
in a later patch that will implement exception handling
in the DFG, and part of that patch includes exception
handling that doesn't go through genericUnwind. The DFG try/catch
patch will not go through genericUnwind when it knows that
an exception check after a callOperation will be caught inside the
machine frame or any inlined frames. This patch enables that
patch by destroying the notion that all exception handling must
filter through genericUnwind.
This patch maintains compatibility with the debugger and
profiler by ensuring we notify the debugger when an
exception is thrown inside VM::throwException and not
in genericUnwind. It also notifies the profiler that we've
potentially changed call frames inside op_catch.
* debugger/Debugger.cpp:
(JSC::Debugger::pauseIfNeeded):
* interpreter/Interpreter.cpp:
(JSC::unwindCallFrame):
(JSC::getStackFrameCodeType):
(JSC::UnwindFunctor::operator()):
(JSC::Interpreter::unwind):
(JSC::Interpreter::notifyDebuggerOfExceptionToBeThrown):
(JSC::checkedReturn):
* interpreter/Interpreter.h:
(JSC::SuspendExceptionScope::SuspendExceptionScope):
(JSC::SuspendExceptionScope::~SuspendExceptionScope):
(JSC::Interpreter::sampler):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::callOperation):
(JSC::JIT::callOperationNoExceptionCheck):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_catch):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_catch):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::llint_throw_stack_overflow_error):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/ExceptionHelpers.cpp:
(JSC::isTerminatedExecutionException):
* runtime/VM.cpp:
(JSC::VM::throwException):
* runtime/VM.h:
(JSC::VM::targetMachinePCForThrowOffset):
(JSC::VM::restorePreviousException):
(JSC::VM::clearException):
(JSC::VM::clearLastException):
(JSC::VM::exception):
(JSC::VM::addressOfException):
(JSC::VM::setException):
2015-09-17 Sukolsak Sakshuwong <sukolsak@gmail.com>
Calling a float function on x86 in WebAssembly incorrectly returns a double
https://bugs.webkit.org/show_bug.cgi?id=149254
Reviewed by Michael Saboff.
In WebAssembly on x86 (32-bit), when we call a function that returns a
float or a double, we use the FSTP instruction to read the return value
from the FPU register stack. The FSTP instruction converts the value to
single-precision or double-precision floating-point format, depending on
the destination operand. Currently, we always use double as the
destination, which is wrong. This patch uses the correct return type.
This should fix the test errors in tests/stress/wasm-arithmetic-float32.js
* assembler/X86Assembler.h:
(JSC::X86Assembler::fstps):
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::appendCallSetResult):
(JSC::WASMFunctionCompiler::callOperation):
2015-09-17 Sukolsak Sakshuwong <sukolsak@gmail.com>
Save and restore callee save registers in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=149247
Reviewed by Michael Saboff.
Save callee save registers when entering WebAssembly functions
and restore them when returning.
* jit/RegisterSet.cpp:
(JSC::RegisterSet::webAssemblyCalleeSaveRegisters):
* jit/RegisterSet.h:
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::startFunction):
(JSC::WASMFunctionCompiler::endFunction):
(JSC::WASMFunctionCompiler::buildReturn):
(JSC::WASMFunctionCompiler::localAddress):
(JSC::WASMFunctionCompiler::temporaryAddress):
(JSC::WASMFunctionCompiler::boxArgumentsAndAdjustStackPointer):
(JSC::WASMFunctionCompiler::callAndUnboxResult):
2015-09-16 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement indirect calls in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=149100
Reviewed by Geoffrey Garen.
This patch implement indirect calls for WebAssembly files generated by
pack-asmjs <https://github.com/WebAssembly/polyfill-prototype-1>.
pack-asmjs uses the same indirect call model as asm.js. In asm.js, an
indirect call looks like this:
t[i & n](...)
where t is a variable referring to an array of functions with the same
signature, i is an integer expression, n is an integer that is equal to
(t.length - 1), and t.length is a power of two. pack-asmjs does not
use the '&' operator nor n in the WebAssembly output, but the semantics
is still the same as asm.js.
* tests/stress/wasm-calls.js:
* tests/stress/wasm/calls.wasm:
* wasm/WASMFormat.h:
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::buildCallIndirect):
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseExpressionI32):
(JSC::WASMFunctionParser::parseExpressionF32):
(JSC::WASMFunctionParser::parseExpressionF64):
(JSC::WASMFunctionParser::parseCallIndirect):
* wasm/WASMFunctionParser.h:
* wasm/WASMFunctionSyntaxChecker.h:
(JSC::WASMFunctionSyntaxChecker::buildCallIndirect):
* wasm/WASMModuleParser.cpp:
(JSC::WASMModuleParser::parseFunctionPointerTableSection):
(JSC::WASMModuleParser::parseFunctionDefinitionSection):
2015-09-16 Sukolsak Sakshuwong <sukolsak@gmail.com>
Fix 32-bit build issues in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=149240
Reviewed by Geoffrey Garen.
Fix the syntax error and replace the instructions that are not available on
64-bit platforms.
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::startFunction):
(JSC::WASMFunctionCompiler::endFunction):
(JSC::WASMFunctionCompiler::buildReturn):
(JSC::WASMFunctionCompiler::callAndUnboxResult):
(JSC::WASMFunctionCompiler::loadValueAndConvertToDouble):
2015-09-16 Geoffrey Garen <ggaren@apple.com>
JavaScriptCore should discard baseline code after some time
https://bugs.webkit.org/show_bug.cgi?id=149220
Reviewed by Saam Barati.
This is a bit more complicated than discarding optimized code because
the engine previously assumed that we would never discard baseline code.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock): Record creation time (and compute time since
creation) instead of install time because CodeBlocks can be installed
more than once, and we don't want to have to worry about edge cases
created by CodeBlocks seeming to get younger.
(JSC::CodeBlock::visitAggregate): Be explicit about only doing the
weak reference fixpoint for optimized CodeBlocks. We used to avoid the
fixpoint for baseline CodeBlocks implicitly, since they would always
visit themselves strongly right away. But now baseline CodeBlocks might
not visit themselves strongly, since they might choose to jettison due
to old age.
(JSC::CodeBlock::shouldVisitStrongly): Add old age as a reason not to
visit ourselves strongly, so that baseline CodeBlocks can jettison due
to old age.
(JSC::CodeBlock::shouldJettisonDueToWeakReference): Be explicit about
only jettisoning optimized CodeBlocks due to weak references so that we
don't confuse ourselves into thinking that we will jettison a baseline
CodeBlock due to weak references.
(JSC::CodeBlock::shouldJettisonDueToOldAge): Updated to use creation time.
(JSC::CodeBlock::visitOSRExitTargets): Clarify a comment and add an
ASSERT to help record some things I discovered while debugging.
(JSC::CodeBlock::jettison): Allow a baseline CodeBlock to jettison. Don't
assume that we have an alternative or a profiler.
(JSC::CodeBlock::install): Deleted.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::releaseAlternative): Deleted.
(JSC::CodeBlock::setInstallTime): Deleted.
(JSC::CodeBlock::timeSinceInstall): Deleted.
* dfg/DFGOSRExitPreparation.cpp:
(JSC::DFG::prepareCodeOriginForOSRExit): Simplified the computation of
baseline CodeBlock.
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::checkLivenessAndVisitChildren): Be sure to strongly
visit our inline callframes because we assume that an optimized CodeBlock
will keep its OSR exit targets alive, but the CodeBlock object won't be
able to mark them for itself until compilation has completed (since it
won't have a JITCode object yet).
* dfg/DFGToFTLDeferredCompilationCallback.cpp:
(JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidComplete):
Updated for interface change.
* jit/JITCode.h:
(JSC::JITCode::timeToLive): Provide a time to live for interpreter and
baseline code, so they will jettison when old. Use seconds in our
code so that we don't need comments. Make DFG 2X interpreter+baseline,
and FTL 2X DFG+interpreter+baseline, also matching the time we allot
before throwing away all code.
* jit/JITToDFGDeferredCompilationCallback.cpp:
(JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::jitCompileAndSetHeuristics): Updated for interface change.
* runtime/Executable.cpp:
(JSC::ScriptExecutable::installCode): Allow our caller to install nullptr,
since we need to do this when jettisoning a baseline CodeBlock. Require
our caller to specify the details of the installation because we can't
rely on a non-null CodeBlock in order to compute them.
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::ScriptExecutable::prepareForExecutionImpl):
* runtime/Executable.h:
(JSC::ScriptExecutable::recordParse): Updated for interface change.
* runtime/Options.h: Renamed the CodeBlock liveness option since it now
controls baseline and optimized code.
2015-09-16 Geoffrey Garen <ggaren@apple.com>
Remove obsolete code for deleting CodeBlocks
https://bugs.webkit.org/show_bug.cgi?id=149231
Reviewed by Mark Lam.
* heap/Heap.cpp:
(JSC::Heap::deleteAllCodeBlocks): ASSERT that we're called in a valid
state, and do the compiler waiting ourselves instead of having our
caller do it. This is more appropriate to our new limited use.
(JSC::Heap::collectImpl):
(JSC::Heap::deleteOldCode): Deleted. Don't call deleteAllCodeBlocks
periodically because it's not such a good idea to delete everything
at once, and CodeBlocks now have a more precise individual policy for
when to delete. Also, this function used to fail all or nearly all of
the time because its invariants that we were not executing or compiling
could not be met.
* heap/Heap.h:
* jsc.cpp:
(GlobalObject::finishCreation):
(functionDeleteAllCompiledCode): Deleted.
* tests/stress/deleteAllCompiledCode.js: Removed. Removed this testing
code because it did not do what it thought it did. All of this code
was guaranteed to no-op since it would run JavaScript to call a function
that would return early because JavaScript was running.
* runtime/VM.cpp:
(JSC::VM::deleteAllCode): This code is simpler now becaue
heap.deleteAllCodeBlocks does some work for us.
* runtime/VMEntryScope.cpp:
(JSC::VMEntryScope::VMEntryScope): Don't delete code on VM entry. This
policy was old, and it dated back to a time when we
(a) couldn't run in the interpreter if compilation failed;
(b) didn't reduce the rate of compilation in response to executable
memory pressure;
(c) didn't throw away individual CodeBlocks automatically.
2015-09-16 Michael Saboff <msaboff@apple.com>
[ES6] Implement tail calls in the LLInt and Baseline JIT
https://bugs.webkit.org/show_bug.cgi?id=148661
Fix for the breakage of Speedometer/Full.html (https://bugs.webkit.org/show_bug.cgi?id=149162).
Reviewed by Filip Pizlo.
Changed SetupVarargsFrame.cpp::emitSetVarargsFrame to align the callframe size to be a
multiple of stackAlignmentRegisters() in addition to the location of the new frame.
Fixed Reviewed by Filip Pizlo.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/AbortReason.h:
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::Call::Call):
(JSC::AbstractMacroAssembler::repatchNearCall):
(JSC::AbstractMacroAssembler::repatchCompact):
* assembler/CodeLocation.h:
(JSC::CodeLocationNearCall::CodeLocationNearCall):
(JSC::CodeLocationNearCall::callMode):
(JSC::CodeLocationCommon::callAtOffset):
(JSC::CodeLocationCommon::nearCallAtOffset):
(JSC::CodeLocationCommon::dataLabelPtrAtOffset):
* assembler/LinkBuffer.h:
(JSC::LinkBuffer::locationOfNearCall):
(JSC::LinkBuffer::locationOf):
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::nearCall):
(JSC::MacroAssemblerARM::nearTailCall):
(JSC::MacroAssemblerARM::call):
(JSC::MacroAssemblerARM::linkCall):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::nearCall):
(JSC::MacroAssemblerARM64::nearTailCall):
(JSC::MacroAssemblerARM64::ret):
(JSC::MacroAssemblerARM64::linkCall):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::nearCall):
(JSC::MacroAssemblerARMv7::nearTailCall):
(JSC::MacroAssemblerARMv7::call):
(JSC::MacroAssemblerARMv7::linkCall):
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::nearCall):
(JSC::MacroAssemblerMIPS::nearTailCall):
(JSC::MacroAssemblerMIPS::call):
(JSC::MacroAssemblerMIPS::linkCall):
(JSC::MacroAssemblerMIPS::repatchCall):
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::call):
(JSC::MacroAssemblerSH4::nearTailCall):
(JSC::MacroAssemblerSH4::nearCall):
(JSC::MacroAssemblerSH4::linkCall):
(JSC::MacroAssemblerSH4::repatchCall):
* assembler/MacroAssemblerX86.h:
(JSC::MacroAssemblerX86::linkCall):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::breakpoint):
(JSC::MacroAssemblerX86Common::nearTailCall):
(JSC::MacroAssemblerX86Common::nearCall):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::linkCall):
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::callTypeFor):
(JSC::CallLinkInfo::isVarargsCallType):
(JSC::CallLinkInfo::CallLinkInfo):
(JSC::CallLinkInfo::specializationKind):
(JSC::CallLinkInfo::callModeFor):
(JSC::CallLinkInfo::callMode):
(JSC::CallLinkInfo::isTailCall):
(JSC::CallLinkInfo::isVarargs):
(JSC::CallLinkInfo::registerPreservationMode):
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFromLLInt):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::CodeBlock):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitCallInTailPosition):
(JSC::BytecodeGenerator::emitCallEval):
(JSC::BytecodeGenerator::emitCall):
(JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
(JSC::BytecodeGenerator::emitConstructVarargs):
* bytecompiler/NodesCodegen.cpp:
(JSC::CallArguments::CallArguments):
(JSC::LabelNode::emitBytecode):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
* interpreter/Interpreter.h:
(JSC::Interpreter::isCallBytecode):
(JSC::calleeFrameForVarargs):
* jit/CCallHelpers.h:
(JSC::CCallHelpers::jumpToExceptionHandler):
(JSC::CCallHelpers::prepareForTailCallSlow):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JIT.h:
* jit/JITCall.cpp:
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
(JSC::JIT::emit_op_call):
(JSC::JIT::emit_op_tail_call):
(JSC::JIT::emit_op_call_eval):
(JSC::JIT::emit_op_call_varargs):
(JSC::JIT::emit_op_tail_call_varargs):
(JSC::JIT::emit_op_construct_varargs):
(JSC::JIT::emitSlow_op_call):
(JSC::JIT::emitSlow_op_tail_call):
(JSC::JIT::emitSlow_op_call_eval):
(JSC::JIT::emitSlow_op_call_varargs):
(JSC::JIT::emitSlow_op_tail_call_varargs):
(JSC::JIT::emitSlow_op_construct_varargs):
* jit/JITCall32_64.cpp:
(JSC::JIT::emitSlow_op_call):
(JSC::JIT::emitSlow_op_tail_call):
(JSC::JIT::emitSlow_op_call_eval):
(JSC::JIT::emitSlow_op_call_varargs):
(JSC::JIT::emitSlow_op_tail_call_varargs):
(JSC::JIT::emitSlow_op_construct_varargs):
(JSC::JIT::emit_op_call):
(JSC::JIT::emit_op_tail_call):
(JSC::JIT::emit_op_call_eval):
(JSC::JIT::emit_op_call_varargs):
(JSC::JIT::emit_op_tail_call_varargs):
(JSC::JIT::emit_op_construct_varargs):
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
* jit/JITInlines.h:
(JSC::JIT::emitNakedCall):
(JSC::JIT::emitNakedTailCall):
(JSC::JIT::updateTopCallFrame):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/Repatch.cpp:
(JSC::linkVirtualFor):
(JSC::linkPolymorphicCall):
* jit/SetupVarargsFrame.cpp:
(JSC::emitSetVarargsFrame):
* jit/ThunkGenerators.cpp:
(JSC::throwExceptionFromCallSlowPathGenerator):
(JSC::slowPathFor):
(JSC::linkCallThunkGenerator):
(JSC::virtualThunkFor):
(JSC::arityFixupGenerator):
(JSC::unreachableGenerator):
(JSC::baselineGetterReturnThunkGenerator):
* jit/ThunkGenerators.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::arityCheckFor):
(JSC::CommonSlowPaths::opIn):
2015-09-15 Michael Saboff <msaboff@apple.com>
Rollout r189774 and 189818.
Broke Speedometer/Full.html
Not reviewed.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/AbortReason.h:
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::Call::Call):
(JSC::AbstractMacroAssembler::repatchNearCall):
(JSC::AbstractMacroAssembler::repatchCompact):
* assembler/CodeLocation.h:
(JSC::CodeLocationNearCall::CodeLocationNearCall):
(JSC::CodeLocationCommon::callAtOffset):
(JSC::CodeLocationCommon::nearCallAtOffset):
(JSC::CodeLocationCommon::dataLabelPtrAtOffset):
(JSC::CodeLocationNearCall::callMode): Deleted.
* assembler/LinkBuffer.h:
(JSC::LinkBuffer::locationOfNearCall):
(JSC::LinkBuffer::locationOf):
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::nearCall):
(JSC::MacroAssemblerARM::call):
(JSC::MacroAssemblerARM::linkCall):
(JSC::MacroAssemblerARM::nearTailCall): Deleted.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::nearCall):
(JSC::MacroAssemblerARM64::ret):
(JSC::MacroAssemblerARM64::linkCall):
(JSC::MacroAssemblerARM64::nearTailCall): Deleted.
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::nearCall):
(JSC::MacroAssemblerARMv7::call):
(JSC::MacroAssemblerARMv7::linkCall):
(JSC::MacroAssemblerARMv7::nearTailCall): Deleted.
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::nearCall):
(JSC::MacroAssemblerMIPS::call):
(JSC::MacroAssemblerMIPS::linkCall):
(JSC::MacroAssemblerMIPS::repatchCall):
(JSC::MacroAssemblerMIPS::nearTailCall): Deleted.
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::call):
(JSC::MacroAssemblerSH4::nearCall):
(JSC::MacroAssemblerSH4::linkCall):
(JSC::MacroAssemblerSH4::repatchCall):
(JSC::MacroAssemblerSH4::nearTailCall): Deleted.
* assembler/MacroAssemblerX86.h:
(JSC::MacroAssemblerX86::linkCall):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::breakpoint):
(JSC::MacroAssemblerX86Common::nearCall):
(JSC::MacroAssemblerX86Common::nearTailCall): Deleted.
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::linkCall):
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::callTypeFor):
(JSC::CallLinkInfo::CallLinkInfo):
(JSC::CallLinkInfo::specializationKind):
(JSC::CallLinkInfo::registerPreservationMode):
(JSC::CallLinkInfo::isVarargsCallType): Deleted.
(JSC::CallLinkInfo::callModeFor): Deleted.
(JSC::CallLinkInfo::callMode): Deleted.
(JSC::CallLinkInfo::isTailCall): Deleted.
(JSC::CallLinkInfo::isVarargs): Deleted.
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFromLLInt):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::CodeBlock):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitCallInTailPosition):
(JSC::BytecodeGenerator::emitCallEval):
(JSC::BytecodeGenerator::emitCall):
(JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
(JSC::BytecodeGenerator::emitConstructVarargs):
* bytecompiler/NodesCodegen.cpp:
(JSC::CallArguments::CallArguments):
(JSC::LabelNode::emitBytecode):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
* interpreter/Interpreter.h:
(JSC::Interpreter::isCallBytecode):
* jit/CCallHelpers.h:
(JSC::CCallHelpers::jumpToExceptionHandler):
(JSC::CCallHelpers::prepareForTailCallSlow): Deleted.
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JIT.h:
* jit/JITCall.cpp:
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
(JSC::JIT::emit_op_call):
(JSC::JIT::emit_op_call_eval):
(JSC::JIT::emit_op_call_varargs):
(JSC::JIT::emit_op_construct_varargs):
(JSC::JIT::emitSlow_op_call):
(JSC::JIT::emitSlow_op_call_eval):
(JSC::JIT::emitSlow_op_call_varargs):
(JSC::JIT::emitSlow_op_construct_varargs):
(JSC::JIT::emit_op_tail_call): Deleted.
(JSC::JIT::emit_op_tail_call_varargs): Deleted.
(JSC::JIT::emitSlow_op_tail_call): Deleted.
(JSC::JIT::emitSlow_op_tail_call_varargs): Deleted.
* jit/JITCall32_64.cpp:
(JSC::JIT::emitSlow_op_call):
(JSC::JIT::emitSlow_op_call_eval):
(JSC::JIT::emitSlow_op_call_varargs):
(JSC::JIT::emitSlow_op_construct_varargs):
(JSC::JIT::emit_op_call):
(JSC::JIT::emit_op_call_eval):
(JSC::JIT::emit_op_call_varargs):
(JSC::JIT::emit_op_construct_varargs):
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
(JSC::JIT::emitSlow_op_tail_call): Deleted.
(JSC::JIT::emitSlow_op_tail_call_varargs): Deleted.
(JSC::JIT::emit_op_tail_call): Deleted.
(JSC::JIT::emit_op_tail_call_varargs): Deleted.
* jit/JITInlines.h:
(JSC::JIT::emitNakedCall):
(JSC::JIT::updateTopCallFrame):
(JSC::JIT::emitNakedTailCall): Deleted.
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/Repatch.cpp:
(JSC::linkVirtualFor):
(JSC::linkPolymorphicCall):
* jit/ThunkGenerators.cpp:
(JSC::throwExceptionFromCallSlowPathGenerator):
(JSC::slowPathFor):
(JSC::linkCallThunkGenerator):
(JSC::virtualThunkFor):
(JSC::arityFixupGenerator):
(JSC::baselineGetterReturnThunkGenerator):
(JSC::unreachableGenerator): Deleted.
* jit/ThunkGenerators.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::arityCheckFor):
(JSC::CommonSlowPaths::opIn):
* tests/stress/mutual-tail-call-no-stack-overflow.js: Removed.
* tests/stress/tail-call-no-stack-overflow.js: Removed.
* tests/stress/tail-call-recognize.js: Removed.
* tests/stress/tail-call-varargs-no-stack-overflow.js: Removed.
* tests/stress/tail-calls-dont-overwrite-live-stack.js: Removed.
2015-09-15 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement imported global variables in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=149206
Reviewed by Filip Pizlo.
Values can now be imported to a WebAssembly module through properties of
the imports object that is passed to loadWebAssembly(). In order to
avoid any side effect when accessing the imports object, we check that
the properties are data properties. We also check that each value is a
primitive and is not a Symbol. According to the ECMA262 6.0 spec,
calling ToNumber() on a primitive that is not a Symbol should not cause
any side effect.[1]
[1]: http://www.ecma-international.org/ecma-262/6.0/#sec-tonumber
* tests/stress/wasm-globals.js:
* tests/stress/wasm/globals.wasm:
* wasm/WASMModuleParser.cpp:
(JSC::WASMModuleParser::parseModule):
(JSC::WASMModuleParser::parseGlobalSection):
* wasm/WASMModuleParser.h:
2015-09-15 Sukolsak Sakshuwong <sukolsak@gmail.com>
Fix asm.js errors in WebAssembly tests
https://bugs.webkit.org/show_bug.cgi?id=149203
Reviewed by Geoffrey Garen.
Our WebAssembly implementation uses asm.js for testing. Using Firefox to
parse asm.js reveals many errors that are not caught by pack-asmjs. For
example,
- asm.js does not allow the use of the multiplication operator (*) to
multiply two integers, because the result can be so large that some
lower bits of precision are lost. Math.imul is used instead.
- an int variable must be coerced to either signed (via x|0) or unsigned
(via x>>>0) before it's returned.
* tests/stress/wasm-arithmetic-int32.js:
* tests/stress/wasm-calls.js:
* tests/stress/wasm-control-flow.js:
* tests/stress/wasm-globals.js:
* tests/stress/wasm-locals.js:
* tests/stress/wasm-relational.js:
* tests/stress/wasm/control-flow.wasm:
2015-09-15 Ryosuke Niwa <rniwa@webkit.org>
Add ShadowRoot interface and Element.prototype.attachShadow
https://bugs.webkit.org/show_bug.cgi?id=149187
Reviewed by Antti Koivisto.
* Configurations/FeatureDefines.xcconfig:
2015-09-15 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Paused Debugger prevents page reload
https://bugs.webkit.org/show_bug.cgi?id=148174
Reviewed by Brian Burg.
* debugger/Debugger.h:
(JSC::Debugger::suppressAllPauses):
(JSC::Debugger::setSuppressAllPauses):
* debugger/Debugger.cpp:
(JSC::Debugger::Debugger):
(JSC::Debugger::pauseIfNeeded):
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::setSuppressAllPauses):
Provide a way to suppress pauses.
2015-09-15 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement calls to JavaScript functions in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=149093
Reviewed by Filip Pizlo.
This patch implements calls to JavaScript functions in WebAssembly.
WebAssembly functions can only call JavaScript functions that are
imported to their module via an object that is passed into
loadWebAssembly(). References to JavaScript functions are resolved at
the module's load time, just like asm.js.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionLoadWebAssembly):
* tests/stress/wasm-calls.js:
* tests/stress/wasm/calls.wasm:
* wasm/JSWASMModule.cpp:
(JSC::JSWASMModule::visitChildren):
* wasm/JSWASMModule.h:
(JSC::JSWASMModule::importedFunctions):
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::buildCallImport):
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseExpressionI32):
(JSC::WASMFunctionParser::parseExpressionF64):
(JSC::WASMFunctionParser::parseCallImport):
* wasm/WASMFunctionParser.h:
* wasm/WASMFunctionSyntaxChecker.h:
(JSC::WASMFunctionSyntaxChecker::buildCallInternal):
(JSC::WASMFunctionSyntaxChecker::buildCallImport):
(JSC::WASMFunctionSyntaxChecker::updateTempStackHeightForCall):
* wasm/WASMModuleParser.cpp:
(JSC::WASMModuleParser::WASMModuleParser):
(JSC::WASMModuleParser::parse):
(JSC::WASMModuleParser::parseModule):
(JSC::WASMModuleParser::parseFunctionImportSection):
(JSC::WASMModuleParser::getImportedValue):
(JSC::parseWebAssembly):
* wasm/WASMModuleParser.h:
2015-09-15 Csaba Osztrogonác <ossy@webkit.org>
Fix the !ENABLE(DFG_JIT) build after r188696
https://bugs.webkit.org/show_bug.cgi?id=149158
Reviewed by Yusuke Suzuki.
* bytecode/GetByIdStatus.cpp:
* bytecode/GetByIdStatus.h:
2015-09-15 Saam barati <sbarati@apple.com>
functions that use try/catch will allocate a top level JSLexicalEnvironment even when it is not necessary
https://bugs.webkit.org/show_bug.cgi?id=148169
Reviewed by Geoffrey Garen.
We used to do this before we had proper lexical scoping
in the bytecode generator. There is absolutely no reason
why need to allocate a top-level "var" activation when a
function/program uses a "catch" block.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createTryStatement):
(JSC::ASTBuilder::incConstants):
(JSC::ASTBuilder::usesThis):
(JSC::ASTBuilder::usesArguments):
(JSC::ASTBuilder::usesWith):
(JSC::ASTBuilder::usesEval):
(JSC::ASTBuilder::usesCatch): Deleted.
* parser/Nodes.h:
(JSC::ScopeNode::isStrictMode):
(JSC::ScopeNode::setUsesArguments):
(JSC::ScopeNode::usesThis):
(JSC::ScopeNode::needsActivation):
(JSC::ScopeNode::hasCapturedVariables):
(JSC::ScopeNode::captures):
(JSC::ScopeNode::needsActivationForMoreThanVariables): Deleted.
* parser/ParserModes.h:
* runtime/Executable.h:
(JSC::ScriptExecutable::usesEval):
(JSC::ScriptExecutable::usesArguments):
(JSC::ScriptExecutable::needsActivation):
(JSC::ScriptExecutable::isStrictMode):
(JSC::ScriptExecutable::ecmaMode):
2015-09-15 Michael Saboff <msaboff@apple.com>
REGRESSION(r189774): CLoop doesn't build after r189774
https://bugs.webkit.org/show_bug.cgi?id=149171
Unreviewed build fix for the C Loop.
Added needed C Loop label opcodes.
* bytecode/BytecodeList.json:
2015-09-15 Andy VanWagoner <thetalecrafter@gmail.com>
[INTL] Implement supportedLocalesOf on Intl Constructors
https://bugs.webkit.org/show_bug.cgi?id=147599
Reviewed by Benjamin Poulain.
Implements all of the abstract operations used by supportedLocalesOf,
except during canonicalization it does not replace redundant tags,
or subtags with their preferred values.
* icu/unicode/ucal.h: Added.
* icu/unicode/udat.h: Added.
* icu/unicode/umisc.h: Added.
* icu/unicode/unum.h: Added.
* icu/unicode/utypes.h: Clear the U_SHOW_CPLUSPLUS_API flag to prevent C++ headers from being included.
* runtime/CommonIdentifiers.h: Adde localeMatcher.
* runtime/IntlCollatorConstructor.cpp:
(JSC::IntlCollatorConstructorFuncSupportedLocalesOf): Implemented.
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf): Implemented.
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf): Implemented.
* runtime/IntlObject.cpp:
(JSC::canonicalizeLanguageTag):
(JSC::getCanonicalLangTag):
(JSC::getPrivateUseLangTag):
(JSC::getGrandfatheredLangTag):
(JSC::canonicalizeLocaleList):
(JSC::bestAvailableLocale):
(JSC::lookupSupportedLocales):
(JSC::bestFitSupportedLocales):
(JSC::supportedLocales):
(JSC::getIntlStringOption):
(JSC::getIntlBooleanOption):
* runtime/IntlObject.h:
* runtime/JSCJSValue.h: Added toLength.
* runtime/JSCJSValue.cpp: Added toLength.
(JSC::JSValue::toLength): Implement ToLength from ECMA 262 6.0 7.1.15
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::intlCollatorAvailableLocales): Added lazy locale list.
(JSC::JSGlobalObject::intlDateTimeFormatAvailableLocales): Added lazy locale list.
(JSC::JSGlobalObject::intlNumberFormatAvailableLocales): Added lazy locale list.
* runtime/JSGlobalObject.h:
2015-09-14 Saam barati <sbarati@apple.com>
rename callFrameForThrow to callFrameForCatch
https://bugs.webkit.org/show_bug.cgi?id=149136
Reviewed by Michael Saboff.
We use "callFrameForThrow" to mean the call frame in
which we're catching the exception. The field name
should accurately represent its purpose by being
named "callFrameForCatch".
* jit/CCallHelpers.h:
(JSC::CCallHelpers::jumpToExceptionHandler):
* jit/JITExceptions.cpp:
(JSC::genericUnwind):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_catch):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_catch):
* jit/JITOperations.cpp:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/VM.h:
(JSC::VM::exceptionOffset):
(JSC::VM::callFrameForCatchOffset):
(JSC::VM::targetMachinePCForThrowOffset):
(JSC::VM::callFrameForThrowOffset): Deleted.
2015-09-14 Basile Clement <basile_clement@apple.com>
[ES6] Implement tail calls in the LLInt and Baseline JIT
https://bugs.webkit.org/show_bug.cgi?id=148661
Reviewed by Filip Pizlo.
This patch introduces two new opcodes, op_tail_call and
op_tail_call_varargs, to perform tail calls, and implements them in the
LLInt and baseline JIT. Their use prevents DFG and FTL compilation for
now. They are currently implemented by sliding the call frame and
masquerading as our own caller right before performing an actual call.
This required to change the operationLink family of operation to return
a SlowPathReturnType instead of a char* in order to distinguish between
exception cases and actual call cases. We introduce a new FrameAction
enum that indicates whether to reuse (non-exceptional tail call) or
keep the current call frame (non-tail call, and exceptional cases).
This is also a semantics change, since the Function.caller property is
now leaking tail calls. Since tail calls are only used in strict mode,
which poisons this property, the only way of seeing this semantics
change is when a sloppy function calls a strict function that then
tail-calls a sloppy function. Previously, the second sloppy function's
caller would have been the strict function (i.e. raises a TypeError
when the .caller attribute is accessed), while it is now the first
sloppy function. Tests have been updated to reflect that.
This also changes the assumptions we make about call frames. In order
to be relatively efficient, we want to be able to compute the frame
size based only on the argument count, which was not possible
previously. To enable this, we now enforce at the bytecode generator,
DFG and FTL level that any space reserved for a call frame is
stack-aligned, which allows to easily compute its size when performing
a tail call. In all the "special call cases" (calls from native code,
inlined cache calls, etc.), we are starting the frame at the current
stack pointer and thus will always have a stack-aligned frame size.
Finally, this patch adds a couple of tests to check that tail calls run
in constant stack space, as well as tests checking that tail calls are
recognized correctly. Those tests use the handy aforementioned leaking
of tail calls through Function.caller to detect tail calls.
Given that this patch only implements tail calls for the LLInt and
Baseline JIT, tail calls are disabled by default. Until changes are
landed for all tiers, tail call testing and use requires the
--enableTailCalls=true or equivalent.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/AbortReason.h:
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::Call::Call):
(JSC::AbstractMacroAssembler::repatchNearCall):
(JSC::AbstractMacroAssembler::repatchCompact):
* assembler/CodeLocation.h:
(JSC::CodeLocationNearCall::CodeLocationNearCall):
(JSC::CodeLocationNearCall::callMode):
(JSC::CodeLocationCommon::callAtOffset):
(JSC::CodeLocationCommon::nearCallAtOffset):
(JSC::CodeLocationCommon::dataLabelPtrAtOffset):
* assembler/LinkBuffer.h:
(JSC::LinkBuffer::locationOfNearCall):
(JSC::LinkBuffer::locationOf):
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::nearCall):
(JSC::MacroAssemblerARM::nearTailCall):
(JSC::MacroAssemblerARM::call):
(JSC::MacroAssemblerARM::linkCall):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::nearCall):
(JSC::MacroAssemblerARM64::nearTailCall):
(JSC::MacroAssemblerARM64::ret):
(JSC::MacroAssemblerARM64::linkCall):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::nearCall):
(JSC::MacroAssemblerARMv7::nearTailCall):
(JSC::MacroAssemblerARMv7::call):
(JSC::MacroAssemblerARMv7::linkCall):
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::nearCall):
(JSC::MacroAssemblerMIPS::nearTailCall):
(JSC::MacroAssemblerMIPS::call):
(JSC::MacroAssemblerMIPS::linkCall):
(JSC::MacroAssemblerMIPS::repatchCall):
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::call):
(JSC::MacroAssemblerSH4::nearTailCall):
(JSC::MacroAssemblerSH4::nearCall):
(JSC::MacroAssemblerSH4::linkCall):
(JSC::MacroAssemblerSH4::repatchCall):
* assembler/MacroAssemblerX86.h:
(JSC::MacroAssemblerX86::linkCall):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::breakpoint):
(JSC::MacroAssemblerX86Common::nearTailCall):
(JSC::MacroAssemblerX86Common::nearCall):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::linkCall):
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::callTypeFor):
(JSC::CallLinkInfo::isVarargsCallType):
(JSC::CallLinkInfo::CallLinkInfo):
(JSC::CallLinkInfo::specializationKind):
(JSC::CallLinkInfo::callModeFor):
(JSC::CallLinkInfo::callMode):
(JSC::CallLinkInfo::isTailCall):
(JSC::CallLinkInfo::isVarargs):
(JSC::CallLinkInfo::registerPreservationMode):
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFromLLInt):
* bytecode/CallMode.cpp: Added.
(WTF::printInternal):
* bytecode/CallMode.h: Added.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::CodeBlock):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitCallInTailPosition):
(JSC::BytecodeGenerator::emitCallEval):
(JSC::BytecodeGenerator::emitCall):
(JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
(JSC::BytecodeGenerator::emitConstructVarargs):
* bytecompiler/NodesCodegen.cpp:
(JSC::CallArguments::CallArguments):
(JSC::LabelNode::emitBytecode):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
* interpreter/Interpreter.h:
(JSC::Interpreter::isCallBytecode):
* jit/CCallHelpers.h:
(JSC::CCallHelpers::jumpToExceptionHandler):
(JSC::CCallHelpers::prepareForTailCallSlow):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JIT.h:
* jit/JITCall.cpp:
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
(JSC::JIT::emit_op_call):
(JSC::JIT::emit_op_tail_call):
(JSC::JIT::emit_op_call_eval):
(JSC::JIT::emit_op_call_varargs):
(JSC::JIT::emit_op_tail_call_varargs):
(JSC::JIT::emit_op_construct_varargs):
(JSC::JIT::emitSlow_op_call):
(JSC::JIT::emitSlow_op_tail_call):
(JSC::JIT::emitSlow_op_call_eval):
(JSC::JIT::emitSlow_op_call_varargs):
(JSC::JIT::emitSlow_op_tail_call_varargs):
(JSC::JIT::emitSlow_op_construct_varargs):
* jit/JITCall32_64.cpp:
(JSC::JIT::emitSlow_op_call):
(JSC::JIT::emitSlow_op_tail_call):
(JSC::JIT::emitSlow_op_call_eval):
(JSC::JIT::emitSlow_op_call_varargs):
(JSC::JIT::emitSlow_op_tail_call_varargs):
(JSC::JIT::emitSlow_op_construct_varargs):
(JSC::JIT::emit_op_call):
(JSC::JIT::emit_op_tail_call):
(JSC::JIT::emit_op_call_eval):
(JSC::JIT::emit_op_call_varargs):
(JSC::JIT::emit_op_tail_call_varargs):
(JSC::JIT::emit_op_construct_varargs):
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
* jit/JITInlines.h:
(JSC::JIT::emitNakedCall):
(JSC::JIT::emitNakedTailCall):
(JSC::JIT::updateTopCallFrame):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/Repatch.cpp:
(JSC::linkVirtualFor):
(JSC::linkPolymorphicCall):
* jit/ThunkGenerators.cpp:
(JSC::throwExceptionFromCallSlowPathGenerator):
(JSC::slowPathFor):
(JSC::linkCallThunkGenerator):
(JSC::virtualThunkFor):
(JSC::arityFixupGenerator):
(JSC::unreachableGenerator):
(JSC::baselineGetterReturnThunkGenerator):
* jit/ThunkGenerators.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::arityCheckFor):
(JSC::CommonSlowPaths::opIn):
* runtime/Options.h:
* tests/stress/mutual-tail-call-no-stack-overflow.js: Added.
(shouldThrow):
(sloppyCountdown.even):
(sloppyCountdown.odd):
(strictCountdown.even):
(strictCountdown.odd):
(strictCountdown):
(odd):
(even):
* tests/stress/tail-call-no-stack-overflow.js: Added.
(shouldThrow):
(strictLoop):
(strictLoopArityFixup1):
(strictLoopArityFixup2):
* tests/stress/tail-call-recognize.js: Added.
(callerMustBeRun):
(callerMustBeStrict):
(runTests):
* tests/stress/tail-call-varargs-no-stack-overflow.js: Added.
(shouldThrow):
(strictLoop):
* tests/stress/tail-calls-dont-overwrite-live-stack.js: Added.
(tail):
(obj.method):
(obj.get fromNative):
(getThis):
2015-09-14 Filip Pizlo <fpizlo@apple.com>
LLInt get/put inline caches shouldn't use tons of opcodes
https://bugs.webkit.org/show_bug.cgi?id=149106
Reviewed by Geoffrey Garen.
Our LLInt get/put inline caches currently use separate opcodes to reduce branching. For
example, instead of having get_by_id branch on the kind of offset (inline or
out-of-line), we have two get_by_id instructions: get_by_id and get_by_id_out_of_line.
But the problem with this approach is that it doesn't scale. In the property type
inference work (https://bugs.webkit.org/show_bug.cgi?id=148610), we need each kind of put
inline cache to support 11 different kinds of type checks. It seemed ridiculous to add 60
new put_by_id opcodes (there are currently 6 variants of put_by_id, so after adding type
checks, we'd have 6 * 11 = 66 variants of put_by_id).
So, this patch completely changes the strategy to mostly using branching inside the
opcode implementation. It's unlikely to have a performance effect. For example, the long
road to generational GC caused a seemingly prohibitive regression in LLInt inline caches,
and yet nobody noticed. The regression was because the inline cache was in terms of the
structure, not the structure ID, so the code was doing a structure ID table lookup. If we
didn't notice that, then we probably won't notice a couple new branches. (Also, this
patch fixes that regression - the code no longer does such lookups except in the one
unavoidable case in put_by_id transition chain checking.)
This patch also turns the isDirect operand of put_by_id into a flags field. I will use
this flags field to encode the desired type check in bug 148610.
This patch has no effect on performance according to run-jsc-benchmarks.
Relanding this patch with LLInt fixes for non-x86. Previous attempts to fix non-x86 LLInt
build also caused every 64-bit test to crash on every platform. So the patch got rolled
out. This fixes the non-x86 LLInt build while also ensuring that 64-bit platforms don't
crash.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::printGetByIdOp):
(JSC::CodeBlock::printGetByIdCacheStatus):
(JSC::CodeBlock::printPutByIdCacheStatus):
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::finalizeLLIntInlineCaches):
* bytecode/CodeBlock.h:
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFromLLInt):
* bytecode/Instruction.h:
(JSC::Instruction::Instruction):
* bytecode/PutByIdFlags.cpp: Added.
(WTF::printInternal):
* bytecode/PutByIdFlags.h: Added.
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedInstruction::UnlinkedInstruction):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitPutById):
(JSC::BytecodeGenerator::emitDirectPutById):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_put_by_id):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_put_by_id):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2015-09-14 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r189751, r189752, and r189754.
https://bugs.webkit.org/show_bug.cgi?id=149143
caused crashes everywhere (Requested by alexchristensen on
#webkit).
Reverted changesets:
"LLInt get/put inline caches shouldn't use tons of opcodes"
https://bugs.webkit.org/show_bug.cgi?id=149106
http://trac.webkit.org/changeset/189751
"Unreviewed, fix non-x86 LLInt build."
http://trac.webkit.org/changeset/189752
"Unreviewed, really fix non-x86 LLInt build without also
breaking everything else."
http://trac.webkit.org/changeset/189754
2015-09-14 Filip Pizlo <fpizlo@apple.com>
Unreviewed, really fix non-x86 LLInt build without also breaking everything else.
* llint/LowLevelInterpreter64.asm:
2015-09-14 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix non-x86 LLInt build.
* llint/LowLevelInterpreter64.asm:
2015-09-13 Filip Pizlo <fpizlo@apple.com>
LLInt get/put inline caches shouldn't use tons of opcodes
https://bugs.webkit.org/show_bug.cgi?id=149106
Reviewed by Geoffrey Garen.
Our LLInt get/put inline caches currently use separate opcodes to reduce branching. For
example, instead of having get_by_id branch on the kind of offset (inline or
out-of-line), we have two get_by_id instructions: get_by_id and get_by_id_out_of_line.
But the problem with this approach is that it doesn't scale. In the property type
inference work (https://bugs.webkit.org/show_bug.cgi?id=148610), we need each kind of put
inline cache to support 11 different kinds of type checks. It seemed ridiculous to add 60
new put_by_id opcodes (there are currently 6 variants of put_by_id, so after adding type
checks, we'd have 6 * 11 = 66 variants of put_by_id).
So, this patch completely changes the strategy to mostly using branching inside the
opcode implementation. It's unlikely to have a performance effect. For example, the long
road to generational GC caused a seemingly prohibitive regression in LLInt inline caches,
and yet nobody noticed. The regression was because the inline cache was in terms of the
structure, not the structure ID, so the code was doing a structure ID table lookup. If we
didn't notice that, then we probably won't notice a couple new branches. (Also, this
patch fixes that regression - the code no longer does such lookups except in the one
unavoidable case in put_by_id transition chain checking.)
This patch also turns the isDirect operand of put_by_id into a flags field. I will use
this flags field to encode the desired type check in bug 148610.
This patch has no effect on performance according to run-jsc-benchmarks.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::printGetByIdOp):
(JSC::CodeBlock::printGetByIdCacheStatus):
(JSC::CodeBlock::printPutByIdCacheStatus):
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::finalizeLLIntInlineCaches):
* bytecode/CodeBlock.h:
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFromLLInt):
* bytecode/Instruction.h:
(JSC::Instruction::Instruction):
* bytecode/PutByIdFlags.cpp: Added.
(WTF::printInternal):
* bytecode/PutByIdFlags.h: Added.
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedInstruction::UnlinkedInstruction):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitPutById):
(JSC::BytecodeGenerator::emitDirectPutById):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_put_by_id):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_put_by_id):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2015-09-14 Alex Christensen <achristensen@webkit.org>
Progress towards CMake on Mac.
https://bugs.webkit.org/show_bug.cgi?id=149123
Reviewed by Chris Dumez.
* CMakeLists.txt:
Make forwarding headers for the replay subdirectory.
* PlatformMac.cmake:
Make forwarding headers for the generated inspector headers.
They should eventually either be packaged correctly with JavaScriptCore headers and included correctly.
2015-09-14 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Cache the resolution result in JSModuleRecord
https://bugs.webkit.org/show_bug.cgi?id=148896
Reviewed by Saam Barati.
The resolveExport operation is frequently called. For example,
1. When instantiating the module environment, we call it for each exported name and imported
name.
2. When linking the imported module environment to the code block, we call it to resolve the
resolution.
3. When looking up the property from the namespace object, we call it to look up the original
module for the imported binding.
4. When creating the namespace object, we need to collect all the exported names from the module
and need to resolve them by calling resolveExport.
However, resolveExport takes some cost. It traces the imported modules and resolves the reference
queried by the original module.
The resolveExport operation is pure function; given a module record and an export name,
it always returns the same result. So we cache resolution results in the module record to avoid
repeated resolveExport calls with the same arguments.
Here, we only cache the correctly resolved references, since,
1. We rarely looked up the non-correctly-resolved ones. In the linking phase, attempting to
resolve non-correctly-resolved ones throws a syntax error. So only namespace object creation
phase does it in a syntax valid script.
2. This strategy limits the size of the cache map. The number of the correctly exported bindings
is defined by the modules' code. So the size does not become infinitely large.
Currently, the all modules cannot be linked twice. For example,
graph 1
-> (A) -> (B)
graph 2
-> (C) -> (A) -> (B)
We cannot test the behavior now because when executing the graph 2, (A) and (B) are already linked,
it raises an error in the current loader spec. But it should be allowed[1] since it will occur when
there is multiple module tag in WebCore.
[1]: https://github.com/whatwg/loader/issues/41
* runtime/JSModuleRecord.cpp:
(JSC::JSModuleRecord::ResolveQuery::Hash::hash):
(JSC::JSModuleRecord::ResolveQuery::Hash::equal):
(JSC::JSModuleRecord::cacheResolution):
(JSC::ResolveQueryHash::hash): Deleted.
(JSC::ResolveQueryHash::equal): Deleted.
(JSC::resolveExportLoop): Deleted.
* runtime/JSModuleRecord.h:
* tests/modules/caching-should-not-make-ambiguous.js: Added.
* tests/modules/caching-should-not-make-ambiguous/A.js: Added.
* tests/modules/caching-should-not-make-ambiguous/B.js: Added.
* tests/modules/caching-should-not-make-ambiguous/C.js: Added.
* tests/modules/caching-should-not-make-ambiguous/D.js: Added.
* tests/modules/caching-should-not-make-ambiguous/main.js: Added.
* tests/modules/different-view.js: Added.
(from.string_appeared_here.shouldThrow):
* tests/modules/different-view/A.js: Added.
* tests/modules/different-view/B.js: Added.
* tests/modules/different-view/C.js: Added.
* tests/modules/different-view/D.js: Added.
* tests/modules/different-view/E.js: Added.
* tests/modules/different-view/main.js: Added.
* tests/modules/fallback-ambiguous.js: Added.
(from.string_appeared_here.shouldThrow):
* tests/modules/fallback-ambiguous/A.js: Added.
* tests/modules/fallback-ambiguous/B.js: Added.
* tests/modules/fallback-ambiguous/C.js: Added.
* tests/modules/fallback-ambiguous/D.js: Added.
* tests/modules/fallback-ambiguous/E.js: Added.
* tests/modules/fallback-ambiguous/main.js: Added.
* tests/modules/self-star-link.js: Added.
* tests/modules/self-star-link/A.js: Added.
* tests/modules/self-star-link/B.js: Added.
* tests/modules/self-star-link/C.js: Added.
* tests/modules/self-star-link/D.js: Added.
* tests/modules/self-star-link/E.js: Added.
* tests/modules/uncacheable-when-see-star.js: Added.
* tests/modules/uncacheable-when-see-star/A-pre.js: Added.
* tests/modules/uncacheable-when-see-star/A.js: Added.
* tests/modules/uncacheable-when-see-star/B.js: Added.
* tests/modules/uncacheable-when-see-star/C.js: Added.
* tests/modules/uncacheable-when-see-star/D.js: Added.
* tests/modules/uncacheable-when-see-star/E-pre.js: Added.
* tests/modules/uncacheable-when-see-star/E.js: Added.
* tests/modules/uncacheable-when-see-star/main1.js: Added.
* tests/modules/uncacheable-when-see-star/main2.js: Added.
2015-09-14 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement the arithmetic instructions for floats in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=149102
Reviewed by Geoffrey Garen.
This patch implements the arithmetic instructions for floats (float32)
in WebAssembly by converting the float operands to doubles, performing
the equivalent double instructions, and converting the result back to
float. The asm.js spec says that "As proved in 'When is double rounding
innocuous?' (Figueroa 1995), both the 32- and 64-bit versions of
standard arithmetic operations produce equivalent results when given
32-bit inputs and coerced to 32-bit outputs."
(http://asmjs.org/spec/latest/#floatish)
This patch also pads WebAssembly call frames by maxFrameExtentForSlowPathCall,
so that there is no need to adjust the stack pointer every time we make
a slow path call.
* tests/stress/wasm-arithmetic-float32.js:
* tests/stress/wasm/arithmetic-float32.wasm:
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::startFunction):
(JSC::WASMFunctionCompiler::buildUnaryF32):
(JSC::WASMFunctionCompiler::buildBinaryF32):
(JSC::WASMFunctionCompiler::callOperation):
(JSC::WASMFunctionCompiler::callAndUnboxResult):
(JSC::WASMFunctionCompiler::endFunction): Deleted.
(JSC::WASMFunctionCompiler::buildBinaryI32): Deleted.
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseExpressionF32):
(JSC::WASMFunctionParser::parseUnaryExpressionF32):
(JSC::WASMFunctionParser::parseBinaryExpressionF32):
* wasm/WASMFunctionParser.h:
* wasm/WASMFunctionSyntaxChecker.h:
(JSC::WASMFunctionSyntaxChecker::buildUnaryF32):
(JSC::WASMFunctionSyntaxChecker::buildBinaryF32):
2015-09-13 Geoffrey Garen <ggaren@apple.com>
Eden GC should not try to jettison old CodeBlocks in the remembered set
https://bugs.webkit.org/show_bug.cgi?id=149108
Reviewed by Saam Barati.
All we know about objects in the remembered set is that they must be
visited. We don't know whether they're referenced or not because we
won't mark the objects that point to them.
Therefore, it's incorrect for a CodeBlock to consider jettisoning
itself when it's marked as a part of the remembered set: Some
old object might have visited the CodeBlock strongly if given the chance.
I believe this doesn't cause any problems currently because we happen
to visit all strong references to all CodeBlocks elligible for jettison
during every GC.
However, this behavior is a logical oddity that tripped me up, and I
believe it will start causing real problems once we start to jettison
baseline CodeBlocks, since we do not visit all strong references to all
baseline CodeBlocks during every GC.
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::clearMarksForEdenCollection):
(JSC::CodeBlockSet::traceMarked): Be sure to visit the remembered set
strongly, in order to prohibit jettisoning.
(JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
* heap/CodeBlockSet.h: Track the remembered set during eden GCs.
2015-09-11 Filip Pizlo <fpizlo@apple.com>
REGRESSION(r189585): run-perf-tests Speedometer fails with a console error
https://bugs.webkit.org/show_bug.cgi?id=149066
Reviewed by Michael Saboff.
The bug here was that the new IC code was calling actionForCell() more than once. That's
illegal, since when actionForCell() returns RetryCacheLater, it means that it changed some
object's Structure. The Repatch code was doing things like "if (actionForCell(blah) ==
AttemptToCache)" in more than one place, so that if the first such expression was false, then
we'd fall through to the next one. It's possible for the first call to return RetryCacheLater,
in which case our view of the world just got clobbered and we need to return, and then the
second call will probably return AttemptToCache because it *thinks* that we had bailed the last
time and we're now in a future IC invocation.
The solution is to cache the actionForCell() result. This is a bit tricky, because we need to
do this after we check if we're in a proxy.
Debugging bugs like these requires adding ad hoc bisection code in various places. We already
had the basic hooks for this. This patch makes those hooks a bit more useful. In the case of
the LLInt->JIT tier-up hooks, it adds a CodeBlock* argument so that we can bisect based on the
CodeBlock. In the case of Repatch, it puts the Options::forceICFailure() check in a helper
function that also takes ExecState*, which allows us to bisect on either CodeBlock or
CodeOrigin.
* jit/Repatch.cpp:
(JSC::actionForCell):
(JSC::forceICFailure):
(JSC::tryCacheGetByID):
(JSC::tryCachePutByID):
(JSC::tryRepatchIn):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::shouldJIT):
(JSC::LLInt::jitCompileAndSetHeuristics):
(JSC::LLInt::entryOSR):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* tests/stress/retry-cache-later.js:
2015-09-11 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement the relational instructions for floats in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=149080
Reviewed by Geoffrey Garen.
This patch implements the relational instructions for floats (float32)
in WebAssembly by converting float operands to doubles and then
comparing them using the existing double comparison instructions in the
macro assembler.
* tests/stress/wasm-relational.js:
* tests/stress/wasm/relational.wasm:
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::buildRelationalF32):
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseExpressionI32):
(JSC::WASMFunctionParser::parseRelationalF32ExpressionI32):
* wasm/WASMFunctionParser.h:
* wasm/WASMFunctionSyntaxChecker.h:
(JSC::WASMFunctionSyntaxChecker::buildRelationalF32):
2015-09-11 Nan Wang <n_wang@apple.com>
AX: ARIA 1.1 @aria-current
https://bugs.webkit.org/show_bug.cgi?id=146012
Reviewed by Chris Fleizach.
Updated inspector to support aria-current.
* inspector/protocol/DOM.json:
2015-09-11 Sukolsak Sakshuwong <sukolsak@gmail.com>
Add initial support for floats in WebAsssembly
https://bugs.webkit.org/show_bug.cgi?id=149062
Reviewed by Geoffrey Garen.
Implement the ConstantPoolIndex, Immediate, GetLocal, and GetGlobal
instructions for floats (float32) in WebAssembly.
* tests/stress/wasm-arithmetic-float32.js: Added.
(shouldBe):
* tests/stress/wasm-globals.js:
* tests/stress/wasm-type-conversion.js:
* tests/stress/wasm/arithmetic-float32.wasm: Added.
* tests/stress/wasm/globals.wasm:
* tests/stress/wasm/type-conversion.wasm:
* wasm/WASMConstants.h:
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::buildSetLocal):
(JSC::WASMFunctionCompiler::buildReturn):
(JSC::WASMFunctionCompiler::buildImmediateF32):
(JSC::WASMFunctionCompiler::buildGetLocal):
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseExpression):
(JSC::WASMFunctionParser::parseExpressionF32):
(JSC::WASMFunctionParser::parseConstantPoolIndexExpressionF32):
(JSC::WASMFunctionParser::parseImmediateExpressionF32):
(JSC::WASMFunctionParser::parseGetLocalExpressionF32):
(JSC::WASMFunctionParser::parseGetGlobalExpressionF32):
* wasm/WASMFunctionParser.h:
* wasm/WASMFunctionSyntaxChecker.h:
(JSC::WASMFunctionSyntaxChecker::buildImmediateF32):
* wasm/WASMReader.cpp:
(JSC::WASMReader::readOpExpressionF32):
* wasm/WASMReader.h:
2015-09-11 Geoffrey Garen <ggaren@apple.com>
Try to fix the CLOOP build.
Unreviewed.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finalizeBaselineJITInlineCaches):
(JSC::CodeBlock::finalizeUnconditionally):
2015-09-11 Csaba Osztrogonác <ossy@webkit.org>
[EFL] Fix WASM build
https://bugs.webkit.org/show_bug.cgi?id=149065
Reviewed by Darin Adler.
* wasm/WASMFunctionParser.cpp:
2015-09-11 Geoffrey Garen <ggaren@apple.com>
JavaScriptCore should discard optimized code after some time
https://bugs.webkit.org/show_bug.cgi?id=149048
Reviewed by Michael Saboff.
This patch adds a new jettison type -- JettisonDueToOldAge -- and starts
using it for DFG and FTL code. Baseline and LLInt code will come in a
follow-up patch.
The primary goal is to save memory. Some popular websites leave about 10MB
of dead code sitting around immediately after they finish loading.
Throwing away code periodically might also save us from profiling
pathologies that lead to performance dead ends.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::visitAggregate): Updated for rename, and removed a
stale comment.
(JSC::CodeBlock::shouldVisitStrongly): Renamed to shouldVisitStrongly
because the practical effect of this function is to trigger a call to
visitStrongly.
(JSC::CodeBlock::isKnownToBeLiveDuringGC): Check the
m_visitStronglyHasBeenCalled flag instead of
shouldImmediatelyAssumeLivenessDuringScan / shouldVisitStrongly because
m_visitStronglyHasBeenCalled can be set by anybody even if the CodeBlock
would not otherwise visit itself strongly.
(JSC::CodeBlock::shouldJettisonDueToWeakReference): New helper function
for readability.
(JSC::CodeBlock::shouldJettisonDueToOldAge): New helper function that
tells if a CodeBlock is old enough for deletion.
(JSC::CodeBlock::determineLiveness): There's no need to check
shouldImmediatelyAssumeLivenessDuringScan here because we will not call
this function if shouldImmediatelyAssumeLivenessDuringScan is true.
Also, it's just not clear -- if someone chooses to call this function --
that it would be safe to ignore them simply because
shouldImmediatelyAssumeLivenessDuringScan was true.
(JSC::CodeBlock::finalizeLLIntInlineCaches): Moved code out into a helper
function to make the main function more readable.
(JSC::CodeBlock::finalizeBaselineJITInlineCaches): Ditto.
(JSC::CodeBlock::finalizeUnconditionally): Added code for jettisoning a
CodeBlock if it is too old. Moved large sections of code into helper
functions to aid readability in this function.
(JSC::CodeBlock::jettison): Account for the fact that we might jettison
a CodeBlock without OSR exit and without requiring a stack shoot-down.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::setInstallTime):
(JSC::CodeBlock::timeSinceInstall): Track CodeBlock age to help us
decide when to delete.
* jit/JITCode.h:
(JSC::JITCode::timeToLive): Static limits on CodeBlock lifetime. I got
these numbers from the place where numbers come from.
* profiler/ProfilerJettisonReason.cpp:
(WTF::printInternal):
* profiler/ProfilerJettisonReason.h: Updated for new jettison type.
* runtime/Executable.cpp:
(JSC::ScriptExecutable::installCode): Record install time so that we
can measure how old a CodeBlock is.
2015-09-11 Andreas Kling <akling@apple.com>
[JSC] Weak should only accept cell pointees.
<https://webkit.org/b/148955>
Reviewed by Geoffrey Garen.
Since WeakImpls only support pointing to JSCell derived objects,
enforce that at compile time by having the API use JSCell* instead of JSValue.
WeakHandleOwner callbacks now get JSCell& and JSCell*& respectively instead
of wrapping the cell pointer in a Handle<Unknown>.
Also added a static_assert so Weak<T> can't be instantiated with a T that's
not convertible to JSCell.
* API/JSAPIWrapperObject.mm:
(JSAPIWrapperObjectHandleOwner::finalize):
(JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots):
(JSC::JSAPIWrapperObject::finishCreation):
* API/JSManagedValue.mm:
(JSManagedValueHandleOwner::isReachableFromOpaqueRoots):
(JSManagedValueHandleOwner::finalize):
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::finalize):
* builtins/BuiltinExecutables.h:
* heap/Heap.cpp:
(JSC::Heap::addFinalizer):
(JSC::Heap::FinalizerOwner::finalize):
* heap/Heap.h:
* heap/WeakBlock.cpp:
(JSC::WeakBlock::visit):
(JSC::WeakBlock::reap):
* heap/WeakHandleOwner.cpp:
(JSC::WeakHandleOwner::isReachableFromOpaqueRoots):
(JSC::WeakHandleOwner::finalize):
* heap/WeakHandleOwner.h:
* heap/WeakImpl.h:
(JSC::WeakImpl::WeakImpl):
(JSC::WeakImpl::state):
(JSC::WeakImpl::cell):
(JSC::WeakImpl::asWeakImpl):
(JSC::WeakImpl::jsValue): Deleted.
* heap/WeakInlines.h:
(JSC::Weak<T>::Weak):
(JSC::>):
(JSC::Weak<T>::operator):
(JSC::Weak<T>::get):
(JSC::Weak<T>::was):
* heap/WeakSet.h:
* heap/WeakSetInlines.h:
(JSC::WeakSet::allocate):
(JSC::WeakBlock::finalize):
* jit/JITThunks.cpp:
(JSC::JITThunks::finalize):
* jit/JITThunks.h:
* jsc.cpp:
(WTF::ElementHandleOwner::isReachableFromOpaqueRoots): Deleted.
* runtime/JSCell.h:
(JSC::jsCast):
* runtime/RegExpCache.cpp:
(JSC::RegExpCache::finalize):
* runtime/RegExpCache.h:
* runtime/Structure.cpp:
(JSC::StructureTransitionTable::singleTransition):
(JSC::StructureTransitionTable::setSingleTransition):
2015-09-10 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement switch statements in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=149051
Reviewed by Geoffrey Garen.
This patch implements switch statements in WebAssembly using the
JSC::BinarySwitch class.
* tests/stress/wasm-control-flow.js:
* tests/stress/wasm/control-flow.wasm:
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::buildSwitch):
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseSwitchStatement):
* wasm/WASMFunctionSyntaxChecker.h:
(JSC::WASMFunctionSyntaxChecker::buildSwitch):
2015-09-10 Filip Pizlo <fpizlo@apple.com>
Structure should be able to tell you if it had ever been a dictionary
https://bugs.webkit.org/show_bug.cgi?id=149047
Reviewed by Mark Lam.
Introduces the hasBeenDictionary flag to Structure, which tells you if this structure or
any of its ancestors is a dictionary. We already implicitly tracked this for DFG
watchpoint optimizations, so this is mainly just decoupling that existing logic from
watchpoints. Having Structure::hasBeenDictionary() enables some of the heuristics in the
property type inference work (https://bugs.webkit.org/show_bug.cgi?id=148610).
* runtime/Structure.cpp:
(JSC::Structure::Structure):
(JSC::Structure::toDictionaryTransition):
(JSC::Structure::dump):
* runtime/Structure.h:
2015-09-10 Yusuke Suzuki <utatane.tea@gmail.com>
Unreviewed, fix Windows file loading in JSC shell after r189583
https://bugs.webkit.org/show_bug.cgi?id=148917
Should load the script files with the binary mode.
Since these loading functions are only used for the simple test scripts,
we just use ftell / fseek now.
* jsc.cpp:
(fillBufferWithContentsOfFile):
2015-09-10 Michael Saboff <msaboff@apple.com>
REGRESSION(r189575): Appears to break ARM64 linux builds
https://bugs.webkit.org/show_bug.cgi?id=149044
Reviewed by Filip Pizlo.
Changed the use of the ARM64 "fp", a register alias, to be "x29", the real register name.
* llint/LowLevelInterpreter.asm:
2015-09-09 Filip Pizlo <fpizlo@apple.com>
There should be one stub hanging off an inline cache that contains code for all of the cases, rather than forming a linked list consisting of one stub per case
https://bugs.webkit.org/show_bug.cgi?id=148717
Reviewed by Michael Saboff.
This is a major rewrite of the JSC get/put/in inline caches (ICs), motivated by the need to add
fancy new kinds of inline caches for property type inference (https://webkit.org/b/148610).
Previously, our inline caches had some problems that made them difficult to work with. It was
impossible to change any code that was previously generated by the IC except by blowing the
whole IC away, the ICs scaled poorly if there were many cases, and there was a lot of duplicate
and ad hoc code.
Impossible to regenerate a previously generated stub: Say that some access (o.f = v) causes our
IC code to emit some stub; let's call it stub1. Then later we find that we need to emit a
different stub, stub2, where we think that stub2 might subsume stub1. We say that stub2
subsumes stub1 if failing to execute stub2 to completion means that we are guaranteed to fail
to execute stub1 to completion. This could happen in trunk if stub2 has the same base structure
as stub1 but different prototype conditions. It could happen with property type inference if
stub2 has a looser type check on v than stub1 did. Currently, if this happened, we would emit
stub2 and have its slow path jump to stub1. Hence, we would still end up executing the checks
of stub1 before falling through to the slow path. This gets bad when there are many stubs.
Stub1 might be in front of a bunch of other stubs, so when we add stub2, we will end up
executing both stub2's and stub1's checks before falling through to the other stubs. It would
be better if we could remove stub1 from the list at this point. But since stub1 could be linked
to from a different stub that we had already generated, we'd have to have a way of patching
stubs or regenerating them from scratch. This is currenty impossible because we just don't keep
around enough meta-data to mess with a stub after it's generated. After this change, we never
link new stubs onto a linked list of pre-existing stubs; instead each IC will have one stub
hanging off of it and we always regenerate that one stub from scratch. That one stub contains
either a BinarySwitch or a branch cascade to select one of the AccessCases. Each AccessCase is
an object that describes everything we need to regenerate it in the future. This means that
when we add a new case to an IC stub, we can figure out which previous cases this one subsumes.
Poor scalability when there are many cases: Previously, the cases of a polymorphic inline cache
formed a linked list of branches. This meant that the complexity of an inline cache grew
linearly with the number of cases. This change turns this into a BinarySwitch in most cases,
leading to logarithmic scaling.
Duplicate code between get, put, and in: The code for op_get_by_id, op_put_by_id, and op_in
inline caches grew independently and ended up having a lot of duplicate code. We had the worst
kinds of duplicate code. In some cases, the code was copy-pasted. In other cases, we wrote code
that felt like it was new despite the fact that it was logically identical to code that was
already written elsewhere. The main sources of duplication were in selecting a scratch
register, checking all of the ObjectPropertyConditions and the base structure, the pro forma
involved in generating a stub, and the data structures needed to describe all of the access
cases. This change deduplicates all of that code. Now, all of those ICs use the same classes:
the PolymorphicAccess and AccessCase. There is code in those classes that handles all of the
common things, and for the most part the only code that actually specializes for the kind of
access is in some switch statement in AccessCase::generate().
Special-casing of array length and string length: Previously, array.length and string.length
were handled in an ad hoc manner in the get_by_id repatching code. The handling was separate
from the polymorphic get_by_id handling, which meant that we could not handle polymorphic
length accesses if one of the length cases was either array or string length. For example, if
you had "o.length" where the length was either array length or a vanilla length property, then
the get_by_id inline cache would either emit a monomorphic stub for array length, or a
monomorphic stub for the vanilla length property, but never a polymorphic stub (or list) that
could do both. This change addresses this problem by folding array length and string length
into the polymorphic get_by_id code.
This was meant to be a perf-neutral change to enable property type inference, but it ended up
being a 1% Octane speed-up, mainly because of a 14% speed-up in raytrace. This isn't too
surprising, since that test does use inline caches a lot and this change makes inline caches
more scalable.
This also fixes and adds a test for a BinarySwitch bug. BinarySwitch had an optimization for
consecutive integer cases. Using it on typed array structures triggers this bug. It's a hard
bug to trigger any other way because our other switch optimizations will usually use a jump
table in case of consecutive integers.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/MacroAssemblerCodeRef.h:
(JSC::MacroAssemblerCodePtr::dumpWithName):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::printGetByIdCacheStatus):
(JSC::CodeBlock::printPutByIdCacheStatus):
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::getByValInfoMap):
(JSC::CodeBlock::addStubInfo):
(JSC::CodeBlock::findStubInfo):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::stubInfoBegin):
(JSC::CodeBlock::stubInfoEnd):
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
* bytecode/PolymorphicAccess.cpp: Copied from Source/JavaScriptCore/bytecode/PolymorphicGetByIdList.cpp.
(JSC::AccessGenerationState::addWatchpoint):
(JSC::AccessGenerationState::restoreScratch):
(JSC::AccessGenerationState::succeed):
(JSC::AccessCase::AccessCase):
(JSC::AccessCase::get):
(JSC::AccessCase::replace):
(JSC::AccessCase::transition):
(JSC::AccessCase::setter):
(JSC::AccessCase::in):
(JSC::AccessCase::getLength):
(JSC::AccessCase::~AccessCase):
(JSC::AccessCase::fromStructureStubInfo):
(JSC::AccessCase::clone):
(JSC::AccessCase::guardedByStructureCheck):
(JSC::AccessCase::alternateBase):
(JSC::AccessCase::canReplace):
(JSC::AccessCase::dump):
(JSC::AccessCase::visitWeak):
(JSC::AccessCase::generateWithGuard):
(JSC::AccessCase::generate):
(JSC::PolymorphicAccess::PolymorphicAccess):
(JSC::PolymorphicAccess::~PolymorphicAccess):
(JSC::PolymorphicAccess::regenerateWithCases):
(JSC::PolymorphicAccess::regenerateWithCase):
(JSC::PolymorphicAccess::visitWeak):
(JSC::PolymorphicAccess::dump):
(JSC::PolymorphicAccess::regenerate):
(WTF::printInternal):
(JSC::GetByIdAccess::GetByIdAccess): Deleted.
(JSC::GetByIdAccess::~GetByIdAccess): Deleted.
(JSC::GetByIdAccess::fromStructureStubInfo): Deleted.
(JSC::GetByIdAccess::visitWeak): Deleted.
(JSC::PolymorphicGetByIdList::PolymorphicGetByIdList): Deleted.
(JSC::PolymorphicGetByIdList::from): Deleted.
(JSC::PolymorphicGetByIdList::~PolymorphicGetByIdList): Deleted.
(JSC::PolymorphicGetByIdList::currentSlowPathTarget): Deleted.
(JSC::PolymorphicGetByIdList::addAccess): Deleted.
(JSC::PolymorphicGetByIdList::isFull): Deleted.
(JSC::PolymorphicGetByIdList::isAlmostFull): Deleted.
(JSC::PolymorphicGetByIdList::didSelfPatching): Deleted.
(JSC::PolymorphicGetByIdList::visitWeak): Deleted.
* bytecode/PolymorphicAccess.h: Copied from Source/JavaScriptCore/bytecode/PolymorphicGetByIdList.h.
(JSC::AccessCase::isGet):
(JSC::AccessCase::isPut):
(JSC::AccessCase::isIn):
(JSC::AccessCase::type):
(JSC::AccessCase::offset):
(JSC::AccessCase::viaProxy):
(JSC::AccessCase::structure):
(JSC::AccessCase::newStructure):
(JSC::AccessCase::conditionSet):
(JSC::AccessCase::additionalSet):
(JSC::AccessCase::customSlotBase):
(JSC::AccessCase::doesCalls):
(JSC::AccessCase::callLinkInfo):
(JSC::AccessCase::RareData::RareData):
(JSC::PolymorphicAccess::isEmpty):
(JSC::PolymorphicAccess::size):
(JSC::PolymorphicAccess::at):
(JSC::PolymorphicAccess::operator[]):
(JSC::GetByIdAccess::GetByIdAccess): Deleted.
(JSC::GetByIdAccess::isSet): Deleted.
(JSC::GetByIdAccess::operator!): Deleted.
(JSC::GetByIdAccess::type): Deleted.
(JSC::GetByIdAccess::structure): Deleted.
(JSC::GetByIdAccess::conditionSet): Deleted.
(JSC::GetByIdAccess::stubRoutine): Deleted.
(JSC::GetByIdAccess::doesCalls): Deleted.
(JSC::PolymorphicGetByIdList::isEmpty): Deleted.
(JSC::PolymorphicGetByIdList::size): Deleted.
(JSC::PolymorphicGetByIdList::at): Deleted.
(JSC::PolymorphicGetByIdList::operator[]): Deleted.
* bytecode/PolymorphicAccessStructureList.h: Removed.
* bytecode/PolymorphicGetByIdList.cpp: Removed.
* bytecode/PolymorphicGetByIdList.h: Removed.
* bytecode/PolymorphicPutByIdList.cpp: Removed.
* bytecode/PolymorphicPutByIdList.h: Removed.
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeForStubInfo):
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::deref):
(JSC::StructureStubInfo::addAccessCase):
(JSC::StructureStubInfo::reset):
(JSC::StructureStubInfo::visitWeakReferences):
* bytecode/StructureStubInfo.h:
(JSC::StructureStubInfo::StructureStubInfo):
(JSC::StructureStubInfo::initGetByIdSelf):
(JSC::StructureStubInfo::initPutByIdReplace):
(JSC::StructureStubInfo::initStub):
(JSC::StructureStubInfo::setSeen):
(JSC::getStructureStubInfoCodeOrigin):
(JSC::isGetByIdAccess): Deleted.
(JSC::isPutByIdAccess): Deleted.
(JSC::isInAccess): Deleted.
(JSC::StructureStubInfo::initGetByIdList): Deleted.
(JSC::StructureStubInfo::initPutByIdTransition): Deleted.
(JSC::StructureStubInfo::initPutByIdList): Deleted.
(JSC::StructureStubInfo::initInList): Deleted.
(JSC::StructureStubInfo::addWatchpoint): Deleted.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileIn):
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* jit/AccessorCallJITStubRoutine.cpp: Removed.
* jit/AccessorCallJITStubRoutine.h: Removed.
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::branchIfEmpty):
(JSC::AssemblyHelpers::branchStructure):
(JSC::AssemblyHelpers::boxBooleanPayload):
(JSC::AssemblyHelpers::boxBoolean):
(JSC::AssemblyHelpers::boxInt32):
* jit/BinarySwitch.cpp:
(JSC::BinarySwitch::BinarySwitch):
(JSC::BinarySwitch::build):
(JSC::BinarySwitch::Case::dump):
(JSC::BinarySwitch::BranchCode::dump):
* jit/BinarySwitch.h:
(JSC::BinarySwitch::Case::operator<):
(JSC::BinarySwitch::BranchCode::BranchCode):
* jit/JIT.h:
* jit/JITInlineCacheGenerator.cpp:
(JSC::garbageStubInfo):
(JSC::JITInlineCacheGenerator::JITInlineCacheGenerator):
(JSC::JITByIdGenerator::JITByIdGenerator):
(JSC::JITGetByIdGenerator::JITGetByIdGenerator):
(JSC::JITPutByIdGenerator::JITPutByIdGenerator):
* jit/JITInlineCacheGenerator.h:
(JSC::JITInlineCacheGenerator::JITInlineCacheGenerator):
(JSC::JITInlineCacheGenerator::stubInfo):
(JSC::JITByIdGenerator::JITByIdGenerator):
(JSC::JITByIdGenerator::reportSlowPathCall):
* jit/JITOperations.cpp:
* jit/Repatch.cpp:
(JSC::repatchCall):
(JSC::repatchByIdSelfAccess):
(JSC::resetGetByIDCheckAndLoad):
(JSC::resetPutByIDCheckAndLoad):
(JSC::replaceWithJump):
(JSC::tryCacheGetByID):
(JSC::repatchGetByID):
(JSC::appropriateGenericPutByIdFunction):
(JSC::appropriateOptimizingPutByIdFunction):
(JSC::tryCachePutByID):
(JSC::repatchPutByID):
(JSC::tryRepatchIn):
(JSC::repatchIn):
(JSC::resetGetByID):
(JSC::resetPutByID):
(JSC::checkObjectPropertyCondition): Deleted.
(JSC::checkObjectPropertyConditions): Deleted.
(JSC::emitRestoreScratch): Deleted.
(JSC::linkRestoreScratch): Deleted.
(JSC::toString): Deleted.
(JSC::kindFor): Deleted.
(JSC::customFor): Deleted.
(JSC::generateByIdStub): Deleted.
(JSC::patchJumpToGetByIdStub): Deleted.
(JSC::tryBuildGetByIDList): Deleted.
(JSC::buildGetByIDList): Deleted.
(JSC::appropriateListBuildingPutByIdFunction): Deleted.
(JSC::emitPutReplaceStub): Deleted.
(JSC::emitPutTransitionStub): Deleted.
(JSC::tryBuildPutByIdList): Deleted.
(JSC::buildPutByIdList): Deleted.
* jit/ScratchRegisterAllocator.cpp:
(JSC::ScratchRegisterAllocator::lock):
(JSC::ScratchRegisterAllocator::allocateScratch):
* jit/ScratchRegisterAllocator.h:
(JSC::ScratchRegisterAllocator::ScratchRegisterAllocator):
* jsc.cpp:
(GlobalObject::finishCreation):
(functionQuit):
(functionAbort):
(functionFalse1):
(functionFalse2):
* runtime/Options.h:
* tests/stress/array-message-passing.js: Added.
(window.addEventListener):
(window.postMessage):
(window._handleEvents):
(testPassed):
(testFailed):
(classCompare):
(bufferCompare):
(viewCompare):
(typedArrayCompare):
(dataViewCompare):
(dataViewCompare2):
(dataViewCompare3):
(createBuffer):
(createTypedArray):
(createTypedArrayOverBuffer):
(new.DataView):
(testList.testList.concat.basicBufferTypes.map):
(doneTest):
2015-09-10 Geoffrey Garen <ggaren@apple.com>
CodeBlock::codeType() doesn't need to compute anything
https://bugs.webkit.org/show_bug.cgi?id=149039
Reviewed by Michael Saboff.
CodeBlock already has an m_codeType data member.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::codeType):
(JSC::CodeBlock::putByIdContext):
2015-09-10 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement global variables in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=149031
Reviewed by Geoffrey Garen.
This patch implements global variables in WebAssembly. There are two
types of global variables in the current format that we use (the format
used by <https://github.com/WebAssembly/polyfill-prototype-1>): internal
global variables and imported global variables. This patch does not yet
import values for imported global variables. It will be done in a
subsequent patch.
* tests/stress/wasm-globals.js: Added.
(shouldBe):
* tests/stress/wasm/globals.wasm: Added.
* wasm/JSWASMModule.h:
(JSC::JSWASMModule::globalVariables):
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::buildSetGlobal):
(JSC::WASMFunctionCompiler::buildGetGlobal):
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseStatement):
(JSC::WASMFunctionParser::parseSetGlobalStatement):
(JSC::WASMFunctionParser::parseExpressionI32):
(JSC::WASMFunctionParser::parseGetGlobalExpressionI32):
(JSC::WASMFunctionParser::parseExpressionF64):
(JSC::WASMFunctionParser::parseGetGlobalExpressionF64):
* wasm/WASMFunctionParser.h:
* wasm/WASMFunctionSyntaxChecker.h:
(JSC::WASMFunctionSyntaxChecker::buildSetGlobal):
(JSC::WASMFunctionSyntaxChecker::buildGetGlobal):
* wasm/WASMModuleParser.cpp:
(JSC::WASMModuleParser::parseGlobalSection):
2015-09-10 Yusuke Suzuki <utatane.tea@gmail.com>
Consider long module path name case in Windows
https://bugs.webkit.org/show_bug.cgi?id=148917
Reviewed by Alex Christensen.
The local file system module loader in the JSC shell manages the module files by the absolute path.
However, in Windows, _MAX_PATH is defined as 260. So if the path like the current working directory or the path to the module is long,
it will be truncated by the API and it fail to open the file.
In JSC tests in Apple Windows buildbot, since the current working directory is long enough, the tests failed.
This patch introduces the following 3 tweaks.
1. When retrieving the current working path, we use GetCurrentDirectoryW instead of _getcwd.
GetCurrentDirectoryW allows the long path while _getcwd automatically truncate the result by the _MAX_PATH.
2. Before opening the module file, we prepend "\\?\" to the path. It converts the local file path to the long UNC path
which allows longer path names.
3. Since Windows ASCII API accepts the characters in the current code page, we use the Unicode APIs like _wfopen instead.
And enable the once disabled module tests in Windows.
Since this functionality is the part of the JSC shell to run the module tests, it is now implemented in jsc.cpp.
* jsc.cpp:
(stringFromUTF):
(jscSource):
(extractDirectoryName):
(currentWorkingDirectory):
(convertShebangToJSComment):
(fillBufferWithContentsOfFile):
(fetchScriptFromLocalFileSystem):
(fetchModuleFromLocalFileSystem):
(GlobalObject::moduleLoaderFetch):
(functionRun):
(functionLoad):
(functionReadFile):
(functionCheckSyntax):
(functionLoadModule):
(runWithScripts):
(runInteractive):
* tests/modules.yaml:
2015-09-10 Sukolsak Sakshuwong <sukolsak@gmail.com>
Convert arguments to WebAssembly functions to the declared types
https://bugs.webkit.org/show_bug.cgi?id=149033
Reviewed by Geoffrey Garen.
This patch checks the types of arguments to WebAssembly functions and
converts them to the declared types. This is necessary because:
- For example, if a function expects an argument of type double and we
pass 1.0 to it, it will get a JSValue of an integer, not a double.
- We should follow asm.js's behavior for now, because we want to be able
to test WebAssembly apps against asm.js apps. asm.js does type
coercion on arguments by using int|0, Math.fround(float), and +double.
* jit/JITOperations.h:
* tests/stress/wasm-type-conversion.js: Added.
(shouldBe):
(two.valueOf):
* tests/stress/wasm/type-conversion.wasm: Added.
* wasm/WASMFunctionCompiler.h:
(JSC::operationConvertJSValueToInt32):
(JSC::operationConvertJSValueToDouble):
(JSC::WASMFunctionCompiler::startFunction):
(JSC::WASMFunctionCompiler::appendCallSetResult):
(JSC::WASMFunctionCompiler::callOperation):
(JSC::WASMFunctionCompiler::loadValueAndConvertToInt32):
(JSC::WASMFunctionCompiler::loadValueAndConvertToDouble):
2015-09-10 Yusuke Suzuki <utatane.tea@gmail.com>
JSInternalPromiseDeferred should inherit JSPromiseDeferred
https://bugs.webkit.org/show_bug.cgi?id=149027
Reviewed by Darin Adler.
JSInternalPromiseDeferred is constructed by using JSPromiseDeferred implementation.
So the class info of JSInternalPromiseDeferred should inherit JSPromiseDeferred.
* runtime/JSInternalPromiseDeferred.cpp:
2015-09-10 Michael Saboff <msaboff@apple.com>
Add support for Callee-Saves registers
https://bugs.webkit.org/show_bug.cgi?id=148666
Reviewed by Filip Pizlo.
We save platform callee save registers right below the call frame header,
in the location(s) starting with VirtualRegister 0. This local space is
allocated in the bytecode compiler. This space is the maximum space
needed for the callee registers that the LLInt and baseline JIT use,
rounded up to a stack aligned number of VirtualRegisters.
The LLInt explicitly saves and restores the registers in the macros
preserveCalleeSavesUsedByLLInt and restoreCalleeSavesUsedByLLInt.
The JITs saves and restores callee saves registers by what registers
are included in m_calleeSaveRegisters in the code block.
Added handling of callee save register restoration to exception handling.
The basic flow is when an exception is thrown or one is recognized to
have been generated in C++ code, we save the current state of all
callee save registers to VM::calleeSaveRegistersBuffer. As we unwind
looking for the corresponding catch, we copy the callee saves from call
frames to the same VM::calleeSaveRegistersBuffer. This is done for all
call frames on the stack up to but not including the call frame that has
the corresponding catch block. When we process the catch, we restore
the callee save registers with the contents of VM::calleeSaveRegistersBuffer.
If there isn't a catch, then handleUncaughtException will restore callee
saves before it returns back to the calling C++.
Eliminated callee saves registers as free registers for various thunk
generators as the callee saves may not have been saved by the function
calling the thunk.
Added code to transition callee saves from one VM's format to the another
as part of OSR entry and OSR exit.
Cleaned up the static RegisterSet's including adding one for LLInt and
baseline JIT callee saves and one to be used to allocate local registers
not including the callee saves or other special registers.
Moved ftl/FTLRegisterAtOffset.{cpp,h} to jit/RegisterAtOffset.{cpp,h}.
Factored out the vector of RegisterAtOffsets in ftl/FTLUnwindInfo.{cpp,h}
into a new class in jit/RegisterAtOffsetList.{cpp,h}.
Eliminted UnwindInfo and changed UnwindInfo::parse() into a standalone
function named parseUnwindInfo. That standalone function now returns
the callee saves RegisterAtOffsetList. This is stored in the CodeBlock
and used instead of UnwindInfo.
Turned off register preservation thunks for outgoing calls from FTL
generated code. THey'll be removed in a subsequent patch.
Changed specialized thinks to save and restore the contents of
tagTypeNumberRegister and tagMaskRegister as they can be called by FTL
compiled functions. We materialize those tag registers for the thunk's
use and then restore the prior contents on function exit.
Also removed the arity check fail return thunk since it is now the
caller's responsibility to restore the stack pointer.
Removed saving of callee save registers and materialization of special
tag registers for 64 bit platforms from vmEntryToJavaScript and
vmEntryToNative.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* ftl/FTLJITCode.h:
* ftl/FTLRegisterAtOffset.cpp: Removed.
* ftl/FTLRegisterAtOffset.h: Removed.
* ftl/FTLUnwindInfo.cpp:
(JSC::FTL::parseUnwindInfo):
(JSC::FTL::UnwindInfo::UnwindInfo): Deleted.
(JSC::FTL::UnwindInfo::~UnwindInfo): Deleted.
(JSC::FTL::UnwindInfo::parse): Deleted.
(JSC::FTL::UnwindInfo::dump): Deleted.
(JSC::FTL::UnwindInfo::find): Deleted.
(JSC::FTL::UnwindInfo::indexOf): Deleted.
* ftl/FTLUnwindInfo.h:
(JSC::RegisterAtOffset::dump):
* jit/RegisterAtOffset.cpp: Added.
* jit/RegisterAtOffset.h: Added.
(JSC::RegisterAtOffset::RegisterAtOffset):
(JSC::RegisterAtOffset::operator!):
(JSC::RegisterAtOffset::reg):
(JSC::RegisterAtOffset::offset):
(JSC::RegisterAtOffset::offsetAsIndex):
(JSC::RegisterAtOffset::operator==):
(JSC::RegisterAtOffset::operator<):
(JSC::RegisterAtOffset::getReg):
* jit/RegisterAtOffsetList.cpp: Added.
(JSC::RegisterAtOffsetList::RegisterAtOffsetList):
(JSC::RegisterAtOffsetList::sort):
(JSC::RegisterAtOffsetList::dump):
(JSC::RegisterAtOffsetList::find):
(JSC::RegisterAtOffsetList::indexOf):
* jit/RegisterAtOffsetList.h: Added.
(JSC::RegisterAtOffsetList::clear):
(JSC::RegisterAtOffsetList::size):
(JSC::RegisterAtOffsetList::at):
(JSC::RegisterAtOffsetList::append):
Move and refactored use of FTLRegisterAtOffset to RegisterAtOffset.
Added RegisterAtOffset and RegisterAtOffsetList to build configurations.
Remove FTLRegisterAtOffset files.
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::setUpCallFromFTL):
Turned off FTL register preservation thunks.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::setCalleeSaveRegisters):
(JSC::roundCalleeSaveSpaceAsVirtualRegisters):
(JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters):
(JSC::CodeBlock::calleeSaveSpaceAsVirtualRegisters):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::numberOfLLIntBaselineCalleeSaveRegisters):
(JSC::CodeBlock::calleeSaveRegisters):
(JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters):
(JSC::CodeBlock::optimizeAfterWarmUp):
(JSC::CodeBlock::numberOfDFGCompiles):
Methods to manage a set of callee save registers. Also to allocate the appropriate
number of VirtualRegisters for callee saves.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::allocateCalleeSaveSpace):
* bytecompiler/BytecodeGenerator.h:
Allocate the appropriate number of VirtualRegisters for callee saves needed by LLInt or baseline JIT.
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compileEntry):
(JSC::DFG::JITCompiler::compileSetupRegistersForEntry):
(JSC::DFG::JITCompiler::compileBody):
(JSC::DFG::JITCompiler::compileExceptionHandlers):
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
* dfg/DFGJITCompiler.h:
* interpreter/Interpreter.cpp:
(JSC::UnwindFunctor::operator()):
(JSC::UnwindFunctor::copyCalleeSavesToVMCalleeSavesBuffer):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::usedRegisters):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStackLayoutPhase.cpp:
(JSC::DFG::StackLayoutPhase::run):
* ftl/FTLCompile.cpp:
(JSC::FTL::fixFunctionBasedOnStackMaps):
(JSC::FTL::compile):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* ftl/FTLThunks.cpp:
(JSC::FTL::osrExitGenerationThunkGenerator):
* jit/ArityCheckFailReturnThunks.cpp: Removed.
* jit/ArityCheckFailReturnThunks.h: Removed.
* jit/JIT.cpp:
(JSC::JIT::emitEnterOptimizationCheck):
(JSC::JIT::privateCompile):
(JSC::JIT::privateCompileExceptionHandlers):
* jit/JITCall32_64.cpp:
(JSC::JIT::emit_op_ret):
* jit/JITExceptions.cpp:
(JSC::genericUnwind):
* jit/JITExceptions.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_end):
(JSC::JIT::emit_op_ret):
(JSC::JIT::emit_op_throw):
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_enter):
(JSC::JIT::emitSlow_op_loop_hint):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_end):
(JSC::JIT::emit_op_throw):
(JSC::JIT::emit_op_catch):
* jit/JITOperations.cpp:
* jit/Repatch.cpp:
(JSC::generateByIdStub):
* jit/ThunkGenerators.cpp:
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
(JSC::throwExceptionFromCallSlowPathGenerator):
(JSC::arityFixupGenerator):
* runtime/CommonSlowPaths.cpp:
(JSC::setupArityCheckData):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::arityCheckFor):
Emit code to save and restore callee save registers and materialize tagTypeNumberRegister
and tagMaskRegister.
Handle callee saves when tiering up.
Copy callee saves register contents to VM::calleeSaveRegistersBuffer at beginning of
exception processing.
Process callee save registers in frames when unwinding from an exception.
Restore callee saves register contents from VM::calleeSaveRegistersBuffer on catch.
Use appropriate register set to make sure we don't allocate a callee save register when
compiling a thunk.
Helper to populate tagTypeNumberRegister and tagMaskRegister with the appropriate
constants.
Removed arity fixup return thunks.
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareOSREntry):
* dfg/DFGOSRExitCompiler32_64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompiler64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
(JSC::DFG::adjustAndJumpToTarget):
Restore callee saves from the DFG and save the appropriate ones for the baseline JIT.
Materialize the tag registers on 64 bit platforms.
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitSaveCalleeSavesFor):
(JSC::AssemblyHelpers::emitRestoreCalleeSavesFor):
(JSC::AssemblyHelpers::emitSaveCalleeSaves):
(JSC::AssemblyHelpers::emitRestoreCalleeSaves):
(JSC::AssemblyHelpers::copyCalleeSavesToVMCalleeSavesBuffer):
(JSC::AssemblyHelpers::restoreCalleeSavesFromVMCalleeSavesBuffer):
(JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToVMCalleeSavesBuffer):
(JSC::AssemblyHelpers::emitMaterializeTagCheckRegisters):
New helpers to save and restore callee saves as well as materialize the tag registers
contents.
* jit/FPRInfo.h:
* jit/GPRInfo.h:
(JSC::GPRInfo::toRegister):
Updated to include FP callee save registers. Added number of callee saves registers and
cleanup register aliases that collide with callee save registers.
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitGetByValWithCachedId):
(JSC::JIT::emitPutByValWithCachedId):
(JSC::JIT::emit_op_get_by_id):
(JSC::JIT::emit_op_put_by_id):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emitGetByValWithCachedId):
(JSC::JIT::emitPutByValWithCachedId):
(JSC::JIT::emit_op_get_by_id):
(JSC::JIT::emit_op_put_by_id):
Uses new stubUnavailableRegisters register set to limit what registers are available for
temporaries.
* jit/RegisterSet.cpp:
(JSC::RegisterSet::stubUnavailableRegisters):
(JSC::RegisterSet::calleeSaveRegisters):
(JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
(JSC::RegisterSet::dfgCalleeSaveRegisters):
(JSC::RegisterSet::ftlCalleeSaveRegisters):
* jit/RegisterSet.h:
New register sets with the callee saves used by various tiers as well as one listing registers
not availble to stub code.
* jit/SpecializedThunkJIT.h:
(JSC::SpecializedThunkJIT::SpecializedThunkJIT):
(JSC::SpecializedThunkJIT::loadDoubleArgument):
(JSC::SpecializedThunkJIT::returnJSValue):
(JSC::SpecializedThunkJIT::returnDouble):
(JSC::SpecializedThunkJIT::returnInt32):
(JSC::SpecializedThunkJIT::returnJSCell):
(JSC::SpecializedThunkJIT::callDoubleToDoublePreservingReturn):
(JSC::SpecializedThunkJIT::emitSaveThenMaterializeTagRegisters):
(JSC::SpecializedThunkJIT::emitRestoreSavedTagRegisters):
(JSC::SpecializedThunkJIT::tagReturnAsInt32):
* jit/ThunkGenerators.cpp:
(JSC::nativeForGenerator):
Changed to save and restore existing tag register contents as the may contain other values.
After saving the existing values, we materialize the tag constants.
* jit/TempRegisterSet.h:
(JSC::TempRegisterSet::getFPRByIndex):
(JSC::TempRegisterSet::getFreeFPR):
(JSC::TempRegisterSet::setByIndex):
* offlineasm/arm64.rb:
* offlineasm/registers.rb:
Added methods for floating point registers to support callee save FP registers.
* jit/JITArithmetic32_64.cpp:
(JSC::JIT::emit_op_mod):
Removed unnecessary #if CPU(X86_64) check to this 32 bit only file.
* offlineasm/x86.rb:
Fixed Windows callee saves naming.
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
(JSC::VM::calleeSaveRegistersBufferOffset):
(JSC::VM::getAllCalleeSaveRegistersMap):
Provide a RegisterSaveMap that has all registers that might be saved. Added a callee save buffer to be
used for OSR exit and for exception processing in a future patch.
2015-09-10 Yusuke Suzuki <utatane.tea@gmail.com>
ModuleProgramExecutable should provide CodeBlock to ScriptExecutable::forEachCodeBlock
https://bugs.webkit.org/show_bug.cgi?id=149028
Reviewed by Michael Saboff.
ModuleProgramExecutable should provide CodeBlock since ModuleProgramExecutable inherits
ScriptExecutable.
* bytecode/CodeBlock.h:
(JSC::ScriptExecutable::forEachCodeBlock):
2015-09-09 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement internal calls in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=148998
Reviewed by Filip Pizlo.
This patch implements internal calls to functions that return a 32-bit
integer in WebAssembly.
* tests/stress/wasm-calls.js: Added.
(shouldBe):
* tests/stress/wasm/calls.wasm: Added.
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::WASMFunctionCompiler):
(JSC::WASMFunctionCompiler::endFunction):
(JSC::WASMFunctionCompiler::buildCallInternal):
(JSC::WASMFunctionCompiler::appendExpressionList):
(JSC::WASMFunctionCompiler::emitNakedCall):
(JSC::WASMFunctionCompiler::boxArgumentsAndAdjustStackPointer):
(JSC::WASMFunctionCompiler::callAndUnboxResult):
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::compile):
(JSC::WASMFunctionParser::parseExpressionI32):
(JSC::WASMFunctionParser::parseCallInternalExpressionI32):
(JSC::WASMFunctionParser::parseCallArguments):
(JSC::WASMFunctionParser::parseCallInternal):
* wasm/WASMFunctionParser.h:
* wasm/WASMFunctionSyntaxChecker.h:
(JSC::WASMFunctionSyntaxChecker::buildCallInternal):
(JSC::WASMFunctionSyntaxChecker::appendExpressionList):
2015-09-09 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r189522.
https://bugs.webkit.org/show_bug.cgi?id=149020
"Caused a ~4% Speedometer regression" (Requested by cdumez on
#webkit).
Reverted changeset:
"Function.prototype.bind: Bound functions must use the
[[Prototype]] of their target function instead of
Function.prototype"
https://bugs.webkit.org/show_bug.cgi?id=145605
http://trac.webkit.org/changeset/189522
2015-09-09 Geoffrey Garen <ggaren@apple.com>
Fix the no-DFG build.
Unreviewed.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::visitOSRExitTargets):
(JSC::CodeBlock::stronglyVisitStrongReferences):
2015-09-09 Geoffrey Garen <ggaren@apple.com>
CodeBlocks should strongly visit their OSR exit targets
https://bugs.webkit.org/show_bug.cgi?id=148988
Reviewed by Saam Barati.
CodeBlocks jump to their OSR exit targets, so we need to keep them alive
explicitly.
This is a step toward throwing away CodeBlocks, which is only safe
if we keep alive logically in-use CodeBlocks.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::visitStrongly): Added a flag to indicate if visit
strongly had been performed yet, since we are likely to revisit
the same CodeBlock many times now.
(JSC::CodeBlock::visitOSRExitTargets):
(JSC::CodeBlock::stronglyVisitStrongReferences): Do the visiting.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::clearMarks):
(JSC::CodeBlockSet::mark): Added a helper function for clearing out
two flags.
2015-09-09 Geoffrey Garen <ggaren@apple.com>
Unreviewed, rolling back in r189516.
https://bugs.webkit.org/show_bug.cgi?id=148989
Restored changeset:
"GC should be able to discover new strong CodeBlock references
during marking"
https://bugs.webkit.org/show_bug.cgi?id=148981
http://trac.webkit.org/changeset/189516
This patch caused infinite recursion on Windows because of a pre-existing
logical error in the non-parallel GC configuration. Even in non-parallel
GC, we must set the mark bit on a CodeBlock to avoid marking it twice
(or, in the case of our crash, infinitely recursively).
2015-09-09 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement the relational instructions for doubles in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=148999
Reviewed by Filip Pizlo.
Implements the relational instructions for doubles (float64) in
WebAssembly. Also pass the values into the test functions as Mark Lam
suggested in https://bugs.webkit.org/show_bug.cgi?id=148882#c3
* tests/stress/wasm-relational.js:
* tests/stress/wasm/relational.wasm:
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::buildRelationalF64):
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseExpressionI32):
(JSC::WASMFunctionParser::parseRelationalF64ExpressionI32):
* wasm/WASMFunctionParser.h:
* wasm/WASMFunctionSyntaxChecker.h:
(JSC::WASMFunctionSyntaxChecker::buildRelationalI32):
(JSC::WASMFunctionSyntaxChecker::buildRelationalF64):
2015-09-09 Saam barati <sbarati@apple.com>
DFG should have a debugging option that runs a phase that flushes all locals
https://bugs.webkit.org/show_bug.cgi?id=148916
Reviewed by Filip Pizlo.
There is now an option to enable the DFG's new MaximalFlushInsertionPhase
phase to run. This phase ensures that we keep all locals and arguments flushed
to the stack at all places in the CFG. This phase is helpful for finding
a class of bugs where enabling this phase to run removes the bug.
This may also be useful in the development of a faster debugger
that doesn't capture all variables.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGMaximalFlushInsertionPhase.cpp: Added.
(JSC::DFG::MaximalFlushInsertionPhase::MaximalFlushInsertionPhase):
(JSC::DFG::MaximalFlushInsertionPhase::run):
(JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
(JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
(JSC::DFG::MaximalFlushInsertionPhase::newVariableAccessData):
(JSC::DFG::performMaximalFlushInsertion):
* dfg/DFGMaximalFlushInsertionPhase.h: Added.
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/Options.h:
2015-09-08 Sukolsak Sakshuwong <sukolsak@gmail.com>
Refactor the test for the arithmetic instructions in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=148983
Reviewed by Mark Lam.
Pass the values into the test functions as Mark Lam suggested in
https://bugs.webkit.org/show_bug.cgi?id=148882#c3
* tests/stress/wasm-arithmetic-int32.js: Added.
(shouldBe):
(shouldThrow):
* tests/stress/wasm-arithmetic.js: Removed.
(shouldBe): Deleted.
(shouldThrow): Deleted.
* tests/stress/wasm/arithmetic-int32.wasm: Added.
* tests/stress/wasm/arithmetic.wasm: Removed.
2015-09-08 Benjamin Poulain <bpoulain@apple.com>
[JSC] reduce the amount of memory access needed for LivenessAnalysisPhase
https://bugs.webkit.org/show_bug.cgi?id=148414
Reviewed by Mark Lam.
LivenessAnalysisPhase still causes a huge number of cache miss.
This patch reduces the amount of accesses needed by the HashTables.
* dfg/DFGBasicBlock.h:
* dfg/DFGLivenessAnalysisPhase.cpp:
(JSC::DFG::LivenessAnalysisPhase::run):
(JSC::DFG::LivenessAnalysisPhase::process):
2015-09-08 Myles C. Maxfield <mmaxfield@apple.com>
Prospective build fix after r189517
Unreviewed.
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::Thread::captureStack):
2015-09-08 Yusuke Suzuki <utatane.tea@gmail.com>
Unify symbolTableGet and Put in JSLexicalEnvironment and JSSymbolTableObject
https://bugs.webkit.org/show_bug.cgi?id=148783
Reviewed by Geoffrey Garen.
Unify the symbolTableGet and symbolTablePut into JSSymbolTableObject's one.
Since symbolTablePutWithAttributes in JSLexicalEnvironment is not used, we drop that function.
* runtime/JSEnvironmentRecord.h:
(JSC::JSEnvironmentRecord::isValidScopeOffset):
(JSC::JSEnvironmentRecord::variableAt):
(JSC::JSEnvironmentRecord::isValid): Deleted.
* runtime/JSGlobalLexicalEnvironment.cpp:
(JSC::JSGlobalLexicalEnvironment::put):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::put):
* runtime/JSLexicalEnvironment.cpp:
(JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames):
(JSC::JSLexicalEnvironment::getOwnPropertySlot):
(JSC::JSLexicalEnvironment::put):
(JSC::JSLexicalEnvironment::symbolTableGet): Deleted.
(JSC::JSLexicalEnvironment::symbolTablePut): Deleted.
(JSC::JSLexicalEnvironment::symbolTablePutWithAttributes): Deleted.
* runtime/JSLexicalEnvironment.h:
* runtime/JSModuleRecord.cpp:
(JSC::JSModuleRecord::instantiateDeclarations):
* runtime/JSSegmentedVariableObject.h:
(JSC::JSSegmentedVariableObject::isValidScopeOffset):
* runtime/JSSymbolTableObject.h:
(JSC::symbolTableGet):
(JSC::symbolTablePut):
(JSC::symbolTablePutTouchWatchpointSet):
(JSC::symbolTablePutInvalidateWatchpointSet):
(JSC::symbolTablePutWithAttributesTouchWatchpointSet):
(JSC::symbolTablePutWithAttributes): Deleted.
2015-09-08 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r189516.
https://bugs.webkit.org/show_bug.cgi?id=148989
broke tests on windows (Requested by alexchristensen on
#webkit).
Reverted changeset:
"GC should be able to discover new strong CodeBlock references
during marking"
https://bugs.webkit.org/show_bug.cgi?id=148981
http://trac.webkit.org/changeset/189516
2015-09-08 Sukolsak Sakshuwong <sukolsak@gmail.com>
Remove unused DFG::dfgConvertJSValueToInt32()
https://bugs.webkit.org/show_bug.cgi?id=148986
Reviewed by Geoffrey Garen.
Remove unused DFG::dfgConvertJSValueToInt32() and also remove
DFG::JITCompiler::callOperation(D_JITOperation_EJ operation, ...) which
was introduced in Bug 69806 for dfgConvertJSValueToNumber() and is no
longer used.
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation): Deleted.
2015-09-08 Matthew Hill <matthew.jh@outlook.com>
Function.prototype.bind: Bound functions must use the [[Prototype]] of their target function instead of Function.prototype
https://bugs.webkit.org/show_bug.cgi?id=145605
Reviewed by Geoffrey Garen.
* runtime/JSBoundFunction.cpp:
(JSC::JSBoundFunction::create):
* tests/es6.yaml:
2015-09-08 Mark Lam <mark.lam@apple.com>
Fixed a bad comment r189517.
Not reviewed.
* heap/MachineStackMarker.cpp:
(JSC::osRedZoneAdjustment):
2015-09-08 Geoffrey Garen <ggaren@apple.com>
InlineCallFrames shouldn't be strongly marked by CodeBlock
https://bugs.webkit.org/show_bug.cgi?id=146613
Reviewed by Saam Barati.
This code was vestigial an unnecessary, so I removed it.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::stronglyVisitStrongReferences):
* bytecode/InlineCallFrame.cpp:
(JSC::InlineCallFrame::calleeConstant):
(JSC::InlineCallFrame::calleeForCallFrame):
(JSC::InlineCallFrame::visitAggregate): Deleted.
* bytecode/InlineCallFrame.h:
(JSC::InlineCallFrame::specializationKind):
* bytecode/InlineCallFrameSet.cpp:
(JSC::InlineCallFrameSet::add):
(JSC::InlineCallFrameSet::visitAggregate): Deleted.
* bytecode/InlineCallFrameSet.h:
(JSC::InlineCallFrameSet::begin):
(JSC::InlineCallFrameSet::end):
2015-09-08 Mark Lam <mark.lam@apple.com>
GC stack scan should include ABI red zone.
https://bugs.webkit.org/show_bug.cgi?id=148976
Reviewed by Geoffrey Garen and Benjamin Poulain.
The x86_64 ABI section 3.2.2[1] and ARM64 ABI[2] both state that there is a
128 byte red zone below the stack pointer (reserved by the OS), and that
"functions may use this area for temporary data that is not needed across
function calls".
Hence, it is possible for a thread to store JSCell pointers in the red zone
area, and the conservative GC thread scanner needs to scan that area as well.
Note: the red zone should not be scanned for the GC thread itself (in
gatherFromCurrentThread()). This because we're guaranteed that there will
be GC frames below the lowest (top of stack) frame that we need to scan.
Hence, we are guaranteed that there are no red zone areas there containing
JSObject pointers of relevance.
No test added for this issue because the issue relies on:
1. the compiler tool chain generating code that stores local variables
containing the sole reference to a JS object (that needs to be kept
alive) in the stack red zone, and
2. GC has to run on another thread while that red zone containing the
JS object reference is in use.
These conditions require a race that cannot be reliably reproduced.
[1]: http://people.freebsd.org/~obrien/amd64-elf-abi.pdf
[2]: https://developer.apple.com/library/ios/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html#//apple_ref/doc/uid/TP40013702-SW7
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::Thread::Thread):
(JSC::MachineThreads::Thread::createForCurrentThread):
(JSC::MachineThreads::Thread::freeRegisters):
(JSC::osRedZoneAdjustment):
(JSC::MachineThreads::Thread::captureStack):
2015-09-08 Geoffrey Garen <ggaren@apple.com>
GC should be able to discover new strong CodeBlock references during marking
https://bugs.webkit.org/show_bug.cgi?id=148981
Reviewed by Mark Lam.
Previously, we required a strong reference to register itself before the
first visit to a CodeBlock. Now, we can discover a strong reference at
any time during the marking phase.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock): Remove the two strong reference state
variables from CodeBlock. Now, a strong reference immediately marks
the CodeBlock and its references at the moment of its discovery, and no
separate state is required.
(JSC::CodeBlock::visitStrongly): New helper function for establishing
a strong reference to a CodeBlock.
(JSC::CodeBlock::visitAggregate): Adopt helper function above.
(JSC::CodeBlock::shouldImmediatelyAssumeLivenessDuringScan): Updated
for state removal.
(JSC::CodeBlock::isKnownToBeLiveDuringGC): Ditto.
(JSC::CodeBlock::stronglyVisitWeakReferences): Be sure to record that
we have proven liveness (by virtue of marking all the references the
proof would check). This is required so that the CodeBlock knows itself
to be live, and it is also an optimization to avoid testing weak references
after we have already visited them.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::clearMarks):
(JSC::CodeBlockSet::mark):
(JSC::CodeBlockSet::clearMarks): Deleted. Updated for state removal.
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::clearCodeBlockMarks):
(JSC::DFG::Plan::checkLivenessAndVisitChildren):
* dfg/DFGPlan.h: No need to use a CodeBlockSet in order to mark anymore.
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::completeAllPlansForVM):
(JSC::DFG::Worklist::clearCodeBlockMarks):
(JSC::DFG::Worklist::resumeAllThreads):
(JSC::DFG::Worklist::visitWeakReferences):
(JSC::DFG::completeAllPlansForVM):
(JSC::DFG::clearCodeBlockMarks):
* dfg/DFGWorklist.h:
(JSC::DFG::worklistForIndexOrNull): No need to use a CodeBlockSet in order
to mark anymore.
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::clearMarksForFullCollection):
(JSC::CodeBlockSet::clearMarksForEdenCollection):
(JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
(JSC::CodeBlockSet::traceMarked):
(JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
(JSC::CodeBlockSet::dump):
* heap/CodeBlockSet.h: Keep the currently executing CodeBlocks in RefPtrs
since we can no longer rely on the m_currentlyExecuting bit to keep them
alive. (A currently executing CodeBlock may not be referenced by its
Executable because it may since have been replaced by another CodeBlock.
This is common in the cases of OSR entry and exit.)
* heap/Heap.cpp:
(JSC::Heap::markRoots):
(JSC::Heap::visitCompilerWorklistWeakReferences):
(JSC::Heap::visitWeakHandles): No need to trace the list of CodeBlocks
on the stack in the weak reference fixpoint because we no longer overload
"on the stack" to include CodeBlocks referenced by the compiler.
2015-09-08 Andreas Kling <akling@apple.com>
[JSC] Remove unused Heap::getConservativeRegisterRoots().
<https://webkit.org/b/148974>
Reviewed by Geoffrey Garen.
Spotted this unused stack root gathering helper in Heap. Let's lose it.
* heap/Heap.cpp:
(JSC::Heap::getConservativeRegisterRoots): Deleted.
* interpreter/JSStack.cpp:
(JSC::JSStack::gatherConservativeRoots): Deleted.
* interpreter/JSStack.h:
(JSC::JSStack::gatherConservativeRoots): Deleted.
2015-09-08 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement control flow statements in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=148934
Reviewed by Geoffrey Garen.
This patch implements if, while, do, label, break, and continue
statements in WebAssembly. Switches will be implemented in a subsequent
patch.
* tests/stress/wasm-control-flow.js: Added.
(shouldBe):
* tests/stress/wasm/control-flow.wasm: Added.
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::linkTarget):
(JSC::WASMFunctionCompiler::jumpToTarget):
(JSC::WASMFunctionCompiler::jumpToTargetIf):
(JSC::WASMFunctionCompiler::startLoop):
(JSC::WASMFunctionCompiler::endLoop):
(JSC::WASMFunctionCompiler::startSwitch):
(JSC::WASMFunctionCompiler::endSwitch):
(JSC::WASMFunctionCompiler::startLabel):
(JSC::WASMFunctionCompiler::endLabel):
(JSC::WASMFunctionCompiler::breakTarget):
(JSC::WASMFunctionCompiler::continueTarget):
(JSC::WASMFunctionCompiler::breakLabelTarget):
(JSC::WASMFunctionCompiler::continueLabelTarget):
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseIfStatement):
(JSC::WASMFunctionParser::parseIfElseStatement):
(JSC::WASMFunctionParser::parseWhileStatement):
(JSC::WASMFunctionParser::parseDoStatement):
(JSC::WASMFunctionParser::parseLabelStatement):
(JSC::WASMFunctionParser::parseBreakStatement):
(JSC::WASMFunctionParser::parseBreakLabelStatement):
(JSC::WASMFunctionParser::parseContinueStatement):
(JSC::WASMFunctionParser::parseContinueLabelStatement):
* wasm/WASMFunctionParser.h:
* wasm/WASMFunctionSyntaxChecker.h:
(JSC::WASMFunctionSyntaxChecker::linkTarget):
(JSC::WASMFunctionSyntaxChecker::jumpToTarget):
(JSC::WASMFunctionSyntaxChecker::jumpToTargetIf):
(JSC::WASMFunctionSyntaxChecker::startLoop):
(JSC::WASMFunctionSyntaxChecker::endLoop):
(JSC::WASMFunctionSyntaxChecker::startSwitch):
(JSC::WASMFunctionSyntaxChecker::endSwitch):
(JSC::WASMFunctionSyntaxChecker::startLabel):
(JSC::WASMFunctionSyntaxChecker::endLabel):
(JSC::WASMFunctionSyntaxChecker::breakTarget):
(JSC::WASMFunctionSyntaxChecker::continueTarget):
(JSC::WASMFunctionSyntaxChecker::breakLabelTarget):
(JSC::WASMFunctionSyntaxChecker::continueLabelTarget):
2015-09-08 Per Arne Vollan <peavo@outlook.com>
[Win] Compile errors in inspector code.
https://bugs.webkit.org/show_bug.cgi?id=148977
Reviewed by Alex Christensen.
Include definition of class FrontendRouter before use.
* inspector/InspectorBackendDispatcher.h:
* inspector/JSGlobalObjectInspectorController.h:
2015-09-08 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement computed accessors
https://bugs.webkit.org/show_bug.cgi?id=147883
Reviewed by Geoffrey Garen.
Patch by Yusuke Suzuki <utatane.tea@gmail.com> and Matthew Mirman <mmirman@apple.com>.
Implement the computed accessors functionality for class syntax and object literal syntax.
Added new opcodes, op_put_getter_by_val and op_put_setter_by_val. LLInt and baseline JIT support them.
As the same to the other accessor opcodes (like op_put_getter_by_id etc.), DFG / FTL does not support
them. This is handled here[1].
[1]: https://bugs.webkit.org/show_bug.cgi?id=148860
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitPutGetterByVal):
(JSC::BytecodeGenerator::emitPutSetterByVal):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::PropertyListNode::emitBytecode):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_put_getter_by_val):
(JSC::JIT::emit_op_put_setter_by_val):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_put_getter_by_val):
(JSC::JIT::emit_op_put_setter_by_val):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createGetterOrSetterProperty):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseGetterSetter):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createGetterOrSetterProperty):
* tests/es6.yaml:
* tests/stress/computed-accessor-parsing.js: Added.
(testShouldNotThrow):
(testShouldThrow):
(Val.prototype.get string_appeared_here):
(Val):
* tests/stress/computed-accessor.js: Added.
(shouldBe):
(.):
* tests/stress/duplicate-computed-accessors.js: Added.
(shouldBe):
2015-09-08 Saam barati <sbarati@apple.com>
baseline JIT should emit better code for UnresolvedProperty in resolve_scope/get_from_scope/put_to_scope
https://bugs.webkit.org/show_bug.cgi?id=148895
Reviewed by Geoffrey Garen.
Previously, if a resolve_scope/get_from_scope/put_to_scope with
UnresolvedProperty made it to the baseline JIT, we would hard compile
a jump to the slow path. This is bad and slow. Because UnresolvedProperty
tries to update itself to something more useful, and succeeds at doing so
with high probability, we should be emitting code that checks to see if the
slow path has performed an update, and if it has, execute more efficient code
and not go to the slow path (unless it needs to for var injection check failure,
or other check failures). This increases the speed of this code greatly because
we may decide to compile a program/function before certain resolve_scope/get_from_scope/put_to_scope
operations ever execute. And now, the baseline JIT code better adapts to such
compilation scenarios.
* bytecode/Watchpoint.h:
(JSC::WatchpointSet::isBeingWatched):
(JSC::WatchpointSet::addressOfState):
(JSC::WatchpointSet::offsetOfState):
(JSC::WatchpointSet::addressOfSetIsNotEmpty):
* jit/JIT.cpp:
(JSC::JIT::emitNotifyWrite):
(JSC::JIT::assertStackPointerOffset):
* jit/JIT.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emitSlow_op_resolve_scope):
(JSC::JIT::emitGetGlobalProperty):
(JSC::JIT::emitGetVarFromPointer):
(JSC::JIT::emitGetVarFromIndirectPointer):
(JSC::JIT::emitGetClosureVar):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emitSlow_op_get_from_scope):
(JSC::JIT::emitPutGlobalProperty):
(JSC::JIT::emitPutGlobalVariable):
(JSC::JIT::emitPutGlobalVariableIndirect):
(JSC::JIT::emitPutClosureVar):
(JSC::JIT::emit_op_put_to_scope):
(JSC::JIT::emitSlow_op_put_to_scope):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emitSlow_op_resolve_scope):
(JSC::JIT::emitGetGlobalProperty):
(JSC::JIT::emitGetVarFromPointer):
(JSC::JIT::emitGetVarFromIndirectPointer):
(JSC::JIT::emitGetClosureVar):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emitSlow_op_get_from_scope):
(JSC::JIT::emitPutGlobalProperty):
(JSC::JIT::emitPutGlobalVariable):
(JSC::JIT::emitPutGlobalVariableIndirect):
(JSC::JIT::emitPutClosureVar):
(JSC::JIT::emit_op_put_to_scope):
(JSC::JIT::emitSlow_op_put_to_scope):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
(JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
* runtime/JSScope.cpp:
(JSC::abstractAccess):
* tests/stress/multiple-files-tests/global-lexical-variable-unresolved-property/first.js:
(foo):
2015-09-08 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement all the arithmetic and logical instructions in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=148882
Reviewed by Mark Lam.
This patch implements all the arithmetic and logical instructions for
32-bit integers in WebAssembly.
* tests/stress/wasm-arithmetic.js:
* tests/stress/wasm/arithmetic.wasm:
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::buildUnaryI32):
(JSC::WASMFunctionCompiler::buildBinaryI32):
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseExpressionI32):
(JSC::WASMFunctionParser::parseUnaryExpressionI32):
* wasm/WASMFunctionParser.h:
* wasm/WASMFunctionSyntaxChecker.h:
(JSC::WASMFunctionSyntaxChecker::buildUnaryI32):
2015-09-08 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix debug by removing an assertion that is not correct anymore.
* jit/Repatch.cpp:
(JSC::linkFor):
2015-09-08 Sukolsak Sakshuwong <sukolsak@gmail.com>
Add initial support for doubles in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=148913
Reviewed by Filip Pizlo.
Implement the ConstantPoolIndex, Immediate, and GetLocal instructions
for doubles (float64) in WebAssembly.
* tests/stress/wasm-arithmetic-float64.js: Added.
(shouldBe):
* tests/stress/wasm/arithmetic-float64.wasm: Added.
* wasm/WASMConstants.h:
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::buildSetLocal):
(JSC::WASMFunctionCompiler::buildReturn):
(JSC::WASMFunctionCompiler::buildImmediateI32):
(JSC::WASMFunctionCompiler::buildImmediateF64):
(JSC::WASMFunctionCompiler::buildGetLocal):
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseExpression):
(JSC::WASMFunctionParser::parseExpressionF64):
(JSC::WASMFunctionParser::parseConstantPoolIndexExpressionF64):
(JSC::WASMFunctionParser::parseImmediateExpressionF64):
(JSC::WASMFunctionParser::parseGetLocalExpressionF64):
* wasm/WASMFunctionParser.h:
* wasm/WASMFunctionSyntaxChecker.h:
(JSC::WASMFunctionSyntaxChecker::buildImmediateF64):
* wasm/WASMReader.cpp:
(JSC::WASMReader::readOpExpressionF64):
* wasm/WASMReader.h:
2015-09-06 Filip Pizlo <fpizlo@apple.com>
CallLinkInfo inside StructureStubInfo should not use polymorphic stubs
https://bugs.webkit.org/show_bug.cgi?id=148915
Reviewed by Mark Lam.
There is a subtle bug where if we reset a get_by_id IC that had a getter stub that in
turn had a polymorphic call stub, then the GC won't know to keep the getter stub alive.
This patch documents the bug in a FIXME and disables polymorphic call optimizations for
getters. It also just so happens that the polymorphic call optimizations usually don't
benefit getters, since it's hard to create polymorphism at the point of call without also
introducing polymorphism in the base object's structure.
The added test doesn't reproduce the problem, because it's hard to get the GC to delete
all of the stubs.
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::CallLinkInfo):
(JSC::CallLinkInfo::setCallLocations):
(JSC::CallLinkInfo::allowStubs):
(JSC::CallLinkInfo::disallowStubs):
(JSC::CallLinkInfo::setUpCallFromFTL):
* jit/Repatch.cpp:
(JSC::generateByIdStub):
(JSC::linkFor):
(JSC::linkPolymorphicCall):
* tests/stress/poly-call-stub-in-getter-stub.js: Added.
(foo):
(makeGetter):
2015-09-07 Filip Pizlo <fpizlo@apple.com>
The put_by_id IC store barrier contract should benefit transition over replace
https://bugs.webkit.org/show_bug.cgi?id=148943
Reviewed by Mark Lam.
Previously, we would only emit a barrier if the value being stored was possibly a cell, so
the transition stub code generator would have to emit a barrier for the store of the
structure, just in case the structure was newer than the base object.
This changes the contract so that the put_by_id callsite would always have a barrier on the
base (except if it proved that the base was brand new). That way, the transition doesn't have
to have a barrier unless it allocates.
This is meant to be a perf-neutral change that I need for the IC refactoring in
https://bugs.webkit.org/show_bug.cgi?id=148717.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGStoreBarrierInsertionPhase.cpp:
* jit/Repatch.cpp:
(JSC::emitPutTransitionStub):
2015-09-07 Alex Christensen <achristensen@webkit.org>
Windows non-cygwin build fix after r189333.
SVN on Windows (non-cygwin) doesn't like having the * character in file names.
I replaced "*" with "star" in some of Geoff's new tests.
* tests/es6.yaml:
Changed all _*_ to _star_
* tests/es6/generators_yield_*_arrays.js: Removed.
* tests/es6/generators_yield_*_astral_plane_strings.js: Removed.
* tests/es6/generators_yield_*_generator_instances.js: Removed.
* tests/es6/generators_yield_*_generic_iterables.js: Removed.
* tests/es6/generators_yield_*_instances_of_iterables.js: Removed.
* tests/es6/generators_yield_*_iterator_closing.js: Removed.
* tests/es6/generators_yield_*_iterator_closing_via_throw.js: Removed.
* tests/es6/generators_yield_*_on_non-iterables_is_a_runtime_error.js: Removed.
* tests/es6/generators_yield_*_sparse_arrays.js: Removed.
* tests/es6/generators_yield_*_strings.js: Removed.
* tests/es6/generators_yield_star_arrays.js: Copied from tests/es6/generators_yield_*_arrays.js.
* tests/es6/generators_yield_star_astral_plane_strings.js: Copied from tests/es6/generators_yield_*_astral_plane_strings.js.
* tests/es6/generators_yield_star_generator_instances.js: Copied from tests/es6/generators_yield_*_generator_instances.js.
* tests/es6/generators_yield_star_generic_iterables.js: Copied from tests/es6/generators_yield_*_generic_iterables.js.
* tests/es6/generators_yield_star_instances_of_iterables.js: Copied from tests/es6/generators_yield_*_instances_of_iterables.js.
* tests/es6/generators_yield_star_iterator_closing.js: Copied from tests/es6/generators_yield_*_iterator_closing.js.
* tests/es6/generators_yield_star_iterator_closing_via_throw.js: Copied from tests/es6/generators_yield_*_iterator_closing_via_throw.js.
* tests/es6/generators_yield_star_on_non-iterables_is_a_runtime_error.js: Copied from tests/es6/generators_yield_*_on_non-iterables_is_a_runtime_error.js.
* tests/es6/generators_yield_star_sparse_arrays.js: Copied from tests/es6/generators_yield_*_sparse_arrays.js.
* tests/es6/generators_yield_star_strings.js: Copied from tests/es6/generators_yield_*_strings.js.
2015-09-06 Mark Lam <mark.lam@apple.com>
Gardening: fix broken Windows build after r189454.
Not reviewed.
* JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
* JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters:
2015-09-06 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement the relational instructions in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=148838
Reviewed by Saam Barati.
This patch implements the relational instructions for 32-bit integers in
WebAssembly.
* tests/stress/wasm-arithmetic.js:
* tests/stress/wasm-locals.js:
* tests/stress/wasm-relational.js: Added.
(shouldBe):
* tests/stress/wasm/arithmetic.wasm: Renamed from Source/JavaScriptCore/tests/stress/wasm-arithmetic.wasm.
* tests/stress/wasm/locals.wasm: Renamed from Source/JavaScriptCore/tests/stress/wasm-locals.wasm.
* tests/stress/wasm/relational.wasm: Added.
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::buildRelationalI32):
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseExpressionI32):
(JSC::WASMFunctionParser::parseRelationalI32ExpressionI32):
* wasm/WASMFunctionParser.h:
* wasm/WASMFunctionSyntaxChecker.h:
(JSC::WASMFunctionSyntaxChecker::buildRelationalI32):
2015-09-06 Mark Lam <mark.lam@apple.com>
StackOverflow stack unwinding should stop at native frames.
https://bugs.webkit.org/show_bug.cgi?id=148749
Reviewed by Michael Saboff.
In the present code, after ping-pong'ing back and forth between native and JS
code a few times, if we have a stack overflow on re-entry into the VM to run
JS code's whose stack frame would overflow the JS stack, the code will end up
unwinding past the native function that is making the call to re-enter the VM.
As a result, any clean up code (e.g. destructors for stack variables) in the
skipped native function frame (and its chain of native function callers) will
not be called.
This patch is based on the Michael Saboff's fix of this issue landed on the
jsc-tailcall branch: http://trac.webkit.org/changeset/188555
We now check for the case where there are no JS frames to unwind since the
last native frame, and treat the exception as an unhandled exception. The
native function is responsible for further propagating the exception if needed.
Other supporting work:
1. Remove vm->vmEntryFrameForThrow. It should always be the same as
vm->topVMEntryFrame.
2. Change operationThrowStackOverflowError() to use the throwStackOverflowError()
helper function instead of rolling its own.
3. Added a test that exercises this edge case. The test should not hang or crash.
* API/tests/PingPongStackOverflowTest.cpp: Added.
(PingPongStackOverflowObject_hasInstance):
(testPingPongStackOverflow):
* API/tests/PingPongStackOverflowTest.h: Added.
* API/tests/testapi.c:
(main):
* JavaScriptCore.xcodeproj/project.pbxproj:
* interpreter/CallFrame.h:
(JSC::ExecState::operator=):
(JSC::ExecState::callerFrame):
(JSC::ExecState::callerFrameOrVMEntryFrame):
(JSC::ExecState::argIndexForRegister):
(JSC::ExecState::callerFrameAndPC):
* interpreter/Interpreter.cpp:
(JSC::UnwindFunctor::UnwindFunctor):
(JSC::UnwindFunctor::operator()):
(JSC::Interpreter::unwind):
* interpreter/Interpreter.h:
(JSC::NativeCallFrameTracer::NativeCallFrameTracer):
(JSC::Interpreter::sampler):
* jit/CCallHelpers.h:
(JSC::CCallHelpers::jumpToExceptionHandler):
* jit/JITExceptions.cpp:
(JSC::genericUnwind):
* jit/JITExceptions.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_catch):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_catch):
* jit/JITOperations.cpp:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/VM.h:
(JSC::VM::exceptionOffset):
(JSC::VM::callFrameForThrowOffset):
(JSC::VM::vmEntryFrameForThrowOffset): Deleted.
(JSC::VM::topVMEntryFrameOffset): Deleted.
2015-09-06 Yusuke Suzuki <utatane.tea@gmail.com>
Unreviewed, disable module tests in Windows until name resolution is fixed
https://bugs.webkit.org/show_bug.cgi?id=148689
Until bug[1] is fixed, we disable the module tests.
Since the local file system name resolution is just implemented in jsc.cpp and
is intended to be used for the module tests, it does not affect JSC framework
and WebKit itself.
[1]: https://bugs.webkit.org/show_bug.cgi?id=148917
* tests/modules.yaml:
2015-09-06 Sukolsak Sakshuwong <sukolsak@gmail.com>
Simplify JIT::emit_op_mod()
https://bugs.webkit.org/show_bug.cgi?id=148908
Reviewed by Michael Saboff.
The IDIV instruction on x86 divides the value in the EDX:EAX registers
by the source operand and stores the quotient in EAX and the remainder
in EDX. Therefore, we store the values that we don't want to be
overwritten by IDIV in registers that are not EAX or EDX. This patch
makes the intention clearer and makes the code easier to read.
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_mod):
2015-09-05 Mark Lam <mark.lam@apple.com>
Fix JSDollarVMPrototype after r189160.
https://bugs.webkit.org/show_bug.cgi?id=148900
Reviewed by Michael Saboff.
JSDollarVMPrototype needs to be updated to match http://trac.webkit.org/changeset/189160 i.e.
remove the use of JSC::Function bit in its property attributes.
* tools/JSDollarVMPrototype.cpp:
(JSC::JSDollarVMPrototype::finishCreation):
2015-09-05 Yusuke Suzuki <utatane.tea@gmail.com>
Unreviewed, fix the module name resolution in Windows
https://bugs.webkit.org/show_bug.cgi?id=148689
Attempt to fix the module name resolution in Windows.
A module name is represented as the UNIX path under the current module tests.
This fix split the module name with '/' instead of pathSeparator().
This is only utilized by the jsc.cpp for the local module tests.
So, WebKit production and JavaScriptCore framework are not affected by this change.
* jsc.cpp:
(ModuleName::startsWithRoot):
(ModuleName::ModuleName):
(resolvePath):
(GlobalObject::moduleLoaderResolve):
2015-09-05 Brian Burg <bburg@apple.com>
Web Inspector: tighten up lifetimes for Agent-owned objects, and initialize agents using contexts
https://bugs.webkit.org/show_bug.cgi?id=148625
Reviewed by Joseph Pecoraro.
All agents own their domain-specific frontend and backend dispatchers. Change so that
they are initialized in constructors rather than when a frontend connects or disconnects.
This may cause additional memory use, but this can be counteracted by lazily creating
some agents that are not required for other agents to function (i.e., runtime and page agents).
To avoid adding frontend/backend dispatcher arguments to every single agent constructor,
change agent construction to take a AgentContext or a subclass of it. This provides agents with
references to objects in the owning InspectorEnvironment subclass that are guaranteed to
outlive all agents. AgentContext and its subclasses follow the existing Agent class hierarchy.
* inspector/InspectorAgentBase.h:
(Inspector::JSAgentContext::JSAgentContext):
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
(Inspector::JSGlobalObjectInspectorController::connectFrontend):
(Inspector::JSGlobalObjectInspectorController::disconnectFrontend):
(Inspector::JSGlobalObjectInspectorController::disconnectAllFrontends):
(Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
* inspector/JSGlobalObjectInspectorController.h:
* inspector/agents/InspectorAgent.cpp:
(Inspector::InspectorAgent::InspectorAgent):
(Inspector::InspectorAgent::didCreateFrontendAndBackend):
(Inspector::InspectorAgent::willDestroyFrontendAndBackend):
* inspector/agents/InspectorAgent.h:
* inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::InspectorConsoleAgent):
(Inspector::InspectorConsoleAgent::didCreateFrontendAndBackend):
(Inspector::InspectorConsoleAgent::willDestroyFrontendAndBackend):
* inspector/agents/InspectorConsoleAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::InspectorDebuggerAgent):
(Inspector::InspectorDebuggerAgent::didCreateFrontendAndBackend):
(Inspector::InspectorDebuggerAgent::willDestroyFrontendAndBackend):
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::InspectorRuntimeAgent):
* inspector/agents/InspectorRuntimeAgent.h:
* inspector/agents/JSGlobalObjectConsoleAgent.cpp:
(Inspector::JSGlobalObjectConsoleAgent::JSGlobalObjectConsoleAgent):
* inspector/agents/JSGlobalObjectConsoleAgent.h:
* inspector/agents/JSGlobalObjectDebuggerAgent.cpp:
(Inspector::JSGlobalObjectDebuggerAgent::JSGlobalObjectDebuggerAgent):
* inspector/agents/JSGlobalObjectDebuggerAgent.h:
* inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
(Inspector::JSGlobalObjectRuntimeAgent::JSGlobalObjectRuntimeAgent):
(Inspector::JSGlobalObjectRuntimeAgent::didCreateFrontendAndBackend):
* inspector/agents/JSGlobalObjectRuntimeAgent.h:
* inspector/augmentable/AlternateDispatchableAgent.h:
* inspector/augmentable/AugmentableInspectorController.h: Alternate agents should
have access to frontend router and backend dispatcher at construction time.
* inspector/scripts/codegen/cpp_generator_templates.py:
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
(CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event):
* inspector/scripts/codegen/objc_generator_templates.py:
2015-09-04 Brian Burg <bburg@apple.com>
Web Inspector: agents should send messages through FrontendRouter instead of FrontendChannel
https://bugs.webkit.org/show_bug.cgi?id=148492
Reviewed by Joseph Pecoraro.
Replace uses of FrontendChannel with FrontendRouter. Minor cleanups along the way.
Make AgentRegistry automatically signal discardAgent() in its destructor, since it always
gets executed in the owning controller's destructor anyway.
* inspector/InspectorAgentBase.h:
* inspector/InspectorAgentRegistry.cpp:
(Inspector::AgentRegistry::~AgentRegistry):
(Inspector::AgentRegistry::didCreateFrontendAndBackend):
(Inspector::AgentRegistry::willDestroyFrontendAndBackend):
(Inspector::AgentRegistry::discardAgents): Deleted.
* inspector/InspectorAgentRegistry.h:
* inspector/InspectorBackendDispatcher.cpp:
* inspector/InspectorFrontendRouter.cpp:
(Inspector::FrontendRouter::leakChannel): Deleted, no longer necessary.
* inspector/InspectorFrontendRouter.h:
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
(Inspector::JSGlobalObjectInspectorController::connectFrontend):
(Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
(Inspector::JSGlobalObjectInspectorController::~JSGlobalObjectInspectorController):
* inspector/JSGlobalObjectInspectorController.h:
* inspector/agents/InspectorAgent.cpp:
(Inspector::InspectorAgent::didCreateFrontendAndBackend):
* inspector/agents/InspectorAgent.h:
* inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::didCreateFrontendAndBackend):
* inspector/agents/InspectorConsoleAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::didCreateFrontendAndBackend):
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
(Inspector::JSGlobalObjectRuntimeAgent::didCreateFrontendAndBackend):
* inspector/agents/JSGlobalObjectRuntimeAgent.h:
* inspector/augmentable/AlternateDispatchableAgent.h:
* inspector/remote/RemoteInspectorDebuggable.cpp:
* inspector/scripts/codegen/cpp_generator_templates.py:
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
(CppBackendDispatcherImplementationGenerator.generate_output):
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
(CppFrontendDispatcherHeaderGenerator.generate_output.FrontendRouter):
(CppFrontendDispatcherHeaderGenerator.generate_output):
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
(CppFrontendDispatcherImplementationGenerator.generate_output):
(CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event):
* inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
(ObjCConfigurationImplementationGenerator.generate_output):
* inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
(ObjCFrontendDispatcherImplementationGenerator.generate_output):
2015-09-05 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Enable ES6 Module in JSC shell by default
https://bugs.webkit.org/show_bug.cgi?id=148689
Reviewed by Geoffrey Garen.
Enable ES6 Modules in JSC shell by default. Compile time flag is left for WebCore.
Since the entry point to evaluate the modules are completely separated from the usual
entry point to evaluate the script, we can safely enable ES6 modules in JSC shell.
And add bunch of tests for ES6 Modules.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionLoadModule):
(runWithScripts):
(printUsageStatement): Deleted.
(CommandLine::parseArguments): Deleted.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner): Deleted.
* tests/modules.yaml: Added.
* tests/modules/aliasing.js: Added.
* tests/modules/aliasing/drink-2.js: Added.
(export.let.Cappuccino.string_appeared_here.export.changeCappuccino):
* tests/modules/aliasing/drink.js: Added.
(export.changeCocoa):
* tests/modules/cyclic-may-produce-tdz.js: Added.
* tests/modules/cyclic-may-produce-tdz/1.js: Added.
* tests/modules/cyclic-may-produce-tdz/2.js: Added.
* tests/modules/default-error/main.js: Added.
* tests/modules/default-value-case-should-be-copied.js: Added.
* tests/modules/default-value-case-should-be-copied/module.js: Added.
(export.changeValue):
* tests/modules/defaults.js: Added.
* tests/modules/defaults/Cappuccino.js: Added.
* tests/modules/defaults/Cocoa.js: Added.
(export.default.Cocoa):
* tests/modules/defaults/Matcha.js: Added.
* tests/modules/destructuring-export.js: Added.
* tests/modules/destructuring-export/array.js: Added.
* tests/modules/destructuring-export/main.js: Added.
* tests/modules/execution-order-cyclic.js: Added.
* tests/modules/execution-order-cyclic/1.js: Added.
* tests/modules/execution-order-cyclic/10.js: Added.
* tests/modules/execution-order-cyclic/11.js: Added.
* tests/modules/execution-order-cyclic/2.js: Added.
* tests/modules/execution-order-cyclic/3.js: Added.
* tests/modules/execution-order-cyclic/4.js: Added.
* tests/modules/execution-order-cyclic/5.js: Added.
* tests/modules/execution-order-cyclic/6.js: Added.
* tests/modules/execution-order-cyclic/7.js: Added.
* tests/modules/execution-order-cyclic/8.js: Added.
* tests/modules/execution-order-cyclic/9.js: Added.
* tests/modules/execution-order-dag.js: Added.
* tests/modules/execution-order-dag/1.js: Added.
* tests/modules/execution-order-dag/10.js: Added.
* tests/modules/execution-order-dag/2.js: Added.
* tests/modules/execution-order-dag/3.js: Added.
* tests/modules/execution-order-dag/4.js: Added.
* tests/modules/execution-order-dag/5.js: Added.
* tests/modules/execution-order-dag/6.js: Added.
* tests/modules/execution-order-dag/7.js: Added.
* tests/modules/execution-order-dag/8.js: Added.
* tests/modules/execution-order-dag/9.js: Added.
* tests/modules/execution-order-depth.js: Added.
* tests/modules/execution-order-depth/1.js: Added.
* tests/modules/execution-order-depth/2.js: Added.
* tests/modules/execution-order-depth/3.js: Added.
* tests/modules/execution-order-self.js: Added.
* tests/modules/execution-order-sibling.js: Added.
* tests/modules/execution-order-sibling/1.js: Added.
* tests/modules/execution-order-sibling/2.js: Added.
* tests/modules/execution-order-sibling/3.js: Added.
* tests/modules/execution-order-tree.js: Added.
* tests/modules/execution-order-tree/1.js: Added.
* tests/modules/execution-order-tree/10.js: Added.
* tests/modules/execution-order-tree/11.js: Added.
* tests/modules/execution-order-tree/2.js: Added.
* tests/modules/execution-order-tree/3.js: Added.
* tests/modules/execution-order-tree/4.js: Added.
* tests/modules/execution-order-tree/5.js: Added.
* tests/modules/execution-order-tree/6.js: Added.
* tests/modules/execution-order-tree/7.js: Added.
* tests/modules/execution-order-tree/8.js: Added.
* tests/modules/execution-order-tree/9.js: Added.
* tests/modules/export-conflict-ok.js: Added.
* tests/modules/export-conflict-ok/A.js: Added.
* tests/modules/export-conflict-ok/B.js: Added.
* tests/modules/export-conflict-ok/main.js: Added.
* tests/modules/export-from.js: Added.
* tests/modules/export-from/main.js: Added.
* tests/modules/export-from/second.js: Added.
* tests/modules/export-with-declarations-list.js: Added.
* tests/modules/export-with-declarations-list/main.js: Added.
* tests/modules/exported-function-may-be-called-before-module-is-executed.js: Added.
* tests/modules/exported-function-may-be-called-before-module-is-executed/1.js: Added.
* tests/modules/exported-function-may-be-called-before-module-is-executed/2.js: Added.
(export.add):
(export.raise):
* tests/modules/import-error.js: Added.
* tests/modules/import-error/export-ambiguous-1.js: Added.
* tests/modules/import-error/export-ambiguous-2.js: Added.
* tests/modules/import-error/export-ambiguous.js: Added.
* tests/modules/import-error/export-default-from-star-2.js: Added.
(export.default.Cocoa):
* tests/modules/import-error/export-default-from-star.js: Added.
* tests/modules/import-error/export-not-found.js: Added.
* tests/modules/import-error/import-ambiguous.js: Added.
* tests/modules/import-error/import-default-from-star.js: Added.
* tests/modules/import-error/import-not-found.js: Added.
* tests/modules/imported-bindings-are-immutable.js: Added.
* tests/modules/imported-bindings-are-immutable/bindings.js: Added.
(export.functionDeclaration):
(export.classDeclaration):
* tests/modules/imported-bindings-can-be-changed-in-original-module.js: Added.
* tests/modules/imported-bindings-can-be-changed-in-original-module/bindings.js: Added.
* tests/modules/indirect-export-error.js: Added.
* tests/modules/indirect-export-error/indirect-export-ambiguous-2.js: Added.
* tests/modules/indirect-export-error/indirect-export-ambiguous-3.js: Added.
* tests/modules/indirect-export-error/indirect-export-ambiguous-4.js: Added.
* tests/modules/indirect-export-error/indirect-export-ambiguous.js: Added.
* tests/modules/indirect-export-error/indirect-export-default-2.js: Added.
* tests/modules/indirect-export-error/indirect-export-default-3.js: Added.
(export.default.Cocoa):
* tests/modules/indirect-export-error/indirect-export-default.js: Added.
* tests/modules/indirect-export-error/indirect-export-not-found-2.js: Added.
* tests/modules/indirect-export-error/indirect-export-not-found.js: Added.
* tests/modules/module-eval.js: Added.
* tests/modules/module-eval/A.js: Added.
* tests/modules/module-eval/B.js: Added.
* tests/modules/module-eval/drink.js: Added.
* tests/modules/module-is-strict-code.js: Added.
* tests/modules/namespace-ambiguous.js: Added.
* tests/modules/namespace-ambiguous/ambiguous-2.js: Added.
* tests/modules/namespace-ambiguous/ambiguous-3.js: Added.
* tests/modules/namespace-ambiguous/ambiguous-4.js: Added.
* tests/modules/namespace-ambiguous/ambiguous.js: Added.
* tests/modules/namespace-error.js: Added.
* tests/modules/namespace-error/namespace-local-error-should-hide-global-ambiguity-2.js: Added.
* tests/modules/namespace-error/namespace-local-error-should-hide-global-ambiguity-3.js: Added.
* tests/modules/namespace-error/namespace-local-error-should-hide-global-ambiguity-4.js: Added.
* tests/modules/namespace-error/namespace-local-error-should-hide-global-ambiguity-5.js: Added.
* tests/modules/namespace-error/namespace-local-error-should-hide-global-ambiguity-6.js: Added.
* tests/modules/namespace-error/namespace-local-error-should-hide-global-ambiguity-7.js: Added.
* tests/modules/namespace-error/namespace-local-error-should-hide-global-ambiguity.js: Added.
* tests/modules/namespace-tdz.js: Added.
* tests/modules/namespace-tdz/A.js: Added.
* tests/modules/namespace-tdz/B.js: Added.
(export.later):
* tests/modules/namespace-tdz/main.js: Added.
* tests/modules/namespace.js: Added.
* tests/modules/namespace/additional-drink.js: Added.
* tests/modules/namespace/drink.js: Added.
(export.default.changeCappuccino):
* tests/modules/namespace/more-additional-drink.js: Added.
* tests/modules/resources/assert.js: Added.
(export.shouldBe):
(export.shouldThrow):
* tests/modules/scopes.js: Added.
* tests/modules/scopes/additional-drink.js: Added.
* tests/modules/scopes/drink.js: Added.
(export.default.changeCappuccino):
* tests/modules/scopes/more-additional-drink.js: Added.
* tests/modules/this-should-be-undefined.js: Added.
* tests/stress/modules-syntax-error-with-names.js:
* tests/stress/modules-syntax-error.js:
* tests/stress/modules-syntax.js:
2015-09-05 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement ModuleNamespaceObject
https://bugs.webkit.org/show_bug.cgi?id=148705
Reviewed by Geoffrey Garen.
Implement Module namespace object.
That is used when importing the module with the form `import * as namespace from "mod"`.
The module namespace object is non-extensible object that has the bindings to the original module
as the property.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::moduleNamespaceObjectStructure):
* runtime/JSModuleNamespaceObject.cpp: Added.
(JSC::JSModuleNamespaceObject::JSModuleNamespaceObject):
(JSC::JSModuleNamespaceObject::finishCreation):
(JSC::JSModuleNamespaceObject::destroy):
(JSC::JSModuleNamespaceObject::visitChildren):
(JSC::callbackGetter):
(JSC::JSModuleNamespaceObject::getOwnPropertySlot):
(JSC::JSModuleNamespaceObject::put):
(JSC::JSModuleNamespaceObject::putByIndex):
(JSC::JSModuleNamespaceObject::deleteProperty):
(JSC::JSModuleNamespaceObject::getOwnPropertyNames):
(JSC::JSModuleNamespaceObject::defineOwnProperty):
(JSC::moduleNamespaceObjectSymbolIterator):
* runtime/JSModuleNamespaceObject.h: Added.
(JSC::JSModuleNamespaceObject::create):
(JSC::JSModuleNamespaceObject::createStructure):
(JSC::JSModuleNamespaceObject::moduleRecord):
* runtime/JSModuleRecord.cpp:
(JSC::JSModuleRecord::visitChildren):
(JSC::getExportedNames):
(JSC::JSModuleRecord::getModuleNamespace):
(JSC::JSModuleRecord::instantiateDeclarations):
* runtime/JSModuleRecord.h:
2015-09-04 Mark Lam <mark.lam@apple.com>
Rollout r189411, r189413: Broke JSC tests.
Not reviewed.
* API/tests/PingPongStackOverflowTest.cpp: Removed.
* API/tests/PingPongStackOverflowTest.h: Removed.
* API/tests/testapi.c:
(main):
* JavaScriptCore.xcodeproj/project.pbxproj:
* interpreter/CallFrame.h:
(JSC::ExecState::operator=):
(JSC::ExecState::callerFrame):
(JSC::ExecState::argIndexForRegister):
(JSC::ExecState::callerFrameOrVMEntryFrame):
(JSC::ExecState::callerFrameAndPC):
* interpreter/Interpreter.cpp:
(JSC::UnwindFunctor::UnwindFunctor):
(JSC::UnwindFunctor::operator()):
(JSC::Interpreter::unwind):
* interpreter/Interpreter.h:
(JSC::NativeCallFrameTracer::NativeCallFrameTracer):
(JSC::Interpreter::sampler):
* jit/CCallHelpers.h:
(JSC::CCallHelpers::jumpToExceptionHandler):
* jit/JITExceptions.cpp:
(JSC::genericUnwind):
* jit/JITExceptions.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_catch):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_catch):
* jit/JITOperations.cpp:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/VM.h:
(JSC::VM::exceptionOffset):
(JSC::VM::vmEntryFrameForThrowOffset):
(JSC::VM::topVMEntryFrameOffset):
(JSC::VM::callFrameForThrowOffset):
2015-09-04 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Test Runtime.saveResult and $n values
https://bugs.webkit.org/show_bug.cgi?id=148837
Reviewed by Timothy Hatcher.
* inspector/InjectedScriptSource.js:
(InjectedScript.prototype._evaluateOn):
We don't need to be in the console object group to put the value
in the saved results list. That strong reference will ensure $n
values are always alive even if other object groups were used
when creating and subsequently released.
2015-09-04 Mark Lam <mark.lam@apple.com>
[Follow up] StackOverflow stack unwinding should stop at native frames.
https://bugs.webkit.org/show_bug.cgi?id=148749
Rubber stamped by Michael Saboff.
Speculative fix for jsc test failure.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::unwind):
2015-09-04 Mark Lam <mark.lam@apple.com>
StackOverflow stack unwinding should stop at native frames.
https://bugs.webkit.org/show_bug.cgi?id=148749
Reviewed by Michael Saboff.
In the present code, after ping-pong'ing back and forth between native and JS
code a few times, if we have a stack overflow on re-entry into the VM to run
JS code's whose stack frame would overflow the JS stack, the code will end up
unwinding past the native function that is making the call to re-enter the VM.
As a result, any clean up code (e.g. destructors for stack variables) in the
skipped native function frame (and its chain of native function callers) will
not be called.
This patch is based on the Michael Saboff's fix of this issue landed on the
jsc-tailcall branch: http://trac.webkit.org/changeset/188555
We now check for the case where there are no JS frames to unwind since the
last native frame, and treat the exception as an unhandled exception. The
native function is responsible for further propagating the exception if needed.
Other supporting work:
1. Remove vm->vmEntryFrameForThrow. It should always be the same as
vm->topVMEntryFrame.
2. Change operationThrowStackOverflowError() to use the throwStackOverflowError()
helper function instead of rolling its own.
3. In the LLINT vm entry, set vm->topVMEntryFrame as soon as the entry frame is
fully initialized (instead of waiting). With this, we can always reliably
tell which VMEntryFrame is on top.
4. Added a test that exercises this edge case. The test should not hang or crash.
* API/tests/PingPongStackOverflowTest.cpp: Added.
(PingPongStackOverflowObject_hasInstance):
(testPingPongStackOverflow):
* API/tests/PingPongStackOverflowTest.h: Added.
* API/tests/testapi.c:
(main):
* JavaScriptCore.xcodeproj/project.pbxproj:
* interpreter/Interpreter.cpp:
(JSC::unwindCallFrame):
(JSC::getStackFrameCodeType):
(JSC::UnwindFunctor::UnwindFunctor):
(JSC::UnwindFunctor::operator()):
(JSC::Interpreter::unwind):
* interpreter/Interpreter.h:
(JSC::NativeCallFrameTracer::NativeCallFrameTracer):
(JSC::NativeCallFrameTracerWithRestore::NativeCallFrameTracerWithRestore):
(JSC::NativeCallFrameTracerWithRestore::~NativeCallFrameTracerWithRestore):
(JSC::Interpreter::sampler):
* jit/CCallHelpers.h:
(JSC::CCallHelpers::jumpToExceptionHandler):
* jit/JITExceptions.cpp:
(JSC::genericUnwind):
* jit/JITExceptions.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_catch):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_catch):
* jit/JITOperations.cpp:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/VM.h:
(JSC::VM::exceptionOffset):
(JSC::VM::callFrameForThrowOffset):
(JSC::VM::vmEntryFrameForThrowOffset): Deleted.
(JSC::VM::topVMEntryFrameOffset): Deleted.
2015-09-04 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement the division and modulo instructions in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=148791
Reviewed by Geoffrey Garen.
This patch implements the unsigned division, signed modulo, and unsigned
modulo instructions for 32-bit integers in WebAssembly. It also
implements the context pool index instructions, which are needed for
testing. (pack-asmjs puts numbers that are used more than once in the
constant pool.)
* assembler/X86Assembler.h:
(JSC::X86Assembler::divl_r):
* tests/stress/wasm-arithmetic.js:
* tests/stress/wasm-arithmetic.wasm:
* wasm/WASMFunctionCompiler.h:
(JSC::operationMod):
(JSC::operationUnsignedDiv):
(JSC::operationUnsignedMod):
(JSC::WASMFunctionCompiler::buildBinaryI32):
(JSC::WASMFunctionCompiler::callOperation):
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseExpressionI32):
(JSC::WASMFunctionParser::parseConstantPoolIndexExpressionI32):
* wasm/WASMFunctionParser.h:
2015-09-04 Basile Clement <basile_clement@apple.com>
Fix debug output for an eval call
https://bugs.webkit.org/show_bug.cgi?id=148839
Reviewed by Filip Pizlo.
* jit/ThunkGenerators.cpp:
(JSC::virtualThunkFor):
2015-09-04 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement the signed division instruction in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=148772
Reviewed by Geoffrey Garen.
This patch implements the signed division instruction in WebAssembly
for 32-bit integers. We use the IDIV instruction on x86 and x86-64 and
use a C function on all other platforms. We throw an exception if
- the denominator is zero, or
- the numerator is -2^31 and the denominator is -1.
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* tests/stress/wasm-arithmetic.js:
(shouldBe):
(shouldThrow):
* tests/stress/wasm-arithmetic.wasm:
* wasm/WASMFunctionCompiler.h:
(JSC::operationDiv):
(JSC::WASMFunctionCompiler::endFunction):
(JSC::WASMFunctionCompiler::buildBinaryI32):
(JSC::WASMFunctionCompiler::appendCall):
(JSC::WASMFunctionCompiler::appendCallWithExceptionCheck):
(JSC::WASMFunctionCompiler::callOperation):
(JSC::WASMFunctionCompiler::throwStackOverflowError): Deleted.
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseExpressionI32):
2015-09-04 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement the GetLocal and SetLocal instructions in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=148793
Reviewed by Saam Barati.
This patch implements the GetLocal and SetLocal instructions for locals
of type int32 in WebAssembly. A "local" in this context is either an
argument or a local variable.
* tests/stress/wasm-locals.js: Added.
(shouldBe):
* tests/stress/wasm-locals.wasm: Added.
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::buildSetLocal):
(JSC::WASMFunctionCompiler::buildGetLocal):
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseSetLocalStatement):
(JSC::WASMFunctionParser::parseExpressionI32):
(JSC::WASMFunctionParser::parseGetLocalExpressionI32):
* wasm/WASMFunctionParser.h:
* wasm/WASMFunctionSyntaxChecker.h:
(JSC::WASMFunctionSyntaxChecker::buildSetLocal):
(JSC::WASMFunctionSyntaxChecker::buildGetLocal):
2015-09-04 Basile Clement <basile_clement@apple.com>
Unreviewed, add missing copyright to file from r189336
* bytecompiler/SetForScope.h:
2015-09-04 Brian Burg <bburg@apple.com>
Web Inspector: InspectorController should support multiple frontend channels
https://bugs.webkit.org/show_bug.cgi?id=148538
Reviewed by Joseph Pecoraro.
Instead of a singleton, it should be possible to have multiple channels open
at the same time and to individually close channels as frontends come and go.
The FrontendRouter class keeps a list of open FrontendChannels and sends messages
to the appropriate frontends based on whether the message is a response or event.
Each InspectorController owns a single FrontendRouter and BackendDispatcher instance.
Inspector backend code that sends messages to the frontend should switch over to
using the router rather than directly using a FrontendChannel.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* inspector/InspectorBackendDispatcher.cpp: Move constructors/destructors out of the header
to avoid including InspectorFrontendRouter everywhere. Use the router instead of a
specific frontend channel. Remove guards that are no longer necessary since the router
is guaranteed to outlive the backend dispatcher.
(Inspector::SupplementalBackendDispatcher::SupplementalBackendDispatcher):
(Inspector::SupplementalBackendDispatcher::~SupplementalBackendDispatcher):
(Inspector::BackendDispatcher::BackendDispatcher):
(Inspector::BackendDispatcher::create):
(Inspector::BackendDispatcher::isActive):
(Inspector::BackendDispatcher::registerDispatcherForDomain):
(Inspector::BackendDispatcher::sendResponse):
(Inspector::BackendDispatcher::sendPendingErrors):
* inspector/InspectorBackendDispatcher.h:
(Inspector::SupplementalBackendDispatcher::SupplementalBackendDispatcher): Deleted.
(Inspector::SupplementalBackendDispatcher::~SupplementalBackendDispatcher): Deleted.
(Inspector::BackendDispatcher::clearFrontend): Deleted, no longer necessary.
(Inspector::BackendDispatcher::isActive): Moved to implementation file.
(Inspector::BackendDispatcher::BackendDispatcher): Moved to implementation file.
* inspector/InspectorFrontendRouter.cpp: Added.
(Inspector::FrontendRouter::create):
(Inspector::FrontendRouter::connectFrontend):
(Inspector::FrontendRouter::disconnectFrontend):
(Inspector::FrontendRouter::disconnectAllFrontends):
(Inspector::FrontendRouter::leakChannel):
(Inspector::FrontendRouter::hasLocalFrontend):
(Inspector::FrontendRouter::hasRemoteFrontend):
(Inspector::FrontendRouter::sendEvent):
(Inspector::FrontendRouter::sendResponse):
* inspector/InspectorFrontendRouter.h: Added.
* inspector/JSGlobalObjectInspectorController.cpp: Remove guards that are no longer necessary.
The frontend router and backend dispatcher now have the same lifetime as the controller.
Explicitly connect/disconnect the frontend channel.
(Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
(Inspector::JSGlobalObjectInspectorController::globalObjectDestroyed):
(Inspector::JSGlobalObjectInspectorController::connectFrontend):
(Inspector::JSGlobalObjectInspectorController::disconnectFrontend):
(Inspector::JSGlobalObjectInspectorController::disconnectAllFrontends):
(Inspector::JSGlobalObjectInspectorController::dispatchMessageFromFrontend):
(Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
(Inspector::JSGlobalObjectInspectorController::pause): Deleted.
* inspector/JSGlobalObjectInspectorController.h:
* inspector/agents/InspectorAgent.cpp:
* inspector/agents/InspectorConsoleAgent.cpp:
* inspector/agents/InspectorDebuggerAgent.cpp:
* inspector/agents/InspectorRuntimeAgent.cpp:
* inspector/augmentable/AugmentableInspectorController.h:
(Inspector::AugmentableInspectorController::connected):
* inspector/remote/RemoteInspectorDebuggable.h:
* inspector/remote/RemoteInspectorDebuggableConnection.mm:
(Inspector::RemoteInspectorDebuggableConnection::close):
* inspector/scripts/codegen/generate_cpp_alternate_backend_dispatcher_header.py:
(CppAlternateBackendDispatcherHeaderGenerator.generate_output):
* inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
(ObjCFrontendDispatcherImplementationGenerator._generate_event): Use the router.
* runtime/JSGlobalObjectDebuggable.cpp:
(JSC::JSGlobalObjectDebuggable::disconnect):
* runtime/JSGlobalObjectDebuggable.h:
2015-09-04 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Expand Console domain test coverage
https://bugs.webkit.org/show_bug.cgi?id=148740
Reviewed by Brian Burg.
* inspector/protocol/Console.json:
Update the description of this command now that it only
manipulates $0, and not $1, $2, .. $n.
2015-09-04 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Test RuntimeAgent.parse, detecting if a script parse error is recoverable
https://bugs.webkit.org/show_bug.cgi?id=148790
Reviewed by Timothy Hatcher.
* parser/Lexer.cpp:
(JSC::Lexer<T>::lex):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::printUnexpectedTokenText):
* parser/ParserTokens.h:
More consistently name and treat unterminated numeric literals.
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
Treat multiline capable unterminated literals as recoverable.
2015-08-25 Basile Clement <basile_clement@apple.com>
Get rid of FTLValueFormat
https://bugs.webkit.org/show_bug.cgi?id=148448
Reviewed by Michael Saboff.
FTL::ValueFormat is nothing more than DataFormat (and is actually
slightly less). Let's get rid of it.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/DataFormat.cpp: Renamed from Source/JavaScriptCore/ftl/FTLValueFormat.h.
(WTF::printInternal):
* bytecode/DataFormat.h:
* ftl/FTLAvailableRecovery.h:
(JSC::FTL::AvailableRecovery::AvailableRecovery):
(JSC::FTL::AvailableRecovery::format):
* ftl/FTLExitArgument.h:
(JSC::FTL::ExitArgument::ExitArgument):
(JSC::FTL::ExitArgument::operator!):
(JSC::FTL::ExitArgument::format):
(JSC::FTL::ExitArgument::withFormat):
* ftl/FTLExitValue.cpp:
(JSC::FTL::ExitValue::dataFormat):
* ftl/FTLExitValue.h:
(JSC::FTL::ExitValue::recovery):
(JSC::FTL::ExitValue::recoveryFormat):
* ftl/FTLFormattedValue.h:
(JSC::FTL::FormattedValue::FormattedValue):
(JSC::FTL::FormattedValue::operator!):
(JSC::FTL::FormattedValue::format):
(JSC::FTL::int32Value):
(JSC::FTL::booleanValue):
(JSC::FTL::jsValueValue):
(JSC::FTL::doubleValue):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
(JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
(JSC::FTL::DFG::LowerDFGToLLVM::convertDoubleToInt32):
(JSC::FTL::DFG::LowerDFGToLLVM::exitValueForNode):
(JSC::FTL::DFG::LowerDFGToLLVM::exitArgument):
(JSC::FTL::DFG::LowerDFGToLLVM::addAvailableRecovery):
* ftl/FTLOSRExit.cpp:
(JSC::FTL::OSRExit::OSRExit):
* ftl/FTLOSRExit.h:
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::reboxAccordingToFormat):
(JSC::FTL::compileRecovery):
(JSC::FTL::compileStub):
* ftl/FTLValueFormat.cpp: Removed.
2015-09-04 Basile Clement <basile_clement@apple.com>
Introduce RegisterMap<T>
https://bugs.webkit.org/show_bug.cgi?id=148335
Reviewed by Michael Saboff.
Introduce RegisterMap<T>, GPRMap<T> and FPRMap<T> dense mappings for
Reg, GPRReg and FPRReg.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* jit/RegisterMap.h: Added.
(JSC::RegisterMap::operator[]):
(JSC::GPRMap::operator[]):
(JSC::FPRMap::operator[]):
2015-09-04 Andreas Kling <akling@apple.com>
Remove some unused functions from MarkedBlock and MarkedSpace.
<https://webkit.org/b/148748>
Reviewed by Darin Adler.
* ftl/FTLAbstractHeapRepository.h:
* heap/MarkedBlock.h:
(JSC::MarkedBlock::offsetOfMarks): Deleted.
(JSC::MarkedBlock::didConsumeEmptyFreeList): Deleted.
* heap/MarkedSpace.h:
2015-09-04 Basile Clement <basile_clement@apple.com>
Make a bunch of MacroAssembler operations constexpr
https://bugs.webkit.org/show_bug.cgi?id=148334
Reviewed by Saam Barati.
This is in preparation of https://bugs.webkit.org/show_bug.cgi?id=148335 .
* assembler/ARM64Assembler.h:
(JSC::ARM64Registers::isSp):
(JSC::ARM64Registers::isZr):
(JSC::ARM64Assembler::firstRegister):
(JSC::ARM64Assembler::lastRegister):
(JSC::ARM64Assembler::firstFPRegister):
(JSC::ARM64Assembler::lastFPRegister):
(JSC::ARM64Assembler::isSp):
(JSC::ARM64Assembler::isZr):
* assembler/ARMAssembler.h:
(JSC::ARMAssembler::firstRegister):
(JSC::ARMAssembler::lastRegister):
(JSC::ARMAssembler::firstFPRegister):
(JSC::ARMAssembler::lastFPRegister):
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::firstRegister):
(JSC::AbstractMacroAssembler::lastRegister):
(JSC::AbstractMacroAssembler::firstFPRegister):
(JSC::AbstractMacroAssembler::lastFPRegister):
* assembler/MIPSAssembler.h:
(JSC::MIPSAssembler::firstRegister):
(JSC::MIPSAssembler::lastRegister):
(JSC::MIPSAssembler::firstFPRegister):
(JSC::MIPSAssembler::lastFPRegister):
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::nextRegister):
(JSC::MacroAssembler::nextFPRegister):
(JSC::MacroAssembler::numberOfRegisters):
(JSC::MacroAssembler::registerIndex):
(JSC::MacroAssembler::numberOfFPRegisters):
(JSC::MacroAssembler::fpRegisterIndex):
(JSC::MacroAssembler::totalNumberOfRegisters):
* assembler/SH4Assembler.h:
(JSC::SH4Assembler::firstRegister):
(JSC::SH4Assembler::lastRegister):
(JSC::SH4Assembler::firstFPRegister):
(JSC::SH4Assembler::lastFPRegister):
* assembler/X86Assembler.h:
(JSC::X86Assembler::firstRegister):
(JSC::X86Assembler::lastRegister):
(JSC::X86Assembler::firstFPRegister):
(JSC::X86Assembler::lastFPRegister):
2015-08-24 Basile Clement <basile_clement@apple.com>
Add a bunch of operators
https://bugs.webkit.org/show_bug.cgi?id=148337
Reviewed by Saam Barati.
* jit/GPRInfo.h:
(JSC::JSValueRegs::operator bool):
(JSC::JSValueRegs::operator==):
(JSC::JSValueRegs::operator!=):
(JSC::JSValueSource::operator bool):
(JSC::JSValueRegs::operator!):
(JSC::JSValueSource::operator!):
* jit/Reg.h:
(JSC::Reg::operator bool):
2015-09-04 Basile Clement <basile_clement@apple.com>
Since r189341, es6.yaml/es6/arrow_functions_no_prototype_property.js is expected to succeed
Rubber stamped by Michael Saboff.
* tests/es6.yaml:
2015-09-04 Csaba Osztrogonác <ossy@webkit.org>
[ARM] Fix the ARM Traditional build after r189288
https://bugs.webkit.org/show_bug.cgi?id=148792
Reviewed by Zoltan Herczeg.
* assembler/MacroAssemblerARM.h: Make repatchCall public similar to changes in r189288.
(JSC::MacroAssemblerARM::repatchCall):
2015-09-03 Aleksandr Skachkov <gskachkov@gmail.com>
[ES6] Implement ES6 arrow function syntax. Prototype of arrow function should be undefined
https://bugs.webkit.org/show_bug.cgi?id=147742
Reviewed by Saam Barati.
Added correct support of prototype property for arrow function. Arrow function
doesn’t have own prototype property, so (() => {}).hasOwnProperty('prototype') === false.
Changes prevent from creation of 'prototype' property automatically during initialization
of arrow function and allow to assign & delete it later in js code.
* runtime/JSFunction.cpp:
(JSC::JSFunction::getOwnPropertySlot):
(JSC::JSFunction::deleteProperty):
* tests/stress/arrowfunction-prototype.js: Added.
2015-09-03 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r189338.
https://bugs.webkit.org/show_bug.cgi?id=148785
Caused tons of crashes (Requested by cdumez on #webkit).
Reverted changeset:
"Web Inspector: InspectorController should support multiple
frontend channels"
https://bugs.webkit.org/show_bug.cgi?id=148538
http://trac.webkit.org/changeset/189338
2015-09-03 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Instantiate Module Environment bindings and execute module
https://bugs.webkit.org/show_bug.cgi?id=148053
Reviewed by Saam Barati.
This patch implements Module Environment binding instantiation.
And since the layout of the module environment is tightly coupled with the variable
look up in LLInt / Baseline / DFG, we implement the execution part at the same time.
For the instantiation, we implement the several operations (like resolveExport)
specified in the spec. The original algorithm contains the recursive call, but it is not
good for C++ code. We flatten the algorithm by using the manual frames to avoid recursions.
By leveraging the information retrieved by the above operations, we instantiate and
initialize the slots of the module environment.
The module namespace object is not implemented yet in this patch. It will be implemented
and instantiated in the module environment in the subsequent patch[1].
To look up the imported module bindings in the JS code, we introduce the "ModuleVar" resolve
type for resolve_scope, get_from_scope and put_to_scope. This "ModuleVar" will be filled
when linking the CodeBlock. This type is used when treating the imported bindings.
1. For resolve_scope, when linking, we resolve the actual module environment where
looked up variable resides and store it directly to the instruction. And resolve_scope
simply retrieve the stored pointer from the instruction.
2. For get_from_scope, since "ModuleVar" behavior for get_from_scope is completely same
to the "ClosureVar", we just store "ClosureVar" for get_from_scope to eliminate
unnecessary branch in LLInt layer.
3. For put_to_scope, we always emit the function call that immediately raises the error.
Because all the imported bindings are immutable and module code is always strict code.
In DFG, we just emit the ForceOSRExit. We don't make put_to_scope with "ModuleVar"
"CannotCompile" because it disables DFG compiling for the function even if this
problematic instruction is never executed.
Exported module variables inside the original module environment are just treated as the
usual heap variables. So the types for closure variables are just used. ("ClosureVar" etc.)
[1]: https://bugs.webkit.org/show_bug.cgi?id=148705
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
* bytecode/CodeBlock.h:
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedModuleProgramCodeBlock::visitChildren): Deleted.
* bytecode/UnlinkedCodeBlock.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
* interpreter/Interpreter.h:
* jit/JITOperations.cpp:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emitSlow_op_resolve_scope):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emit_op_put_to_scope):
(JSC::JIT::emitSlow_op_put_to_scope):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emitSlow_op_resolve_scope):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emit_op_put_to_scope):
(JSC::JIT::emitSlow_op_put_to_scope):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* parser/ModuleAnalyzer.cpp:
(JSC::ModuleAnalyzer::exportVariable):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* runtime/Error.cpp:
(JSC::throwSyntaxError):
* runtime/Error.h:
* runtime/Executable.cpp:
(JSC::ModuleProgramExecutable::create):
(JSC::ModuleProgramExecutable::visitChildren):
(JSC::ModuleProgramExecutable::clearCode):
* runtime/Executable.h:
* runtime/GetPutInfo.h:
(JSC::resolveTypeName):
(JSC::makeType):
(JSC::needsVarInjectionChecks):
(JSC::ResolveOp::ResolveOp):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::moduleEnvironmentStructure):
* runtime/JSLexicalEnvironment.h:
* runtime/JSModuleEnvironment.cpp: Added.
(JSC::JSModuleEnvironment::create):
(JSC::JSModuleEnvironment::finishCreation):
(JSC::JSModuleEnvironment::visitChildren):
(JSC::JSModuleEnvironment::getOwnPropertySlot):
(JSC::JSModuleEnvironment::getOwnNonIndexPropertyNames):
(JSC::JSModuleEnvironment::put):
(JSC::JSModuleEnvironment::deleteProperty):
* runtime/JSModuleEnvironment.h: Copied from Source/JavaScriptCore/runtime/JSLexicalEnvironment.h.
(JSC::JSModuleEnvironment::create):
(JSC::JSModuleEnvironment::createStructure):
(JSC::JSModuleEnvironment::offsetOfModuleRecord):
(JSC::JSModuleEnvironment::allocationSize):
(JSC::JSModuleEnvironment::moduleRecord):
(JSC::JSModuleEnvironment::moduleRecordSlot):
(JSC::JSModuleEnvironment::JSModuleEnvironment):
* runtime/JSModuleRecord.cpp:
(JSC::JSModuleRecord::visitChildren):
(JSC::JSModuleRecord::appendRequestedModule):
(JSC::JSModuleRecord::addStarExportEntry):
(JSC::JSModuleRecord::addImportEntry):
(JSC::JSModuleRecord::addExportEntry):
(JSC::ResolveQuery::ResolveQuery):
(JSC::ResolveQuery::isEmptyValue):
(JSC::ResolveQuery::isDeletedValue):
(JSC::ResolveQueryHash::hash):
(JSC::ResolveQueryHash::equal):
(JSC::resolveExportLoop):
(JSC::JSModuleRecord::link):
(JSC::JSModuleRecord::instantiateDeclarations):
(JSC::JSModuleRecord::execute):
(JSC::JSModuleRecord::dump):
* runtime/JSModuleRecord.h:
(JSC::JSModuleRecord::exportEntries):
(JSC::JSModuleRecord::importEntries):
(JSC::JSModuleRecord::starExportEntries):
(JSC::JSModuleRecord::moduleEnvironment):
(JSC::JSModuleRecord::appendRequestedModule): Deleted.
(JSC::JSModuleRecord::addImportEntry): Deleted.
(JSC::JSModuleRecord::addExportEntry): Deleted.
(JSC::JSModuleRecord::addStarExportEntry): Deleted.
* runtime/JSScope.cpp:
(JSC::abstractAccess):
(JSC::JSScope::collectVariablesUnderTDZ):
(JSC::JSScope::isModuleScope):
* runtime/JSScope.h:
* runtime/ModuleLoaderObject.cpp:
2015-09-03 Brian Burg <bburg@apple.com>
Web Inspector: InspectorController should support multiple frontend channels
https://bugs.webkit.org/show_bug.cgi?id=148538
Reviewed by Joseph Pecoraro.
Instead of a singleton, it should be possible to have multiple channels open
at the same time and to individually close channels as frontends come and go.
The FrontendRouter class keeps a list of open FrontendChannels and sends messages
to the appropriate frontends based on whether the message is a response or event.
Each InspectorController owns a single FrontendRouter and BackendDispatcher instance.
Inspector backend code that sends messages to the frontend should switch over to
using the router rather than directly using a FrontendChannel.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* inspector/InspectorBackendDispatcher.cpp: Move constructors/destructors out of the header
to avoid including InspectorFrontendRouter everywhere. Use the router instead of a
specific frontend channel. Remove guards that are no longer necessary since the router
is guaranteed to outlive the backend dispatcher.
(Inspector::SupplementalBackendDispatcher::SupplementalBackendDispatcher):
(Inspector::SupplementalBackendDispatcher::~SupplementalBackendDispatcher):
(Inspector::BackendDispatcher::BackendDispatcher):
(Inspector::BackendDispatcher::create):
(Inspector::BackendDispatcher::isActive):
(Inspector::BackendDispatcher::registerDispatcherForDomain):
(Inspector::BackendDispatcher::sendResponse):
(Inspector::BackendDispatcher::sendPendingErrors):
* inspector/InspectorBackendDispatcher.h:
(Inspector::SupplementalBackendDispatcher::SupplementalBackendDispatcher): Deleted.
(Inspector::SupplementalBackendDispatcher::~SupplementalBackendDispatcher): Deleted.
(Inspector::BackendDispatcher::clearFrontend): Deleted, no longer necessary.
(Inspector::BackendDispatcher::isActive): Moved to implementation file.
(Inspector::BackendDispatcher::BackendDispatcher): Moved to implementation file.
* inspector/InspectorFrontendRouter.cpp: Added.
(Inspector::FrontendRouter::create):
(Inspector::FrontendRouter::connectFrontend):
(Inspector::FrontendRouter::disconnectFrontend):
(Inspector::FrontendRouter::disconnectAllFrontends):
(Inspector::FrontendRouter::leakChannel):
(Inspector::FrontendRouter::hasLocalFrontend):
(Inspector::FrontendRouter::hasRemoteFrontend):
(Inspector::FrontendRouter::sendEvent):
(Inspector::FrontendRouter::sendResponse):
* inspector/InspectorFrontendRouter.h: Added.
* inspector/JSGlobalObjectInspectorController.cpp: Remove guards that are no longer necessary.
The frontend router and backend dispatcher now have the same lifetime as the controller.
Explicitly connect/disconnect the frontend channel.
(Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
(Inspector::JSGlobalObjectInspectorController::globalObjectDestroyed):
(Inspector::JSGlobalObjectInspectorController::connectFrontend):
(Inspector::JSGlobalObjectInspectorController::disconnectFrontend):
(Inspector::JSGlobalObjectInspectorController::disconnectAllFrontends):
(Inspector::JSGlobalObjectInspectorController::dispatchMessageFromFrontend):
(Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
(Inspector::JSGlobalObjectInspectorController::pause): Deleted.
* inspector/JSGlobalObjectInspectorController.h:
* inspector/agents/InspectorAgent.cpp:
* inspector/agents/InspectorConsoleAgent.cpp:
* inspector/agents/InspectorDebuggerAgent.cpp:
* inspector/agents/InspectorRuntimeAgent.cpp:
* inspector/augmentable/AugmentableInspectorController.h:
(Inspector::AugmentableInspectorController::connected):
* inspector/remote/RemoteInspectorDebuggable.h:
* inspector/remote/RemoteInspectorDebuggableConnection.mm:
(Inspector::RemoteInspectorDebuggableConnection::close):
* inspector/scripts/codegen/generate_cpp_alternate_backend_dispatcher_header.py:
(CppAlternateBackendDispatcherHeaderGenerator.generate_output):
* inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
(ObjCFrontendDispatcherImplementationGenerator._generate_event): Use the router.
* runtime/JSGlobalObjectDebuggable.cpp:
(JSC::JSGlobalObjectDebuggable::disconnect):
* runtime/JSGlobalObjectDebuggable.h:
2015-09-03 Basile Clement <basile_clement@apple.com>
[ES6] Recognize calls in tail position
https://bugs.webkit.org/show_bug.cgi?id=148665
Reviewed by Saam Barati.
This patch adds the capability for the bytecode generator to recognize
and dispatch tail calls, as per ES6 spec:
http://www.ecma-international.org/ecma-262/6.0/#sec-isintailposition
This does not change the generated bytecode, but merely provides the
hook for generating tail calls in subsequent patches toward
https://bugs.webkit.org/show_bug.cgi?id=146477
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitCallInTailPosition):
(JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::emitNode):
(JSC::BytecodeGenerator::emitNodeInTailPosition):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionCallValueNode::emitBytecode):
(JSC::FunctionCallResolveNode::emitBytecode):
(JSC::FunctionCallBracketNode::emitBytecode):
(JSC::FunctionCallDotNode::emitBytecode):
(JSC::CallFunctionCallDotNode::emitBytecode):
(JSC::ApplyFunctionCallDotNode::emitBytecode):
(JSC::LogicalOpNode::emitBytecode):
(JSC::ConditionalNode::emitBytecode):
(JSC::CommaNode::emitBytecode):
(JSC::SourceElements::emitBytecode):
(JSC::IfElseNode::emitBytecode):
(JSC::DoWhileNode::emitBytecode):
(JSC::WhileNode::emitBytecode):
(JSC::ForNode::emitBytecode):
(JSC::ReturnNode::emitBytecode):
(JSC::WithNode::emitBytecode):
(JSC::TryNode::emitBytecode):
* bytecompiler/SetForScope.h: Added.
(JSC::SetForScope::SetForScope):
(JSC::SetForScope::~SetForScope):
* runtime/Options.h:
2015-08-11 Basile Clement <basile_clement@apple.com>
Add more strict mode tests
https://bugs.webkit.org/show_bug.cgi?id=147850
Reviewed by Michael Saboff.
We should have more tests in strict mode to have better test coverage.
This adds a copy of the v8-v6 tests from SunSpider as JSC stress tests,
with "use strict"; added at the top of the files.
A few modifications were necessary to make the files valid in strict
mode, namely adding a couple of "var" statements and removing some
generated code in earley-boyer that was using strings with octal
escapes.
* tests/stress/v8-crypto-strict.js: Added.
* tests/stress/v8-deltablue-strict.js: Added.
* tests/stress/v8-earley-boyer-strict.js: Added.
* tests/stress/v8-raytrace-strict.js: Added.
* tests/stress/v8-regexp-strict.js: Added.
* tests/stress/v8-richards-strict.js: Added.
* tests/stress/v8-splay-strict.js: Added.
2015-09-03 Geoffrey Garen <ggaren@apple.com>
JavaScriptCore should have some ES6 conformance tests
https://bugs.webkit.org/show_bug.cgi?id=148771
Reviewed by Chris Dumez.
I created 590 independent, reduced test cases that collectively tell us
whether we pass or fail the conformance matrix @ http://kangax.github.io/compat-table/es6/.
* tests/es6: Added.
* tests/es6.yaml: Added.
* tests/es6/Array.prototype_methods_Array.prototype.copyWithin.js: Added.
(test):
* tests/es6/Array.prototype_methods_Array.prototype.entries.js: Added.
(test):
* tests/es6/Array.prototype_methods_Array.prototype.fill.js: Added.
(test):
* tests/es6/Array.prototype_methods_Array.prototype.find.js: Added.
(test):
* tests/es6/Array.prototype_methods_Array.prototype.findIndex.js: Added.
(test):
* tests/es6/Array.prototype_methods_Array.prototype.keys.js: Added.
(test):
* tests/es6/Array.prototype_methods_Array.prototype.values.js: Added.
(test):
* tests/es6/Array.prototype_methods_Array.prototype[Symbol.iterator].js: Added.
(test):
* tests/es6/Array.prototype_methods_Array.prototype[Symbol.unscopables].js: Added.
(test):
* tests/es6/Array.prototype_methods_Array_iterator_prototype_chain.js: Added.
(test):
* tests/es6/Array_is_subclassable_Array.from.js: Added.
(test.C):
(test):
* tests/es6/Array_is_subclassable_Array.isArray_support.js: Added.
(test.C):
(test):
* tests/es6/Array_is_subclassable_Array.of.js: Added.
(test.C):
(test):
* tests/es6/Array_is_subclassable_Array.prototype.concat.js: Added.
(test.C):
(test):
* tests/es6/Array_is_subclassable_Array.prototype.filter.js: Added.
(test.C):
(test):
* tests/es6/Array_is_subclassable_Array.prototype.map.js: Added.
(test.C):
(test):
* tests/es6/Array_is_subclassable_Array.prototype.slice.js: Added.
(test.C):
(test):
* tests/es6/Array_is_subclassable_Array.prototype.splice.js: Added.
(test.C):
(test):
* tests/es6/Array_is_subclassable_correct_prototype_chain.js: Added.
(test.C):
(test):
* tests/es6/Array_is_subclassable_length_property_accessing.js: Added.
(test.C):
(test):
* tests/es6/Array_is_subclassable_length_property_setting.js: Added.
(test.C):
(test):
* tests/es6/Array_static_methods_Array.from_array-like_objects.js: Added.
(test):
* tests/es6/Array_static_methods_Array.from_generator_instances.js: Added.
(test.iterable):
(test):
* tests/es6/Array_static_methods_Array.from_generic_iterables.js: Added.
(test):
* tests/es6/Array_static_methods_Array.from_instances_of_generic_iterables.js: Added.
(test):
* tests/es6/Array_static_methods_Array.from_iterator_closing.js: Added.
(test.):
(test):
* tests/es6/Array_static_methods_Array.from_map_function_array-like_objects.js: Added.
(test):
* tests/es6/Array_static_methods_Array.from_map_function_generator_instances.js: Added.
(test.iterable):
(test):
* tests/es6/Array_static_methods_Array.from_map_function_generic_iterables.js: Added.
(test):
* tests/es6/Array_static_methods_Array.from_map_function_instances_of_iterables.js: Added.
(test):
* tests/es6/Array_static_methods_Array.of.js: Added.
(test):
* tests/es6/Array_static_methods_Array[Symbol.species].js: Added.
(test):
* tests/es6/Function_is_subclassable_Function.prototype.apply.js: Added.
(test.C):
(test):
* tests/es6/Function_is_subclassable_Function.prototype.bind.js: Added.
(test.C):
(test):
* tests/es6/Function_is_subclassable_Function.prototype.call.js: Added.
(test.C):
(test):
* tests/es6/Function_is_subclassable_can_be_called.js: Added.
(test.C):
(test):
* tests/es6/Function_is_subclassable_can_be_used_with_new.js: Added.
(test.C):
(test):
* tests/es6/Function_is_subclassable_correct_prototype_chain.js: Added.
(test.C):
(test):
* tests/es6/HTML-style_comments.js: Added.
(test):
* tests/es6/Map_-0_key_converts_to_+0.js: Added.
(test.set var):
* tests/es6/Map_Map.prototype.clear.js: Added.
(test):
* tests/es6/Map_Map.prototype.delete.js: Added.
(test):
* tests/es6/Map_Map.prototype.entries.js: Added.
(test):
* tests/es6/Map_Map.prototype.forEach.js: Added.
(test):
* tests/es6/Map_Map.prototype.keys.js: Added.
(test):
* tests/es6/Map_Map.prototype.set_returns_this.js: Added.
* tests/es6/Map_Map.prototype.size.js: Added.
* tests/es6/Map_Map.prototype.values.js: Added.
(test):
* tests/es6/Map_Map.prototype[Symbol.iterator].js: Added.
(test):
* tests/es6/Map_Map[Symbol.species].js: Added.
(test):
* tests/es6/Map_Map_iterator_prototype_chain.js: Added.
(test):
* tests/es6/Map_basic_functionality.js: Added.
* tests/es6/Map_constructor_accepts_null.js: Added.
(test):
* tests/es6/Map_constructor_arguments.js: Added.
* tests/es6/Map_constructor_invokes_set.js: Added.
* tests/es6/Map_constructor_requires_new.js: Added.
(test):
* tests/es6/Map_iterator_closing.js: Added.
(test.):
(test):
* tests/es6/Math_methods_Math.acosh.js: Added.
(test):
* tests/es6/Math_methods_Math.asinh.js: Added.
(test):
* tests/es6/Math_methods_Math.atanh.js: Added.
(test):
* tests/es6/Math_methods_Math.cbrt.js: Added.
(test):
* tests/es6/Math_methods_Math.clz32.js: Added.
(test):
* tests/es6/Math_methods_Math.cosh.js: Added.
(test):
* tests/es6/Math_methods_Math.expm1.js: Added.
(test):
* tests/es6/Math_methods_Math.fround.js: Added.
(test):
* tests/es6/Math_methods_Math.hypot.js: Added.
(test):
* tests/es6/Math_methods_Math.imul.js: Added.
(test):
* tests/es6/Math_methods_Math.log10.js: Added.
(test):
* tests/es6/Math_methods_Math.log1p.js: Added.
(test):
* tests/es6/Math_methods_Math.log2.js: Added.
(test):
* tests/es6/Math_methods_Math.sign.js: Added.
(test):
* tests/es6/Math_methods_Math.sinh.js: Added.
(test):
* tests/es6/Math_methods_Math.tanh.js: Added.
(test):
* tests/es6/Math_methods_Math.trunc.js: Added.
(test):
* tests/es6/Number_properties_Number.EPSILON.js: Added.
(test):
* tests/es6/Number_properties_Number.MAX_SAFE_INTEGER.js: Added.
(test):
* tests/es6/Number_properties_Number.MIN_SAFE_INTEGER.js: Added.
(test):
* tests/es6/Number_properties_Number.isFinite.js: Added.
(test):
* tests/es6/Number_properties_Number.isInteger.js: Added.
(test):
* tests/es6/Number_properties_Number.isNaN.js: Added.
(test):
* tests/es6/Number_properties_Number.isSafeInteger.js: Added.
(test):
* tests/es6/Object.prototype.__proto___absent_from_Object.createnull.js: Added.
(test):
* tests/es6/Object.prototype.__proto___correct_property_descriptor.js: Added.
(test.A):
(test):
* tests/es6/Object.prototype.__proto___get_prototype.js: Added.
(test.A):
(test):
* tests/es6/Object.prototype.__proto___present_in_Object.getOwnPropertyNames.js: Added.
(test):
* tests/es6/Object.prototype.__proto___present_in_hasOwnProperty.js: Added.
(test):
* tests/es6/Object.prototype.__proto___set_prototype.js: Added.
(test):
* tests/es6/Object_static_methods_Object.assign.js: Added.
(test):
* tests/es6/Object_static_methods_Object.getOwnPropertySymbols.js: Added.
(test):
* tests/es6/Object_static_methods_Object.is.js: Added.
(test):
* tests/es6/Object_static_methods_Object.setPrototypeOf.js: Added.
(test):
* tests/es6/Object_static_methods_accept_primitives_Object.freeze.js: Added.
(test):
* tests/es6/Object_static_methods_accept_primitives_Object.getOwnPropertyDescriptor.js: Added.
(test):
* tests/es6/Object_static_methods_accept_primitives_Object.getOwnPropertyNames.js: Added.
(test):
* tests/es6/Object_static_methods_accept_primitives_Object.getPrototypeOf.js: Added.
(test):
* tests/es6/Object_static_methods_accept_primitives_Object.isExtensible.js: Added.
(test):
* tests/es6/Object_static_methods_accept_primitives_Object.isFrozen.js: Added.
(test):
* tests/es6/Object_static_methods_accept_primitives_Object.isSealed.js: Added.
(test):
* tests/es6/Object_static_methods_accept_primitives_Object.keys.js: Added.
(test):
* tests/es6/Object_static_methods_accept_primitives_Object.preventExtensions.js: Added.
(test):
* tests/es6/Object_static_methods_accept_primitives_Object.seal.js: Added.
(test):
* tests/es6/Promise_Promise.all.js: Added.
(test):
* tests/es6/Promise_Promise.all_generic_iterables.js: Added.
(test):
* tests/es6/Promise_Promise.race.js: Added.
(test):
* tests/es6/Promise_Promise.race_generic_iterables.js: Added.
(test):
* tests/es6/Promise_Promise[Symbol.species].js: Added.
(test):
* tests/es6/Promise_basic_functionality.js: Added.
(test.thenFn):
(test.catchFn):
(test.shouldNotRun):
(test):
* tests/es6/Promise_constructor_requires_new.js: Added.
(test):
* tests/es6/Promise_is_subclassable_Promise.all.js: Added.
(test.P):
(test):
* tests/es6/Promise_is_subclassable_Promise.race.js: Added.
(test.P):
(test):
* tests/es6/Promise_is_subclassable_basic_functionality.js: Added.
(test.P):
(test):
(test.catchFn):
(test.shouldNotRun):
* tests/es6/Promise_is_subclassable_correct_prototype_chain.js: Added.
(test.C):
(test):
* tests/es6/Proxy_Array.isArray_support.js: Added.
(test):
* tests/es6/Proxy_JSON.stringify_support.js: Added.
(test):
* tests/es6/Proxy_Proxy.revocable.js: Added.
(test.):
(test.get var):
(test):
* tests/es6/Proxy_apply_handler.js: Added.
(test.proxied):
(test.host.):
(test):
* tests/es6/Proxy_construct_handler.js: Added.
(test.proxied):
(test.):
(test):
* tests/es6/Proxy_constructor_requires_new.js: Added.
(test):
* tests/es6/Proxy_defineProperty_handler.js: Added.
(test.):
(test):
* tests/es6/Proxy_deleteProperty_handler.js: Added.
(test.):
(test):
* tests/es6/Proxy_enumerate_handler.js: Added.
(test.):
(test):
* tests/es6/Proxy_getOwnPropertyDescriptor_handler.js: Added.
(test.):
(test):
* tests/es6/Proxy_getPrototypeOf_handler.js: Added.
(test.):
(test):
* tests/es6/Proxy_get_handler.js: Added.
(test.):
* tests/es6/Proxy_get_handler_instances_of_proxies.js: Added.
(test.):
* tests/es6/Proxy_has_handler.js: Added.
(test.):
(test):
* tests/es6/Proxy_has_handler_instances_of_proxies.js: Added.
(test.):
(test):
* tests/es6/Proxy_internal_defineProperty_calls_SetIntegrityLevel.js: Added.
(test.):
(test):
* tests/es6/Proxy_internal_defineProperty_calls_[[Set]].js: Added.
(test.):
(test):
* tests/es6/Proxy_internal_deleteProperty_calls_Array.prototype.copyWithin.js: Added.
(test.):
(test):
* tests/es6/Proxy_internal_deleteProperty_calls_Array.prototype.pop.js: Added.
(test.):
(test):
* tests/es6/Proxy_internal_deleteProperty_calls_Array.prototype.reverse.js: Added.
(test.):
(test):
* tests/es6/Proxy_internal_deleteProperty_calls_Array.prototype.shift.js: Added.
(test.):
(test):
* tests/es6/Proxy_internal_deleteProperty_calls_Array.prototype.splice.js: Added.
(test.):
(test):
* tests/es6/Proxy_internal_deleteProperty_calls_Array.prototype.unshift.js: Added.
(test.):
(test):
* tests/es6/Proxy_internal_getOwnPropertyDescriptor_calls_Function.prototype.bind.js: Added.
(test.):
(test):
* tests/es6/Proxy_internal_getOwnPropertyDescriptor_calls_Object.assign.js: Added.
(test.):
(test):
* tests/es6/Proxy_internal_getOwnPropertyDescriptor_calls_Object.prototype.hasOwnProperty.js: Added.
(test.):
(test):
* tests/es6/Proxy_internal_getOwnPropertyDescriptor_calls_[[Set]].js: Added.
(test.):
(test):
* tests/es6/Proxy_internal_get_calls_Array.from.js: Added.
(test.get var):
(test.):
* tests/es6/Proxy_internal_get_calls_Array.prototype.concat.js: Added.
(test.):
(test.get var):
* tests/es6/Proxy_internal_get_calls_Array.prototype.pop.js: Added.
(test.):
(test.get var):
* tests/es6/Proxy_internal_get_calls_Array.prototype.reverse.js: Added.
(test.):
(test.get var):
* tests/es6/Proxy_internal_get_calls_Array.prototype.shift.js: Added.
(test.):
(test.get var):
* tests/es6/Proxy_internal_get_calls_Array.prototype.splice.js: Added.
(test.):
(test.get var):
* tests/es6/Proxy_internal_get_calls_Array.prototype.toString.js: Added.
(test.get var):
(test.):
* tests/es6/Proxy_internal_get_calls_Array.prototype_iteration_methods.js: Added.
(test.get var):
(test.):
* tests/es6/Proxy_internal_get_calls_ClassDefinitionEvaluation.js: Added.
(test.):
(test.get var):
(test):
* tests/es6/Proxy_internal_get_calls_CreateDynamicFunction.js: Added.
(test.):
(test.get var):
* tests/es6/Proxy_internal_get_calls_CreateListFromArrayLike.js: Added.
(test.get var):
(test.):
(test.get Function):
* tests/es6/Proxy_internal_get_calls_Date.prototype.toJSON.js: Added.
(test.get var):
(test.):
* tests/es6/Proxy_internal_get_calls_Error.prototype.toString.js: Added.
(test.get var):
(test.):
* tests/es6/Proxy_internal_get_calls_Function.prototype.bind.js: Added.
(test.):
(test.get var):
* tests/es6/Proxy_internal_get_calls_HasBinding.js: Added.
(test.get var):
(test.):
(test.get p):
* tests/es6/Proxy_internal_get_calls_IteratorComplete_IteratorValue.js: Added.
(test.get var):
(test.iterable.Symbol.iterator.return.next.):
(test.iterable.Symbol.iterator.return.next):
(test.iterable.Symbol.iterator):
* tests/es6/Proxy_internal_get_calls_JSON.stringify.js: Added.
(test.get var):
(test.):
* tests/es6/Proxy_internal_get_calls_Object.assign.js: Added.
(test.get var):
(test.):
(test.get Object):
* tests/es6/Proxy_internal_get_calls_Object.defineProperties.js: Added.
(test.get var):
(test.):
(test.get Object):
* tests/es6/Proxy_internal_get_calls_Promise_resolve_functions.js: Added.
(test.get var):
(test.):
(test.get new):
* tests/es6/Proxy_internal_get_calls_RegExp.prototype.flags.js: Added.
(test.get var):
(test.):
* tests/es6/Proxy_internal_get_calls_RegExp.prototype.test.js: Added.
(test.get var.p.new.Proxy):
(test.get var):
(test.):
* tests/es6/Proxy_internal_get_calls_RegExp.prototype[Symbol.match].js: Added.
(test.get var.p.new.Proxy):
(test.get var):
(test.):
* tests/es6/Proxy_internal_get_calls_RegExp.prototype[Symbol.replace].js: Added.
(test.get var.p.new.Proxy):
(test.get var):
(test.):
* tests/es6/Proxy_internal_get_calls_RegExp.prototype[Symbol.search].js: Added.
(test.get var.p.new.Proxy):
(test.get var):
(test.):
* tests/es6/Proxy_internal_get_calls_RegExp.prototype[Symbol.split].js: Added.
(test.p.new.Proxy):
(test.get var):
(test.):
* tests/es6/Proxy_internal_get_calls_RegExp_constructor.js: Added.
(test.get var):
(test.):
* tests/es6/Proxy_internal_get_calls_String.prototype.match.js: Added.
(test.get var):
(test.):
* tests/es6/Proxy_internal_get_calls_String.prototype.replace.js: Added.
(test.get var):
(test.):
* tests/es6/Proxy_internal_get_calls_String.prototype.search.js: Added.
(test.get var):
(test.):
* tests/es6/Proxy_internal_get_calls_String.prototype.split.js: Added.
(test.get var):
(test.):
* tests/es6/Proxy_internal_get_calls_String.raw.js: Added.
(test.get var):
(test.):
* tests/es6/Proxy_internal_get_calls_ToPrimitive.js: Added.
(test.get var):
(test.):
* tests/es6/Proxy_internal_get_calls_ToPropertyDescriptor.js: Added.
(test.get var):
(test.):
(test.set get try):
* tests/es6/Proxy_internal_get_calls_instanceof_operator.js: Added.
(test.):
(test.get var):
* tests/es6/Proxy_internal_ownKeys_calls_SerializeJSONObject.js: Added.
(test.):
(test):
* tests/es6/Proxy_internal_ownKeys_calls_SetIntegrityLevel.js: Added.
(test.):
(test):
* tests/es6/Proxy_internal_ownKeys_calls_TestIntegrityLevel.js: Added.
(test.):
(test):
* tests/es6/Proxy_internal_set_calls_Array.from.js: Added.
(test.set var):
(test.):
(test.set Array):
* tests/es6/Proxy_internal_set_calls_Array.of.js: Added.
(test.set var):
(test.):
(test.set Array):
* tests/es6/Proxy_internal_set_calls_Array.prototype.copyWithin.js: Added.
(test.):
(test.set var):
* tests/es6/Proxy_internal_set_calls_Array.prototype.fill.js: Added.
(test.):
(test.set var):
* tests/es6/Proxy_internal_set_calls_Array.prototype.pop.js: Added.
(test.):
(test.set var):
* tests/es6/Proxy_internal_set_calls_Array.prototype.push.js: Added.
(test.):
(test.set var):
* tests/es6/Proxy_internal_set_calls_Array.prototype.reverse.js: Added.
(test.):
(test.set var):
* tests/es6/Proxy_internal_set_calls_Array.prototype.shift.js: Added.
(test.):
(test.set var):
* tests/es6/Proxy_internal_set_calls_Array.prototype.splice.js: Added.
(test.):
(test.set var):
* tests/es6/Proxy_internal_set_calls_Array.prototype.unshift.js: Added.
(test.):
(test.set var):
* tests/es6/Proxy_internal_set_calls_Object.assign.js: Added.
(test.set var):
(test.):
(test.set Object):
* tests/es6/Proxy_isExtensible_handler.js: Added.
(test.):
(test):
* tests/es6/Proxy_ownKeys_handler.js: Added.
(test.):
(test):
* tests/es6/Proxy_preventExtensions_handler.js: Added.
(test.):
(test):
* tests/es6/Proxy_setPrototypeOf_handler.js: Added.
(test.):
(test):
* tests/es6/Proxy_set_handler.js: Added.
(test.):
* tests/es6/Proxy_set_handler_instances_of_proxies.js: Added.
(test.):
* tests/es6/Reflect_Reflect.apply.js: Added.
(test):
* tests/es6/Reflect_Reflect.construct.js: Added.
(test):
* tests/es6/Reflect_Reflect.construct_creates_instance_from_newTarget_argument.js: Added.
(test.F):
(test):
* tests/es6/Reflect_Reflect.construct_sets_new.target_meta_property.js: Added.
(test):
* tests/es6/Reflect_Reflect.defineProperty.js: Added.
(test):
* tests/es6/Reflect_Reflect.deleteProperty.js: Added.
(test):
* tests/es6/Reflect_Reflect.enumerate.js: Added.
(test):
* tests/es6/Reflect_Reflect.get.js: Added.
* tests/es6/Reflect_Reflect.getOwnPropertyDescriptor.js: Added.
(test):
* tests/es6/Reflect_Reflect.getPrototypeOf.js: Added.
(test):
* tests/es6/Reflect_Reflect.has.js: Added.
(test):
* tests/es6/Reflect_Reflect.isExtensible.js: Added.
(test):
* tests/es6/Reflect_Reflect.ownKeys_string_keys.js: Added.
(test):
* tests/es6/Reflect_Reflect.ownKeys_symbol_keys.js: Added.
(test):
* tests/es6/Reflect_Reflect.preventExtensions.js: Added.
(test):
* tests/es6/Reflect_Reflect.set.js: Added.
* tests/es6/Reflect_Reflect.setPrototypeOf.js: Added.
(test):
* tests/es6/RegExp.prototype.compile.js: Added.
(test):
* tests/es6/RegExp.prototype_properties_RegExp.prototype.flags.js: Added.
(test):
* tests/es6/RegExp.prototype_properties_RegExp.prototype[Symbol.match].js: Added.
(test):
* tests/es6/RegExp.prototype_properties_RegExp.prototype[Symbol.replace].js: Added.
(test):
* tests/es6/RegExp.prototype_properties_RegExp.prototype[Symbol.search].js: Added.
(test):
* tests/es6/RegExp.prototype_properties_RegExp.prototype[Symbol.split].js: Added.
(test):
* tests/es6/RegExp.prototype_properties_RegExp[Symbol.species].js: Added.
(test):
* tests/es6/RegExp_is_subclassable_RegExp.prototype.exec.js: Added.
(test.R):
(test):
* tests/es6/RegExp_is_subclassable_RegExp.prototype.test.js: Added.
(test.R):
(test):
* tests/es6/RegExp_is_subclassable_basic_functionality.js: Added.
(test.R):
(test):
* tests/es6/RegExp_is_subclassable_correct_prototype_chain.js: Added.
(test.R):
(test):
* tests/es6/RegExp_syntax_extensions_hyphens_in_character_sets.js: Added.
(test):
* tests/es6/RegExp_syntax_extensions_incomplete_patterns_and_quantifiers.js: Added.
* tests/es6/RegExp_syntax_extensions_invalid_Unicode_escapes.js: Added.
(test):
* tests/es6/RegExp_syntax_extensions_invalid_backreferences_become_octal_escapes.js: Added.
(test):
* tests/es6/RegExp_syntax_extensions_invalid_character_escapes.js: Added.
(test):
* tests/es6/RegExp_syntax_extensions_invalid_control-character_escapes.js: Added.
(test):
* tests/es6/RegExp_syntax_extensions_invalid_hexadecimal_escapes.js: Added.
(test):
* tests/es6/RegExp_syntax_extensions_octal_escape_sequences.js: Added.
(test):
* tests/es6/RegExp_y_and_u_flags_u_flag.js: Added.
(test):
* tests/es6/RegExp_y_and_u_flags_u_flag_Unicode_code_point_escapes.js: Added.
(test):
* tests/es6/RegExp_y_and_u_flags_y_flag.js: Added.
(test):
* tests/es6/RegExp_y_and_u_flags_y_flag_lastIndex.js: Added.
(test):
* tests/es6/Set_-0_key_converts_to_+0.js: Added.
(test.set forEach):
* tests/es6/Set_Set.prototype.add_returns_this.js: Added.
* tests/es6/Set_Set.prototype.clear.js: Added.
(test):
* tests/es6/Set_Set.prototype.delete.js: Added.
(test):
* tests/es6/Set_Set.prototype.entries.js: Added.
(test):
* tests/es6/Set_Set.prototype.forEach.js: Added.
(test):
* tests/es6/Set_Set.prototype.keys.js: Added.
(test):
* tests/es6/Set_Set.prototype.size.js: Added.
* tests/es6/Set_Set.prototype.values.js: Added.
(test):
* tests/es6/Set_Set.prototype[Symbol.iterator].js: Added.
(test):
* tests/es6/Set_Set[Symbol.species].js: Added.
(test):
* tests/es6/Set_Set_iterator_prototype_chain.js: Added.
(test):
* tests/es6/Set_basic_functionality.js: Added.
* tests/es6/Set_constructor_accepts_null.js: Added.
(test):
* tests/es6/Set_constructor_arguments.js: Added.
* tests/es6/Set_constructor_invokes_add.js: Added.
(test.Set.prototype.add):
(test):
* tests/es6/Set_constructor_requires_new.js: Added.
(test):
* tests/es6/Set_iterator_closing.js: Added.
(test.):
(test.Set.prototype.add):
(test):
* tests/es6/String.prototype_HTML_methods_existence.js: Added.
(test):
* tests/es6/String.prototype_HTML_methods_quotes_in_arguments_are_escaped.js: Added.
(test):
* tests/es6/String.prototype_HTML_methods_tags_names_are_lowercase.js: Added.
(test):
* tests/es6/String.prototype_methods_String.prototype.codePointAt.js: Added.
(test):
* tests/es6/String.prototype_methods_String.prototype.endsWith.js: Added.
(test):
* tests/es6/String.prototype_methods_String.prototype.includes.js: Added.
(test):
* tests/es6/String.prototype_methods_String.prototype.normalize.js: Added.
(test):
* tests/es6/String.prototype_methods_String.prototype.repeat.js: Added.
(test):
* tests/es6/String.prototype_methods_String.prototype.startsWith.js: Added.
(test):
* tests/es6/String.prototype_methods_String.prototype[Symbol.iterator].js: Added.
(test):
* tests/es6/String.prototype_methods_String_iterator_prototype_chain.js: Added.
(test):
* tests/es6/String_static_methods_String.fromCodePoint.js: Added.
(test):
* tests/es6/String_static_methods_String.raw.js: Added.
(test):
* tests/es6/Symbol_JSON.stringify_ignores_symbols.js: Added.
(test):
* tests/es6/Symbol_Object.defineProperty_support.js: Added.
(test):
* tests/es6/Symbol_Objectsymbol.js: Added.
(test):
* tests/es6/Symbol_basic_functionality.js: Added.
(test):
* tests/es6/Symbol_can_convert_with_String.js: Added.
(test):
* tests/es6/Symbol_cannot_coerce_to_string_or_number.js: Added.
(test):
* tests/es6/Symbol_global_symbol_registry.js: Added.
(test):
* tests/es6/Symbol_new_Symbol_throws.js: Added.
(test):
* tests/es6/Symbol_symbol_keys_are_hidden_to_pre-ES6_code.js: Added.
(test):
* tests/es6/Symbol_typeof_support.js: Added.
(test):
* tests/es6/Unicode_code_point_escapes_in_identifiers.js: Added.
(test):
* tests/es6/Unicode_code_point_escapes_in_strings.js: Added.
(test):
* tests/es6/WeakMap_WeakMap.prototype.delete.js: Added.
(test):
* tests/es6/WeakMap_WeakMap.prototype.set_returns_this.js: Added.
* tests/es6/WeakMap_basic_functionality.js: Added.
* tests/es6/WeakMap_constructor_accepts_null.js: Added.
(test):
* tests/es6/WeakMap_constructor_arguments.js: Added.
* tests/es6/WeakMap_constructor_invokes_set.js: Added.
* tests/es6/WeakMap_constructor_requires_new.js: Added.
(test):
* tests/es6/WeakMap_frozen_objects_as_keys.js: Added.
* tests/es6/WeakMap_iterator_closing.js: Added.
(test.):
(test):
* tests/es6/WeakMap_no_WeakMap.prototype.clear_method.js: Added.
* tests/es6/WeakSet_WeakSet.prototype.add_returns_this.js: Added.
(test):
* tests/es6/WeakSet_WeakSet.prototype.delete.js: Added.
(test):
* tests/es6/WeakSet_basic_functionality.js: Added.
(test):
* tests/es6/WeakSet_constructor_accepts_null.js: Added.
(test):
* tests/es6/WeakSet_constructor_arguments.js: Added.
(test):
* tests/es6/WeakSet_constructor_invokes_add.js: Added.
(test.WeakSet.prototype.add):
(test):
* tests/es6/WeakSet_constructor_requires_new.js: Added.
(test):
* tests/es6/WeakSet_iterator_closing.js: Added.
(test.):
(test):
* tests/es6/WeakSet_no_WeakSet.prototype.clear_method.js: Added.
(test):
* tests/es6/__proto___in_object_literals_basic_support.js: Added.
(test):
* tests/es6/__proto___in_object_literals_multiple___proto___is_an_error.js: Added.
(test):
* tests/es6/__proto___in_object_literals_not_a_computed_property.js: Added.
(test):
* tests/es6/__proto___in_object_literals_not_a_shorthand_method.js: Added.
(test):
* tests/es6/__proto___in_object_literals_not_a_shorthand_property.js: Added.
(test):
* tests/es6/arrow_functions_0_parameters.js: Added.
(test):
* tests/es6/arrow_functions_1_parameter_no_brackets.js: Added.
(test):
* tests/es6/arrow_functions_cant_be_bound_can_be_curried.js: Added.
(test.d.y):
(test):
* tests/es6/arrow_functions_correct_precedence.js: Added.
(test):
* tests/es6/arrow_functions_lexical_arguments_binding.js: Added.
(test.f):
(test):
* tests/es6/arrow_functions_lexical_new.target_binding.js: Added.
(test.C):
(test):
* tests/es6/arrow_functions_lexical_super_binding.js: Added.
(test.B.prototype.qux):
(test.B):
(test.C.prototype.baz):
(test.C):
(test):
* tests/es6/arrow_functions_lexical_this_binding.js: Added.
(test.d.y):
(test):
* tests/es6/arrow_functions_multiple_parameters.js: Added.
(test):
* tests/es6/arrow_functions_no_line_break_between_params_and_code_=_code.js: Added.
(test):
* tests/es6/arrow_functions_no_prototype_property.js: Added.
(test):
* tests/es6/arrow_functions_this_unchanged_by_call_or_apply.js: Added.
(test.d.y):
(test):
* tests/es6/block-level_function_declaration.js: Added.
(test.f):
(test):
* tests/es6/class_accessor_properties.js: Added.
(test.C.prototype.get foo):
(test.C.prototype.set bar):
(test.C):
(test):
* tests/es6/class_anonymous_class.js: Added.
* tests/es6/class_class_expression.js: Added.
(test.return.typeof.C):
(test):
* tests/es6/class_class_name_is_lexically_scoped.js: Added.
(test.C.prototype.method):
(test.C):
(test):
* tests/es6/class_class_statement.js: Added.
(test.C):
(test):
* tests/es6/class_computed_accessor_properties.js: Added.
(test.C.prototype.get garply):
(test.C.prototype.set grault):
(test.C):
(test):
* tests/es6/class_computed_names_temporal_dead_zone.js: Added.
(test.try.B.prototype.C):
(test.try.B):
(test):
* tests/es6/class_computed_prototype_methods.js: Added.
(test.C.prototype.foo):
(test.C):
(test):
* tests/es6/class_computed_static_accessor_properties.js: Added.
(test.C.prototype.get garply):
(test.C.prototype.set grault):
(test.C):
(test):
* tests/es6/class_computed_static_methods.js: Added.
(test.C.foo):
(test.C):
(test):
* tests/es6/class_constructor.js: Added.
(test.C):
(test):
* tests/es6/class_constructor_requires_new.js: Added.
(test.C):
(test):
* tests/es6/class_extends.js: Added.
(test.B):
(test.C):
(test):
* tests/es6/class_extends_expressions.js: Added.
(test.C):
(test):
* tests/es6/class_extends_null.js: Added.
(test.C):
(test):
* tests/es6/class_implicit_strict_mode.js: Added.
(test.C.method):
(test.C):
(test):
* tests/es6/class_is_block-scoped.js: Added.
(test.C):
(test):
* tests/es6/class_methods_arent_enumerable.js: Added.
(test.C.prototype.foo):
(test.C.bar):
(test.C):
(test):
* tests/es6/class_new.target.js: Added.
(test.new.f):
(test.A):
(test.B):
(test):
* tests/es6/class_prototype_methods.js: Added.
(test.C.prototype.method):
(test.C):
(test):
* tests/es6/class_static_accessor_properties.js: Added.
(test.C.prototype.get foo):
(test.C.prototype.set bar):
(test.C):
(test):
* tests/es6/class_static_methods.js: Added.
(test.C.method):
(test.C):
(test):
* tests/es6/class_string-keyed_methods.js: Added.
(test.C.prototype.string_appeared_here):
(test.C):
(test):
* tests/es6/const_basic_support.js: Added.
(test):
* tests/es6/const_basic_support_strict_mode.js: Added.
(test):
* tests/es6/const_is_block-scoped.js: Added.
(test):
* tests/es6/const_is_block-scoped_strict_mode.js: Added.
(test):
* tests/es6/const_redefining_a_const_is_an_error.js: Added.
(test):
* tests/es6/const_redefining_a_const_strict_mode.js: Added.
(test):
* tests/es6/const_temporal_dead_zone.js: Added.
(test.passed):
(test):
* tests/es6/const_temporal_dead_zone_strict_mode.js: Added.
(test.passed):
(test):
* tests/es6/default_function_parameters_arguments_object_interaction.js: Added.
(test):
* tests/es6/default_function_parameters_basic_functionality.js: Added.
(test):
* tests/es6/default_function_parameters_defaults_can_refer_to_previous_params.js: Added.
(test):
* tests/es6/default_function_parameters_explicit_undefined_defers_to_the_default.js: Added.
(test):
* tests/es6/default_function_parameters_new_Function_support.js: Added.
(test):
* tests/es6/default_function_parameters_separate_scope.js: Added.
(test.return):
(test):
* tests/es6/default_function_parameters_temporal_dead_zone.js: Added.
(test):
* tests/es6/destructuring_chained_iterable_destructuring.js: Added.
(test):
* tests/es6/destructuring_chained_object_destructuring.js: Added.
(test):
* tests/es6/destructuring_computed_properties.js: Added.
(test):
* tests/es6/destructuring_defaults.js: Added.
(test):
* tests/es6/destructuring_defaults_in_parameters.js: Added.
(test):
* tests/es6/destructuring_defaults_in_parameters_new_Function_support.js: Added.
(test):
* tests/es6/destructuring_defaults_in_parameters_separate_scope.js: Added.
(test.return):
(test):
* tests/es6/destructuring_defaults_let_temporal_dead_zone.js: Added.
(test):
* tests/es6/destructuring_empty_patterns.js: Added.
(test):
* tests/es6/destructuring_empty_patterns_in_parameters.js: Added.
(test):
* tests/es6/destructuring_in_for-in_loop_heads.js: Added.
(test):
* tests/es6/destructuring_in_for-of_loop_heads.js: Added.
(test):
* tests/es6/destructuring_in_parameters.js: Added.
(test):
* tests/es6/destructuring_in_parameters_arguments_interaction.js: Added.
(test):
* tests/es6/destructuring_in_parameters_function_length_property.js: Added.
(test):
* tests/es6/destructuring_in_parameters_new_Function_support.js: Added.
(test):
* tests/es6/destructuring_iterable_destructuring_expression.js: Added.
(test):
* tests/es6/destructuring_iterator_closing.js: Added.
(test.):
(test):
* tests/es6/destructuring_multiples_in_a_single_var_statement.js: Added.
(test):
* tests/es6/destructuring_nested.js: Added.
(test):
* tests/es6/destructuring_nested_rest.js: Added.
(test):
* tests/es6/destructuring_object_destructuring_expression.js: Added.
(test):
* tests/es6/destructuring_object_destructuring_with_primitives.js: Added.
(test):
* tests/es6/destructuring_parenthesised_left-hand-side_is_a_syntax_error.js: Added.
(test):
* tests/es6/destructuring_rest.js: Added.
(test):
* tests/es6/destructuring_throws_on_null_and_undefined.js: Added.
(test):
* tests/es6/destructuring_trailing_commas_in_iterable_patterns.js: Added.
(test):
* tests/es6/destructuring_trailing_commas_in_object_patterns.js: Added.
(test):
* tests/es6/destructuring_with_arrays.js: Added.
(test):
* tests/es6/destructuring_with_astral_plane_strings.js: Added.
(test):
* tests/es6/destructuring_with_generator_instances.js: Added.
(test.c):
(test.e):
(test):
* tests/es6/destructuring_with_generic_iterables.js: Added.
(test):
* tests/es6/destructuring_with_instances_of_generic_iterables.js: Added.
(test):
* tests/es6/destructuring_with_objects.js: Added.
(test):
* tests/es6/destructuring_with_sparse_arrays.js: Added.
(test):
* tests/es6/destructuring_with_strings.js: Added.
(test):
* tests/es6/for..of_loops_iterator_closing_break.js: Added.
(test.):
(test):
* tests/es6/for..of_loops_iterator_closing_throw.js: Added.
(test.):
(test):
* tests/es6/for..of_loops_with_arrays.js: Added.
(test):
* tests/es6/for..of_loops_with_astral_plane_strings.js: Added.
(test):
* tests/es6/for..of_loops_with_generator_instances.js: Added.
(test.iterable):
(test):
* tests/es6/for..of_loops_with_generic_iterables.js: Added.
(test):
* tests/es6/for..of_loops_with_instances_of_generic_iterables.js: Added.
(test):
* tests/es6/for..of_loops_with_sparse_arrays.js: Added.
(test):
* tests/es6/for..of_loops_with_strings.js: Added.
(test):
* tests/es6/function_name_property_accessor_properties.js: Added.
(test.o.get foo):
(test.o.set foo):
* tests/es6/function_name_property_bound_functions.js: Added.
(test.foo):
(test):
* tests/es6/function_name_property_class_expressions.js: Added.
(test.return.foo):
(test.name.string_appeared_here.typeof.bar.name):
(test.name.string_appeared_here.typeof.bar):
(test):
* tests/es6/function_name_property_class_prototype_methods.js: Added.
(test.C.prototype.foo):
(test.C):
(test):
* tests/es6/function_name_property_class_statements.js: Added.
(test.foo):
(test.bar.name):
(test.bar):
(test):
* tests/es6/function_name_property_class_static_methods.js: Added.
(test.C.foo):
(test.C):
(test):
* tests/es6/function_name_property_function_expressions.js: Added.
(test):
* tests/es6/function_name_property_function_statements.js: Added.
(test.foo):
(test):
* tests/es6/function_name_property_isnt_writable_is_configurable.js: Added.
(test):
* tests/es6/function_name_property_new_Function.js: Added.
(test):
* tests/es6/function_name_property_object_methods_class.js: Added.
(test.o):
* tests/es6/function_name_property_object_methods_function.js: Added.
(test.o.foo):
(test.o.bar):
(test.o.qux):
(test):
* tests/es6/function_name_property_shorthand_methods.js: Added.
(test):
* tests/es6/function_name_property_shorthand_methods_no_lexical_binding.js: Added.
(test):
* tests/es6/function_name_property_symbol-keyed_methods.js: Added.
(test.o.sym1):
(test.o.sym2):
(test):
* tests/es6/function_name_property_variables_class.js: Added.
(test.bar):
(test.qux):
* tests/es6/function_name_property_variables_function.js: Added.
(test.foo):
(test.bar):
(test):
* tests/es6/generators_%GeneratorPrototype%.constructor.js: Added.
(test.g):
(test):
* tests/es6/generators_%GeneratorPrototype%.js: Added.
(test.generatorFn):
(test):
* tests/es6/generators_%GeneratorPrototype%.return.js: Added.
(test.generator):
(test):
* tests/es6/generators_%GeneratorPrototype%.throw.js: Added.
(test.generator):
(test):
* tests/es6/generators_basic_functionality.js: Added.
(test.generator):
(test):
* tests/es6/generators_cant_use_this_with_new.js: Added.
(test.generator):
(test):
* tests/es6/generators_computed_shorthand_generators.js: Added.
(test):
* tests/es6/generators_computed_shorthand_generators_classes.js: Added.
(test.C.prototype.garply):
(test.C):
(test):
* tests/es6/generators_correct_this_binding.js: Added.
(test.generator):
(test):
* tests/es6/generators_generator_function_expressions.js: Added.
(test.generator):
(test):
* tests/es6/generators_sending.js: Added.
(test.generator):
(test):
* tests/es6/generators_shorthand_generator_methods.js: Added.
(test):
* tests/es6/generators_shorthand_generator_methods_classes.js: Added.
(test.C.prototype.generator):
(test.C):
(test):
* tests/es6/generators_string-keyed_shorthand_generator_methods.js: Added.
(test):
* tests/es6/generators_yield_*_arrays.js: Added.
(test.iterator):
(test):
* tests/es6/generators_yield_*_astral_plane_strings.js: Added.
(test.iterator):
(test):
* tests/es6/generators_yield_*_generator_instances.js: Added.
(test.iterator):
(test):
* tests/es6/generators_yield_*_generic_iterables.js: Added.
(test.iterator):
(test):
* tests/es6/generators_yield_*_instances_of_iterables.js: Added.
(test.iterator):
(test):
* tests/es6/generators_yield_*_iterator_closing.js: Added.
(test.):
(test.gen):
(test):
* tests/es6/generators_yield_*_iterator_closing_via_throw.js: Added.
(test.):
(test.gen):
(test):
* tests/es6/generators_yield_*_on_non-iterables_is_a_runtime_error.js: Added.
(test.iterator):
(test):
* tests/es6/generators_yield_*_sparse_arrays.js: Added.
(test.iterator):
(test):
* tests/es6/generators_yield_*_strings.js: Added.
(test.iterator):
(test):
* tests/es6/generators_yield_operator_precedence.js: Added.
(test.generator):
(test):
* tests/es6/let_basic_support.js: Added.
(test):
* tests/es6/let_basic_support_strict_mode.js: Added.
(test):
* tests/es6/let_for-loop_iteration_scope.js: Added.
(test):
* tests/es6/let_for-loop_iteration_scope_strict_mode.js: Added.
(test):
* tests/es6/let_for-loop_statement_scope.js: Added.
(test):
* tests/es6/let_for-loop_statement_scope_strict_mode.js: Added.
(test):
* tests/es6/let_is_block-scoped.js: Added.
(test):
* tests/es6/let_is_block-scoped_strict_mode.js: Added.
(test):
* tests/es6/let_temporal_dead_zone.js: Added.
(test.passed):
(test):
* tests/es6/let_temporal_dead_zone_strict_mode.js: Added.
(test.passed):
(test):
* tests/es6/miscellaneous_Invalid_Date.js: Added.
(test):
* tests/es6/miscellaneous_RegExp_constructor_can_alter_flags.js: Added.
(test):
* tests/es6/miscellaneous_String.prototype_case_methods_Unicode_support.js: Added.
(test):
* tests/es6/miscellaneous_accessors_arent_constructors.js: Added.
(test.get catch):
(test):
* tests/es6/miscellaneous_built-in_prototypes_are_not_instances.js: Added.
(test):
* tests/es6/miscellaneous_duplicate_property_names_in_strict_mode.js: Added.
(test):
* tests/es6/miscellaneous_function_length_is_configurable.js: Added.
(test.fn):
(test):
* tests/es6/miscellaneous_no_assignments_allowed_in_for-in_head.js: Added.
(test):
* tests/es6/miscellaneous_no_escaped_reserved_words_as_identifiers.js: Added.
(test):
* tests/es6/miscellaneous_no_semicolon_needed_after_do-while.js: Added.
(test):
* tests/es6/miscellaneous_subclassables_Boolean_is_subclassable.js: Added.
(test.C):
(test):
* tests/es6/miscellaneous_subclassables_Map_is_subclassable.js: Added.
(test):
* tests/es6/miscellaneous_subclassables_Number_is_subclassable.js: Added.
(test.C):
(test):
* tests/es6/miscellaneous_subclassables_Set_is_subclassable.js: Added.
(test):
* tests/es6/miscellaneous_subclassables_String_is_subclassable.js: Added.
(test.C):
(test):
* tests/es6/new.target_assignment_is_an_early_error.js: Added.
(test.new.f):
(test):
* tests/es6/new.target_in_constructors.js: Added.
(test.new.f):
(test):
* tests/es6/non-strict_function_semantics_function_statements_in_if-statement_clauses.js: Added.
(test.foo):
(test.else.bar):
(test.baz):
(test.qux):
(test.else.qux):
(test):
* tests/es6/non-strict_function_semantics_hoisted_block-level_function_declaration.js: Added.
(test.f):
(test.g):
(test.h):
(test):
* tests/es6/non-strict_function_semantics_labeled_function_statements.js: Added.
(test.label):
(test):
* tests/es6/object_literal_extensions_computed_accessors.js: Added.
(test.obj.get x):
(test.obj.set x):
(test):
* tests/es6/object_literal_extensions_computed_properties.js: Added.
(test):
* tests/es6/object_literal_extensions_computed_shorthand_methods.js: Added.
(test):
* tests/es6/object_literal_extensions_shorthand_methods.js: Added.
(test):
* tests/es6/object_literal_extensions_shorthand_properties.js: Added.
(test):
* tests/es6/object_literal_extensions_string-keyed_shorthand_methods.js: Added.
(test):
* tests/es6/octal_and_binary_literals_binary_literals.js: Added.
(test):
* tests/es6/octal_and_binary_literals_binary_supported_by_Number.js: Added.
(test):
* tests/es6/octal_and_binary_literals_octal_literals.js: Added.
(test):
* tests/es6/octal_and_binary_literals_octal_supported_by_Number.js: Added.
(test):
* tests/es6/own_property_order_JSON.parse.js: Added.
(test):
* tests/es6/own_property_order_JSON.stringify.js: Added.
(test):
* tests/es6/own_property_order_Object.assign.js: Added.
* tests/es6/own_property_order_Object.getOwnPropertyNames.js: Added.
(test):
* tests/es6/own_property_order_Object.keys.js: Added.
(test):
* tests/es6/own_property_order_Reflect.ownKeys_string_key_order.js: Added.
(test):
* tests/es6/own_property_order_Reflect.ownKeys_symbol_key_order.js: Added.
(test):
* tests/es6/own_property_order_for..in.js: Added.
(test):
* tests/es6/proper_tail_calls_tail_call_optimisation_direct_recursion.js: Added.
(test):
* tests/es6/proper_tail_calls_tail_call_optimisation_mutual_recursion.js: Added.
(test.f):
(test.g):
(test):
* tests/es6/prototype_of_bound_functions_arrow_functions.js: Added.
(test.correctProtoBound):
(test):
* tests/es6/prototype_of_bound_functions_basic_functions.js: Added.
(test.correctProtoBound.f):
(test.correctProtoBound):
(test):
* tests/es6/prototype_of_bound_functions_classes.js: Added.
(test.correctProtoBound.C):
(test.correctProtoBound):
(test):
* tests/es6/prototype_of_bound_functions_generator_functions.js: Added.
(test.correctProtoBound.f):
(test.correctProtoBound):
(test):
* tests/es6/prototype_of_bound_functions_subclasses.js: Added.
(test.correctProtoBound.C):
(test.correctProtoBound):
(test):
* tests/es6/rest_parameters_arguments_object_interaction.js: Added.
(test):
* tests/es6/rest_parameters_basic_functionality.js: Added.
(test):
* tests/es6/rest_parameters_cant_be_used_in_setters.js: Added.
(test):
* tests/es6/rest_parameters_function_length_property.js: Added.
(test):
* tests/es6/rest_parameters_new_Function_support.js: Added.
(test):
* tests/es6/spread_..._operator_spreading_non-iterables_is_a_runtime_error.js: Added.
(test):
* tests/es6/spread_..._operator_with_arrays_in_array_literals.js: Added.
(test):
* tests/es6/spread_..._operator_with_arrays_in_function_calls.js: Added.
(test):
* tests/es6/spread_..._operator_with_astral_plane_strings_in_array_literals.js: Added.
(test):
* tests/es6/spread_..._operator_with_astral_plane_strings_in_function_calls.js: Added.
(test):
* tests/es6/spread_..._operator_with_generator_instances_in_arrays.js: Added.
(test.iterable):
(test):
* tests/es6/spread_..._operator_with_generator_instances_in_calls.js: Added.
(test.iterable):
(test):
* tests/es6/spread_..._operator_with_generic_iterables_in_arrays.js: Added.
(test):
* tests/es6/spread_..._operator_with_generic_iterables_in_calls.js: Added.
(test):
* tests/es6/spread_..._operator_with_instances_of_iterables_in_arrays.js: Added.
(test):
* tests/es6/spread_..._operator_with_instances_of_iterables_in_calls.js: Added.
(test):
* tests/es6/spread_..._operator_with_sparse_arrays_in_array_literals.js: Added.
(test):
* tests/es6/spread_..._operator_with_sparse_arrays_in_function_calls.js: Added.
(test):
* tests/es6/spread_..._operator_with_strings_in_array_literals.js: Added.
(test):
* tests/es6/spread_..._operator_with_strings_in_function_calls.js: Added.
(test):
* tests/es6/super_constructor_calls_use_correct_new.target_binding.js: Added.
(test.B):
(test):
* tests/es6/super_expression_in_constructors.js: Added.
(test.B):
(test.C):
(test):
* tests/es6/super_in_methods_method_calls.js: Added.
(test.B.prototype.qux):
(test.B):
(test.C.prototype.qux):
(test.C):
(test):
* tests/es6/super_in_methods_property_access.js: Added.
(test.B):
(test.C.prototype.quux):
(test.C):
(test):
* tests/es6/super_is_statically_bound.js: Added.
(test.B.prototype.qux):
(test.B):
(test.C.prototype.qux):
(test.C):
(test):
* tests/es6/super_method_calls_use_correct_this_binding.js: Added.
(test.B.prototype.qux):
(test.B):
(test.C.prototype.qux):
(test.C):
(test):
* tests/es6/super_statement_in_constructors.js: Added.
(test.B):
(test):
* tests/es6/template_strings_basic_functionality.js: Added.
(test):
* tests/es6/template_strings_line_break_normalisation.js: Added.
(test):
* tests/es6/template_strings_passed_array_is_frozen.js: Added.
(test):
* tests/es6/template_strings_tagged_template_strings.js: Added.
(test.fn):
(test):
* tests/es6/template_strings_toString_conversion.js: Added.
(test.a.toString):
(test.a.valueOf):
(test):
* tests/es6/typed_arrays_%TypedArray%.from.js: Added.
(test):
* tests/es6/typed_arrays_%TypedArray%.of.js: Added.
(test):
* tests/es6/typed_arrays_%TypedArray%.prototype.copyWithin.js: Added.
(test):
* tests/es6/typed_arrays_%TypedArray%.prototype.entries.js: Added.
(test):
* tests/es6/typed_arrays_%TypedArray%.prototype.every.js: Added.
(test):
* tests/es6/typed_arrays_%TypedArray%.prototype.fill.js: Added.
(test):
* tests/es6/typed_arrays_%TypedArray%.prototype.filter.js: Added.
(test):
* tests/es6/typed_arrays_%TypedArray%.prototype.find.js: Added.
(test):
* tests/es6/typed_arrays_%TypedArray%.prototype.findIndex.js: Added.
(test):
* tests/es6/typed_arrays_%TypedArray%.prototype.forEach.js: Added.
(test):
* tests/es6/typed_arrays_%TypedArray%.prototype.indexOf.js: Added.
(test):
* tests/es6/typed_arrays_%TypedArray%.prototype.join.js: Added.
(test):
* tests/es6/typed_arrays_%TypedArray%.prototype.keys.js: Added.
(test):
* tests/es6/typed_arrays_%TypedArray%.prototype.lastIndexOf.js: Added.
(test):
* tests/es6/typed_arrays_%TypedArray%.prototype.map.js: Added.
(test):
* tests/es6/typed_arrays_%TypedArray%.prototype.reduce.js: Added.
(test):
* tests/es6/typed_arrays_%TypedArray%.prototype.reduceRight.js: Added.
(test):
* tests/es6/typed_arrays_%TypedArray%.prototype.reverse.js: Added.
(test):
* tests/es6/typed_arrays_%TypedArray%.prototype.slice.js: Added.
(test):
* tests/es6/typed_arrays_%TypedArray%.prototype.some.js: Added.
(test):
* tests/es6/typed_arrays_%TypedArray%.prototype.sort.js: Added.
(test):
* tests/es6/typed_arrays_%TypedArray%.prototype.subarray.js: Added.
(test):
* tests/es6/typed_arrays_%TypedArray%.prototype.values.js: Added.
(test):
* tests/es6/typed_arrays_%TypedArray%.prototype[Symbol.iterator].js: Added.
(test):
* tests/es6/typed_arrays_%TypedArray%[Symbol.species].js: Added.
(test):
* tests/es6/typed_arrays_ArrayBuffer[Symbol.species].js: Added.
(test):
* tests/es6/typed_arrays_DataView_Float32.js: Added.
(test):
* tests/es6/typed_arrays_DataView_Float64.js: Added.
(test):
* tests/es6/typed_arrays_DataView_Int16.js: Added.
(test):
* tests/es6/typed_arrays_DataView_Int32.js: Added.
(test):
* tests/es6/typed_arrays_DataView_Int8.js: Added.
(test):
* tests/es6/typed_arrays_DataView_Uint16.js: Added.
(test):
* tests/es6/typed_arrays_DataView_Uint32.js: Added.
(test):
* tests/es6/typed_arrays_DataView_Uint8.js: Added.
(test):
* tests/es6/typed_arrays_Float32Array.js: Added.
(test):
* tests/es6/typed_arrays_Float64Array.js: Added.
(test):
* tests/es6/typed_arrays_Int16Array.js: Added.
(test):
* tests/es6/typed_arrays_Int32Array.js: Added.
(test):
* tests/es6/typed_arrays_Int8Array.js: Added.
(test):
* tests/es6/typed_arrays_Uint16Array.js: Added.
(test):
* tests/es6/typed_arrays_Uint32Array.js: Added.
(test):
* tests/es6/typed_arrays_Uint8Array.js: Added.
(test):
* tests/es6/typed_arrays_Uint8ClampedArray.js: Added.
(test):
* tests/es6/typed_arrays_constructors_require_new.js: Added.
(test):
* tests/es6/typed_arrays_correct_prototype_chains.js: Added.
(test):
* tests/es6/well-known_symbols_Symbol.hasInstance.js: Added.
(test.C):
(test.):
(test):
* tests/es6/well-known_symbols_Symbol.isConcatSpreadable.js: Added.
(test):
* tests/es6/well-known_symbols_Symbol.iterator_arguments_object.js: Added.
(test):
* tests/es6/well-known_symbols_Symbol.iterator_existence.js: Added.
(test):
* tests/es6/well-known_symbols_Symbol.match.js: Added.
(test.O.Symbol.match):
(test):
* tests/es6/well-known_symbols_Symbol.replace.js: Added.
(test.O.Symbol.replace):
(test):
* tests/es6/well-known_symbols_Symbol.search.js: Added.
(test.O.Symbol.search):
(test):
* tests/es6/well-known_symbols_Symbol.species_Array.prototype.concat.js: Added.
(test.obj.Symbol.species):
(test):
* tests/es6/well-known_symbols_Symbol.species_Array.prototype.filter.js: Added.
(test.obj.Symbol.species):
(test):
* tests/es6/well-known_symbols_Symbol.species_Array.prototype.map.js: Added.
(test.obj.Symbol.species):
(test):
* tests/es6/well-known_symbols_Symbol.species_Array.prototype.slice.js: Added.
(test.obj.Symbol.species):
(test):
* tests/es6/well-known_symbols_Symbol.species_Array.prototype.splice.js: Added.
(test.obj.Symbol.species):
(test):
* tests/es6/well-known_symbols_Symbol.species_RegExp.prototype[Symbol.split].js: Added.
(test.obj.Symbol.species):
(test):
* tests/es6/well-known_symbols_Symbol.species_existence.js: Added.
(test):
* tests/es6/well-known_symbols_Symbol.split.js: Added.
(test.O.Symbol.split):
(test):
* tests/es6/well-known_symbols_Symbol.toPrimitive.js: Added.
(test.a.Symbol.toPrimitive):
(test.b.Symbol.toPrimitive):
(test.c.Symbol.toPrimitive):
(test):
* tests/es6/well-known_symbols_Symbol.toStringTag.js: Added.
(test):
* tests/es6/well-known_symbols_Symbol.toStringTag_misc._built-ins.js: Added.
(test):
* tests/es6/well-known_symbols_Symbol.unscopables.js: Added.
(test):
2015-09-03 Filip Pizlo <fpizlo@apple.com>
WatchpointsOnStructureStubInfo doesn't need to be reference counted
https://bugs.webkit.org/show_bug.cgi?id=148766
Reviewed by Saam Barati.
It doesn't need to be reference counted because the only RefPtr to it is in
StructureStubInfo. Therefore, it can be a unique_ptr.
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::WatchpointsOnStructureStubInfo::addWatchpoint):
(JSC::WatchpointsOnStructureStubInfo::ensureReferenceAndAddWatchpoint):
* bytecode/StructureStubClearingWatchpoint.h:
(JSC::WatchpointsOnStructureStubInfo::WatchpointsOnStructureStubInfo):
(JSC::WatchpointsOnStructureStubInfo::codeBlock):
* bytecode/StructureStubInfo.h:
(JSC::getStructureStubInfoCodeOrigin):
2015-09-03 Basile Clement <basile_clement@apple.com>
JavaScript functions should restore the stack pointer after a call
https://bugs.webkit.org/show_bug.cgi?id=148659
Reviewed by Michael Saboff.
This patch makes it so that the various places where we are making a
JS-to-JS call restore the stack pointer afterwards. This allows us to
no longer rely on the stack pointer still being valid after a call, and
is a prerequisite for getting rid of the arity fixup return thunk.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLInlineCacheSize.cpp:
(JSC::FTL::sizeOfCall):
* ftl/FTLJSCall.cpp:
(JSC::FTL::JSCall::emit):
* ftl/FTLJSCall.h:
* ftl/FTLStackMaps.h:
(JSC::FTL::StackMaps::stackSizeForLocals):
* jit/Repatch.cpp:
(JSC::generateByIdStub):
* tests/stress/tail-call-in-inline-cache.js: Added.
(tail):
(obj.get x):
2015-09-03 Filip Pizlo <fpizlo@apple.com>
StructureStubInfo should be able to reset itself without going through CodeBlock
https://bugs.webkit.org/show_bug.cgi?id=148743
Reviewed by Geoffrey Garen.
We had some resetStub...() methods in CodeBlock that didn't really do anything that
StructureStubInfo couldn't do by itself. It makes sense for the functionality to reset a
stub to be in the stub class, not in CodeBlock.
It's still true that:
- In order to mess with a StructureStubInfo, you either have to be in GC or you have to
be holding the owning CodeBlock's lock.
- StructureStubInfo doesn't remember which CodeBlock owns it (to save space), and all
of the callers of StructureStubInfo methods know which CodeBlock own it. So, many stub
methods take CodeBlock* as an argument.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finalizeUnconditionally):
(JSC::CodeBlock::addCallLinkInfo):
(JSC::CodeBlock::getCallLinkInfoForBytecodeIndex):
(JSC::CodeBlock::resetStub): Deleted.
(JSC::CodeBlock::resetStubInternal): Deleted.
(JSC::CodeBlock::resetStubDuringGCInternal): Deleted.
* bytecode/CodeBlock.h:
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::fireInternal):
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::deref):
(JSC::StructureStubInfo::reset):
(JSC::StructureStubInfo::visitWeakReferences):
* bytecode/StructureStubInfo.h:
(JSC::StructureStubInfo::initInList):
(JSC::StructureStubInfo::seenOnce):
(JSC::StructureStubInfo::reset): Deleted.
2015-09-03 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement some arithmetic instructions in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=148737
Reviewed by Geoffrey Garen.
This patch implements the addition and subtraction instructions in
WebAssembly using a stack-based approach: each instruction reads its
operands from the top of the 'temporary' stack, pops them, and
optionally pushes a return value to the stack. Since operands are passed
on the stack, we don't use the arguments that are passed to the methods
of WASMFunctionCompiler, and we don't use the return values from these
methods. (We will use them when we implement LLVM IR generation for
WebAssembly, where each expression is an LLVMValueRef.)
* tests/stress/wasm-arithmetic.js: Added.
* tests/stress/wasm-arithmetic.wasm: Added.
* wasm/WASMFunctionCompiler.h:
(JSC::WASMFunctionCompiler::endFunction):
(JSC::WASMFunctionCompiler::buildReturn):
(JSC::WASMFunctionCompiler::buildImmediateI32):
(JSC::WASMFunctionCompiler::buildBinaryI32):
(JSC::WASMFunctionCompiler::temporaryAddress):
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseReturnStatement):
(JSC::WASMFunctionParser::parseExpressionI32):
(JSC::WASMFunctionParser::parseImmediateExpressionI32):
(JSC::WASMFunctionParser::parseBinaryExpressionI32):
* wasm/WASMFunctionParser.h:
* wasm/WASMFunctionSyntaxChecker.h:
(JSC::WASMFunctionSyntaxChecker::startFunction):
(JSC::WASMFunctionSyntaxChecker::endFunction):
(JSC::WASMFunctionSyntaxChecker::buildReturn):
(JSC::WASMFunctionSyntaxChecker::buildImmediateI32):
(JSC::WASMFunctionSyntaxChecker::buildBinaryI32):
(JSC::WASMFunctionSyntaxChecker::stackHeight):
(JSC::WASMFunctionSyntaxChecker::updateTempStackHeight):
2015-09-03 Brian Burg <bburg@apple.com>
Web Inspector: should crash on purpose if InjectedScriptSource.js is unparseable
https://bugs.webkit.org/show_bug.cgi?id=148750
Reviewed by Timothy Hatcher.
If an injected script cannot be parsed or executed without exception, we should abort as
soon as possible. This patch adds a release assertion after creating the injected
script and dumps the bad injected script's source as it was embedded into the binary.
* inspector/InjectedScriptManager.cpp:
(Inspector::InjectedScriptManager::injectedScriptFor):
2015-09-03 Basile Clement <basile_clement@apple.com> and Michael Saboff <msaboff@apple.com>
Clean up register naming
https://bugs.webkit.org/show_bug.cgi?id=148658
Reviewed by Geoffrey Garen.
This changes register naming conventions in the llint and baseline JIT
in order to use as few (native) callee-save registers as possible on
64-bits platforms. It also introduces significant changes in the way
registers names are defined in the LLint and baseline JIT in order to
enable a simpler convention about which registers can be aliased. That
convention is valid across all architecture, and described in
llint/LowLevelInterpreter.asm.
Callee save registers are now called out regCS<n> (in the JIT) or
csr<n> (in the LLInt) with a common numbering across all tiers. Some
registers are unused in some tiers.
As a part of this change, rdi was removed from the list of temporary
registers for X86-64 Windows as it is a callee saves register. This
reduced the number of temporary registers for X86-64 Windows.
This is in preparation for properly handling callee save register
preservation and restoration.
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compileFunction):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* jit/FPRInfo.h:
(JSC::FPRInfo::toRegister):
(JSC::FPRInfo::toIndex):
* jit/GPRInfo.h:
(JSC::GPRInfo::toIndex):
(JSC::GPRInfo::toRegister):
(JSC::GPRInfo::debugName): Deleted.
* jit/JIT.cpp:
(JSC::JIT::privateCompile):
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_mod):
* jit/JITOpcodes.cpp:
(JSC::JIT::emitSlow_op_loop_hint):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_end):
(JSC::JIT::emit_op_new_object):
* jit/RegisterPreservationWrapperGenerator.cpp:
(JSC::generateRegisterPreservationWrapper):
(JSC::generateRegisterRestoration):
* jit/ThunkGenerators.cpp:
(JSC::arityFixupGenerator):
(JSC::nativeForGenerator): Deleted.
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* offlineasm/arm.rb:
* offlineasm/arm64.rb:
* offlineasm/cloop.rb:
* offlineasm/mips.rb:
* offlineasm/registers.rb:
* offlineasm/sh4.rb:
* offlineasm/x86.rb:
2015-09-03 Filip Pizlo <fpizlo@apple.com>
Get rid of RepatchBuffer and replace it with static functions
https://bugs.webkit.org/show_bug.cgi?id=148742
Reviewed by Geoffrey Garen and Mark Lam.
RepatchBuffer is an object that doesn't have any state. All of its instance methods are
just wrappers for methods on MacroAssembler. So, we should make those MacroAssembler
methods public and call them directly.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::linkJump):
(JSC::AbstractMacroAssembler::linkPointer):
(JSC::AbstractMacroAssembler::getLinkerAddress):
(JSC::AbstractMacroAssembler::getLinkerCallReturnOffset):
(JSC::AbstractMacroAssembler::repatchJump):
(JSC::AbstractMacroAssembler::repatchNearCall):
(JSC::AbstractMacroAssembler::repatchCompact):
(JSC::AbstractMacroAssembler::repatchInt32):
(JSC::AbstractMacroAssembler::repatchPointer):
(JSC::AbstractMacroAssembler::readPointer):
(JSC::AbstractMacroAssembler::replaceWithLoad):
(JSC::AbstractMacroAssembler::replaceWithAddressComputation):
(JSC::AbstractMacroAssembler::AbstractMacroAssembler):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::revertJumpReplacementToPatchableBranch32WithPatch):
(JSC::MacroAssemblerARM64::repatchCall):
(JSC::MacroAssemblerARM64::makeBranch):
(JSC::MacroAssemblerARM64::linkCall):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::revertJumpReplacementToPatchableBranch32WithPatch):
(JSC::MacroAssemblerARMv7::repatchCall):
(JSC::MacroAssemblerARMv7::linkCall):
(JSC::MacroAssemblerARMv7::trustedImm32FromPtr):
* assembler/MacroAssemblerX86.h:
(JSC::MacroAssemblerX86::revertJumpReplacementToPatchableBranch32WithPatch):
(JSC::MacroAssemblerX86::repatchCall):
(JSC::MacroAssemblerX86::linkCall):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::revertJumpReplacementToBranchPtrWithPatch):
(JSC::MacroAssemblerX86_64::repatchCall):
(JSC::MacroAssemblerX86_64::linkCall):
* assembler/RepatchBuffer.h: Removed.
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::clearStub):
(JSC::CallLinkInfo::unlink):
(JSC::CallLinkInfo::visitWeak):
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::registerPreservationMode):
(JSC::CallLinkInfo::isLinked):
(JSC::CallLinkInfo::setUpCall):
(JSC::CallLinkInfo::codeOrigin):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finalizeUnconditionally):
(JSC::CodeBlock::resetStub):
(JSC::CodeBlock::resetStubInternal):
(JSC::CodeBlock::resetStubDuringGCInternal):
(JSC::CodeBlock::unlinkIncomingCalls):
* bytecode/CodeBlock.h:
* bytecode/PolymorphicGetByIdList.cpp:
(JSC::GetByIdAccess::fromStructureStubInfo):
(JSC::GetByIdAccess::visitWeak):
(JSC::PolymorphicGetByIdList::didSelfPatching):
(JSC::PolymorphicGetByIdList::visitWeak):
* bytecode/PolymorphicGetByIdList.h:
(JSC::GetByIdAccess::doesCalls):
* bytecode/PolymorphicPutByIdList.cpp:
(JSC::PutByIdAccess::fromStructureStubInfo):
(JSC::PutByIdAccess::visitWeak):
(JSC::PolymorphicPutByIdList::addAccess):
(JSC::PolymorphicPutByIdList::visitWeak):
* bytecode/PolymorphicPutByIdList.h:
(JSC::PutByIdAccess::customSetter):
(JSC::PolymorphicPutByIdList::kind):
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::deref):
(JSC::StructureStubInfo::visitWeakReferences):
* bytecode/StructureStubInfo.h:
(JSC::StructureStubInfo::seenOnce):
* dfg/DFGOSRExitCompiler.cpp:
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileFTLOSRExit):
* jit/AccessorCallJITStubRoutine.cpp:
(JSC::AccessorCallJITStubRoutine::~AccessorCallJITStubRoutine):
(JSC::AccessorCallJITStubRoutine::visitWeak):
* jit/AccessorCallJITStubRoutine.h:
* jit/JIT.cpp:
(JSC::ctiPatchCallByReturnAddress):
(JSC::JIT::JIT):
(JSC::ctiPatchNearCallByReturnAddress): Deleted.
* jit/JIT.h:
* jit/JITCall.cpp:
* jit/JITOpcodes.cpp:
(JSC::JIT::privateCompileHasIndexedProperty):
(JSC::JIT::emit_op_has_indexed_property):
* jit/JITOperations.cpp:
(JSC::getByVal):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::privateCompileGetByVal):
(JSC::JIT::privateCompileGetByValWithCachedId):
(JSC::JIT::privateCompilePutByVal):
(JSC::JIT::privateCompilePutByValWithCachedId):
* jit/JITPropertyAccess32_64.cpp:
* jit/JITStubRoutine.cpp:
(JSC::JITStubRoutine::~JITStubRoutine):
(JSC::JITStubRoutine::visitWeak):
* jit/JITStubRoutine.h:
* jit/PolymorphicCallStubRoutine.cpp:
(JSC::PolymorphicCallNode::~PolymorphicCallNode):
(JSC::PolymorphicCallNode::unlink):
(JSC::PolymorphicCallStubRoutine::clearCallNodesFor):
(JSC::PolymorphicCallStubRoutine::visitWeak):
* jit/PolymorphicCallStubRoutine.h:
(JSC::PolymorphicCallNode::hasCallLinkInfo):
* jit/Repatch.cpp:
(JSC::readCallTarget):
(JSC::repatchCall):
(JSC::repatchByIdSelfAccess):
(JSC::checkObjectPropertyConditions):
(JSC::replaceWithJump):
(JSC::tryCacheGetByID):
(JSC::repatchGetByID):
(JSC::patchJumpToGetByIdStub):
(JSC::tryBuildGetByIDList):
(JSC::tryCachePutByID):
(JSC::tryBuildPutByIdList):
(JSC::tryRepatchIn):
(JSC::repatchIn):
(JSC::linkSlowFor):
(JSC::linkFor):
(JSC::revertCall):
(JSC::unlinkFor):
(JSC::linkVirtualFor):
(JSC::linkPolymorphicCall):
(JSC::resetGetByID):
(JSC::resetPutByID):
(JSC::resetIn):
* jit/Repatch.h:
2015-09-03 Sukolsak Sakshuwong <sukolsak@gmail.com>
Initial implementation of WebAssembly function compiler
https://bugs.webkit.org/show_bug.cgi?id=148734
Reviewed by Filip Pizlo.
This patch introduces WASMFunctionCompiler, a class for generating
baseline JIT code for WebAssembly functions. The source for each
WebAssembly function is parsed in two passes.
- The first pass is done by WASMFunctionSyntaxChecker when the
WebAssembly module is initialized. It validates the syntax,
determines the start and the end offsets in the source, and
calculates the stack height of the function.
- The second pass is done by WASMFunctionCompiler when the function
is about to be executed.
This patch doesn't calculate the correct stack height nor generate
the correct code. That will be done in a subsequent patch.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* wasm/JSWASMModule.h:
(JSC::JSWASMModule::functionStartOffsetsInSource):
(JSC::JSWASMModule::functionStackHeights):
* wasm/WASMFunctionCompiler.h: Added.
(JSC::WASMFunctionCompiler::WASMFunctionCompiler):
(JSC::WASMFunctionCompiler::startFunction):
(JSC::WASMFunctionCompiler::endFunction):
(JSC::WASMFunctionCompiler::throwStackOverflowError):
(JSC::WASMFunctionCompiler::localAddress):
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::checkSyntax):
(JSC::WASMFunctionParser::compile):
(JSC::WASMFunctionParser::parseFunction):
* wasm/WASMFunctionParser.h:
* wasm/WASMFunctionSyntaxChecker.h:
(JSC::WASMFunctionSyntaxChecker::startFunction):
(JSC::WASMFunctionSyntaxChecker::endFunction):
(JSC::WASMFunctionSyntaxChecker::stackHeight):
* wasm/WASMModuleParser.cpp:
(JSC::WASMModuleParser::parseFunctionDeclarationSection):
(JSC::WASMModuleParser::parseFunctionDefinition):
2015-09-03 Saam barati <sbarati@apple.com>
Block scoped variables should be visible across scripts
https://bugs.webkit.org/show_bug.cgi?id=147813
Reviewed by Filip Pizlo.
This patch properly implements the global lexical tier described in
http://www.ecma-international.org/ecma-262/6.0/index.html#sec-globaldeclarationinstantiation.
The sepcification mandates that there is a global lexical environment
that wrtaps all program execution. This global lexical environment
holds let/const/class variables defined at the top-level scope
inside a program. These variables can never shadow other program-level
"var"s, global object properties, or other global lexical environment
declarations. Doing so is a SyntaxError.
This patch adds new ResolveTypes that describe the global lexical environment:
GlobalLexicalVar and GlobalLexiclaVarWithInjectionChecks. Resolving to
these means we're doing a load/store from the JSGlobalLexicalEnvironment.
This patch also addes new ResolveTypes: UnresolvedProperty and
UnresolvedPropertyWithVarInjectionChecks. Before, we used GlobalProperty
to encompass this category because if JSScope::abstractAccess didn't
resolve to anything, we could safely assume that this property is
on the global object. Such an assumption is no longer true in ES6.
When we have a resolve_scope/put_to_scope/get_from_scope with this
ResolveType, we try to transition it to either a GlobalProperty
ResolveType or a GlobalLexicalVar resolve type.
JSGlobalLexicalEnvironment is a subclass of JSSegmentedVariableObject.
This means get_from_scopes are direct pointer reads and
put_to_scopes are direct pointer stores.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::finalizeUnconditionally):
* bytecode/EvalCodeCache.h:
(JSC::EvalCodeCache::clear):
(JSC::EvalCodeCache::isCacheableScope):
(JSC::EvalCodeCache::isCacheable):
* bytecode/SpeculatedType.h:
* bytecode/UnlinkedCodeBlock.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
(JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
(JSC::BytecodeGenerator::emitGetFromScope):
(JSC::BytecodeGenerator::emitPutToScope):
(JSC::BytecodeGenerator::initializeVariable):
(JSC::BytecodeGenerator::emitInstanceOf):
(JSC::BytecodeGenerator::emitPushFunctionNameScope):
(JSC::BytecodeGenerator::pushScopedControlFlowContext):
(JSC::BytecodeGenerator::emitPushCatchScope):
(JSC::BytecodeGenerator::emitPopCatchScope):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::PostfixNode::emitResolve):
(JSC::PrefixNode::emitResolve):
(JSC::ReadModifyResolveNode::emitBytecode):
(JSC::AssignResolveNode::emitBytecode):
(JSC::EmptyLetExpression::emitBytecode):
(JSC::ForInNode::emitLoopHeader):
(JSC::ForOfNode::emitBytecode):
(JSC::BindingNode::bindValue):
* debugger/DebuggerScope.cpp:
(JSC::DebuggerScope::isGlobalScope):
(JSC::DebuggerScope::isGlobalLexicalEnvironment):
(JSC::DebuggerScope::isClosureScope):
(JSC::DebuggerScope::caughtValue):
(JSC::DebuggerScope::isFunctionOrEvalScope): Deleted.
* debugger/DebuggerScope.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/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasRegisterPointer):
(JSC::DFG::Node::variablePointer):
(JSC::DFG::Node::hasHeapPrediction):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStoreBarrierInsertionPhase.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
(JSC::FTL::DFG::LowerDFGToLLVM::compileMultiPutByOffset):
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetGlobalVariable):
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutGlobalVariable):
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetGlobalVar): Deleted.
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutGlobalVar): Deleted.
* inspector/JSJavaScriptCallFrame.cpp:
(Inspector::JSJavaScriptCallFrame::scopeType):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
* jit/JIT.h:
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emitSlow_op_resolve_scope):
(JSC::JIT::emitLoadWithStructureCheck):
(JSC::JIT::emitGetGlobalProperty):
(JSC::JIT::emitGetVarFromPointer):
(JSC::JIT::emitGetClosureVar):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emitSlow_op_get_from_scope):
(JSC::JIT::emitPutGlobalProperty):
(JSC::JIT::emitPutGlobalVariable):
(JSC::JIT::emit_op_put_to_scope):
(JSC::JIT::emitSlow_op_put_to_scope):
(JSC::JIT::emitGetGlobalVar): Deleted.
(JSC::JIT::emitPutGlobalVar): Deleted.
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emitSlow_op_resolve_scope):
(JSC::JIT::emitLoadWithStructureCheck):
(JSC::JIT::emitGetGlobalProperty):
(JSC::JIT::emitGetVarFromPointer):
(JSC::JIT::emitGetClosureVar):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emitSlow_op_get_from_scope):
(JSC::JIT::emitPutGlobalProperty):
(JSC::JIT::emitPutGlobalVariable):
(JSC::JIT::emit_op_put_to_scope):
(JSC::JIT::emitSlow_op_put_to_scope):
(JSC::JIT::emitGetGlobalVar): Deleted.
(JSC::JIT::emitPutGlobalVar): Deleted.
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
(JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
* runtime/Executable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties):
* runtime/GetPutInfo.h: Added.
(JSC::resolveModeName):
(JSC::resolveTypeName):
(JSC::initializationModeName):
(JSC::makeType):
(JSC::needsVarInjectionChecks):
(JSC::ResolveOp::ResolveOp):
(JSC::GetPutInfo::GetPutInfo):
(JSC::GetPutInfo::resolveType):
(JSC::GetPutInfo::initializationMode):
(JSC::GetPutInfo::resolveMode):
(JSC::GetPutInfo::operand):
* runtime/JSGlobalLexicalEnvironment.cpp: Added.
(JSC::JSGlobalLexicalEnvironment::getOwnPropertySlot):
(JSC::JSGlobalLexicalEnvironment::put):
* runtime/JSGlobalLexicalEnvironment.h: Added.
(JSC::JSGlobalLexicalEnvironment::create):
(JSC::JSGlobalLexicalEnvironment::isEmpty):
(JSC::JSGlobalLexicalEnvironment::createStructure):
(JSC::JSGlobalLexicalEnvironment::JSGlobalLexicalEnvironment):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::put):
(JSC::JSGlobalObject::addGlobalVar):
(JSC::JSGlobalObject::visitChildren):
(JSC::JSGlobalObject::addStaticGlobals):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::addVar):
(JSC::JSGlobalObject::globalScope):
(JSC::JSGlobalObject::globalLexicalEnvironment):
(JSC::JSGlobalObject::hasOwnPropertyForWrite):
(JSC::constructEmptyArray):
(JSC::JSGlobalObject::symbolTableHasProperty): Deleted.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncEval):
(JSC::globalFuncParseInt):
* runtime/JSLexicalEnvironment.h:
(JSC::JSLexicalEnvironment::createStructure):
* runtime/JSObject.h:
(JSC::JSObject::isGlobalObject):
(JSC::JSObject::isErrorInstance):
(JSC::JSObject::isVariableObject): Deleted.
(JSC::JSObject::isStaticScopeObject): Deleted.
(JSC::JSObject::isNameScopeObject): Deleted.
(JSC::JSObject::isActivationObject): Deleted.
* runtime/JSScope.cpp:
(JSC::JSScope::visitChildren):
(JSC::abstractAccess):
(JSC::JSScope::resolve):
(JSC::JSScope::abstractResolve):
(JSC::JSScope::collectVariablesUnderTDZ):
(JSC::isScopeType):
(JSC::JSScope::isVarScope):
(JSC::JSScope::isLexicalScope):
(JSC::JSScope::isCatchScope):
(JSC::JSScope::isFunctionNameScopeObject):
(JSC::JSScope::isGlobalLexicalEnvironment):
(JSC::JSScope::constantScopeForCodeBlock):
(JSC::resolveModeName): Deleted.
(JSC::resolveTypeName): Deleted.
* runtime/JSScope.h:
(JSC::makeType): Deleted.
(JSC::needsVarInjectionChecks): Deleted.
(JSC::ResolveOp::ResolveOp): Deleted.
(JSC::ResolveModeAndType::ResolveModeAndType): Deleted.
(JSC::ResolveModeAndType::mode): Deleted.
(JSC::ResolveModeAndType::type): Deleted.
(JSC::ResolveModeAndType::operand): Deleted.
* runtime/JSSegmentedVariableObject.cpp:
(JSC::JSSegmentedVariableObject::findVariableIndex):
(JSC::JSSegmentedVariableObject::addVariables):
* runtime/JSSegmentedVariableObject.h:
* runtime/JSSymbolTableObject.h:
(JSC::symbolTablePut):
* runtime/JSType.h:
* runtime/PutPropertySlot.h:
(JSC::PutPropertySlot::PutPropertySlot):
(JSC::PutPropertySlot::isCacheablePut):
(JSC::PutPropertySlot::isCacheableSetter):
(JSC::PutPropertySlot::isCacheableCustom):
(JSC::PutPropertySlot::isInitialization):
(JSC::PutPropertySlot::cachedOffset):
* runtime/SymbolTable.h:
* tests/stress/global-lexical-let-no-rhs.js: Added.
(assert):
(foo):
* tests/stress/global-lexical-redeclare-variable.js: Added.
(globalFunction):
(globalClass):
(assert):
(assertExpectations):
(assertProperError):
* tests/stress/global-lexical-redefine-const.js: Added.
* tests/stress/global-lexical-var-injection.js: Added.
(assert):
(baz):
* tests/stress/global-lexical-variable-tdz.js: Added.
* tests/stress/global-lexical-variable-unresolved-property.js: Added.
* tests/stress/global-lexical-variable-with-statement.js: Added.
(assert):
(shouldThrowInvalidConstAssignment):
(makeObj):
* tests/stress/multiple-files-tests: Added.
* tests/stress/multiple-files-tests/global-lexical-redeclare-variable: Added.
* tests/stress/multiple-files-tests/global-lexical-redeclare-variable/fifth.js: Added.
* tests/stress/multiple-files-tests/global-lexical-redeclare-variable/first.js: Added.
* tests/stress/multiple-files-tests/global-lexical-redeclare-variable/fourth.js: Added.
* tests/stress/multiple-files-tests/global-lexical-redeclare-variable/second.js: Added.
* tests/stress/multiple-files-tests/global-lexical-redeclare-variable/sixth.js: Added.
* tests/stress/multiple-files-tests/global-lexical-redeclare-variable/third.js: Added.
* tests/stress/multiple-files-tests/global-lexical-redefine-const: Added.
* tests/stress/multiple-files-tests/global-lexical-redefine-const/first.js: Added.
(assert):
(shouldThrowInvalidConstAssignment):
* tests/stress/multiple-files-tests/global-lexical-redefine-const/second.js: Added.
(foo):
(bar):
(baz):
* tests/stress/multiple-files-tests/global-lexical-variable-tdz: Added.
* tests/stress/multiple-files-tests/global-lexical-variable-tdz/first.js: Added.
(assert):
(shouldThrowTDZ):
(foo):
(bar):
* tests/stress/multiple-files-tests/global-lexical-variable-tdz/second.js: Added.
* tests/stress/multiple-files-tests/global-lexical-variable-unresolved-property: Added.
* tests/stress/multiple-files-tests/global-lexical-variable-unresolved-property/first.js: Added.
(assert):
(shouldThrowTDZ):
(foo):
* tests/stress/multiple-files-tests/global-lexical-variable-unresolved-property/second.js: Added.
2015-09-03 Filip Pizlo <fpizlo@apple.com>
RepatchBuffer should be stateless
https://bugs.webkit.org/show_bug.cgi?id=148741
Reviewed by Geoffrey Garen.
This removes our reliance on RepatchBuffer having a pointer to CodeBlock. This is in
preparation for removing RepatchBuffer entirely (see
https://bugs.webkit.org/show_bug.cgi?id=148742). In the longer term, this is necessary
for making inline cache code, particularly in StructureStubInfo, more self-contained.
Currently StructureStubInfo relies on very pointless-looking methods in CodeBlock to
clear itself, and the only thing that those methods do is create a RepatchBuffer. It's
quite silly.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::allocate):
(JSC::LinkBuffer::performFinalization):
* assembler/RepatchBuffer.h:
(JSC::RepatchBuffer::RepatchBuffer):
(JSC::RepatchBuffer::~RepatchBuffer):
(JSC::RepatchBuffer::relink):
(JSC::RepatchBuffer::revertJumpReplacementToPatchableBranch32WithPatch):
(JSC::RepatchBuffer::codeBlock): Deleted.
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::clearStub):
(JSC::CallLinkInfo::unlink):
(JSC::CallLinkInfo::visitWeak):
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::registerPreservationMode):
(JSC::CallLinkInfo::isLinked):
(JSC::CallLinkInfo::setUpCall):
(JSC::CallLinkInfo::codeOrigin):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finalizeUnconditionally):
(JSC::CodeBlock::resetStubInternal):
(JSC::CodeBlock::unlinkIncomingCalls):
* bytecode/PolymorphicGetByIdList.cpp:
(JSC::GetByIdAccess::fromStructureStubInfo):
(JSC::GetByIdAccess::visitWeak):
(JSC::PolymorphicGetByIdList::didSelfPatching):
(JSC::PolymorphicGetByIdList::visitWeak):
* bytecode/PolymorphicGetByIdList.h:
(JSC::GetByIdAccess::doesCalls):
* bytecode/PolymorphicPutByIdList.cpp:
(JSC::PutByIdAccess::fromStructureStubInfo):
(JSC::PutByIdAccess::visitWeak):
(JSC::PolymorphicPutByIdList::addAccess):
(JSC::PolymorphicPutByIdList::visitWeak):
* bytecode/PolymorphicPutByIdList.h:
(JSC::PutByIdAccess::customSetter):
(JSC::PolymorphicPutByIdList::kind):
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::deref):
(JSC::StructureStubInfo::visitWeakReferences):
* bytecode/StructureStubInfo.h:
(JSC::StructureStubInfo::seenOnce):
* jit/AccessorCallJITStubRoutine.cpp:
(JSC::AccessorCallJITStubRoutine::~AccessorCallJITStubRoutine):
(JSC::AccessorCallJITStubRoutine::visitWeak):
* jit/AccessorCallJITStubRoutine.h:
* jit/ExecutableAllocator.h:
(JSC::ExecutableAllocator::makeWritable): Deleted.
(JSC::ExecutableAllocator::makeExecutable): Deleted.
(JSC::ExecutableAllocator::allocator): Deleted.
* jit/JITStubRoutine.cpp:
(JSC::JITStubRoutine::~JITStubRoutine):
(JSC::JITStubRoutine::visitWeak):
* jit/JITStubRoutine.h:
* jit/PolymorphicCallStubRoutine.cpp:
(JSC::PolymorphicCallNode::~PolymorphicCallNode):
(JSC::PolymorphicCallNode::unlink):
(JSC::PolymorphicCallStubRoutine::clearCallNodesFor):
(JSC::PolymorphicCallStubRoutine::visitWeak):
* jit/PolymorphicCallStubRoutine.h:
(JSC::PolymorphicCallNode::hasCallLinkInfo):
* jit/Repatch.cpp:
(JSC::readCallTarget):
(JSC::repatchCall):
(JSC::repatchByIdSelfAccess):
(JSC::tryCacheGetByID):
(JSC::tryCachePutByID):
(JSC::tryBuildPutByIdList):
(JSC::revertCall):
(JSC::unlinkFor):
(JSC::linkVirtualFor):
(JSC::linkPolymorphicCall):
(JSC::resetGetByID):
(JSC::resetPutByID):
(JSC::resetIn):
* jit/Repatch.h:
2015-09-02 Filip Pizlo <fpizlo@apple.com>
Replace all the various forms of branchStructure() with a single method in AssemblyHelpers
https://bugs.webkit.org/show_bug.cgi?id=148725
Reviewed by Saam Barati.
Previously there were the following branchStructure() implementations:
JSC::JIT::branchStructure()
JSC::branchStructure()
JSC::DFG::JITCompiler::branchStructurePtr()
They all did the same thing. Now there is only one, AssemblyHelpers::branchStructure().
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::branchWeakStructure):
(JSC::DFG::JITCompiler::jitCode):
(JSC::DFG::JITCompiler::branchStructurePtr): Deleted.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
(JSC::DFG::SpeculativeJIT::speculateStringOrStringObject):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::branchIfEmpty):
(JSC::AssemblyHelpers::branchStructure):
(JSC::AssemblyHelpers::addressForByteOffset):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::branchStructure): Deleted.
(JSC::branchStructure): Deleted.
* jit/JITPropertyAccess.cpp:
(JSC::JIT::stringGetByValStubGenerator):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::stringGetByValStubGenerator):
* jit/Repatch.cpp:
(JSC::checkObjectPropertyCondition):
(JSC::checkObjectPropertyConditions):
(JSC::generateByIdStub):
(JSC::emitPutReplaceStub):
(JSC::emitPutTransitionStub):
(JSC::tryRepatchIn):
* jit/SpecializedThunkJIT.h:
(JSC::SpecializedThunkJIT::loadJSStringArgument):
2015-09-02 Filip Pizlo <fpizlo@apple.com>
Remove some unused methods from GetByIdAccess.
Rubber stamped by Michael Saboff.
* bytecode/PolymorphicGetByIdList.h:
(JSC::GetByIdAccess::stubRoutine):
(JSC::GetByIdAccess::doesCalls):
(JSC::GetByIdAccess::isWatched): Deleted.
(JSC::GetByIdAccess::isSimple): Deleted.
2015-09-02 Geoffrey Garen <ggaren@apple.com>
Fix the no JIT build.
Unreviewed.
* heap/Heap.cpp:
(JSC::Heap::markRoots):
2015-09-02 Geoffrey Garen <ggaren@apple.com>
CodeBlock should have a more explicit "strongly referenced" state
https://bugs.webkit.org/show_bug.cgi?id=148714
Reviewed by Filip Pizlo.
Previously, CodeBlock had a "may be executing" bit, which was used by
both the stack visitor and the compiler to indicate "this CodeBlock must
not jettison itself".
Now, CodeBlock has an explicit "is strongly referenced" bit to do the
same.
For now, there is no behavior change. In future, I will use the "is
strongly referenced" bit to indicate the set of all references that
cause a CodeBlock not to jettison itself. Strong references and stack
references will be different because:
(1) A stack reference requires a write barrier at the end of GC
(since CodeBlocks only barrier themselves on function entry,
and GC will clear that barrier); but a strong reference does not
need or want a write barrier at the end of GC.
(2) Visiting more heap objects might reveal more strong references
but, by definition, it cannot reveal more stack references.
Also, this patch adds an explicit mark clearing phase for compiler
CodeBlocks, which does the work that would normally be done by a write
barrier. A compiler CodeBlock can't rely on a normal write barrier
because the compiler writes to CodeBlocks without invoking a write
barrier, and because the CodeBlock write barrier operates on an
executable, but an in-flight compilation is not pointed to by any
executable. This bug does not appear to be noticeable in the current
system, but I will probably make it noticeable.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::shouldImmediatelyAssumeLivenessDuringScan):
(JSC::CodeBlock::isKnownToBeLiveDuringGC):
* bytecode/CodeBlock.h:
(JSC::ExecState::uncheckedR):
(JSC::CodeBlockSet::clearMarks):
(JSC::CodeBlockSet::mark):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::key):
(JSC::DFG::Plan::clearCodeBlockMarks):
(JSC::DFG::Plan::checkLivenessAndVisitChildren):
* dfg/DFGPlan.h:
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::completeAllPlansForVM):
(JSC::DFG::Worklist::clearCodeBlockMarks):
(JSC::DFG::Worklist::suspendAllThreads):
(JSC::DFG::Worklist::visitWeakReferences):
(JSC::DFG::completeAllPlansForVM):
(JSC::DFG::clearCodeBlockMarks):
* dfg/DFGWorklist.h:
(JSC::DFG::worklistForIndexOrNull):
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::clearMarksForFullCollection):
(JSC::CodeBlockSet::clearMarksForEdenCollection):
(JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
(JSC::CodeBlockSet::traceMarked):
(JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
* heap/CodeBlockSet.h:
* heap/Heap.cpp:
(JSC::Heap::markRoots):
2015-09-01 Brian Burg <bburg@apple.com>
Web Inspector: protocol generator should not allow non-boolean values for "optional" key
https://bugs.webkit.org/show_bug.cgi?id=148679
Reviewed by Joseph Pecoraro.
In Python, the 'bool' type inherits from 'int'. In the runtime, True and False are
just numbers to Python. So, the existing check for boolean literals was not quite right.
* inspector/scripts/codegen/models.py: Use isinstance instead.
(TypeMember.__init__):
(Parameter.__init__):
* inspector/scripts/tests/expected/fail-on-number-typed-optional-parameter-flag.json-error: Added.
* inspector/scripts/tests/expected/fail-on-number-typed-optional-type-member.json-error: Added.
* inspector/scripts/tests/fail-on-number-typed-optional-parameter-flag.json: Added.
* inspector/scripts/tests/fail-on-number-typed-optional-type-member.json: Added.
2015-09-01 Filip Pizlo <fpizlo@apple.com>
DFG AI assertions about not having to do type checks at the point of a Known use kind are unsound
https://bugs.webkit.org/show_bug.cgi?id=148649
Reviewed by Saam Barati.
We often generate IR like:
Check(Int32:@x)
...
Foo(KnownInt32:@x)
It would be valid for any optimization that somehow proves the type of @x to remove the
Check node entirely. But then, AI might fail on an assertion at Foo() because of the
KnownInt32 use kind, if AI isn't smart enough to construct the same proof that the former
optimization used for removing the Check.
The correct solution is to remove the compile-time assertions about Known use kinds
having already been checked.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::verifyEdge):
2015-09-01 Brian Burg <bburg@apple.com>
Web Inspector: tighten up lifetimes for InspectorController-owned objects; add brace initializers to agents
https://bugs.webkit.org/show_bug.cgi?id=148612
Reviewed by Joseph Pecoraro.
Both InjectedScriptManager and AgentRegistry (thus all agents) are
owned by JSGlobalObjectInspectorController. So, use references.
Add brace initalizers for scalar and pointer members in agent classes.
* inspector/ConsoleMessage.cpp:
(Inspector::ConsoleMessage::addToFrontend):
(Inspector::ConsoleMessage::updateRepeatCountInConsole):
(Inspector::ConsoleMessage::ConsoleMessage):
* inspector/ConsoleMessage.h:
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
* inspector/agents/InspectorAgent.cpp:
(Inspector::InspectorAgent::InspectorAgent):
* inspector/agents/InspectorAgent.h:
* inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::InspectorConsoleAgent):
(Inspector::InspectorConsoleAgent::enable):
(Inspector::InspectorConsoleAgent::clearMessages):
(Inspector::InspectorConsoleAgent::addMessageToConsole):
(Inspector::InspectorConsoleAgent::addConsoleMessage):
* inspector/agents/InspectorConsoleAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::InspectorDebuggerAgent):
(Inspector::InspectorDebuggerAgent::removeBreakpoint):
(Inspector::InspectorDebuggerAgent::getFunctionDetails):
(Inspector::InspectorDebuggerAgent::evaluateOnCallFrame):
(Inspector::InspectorDebuggerAgent::didPause):
(Inspector::InspectorDebuggerAgent::breakpointActionProbe):
(Inspector::InspectorDebuggerAgent::didContinue):
(Inspector::InspectorDebuggerAgent::clearExceptionValue):
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::InspectorRuntimeAgent):
(Inspector::InspectorRuntimeAgent::callFunctionOn):
(Inspector::InspectorRuntimeAgent::getProperties):
(Inspector::InspectorRuntimeAgent::getDisplayableProperties):
(Inspector::InspectorRuntimeAgent::getCollectionEntries):
(Inspector::InspectorRuntimeAgent::saveResult):
(Inspector::InspectorRuntimeAgent::releaseObject):
(Inspector::InspectorRuntimeAgent::releaseObjectGroup):
* inspector/agents/InspectorRuntimeAgent.h:
* inspector/agents/JSGlobalObjectConsoleAgent.cpp:
(Inspector::JSGlobalObjectConsoleAgent::JSGlobalObjectConsoleAgent):
* inspector/agents/JSGlobalObjectConsoleAgent.h:
* inspector/agents/JSGlobalObjectDebuggerAgent.cpp:
(Inspector::JSGlobalObjectDebuggerAgent::JSGlobalObjectDebuggerAgent):
(Inspector::JSGlobalObjectDebuggerAgent::injectedScriptForEval):
* inspector/agents/JSGlobalObjectDebuggerAgent.h:
* inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
(Inspector::JSGlobalObjectRuntimeAgent::JSGlobalObjectRuntimeAgent):
(Inspector::JSGlobalObjectRuntimeAgent::injectedScriptForEval):
* inspector/agents/JSGlobalObjectRuntimeAgent.h:
2015-08-31 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Introduce ModuleProgramExecutable families and compile Module code to bytecode
https://bugs.webkit.org/show_bug.cgi?id=148581
Reviewed by Saam Barati.
This patch introduces ModuleProgramExecutable, that is new executable type for the ES6 modules.
And related code block types, UninkedModuleProgramCodeBlock and ModuleProgramCodeBlock are also
introduced. BytecodeGenerator now recognizes these types and emits the bytecode and constructs
the symbol table for the module environment. While this patch introduces the bytecode generation
for the ES6 modules, the module environment instantiation initialization and imported binding
resolution are not included in this patch. They will be implemented in the subsequent patch.
The interesting part is the symbol table construction for the module environment.
Since the module code will be only executed once, the module environment need not to be allocated
and instantiated inside the module code; In the case of the function code, the function code need
to allocate the environment inside the prologue of it because the function code can be executed
more than once and the function environments are different in each time of the executions.
The module environment will be instantiated outside the module code before executing the module code.
This is required because we need to link the module environments to import the bindings before
executing the any module code in the dependency graph. And this is because the function inside the
module may be executed before the module top-level body is executed. (See the code comment for more
detailed situations)
The module environment will hold the top-most heap allocated variables in the module code.
This has the following benefits.
1) This enables JSC to perform the usual LocalClosureVar operations onto it.
2) It also makes the exported lexical variables just the heap allocated lexical variables.
3) Make it possible to initialize the heap allocated function declarations before executing the module
code. It is required under the circular dependency (see the code comment for more details).
To do so, the module environment will be constructed with the symbol table that is generated by the
bytecode generator. And the symbol table is held by the unlinked code block. That means, once the module
environment is instantiated, we cannot clear the unlinked code block before executing the module since
the layout of the instantiated module environment is coupled with the unlinked code block. This is OK
because the module code can be cleared once we executed the module code. If we failed to execute the
module (some errors occur), we can throw away the both, the module environment and the unlinked code block.
The unlinked module program code block holds the symbol table, but it does not hold the module environment.
So the unlinked module program code block can be cached. While unlinked code block can be cached, the linked
code block cannot be cached because it is already linked to the specific set of the module environment to
resolve the imported bindings.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/BytecodeList.json:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::inferredName):
(JSC::ModuleProgramCodeBlock::replacement):
(JSC::ProgramCodeBlock::capabilityLevelInternal):
(JSC::ModuleProgramCodeBlock::capabilityLevelInternal):
* bytecode/CodeBlock.h:
(JSC::ModuleProgramCodeBlock::ModuleProgramCodeBlock):
(JSC::EvalCodeBlock::EvalCodeBlock):
(JSC::FunctionCodeBlock::FunctionCodeBlock):
* bytecode/CodeType.cpp:
(WTF::printInternal):
* bytecode/CodeType.h:
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedModuleProgramCodeBlock::visitChildren):
(JSC::UnlinkedModuleProgramCodeBlock::destroy):
(JSC::UnlinkedCodeBlock::visitChildren): Deleted.
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::finishCreation): Deleted.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::instantiateLexicalVariables):
(JSC::BytecodeGenerator::emitPrefillStackTDZVariables):
(JSC::BytecodeGenerator::pushLexicalScopeInternal):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::emitProgramNodeBytecode):
(JSC::ProgramNode::emitBytecode):
(JSC::ModuleProgramNode::emitBytecode):
(JSC::ImportDeclarationNode::emitBytecode):
(JSC::ExportAllDeclarationNode::emitBytecode):
(JSC::ExportDefaultDeclarationNode::emitBytecode):
(JSC::ExportLocalDeclarationNode::emitBytecode):
(JSC::ExportNamedDeclarationNode::emitBytecode):
* interpreter/Interpreter.cpp:
(JSC::StackFrame::friendlySourceURL):
(JSC::StackFrame::friendlyFunctionName):
(JSC::getStackFrameCodeType):
* interpreter/Interpreter.h:
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::codeType):
(JSC::StackVisitor::Frame::functionName):
(JSC::StackVisitor::Frame::sourceURL):
* interpreter/StackVisitor.h:
* jit/JIT.cpp:
(JSC::JIT::privateCompile):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LLIntEntrypoint.cpp:
(JSC::LLInt::setModuleProgramEntrypoint):
(JSC::LLInt::setEntrypoint):
* llint/LLIntOffsetsExtractor.cpp:
* llint/LLIntThunks.cpp:
(JSC::LLInt::moduleProgramEntryThunkGenerator):
* llint/LLIntThunks.h:
* llint/LowLevelInterpreter.asm:
* parser/ModuleAnalyzer.cpp:
(JSC::ModuleAnalyzer::exportVariable):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseImportClauseItem):
(JSC::Parser<LexerType>::parseExportDeclaration):
* parser/Parser.h:
(JSC::Scope::declareLexicalVariable):
* parser/VariableEnvironment.h:
(JSC::VariableEnvironmentEntry::isImportedNamespace):
(JSC::VariableEnvironmentEntry::setIsImportedNamespace):
(JSC::VariableEnvironment::find):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getModuleProgramCodeBlock):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::installCode):
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::ScriptExecutable::newReplacementCodeBlockFor):
(JSC::ModuleProgramExecutable::ModuleProgramExecutable):
(JSC::ModuleProgramExecutable::create):
(JSC::ModuleProgramExecutable::destroy):
(JSC::ModuleProgramExecutable::visitChildren):
(JSC::ModuleProgramExecutable::clearCode):
(JSC::ExecutableBase::dump):
* runtime/Executable.h:
(JSC::ExecutableBase::isModuleProgramExecutable):
(JSC::ExecutableBase::clearCodeVirtual):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createModuleProgramCodeBlock):
* runtime/JSGlobalObject.h:
* runtime/JSModuleRecord.cpp:
(JSC::JSModuleRecord::visitChildren):
(JSC::JSModuleRecord::link):
* runtime/JSModuleRecord.h:
(JSC::JSModuleRecord::moduleProgramExecutable):
* runtime/JSType.h:
* runtime/ModuleLoaderObject.cpp:
(JSC::moduleLoaderObjectModuleDeclarationInstantiation):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2015-08-31 Basile Clement <basile_clement@apple.com>
Unreviewed, build fix after r189292
* bytecode/ValueRecovery.h:
(JSC::ValueRecovery::jsValueRegs): Deleted.
2015-08-24 Basile Clement <basile_clement@apple.com>
ValueRecovery should distinguish between doubles in an FPR and JSValues in an FPR
https://bugs.webkit.org/show_bug.cgi?id=148336
Reviewed by Michael Saboff.
Currently, ValueRecovery::InFPR means "this is a *double* value in an
FPR". Let's change the semantics to be "this is a *JSValue* in an FPR"
(to match ValueRecovery::InGPR), and introduce
ValueRecovery::UnboxedDoubleInFPR to mean "this is a double value in an
FPR".
* bytecode/ValueRecovery.cpp:
(JSC::ValueRecovery::dumpInContext):
* bytecode/ValueRecovery.h:
(JSC::ValueRecovery::operator bool):
(JSC::ValueRecovery::inFPR):
(JSC::ValueRecovery::isInGPR):
(JSC::ValueRecovery::isInFPR):
(JSC::ValueRecovery::isInRegisters):
(JSC::ValueRecovery::isInJSStack):
(JSC::ValueRecovery::dataFormat):
(JSC::ValueRecovery::gpr):
(JSC::ValueRecovery::isInJSValueRegs):
(JSC::ValueRecovery::jsValueRegs):
(JSC::ValueRecovery::fpr):
(JSC::ValueRecovery::virtualRegister):
(JSC::ValueRecovery::constant):
* dfg/DFGOSRExitCompiler32_64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompiler64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGVariableEventStream.cpp:
(JSC::DFG::VariableEventStream::reconstruct):
2015-08-31 Chris Dumez <cdumez@apple.com>
NodeFilter.SHOW_ALL has wrong value on 32-bit
https://bugs.webkit.org/show_bug.cgi?id=148602
Reviewed by Geoffrey Garen.
NodeFilter.SHOW_ALL has wrong value on 32-bit. This is because
NodeFilter.SHOW_ALL is an unsigned long whose value is 0xFFFFFFFF but
our bindings code is casting it to an intptr_t type which is not wide
enough on 32-bit.
* create_hash_table:
Add extra curly brackets to initialize the union.
* runtime/Lookup.h:
Use a union type to store either a struct containing 2 intptr_t members
(value1 / value2) or a large constant of type unsigned long long. When
storing a constant, we only need one of the values so this allows us to
support larger constants without increasing the actual HashTableValue
size.
2015-08-31 Mark Lam <mark.lam@apple.com>
Watchdog timer callback should release the lock before deref'ing the watchdog.
https://bugs.webkit.org/show_bug.cgi?id=148635
Reviewed by Filip Pizlo.
The deref'ing of the watchdog may free it. The lock may not be available to be unlocked
after the deref.
* runtime/Watchdog.cpp:
(JSC::Watchdog::Watchdog):
2015-08-30 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] JSON.stringify should ignore object properties that have symbol values and convert the symbol values in array to null
https://bugs.webkit.org/show_bug.cgi?id=148628
Reviewed by Saam Barati.
As per ECMA262 6.0,
1. JSON.stringify should ignore object properties that have symbol values.
SerializeJSONProperty[1] will return undefined if the value of the property is a symbol.
In this case, SerializeJSONObject[2] does not append any string for this property.
2. JSON.stringify should convert the symbol values in array to null
As the same to the object case, SerializeJSONProperty will return undefined if the value of the property is a symbol.
But in the case of arrays, if the result of SerializeJSONProperty is undefined, it will emit "null"[3].
This behavior is already implemented in the existing JSON.stringify. Added tests to ensure that.
[1]: http://www.ecma-international.org/ecma-262/6.0/#sec-serializejsonproperty
[2]: http://www.ecma-international.org/ecma-262/6.0/#sec-serializejsonobject
[3]: http://www.ecma-international.org/ecma-262/6.0/#sec-serializejsonarray
* runtime/JSONObject.cpp:
(JSC::unwrapBoxedPrimitive):
(JSC::Stringifier::appendStringifiedValue):
(JSC::Stringifier::Holder::appendNextProperty):
* tests/stress/symbol-with-json.js:
(shouldBe):
2015-08-30 Filip Pizlo <fpizlo@apple.com>
JSC property attributes should fit in a byte
https://bugs.webkit.org/show_bug.cgi?id=148611
Reviewed by Sam Weinig.
I want to make room in PropertyMapEntry for more things to support property type inference (see
https://bugs.webkit.org/show_bug.cgi?id=148610). The most obvious candidate for a size reduction is
attributes, since we only have a small number of attribute bits. Even without complex changes, it
would have been possible to reduce the attribute field from 32 bits to 16 bits. Specifically, prior
to this change, the attributes field needed 9 bits. This made it very tempting to trim it so that
it could fit in a byte.
Luckily, many of the attributes bits are for the static lookup hashtables that we use for lazily
building objects in the standard library. Those bits don't need to stay around after the property
has been created, since they are just for telling the code in Lookup how to create the property.
So, this change separates the attributes bits into those that are interesting for Structure and
those that aren't. The ones used by Structure sit in the low 8 bits, allowing for the attributes
field in PropertyMapEntry to be a uint8_t. The attributes bits used only by Lookup use the higher
bits. In production, the conversion from the Lookup attributes to the Structure attributes is just
a cast to uint8_t. In debug, we assert that those bits are not dropped by accident. Code that
intentionally drops those bits calls attributesForStructure().
It turned out that there was a lot of code that was using the Function bit even in code that didn't
involve Lookup. This change removes those uses of Function. Structure does not need to know if we
think that a property points to a function.
* jsc.cpp:
(GlobalObject::finishCreation):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSObject.h:
* runtime/Lookup.cpp:
(JSC::setUpStaticFunctionSlot):
* runtime/Lookup.h:
(JSC::getStaticPropertySlot):
(JSC::getStaticValueSlot):
(JSC::reifyStaticProperties):
* runtime/MathObject.cpp:
(JSC::MathObject::finishCreation):
* runtime/NumberConstructor.cpp:
(JSC::NumberConstructor::finishCreation):
* runtime/PropertySlot.h:
(JSC::attributesForStructure):
(JSC::PropertySlot::setValue):
(JSC::PropertySlot::setCustom):
(JSC::PropertySlot::setCacheableCustom):
(JSC::PropertySlot::setGetterSlot):
(JSC::PropertySlot::setCacheableGetterSlot):
* runtime/Structure.h:
(JSC::PropertyMapEntry::PropertyMapEntry):
2015-08-29 Chris Dumez <cdumez@apple.com>
Unreviewed, fix PropertyName::isNull() that was introduced in r188994.
The condition was reversed.
* runtime/PropertyName.h:
(JSC::PropertyName::isNull):
2015-08-28 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r189136.
https://bugs.webkit.org/show_bug.cgi?id=148608
Made JSC tests flaky (Requested by ap on #webkit).
Reverted changeset:
"[JSC][x86] Improve the compare functions when comparing with
zero"
https://bugs.webkit.org/show_bug.cgi?id=148536
http://trac.webkit.org/changeset/189136
2015-08-28 Benjamin Poulain <bpoulain@apple.com>
[JSC] Get rid of DFG's MergeMode
https://bugs.webkit.org/show_bug.cgi?id=148245
Reviewed by Mark Lam.
That code has become useless, the merge mode is always MergeToSuccessors.
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGCFAPhase.cpp:
(JSC::DFG::CFAPhase::performBlockCFA):
* dfg/DFGInPlaceAbstractState.cpp:
(JSC::DFG::InPlaceAbstractState::endBasicBlock):
* dfg/DFGInPlaceAbstractState.h:
* dfg/DFGMergeMode.h: Removed.
2015-08-28 Benjamin Poulain <bpoulain@apple.com>
[JSC][x86] Improve the compare functions when comparing with zero
https://bugs.webkit.org/show_bug.cgi?id=148536
Reviewed by Geoffrey Garen.
This patch has two parts:
1) The macro assembler gets an additional cmp->test optimization
for LessThan and GreaterThanOrEqual.
Instead of comparing the value with an immediate, test the value
with itself and use the flag.
2) Extend the DFG JIT optimization of compare.
In particular, use the same optimization in compileInt32Compare()
as we have in compilePeepHoleBooleanBranch().
The generator compileInt32Compare() is unfortunately very
common due to MoveHints placed between the Compare node and the Branch
node.
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::compare32):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::branch32):
(JSC::MacroAssemblerX86Common::compare32):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePeepHoleBooleanBranch):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compileInt32Compare):
2015-08-28 Mark Lam <mark.lam@apple.com>
Add MacroAssemblerPrinter support for printing memory.
https://bugs.webkit.org/show_bug.cgi?id=148600
Reviewed by Saam Barati.
Previously, we can dump registers at runtime. Now we can dump memory too.
See comment in MacroAssemblerPrinter.h for examples of how to do this.
* assembler/MacroAssemblerPrinter.cpp:
(JSC::printMemory):
(JSC::MacroAssemblerPrinter::printCallback):
* assembler/MacroAssemblerPrinter.h:
(JSC::Memory::Memory):
(JSC::MemWord::MemWord):
(JSC::MacroAssemblerPrinter::PrintArg::PrintArg):
2015-08-28 Khem Raj <raj.khem@gmail.com>
JavaScriptCore fails to build using GCC 5
https://bugs.webkit.org/show_bug.cgi?id=147815
Reviewed by Filip Pizlo.
* runtime/JSObject.cpp: Explicitly instantiate all variants of
putByIndexBeyondVectorLengthWithAttributes used by JSArray.cpp.
2015-08-28 Mark Lam <mark.lam@apple.com>
Refactor the JIT printer out of the AbstractMacroAssembler into MacroAssemblerPrinter.
https://bugs.webkit.org/show_bug.cgi?id=148595
Reviewed by Geoffrey Garen.
Why do this?
1. MacroAssembler::print() code (except for the prototype) need no longer be parsed
when compiling C++ files that don't need it.
2. Adding support for more printable types to MacroAssemblerPrinter::PrintArg
triggers recompilation of less files.
3. The printing code is for most the part common between all target platforms and
was previously duplicated by cut-and-paste to all the varieties of MacroAssemblers
that support the MASM_PROBE mechanism. Now, there is only one copy in
MacroAssemblerPrinter.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::ProbeContext::print): Deleted.
- Removed this function because it is no longer useful since we have this more
flexible print() functionality.
(JSC::AbstractMacroAssembler::printIndent): Deleted.
(JSC::AbstractMacroAssembler::printCPU): Deleted.
(JSC::AbstractMacroAssembler::print): Deleted.
(JSC::AbstractMacroAssembler::PrintArg::PrintArg): Deleted.
(JSC::AbstractMacroAssembler::appendPrintArg): Deleted.
(JSC::AbstractMacroAssembler::printInternal): Deleted.
(JSC::AbstractMacroAssembler::printCallback): Deleted.
- These got moved into MacroAssemblerPrinter.cpp.
* assembler/MacroAssembler.h:
* assembler/MacroAssemblerARM.cpp:
(JSC::MacroAssemblerARM::printCPURegisters): Deleted.
(JSC::MacroAssemblerARM::printRegister): Deleted.
* assembler/MacroAssemblerARM.h:
* assembler/MacroAssemblerARMv7.cpp:
(JSC::MacroAssemblerARMv7::printCPURegisters): Deleted.
(JSC::MacroAssemblerARMv7::printRegister): Deleted.
* assembler/MacroAssemblerARMv7.h:
* assembler/MacroAssemblerX86Common.cpp:
(JSC::MacroAssemblerX86Common::printCPURegisters): Deleted.
(JSC::MacroAssemblerX86Common::printRegister): Deleted.
* assembler/MacroAssemblerX86Common.h:
- Deleted a whole bunch of mostly duplicated code.
* assembler/MacroAssemblerPrinter.cpp: Added.
(JSC::printIndent):
(JSC::printCPU):
(JSC::printCPURegisters):
(JSC::printRegister):
(JSC::MacroAssemblerPrinter::printCallback):
* assembler/MacroAssemblerPrinter.h: Added.
(JSC::MacroAssemblerPrinter::print):
(JSC::MacroAssemblerPrinter::PrintArg::PrintArg):
(JSC::MacroAssemblerPrinter::appendPrintArg):
(JSC::MacroAssembler::print):
2015-08-28 Filip Pizlo <fpizlo@apple.com>
LICM should be sound even if the CFG has changed
https://bugs.webkit.org/show_bug.cgi?id=148259
Reviewed by Benjamin Poulain.
Prior to this change, LICM expected a certain CFG shape around a loop: broken critical edges,
a pre-header, and the pre-header's terminal has exitOK. LICM would either crash on an
assertion, or generate code that fails validation, if these conditions weren't met.
The broken critical edge assumption is fine; so far we are assuming that SSA means broken
critical edges. We may revisit this, but we don't have to right now.
The other assumptions are not fine, because it's hard to guarantee that every phase will
preserve the presence of pre-headers. Even if we required that pre-headers are regenerated
before LICM, that regeneration wouldn't be guaranteed to create pre-headers that have exitOK at
the terminal. That's because once in SSA, the loop header probably has exitOK=false at the
head because of Phi's. Pre-header creation has no choice but to use the Node::origin from the
loop header, which means creating a pre-header that has exitOK=false. Regardless of whether
that's a fixable problem, it seems that our best short-term approach is just to be defensive
and turn undesirable pathologies into performance bugs and not crashes.
For the foreseeable future, once pre-headers are created they will probably not be removed. Our
current CFG simplification phase doesn't have a rule for removing pre-headers (since it doesn't
have any jump threading). So, it wouldn't be profitable to put effort towards reneration of
pre-headers for LICM's benefit.
Also, we cannot guarantee that some sequence of CFG transformations will not create a loop that
doesn't have a pre-header. This would be super rare. But you could imagine that some program
has control flow encoded using relooping (like
https://github.com/kripken/Relooper/blob/master/paper.pdf). If that happens, our compiler will
probably incrementally discover the "original" CFG. That may happen only after SSA conversion,
and so after pre-header generation. This is super unlikely for a bunch of reasons, but it
*could* happen.
So, this patch just makes sure that if pre-headers are missing or cannot be exited from, LICM
will simply avoid hoisting out of that block. At some point later, we can worry about a more
comprehensive solution to the pre-header problem. That's covered by this bug:
https://bugs.webkit.org/show_bug.cgi?id=148586
* dfg/DFGLICMPhase.cpp:
(JSC::DFG::LICMPhase::run):
(JSC::DFG::LICMPhase::attemptHoist):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* runtime/Options.h:
* tests/stress/licm-no-pre-header.js: Added.
(foo):
* tests/stress/licm-pre-header-cannot-exit.js: Added.
(foo):
2015-08-28 Yusuke Suzuki <utatane.tea@gmail.com>
Move std::function from JSFunction into NativeStdFunctionCell to correctly destroy the heap allocated std::function
https://bugs.webkit.org/show_bug.cgi?id=148262
Reviewed by Filip Pizlo.
std::function is heap allocated value. So if this is held in the JSCell, the cell should be destructible.
Before this patch, it is held in the JSStdFunction. JSStdFunction is the derived class from the JSFunction,
and they are not destructible. So it leaked the memory.
This patch extracts std::function field from the JSStdFunction to the NativeStdFunctionCell. NativeStdFunctionCell
is responsible for destructing the held std::function.
Instead of moving std::function to the ExecutableBase, we move it to the newly created NativeStdFunctionCell cell.
The reason is the following.
- Each NativeExecutable (in 64_32 JIT environment) has the trampolines to call given host functions.
And the address of the host function is directly embedded on the JIT-compiled trampoline code.
- To suppress the overuse of the executable memory (which is used to generate the trampoline), NativeExecutable
is cached. The host function address is used as the key to look up the cached executable from the table.
- In all the JSStdFunction, we use the same host function that immediately calls the each std::function.
- As a result, without any change, all the JSStdFunction hit the same cached NativeExecutable even if the held
std::function is different.
- To solve it, if we put the std::function in the NativeExecutable, we need to add this std::function
identity (like address) to the cache key, because the address of the stub host function (that calls the
std::function) is the same in the all JSStdFunction.
- But since the std::function will be allocated in the heap, this address is always different. So caching has
no effect.
- If we do not cache the NativeExecutable that holds the std::function, each time when creating the JSStdFunction,
we need to regenerate the completely same trampolines (since it just calls the same host function stub that
calls the std::function).
And this patch drops JSArrowFunction::destroy because (1) JSArrowFunction is not destructible and (2) it no longer
holds any fields that require destructions.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* jsc.cpp:
(runWithScripts):
* runtime/JSArrowFunction.cpp:
(JSC::JSArrowFunction::destroy): Deleted.
* runtime/JSArrowFunction.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::lookUpOrCreateNativeExecutable):
(JSC::JSFunction::create):
(JSC::getNativeExecutable): Deleted.
(JSC::JSStdFunction::JSStdFunction): Deleted.
(JSC::runStdFunction): Deleted.
* runtime/JSFunction.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::nativeStdFunctionStructure):
* runtime/JSNativeStdFunction.cpp: Added.
(JSC::JSNativeStdFunction::JSNativeStdFunction):
(JSC::JSNativeStdFunction::visitChildren):
(JSC::JSNativeStdFunction::finishCreation):
(JSC::runStdFunction):
(JSC::JSNativeStdFunction::create):
* runtime/JSNativeStdFunction.h: Copied from Source/JavaScriptCore/runtime/JSArrowFunction.h.
(JSC::JSNativeStdFunction::createStructure):
(JSC::JSNativeStdFunction::nativeStdFunctionCell):
* runtime/NativeStdFunctionCell.cpp: Added.
(JSC::NativeStdFunctionCell::create):
(JSC::NativeStdFunctionCell::NativeStdFunctionCell):
(JSC::NativeStdFunctionCell::destroy):
* runtime/NativeStdFunctionCell.h: Added.
(JSC::NativeStdFunctionCell::createStructure):
(JSC::NativeStdFunctionCell::function):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2015-08-28 Sukolsak Sakshuwong <sukolsak@gmail.com>
Create WebAssembly functions
https://bugs.webkit.org/show_bug.cgi?id=148373
Reviewed by Filip Pizlo.
Create functions from WebAssembly files generated by pack-asmjs
<https://github.com/WebAssembly/polyfill-prototype-1>.
WebAssembly functions created by this patch can only return 0.
Actual code generation will be implemented in subsequent patches.
This patch introduces WebAssemblyExecutable, a new subclass of
ExecutableBase for WebAssembly functions. CodeBlocks can now have
an owner that is not a ScriptExecutable. This patch changes the
return type of CodeBlock::ownerExecutable() from ScriptExecutable*
to ExecutableBase*. It also changes code that calls ScriptExecutable's
methods on CodeBlock::ownerExecutable() to use
CodeBlock::ownerScriptExecutable(), which does jsCast<ScriptExecutable*>.
Since ownerScriptExecutable() is called from WebCore and it uses
jsCast<ScriptExecutable*>, this patch needs to export
ScriptExecutable::info(). This should fix the build error in
https://bugs.webkit.org/show_bug.cgi?id=148555
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::hash):
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::dumpAssumingJITType):
(JSC::CodeBlock::dumpSource):
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::finalizeUnconditionally):
(JSC::CodeBlock::lineNumberForBytecodeOffset):
(JSC::CodeBlock::expressionRangeForBytecodeOffset):
(JSC::CodeBlock::install):
(JSC::CodeBlock::newReplacement):
(JSC::WebAssemblyCodeBlock::replacement):
(JSC::WebAssemblyCodeBlock::capabilityLevelInternal):
(JSC::CodeBlock::updateAllPredictions):
(JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::ownerExecutable):
(JSC::CodeBlock::ownerScriptExecutable):
(JSC::CodeBlock::codeType):
(JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock):
* debugger/Debugger.cpp:
(JSC::Debugger::toggleBreakpoint):
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::sourceIDForCallFrame):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::InlineStackEntry::executable):
(JSC::DFG::ByteCodeParser::inliningCost):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
(JSC::DFG::ByteCodeParser::parseCodeBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::isSupportedForInlining):
(JSC::DFG::mightCompileEval):
(JSC::DFG::mightCompileProgram):
(JSC::DFG::mightCompileFunctionForCall):
(JSC::DFG::mightCompileFunctionForConstruct):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::executableFor):
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareOSREntry):
* inspector/ScriptCallStackFactory.cpp:
(Inspector::CreateScriptCallStackFunctor::operator()):
* interpreter/Interpreter.cpp:
(JSC::eval):
(JSC::isWebAssemblyExecutable):
(JSC::GetStackTraceFunctor::operator()):
(JSC::UnwindFunctor::operator()):
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::sourceURL):
(JSC::StackVisitor::Frame::computeLineAndColumn):
* jit/JITOperations.cpp:
* jit/Repatch.cpp:
(JSC::linkPolymorphicCall):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setUpCall):
* llint/LowLevelInterpreter.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/Executable.cpp:
(JSC::WebAssemblyExecutable::WebAssemblyExecutable):
(JSC::WebAssemblyExecutable::destroy):
(JSC::WebAssemblyExecutable::visitChildren):
(JSC::WebAssemblyExecutable::clearCode):
(JSC::WebAssemblyExecutable::prepareForExecution):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isFunctionExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ExecutableBase::isWebAssemblyExecutable):
(JSC::ExecutableBase::clearCodeVirtual):
* runtime/JSFunction.cpp:
(JSC::JSFunction::create):
* runtime/JSFunction.h:
* runtime/JSFunctionInlines.h:
(JSC::JSFunction::JSFunction):
(JSC::JSFunction::isBuiltinFunction):
* runtime/JSType.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
* wasm/JSWASMModule.h:
(JSC::JSWASMModule::functions):
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::compile):
* wasm/WASMFunctionParser.h:
* wasm/WASMModuleParser.cpp:
(JSC::WASMModuleParser::WASMModuleParser):
(JSC::WASMModuleParser::parse):
(JSC::WASMModuleParser::parseFunctionDeclarationSection):
(JSC::WASMModuleParser::parseFunctionDefinition):
(JSC::WASMModuleParser::parseExportSection):
(JSC::parseWebAssembly):
* wasm/WASMModuleParser.h:
2015-08-28 Mark Lam <mark.lam@apple.com>
[Follow up] ScratchRegisterAllocator::preserveReusedRegistersByPushing() should allow room for C helper calls and keep sp properly aligned.
https://bugs.webkit.org/show_bug.cgi?id=148564
Not reviewed.
Updated the test to run with //@ runNoCJITNoAccessInlining instead of specifying
the JSC option directly via //@ run(). This is the right thing to do in order
to guarantee that the test will be compiled by the DFG.
* tests/stress/regress-148564.js:
2015-08-28 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Separate creating a style sheet from adding a new rule in the protocol
https://bugs.webkit.org/show_bug.cgi?id=148502
Reviewed by Timothy Hatcher.
* inspector/protocol/CSS.json:
Add CSS.createStyleSheet. Modify CSS.addRule.
2015-08-28 Mark Lam <mark.lam@apple.com>
ScratchRegisterAllocator::preserveReusedRegistersByPushing() should allow room for C helper calls and keep sp properly aligned.
https://bugs.webkit.org/show_bug.cgi?id=148564
Reviewed by Saam Barati.
ScratchRegisterAllocator::preserveReusedRegistersByPushing() pushes registers on
the stack in order to preserve them. But emitPutTransitionStub() (which uses
preserveReusedRegistersByPushing()) may also emit a call to a C helper function
to flush the heap write barrier buffer. The code for emitting a C helper call
expects the stack pointer (sp) to already be pointing to a location on the stack
where there's adequate space reserved for storing the arguments to the C helper,
and that space is expected to be at the top of the stack. Hence, there is a
conflict of expectations. As a result, the arguments for the C helper will
overwrite and corrupt the values that are pushed on the stack by
preserveReusedRegistersByPushing().
In addition, JIT compiled functions always position the sp such that it will be
aligned (according to platform ABI dictates) after a C call is made (i.e. after
the frame pointer and return address is pushed on to the stack).
preserveReusedRegistersByPushing()'s arbitrary pushing of a number of saved
register values may mess up this alignment.
The fix is to have preserveReusedRegistersByPushing(), after it has pushed the
saved register values, adjust the sp to reserve an additional amount of stack
space needed for C call helpers plus any padding needed to restore proper sp
alignment. The stack's ReservedZone will ensure that we have enough stack space
for this. ScratchRegisterAllocator::restoreReusedRegistersByPopping() also
needs to be updated to perform the complement of this behavior.
* jit/Repatch.cpp:
(JSC::emitPutReplaceStub):
(JSC::emitPutTransitionStub):
* jit/ScratchRegisterAllocator.cpp:
(JSC::ScratchRegisterAllocator::allocateScratchGPR):
(JSC::ScratchRegisterAllocator::allocateScratchFPR):
(JSC::ScratchRegisterAllocator::preserveReusedRegistersByPushing):
(JSC::ScratchRegisterAllocator::restoreReusedRegistersByPopping):
* jit/ScratchRegisterAllocator.h:
(JSC::ScratchRegisterAllocator::numberOfReusedRegisters):
* tests/stress/regress-148564.js: Added.
(test):
(runTest):
2015-08-28 Csaba Osztrogonác <ossy@webkit.org>
Unreviewed Windows buildfix.
Revert part of r189072 since the original change was rolled out by r189085.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2015-08-28 Csaba Osztrogonác <ossy@webkit.org>
Unreviewed Windows buildfix.
Revert r189077 since the original change was rolled out by r189085.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2015-08-27 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement Module execution and Loader's ready / link phase
https://bugs.webkit.org/show_bug.cgi?id=148172
Reviewed by Saam Barati.
This patch adds the link / ready phases to the existing module loader.
They are just the stubs and the actual implementations will be
forthcoming in the subsequnt patch.
And this patch paves the way to instantiate the module environment and
compile the executable code in the link phase. Move declaredVariables /
lexicalVariables from ModuleAnalyzer to JSModuleRecord to use them when
instantiating the module environment. Hold the source code in
JSModuleRecord to construct the executable in the link phase. And to
use HostResolveImportedModule operation from the C++ side, we expose
the JSMap from C++ to JS and use it in the builtin JS module loader
code.
* builtins/ModuleLoaderObject.js:
(requestResolveDependencies.resolveDependenciesPromise.this.requestInstantiate.then.):
(requestLink):
(requestReady):
(link):
(moduleEvaluation):
(loadModule):
* parser/ModuleAnalyzer.cpp:
(JSC::ModuleAnalyzer::ModuleAnalyzer):
(JSC::ModuleAnalyzer::analyze):
* parser/ModuleAnalyzer.h:
* runtime/Completion.cpp:
(JSC::checkModuleSyntax):
* runtime/JSModuleRecord.cpp:
(JSC::JSModuleRecord::finishCreation):
(JSC::JSModuleRecord::visitChildren):
(JSC::identifierToJSValue):
(JSC::JSModuleRecord::hostResolveImportedModule):
(JSC::JSModuleRecord::link):
(JSC::JSModuleRecord::execute):
* runtime/JSModuleRecord.h:
(JSC::JSModuleRecord::create):
(JSC::JSModuleRecord::sourceCode):
(JSC::JSModuleRecord::moduleKey):
(JSC::JSModuleRecord::exportEntries):
(JSC::JSModuleRecord::importEntries):
(JSC::JSModuleRecord::declaredVariables):
(JSC::JSModuleRecord::lexicalVariables):
(JSC::JSModuleRecord::JSModuleRecord):
* runtime/ModuleLoaderObject.cpp:
(JSC::moduleLoaderObjectParseModule):
(JSC::moduleLoaderObjectRequestedModules):
(JSC::moduleLoaderObjectModuleDeclarationInstantiation):
(JSC::moduleLoaderObjectEvaluate):
(JSC::ModuleLoaderObject::requestInstantiateAll): Deleted.
* runtime/ModuleLoaderObject.h:
2015-08-27 Mark Lam <mark.lam@apple.com>
Add noDFG() to jsc to prevent DFG compilation of a specified function.
https://bugs.webkit.org/show_bug.cgi?id=148559
Reviewed by Geoffrey Garen and Saam Barati.
* API/JSCTestRunnerUtils.cpp:
(JSC::setNeverInline):
(JSC::setNeverOptimize):
* API/JSCTestRunnerUtils.h:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpAssumingJITType):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::mightCompileEval):
(JSC::DFG::mightCompileProgram):
(JSC::DFG::mightCompileFunctionForCall):
(JSC::DFG::mightCompileFunctionForConstruct):
(JSC::DFG::mightInlineFunctionForCall):
* jsc.cpp:
(GlobalObject::finishCreation):
(functionNoDFG):
* runtime/Executable.h:
(JSC::ScriptExecutable::ecmaMode):
(JSC::ScriptExecutable::setNeverInline):
(JSC::ScriptExecutable::setNeverOptimize):
(JSC::ScriptExecutable::setDidTryToEnterInLoop):
(JSC::ScriptExecutable::neverInline):
(JSC::ScriptExecutable::neverOptimize):
(JSC::ScriptExecutable::didTryToEnterInLoop):
(JSC::ScriptExecutable::isInliningCandidate):
(JSC::ScriptExecutable::isOkToOptimize):
(JSC::ScriptExecutable::addressOfDidTryToEnterInLoop):
* runtime/TestRunnerUtils.cpp:
(JSC::setNeverInline):
(JSC::setNeverOptimize):
(JSC::optimizeNextInvocation):
* runtime/TestRunnerUtils.h:
2015-08-27 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r189064 and r189084.
https://bugs.webkit.org/show_bug.cgi?id=148560
Breaks 117 JSC tests. (Requested by mlam on #webkit).
Reverted changesets:
"[ES6] Add TypedArray.prototype functionality."
https://bugs.webkit.org/show_bug.cgi?id=148035
http://trac.webkit.org/changeset/189064
"Unbreak JSC tests (broken since r189064)."
http://trac.webkit.org/changeset/189084
2015-08-27 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r189079.
https://bugs.webkit.org/show_bug.cgi?id=148555
broke the build (Requested by jessieberlin on #webkit).
Reverted changeset:
"Create WebAssembly functions"
https://bugs.webkit.org/show_bug.cgi?id=148373
http://trac.webkit.org/changeset/189079
2015-08-27 Sukolsak Sakshuwong <sukolsak@gmail.com>
Create WebAssembly functions
https://bugs.webkit.org/show_bug.cgi?id=148373
Reviewed by Geoffrey Garen.
Create functions from WebAssembly files generated by pack-asmjs
<https://github.com/WebAssembly/polyfill-prototype-1>.
WebAssembly functions created by this patch can only return 0.
Actual code generation will be implemented in subsequent patches.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::hash):
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::dumpAssumingJITType):
(JSC::CodeBlock::dumpSource):
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::finalizeUnconditionally):
(JSC::CodeBlock::lineNumberForBytecodeOffset):
(JSC::CodeBlock::expressionRangeForBytecodeOffset):
(JSC::CodeBlock::install):
(JSC::CodeBlock::newReplacement):
(JSC::WebAssemblyCodeBlock::replacement):
(JSC::WebAssemblyCodeBlock::capabilityLevelInternal):
(JSC::CodeBlock::updateAllPredictions):
(JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::ownerExecutable):
(JSC::CodeBlock::ownerScriptExecutable):
(JSC::CodeBlock::codeType):
(JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock):
* debugger/Debugger.cpp:
(JSC::Debugger::toggleBreakpoint):
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::sourceIDForCallFrame):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::InlineStackEntry::executable):
(JSC::DFG::ByteCodeParser::inliningCost):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
(JSC::DFG::ByteCodeParser::parseCodeBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::isSupportedForInlining):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::executableFor):
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareOSREntry):
* inspector/ScriptCallStackFactory.cpp:
(Inspector::CreateScriptCallStackFunctor::operator()):
* interpreter/Interpreter.cpp:
(JSC::eval):
(JSC::isWebAssemblyExecutable):
(JSC::GetStackTraceFunctor::operator()):
(JSC::UnwindFunctor::operator()):
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::sourceURL):
(JSC::StackVisitor::Frame::computeLineAndColumn):
* jit/JITOperations.cpp:
* jit/Repatch.cpp:
(JSC::isWebAssemblyExecutable):
(JSC::linkPolymorphicCall):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setUpCall):
* llint/LowLevelInterpreter.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/Executable.cpp:
(JSC::WebAssemblyExecutable::WebAssemblyExecutable):
(JSC::WebAssemblyExecutable::destroy):
(JSC::WebAssemblyExecutable::visitChildren):
(JSC::WebAssemblyExecutable::clearCode):
(JSC::WebAssemblyExecutable::prepareForExecution):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isFunctionExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ExecutableBase::isWebAssemblyExecutable):
(JSC::ExecutableBase::clearCodeVirtual):
* runtime/JSFunction.cpp:
(JSC::JSFunction::create):
* runtime/JSFunction.h:
* runtime/JSFunctionInlines.h:
(JSC::JSFunction::JSFunction):
(JSC::JSFunction::isBuiltinFunction):
* runtime/JSType.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
* wasm/JSWASMModule.h:
(JSC::JSWASMModule::functions):
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::compile):
* wasm/WASMFunctionParser.h:
* wasm/WASMModuleParser.cpp:
(JSC::WASMModuleParser::WASMModuleParser):
(JSC::WASMModuleParser::parse):
(JSC::WASMModuleParser::parseFunctionDeclarationSection):
(JSC::WASMModuleParser::parseFunctionDefinition):
(JSC::WASMModuleParser::parseExportSection):
(JSC::parseWebAssembly):
* wasm/WASMModuleParser.h:
2015-08-27 Brent Fulgham <bfulgham@apple.com>
[Win] Unreviewed build fix after r189064.
JSTypedArrayViewPrototypes.{h,cpp} -> JSTypedArrayViewPrototype.{h,cpp}
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2015-08-27 Alex Christensen <achristensen@webkit.org>
Make DLLLauncherMain executables dependent on dll
https://bugs.webkit.org/show_bug.cgi?id=148548
Reviewed by Brent Fulgham.
* shell/CMakeLists.txt:
* shell/PlatformWin.cmake:
2015-08-27 Filip Pizlo <fpizlo@apple.com>
DFG::StrCat isn't really effectful
https://bugs.webkit.org/show_bug.cgi?id=148443
Reviewed by Geoffrey Garen.
I previously made the DFG StrCat node effectful because it is implemented by calling a
DFGOperations function that could cause arbitrary effects. But, the node is only generated from the
op_strcat bytecode operation, and that operation is only used when we first ensure that its
operands are primitives. Primitive operands to StrCat cannot cause arbitrary side-effects. The
reason why I didn't immediately mark StrCat as pure was because there was nothing in DFG IR that
guaranteed that StrCat's children were primitives.
This change adds a KnownPrimitiveUse use kind, and applies it to StrCat. This allows us to mark
StrCat as being pure. This should be a speed-up because we can CSE StrCat and because it means that
we can OSR exit after a StrCat (a pure node doesn't clobber exit state), so we can convert more
of a large string concatenation into MakeRope's.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
* dfg/DFGOperations.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::SafeToExecuteEdge::operator()):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::speculate):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGUseKind.cpp:
(WTF::printInternal):
* dfg/DFGUseKind.h:
(JSC::DFG::typeFilterFor):
(JSC::DFG::shouldNotHaveTypeCheck):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileStrCat):
(JSC::FTL::DFG::LowerDFGToLLVM::speculate):
2015-08-27 Brent Fulgham <bfulgham@apple.com>
[Win] Unreviewed build fix after r189064.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2015-08-27 Yusuke Suzuki <utatane.tea@gmail.com>
Add module loader "resolve" hook for local file system to test the loader in JSC shell
https://bugs.webkit.org/show_bug.cgi?id=148543
Reviewed by Filip Pizlo.
Add the module loader "resolve" hook to the JSC shell.
It takes the module name and the referrer module key and resolves the name to the unique module key.
resolve(ModuleName moduleName, ModuleKey referrer) -> Promise<ModuleKey>
In the JSC shell, since we load the module from the local file system, we treat an absolute file path
as a module key. So, in this patch, we implement the "resolve" hook that resolves the module name to
the absolute file path.
This local file system "resolve" functionality makes JSC shell easy to test the module loader.
* jsc.cpp:
(GlobalObject::finishCreation):
(GlobalObject::moduleLoaderFetch):
(pathSeparator):
(extractDirectoryName):
(currentWorkingDirectory):
(resolvePath):
(GlobalObject::moduleLoaderResolve):
(functionDrainMicrotasks):
* runtime/JSInternalPromiseDeferred.cpp:
(JSC::JSInternalPromiseDeferred::resolve):
(JSC::JSInternalPromiseDeferred::reject):
* runtime/JSInternalPromiseDeferred.h:
* tests/stress/pathname-resolve.js: Added.
(shouldBe):
(shouldThrow):
2015-08-27 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix some FIXMEs and add some new ones, based on things we've learned from some
recent OSR exit work.
* dfg/DFGLICMPhase.cpp:
(JSC::DFG::LICMPhase::run):
(JSC::DFG::LICMPhase::attemptHoist):
* dfg/DFGMayExit.cpp:
* dfg/DFGMayExit.h:
2015-08-27 Keith Miller <keith_miller@apple.com>
[ES6] Add TypedArray.prototype functionality.
https://bugs.webkit.org/show_bug.cgi?id=148035
Reviewed by Geoffrey Garen.
This patch should add most of the functionality for
the prototype properties of TypedArray objects in ES6.
There are a few exceptions to this, which will be added
in upcoming patches:
1) First we do not use the species constructor for some
of the TypedArray prototype functions (namely: map, filter,
slice, and subarray). That will need to be added when
species constructors are finished.
2) TypedArrays still have a length, byteOffset, byteLength,
and buffer are still attached to the TypedArray instance (in
the spec they are on the TypedArray.prototype instance object)
since the JIT currently assumes those properties are fixed.
3) The TypedArray.constructor property is not added yet
as it should point to the TypedArray instance object,
which will be added in a future patch.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/TypedArray.prototype.js: Added.
(every):
(find):
(findIndex):
(forEach):
(some):
(sort.min):
(sort.merge):
(sort.mergeSort):
(sort):
(reduce):
(reduceRight):
(map):
(filter):
(toLocaleString):
* runtime/ArrayPrototype.cpp:
* runtime/ArrayPrototype.h:
* runtime/CommonIdentifiers.h:
* runtime/JSGenericTypedArrayView.h:
(JSC::sortFloat):
(JSC::JSGenericTypedArrayView::toAdaptorNativeFromValue):
(JSC::JSGenericTypedArrayView::setRangeToValue):
(JSC::JSGenericTypedArrayView::sort):
* runtime/JSGenericTypedArrayViewInlines.h:
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h: Added.
(JSC::argumentClampedIndexFromStartOrEnd):
(JSC::genericTypedArrayViewProtoFuncSet):
(JSC::genericTypedArrayViewProtoFuncEntries):
(JSC::genericTypedArrayViewProtoFuncCopyWithin):
(JSC::genericTypedArrayViewProtoFuncFill):
(JSC::genericTypedArrayViewProtoFuncIndexOf):
(JSC::genericTypedArrayViewProtoFuncJoin):
(JSC::genericTypedArrayViewProtoFuncKeys):
(JSC::genericTypedArrayViewProtoFuncLastIndexOf):
(JSC::genericTypedArrayViewProtoGetterFuncLength):
(JSC::genericTypedArrayViewProtoGetterFuncByteLength):
(JSC::genericTypedArrayViewProtoGetterFuncByteOffset):
(JSC::genericTypedArrayViewProtoFuncReverse):
(JSC::genericTypedArrayViewPrivateFuncSort):
(JSC::genericTypedArrayViewProtoFuncSlice):
(JSC::genericTypedArrayViewProtoFuncSubarray):
(JSC::typedArrayViewProtoFuncValues):
* runtime/JSGenericTypedArrayViewPrototypeInlines.h:
(JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
(JSC::genericTypedArrayViewProtoFuncSet): Deleted.
(JSC::genericTypedArrayViewProtoFuncSubarray): Deleted.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSObject.h:
* runtime/JSTypedArrayPrototypes.cpp:
* runtime/JSTypedArrayPrototypes.h:
* runtime/JSTypedArrayViewPrototype.cpp: Added.
(JSC::typedArrayViewPrivateFuncLength):
(JSC::typedArrayViewPrivateFuncSort):
(JSC::typedArrayViewProtoFuncSet):
(JSC::typedArrayViewProtoFuncEntries):
(JSC::typedArrayViewProtoFuncCopyWithin):
(JSC::typedArrayViewProtoFuncFill):
(JSC::typedArrayViewProtoFuncLastIndexOf):
(JSC::typedArrayViewProtoFuncIndexOf):
(JSC::typedArrayViewProtoFuncJoin):
(JSC::typedArrayViewProtoFuncKeys):
(JSC::typedArrayViewProtoGetterFuncLength):
(JSC::typedArrayViewProtoGetterFuncByteLength):
(JSC::typedArrayViewProtoGetterFuncByteOffset):
(JSC::typedArrayViewProtoFuncReverse):
(JSC::typedArrayViewProtoFuncSubarray):
(JSC::typedArrayViewProtoFuncSlice):
(JSC::typedArrayViewProtoFuncValues):
(JSC::JSTypedArrayViewPrototype::JSTypedArrayViewPrototype):
(JSC::JSTypedArrayViewPrototype::finishCreation):
(JSC::JSTypedArrayViewPrototype::create):
(JSC::JSTypedArrayViewPrototype::createStructure):
* runtime/JSTypedArrayViewPrototype.h: Copied from Source/JavaScriptCore/runtime/JSTypedArrayPrototypes.cpp.
2015-08-27 Alex Christensen <achristensen@webkit.org>
Isolate Source directories in CMake build
https://bugs.webkit.org/show_bug.cgi?id=148389
Reviewed by Brent Fulgham.
* PlatformWin.cmake:
Include ../include/private to find WTF headers in internal build.
Don't use a script to generate forwarding headers.
* shell/PlatformWin.cmake:
Copy inspector scripts to the forwarding headers directory to be used by WebCore.
2015-08-27 Alex Christensen <achristensen@webkit.org>
[Win CMake] Fix incremental build after r188673
https://bugs.webkit.org/show_bug.cgi?id=148539
Reviewed by Brent Fulgham.
* PlatformWin.cmake:
Use xcopy as a build step instead of file(COPY ...) to copy updated headers.
2015-08-27 Jon Davis <jond@apple.com>
Include ES6 Generators and Proxy object status to feature status page.
https://bugs.webkit.org/show_bug.cgi?id=148095
Reviewed by Timothy Hatcher.
* features.json:
2015-08-27 Filip Pizlo <fpizlo@apple.com>
Unreviewed, add a comment to describe something I learned about a confusingly-named function.
* dfg/DFGUseKind.h:
(JSC::DFG::isCell):
2015-08-27 Basile Clement <basile_clement@apple.com>
REGRESSION(r184779): Possible read-after-free in JavaScriptCore/dfg/DFGClobberize.h
https://bugs.webkit.org/show_bug.cgi?id=148411
Reviewed by Geoffrey Garen and Filip Pizlo.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
2015-08-27 Brian Burg <bburg@apple.com>
Web Inspector: FrontendChannel should know its own connection type
https://bugs.webkit.org/show_bug.cgi?id=148482
Reviewed by Joseph Pecoraro.
* inspector/InspectorFrontendChannel.h: Add connectionType().
* inspector/remote/RemoteInspectorDebuggableConnection.h:
2015-08-26 Filip Pizlo <fpizlo@apple.com>
Node::origin should always be set, and the dead zone due to SSA Phis can just use exitOK=false
https://bugs.webkit.org/show_bug.cgi?id=148462
Reviewed by Saam Barati.
The need to label nodes that absolutely cannot exit was first observed when we introduced SSA form.
We indicated this by not setting the CodeOrigin.
But just recently (http://trac.webkit.org/changeset/188979), we added a more comprehensive "exitOK"
bit in NodeOrigin. After that change, there were two ways of indicating that you cannot exit:
!exitOK and an unset NodeOrigin. An unset NodeOrigin implied !exitOK.
Now, this change is about removing the old way so that we only use !exitOK. From now on, all nodes
must have their NodeOrigin set, and the IR validation will check this. This means that I could
remove various pieces of cruft for dealing with unset NodeOrigins, but I did have to add some new
cruft to ensure that all nodes we create have a NodeOrigin.
This change simplifies our IR by having a simpler rule about when NodeOrigin is set: it's always
set.
* dfg/DFGBasicBlock.cpp:
(JSC::DFG::BasicBlock::isInBlock):
(JSC::DFG::BasicBlock::removePredecessor):
(JSC::DFG::BasicBlock::firstOriginNode): Deleted.
(JSC::DFG::BasicBlock::firstOrigin): Deleted.
* dfg/DFGBasicBlock.h:
(JSC::DFG::BasicBlock::begin):
(JSC::DFG::BasicBlock::end):
(JSC::DFG::BasicBlock::numSuccessors):
(JSC::DFG::BasicBlock::successor):
* dfg/DFGCombinedLiveness.cpp:
(JSC::DFG::liveNodesAtHead):
* dfg/DFGConstantHoistingPhase.cpp:
* dfg/DFGCriticalEdgeBreakingPhase.cpp:
(JSC::DFG::CriticalEdgeBreakingPhase::breakCriticalEdge):
* dfg/DFGForAllKills.h:
(JSC::DFG::forAllKilledOperands):
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
* dfg/DFGLoopPreHeaderCreationPhase.cpp:
(JSC::DFG::createPreHeader):
(JSC::DFG::LoopPreHeaderCreationPhase::run):
* dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
(JSC::DFG::OSRAvailabilityAnalysisPhase::run):
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* dfg/DFGPutStackSinkingPhase.cpp:
* dfg/DFGSSAConversionPhase.cpp:
(JSC::DFG::SSAConversionPhase::run):
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::validate):
(JSC::DFG::Validate::validateSSA):
2015-08-26 Saam barati <sbarati@apple.com>
MarkedBlock::allocateBlock will have the wrong allocation size when (sizeof(MarkedBlock) + bytes) is divisible by WTF::pageSize()
https://bugs.webkit.org/show_bug.cgi?id=148500
Reviewed by Mark Lam.
Consider the following scenario:
- On OS X, WTF::pageSize() is 4*1024 bytes.
- JSEnvironmentRecord::allocationSizeForScopeSize(6621) == 53000
- sizeof(MarkedBlock) == 248
- (248 + 53000) is a multiple of 4*1024.
- (248 + 53000)/(4*1024) == 13
We will allocate a chunk of memory of size 53248 bytes that looks like this:
0 248 256 53248 53256
[Marked Block | 8 bytes | payload ...... ] 8 bytes |
^ ^
Our Environment record starts here. ^
^
Our last JSValue in the environment record will go from byte 53248 to 53256. But, we don't own this memory.
We need to ensure that we round up sizeof(MarkedBlock) to an
atomSize boundary. We need to do this because the first atom
inside the MarkedBlock will start at the rounded up multiple
of atomSize past MarkedBlock. If we end up with an allocation
that is perfectly aligned to the page size, then we will be short
8 bytes (in the current implementation where atomSize is 16 bytes,
and MarkedBlock is 248 bytes).
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::allocateBlock):
* tests/stress/heap-allocator-allocates-incorrect-size-for-activation.js: Added.
(use):
(makeFunction):
2015-08-26 Mark Lam <mark.lam@apple.com>
watchdog m_didFire state erroneously retained.
https://bugs.webkit.org/show_bug.cgi?id=131082
Reviewed by Geoffrey Garen.
The watchdog can fire for 2 reasons:
1. an external controlling entity (i.e. another thread) has scheduled termination
of the script thread via watchdog::terminateSoon().
2. the allowed CPU time has expired.
For case 1, we're doing away with the m_didFire flag. Watchdog::terminateSoon()
will set the timer deadlines and m_timeLimit to 0, and m_timerDidFire to true.
This will get the script thread to check Watchdog::didFire() and terminate
execution.
Note: the watchdog only guarantees that script execution will terminate as soon
as possible due to a time limit of 0. Once we've exited the VM, the client of the
VM is responsible from keeping a flag to prevent new script execution.
In a race condition, if terminateSoon() is called just after execution has gotten
past the client's reentry check and the client is in the process of re-entering,
the worst that can happen is that we will schedule the watchdog timer to fire
after a period of 0. This will terminate script execution quickly, and thereafter
the client's check should be able to prevent further entry into the VM.
The correctness (i.e. has no race condition) of this type of termination relies
on the termination state being sticky. Once the script thread is terminated this
way, the VM will continue to terminate scripts quickly until the client sets the
time limit to a non-zero value (or clears it which sets the time limit to
noTimeLimit).
For case 2, the watchdog does not alter m_timeLimit. If the CPU deadline has
been reached, the script thread will terminate execution and exit the VM.
If the client of the VM starts new script execution, the watchdog will allow
execution for the specified m_timeLimit. In this case, since m_timeLimit is not
0, the script gets a fresh allowance of CPU time to execute. Hence, terminations
due to watchdog time outs are no longer sticky.
* API/JSContextRef.cpp:
(JSContextGroupSetExecutionTimeLimit):
(JSContextGroupClearExecutionTimeLimit):
* API/tests/ExecutionTimeLimitTest.cpp:
- Add test scenarios to verify that the watchdog is automatically reset by the VM
upon throwing the TerminatedExecutionException.
(testResetAfterTimeout):
(testExecutionTimeLimit):
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_loop_hint):
(JSC::JIT::emitSlow_op_loop_hint):
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::ensureWatchdog):
* runtime/VM.h:
* runtime/VMInlines.h: Added.
(JSC::VM::shouldTriggerTermination):
* runtime/Watchdog.cpp:
(JSC::Watchdog::Watchdog):
(JSC::Watchdog::setTimeLimit):
(JSC::Watchdog::terminateSoon):
(JSC::Watchdog::didFireSlow):
(JSC::Watchdog::hasTimeLimit):
(JSC::Watchdog::enteredVM):
(JSC::Watchdog::exitedVM):
(JSC::Watchdog::startTimer):
(JSC::Watchdog::stopTimer):
(JSC::Watchdog::hasStartedTimer): Deleted.
(JSC::Watchdog::fire): Deleted.
* runtime/Watchdog.h:
(JSC::Watchdog::didFire):
(JSC::Watchdog::timerDidFireAddress):
2015-08-26 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Implement tracking of active stylesheets in the frontend
https://bugs.webkit.org/show_bug.cgi?id=105828
Reviewed by Timothy Hatcher.
* inspector/protocol/CSS.json:
Add new events for when a StyleSheet is added or removed.
2015-08-26 Chris Dumez <cdumez@apple.com>
Distinguish Web IDL callback interfaces from Web IDL callback functions
https://bugs.webkit.org/show_bug.cgi?id=148434
Reviewed by Geoffrey Garen.
Add isNull() convenience method on PropertyName.
* runtime/PropertyName.h:
(JSC::PropertyName::isNull):
2015-08-26 Filip Pizlo <fpizlo@apple.com>
Node::origin should be able to tell you if it's OK to exit
https://bugs.webkit.org/show_bug.cgi?id=145204
Reviewed by Geoffrey Garen.
This is a major change to DFG IR, that makes it easier to reason about where nodes with
speculations can be soundly hoisted.
A program in DFG IR is a sequence of operations that compute the values of SSA variables,
perform effects on the heap or stack, and perform updates to the OSR exit state. Because
effects and OSR exit updates are interleaved, there are points in execution where exiting
simply won't work. For example, we may have some bytecode operation:
[ 24] op_foo loc42 // does something, and puts a value in loc42.
that gets compiled down to a sequence of DFG IR nodes like:
a: Foo(W:Heap, R:World, bc#24) // writes heap, reads world - i.e. an observable effect.
b: MovHint(@a, loc42, bc#24)
c: SetLocal(Check:Int32:@a, loc42, bc#24, exit: bc#26)
Note that we can OSR exit at @a because we haven't yet performed any effects for bc#24 yet and
we have performed all effects for prior bytecode operations. That's what the origin.forExit
being set to "bc#24" guarantees. So, an OSR exit at @a would transfer execution to bc#24 and
this would not be observable. But at @b, if we try to exit to bc#24 as indicated by forExit, we
would end up causing the side effect of bc#24 to execute a second time. This would be
observable, so we cannot do it. And we cannot exit to the next instruction - bc#26 - either,
because @b is responsible for updating the OSR state to indicate that the result of @a should
be put into loc42. It's not until we get to @c that we can exit again.
This is a confusing, but useful, property of DFG IR. It's useful because it allows us to use IR
to spell out how we would have affected the bytecode state, and we use this to implement hard
things like object allocation elimination, where we use IR instructions to indicate what object
allocation and mutation operations we would have performed, and which bytecode variables would
have pointed to those objects. So long as IR allows us to describe how OSR exit state is
updated, there will be points in execution where that state is invalid - especially if the IR
to update exit state is separate from the IR to perform actual effects.
But this property is super confusing! It's difficult to explain that somehow magically, @b is a
bad place to put OSR exits, and that magically we will only have OSR exits at @a. Of course, it
all kind of makes sense - we insert OSR exit checks in phases that *know* where it's safe to
exit - but it's just too opaque. This also gets in the way of more sophisticated
transformations. For example, LICM barely works - it magically knows that loop pre-headers are
good places to exit from, but it has no way of determining if that is actually true. It would
be odd to introduce a restriction that anytime some block qualifies as a pre-header according
to our loop calculator, it must end with a terminal at which it is OK to exit. So, our choices
are to either leave LICM in a magical state and exercise extreme caution when introducing new
optimizations that hoist checks, or to do something to make the "can I exit here" property more
explicit in IR.
We have already, in a separate change, added a NodeOrigin::exitOK property, though it didn't do
anything yet. This change puts exitOK to work, and makes it an integral part of IR. The key
intuition behind this change is that if we know which nodes clobber exit state - i.e. after the
node, it's no longer possible to OSR exit until the exit state is fixed up - then we can figure
out where it's fine to exit. This change mostly adopts the already implicit rule that it's
always safe to exit right at the boundary of exit origins (in between two nodes where
origin.forExit differs), and adds a new node, called ExitOK, which is a kind of declaration
that exit state is good again. When making this change, I struggled with the question of
whether to make origin.exitOK be explicit, or something that we can compute with an analysis.
Of course if we are armed with a clobbersExitState(Node*) function, we can find the places
where it's fine to exit. But this kind of computation could get quite sophisticated if the
nodes belonging to an exit origin are lowered to a control-flow construct. It would also be
harder to see what the original intent was, if we found an error: is the bug that we shouldn't
be clobbering exit state, or that we shouldn't be exiting? This change opts to make exitOK be
an explicit property of IR, so that DFG IR validation will reject any program where exitOK is
true after a node that clobbersExitState(), or if exitOK is true after a node has exitOK set to
false - unless the latter node has a different exit origin or is an ExitOK node. It will also
reject any program where a node mayExit() with !exitOK.
It turns out that this revealed a lot of sloppiness and what almost looked like an outright
bug: the callee property of an inline closure call frame was being set up "as if" by the
callee's op_enter. If we did hoist a check per the old rule - to the boundary of exit origins -
then we would crash because the callee is unknown. It also revealed that LICM could *almost*
get hosed by having a pre-header where there are effects before the jump. I wasn't able to
construct a test case that would crash trunk, but I also couldn't quite prove why such a
program couldn't be constructed. I did fix the issue in loop pre-header creation, and the
validater does catch the issue because of its exitOK assertions.
This doesn't yet add any other safeguards to LICM - that phase still expects that pre-headers
are in place and that they were created in such a way that their terminal origins have exitOK.
It also still keeps the old way of saying "not OK to exit" - having a clear NodeOrigin. In a
later patch I'll remove that and use !exitOK everywhere. Note that I did consider using clear
NodeOrigins to signify that it's not OK to exit, but that would make DFGForAllKills a lot more
expensive - it would have to sometimes search to find nearby forExit origins if the current
node doesn't have it set - and that's a critical phase for DFG compilation performance.
Requiring that forExit is usually set to *something* and that properly shadows the original
bytecode is cheap and easy, so it seemed like a good trade-off.
This change has no performance effect. Its only effect is that it makes the compiler easier to
understand by turning a previously magical concept into an explicit one.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAbstractHeap.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::setDirect):
(JSC::DFG::ByteCodeParser::currentNodeOrigin):
(JSC::DFG::ByteCodeParser::branchData):
(JSC::DFG::ByteCodeParser::addToGraph):
(JSC::DFG::ByteCodeParser::handleCall):
(JSC::DFG::ByteCodeParser::inlineCall):
(JSC::DFG::ByteCodeParser::handleInlining):
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::handlePutById):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCFGSimplificationPhase.cpp:
(JSC::DFG::CFGSimplificationPhase::run):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGClobbersExitState.cpp: Added.
(JSC::DFG::clobbersExitState):
* dfg/DFGClobbersExitState.h: Added.
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::convertStringAddUse):
(JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
(JSC::DFG::FixupPhase::fixupGetAndSetLocalsInBlock):
(JSC::DFG::FixupPhase::fixupChecksInBlock):
* dfg/DFGFlushFormat.h:
(JSC::DFG::useKindFor):
(JSC::DFG::uncheckedUseKindFor):
(JSC::DFG::typeFilterFor):
* dfg/DFGGraph.cpp:
(JSC::DFG::printWhiteSpace):
(JSC::DFG::Graph::dumpCodeOrigin):
(JSC::DFG::Graph::dump):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::addSpeculationMode):
* dfg/DFGInsertionSet.cpp:
(JSC::DFG::InsertionSet::insertSlow):
(JSC::DFG::InsertionSet::execute):
* dfg/DFGLoopPreHeaderCreationPhase.cpp:
(JSC::DFG::LoopPreHeaderCreationPhase::run):
* dfg/DFGMayExit.cpp:
(JSC::DFG::mayExit):
(WTF::printInternal):
* dfg/DFGMayExit.h:
* dfg/DFGMovHintRemovalPhase.cpp:
* dfg/DFGNodeOrigin.cpp: Added.
(JSC::DFG::NodeOrigin::dump):
* dfg/DFGNodeOrigin.h:
(JSC::DFG::NodeOrigin::NodeOrigin):
(JSC::DFG::NodeOrigin::isSet):
(JSC::DFG::NodeOrigin::withSemantic):
(JSC::DFG::NodeOrigin::withExitOK):
(JSC::DFG::NodeOrigin::withInvalidExit):
(JSC::DFG::NodeOrigin::takeValidExit):
(JSC::DFG::NodeOrigin::forInsertingAfter):
(JSC::DFG::NodeOrigin::operator==):
(JSC::DFG::NodeOrigin::operator!=):
* dfg/DFGNodeType.h:
* dfg/DFGOSREntrypointCreationPhase.cpp:
(JSC::DFG::OSREntrypointCreationPhase::run):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::OSRExit):
(JSC::DFG::OSRExit::setPatchableCodeOffset):
* dfg/DFGOSRExitBase.h:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* dfg/DFGPhantomInsertionPhase.cpp:
* dfg/DFGPhase.cpp:
(JSC::DFG::Phase::validate):
(JSC::DFG::Phase::beginPhase):
(JSC::DFG::Phase::endPhase):
* dfg/DFGPhase.h:
(JSC::DFG::Phase::vm):
(JSC::DFG::Phase::codeBlock):
(JSC::DFG::Phase::profiledBlock):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGPutStackSinkingPhase.cpp:
* dfg/DFGSSAConversionPhase.cpp:
(JSC::DFG::SSAConversionPhase::run):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::SpeculativeJIT):
(JSC::DFG::SpeculativeJIT::speculationCheck):
(JSC::DFG::SpeculativeJIT::emitInvalidationPoint):
(JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution):
(JSC::DFG::SpeculativeJIT::compileCurrentBlock):
(JSC::DFG::SpeculativeJIT::checkArgumentTypes):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStoreBarrierInsertionPhase.cpp:
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::run):
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::validate):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::lower):
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
(JSC::FTL::DFG::LowerDFGToLLVM::compileUpsilon):
(JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
2015-08-26 Andreas Kling <akling@apple.com>
[JSC] StructureTransitionTable should eagerly deallocate single-transition WeakImpls.
<https://webkit.org/b/148478>
Reviewed by Geoffrey Garen.
Use a WeakHandleOwner to eagerly deallocate StructureTransitionTable's Weak pointers
when it's using the single-transition optimization and the Structure it transitioned
to has been GC'd.
This prevents Structures from keeping WeakBlocks alive longer than necessary when
they've been transitioned away from but are still in use themselves.
* runtime/Structure.cpp:
(JSC::singleSlotTransitionWeakOwner):
(JSC::StructureTransitionTable::singleTransition):
(JSC::StructureTransitionTable::setSingleTransition):
(JSC::StructureTransitionTable::add):
* runtime/StructureTransitionTable.h:
(JSC::StructureTransitionTable::singleTransition): Deleted.
(JSC::StructureTransitionTable::setSingleTransition): Deleted.
2015-08-26 Brian Burg <bburg@apple.com>
Web Inspector: REGRESSION(r188965): BackendDispatcher loses request ids when called re-entrantly
https://bugs.webkit.org/show_bug.cgi?id=148480
Reviewed by Joseph Pecoraro.
I added an assertion that m_currentRequestId is Nullopt when dispatch() is called, but this should
not hold if dispatching a backend command while debugger is paused. I will remove the assertion
and add proper scoping for all dispatch() branches.
No new tests, this wrong assert caused inspector/dom-debugger/node-removed.html to crash reliably.
* inspector/InspectorBackendDispatcher.cpp:
(Inspector::BackendDispatcher::dispatch): Cover each exit with an appropriate TemporaryChange scope.
2015-08-26 Sukolsak Sakshuwong <sukolsak@gmail.com>
Remove the unused *Executable::unlinkCalls() and CodeBlock::unlinkCalls()
https://bugs.webkit.org/show_bug.cgi?id=148469
Reviewed by Geoffrey Garen.
We use CodeBlock::unlinkIncomingCalls() to unlink calls.
(...)Executable::unlinkCalls() and CodeBlock::unlinkCalls() are no longer used.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::unlinkCalls): Deleted.
* bytecode/CodeBlock.h:
* runtime/Executable.cpp:
(JSC::EvalExecutable::unlinkCalls): Deleted.
(JSC::ProgramExecutable::unlinkCalls): Deleted.
(JSC::FunctionExecutable::unlinkCalls): Deleted.
* runtime/Executable.h:
(JSC::ScriptExecutable::unlinkCalls): Deleted.
2015-08-25 Brian Burg <bburg@apple.com>
Web Inspector: no need to allocate protocolErrors array for every dispatched backend command
https://bugs.webkit.org/show_bug.cgi?id=146466
Reviewed by Joseph Pecoraro.
Clean up some of the backend dispatcher code, with a focus on eliminating useless allocations
of objects in the common case when no protocol errors happen. This is done by saving the
current id of each request as it is being processed by the backend dispatcher, and tagging any
subsequent errors with that id. This also means we don't have to thread the requestId except
in the async command code path.
This patch also lifts some common code shared between all generated backend command
implementatations into the per-domain dispatch method instead. This reduces generated code size.
To be consistent, this patch standardizes on calling the id of a backend message its 'requestId'.
Requests can be handled synchronously or asynchronously (triggered via the 'async' property).
No new tests, covered by existing protocol tests.
* inspector/InspectorBackendDispatcher.cpp:
(Inspector::BackendDispatcher::CallbackBase::CallbackBase): Split the two code paths for reporting
success and failure.
(Inspector::BackendDispatcher::CallbackBase::sendFailure):
(Inspector::BackendDispatcher::CallbackBase::sendSuccess): Renamed from sendIfActive.
(Inspector::BackendDispatcher::dispatch): Reset counters and current requestId before dispatching.
No need to manually thread the requestId to all reportProtocolError calls.
(Inspector::BackendDispatcher::hasProtocolErrors): Added.
(Inspector::BackendDispatcher::sendResponse):
(Inspector::BackendDispatcher::sendPendingErrors): Send any saved protocol errors to the frontend.
Always send a 'data' member with all of the errors, even if there's just one. We might want to add
more information about errors later.
(Inspector::BackendDispatcher::reportProtocolError): Enqueue a protocol error to be sent later.
(Inspector::BackendDispatcher::getPropertyValue): Remove useless type parameters and nuke most of
the type conversion methods. Use std::function types instead of function pointer types.
(Inspector::castToInteger): Added.
(Inspector::castToNumber): Added.
(Inspector::BackendDispatcher::getInteger):
(Inspector::BackendDispatcher::getDouble):
(Inspector::BackendDispatcher::getString):
(Inspector::BackendDispatcher::getBoolean):
(Inspector::BackendDispatcher::getObject):
(Inspector::BackendDispatcher::getArray):
(Inspector::BackendDispatcher::getValue):
(Inspector::getPropertyValue): Deleted.
(Inspector::AsMethodBridges::asInteger): Deleted.
(Inspector::AsMethodBridges::asDouble): Deleted.
(Inspector::AsMethodBridges::asString): Deleted.
(Inspector::AsMethodBridges::asBoolean): Deleted.
(Inspector::AsMethodBridges::asObject): Deleted.
(Inspector::AsMethodBridges::asArray): Deleted.
(Inspector::AsMethodBridges::asValue): Deleted.
* inspector/InspectorBackendDispatcher.h:
* inspector/scripts/codegen/cpp_generator_templates.py: Extract 'params' object in domain dispatch method.
Omit requestIds where possible. Convert dispatch tables to use NeverDestroyed. Check the protocol error count
to decide whether to abort the dispatch or not, rather than allocating our own errors array.
* inspector/scripts/codegen/cpp_generator_templates.py:
(void):
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py: Revert to passing RefPtr<InspectorObject>
since parameters are now being passed rather than the message object. Some commands do not require parameters.
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
(CppBackendDispatcherImplementationGenerator.generate_output):
(CppBackendDispatcherImplementationGenerator._generate_small_dispatcher_switch_implementation_for_domain):
(CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
* inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
(ObjCBackendDispatcherHeaderGenerator._generate_objc_handler_declaration_for_command):
* inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
(ObjCConfigurationImplementationGenerator._generate_handler_implementation_for_command):
(ObjCConfigurationImplementationGenerator._generate_success_block_for_command):
* inspector/scripts/codegen/objc_generator_templates.py:
Rebaseline some protocol generator tests.
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2015-08-25 Saam barati <sbarati@apple.com>
Lets rename codeOriginIndex to callSiteIndex and get rid of CallFrame::Location.
https://bugs.webkit.org/show_bug.cgi?id=148213
Reviewed by Filip Pizlo.
This patch introduces a struct called CallSiteIndex which is
used as a wrapper for a 32-bit int to place things in the tag for ArgumentCount
in the call frame. On 32-bit we place Instruction* into this slot for LLInt and Basline.
For 32-bit DFG we place a an index into the code origin table in this slot.
On 64-bit we place a bytecode offset into this slot for LLInt and Baseline.
On 64-bit we place the index into the code origin table in this slot in the
DFG/FTL.
This patch also gets rid of the encoding scheme that describes if something is a
bytecode index or a code origin table index. This information can always
be determined based on the CodeBlock's' JITType.
StructureStubInfo now also has a CallSiteIndex which it stores to
the call frame when making a call.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::hasCodeOrigins):
(JSC::CodeBlock::canGetCodeOrigin):
(JSC::CodeBlock::codeOrigin):
(JSC::CodeBlock::addFrequentExitSite):
* bytecode/StructureStubInfo.h:
(JSC::StructureStubInfo::StructureStubInfo):
* dfg/DFGCommonData.cpp:
(JSC::DFG::CommonData::notifyCompilingStructureTransition):
(JSC::DFG::CommonData::addCodeOrigin):
(JSC::DFG::CommonData::shrinkToFit):
* dfg/DFGCommonData.h:
(JSC::DFG::CommonData::CommonData):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::setEndOfCode):
(JSC::DFG::JITCompiler::addCallSite):
(JSC::DFG::JITCompiler::emitStoreCodeOrigin):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileIn):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetById):
(JSC::DFG::SpeculativeJIT::cachedPutById):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetById):
(JSC::DFG::SpeculativeJIT::cachedPutById):
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLInlineCacheDescriptor.h:
(JSC::FTL::InlineCacheDescriptor::InlineCacheDescriptor):
(JSC::FTL::InlineCacheDescriptor::stackmapID):
(JSC::FTL::InlineCacheDescriptor::callSiteIndex):
(JSC::FTL::InlineCacheDescriptor::uid):
(JSC::FTL::GetByIdDescriptor::GetByIdDescriptor):
(JSC::FTL::PutByIdDescriptor::PutByIdDescriptor):
(JSC::FTL::CheckInDescriptor::CheckInDescriptor):
(JSC::FTL::InlineCacheDescriptor::codeOrigin): Deleted.
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
(JSC::FTL::DFG::LowerDFGToLLVM::compileIn):
(JSC::FTL::DFG::LowerDFGToLLVM::getById):
(JSC::FTL::DFG::LowerDFGToLLVM::callPreflight):
* ftl/FTLSlowPathCall.cpp:
(JSC::FTL::storeCodeOrigin):
* interpreter/CallFrame.cpp:
(JSC::CallFrame::currentVPC):
(JSC::CallFrame::setCurrentVPC):
(JSC::CallFrame::callSiteBitsAsBytecodeOffset):
(JSC::CallFrame::bytecodeOffset):
(JSC::CallFrame::codeOrigin):
(JSC::CallFrame::topOfFrameInternal):
(JSC::CallFrame::locationAsBytecodeOffset): Deleted.
(JSC::CallFrame::setLocationAsBytecodeOffset): Deleted.
(JSC::CallFrame::bytecodeOffsetFromCodeOriginIndex): Deleted.
* interpreter/CallFrame.h:
(JSC::CallSiteIndex::CallSiteIndex):
(JSC::CallSiteIndex::bits):
(JSC::ExecState::returnPCOffset):
(JSC::ExecState::abstractReturnPC):
(JSC::ExecState::topOfFrame):
(JSC::ExecState::setCallerFrame):
(JSC::ExecState::setScope):
(JSC::ExecState::currentVPC): Deleted.
(JSC::ExecState::setCurrentVPC): Deleted.
* interpreter/CallFrameInlines.h:
(JSC::CallFrame::callSiteBitsAreBytecodeOffset):
(JSC::CallFrame::callSiteBitsAreCodeOriginIndex):
(JSC::CallFrame::callSiteAsRawBits):
(JSC::CallFrame::callSiteIndex):
(JSC::CallFrame::hasActivation):
(JSC::CallFrame::Location::encode): Deleted.
(JSC::CallFrame::Location::decode): Deleted.
(JSC::CallFrame::Location::encodeAsBytecodeOffset): Deleted.
(JSC::CallFrame::Location::encodeAsBytecodeInstruction): Deleted.
(JSC::CallFrame::Location::encodeAsCodeOriginIndex): Deleted.
(JSC::CallFrame::Location::isBytecodeLocation): Deleted.
(JSC::CallFrame::Location::isCodeOriginIndex): Deleted.
(JSC::CallFrame::hasLocationAsBytecodeOffset): Deleted.
(JSC::CallFrame::hasLocationAsCodeOriginIndex): Deleted.
(JSC::CallFrame::locationAsRawBits): Deleted.
(JSC::CallFrame::setLocationAsRawBits): Deleted.
(JSC::CallFrame::locationAsBytecodeOffset): Deleted.
(JSC::CallFrame::setLocationAsBytecodeOffset): Deleted.
(JSC::CallFrame::locationAsCodeOriginIndex): Deleted.
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::readFrame):
(JSC::StackVisitor::readNonInlinedFrame):
(JSC::StackVisitor::Frame::print):
* jit/JITCall.cpp:
(JSC::JIT::compileOpCall):
* jit/JITCall32_64.cpp:
(JSC::JIT::compileOpCall):
* jit/JITInlineCacheGenerator.cpp:
(JSC::garbageStubInfo):
(JSC::JITInlineCacheGenerator::JITInlineCacheGenerator):
(JSC::JITByIdGenerator::JITByIdGenerator):
(JSC::JITByIdGenerator::generateFastPathChecks):
(JSC::JITGetByIdGenerator::JITGetByIdGenerator):
(JSC::JITGetByIdGenerator::generateFastPath):
(JSC::JITPutByIdGenerator::JITPutByIdGenerator):
* jit/JITInlineCacheGenerator.h:
(JSC::JITInlineCacheGenerator::JITInlineCacheGenerator):
(JSC::JITInlineCacheGenerator::stubInfo):
(JSC::JITByIdGenerator::JITByIdGenerator):
(JSC::JITGetByIdGenerator::JITGetByIdGenerator):
(JSC::JITPutByIdGenerator::JITPutByIdGenerator):
* jit/JITInlines.h:
(JSC::JIT::updateTopCallFrame):
* jit/JITOperations.cpp:
(JSC::getByVal):
(JSC::tryGetByValOptimize):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitGetByValWithCachedId):
(JSC::JIT::emitPutByValWithCachedId):
(JSC::JIT::emit_op_get_by_id):
(JSC::JIT::emit_op_put_by_id):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emitGetByValWithCachedId):
(JSC::JIT::emitPutByValWithCachedId):
(JSC::JIT::emit_op_get_by_id):
(JSC::JIT::emit_op_put_by_id):
* jit/Repatch.cpp:
(JSC::generateByIdStub):
2015-08-25 Aleksandr Skachkov <gskachkov@gmail.com>
Function.prototype.toString is incorrect for ArrowFunction
https://bugs.webkit.org/show_bug.cgi?id=148148
Reviewed by Saam Barati.
Added correct support of toString() method for arrow function.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionMetadata):
(JSC::ASTBuilder::createArrowFunctionExpr):
* parser/Nodes.cpp:
(JSC::FunctionMetadataNode::FunctionMetadataNode):
* parser/Nodes.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionBody):
(JSC::Parser<LexerType>::parseFunctionInfo):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionMetadata):
* runtime/FunctionPrototype.cpp:
(JSC::functionProtoFuncToString):
* tests/stress/arrowfunction-tostring.js: Added.
2015-08-25 Saam barati <sbarati@apple.com>
Callee can be incorrectly overridden when it's captured
https://bugs.webkit.org/show_bug.cgi?id=148400
Reviewed by Filip Pizlo.
We now resort to always creating the function name scope
when the function name is in scope. Because the bytecode
generator now has a notion of local lexical scoping,
this incurs no runtime penalty for function expression names
that aren't heap allocated. If they are heap allocated,
this means we may now have one more scope on the runtime
scope stack than before. This modification simplifies the
callee initialization code and uses the lexical scoping constructs
to implement this. This implementation also ensures
that everything Just Works for function's with default
parameter values. Before this patch, IIFE functions
with default parameter values and a captured function
name would crash JSC.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::pushLexicalScopeInternal):
(JSC::BytecodeGenerator::popLexicalScopeInternal):
(JSC::BytecodeGenerator::variable):
(JSC::BytecodeGenerator::resolveType):
(JSC::BytecodeGenerator::emitThrowTypeError):
(JSC::BytecodeGenerator::emitPushFunctionNameScope):
(JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
* bytecompiler/BytecodeGenerator.h:
(JSC::Variable::isReadOnly):
(JSC::Variable::isSpecial):
(JSC::Variable::isConst):
(JSC::Variable::setIsReadOnly):
* bytecompiler/NodesCodegen.cpp:
(JSC::PostfixNode::emitResolve):
(JSC::PrefixNode::emitResolve):
(JSC::ReadModifyResolveNode::emitBytecode):
(JSC::AssignResolveNode::emitBytecode):
(JSC::BindingNode::bindValue):
* tests/stress/IIFE-es6-default-parameters.js: Added.
(assert):
(.):
* tests/stress/IIFE-function-name-captured.js: Added.
(assert):
(.):
2015-08-24 Brian Burg <bburg@apple.com>
Web Inspector: add protocol test for existing error handling performed by the backend
https://bugs.webkit.org/show_bug.cgi?id=147097
Reviewed by Joseph Pecoraro.
A new test revealed that the protocol "method" parameter was being parsed in a naive way.
Rewrite it to use String::split and improve error checking to avoid failing later.
* inspector/InspectorBackendDispatcher.cpp:
(Inspector::BackendDispatcher::dispatch):
2015-08-24 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Return JSInternalPromise as result of evaluateModule
https://bugs.webkit.org/show_bug.cgi?id=148173
Reviewed by Saam Barati.
Now evaluateModule returns JSInternalPromise* as its result value.
When an error occurs while loading or executing the modules,
this promise is rejected by that error. By leveraging this, we implemented
asynchronous error reporting when executing the modules in JSC shell.
And this patch also changes the evaluateModule signature to accept the entry
point by the moduleName. By using it, JSC shell can start executing the modules
with the entry point module name.
* builtins/ModuleLoaderObject.js:
(loadModule):
* jsc.cpp:
(dumpException):
(runWithScripts):
* runtime/Completion.cpp:
(JSC::evaluateModule):
* runtime/Completion.h:
* runtime/JSInternalPromise.cpp:
(JSC::JSInternalPromise::then):
* runtime/JSInternalPromise.h:
* runtime/ModuleLoaderObject.cpp:
(JSC::ModuleLoaderObject::requestInstantiateAll):
(JSC::ModuleLoaderObject::loadModule):
(JSC::ModuleLoaderObject::resolve):
(JSC::ModuleLoaderObject::fetch):
(JSC::ModuleLoaderObject::translate):
(JSC::ModuleLoaderObject::instantiate):
(JSC::moduleLoaderObjectParseModule):
* runtime/ModuleLoaderObject.h:
2015-08-24 Basile Clement <basile_clement@apple.com>
REPTACH is not a word
https://bugs.webkit.org/show_bug.cgi?id=148401
Reviewed by Saam Barati.
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::callWithSlowPathReturnType):
(JSC::MacroAssemblerX86_64::call):
(JSC::MacroAssemblerX86_64::tailRecursiveCall):
(JSC::MacroAssemblerX86_64::makeTailRecursiveCall):
(JSC::MacroAssemblerX86_64::readCallTarget):
(JSC::MacroAssemblerX86_64::linkCall):
(JSC::MacroAssemblerX86_64::repatchCall):
2015-08-24 Mark Lam <mark.lam@apple.com>
Add support for setting JSC options from a file.
https://bugs.webkit.org/show_bug.cgi?id=148394
Reviewed by Saam Barati.
This is needed for environments where the JSC executable does not have access to
environmental variables. This is only needed for debugging, and is currently
guarded under a #define USE_OPTIONS_FILE in Options.cpp, and is disabled by
default.
Also fixed Options::setOptions() to be allow for whitespace that is not a single
' '. This makes setOptions() much more flexible and friendlier to use for loading
options in general.
For example, this current use case of loading options from a file may have '\n's
in the character stream, and this feature is easier to implement if setOptions()
just support more than 1 whitespace char between options, and recognize whitespace
characters other than ' '.
* runtime/Options.cpp:
(JSC::parse):
(JSC::Options::initialize):
(JSC::Options::setOptions):
2015-08-24 Filip Pizlo <fpizlo@apple.com>
DFG::FixupPhase should use the lambda form of m_graph.doToChildren() rather than the old macro
https://bugs.webkit.org/show_bug.cgi?id=148397
Reviewed by Geoffrey Garen.
We used to iterate the edges of a node by using the DFG_NODE_DO_TO_CHILDREN macro. We
don't need to do that anymore since we have the lambda-based m_graph.doToChildren(). This
allows us to get rid of a bunch of helper methods in DFG::FixupPhase.
I also took the opportunity to give the injectTypeConversionsInBlock() method a more
generic name, since after https://bugs.webkit.org/show_bug.cgi?id=145204 it will be used
for fix-up of checks more broadly.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::run):
(JSC::DFG::FixupPhase::attemptToMakeGetTypedArrayByteOffset):
(JSC::DFG::FixupPhase::fixupChecksInBlock):
(JSC::DFG::FixupPhase::injectTypeConversionsInBlock): Deleted.
(JSC::DFG::FixupPhase::tryToRelaxRepresentation): Deleted.
(JSC::DFG::FixupPhase::fixEdgeRepresentation): Deleted.
(JSC::DFG::FixupPhase::injectTypeConversionsForEdge): Deleted.
2015-08-24 Geoffrey Garen <ggaren@apple.com>
Some renaming to clarify CodeBlock and UnlinkedCodeBlock
https://bugs.webkit.org/show_bug.cgi?id=148391
Reviewed by Saam Barati.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::generateUnlinkedFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::visitChildren):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
(JSC::generateFunctionCodeBlock): Deleted.
(JSC::UnlinkedFunctionExecutable::codeBlockFor): Deleted.
* bytecode/UnlinkedFunctionExecutable.h: Call our CodeBlocks "unlinked"
in the name for clarity, since we are unlinked.
* heap/Heap.cpp:
(JSC::Heap::objectTypeCounts):
(JSC::Heap::deleteAllCodeBlocks):
(JSC::Heap::deleteAllUnlinkedCodeBlocks):
(JSC::Heap::clearUnmarkedExecutables):
(JSC::Heap::deleteOldCode):
(JSC::Heap::FinalizerOwner::finalize):
(JSC::Heap::addExecutable):
(JSC::Heap::collectAllGarbageIfNotDoneRecently):
(JSC::Heap::deleteAllCompiledCode): Deleted.
(JSC::Heap::deleteAllUnlinkedFunctionCode): Deleted.
(JSC::Heap::addCompiledCode): Deleted.
* heap/Heap.h:
(JSC::Heap::notifyIsSafeToCollect):
(JSC::Heap::isSafeToCollect):
(JSC::Heap::sizeBeforeLastFullCollection):
(JSC::Heap::sizeAfterLastFullCollection):
(JSC::Heap::compiledCode): Deleted.
deleteAllCompiledCode => deleteAllCodeBlocks because "compiled"
is a broad phrase these days.
m_compiledCode => m_executables for the same reason.
addCompiledCode => addExecutable for the same reason.
deleteAllUnlinkedFunctionCode => deleteAllUnlinkedCodeBlocks
for consistency.
* jsc.cpp:
(functionDeleteAllCompiledCode):
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor): codeBlockFor => unlinkedCodeBlockFor
(JSC::FunctionExecutable::clearUnlinkedCodeForRecompilation): Deleted.
It was strange to put this function on executable, since its name implied
that it only changed the executable, but it actually changed all cached
code. Now, a client that wants to change cached code must do so explicitly.
* runtime/Executable.h:
(JSC::ScriptExecutable::finishCreation):
* runtime/VM.cpp:
(JSC::VM::deleteAllCode):
* runtime/VMEntryScope.cpp:
(JSC::VMEntryScope::VMEntryScope): Updated for renames above.
2015-08-22 Filip Pizlo <fpizlo@apple.com>
DFG::InsertionSet should be tolerant of occasional out-of-order insertions
https://bugs.webkit.org/show_bug.cgi?id=148367
Reviewed by Geoffrey Garen and Saam Barati.
Since forever, the DFG::InsertionSet has been the way we insert nodes into DFG IR, and it
requires that you walk a block in order and perform insertions in order: you can't insert
something at index J, then at index I where I < J, except if you do a second pass.
This restriction makes sense, because it enables a very fast algorithm. And it's very
rare that a phase would need to insert things out of order.
But sometimes - rarely - we need to insert things slightly out-of-order. For example we
may want to insert a node at index J, but to insert a check associated with that node, we
may need to use index I where I < J. This will come up from the work on
https://bugs.webkit.org/show_bug.cgi?id=145204. And it has already come up in the past.
It seems like it would be best to just lift this restriction.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGInsertionSet.cpp: Added.
(JSC::DFG::InsertionSet::insertSlow):
* dfg/DFGInsertionSet.h:
(JSC::DFG::InsertionSet::InsertionSet):
(JSC::DFG::InsertionSet::graph):
(JSC::DFG::InsertionSet::insert):
(JSC::DFG::InsertionSet::execute):
2015-08-24 Yusuke Suzuki <utatane.tea@gmail.com>
Create ById IC for ByVal operation only when the specific Id comes more than once
https://bugs.webkit.org/show_bug.cgi?id=148288
Reviewed by Geoffrey Garen.
After introducing byId ICs into byVal ops, byVal ops creates much ICs than before.
The failure fixed in r188767 figures out these ICs are created even if this op is executed only once.
The situation is the following;
In the current code, when byVal op is executed with the Id, we immediately set up the byId IC for that byVal op.
But setting up JITGetByIdGenerator generates the fast path IC code and consumes executable memory.
As a result, if we call eval("contains byVal ops") with the different strings repeatedly under no-llint environment, each eval call creates byId IC for byVal and consumes executable memory.
To solve it, we will add "seen" flag to ByValInfo.
And we will create the IC on the second byVal op call with the same Id.
* bytecode/ByValInfo.h:
(JSC::ByValInfo::ByValInfo):
* jit/JITOperations.cpp:
(JSC::tryGetByValOptimize):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::privateCompileGetByValWithCachedId): Deleted.
(JSC::JIT::privateCompilePutByValWithCachedId): Deleted.
2015-08-23 Benjamin Poulain <bpoulain@apple.com>
[JSC] Get rid of NodePointerTraits
https://bugs.webkit.org/show_bug.cgi?id=148340
Reviewed by Anders Carlsson.
NodePointerTraits does exactly the same thing has the default trait.
* dfg/DFGBasicBlock.h:
* dfg/DFGCommon.h:
(JSC::DFG::NodePointerTraits::defaultValue): Deleted.
(JSC::DFG::NodePointerTraits::isEmptyForDump): Deleted.
2015-08-23 Benjamin Poulain <bpoulain@apple.com>
[JSC] Reduce the memory usage of BytecodeLivenessAnalysis
https://bugs.webkit.org/show_bug.cgi?id=148353
Reviewed by Darin Adler.
BytecodeLivenessAnalysis easily takes kilobytes of memory for
non trivial blocks and that memory sticks around because
it stored on CodeBlock.
This patch reduces that memory use a bit.
Most of the memory is in the array of BytecodeBasicBlock.
BytecodeBasicBlock is shrunk by:
-Making it not ref-counted.
-Removing m_predecessors, it was only used for debugging and
is usually big.
-Added a shrinkToFit() phase to shrink the vectors once we are
done building the BytecodeBasicBlock.
There are more things we should do in the future:
-Store all the BytecodeBasicBlock direclty in the array.
We know the size ahead of time, this would be a pure win.
The only tricky part is changing m_successors to have the
index of the successor instead of a pointer.
-Stop putting duplicates in m_successors.
* bytecode/BytecodeBasicBlock.cpp:
(JSC::computeBytecodeBasicBlocks):
(JSC::BytecodeBasicBlock::shrinkToFit): Deleted.
(JSC::linkBlocks): Deleted.
* bytecode/BytecodeBasicBlock.h:
(JSC::BytecodeBasicBlock::addSuccessor):
(JSC::BytecodeBasicBlock::addPredecessor): Deleted.
(JSC::BytecodeBasicBlock::predecessors): Deleted.
* bytecode/BytecodeLivenessAnalysis.cpp:
(JSC::getLeaderOffsetForBasicBlock):
(JSC::findBasicBlockWithLeaderOffset):
(JSC::findBasicBlockForBytecodeOffset):
(JSC::stepOverInstruction):
(JSC::computeLocalLivenessForBytecodeOffset):
(JSC::computeLocalLivenessForBlock):
(JSC::BytecodeLivenessAnalysis::dumpResults): Deleted.
* bytecode/BytecodeLivenessAnalysis.h:
2015-08-23 Geoffrey Garen <ggaren@apple.com>
Unreviewed, rolling back in r188792.
https://bugs.webkit.org/show_bug.cgi?id=148347
Previously reverted changesets:
"Unify code paths for manually deleting all code"
https://bugs.webkit.org/show_bug.cgi?id=148280
http://trac.webkit.org/changeset/188792
The previous patch caused some inspector tests to hang because it
introduced extra calls to sourceParsed, and sourceParsed is
pathologically slow in WK1 debug builds. This patch restores pre-existing
code to limit calls to sourceParsed, excluding code not being debugged
(i.e., inspector code).
2015-08-23 Geoffrey Garen <ggaren@apple.com>
Unreviewed, rolling back in r188803.
Previously reverted changesets:
"Debugger's VM should never be null"
https://bugs.webkit.org/show_bug.cgi?id=148341
http://trac.webkit.org/changeset/188803
* debugger/Debugger.cpp:
(JSC::Debugger::Debugger):
(JSC::Debugger::attach):
(JSC::Debugger::detach):
(JSC::Debugger::isAttached):
(JSC::Debugger::setSteppingMode):
(JSC::Debugger::registerCodeBlock):
(JSC::Debugger::toggleBreakpoint):
(JSC::Debugger::recompileAllJSFunctions):
(JSC::Debugger::setBreakpoint):
(JSC::Debugger::clearBreakpoints):
(JSC::Debugger::clearDebuggerRequests):
(JSC::Debugger::setBreakpointsActivated):
(JSC::Debugger::breakProgram):
(JSC::Debugger::stepOutOfFunction):
(JSC::Debugger::returnEvent):
(JSC::Debugger::didExecuteProgram):
* debugger/Debugger.h:
* inspector/JSGlobalObjectScriptDebugServer.cpp:
(Inspector::JSGlobalObjectScriptDebugServer::JSGlobalObjectScriptDebugServer):
(Inspector::JSGlobalObjectScriptDebugServer::removeListener):
(Inspector::JSGlobalObjectScriptDebugServer::runEventLoopWhilePaused):
(Inspector::JSGlobalObjectScriptDebugServer::recompileAllJSFunctions): Deleted.
* inspector/JSGlobalObjectScriptDebugServer.h:
* inspector/ScriptDebugServer.cpp:
(Inspector::ScriptDebugServer::ScriptDebugServer):
* inspector/ScriptDebugServer.h:
2015-08-22 Filip Pizlo <fpizlo@apple.com>
DFG string concatenation shouldn't be playing fast and loose with effects and OSR exit
https://bugs.webkit.org/show_bug.cgi?id=148338
Reviewed by Michael Saboff and Saam Barati.
Prior to this change, DFG string concatenation appeared to have various different ways of
creating an OSR exit right after a side effect. That's bad, because the exit will cause
us to reexecute the side effect. The code appears to have some hacks for avoiding this,
but some cases are basically unavoidable, like the OOM case of string concatenation: in
trunk that could cause two executions of the toString operation.
This changes the string concatenation code to either be speculative or effectful but
never both. It's already the case that when this code needs to be effectful, it also
needs to be slow (it does int->string conversions, calls JS functions, etc). So, this is
a small price to pay for sanity.
The biggest part of this change is the introduction of StrCat, which is like MakeRope but
does toString conversions on its own instead of relying on separate nodes. StrCat can
take either 2 or 3 children. It's the effectful but not speculative version of MakeRope.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::convertStringAddUse):
(JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor):
(JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
(JSC::DFG::FixupPhase::canOptimizeStringObjectAccess):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
(JSC::DFG::JSValueOperand::JSValueOperand):
(JSC::DFG::JSValueOperand::~JSValueOperand):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::validate):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLIntrinsicRepository.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
(JSC::FTL::DFG::LowerDFGToLLVM::compileValueAdd):
(JSC::FTL::DFG::LowerDFGToLLVM::compileStrCat):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
* jit/JITOperations.h:
* tests/stress/exception-effect-strcat.js: Added. This test previously failed.
* tests/stress/exception-in-strcat-string-overflow.js: Added. An earlier version of this patch made this fail.
* tests/stress/exception-in-strcat.js: Added.
2015-08-22 Andreas Kling <akling@apple.com>
[JSC] Static hash tables should be 100% compile-time constant.
<https://webkit.org/b/148359>
Reviewed by Michael Saboff.
We were dirtying the memory pages containing static hash tables the
first time they were used, when a dynamically allocated index-to-key
table was built and cached in the HashTable struct.
It turns out that this "optimization" was completely useless, since
we've long since decoupled static hash tables from the JSC::VM and
we can get the key for an index via HashTable::values[index].m_key!
We also get rid of VM::keywords which was a little wrapper around
a VM-specific copy of JSC::mainTable. There was nothing VM-specific
about it at all, so clients now use JSC::mainTable directly.
After this change all fooHashTable structs end up in __DATA __const
and no runtime initialization/allocation takes place.
* create_hash_table:
* jsc.cpp:
* parser/Lexer.cpp:
(JSC::isLexerKeyword):
(JSC::Lexer<LChar>::parseIdentifier):
(JSC::Lexer<UChar>::parseIdentifier):
(JSC::Lexer<CharacterType>::parseIdentifierSlowCase):
(JSC::Keywords::Keywords): Deleted.
* parser/Lexer.h:
(JSC::Keywords::isKeyword): Deleted.
(JSC::Keywords::getKeyword): Deleted.
(JSC::Keywords::~Keywords): Deleted.
* runtime/LiteralParser.cpp:
(JSC::LiteralParser<CharType>::tryJSONPParse):
* runtime/Lookup.cpp:
(JSC::HashTable::createTable): Deleted.
(JSC::HashTable::deleteTable): Deleted.
* runtime/Lookup.h:
(JSC::HashTable::entry):
(JSC::HashTable::ConstIterator::key):
(JSC::HashTable::ConstIterator::skipInvalidKeys):
(JSC::HashTable::copy): Deleted.
(JSC::HashTable::initializeIfNeeded): Deleted.
(JSC::HashTable::begin): Deleted.
(JSC::HashTable::end): Deleted.
* runtime/VM.cpp:
(JSC::VM::VM): Deleted.
* runtime/VM.h:
* testRegExp.cpp:
2015-08-21 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r188792 and r188803.
https://bugs.webkit.org/show_bug.cgi?id=148347
broke lots of tests, ggaren is going to investigate and reland
(Requested by thorton on #webkit).
Reverted changesets:
"Unify code paths for manually deleting all code"
https://bugs.webkit.org/show_bug.cgi?id=148280
http://trac.webkit.org/changeset/188792
"Debugger's VM should never be null"
https://bugs.webkit.org/show_bug.cgi?id=148341
http://trac.webkit.org/changeset/188803
2015-08-21 Sukolsak Sakshuwong <sukolsak@gmail.com>
Parse control flow statements in WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=148333
Reviewed by Geoffrey Garen.
Parse control flow statements in WebAssembly files generated by pack-asmjs
<https://github.com/WebAssembly/polyfill-prototype-1>.
* wasm/WASMConstants.h:
* wasm/WASMFunctionParser.cpp:
(JSC::WASMFunctionParser::parseStatement):
(JSC::WASMFunctionParser::parseIfStatement):
(JSC::WASMFunctionParser::parseIfElseStatement):
(JSC::WASMFunctionParser::parseWhileStatement):
(JSC::WASMFunctionParser::parseDoStatement):
(JSC::WASMFunctionParser::parseLabelStatement):
(JSC::WASMFunctionParser::parseBreakStatement):
(JSC::WASMFunctionParser::parseBreakLabelStatement):
(JSC::WASMFunctionParser::parseContinueStatement):
(JSC::WASMFunctionParser::parseContinueLabelStatement):
(JSC::WASMFunctionParser::parseSwitchStatement):
* wasm/WASMFunctionParser.h:
(JSC::WASMFunctionParser::WASMFunctionParser):
* wasm/WASMReader.cpp:
(JSC::WASMReader::readCompactInt32):
(JSC::WASMReader::readSwitchCase):
* wasm/WASMReader.h:
2015-08-21 Geoffrey Garen <ggaren@apple.com>
Debugger's VM should never be null
https://bugs.webkit.org/show_bug.cgi?id=148341
Reviewed by Joseph Pecoraro.
It doesn't make sense for a Debugger's VM to be null, and code related
to maintaining that illusion just caused the Web Inspector to crash on
launch (https://bugs.webkit.org/show_bug.cgi?id=148312). So, let's stop
doing that.
Now, Debugger requires its subclass to provide a never-null VM&.
Also took the opportunity, based on review feedback, to remove some
confusion in the virtual recompileAllJSFunctions hierarchy, by eliminating
the pure virtual in ScriptDebugServer and the unnecessary override in
JSGlobalObjectScriptDebugServer.
* debugger/Debugger.cpp:
(JSC::Debugger::Debugger):
(JSC::Debugger::attach):
(JSC::Debugger::detach):
(JSC::Debugger::isAttached):
(JSC::Debugger::setSteppingMode):
(JSC::Debugger::registerCodeBlock):
(JSC::Debugger::toggleBreakpoint):
(JSC::Debugger::recompileAllJSFunctions):
(JSC::Debugger::setBreakpoint):
(JSC::Debugger::clearBreakpoints):
(JSC::Debugger::clearDebuggerRequests):
(JSC::Debugger::setBreakpointsActivated):
(JSC::Debugger::breakProgram):
(JSC::Debugger::stepOutOfFunction):
(JSC::Debugger::returnEvent):
(JSC::Debugger::didExecuteProgram):
* debugger/Debugger.h:
* inspector/JSGlobalObjectScriptDebugServer.cpp:
(Inspector::JSGlobalObjectScriptDebugServer::JSGlobalObjectScriptDebugServer):
(Inspector::JSGlobalObjectScriptDebugServer::recompileAllJSFunctions):
(Inspector::JSGlobalObjectScriptDebugServer::runEventLoopWhilePaused):
* inspector/ScriptDebugServer.cpp:
(Inspector::ScriptDebugServer::ScriptDebugServer):
* inspector/ScriptDebugServer.h:
2015-08-21 Basile Clement <basile_clement@apple.com>
Remove unused code relative to allocation sinking
https://bugs.webkit.org/show_bug.cgi?id=148342
Reviewed by Mark Lam.
This removes two things:
- The DFGPromoteHeapAccess.h file which is a relic of the old sinking
phase and is no longer used (it has been subsumed by
ObjectAllocationSinking::promoteLocalHeap)
- Code in the allocation sinking phase for sinking
MaterializeCreateActivation and MaterializeNewObject. Handling those
is no longer necessary since the phase no longer runs in a fixpoint
and thus will never see those nodes, since no other phase creates
them.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* dfg/DFGPromoteHeapAccess.h: Removed.
2015-08-21 Geoffrey Garen <ggaren@apple.com>
Unify code paths for manually deleting all code
https://bugs.webkit.org/show_bug.cgi?id=148280
Reviewed by Saam Barati.
We used to have three paths for manually deleting all code. Now we have
one shared path.
* debugger/Debugger.cpp:
(JSC::Debugger::attach): Notify the debugger of all previous code when
it attaches. We used to do this when recompiling, which was only correct
by accident.
(JSC::Debugger::recompileAllJSFunctions): Switch to the shared path.
* heap/Heap.h:
(JSC::Heap::compiledCode):
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
(Inspector::InspectorRuntimeAgent::willDestroyFrontendAndBackend):
(Inspector::InspectorRuntimeAgent::setTypeProfilerEnabledState):
(Inspector::InspectorRuntimeAgent::getBasicBlocks):
(Inspector::TypeRecompiler::visit): Deleted.
(Inspector::TypeRecompiler::operator()): Deleted.
(Inspector::recompileAllJSFunctionsForTypeProfiling): Deleted. Switch
to the shared path.
* runtime/VM.cpp:
(JSC::VM::afterVMExit): Added a helper for scheduling an activity after
VM exit. We can't delete code while it's on the stack, and we can't
delete auxiliary profiling data while profiling code is on the stack,
so in those cases, we schedule the deletion for the next time we exit.
(JSC::VM::deleteAllCode): Use afterVMExit because we might have code
on the stack when debugger, profiler, or watchdog state changes.
* runtime/VM.h:
* runtime/VMEntryScope.cpp:
(JSC::VMEntryScope::VMEntryScope):
(JSC::VMEntryScope::addDidPopListener):
(JSC::VMEntryScope::~VMEntryScope):
(JSC::VMEntryScope::setEntryScopeDidPopListener): Deleted.
* runtime/VMEntryScope.h:
(JSC::VMEntryScope::globalObject): Removed the uniquing feature from
the scope pop listener list because we don't have a client that wants
it, and it's not convenient to use correctly since you can't take
the address of a member function, a lambda, or an std::function. We can
add this feature back if we discover that we want it.
2015-08-21 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement WebAssembly function parser
https://bugs.webkit.org/show_bug.cgi?id=147738
Reviewed by Filip Pizlo.
Implement WebAssembly function parser for WebAssembly files produced by pack-asmjs
<https://github.com/WebAssembly/polyfill-prototype-1>. This patch parses only
some instructions on statements and int32 expressions. Parsing of the rest
will be implemented in subsequent patches. The instruction lists in WASMConstants.h
are slightly modified from
<https://github.com/WebAssembly/polyfill-prototype-1/blob/master/src/shared.h>.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* wasm/WASMConstants.h: Added.
* wasm/WASMFormat.h:
* wasm/WASMFunctionParser.cpp: Added.
(JSC::WASMFunctionParser::checkSyntax):
(JSC::WASMFunctionParser::parseFunction):
(JSC::WASMFunctionParser::parseLocalVariables):
(JSC::WASMFunctionParser::parseStatement):
(JSC::WASMFunctionParser::parseSetLocalStatement):
(JSC::WASMFunctionParser::parseReturnStatement):
(JSC::WASMFunctionParser::parseBlockStatement):
(JSC::WASMFunctionParser::parseExpression):
(JSC::WASMFunctionParser::parseExpressionI32):
(JSC::WASMFunctionParser::parseImmediateExpressionI32):
* wasm/WASMFunctionParser.h: Added.
(JSC::WASMFunctionParser::WASMFunctionParser):
* wasm/WASMFunctionSyntaxChecker.h: Renamed from Source/JavaScriptCore/wasm/WASMMagicNumber.h.
* wasm/WASMModuleParser.cpp:
(JSC::WASMModuleParser::WASMModuleParser):
(JSC::WASMModuleParser::parseFunctionDefinitionSection):
(JSC::WASMModuleParser::parseFunctionDefinition):
* wasm/WASMModuleParser.h:
* wasm/WASMReader.cpp:
(JSC::WASMReader::readType):
(JSC::WASMReader::readExpressionType):
(JSC::WASMReader::readExportFormat):
(JSC::WASMReader::readOpStatement):
(JSC::WASMReader::readOpExpressionI32):
(JSC::WASMReader::readVariableTypes):
(JSC::WASMReader::readOp):
* wasm/WASMReader.h:
(JSC::WASMReader::offset):
(JSC::WASMReader::setOffset):
2015-08-21 Filip Pizlo <fpizlo@apple.com>
DFG::PutStackSinkingPhase doesn't need to emit KillStack nodes
https://bugs.webkit.org/show_bug.cgi?id=148331
Reviewed by Geoffrey Garen.
PutStackSinkingPhase previously emitted a KillStack node when it sank a PutStack. This
isn't necessary because KillStack is only interesting for OSR exit, and PutStack nodes
that are relevant to OSR will already be preceded by a KillStack/MovHint pair.
* dfg/DFGPutStackSinkingPhase.cpp:
2015-08-21 Filip Pizlo <fpizlo@apple.com>
DFG::NodeOrigin should have a flag determining if exiting is OK right now
https://bugs.webkit.org/show_bug.cgi?id=148323
Reviewed by Saam Barati.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::currentNodeOrigin):
(JSC::DFG::ByteCodeParser::branchData):
* dfg/DFGInsertionSet.h:
(JSC::DFG::InsertionSet::insertConstant):
(JSC::DFG::InsertionSet::insertConstantForUse):
(JSC::DFG::InsertionSet::insertBottomConstantForUse):
* dfg/DFGIntegerCheckCombiningPhase.cpp:
(JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
* dfg/DFGLICMPhase.cpp:
(JSC::DFG::LICMPhase::attemptHoist):
* dfg/DFGNodeOrigin.h:
(JSC::DFG::NodeOrigin::NodeOrigin):
(JSC::DFG::NodeOrigin::isSet):
(JSC::DFG::NodeOrigin::withSemantic):
* dfg/DFGObjectAllocationSinkingPhase.cpp:
2015-08-21 Saam barati <sbarati@apple.com>
DFG callOperations should not implicitly emit an exception check. At callOperation call sites, we should explicitly emit exception checks
https://bugs.webkit.org/show_bug.cgi?id=147988
Reviewed by Geoffrey Garen.
This is in preparation for the DFG being able to handle exceptions.
To do this, we need more control over when we emit exception checks.
Specifically, we want to be able to silentFill before emitting an exception check.
This patch does that. This patch also allows us to easily see which
operations do and do not emit exception checks. Finding this information
out before was a pain.
* assembler/AbortReason.h:
* dfg/DFGArrayifySlowPathGenerator.h:
* dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
* dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h:
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::appendCall):
(JSC::DFG::JITCompiler::exceptionCheck):
* dfg/DFGSaneStringGetByValSlowPathGenerator.h:
* dfg/DFGSlowPathGenerator.h:
(JSC::DFG::CallSlowPathGenerator::CallSlowPathGenerator):
(JSC::DFG::CallSlowPathGenerator::tearDown):
(JSC::DFG::CallResultAndNoArgumentsSlowPathGenerator::CallResultAndNoArgumentsSlowPathGenerator):
(JSC::DFG::CallResultAndOneArgumentSlowPathGenerator::CallResultAndOneArgumentSlowPathGenerator):
(JSC::DFG::CallResultAndTwoArgumentsSlowPathGenerator::CallResultAndTwoArgumentsSlowPathGenerator):
(JSC::DFG::CallResultAndThreeArgumentsSlowPathGenerator::CallResultAndThreeArgumentsSlowPathGenerator):
(JSC::DFG::CallResultAndFourArgumentsSlowPathGenerator::CallResultAndFourArgumentsSlowPathGenerator):
(JSC::DFG::CallResultAndFiveArgumentsSlowPathGenerator::CallResultAndFiveArgumentsSlowPathGenerator):
(JSC::DFG::slowPathCall):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileIn):
(JSC::DFG::SpeculativeJIT::compileCurrentBlock):
(JSC::DFG::SpeculativeJIT::compileValueToInt32):
(JSC::DFG::SpeculativeJIT::compileArithRound):
(JSC::DFG::SpeculativeJIT::compileNewFunction):
(JSC::DFG::SpeculativeJIT::compileCreateActivation):
(JSC::DFG::SpeculativeJIT::compileCreateScopedArguments):
(JSC::DFG::SpeculativeJIT::compileCreateClonedArguments):
(JSC::DFG::SpeculativeJIT::compileNotifyWrite):
(JSC::DFG::SpeculativeJIT::compileRegExpExec):
(JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
(JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
(JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
(JSC::DFG::SpeculativeJIT::emitSwitchImm):
(JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
(JSC::DFG::SpeculativeJIT::callOperationWithCallFrameRollbackOnException):
(JSC::DFG::SpeculativeJIT::prepareForExternalCall):
(JSC::DFG::SpeculativeJIT::appendCall):
(JSC::DFG::SpeculativeJIT::appendCallWithCallFrameRollbackOnException):
(JSC::DFG::SpeculativeJIT::appendCallWithCallFrameRollbackOnExceptionSetResult):
(JSC::DFG::SpeculativeJIT::appendCallSetResult):
(JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheck): Deleted.
(JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheckSetResult): Deleted.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
(JSC::DFG::CompareAndBoxBooleanSlowPathGenerator::CompareAndBoxBooleanSlowPathGenerator):
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
(JSC::DFG::SpeculativeJIT::emitCall):
(JSC::DFG::SpeculativeJIT::compileLogicalNot):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
(JSC::DFG::CompareAndBoxBooleanSlowPathGenerator::CompareAndBoxBooleanSlowPathGenerator):
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
(JSC::DFG::SpeculativeJIT::emitCall):
(JSC::DFG::SpeculativeJIT::compileLogicalNot):
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLIntrinsicRepository.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::jitAssertArgumentCountSane):
(JSC::AssemblyHelpers::jitAssertNoException):
(JSC::AssemblyHelpers::callExceptionFuzz):
(JSC::AssemblyHelpers::emitExceptionCheck):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::jitAssertIsInt32):
(JSC::AssemblyHelpers::jitAssertIsJSInt32):
(JSC::AssemblyHelpers::jitAssertIsNull):
(JSC::AssemblyHelpers::jitAssertTagsInPlace):
(JSC::AssemblyHelpers::jitAssertArgumentCountSane):
(JSC::AssemblyHelpers::jitAssertNoException):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* runtime/VM.h:
(JSC::VM::scratchBufferForSize):
(JSC::VM::exceptionFuzzingBuffer):
2015-08-21 Geoffrey Garen <ggaren@apple.com>
REGRESSION (r188714): RELEASE_ASSERT in JSC::Heap::incrementDeferralDepth() opening Web Inspector on daringfireball.net
https://bugs.webkit.org/show_bug.cgi?id=148312
Reviewed by Mark Lam.
* debugger/Debugger.cpp:
(JSC::Debugger::recompileAllJSFunctions): Use our vm argument instead of
m_vm because sometimes they are different and m_vm is null. (This behavior
is very strange, and we should probably eliminate it -- but we need a
fix for this serious regression right now.)
2015-08-20 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] prototyping module loader in JSC shell
https://bugs.webkit.org/show_bug.cgi?id=147876
Reviewed by Saam Barati.
This patch implements ES6 Module Loader part. The implementation is based on
the latest draft[1, 2]. The naive implementation poses several problems.
This patch attempts to solve the spec issues and proposes the fix[3, 4, 5].
We construct the JSC internal module loader based on the ES6 Promises.
The chain of the promises represents the dependency graph of the modules and
it automatically enables asynchronous module fetching.
To leverage the Promises internally, we use the InternalPromise landed in r188681.
The loader has several platform-dependent hooks. The platform can implement
these hooks to provide the functionality missing in the module loaders, like
"how to fetch the resources". The method table of the JSGlobalObject is extended
to accept these hooks from the platform.
This patch focus on the loading part. So we don't create the module environment
and don't link the modules yet.
To test the current module progress easily, we add the `-m` option to the JSC shell.
When this option is specified, we load the given script as the module. And to use
the module loading inside the JSC shell, we added the simple loader hook for fetching.
It fetches the module content from the file system.
And to use the ES6 Map in the Loader implementation, we added @get and @set methods to the Map.
But it conflicts with the existing `getPrivateName` method. Rename it to `lookUpPrivateName`.
[1]: https://whatwg.github.io/loader/
[2]: https://github.com/whatwg/loader/commit/214c7a6625b445bdf411c39984f36f01139a24be
[3]: https://github.com/whatwg/loader/pull/66
[4]: https://github.com/whatwg/loader/pull/67
[5]: https://github.com/whatwg/loader/issues/68
[6]: https://bugs.webkit.org/show_bug.cgi?id=148136
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/BuiltinNames.h:
(JSC::BuiltinNames::lookUpPrivateName):
(JSC::BuiltinNames::lookUpPublicName):
(JSC::BuiltinNames::getPrivateName): Deleted.
(JSC::BuiltinNames::getPublicName): Deleted.
* builtins/ModuleLoaderObject.js: Added.
(setStateToMax):
(newRegistryEntry):
(forceFulfillPromise):
(fulfillFetch):
(fulfillTranslate):
(fulfillInstantiate):
(instantiation):
(requestFetch):
(requestTranslate):
(requestInstantiate):
(requestResolveDependencies.resolveDependenciesPromise.this.requestInstantiate.then.):
(requestResolveDependencies.resolveDependenciesPromise.this.requestInstantiate.then):
(requestResolveDependencies):
(requestInstantiateAll):
(provide):
* jsc.cpp:
(stringFromUTF):
(jscSource):
(GlobalObject::moduleLoaderFetch):
(functionCheckModuleSyntax):
(dumpException):
(runWithScripts):
(printUsageStatement):
(CommandLine::parseArguments):
(jscmain):
(CommandLine::CommandLine): Deleted.
* parser/Lexer.cpp:
(JSC::Lexer<LChar>::parseIdentifier):
(JSC::Lexer<UChar>::parseIdentifier):
* parser/ModuleAnalyzer.cpp:
(JSC::ModuleAnalyzer::ModuleAnalyzer):
(JSC::ModuleAnalyzer::exportVariable):
(JSC::ModuleAnalyzer::analyze):
* parser/ModuleAnalyzer.h:
(JSC::ModuleAnalyzer::moduleRecord):
* parser/ModuleRecord.cpp:
(JSC::printableName): Deleted.
(JSC::ModuleRecord::dump): Deleted.
* parser/ModuleRecord.h:
(JSC::ModuleRecord::ImportEntry::isNamespace): Deleted.
(JSC::ModuleRecord::create): Deleted.
(JSC::ModuleRecord::appendRequestedModule): Deleted.
(JSC::ModuleRecord::addImportEntry): Deleted.
(JSC::ModuleRecord::addExportEntry): Deleted.
(JSC::ModuleRecord::addStarExportEntry): Deleted.
* parser/Nodes.h:
* parser/NodesAnalyzeModule.cpp:
(JSC::ImportDeclarationNode::analyzeModule):
(JSC::ExportAllDeclarationNode::analyzeModule):
(JSC::ExportNamedDeclarationNode::analyzeModule):
* runtime/CommonIdentifiers.cpp:
(JSC::CommonIdentifiers::lookUpPrivateName):
(JSC::CommonIdentifiers::lookUpPublicName):
(JSC::CommonIdentifiers::getPrivateName): Deleted.
(JSC::CommonIdentifiers::getPublicName): Deleted.
* runtime/CommonIdentifiers.h:
* runtime/Completion.cpp:
(JSC::checkModuleSyntax):
(JSC::evaluateModule):
* runtime/Completion.h:
* runtime/ExceptionHelpers.cpp:
(JSC::createUndefinedVariableError):
* runtime/Identifier.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::moduleLoader):
(JSC::JSGlobalObject::moduleRecordStructure):
* runtime/JSModuleRecord.cpp: Renamed from Source/JavaScriptCore/parser/ModuleRecord.cpp.
(JSC::JSModuleRecord::destroy):
(JSC::JSModuleRecord::finishCreation):
(JSC::printableName):
(JSC::JSModuleRecord::dump):
* runtime/JSModuleRecord.h: Renamed from Source/JavaScriptCore/parser/ModuleRecord.h.
(JSC::JSModuleRecord::ImportEntry::isNamespace):
(JSC::JSModuleRecord::createStructure):
(JSC::JSModuleRecord::create):
(JSC::JSModuleRecord::requestedModules):
(JSC::JSModuleRecord::JSModuleRecord):
(JSC::JSModuleRecord::appendRequestedModule):
(JSC::JSModuleRecord::addImportEntry):
(JSC::JSModuleRecord::addExportEntry):
(JSC::JSModuleRecord::addStarExportEntry):
* runtime/MapPrototype.cpp:
(JSC::MapPrototype::finishCreation):
* runtime/ModuleLoaderObject.cpp: Added.
(JSC::ModuleLoaderObject::ModuleLoaderObject):
(JSC::ModuleLoaderObject::finishCreation):
(JSC::ModuleLoaderObject::getOwnPropertySlot):
(JSC::printableModuleKey):
(JSC::ModuleLoaderObject::provide):
(JSC::ModuleLoaderObject::requestInstantiateAll):
(JSC::ModuleLoaderObject::resolve):
(JSC::ModuleLoaderObject::fetch):
(JSC::ModuleLoaderObject::translate):
(JSC::ModuleLoaderObject::instantiate):
(JSC::moduleLoaderObjectParseModule):
(JSC::moduleLoaderObjectRequestedModules):
(JSC::moduleLoaderObjectResolve):
(JSC::moduleLoaderObjectFetch):
(JSC::moduleLoaderObjectTranslate):
(JSC::moduleLoaderObjectInstantiate):
* runtime/ModuleLoaderObject.h: Added.
(JSC::ModuleLoaderObject::create):
(JSC::ModuleLoaderObject::createStructure):
* runtime/Options.h:
2015-08-20 Filip Pizlo <fpizlo@apple.com>
DFG should have a KnownBooleanUse for cases where we are required to know that the child is a boolean and it's not OK to speculate
https://bugs.webkit.org/show_bug.cgi?id=148286
Reviewed by Benjamin Poulain.
This enables us to ensure that the Branch or LogicalNot after an effectful CompareXYZ can
be marked as !mayExit(). I need that for https://bugs.webkit.org/show_bug.cgi?id=145204.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::observeUseKindOnNode):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::SafeToExecuteEdge::operator()):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::speculate):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculateBooleanOperand::SpeculateBooleanOperand):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
(JSC::DFG::SpeculativeJIT::compileLogicalNot):
(JSC::DFG::SpeculativeJIT::emitBranch):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
(JSC::DFG::SpeculativeJIT::compileLogicalNot):
(JSC::DFG::SpeculativeJIT::emitBranch):
* dfg/DFGUseKind.cpp:
(WTF::printInternal):
* dfg/DFGUseKind.h:
(JSC::DFG::typeFilterFor):
(JSC::DFG::shouldNotHaveTypeCheck):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::boolify):
(JSC::FTL::DFG::LowerDFGToLLVM::lowBoolean):
2015-08-20 Filip Pizlo <fpizlo@apple.com>
Overflow check elimination fails for a simple test case
https://bugs.webkit.org/show_bug.cgi?id=147387
Reviewed by Benjamin Poulain.
Overflow check elimination was having issues when things got constant-folded, because whereas an
Add or LessThan operation teaches us about relationships between the things being added or
compared, we don't do that when we see a JSConstant. We don't create a relationship between every
JSConstant and every other JSConstant. So, if we constant-fold an Add, we forget the relationships
that it would have had with its inputs.
One solution would be to have every JSConstant create a relationship with every other JSConstant.
This is dangerous, since it would create O(n^2) explosion of relationships.
Instead, this patch teaches filtration and merging how to behave "as if" there were inter-constant
relationships. Normally those operations only work on two relationships involving the same node
pair. But now, if we have @x op @c and @x op @d, where @c and @d are different nodes but both are
constants, we will do merging or filtering by grokking the constant values.
This speeds up lots of tests in JSRegress, because it enables overflow check elimination on things
like:
for (var i = 0; i < 100; ++i)
Previously, the fact that this was all constants would throw off the analysis because the analysis
wouldn't "know" that 0 < 100.
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
2015-08-20 Geoffrey Garen <ggaren@apple.com>
forEachCodeBlock should wait for all CodeBlocks automatically
https://bugs.webkit.org/show_bug.cgi?id=148255
Add back a line of code I deleted by accident in my last patch due to
incorrect merge.
Unreviewed.
* runtime/VM.cpp:
(JSC::VM::deleteAllCode):
2015-08-20 Geoffrey Garen <ggaren@apple.com>
forEachCodeBlock should wait for all CodeBlocks automatically
https://bugs.webkit.org/show_bug.cgi?id=148255
Reviewed by Saam Barati.
Previously, all clients needed to wait manually before calling
forEachCodeBlock. That's easy to get wrong, and at least one place
got it wrong. Let's do this automatically instead.
* debugger/Debugger.cpp:
(JSC::Debugger::Debugger):
(JSC::Debugger::setSteppingMode):
(JSC::Debugger::toggleBreakpoint): No need to wait manually;
forEachCodeBlock will do it automatically now.
(JSC::Debugger::recompileAllJSFunctions): We still need to wait manually
here because this is an iteration of the heap, which does not wait
automatically. Use the new helper function for waiting.
(JSC::Debugger::clearBreakpoints):
(JSC::Debugger::clearDebuggerRequests):
(JSC::Debugger::setBreakpointsActivated):
(JSC::Debugger::forEachCodeBlock): Deleted. No need to wait manually.
* debugger/Debugger.h:
* dfg/DFGWorklist.cpp:
(JSC::DFG::completeAllPlansForVM):
* dfg/DFGWorklist.h:
(JSC::DFG::completeAllPlansForVM): Added a helper function that replaces
vm.prepareToDeleteCode. This new function is clearer because we need
to call it sometimes even if we are not going to delete code.
* heap/HeapInlines.h:
(JSC::Heap::forEachCodeBlock): Moved.
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::recompileAllJSFunctionsForTypeProfiling): Use the new helper
function.
* runtime/JSCInlines.h:
(JSC::Heap::forEachCodeBlock): Do the waiting automatically.
* runtime/VM.cpp:
(JSC::VM::stopSampling):
(JSC::VM::deleteAllCode):
(JSC::VM::setEnabledProfiler):
(JSC::VM::prepareToDeleteCode): Deleted.
* runtime/VM.h: No need to wait manually.
2015-08-20 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r188675.
https://bugs.webkit.org/show_bug.cgi?id=148244
"caused a 17% Mac PLT regression" (Requested by ggaren on
#webkit).
Reverted changeset:
"clearCode() should clear code"
https://bugs.webkit.org/show_bug.cgi?id=148203
http://trac.webkit.org/changeset/188675
2015-08-11 Yusuke Suzuki <utatane.tea@gmail.com>
Introduce put_by_id like IC into put_by_val when the given name is String or Symbol
https://bugs.webkit.org/show_bug.cgi?id=147760
Reviewed by Filip Pizlo.
This patch adds put_by_id IC to put_by_val by caching the one candidate id,
it is the same thing to the get_by_val IC extension.
It will encourage the use of ES6 Symbols and ES6 computed properties in the object literals.
In this patch, we leverage the existing CheckIdent and PutById / PutByVal in DFG,
so this patch does not change FTL because the above operations are already supported in FTL.
And this patch also includes refactoring to leverage byValInfo->slowPathCount in the cached Id path.
Performance results report there's no regression in the existing tests. And in the synthetic
benchmarks created by modifying put-by-id to put-by-val, we can see significant performance
improvements up to 13.9x.
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeForStubInfo):
* bytecode/PutByIdStatus.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* jit/JIT.h:
(JSC::JIT::compilePutByValWithCachedId):
* jit/JITOperations.cpp:
(JSC::getByVal):
(JSC::tryGetByValOptimize):
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitGetByValWithCachedId):
(JSC::JIT::emit_op_put_by_val):
(JSC::JIT::emitPutByValWithCachedId):
(JSC::JIT::emitSlow_op_put_by_val):
(JSC::JIT::emitIdentifierCheck):
(JSC::JIT::privateCompilePutByValWithCachedId):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emitGetByValWithCachedId):
(JSC::JIT::emit_op_put_by_val):
(JSC::JIT::emitPutByValWithCachedId):
(JSC::JIT::emitSlow_op_put_by_val):
* tests/stress/put-by-val-with-string-break.js: Added.
(shouldBe):
(assign):
* tests/stress/put-by-val-with-string-generated.js: Added.
(shouldBe):
(gen1):
(gen2):
(assign):
* tests/stress/put-by-val-with-string-generic.js: Added.
(shouldBe):
(assign):
* tests/stress/put-by-val-with-symbol-break.js: Added.
(shouldBe):
(assign):
* tests/stress/put-by-val-with-symbol-generic.js: Added.
(shouldBe):
(assign):
2015-08-20 Alex Christensen <achristensen@webkit.org>
Clean up CMake build after r188673
https://bugs.webkit.org/show_bug.cgi?id=148234
Reviewed by Tim Horton.
* shell/PlatformWin.cmake:
Define WIN_CAIRO so the WinCairo jsc.exe can find the correct dlls.
2015-08-20 Mark Lam <mark.lam@apple.com>
A watchdog tests is failing on Windows.
https://bugs.webkit.org/show_bug.cgi?id=148228
Reviewed by Brent Fulgham.
The test just needed a little more time because Windows' timer resolution is low.
After increasing the test deadlines, the test started passing.
* API/tests/ExecutionTimeLimitTest.cpp:
(testExecutionTimeLimit):
2015-08-20 Mark Lam <mark.lam@apple.com>
Fixed some warnings on Windows.
https://bugs.webkit.org/show_bug.cgi?id=148224
Reviewed by Brent Fulgham.
The Windows build was complaining that function params were hiding a global variable.
Since the function params were unused, I resolved this by removing the param names.
* API/tests/ExecutionTimeLimitTest.cpp:
(currentCPUTimeAsJSFunctionCallback):
(shouldTerminateCallback):
(cancelTerminateCallback):
(extendTerminateCallback):
2015-08-19 Yusuke Suzuki <utatane.tea@gmail.com>
Add InternalPromise to use Promises safely in the internals
https://bugs.webkit.org/show_bug.cgi?id=148136
Reviewed by Saam Barati.
This patch implements InternalPromise.
It is completely different instance set (constructor, prototype, instance)
but it has the same feature to the Promise.
In the Promise operations, when resolving the promise with the returned promise
from the fulfill handler, we need to look up "then" method.
e.g.
var p3 = p1.then(function handler(...) {
return p2;
});
When handler is executed, we retrieve the returned `p2` promise. And to resolve
the returned promise by "then" method (that is `p3`), we construct the chain by executing
`p2.then(resolving function for p3)`. So if the user modify the Promise.prototype.then,
we can observe the internal operations.
By using InternalPromise, we completely hide InternalPromise.prototype from the users.
It allows JSC to use Promises internally; even if the user modify / override
the Promise.prototype.then function, it does not effect on InternalPromise.
One limitation is that the implementation need to take care not to leak the InternalPromise instance
to the user space.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/InternalPromiseConstructor.js: Added.
(internalAll.newResolveElement):
(internalAll):
* builtins/Operations.Promise.js:
(newPromiseDeferred): Deleted.
* builtins/PromiseConstructor.js:
(privateAll.newResolveElement): Deleted.
(privateAll): Deleted.
* runtime/CommonIdentifiers.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::promiseConstructor):
(JSC::JSGlobalObject::internalPromiseConstructor):
(JSC::JSGlobalObject::newPromiseCapabilityFunction):
(JSC::JSGlobalObject::newPromiseDeferredFunction): Deleted.
* runtime/JSInternalPromise.cpp: Copied from Source/JavaScriptCore/runtime/JSPromisePrototype.h.
(JSC::JSInternalPromise::create):
(JSC::JSInternalPromise::createStructure):
(JSC::JSInternalPromise::JSInternalPromise):
* runtime/JSInternalPromise.h: Copied from Source/JavaScriptCore/runtime/JSPromise.h.
* runtime/JSInternalPromiseConstructor.cpp: Added.
(JSC::JSInternalPromiseConstructor::create):
(JSC::JSInternalPromiseConstructor::createStructure):
(JSC::JSInternalPromiseConstructor::JSInternalPromiseConstructor):
(JSC::constructPromise):
(JSC::JSInternalPromiseConstructor::getConstructData):
(JSC::JSInternalPromiseConstructor::getCallData):
(JSC::JSInternalPromiseConstructor::getOwnPropertySlot):
* runtime/JSInternalPromiseConstructor.h: Copied from Source/JavaScriptCore/runtime/JSPromiseConstructor.h.
* runtime/JSInternalPromiseDeferred.cpp: Added.
(JSC::JSInternalPromiseDeferred::create):
(JSC::JSInternalPromiseDeferred::JSInternalPromiseDeferred):
(JSC::JSInternalPromiseDeferred::promise):
* runtime/JSInternalPromiseDeferred.h: Copied from Source/JavaScriptCore/runtime/JSPromisePrototype.h.
* runtime/JSInternalPromisePrototype.cpp: Copied from Source/JavaScriptCore/runtime/JSPromisePrototype.cpp.
(JSC::JSInternalPromisePrototype::create):
(JSC::JSInternalPromisePrototype::createStructure):
(JSC::JSInternalPromisePrototype::JSInternalPromisePrototype):
* runtime/JSInternalPromisePrototype.h: Copied from Source/JavaScriptCore/runtime/JSPromise.h.
* runtime/JSPromise.cpp:
(JSC::JSPromise::create):
(JSC::JSPromise::JSPromise):
(JSC::JSPromise::initialize):
* runtime/JSPromise.h:
* runtime/JSPromiseConstructor.cpp:
(JSC::JSPromiseConstructor::JSPromiseConstructor):
(JSC::constructPromise):
(JSC::JSPromiseConstructor::getOwnPropertySlot):
(JSC::JSPromiseConstructor::finishCreation): Deleted.
* runtime/JSPromiseConstructor.h:
* runtime/JSPromiseDeferred.cpp:
(JSC::newPromiseCapability):
(JSC::JSPromiseDeferred::create):
(JSC::JSPromiseDeferred::JSPromiseDeferred):
* runtime/JSPromiseDeferred.h:
* runtime/JSPromisePrototype.cpp:
(JSC::JSPromisePrototype::getOwnPropertySlot):
* runtime/JSPromisePrototype.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2015-08-19 Filip Pizlo <fpizlo@apple.com>
Remove WTF::SpinLock
https://bugs.webkit.org/show_bug.cgi?id=148208
Reviewed by Geoffrey Garen.
Remove the one remaining use of SpinLock.
* API/JSValue.mm:
(handerForStructTag):
2015-08-19 Geoffrey Garen <ggaren@apple.com>
clearCode() should clear code
https://bugs.webkit.org/show_bug.cgi?id=148203
Reviewed by Saam Barati.
Clearing code used to require two steps: clearCode() and
clearUnlinkedCodeForRecompilation(). Unsurprisingly, clients sometimes
did one or the other or both without much rhyme or reason.
This patch simplifies things by merging both functions into clearCode().
* bytecode/UnlinkedFunctionExecutable.h:
* debugger/Debugger.cpp:
* heap/Heap.cpp:
(JSC::Heap::deleteAllCompiledCode):
(JSC::Heap::clearUnmarkedExecutables):
(JSC::Heap::deleteAllUnlinkedFunctionCode): Deleted. No need for this
function anymore since it was only used by clients who already called
clearCode() (and it would be terribly wrong to use without doing both.)
* heap/Heap.h:
(JSC::Heap::sizeAfterLastFullCollection):
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::TypeRecompiler::visit):
(Inspector::TypeRecompiler::operator()):
* runtime/Executable.cpp:
(JSC::FunctionExecutable::visitChildren):
(JSC::FunctionExecutable::clearCode):
(JSC::FunctionExecutable::clearUnlinkedCodeForRecompilation): Deleted.
* runtime/Executable.h:
* runtime/VM.cpp:
(JSC::VM::deleteAllCode):
2015-08-19 Alex Christensen <achristensen@webkit.org>
CMake Windows build should not include files directly from other Source directories
https://bugs.webkit.org/show_bug.cgi?id=148198
Reviewed by Brent Fulgham.
* CMakeLists.txt:
JavaScriptCore_FORWARDING_HEADERS_FILES is no longer necessary because all the headers
that used to be in it are now in JavaScriptCore_FORWARDING_HEADERS_DIRECTORIES
* PlatformEfl.cmake:
* PlatformGTK.cmake:
* PlatformMac.cmake:
* PlatformWin.cmake:
2015-08-19 Eric Carlson <eric.carlson@apple.com>
Remove ENABLE_WEBVTT_REGIONS
https://bugs.webkit.org/show_bug.cgi?id=148184
Reviewed by Jer Noble.
* Configurations/FeatureDefines.xcconfig: Remove ENABLE_WEBVTT_REGIONS.
2015-08-19 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Unexpected node preview format for an element with newlines in className attribute
https://bugs.webkit.org/show_bug.cgi?id=148192
Reviewed by Brian Burg.
* inspector/InjectedScriptSource.js:
(InjectedScript.prototype._nodePreview):
Replace whitespace blocks with single spaces to produce a simpler class string for previews.
2015-08-19 Mark Lam <mark.lam@apple.com>
Add support for CheckWatchdogTimer as slow path in DFG and FTL.
https://bugs.webkit.org/show_bug.cgi?id=147968
Reviewed by Michael Saboff.
Re-implement the DFG's CheckWatchdogTimer as a slow path instead of a speculation
check. Since the watchdog timer can fire spuriously, this allows the code to
stay optimized if all we have are spurious fires.
Implement the equivalent slow path for CheckWatchdogTimer in the FTL.
The watchdog tests in ExecutionTimeLimitTest.cpp has already been updated in
https://bugs.webkit.org/show_bug.cgi?id=148125 to test for the FTL's watchdog
implementation.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
(JSC::FTL::DFG::LowerDFGToLLVM::compileMaterializeCreateActivation):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCheckWatchdogTimer):
(JSC::FTL::DFG::LowerDFGToLLVM::isInlinableSize):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
- Changed operationHandleWatchdogTimer() to return an unused nullptr. This
allows me to reuse the existing DFG slow path generator mechanism. I didn't
think that operationHandleWatchdogTimer() was worth introducing a whole new set
of machinery just so we can have a slow path that returns void.
2015-08-19 Mark Lam <mark.lam@apple.com>
Add ability to save and restore JSC options.
https://bugs.webkit.org/show_bug.cgi?id=148125
Reviewed by Saam Barati.
* API/tests/ExecutionTimeLimitTest.cpp:
(testExecutionTimeLimit):
- Employ the new options getter/setter to run watchdog tests for each of the
execution engine tiers.
- Also altered the test scripts to be in a function instead of global code.
This is one of 2 changes needed to give them an opportunity to be FTL compiled.
The other is to add support for compiling CheckWatchdogTimer in the FTL (which
will be addressed in a separate patch).
* jsc.cpp:
(CommandLine::parseArguments):
* runtime/Options.cpp:
(JSC::parse):
- Add the ability to clear a string option with a nullptr value.
This is needed to restore a default string option value which may be null.
(JSC::OptionRange::init):
- Add the ability to clear a range option with a null value.
This is needed to restore a default range option value which may be null.
(JSC::Options::initialize):
(JSC::Options::dumpOptionsIfNeeded):
- Factor code to dump options out to dumpOptionsIfNeeded() since we will need
that logic elsewhere.
(JSC::Options::setOptions):
- Parse an options string and set each of the specified options.
(JSC::Options::dumpAllOptions):
(JSC::Options::dumpAllOptionsInALine):
(JSC::Options::dumpOption):
(JSC::Option::dump):
- Refactored so that the underlying dumper dumps to a StringBuilder instead of
stderr. This lets us reuse this code to serialize all the options into a
single string for dumpAllOptionsInALine().
* runtime/Options.h:
(JSC::OptionRange::rangeString):
2015-08-18 Filip Pizlo <fpizlo@apple.com>
Replace all uses of std::mutex/std::condition_variable with WTF::Lock/WTF::Condition
https://bugs.webkit.org/show_bug.cgi?id=148140
Reviewed by Geoffrey Garen.
* inspector/remote/RemoteInspector.h:
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::registerDebuggable):
(Inspector::RemoteInspector::unregisterDebuggable):
(Inspector::RemoteInspector::updateDebuggable):
(Inspector::RemoteInspector::updateDebuggableAutomaticInspectCandidate):
(Inspector::RemoteInspector::sendMessageToRemoteFrontend):
(Inspector::RemoteInspector::setupFailed):
(Inspector::RemoteInspector::setupCompleted):
(Inspector::RemoteInspector::start):
(Inspector::RemoteInspector::stop):
(Inspector::RemoteInspector::setupXPCConnectionIfNeeded):
(Inspector::RemoteInspector::setParentProcessInformation):
(Inspector::RemoteInspector::xpcConnectionReceivedMessage):
(Inspector::RemoteInspector::xpcConnectionFailed):
(Inspector::RemoteInspector::pushListingSoon):
(Inspector::RemoteInspector::receivedIndicateMessage):
(Inspector::RemoteInspector::receivedProxyApplicationSetupMessage):
* inspector/remote/RemoteInspectorXPCConnection.h:
* inspector/remote/RemoteInspectorXPCConnection.mm:
(Inspector::RemoteInspectorXPCConnection::close):
(Inspector::RemoteInspectorXPCConnection::closeFromMessage):
(Inspector::RemoteInspectorXPCConnection::deserializeMessage):
(Inspector::RemoteInspectorXPCConnection::handleEvent):
2015-08-18 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Links for rules in <style> are incorrect, do not account for <style> offset in the document
https://bugs.webkit.org/show_bug.cgi?id=148141
Reviewed by Brian Burg.
* inspector/protocol/CSS.json:
Extend StyleSheetHeader to include start offset information and a bit
for whether or not this was an inline style tag created by the parser.
These match additions to Blink's protocol.
2015-08-18 Benjamin Poulain <bpoulain@apple.com>
[JSC] Optimize more cases of something-compared-to-null/undefined
https://bugs.webkit.org/show_bug.cgi?id=148157
Reviewed by Geoffrey Garen and Filip Pizlo.
CompareEq is fairly trivial if you assert one of the operands is either
null or undefined. Under those conditions, the only way to have "true"
is to have the other operand be null/undefined or have an object
that masquerades to undefined.
JSC already had a fast path in CompareEqConstant.
With this patch, I generalize this fast path to more cases and try
to eliminate the checks whenever possible.
CompareEq now does the job of CompareEqConstant. If any operand can
be proved to be undefined/other, its edge is set to OtherUse. Whenever
any edge is OtherUse, we generate the fast code we had for CompareEqConstant.
The AbstractInterpreter has additional checks to reduce the node to a constant
whenever possible.
There are two additional changes in this patch:
-The Fixup Phase tries to set edges to OtherUse early. This is done correctly
in ConstantFoldingPhase but setting it up early helps the phases relying
on Clobberize.
-The codegen for CompareEqConstant was improved. The reason is the comparison
for ObjectOrOther could be faster just because the codegen was better.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize): Deleted.
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC): Deleted.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::isUndefinedOrNullConstant):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate): Deleted.
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute): Deleted.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
(JSC::DFG::SpeculativeJIT::compare):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::isKnownNotOther):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined):
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNullOrUndefined):
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): Deleted.
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): Deleted.
(JSC::DFG::SpeculativeJIT::nonSpeculativeCompareNull): Deleted.
(JSC::DFG::SpeculativeJIT::compile): Deleted.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined):
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNullOrUndefined):
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): Deleted.
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): Deleted.
(JSC::DFG::SpeculativeJIT::nonSpeculativeCompareNull): Deleted.
(JSC::DFG::SpeculativeJIT::compile): Deleted.
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::validate): Deleted.
* dfg/DFGWatchpointCollectionPhase.cpp:
(JSC::DFG::WatchpointCollectionPhase::handle):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileCompareEq):
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode): Deleted.
(JSC::FTL::DFG::LowerDFGToLLVM::compileCompareEqConstant): Deleted.
* tests/stress/compare-eq-on-null-and-undefined-non-peephole.js: Added.
(string_appeared_here.useForMath):
(testUseForMath):
* tests/stress/compare-eq-on-null-and-undefined-optimized-in-constant-folding.js: Added.
(string_appeared_here.unreachableCodeTest):
(inlinedCompareToNull):
(inlinedComparedToUndefined):
(warmupInlineFunctions):
(testInlineFunctions):
* tests/stress/compare-eq-on-null-and-undefined.js: Added.
(string_appeared_here.compareConstants):
(opaqueNull):
(opaqueUndefined):
(compareConstantsAndDynamicValues):
(compareDynamicValues):
(compareDynamicValueToItself):
(arrayTesting):
(opaqueCompare1):
(testNullComparatorUpdate):
(opaqueCompare2):
(testUndefinedComparatorUpdate):
(opaqueCompare3):
(testNullAndUndefinedComparatorUpdate):
2015-08-18 Yusuke Suzuki <utatane.tea@gmail.com>
Introduce non-user-observable Promise functions to use Promises internally
https://bugs.webkit.org/show_bug.cgi?id=148118
Reviewed by Saam Barati.
To leverage the Promises internally (like ES6 Module Loaders), we add
the several non-user-observable private methods, like @then, @all. And
refactor the existing Promises implementation to make it easy to use
internally.
But still the trappable part remains. When resolving the promise with
the returned value, we look up the "then" function. So users can trap
by replacing "then" function of the Promise's prototype.
To avoid this situation, we'll introduce completely differnt promise
instances called InternalPromise in the subsequent patch[1].
No behavior change.
[1]: https://bugs.webkit.org/show_bug.cgi?id=148136
* builtins/PromiseConstructor.js:
(privateAll.newResolveElement):
(privateAll):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren): Deleted.
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::promiseConstructor): Deleted.
(JSC::JSGlobalObject::promisePrototype): Deleted.
(JSC::JSGlobalObject::promiseStructure): Deleted.
* runtime/JSPromiseConstructor.cpp:
(JSC::JSPromiseConstructor::finishCreation):
* runtime/JSPromiseDeferred.cpp:
(JSC::callFunction):
(JSC::JSPromiseDeferred::resolve):
(JSC::JSPromiseDeferred::reject):
* runtime/JSPromiseDeferred.h:
* runtime/JSPromisePrototype.cpp:
(JSC::JSPromisePrototype::create):
(JSC::JSPromisePrototype::JSPromisePrototype):
* runtime/JSPromisePrototype.h:
2015-08-18 Geoffrey Garen <ggaren@apple.com>
Try to fix the CLOOP build.
Unreviewed.
* bytecode/CodeBlock.cpp:
2015-08-18 Geoffrey Garen <ggaren@apple.com>
Split InlineCallFrame into its own file
https://bugs.webkit.org/show_bug.cgi?id=148131
Reviewed by Saam Barati.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CallLinkStatus.cpp:
* bytecode/CodeBlock.h:
(JSC::ExecState::r):
(JSC::baselineCodeBlockForInlineCallFrame): Deleted.
(JSC::baselineCodeBlockForOriginAndBaselineCodeBlock): Deleted.
* bytecode/CodeOrigin.cpp:
(JSC::CodeOrigin::inlineStack):
(JSC::CodeOrigin::codeOriginOwner):
(JSC::CodeOrigin::stackOffset):
(JSC::CodeOrigin::dump):
(JSC::CodeOrigin::dumpInContext):
(JSC::InlineCallFrame::calleeConstant): Deleted.
(JSC::InlineCallFrame::visitAggregate): Deleted.
(JSC::InlineCallFrame::calleeForCallFrame): Deleted.
(JSC::InlineCallFrame::hash): Deleted.
(JSC::InlineCallFrame::hashAsStringIfPossible): Deleted.
(JSC::InlineCallFrame::inferredName): Deleted.
(JSC::InlineCallFrame::baselineCodeBlock): Deleted.
(JSC::InlineCallFrame::dumpBriefFunctionInformation): Deleted.
(JSC::InlineCallFrame::dumpInContext): Deleted.
(JSC::InlineCallFrame::dump): Deleted.
(WTF::printInternal): Deleted.
* bytecode/CodeOrigin.h:
(JSC::CodeOrigin::deletedMarker):
(JSC::CodeOrigin::hash):
(JSC::CodeOrigin::operator==):
(JSC::CodeOriginHash::hash):
(JSC::CodeOriginHash::equal):
(JSC::InlineCallFrame::kindFor): Deleted.
(JSC::InlineCallFrame::varargsKindFor): Deleted.
(JSC::InlineCallFrame::specializationKindFor): Deleted.
(JSC::InlineCallFrame::isVarargs): Deleted.
(JSC::InlineCallFrame::InlineCallFrame): Deleted.
(JSC::InlineCallFrame::specializationKind): Deleted.
(JSC::InlineCallFrame::setStackOffset): Deleted.
(JSC::InlineCallFrame::callerFrameOffset): Deleted.
(JSC::InlineCallFrame::returnPCOffset): Deleted.
(JSC::CodeOrigin::stackOffset): Deleted.
(JSC::CodeOrigin::codeOriginOwner): Deleted.
* bytecode/InlineCallFrame.cpp: Copied from Source/JavaScriptCore/bytecode/CodeOrigin.cpp.
(JSC::InlineCallFrame::calleeConstant):
(JSC::CodeOrigin::inlineDepthForCallFrame): Deleted.
(JSC::CodeOrigin::inlineDepth): Deleted.
(JSC::CodeOrigin::isApproximatelyEqualTo): Deleted.
(JSC::CodeOrigin::approximateHash): Deleted.
(JSC::CodeOrigin::inlineStack): Deleted.
(JSC::CodeOrigin::dump): Deleted.
(JSC::CodeOrigin::dumpInContext): Deleted.
* bytecode/InlineCallFrame.h: Copied from Source/JavaScriptCore/bytecode/CodeOrigin.h.
(JSC::InlineCallFrame::isVarargs):
(JSC::InlineCallFrame::InlineCallFrame):
(JSC::InlineCallFrame::specializationKind):
(JSC::baselineCodeBlockForInlineCallFrame):
(JSC::baselineCodeBlockForOriginAndBaselineCodeBlock):
(JSC::CodeOrigin::CodeOrigin): Deleted.
(JSC::CodeOrigin::isSet): Deleted.
(JSC::CodeOrigin::operator!): Deleted.
(JSC::CodeOrigin::isHashTableDeletedValue): Deleted.
(JSC::CodeOrigin::operator!=): Deleted.
(JSC::CodeOrigin::deletedMarker): Deleted.
(JSC::CodeOrigin::stackOffset): Deleted.
(JSC::CodeOrigin::hash): Deleted.
(JSC::CodeOrigin::operator==): Deleted.
(JSC::CodeOrigin::codeOriginOwner): Deleted.
(JSC::CodeOriginHash::hash): Deleted.
(JSC::CodeOriginHash::equal): Deleted.
(JSC::CodeOriginApproximateHash::hash): Deleted.
(JSC::CodeOriginApproximateHash::equal): Deleted.
* bytecode/InlineCallFrameSet.cpp:
* dfg/DFGCommonData.cpp:
* dfg/DFGOSRExitBase.cpp:
* dfg/DFGVariableEventStream.cpp:
* ftl/FTLOperations.cpp:
* interpreter/CallFrame.cpp:
* interpreter/StackVisitor.cpp:
* jit/AssemblyHelpers.h:
* profiler/ProfilerOriginStack.cpp:
* runtime/ClonedArguments.cpp:
2015-08-18 Mark Lam <mark.lam@apple.com>
Removed an unused param in Interpreter::initialize().
https://bugs.webkit.org/show_bug.cgi?id=148129
Reviewed by Michael Saboff.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::~Interpreter):
(JSC::Interpreter::initialize):
* interpreter/Interpreter.h:
(JSC::Interpreter::stack):
* runtime/VM.cpp:
(JSC::VM::VM):
2015-08-17 Alex Christensen <achristensen@webkit.org>
Add const to content extension parser
https://bugs.webkit.org/show_bug.cgi?id=148044
Reviewed by Benjamin Poulain.
* runtime/JSObject.h:
(JSC::JSObject::getIndexQuickly):
(JSC::JSObject::tryGetIndexQuickly):
(JSC::JSObject::getDirectIndex):
(JSC::JSObject::getIndex):
Added a few const keywords.
2015-08-17 Alex Christensen <achristensen@webkit.org>
Build Debug Suffix on Windows with CMake
https://bugs.webkit.org/show_bug.cgi?id=148083
Reviewed by Brent Fulgham.
* CMakeLists.txt:
* PlatformWin.cmake:
* shell/CMakeLists.txt:
* shell/PlatformWin.cmake:
Add DEBUG_SUFFIX
2015-08-17 Saam barati <sbarati@apple.com>
Web Inspector: Type profiler return types aren't showing up
https://bugs.webkit.org/show_bug.cgi?id=147348
Reviewed by Brian Burg.
Bug #145995 changed the starting offset of a function to
be the open parenthesis of the function's parameter list.
This broke JSC's type profiler protocol of communicating
return types of a function to the web inspector. This
is now fixed. The text offset used in the protocol is now
the first letter of the function/get/set/method name.
So "f" in "function a() {}", "s" in "set foo(){}", etc.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
* jsc.cpp:
(functionReturnTypeFor):
2015-08-17 Aleksandr Skachkov <gskachkov@gmail.com>
[ES6] Implement ES6 arrow function syntax. Arrow function specific features. Lexical bind of this
https://bugs.webkit.org/show_bug.cgi?id=144956
Reviewed by Saam Barati.
Added support of ES6 arrow function specific feature, lexical bind of this and no constructor. http://wiki.ecmascript.org/doku.php?id=harmony:arrow_function_syntax
In patch were implemented the following cases:
this - variable |this| is point to the |this| of the function where arrow function is declared. Lexical bind of |this|
constructor - the using of the command |new| for arrow function leads to runtime error
call(), apply(), bind() - methods can only pass in arguments, but has no effect on |this|
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecode/ExecutableInfo.h:
(JSC::ExecutableInfo::ExecutableInfo):
(JSC::ExecutableInfo::isArrowFunction):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::isArrowFunction):
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::UnlinkedFunctionExecutable::codeBlockFor):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitNewFunctionCommon):
(JSC::BytecodeGenerator::emitNewFunctionExpression):
(JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
(JSC::BytecodeGenerator::emitLoadArrowFunctionThis):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ArrowFuncExprNode::emitBytecode):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToPhantomNewFunction):
(JSC::DFG::Node::hasCellOperand):
(JSC::DFG::Node::isFunctionAllocation):
* dfg/DFGNodeType.h:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGPromotedHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGPromotedHeapLocation.h:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileLoadArrowFunctionThis):
(JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
(JSC::DFG::SpeculativeJIT::compileNewFunction):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStoreBarrierInsertionPhase.cpp:
* dfg/DFGStructureRegistrationPhase.cpp:
(JSC::DFG::StructureRegistrationPhase::run):
* ftl/FTLAbstractHeapRepository.cpp:
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLIntrinsicRepository.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
(JSC::FTL::DFG::LowerDFGToLLVM::compileNewFunction):
(JSC::FTL::DFG::LowerDFGToLLVM::compileLoadArrowFunctionThis):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
* interpreter/Interpreter.cpp:
* interpreter/Interpreter.h:
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState): Added 3 arguments version for windows build.
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_load_arrowfunction_this):
(JSC::JIT::emit_op_new_func_exp):
(JSC::JIT::emitNewFuncExprCommon):
(JSC::JIT::emit_op_new_arrow_func_exp):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_load_arrowfunction_this):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* llint/LLIntOffsetsExtractor.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::setUpCall):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionMetadata):
(JSC::ASTBuilder::createArrowFunctionExpr):
* parser/NodeConstructors.h:
(JSC::BaseFuncExprNode::BaseFuncExprNode):
(JSC::FuncExprNode::FuncExprNode):
(JSC::ArrowFuncExprNode::ArrowFuncExprNode):
* parser/Nodes.cpp:
(JSC::FunctionMetadataNode::FunctionMetadataNode):
* parser/Nodes.h:
(JSC::ExpressionNode::isArrowFuncExprNode):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionBody):
(JSC::Parser<LexerType>::parseFunctionInfo):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionMetadata):
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
* runtime/Executable.h:
* runtime/JSArrowFunction.cpp: Added.
(JSC::JSArrowFunction::destroy):
(JSC::JSArrowFunction::create):
(JSC::JSArrowFunction::JSArrowFunction):
(JSC::JSArrowFunction::createWithInvalidatedReallocationWatchpoint):
(JSC::JSArrowFunction::visitChildren):
(JSC::JSArrowFunction::getConstructData):
* runtime/JSArrowFunction.h: Added.
(JSC::JSArrowFunction::allocationSize):
(JSC::JSArrowFunction::createImpl):
(JSC::JSArrowFunction::boundThis):
(JSC::JSArrowFunction::createStructure):
(JSC::JSArrowFunction::offsetOfThisValue):
* runtime/JSFunction.h:
* runtime/JSFunctionInlines.h:
(JSC::JSFunction::JSFunction):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::arrowFunctionStructure):
* tests/stress/arrowfunction-activation-sink-osrexit-default-value-tdz-error.js: Added.
* tests/stress/arrowfunction-activation-sink-osrexit-default-value.js: Added.
* tests/stress/arrowfunction-activation-sink-osrexit.js: Added.
* tests/stress/arrowfunction-activation-sink.js: Added.
* tests/stress/arrowfunction-bound.js: Added.
* tests/stress/arrowfunction-call.js: Added.
* tests/stress/arrowfunction-constructor.js: Added.
* tests/stress/arrowfunction-lexical-bind-this-1.js: Added.
* tests/stress/arrowfunction-lexical-bind-this-2.js: Added.
* tests/stress/arrowfunction-lexical-bind-this-3.js: Added.
* tests/stress/arrowfunction-lexical-bind-this-4.js: Added.
* tests/stress/arrowfunction-lexical-bind-this-5.js: Added.
* tests/stress/arrowfunction-lexical-bind-this-6.js: Added.
* tests/stress/arrowfunction-lexical-this-activation-sink-osrexit.js: Added.
* tests/stress/arrowfunction-lexical-this-activation-sink.js: Added.
* tests/stress/arrowfunction-lexical-this-sinking-no-double-allocate.js: Added.
* tests/stress/arrowfunction-lexical-this-sinking-osrexit.js: Added.
* tests/stress/arrowfunction-lexical-this-sinking-put.js: Added.
* tests/stress/arrowfunction-others.js: Added.
* tests/stress/arrowfunction-run-10-1.js: Added.
* tests/stress/arrowfunction-run-10-2.js: Added.
* tests/stress/arrowfunction-run-10000-1.js: Added.
* tests/stress/arrowfunction-run-10000-2.js: Added.
* tests/stress/arrowfunction-sinking-no-double-allocate.js: Added.
* tests/stress/arrowfunction-sinking-osrexit.js: Added.
* tests/stress/arrowfunction-sinking-put.js: Added.
* tests/stress/arrowfunction-tdz.js: Added.
* tests/stress/arrowfunction-typeof.js: Added.
2015-07-28 Sam Weinig <sam@webkit.org>
Cleanup the builtin JavaScript files
https://bugs.webkit.org/show_bug.cgi?id=147382
Reviewed by Geoffrey Garen.
* builtins/Array.prototype.js:
* builtins/ArrayConstructor.js:
* builtins/ArrayIterator.prototype.js:
* builtins/Function.prototype.js:
* builtins/Iterator.prototype.js:
* builtins/ObjectConstructor.js:
* builtins/StringConstructor.js:
* builtins/StringIterator.prototype.js:
Unify the style of the built JavaScript files.
2015-08-17 Alex Christensen <achristensen@webkit.org>
Move some commands from ./CMakeLists.txt to Source/cmake
https://bugs.webkit.org/show_bug.cgi?id=148003
Reviewed by Brent Fulgham.
* CMakeLists.txt:
Added commands needed to build JSC by itself.
2015-08-17 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement Reflect.get
https://bugs.webkit.org/show_bug.cgi?id=147925
Reviewed by Geoffrey Garen.
This patch implements Reflect.get API.
It can take the receiver object as the third argument.
When the receiver is specified and there's a getter for the given property name,
we call the getter with the receiver as the |this| value.
* runtime/ReflectObject.cpp:
(JSC::reflectObjectGet):
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayEntry::get): Deleted.
* runtime/SparseArrayValueMap.h:
* tests/stress/reflect-get.js: Added.
(shouldBe):
(shouldThrow):
(.get shouldThrow):
(.get var):
(get var.object.get hello):
(.get shouldBe):
(get var.object.set hello):
2015-08-17 Simon Fraser <simon.fraser@apple.com>
will-change should sometimes trigger compositing
https://bugs.webkit.org/show_bug.cgi?id=148072
Reviewed by Tim Horton.
Include will-change as a reason for compositing.
* inspector/protocol/LayerTree.json:
2015-08-17 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement Reflect.getOwnPropertyDescriptor
https://bugs.webkit.org/show_bug.cgi?id=147929
Reviewed by Geoffrey Garen.
Implement Reflect.getOwnPropertyDescriptor.
The difference from the Object.getOwnPropertyDescriptor is
Reflect.getOwnPropertyDescriptor does not perform ToObject onto
the first argument. If the first argument is not an Object, it
immediately raises the TypeError.
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorGetOwnPropertyDescriptor):
* runtime/ObjectConstructor.h:
* runtime/ReflectObject.cpp:
(JSC::reflectObjectGetOwnPropertyDescriptor):
* tests/stress/reflect-get-own-property.js: Added.
(shouldBe):
(shouldThrow):
2015-08-16 Benjamin Poulain <bpoulain@apple.com>
[JSC] Use (x + x) instead of (x * 2) when possible
https://bugs.webkit.org/show_bug.cgi?id=148051
Reviewed by Michael Saboff.
When multiplying a number by 2, JSC was loading a constant "2"
in register and multiplying it with the first number:
mov $0x4000000000000000, %rcx
movd %rcx, %xmm0
mulsd %xmm0, %xmm1
This is a problem for a few reasons.
1) "movd %rcx, %xmm0" only set half of XMM0. This instruction
has to wait for any preceding instruction on XMM0 to finish
before executing.
2) The load and transform itself is large and unecessary.
To fix that, I added a StrengthReductionPhase to transform
multiplications by 2 into a addition.
Unfortunately, that turned the code into:
movsd %xmm0 %xmm1
mulsd %xmm1 %xmm0
The reason is GenerationInfo::canReuse() was not accounting
for nodes using other nodes multiple times.
After fixing that too, we now have the multiplications by 2
done as:
addsd %xmm0 %xmm0
* dfg/DFGGenerationInfo.h:
(JSC::DFG::GenerationInfo::useCount):
(JSC::DFG::GenerationInfo::canReuse): Deleted.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::FPRTemporary::FPRTemporary):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::canReuse):
(JSC::DFG::GPRTemporary::GPRTemporary):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
2015-08-14 Basile Clement <basile_clement@apple.com>
Occasional failure in v8-v6/v8-raytrace.js.ftl-eager
https://bugs.webkit.org/show_bug.cgi?id=147165
Reviewed by Saam Barati.
The object allocation sinking phase was not properly checking that a
MultiGetByOffset was safe to lower before lowering it.
This makes it so that we only lower MultiGetByOffset if it only loads
from direct properties of the object, and considers it as an escape in
any other case (e.g. a load from the prototype).
It also ensure proper conversion of MultiGetByOffset into
CheckStructureImmediate when needed.
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::checkStructure):
We were not compiling properly CheckStructure and
CheckStructureImmediate nodes with an empty StructureSet.
* tests/stress/sink-multigetbyoffset.js: Regression test.
2015-08-14 Filip Pizlo <fpizlo@apple.com>
Use WTF::Lock and WTF::Condition instead of WTF::Mutex, WTF::ThreadCondition, std::mutex, and std::condition_variable
https://bugs.webkit.org/show_bug.cgi?id=147999
Reviewed by Geoffrey Garen.
* API/JSVirtualMachine.mm:
(initWrapperCache):
(+[JSVMWrapperCache addWrapper:forJSContextGroupRef:]):
(+[JSVMWrapperCache wrapperForJSContextGroupRef:]):
(wrapperCacheMutex): Deleted.
* bytecode/SamplingTool.cpp:
(JSC::SamplingTool::doRun):
(JSC::SamplingTool::notifyOfScope):
* bytecode/SamplingTool.h:
* dfg/DFGThreadData.h:
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::~Worklist):
(JSC::DFG::Worklist::isActiveForVM):
(JSC::DFG::Worklist::enqueue):
(JSC::DFG::Worklist::compilationState):
(JSC::DFG::Worklist::waitUntilAllPlansForVMAreReady):
(JSC::DFG::Worklist::removeAllReadyPlansForVM):
(JSC::DFG::Worklist::completeAllReadyPlansForVM):
(JSC::DFG::Worklist::visitWeakReferences):
(JSC::DFG::Worklist::removeDeadPlans):
(JSC::DFG::Worklist::queueLength):
(JSC::DFG::Worklist::dump):
(JSC::DFG::Worklist::runThread):
* dfg/DFGWorklist.h:
* disassembler/Disassembler.cpp:
* heap/CopiedSpace.cpp:
(JSC::CopiedSpace::doneFillingBlock):
(JSC::CopiedSpace::doneCopying):
* heap/CopiedSpace.h:
* heap/CopiedSpaceInlines.h:
(JSC::CopiedSpace::recycleBorrowedBlock):
(JSC::CopiedSpace::allocateBlockForCopyingPhase):
* heap/GCThread.cpp:
(JSC::GCThread::waitForNextPhase):
(JSC::GCThread::gcThreadMain):
* heap/GCThreadSharedData.cpp:
(JSC::GCThreadSharedData::GCThreadSharedData):
(JSC::GCThreadSharedData::~GCThreadSharedData):
(JSC::GCThreadSharedData::startNextPhase):
(JSC::GCThreadSharedData::endCurrentPhase):
(JSC::GCThreadSharedData::didStartMarking):
(JSC::GCThreadSharedData::didFinishMarking):
* heap/GCThreadSharedData.h:
* heap/HeapTimer.h:
* heap/MachineStackMarker.cpp:
(JSC::ActiveMachineThreadsManager::Locker::Locker):
(JSC::ActiveMachineThreadsManager::add):
(JSC::ActiveMachineThreadsManager::remove):
(JSC::ActiveMachineThreadsManager::ActiveMachineThreadsManager):
(JSC::MachineThreads::~MachineThreads):
(JSC::MachineThreads::addCurrentThread):
(JSC::MachineThreads::removeThreadIfFound):
(JSC::MachineThreads::tryCopyOtherThreadStack):
(JSC::MachineThreads::tryCopyOtherThreadStacks):
(JSC::MachineThreads::gatherConservativeRoots):
* heap/MachineStackMarker.h:
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::donateKnownParallel):
(JSC::SlotVisitor::drain):
(JSC::SlotVisitor::drainFromShared):
(JSC::SlotVisitor::mergeOpaqueRoots):
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::containsOpaqueRootTriState):
* inspector/remote/RemoteInspectorDebuggableConnection.h:
* inspector/remote/RemoteInspectorDebuggableConnection.mm:
(Inspector::RemoteInspectorHandleRunSourceGlobal):
(Inspector::RemoteInspectorQueueTaskOnGlobalQueue):
(Inspector::RemoteInspectorInitializeGlobalQueue):
(Inspector::RemoteInspectorHandleRunSourceWithInfo):
(Inspector::RemoteInspectorDebuggableConnection::setup):
(Inspector::RemoteInspectorDebuggableConnection::closeFromDebuggable):
(Inspector::RemoteInspectorDebuggableConnection::close):
(Inspector::RemoteInspectorDebuggableConnection::sendMessageToBackend):
(Inspector::RemoteInspectorDebuggableConnection::queueTaskOnPrivateRunLoop):
* interpreter/JSStack.cpp:
(JSC::JSStack::JSStack):
(JSC::JSStack::releaseExcessCapacity):
(JSC::JSStack::addToCommittedByteCount):
(JSC::JSStack::committedByteCount):
(JSC::stackStatisticsMutex): Deleted.
(JSC::JSStack::initializeThreading): Deleted.
* interpreter/JSStack.h:
(JSC::JSStack::gatherConservativeRoots):
(JSC::JSStack::sanitizeStack):
(JSC::JSStack::size):
(JSC::JSStack::initializeThreading): Deleted.
* jit/ExecutableAllocator.cpp:
(JSC::DemandExecutableAllocator::DemandExecutableAllocator):
(JSC::DemandExecutableAllocator::~DemandExecutableAllocator):
(JSC::DemandExecutableAllocator::bytesAllocatedByAllAllocators):
(JSC::DemandExecutableAllocator::bytesCommittedByAllocactors):
(JSC::DemandExecutableAllocator::dumpProfileFromAllAllocators):
(JSC::DemandExecutableAllocator::allocators):
(JSC::DemandExecutableAllocator::allocatorsMutex):
* jit/JITThunks.cpp:
(JSC::JITThunks::ctiStub):
* jit/JITThunks.h:
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::ensureBytecodesFor):
(JSC::Profiler::Database::notifyDestruction):
* profiler/ProfilerDatabase.h:
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSLock.cpp:
(JSC::GlobalJSLock::GlobalJSLock):
(JSC::GlobalJSLock::~GlobalJSLock):
(JSC::JSLockHolder::JSLockHolder):
(JSC::GlobalJSLock::initialize): Deleted.
* runtime/JSLock.h:
2015-08-14 Ryosuke Niwa <rniwa@webkit.org>
ES6 class syntax should allow computed name method
https://bugs.webkit.org/show_bug.cgi?id=142690
Reviewed by Saam Barati.
Added a new "attributes" attribute to op_put_getter_by_id, op_put_setter_by_id, op_put_getter_setter to specify
the property descriptor options so that we can use use op_put_setter_by_id and op_put_getter_setter to define
getters and setters for classes. Without this, getters and setters could erroneously override methods.
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitDirectPutById):
(JSC::BytecodeGenerator::emitPutGetterById):
(JSC::BytecodeGenerator::emitPutSetterById):
(JSC::BytecodeGenerator::emitPutGetterSetter):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::PropertyListNode::emitBytecode): Always use emitPutGetterSetter to emit getters and setters for classes
as done for object literals.
(JSC::PropertyListNode::emitPutConstantProperty):
(JSC::ClassExprNode::emitBytecode):
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_put_getter_by_id):
(JSC::JIT::emit_op_put_setter_by_id):
(JSC::JIT::emit_op_put_getter_setter):
(JSC::JIT::emit_op_del_by_id):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_put_getter_by_id):
(JSC::JIT::emit_op_put_setter_by_id):
(JSC::JIT::emit_op_put_getter_setter):
(JSC::JIT::emit_op_del_by_id):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter.asm:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createProperty):
(JSC::ASTBuilder::createPropertyList):
* parser/NodeConstructors.h:
(JSC::PropertyNode::PropertyNode):
* parser/Nodes.h:
(JSC::PropertyNode::expressionName):
(JSC::PropertyNode::name):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass): Added the support for computed property name. We don't support computed names
for getters and setters.
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createProperty):
* runtime/JSObject.cpp:
(JSC::JSObject::allowsAccessFrom):
(JSC::JSObject::putGetter):
(JSC::JSObject::putSetter):
* runtime/JSObject.h:
* runtime/PropertyDescriptor.h:
2015-08-13 Yusuke Suzuki <utatane.tea@gmail.com>
Add InspectorInstrumentation builtin object to instrument the code in JS builtins like Promises
https://bugs.webkit.org/show_bug.cgi?id=147942
Reviewed by Geoffrey Garen.
This patch adds new private global object, @InspectorInstrumentation.
It is intended to be used as the namespace object (like Reflect/Math) for Inspector's
instrumentation system and it is used to instrument the builtin JS code, like Promises.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/InspectorInstrumentationObject.js: Added.
(debug):
(promiseFulfilled):
(promiseRejected):
* builtins/Operations.Promise.js:
(rejectPromise):
(fulfillPromise):
* runtime/CommonIdentifiers.h:
* runtime/InspectorInstrumentationObject.cpp: Added.
(JSC::InspectorInstrumentationObject::InspectorInstrumentationObject):
(JSC::InspectorInstrumentationObject::finishCreation):
(JSC::InspectorInstrumentationObject::getOwnPropertySlot):
(JSC::InspectorInstrumentationObject::isEnabled):
(JSC::InspectorInstrumentationObject::enable):
(JSC::InspectorInstrumentationObject::disable):
(JSC::inspectorInstrumentationObjectDataLogImpl):
* runtime/InspectorInstrumentationObject.h: Added.
(JSC::InspectorInstrumentationObject::create):
(JSC::InspectorInstrumentationObject::createStructure):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
2015-08-14 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r188444.
https://bugs.webkit.org/show_bug.cgi?id=148029
Broke GTK and EFL (see bug #148027) (Requested by philn on
#webkit).
Reverted changeset:
"Use WTF::Lock and WTF::Condition instead of WTF::Mutex,
WTF::ThreadCondition, std::mutex, and std::condition_variable"
https://bugs.webkit.org/show_bug.cgi?id=147999
http://trac.webkit.org/changeset/188444
2015-08-13 Filip Pizlo <fpizlo@apple.com>
Use WTF::Lock and WTF::Condition instead of WTF::Mutex, WTF::ThreadCondition, std::mutex, and std::condition_variable
https://bugs.webkit.org/show_bug.cgi?id=147999
Reviewed by Geoffrey Garen.
* API/JSVirtualMachine.mm:
(initWrapperCache):
(+[JSVMWrapperCache addWrapper:forJSContextGroupRef:]):
(+[JSVMWrapperCache wrapperForJSContextGroupRef:]):
(wrapperCacheMutex): Deleted.
* bytecode/SamplingTool.cpp:
(JSC::SamplingTool::doRun):
(JSC::SamplingTool::notifyOfScope):
* bytecode/SamplingTool.h:
* dfg/DFGThreadData.h:
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::~Worklist):
(JSC::DFG::Worklist::isActiveForVM):
(JSC::DFG::Worklist::enqueue):
(JSC::DFG::Worklist::compilationState):
(JSC::DFG::Worklist::waitUntilAllPlansForVMAreReady):
(JSC::DFG::Worklist::removeAllReadyPlansForVM):
(JSC::DFG::Worklist::completeAllReadyPlansForVM):
(JSC::DFG::Worklist::visitWeakReferences):
(JSC::DFG::Worklist::removeDeadPlans):
(JSC::DFG::Worklist::queueLength):
(JSC::DFG::Worklist::dump):
(JSC::DFG::Worklist::runThread):
* dfg/DFGWorklist.h:
* disassembler/Disassembler.cpp:
* heap/CopiedSpace.cpp:
(JSC::CopiedSpace::doneFillingBlock):
(JSC::CopiedSpace::doneCopying):
* heap/CopiedSpace.h:
* heap/CopiedSpaceInlines.h:
(JSC::CopiedSpace::recycleBorrowedBlock):
(JSC::CopiedSpace::allocateBlockForCopyingPhase):
* heap/GCThread.cpp:
(JSC::GCThread::waitForNextPhase):
(JSC::GCThread::gcThreadMain):
* heap/GCThreadSharedData.cpp:
(JSC::GCThreadSharedData::GCThreadSharedData):
(JSC::GCThreadSharedData::~GCThreadSharedData):
(JSC::GCThreadSharedData::startNextPhase):
(JSC::GCThreadSharedData::endCurrentPhase):
(JSC::GCThreadSharedData::didStartMarking):
(JSC::GCThreadSharedData::didFinishMarking):
* heap/GCThreadSharedData.h:
* heap/HeapTimer.h:
* heap/MachineStackMarker.cpp:
(JSC::ActiveMachineThreadsManager::Locker::Locker):
(JSC::ActiveMachineThreadsManager::add):
(JSC::ActiveMachineThreadsManager::remove):
(JSC::ActiveMachineThreadsManager::ActiveMachineThreadsManager):
(JSC::MachineThreads::~MachineThreads):
(JSC::MachineThreads::addCurrentThread):
(JSC::MachineThreads::removeThreadIfFound):
(JSC::MachineThreads::tryCopyOtherThreadStack):
(JSC::MachineThreads::tryCopyOtherThreadStacks):
(JSC::MachineThreads::gatherConservativeRoots):
* heap/MachineStackMarker.h:
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::donateKnownParallel):
(JSC::SlotVisitor::drain):
(JSC::SlotVisitor::drainFromShared):
(JSC::SlotVisitor::mergeOpaqueRoots):
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::containsOpaqueRootTriState):
* inspector/remote/RemoteInspectorDebuggableConnection.h:
* inspector/remote/RemoteInspectorDebuggableConnection.mm:
(Inspector::RemoteInspectorHandleRunSourceGlobal):
(Inspector::RemoteInspectorQueueTaskOnGlobalQueue):
(Inspector::RemoteInspectorInitializeGlobalQueue):
(Inspector::RemoteInspectorHandleRunSourceWithInfo):
(Inspector::RemoteInspectorDebuggableConnection::setup):
(Inspector::RemoteInspectorDebuggableConnection::closeFromDebuggable):
(Inspector::RemoteInspectorDebuggableConnection::close):
(Inspector::RemoteInspectorDebuggableConnection::sendMessageToBackend):
(Inspector::RemoteInspectorDebuggableConnection::queueTaskOnPrivateRunLoop):
* interpreter/JSStack.cpp:
(JSC::JSStack::JSStack):
(JSC::JSStack::releaseExcessCapacity):
(JSC::JSStack::addToCommittedByteCount):
(JSC::JSStack::committedByteCount):
(JSC::stackStatisticsMutex): Deleted.
(JSC::JSStack::initializeThreading): Deleted.
* interpreter/JSStack.h:
(JSC::JSStack::gatherConservativeRoots):
(JSC::JSStack::sanitizeStack):
(JSC::JSStack::size):
(JSC::JSStack::initializeThreading): Deleted.
* jit/ExecutableAllocator.cpp:
(JSC::DemandExecutableAllocator::DemandExecutableAllocator):
(JSC::DemandExecutableAllocator::~DemandExecutableAllocator):
(JSC::DemandExecutableAllocator::bytesAllocatedByAllAllocators):
(JSC::DemandExecutableAllocator::bytesCommittedByAllocactors):
(JSC::DemandExecutableAllocator::dumpProfileFromAllAllocators):
(JSC::DemandExecutableAllocator::allocators):
(JSC::DemandExecutableAllocator::allocatorsMutex):
* jit/JITThunks.cpp:
(JSC::JITThunks::ctiStub):
* jit/JITThunks.h:
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::ensureBytecodesFor):
(JSC::Profiler::Database::notifyDestruction):
* profiler/ProfilerDatabase.h:
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSLock.cpp:
(JSC::GlobalJSLock::GlobalJSLock):
(JSC::GlobalJSLock::~GlobalJSLock):
(JSC::JSLockHolder::JSLockHolder):
(JSC::GlobalJSLock::initialize): Deleted.
* runtime/JSLock.h:
2015-08-13 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r188428.
https://bugs.webkit.org/show_bug.cgi?id=148015
broke cmake build (Requested by alexchristensen on #webkit).
Reverted changeset:
"Move some commands from ./CMakeLists.txt to Source/cmake"
https://bugs.webkit.org/show_bug.cgi?id=148003
http://trac.webkit.org/changeset/188428
2015-08-13 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r188431.
https://bugs.webkit.org/show_bug.cgi?id=148013
JSC headers are too hard to understand (Requested by smfr on
#webkit).
Reverted changeset:
"Remove a few includes from JSGlobalObject.h"
https://bugs.webkit.org/show_bug.cgi?id=148004
http://trac.webkit.org/changeset/188431
2015-08-13 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add support for GetByVal on arrays of Undecided shape
https://bugs.webkit.org/show_bug.cgi?id=147814
Reviewed by Filip Pizlo.
Previously, GetByVal on Array::Undecided would just take
the generic path. The problem is the generic path is so
slow that it could take a significant amount of time
even for unfrequent accesses.
With this patch, if the following conditions are met,
the GetByVal just returns a "undefined" constant:
-The object is an OriginalArray.
-The prototype chain is sane.
-The index is an integer.
-The integer is positive (runtime check).
Ideally, the 4th conditions should be removed
deducing a compile-time constant gives us so much better
opportunities at getting rid of this code.
There are two cases where this patch removes the runtime
check:
-If the index is constant (uncommon but easy)
-If the index is within a range known to be positive.
(common case and made possible with DFGIntegerRangeOptimizationPhase).
When we get into those cases, DFG just nukes everything
and all we have left is a structure check :)
This patch is a 14% improvement on audio-beat-detection,
a few percent faster here and there and no regression.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
If the index is a positive constant, we can get rid of the GetByVal
entirely. :)
* dfg/DFGArrayMode.cpp:
(JSC::DFG::ArrayMode::fromObserved):
The returned type is now Array::Undecided + profiling information.
The useful type is set in ArrayMode::refine().
(JSC::DFG::ArrayMode::refine):
If we meet the particular set conditions, we speculate an Undecided
array type with sane chain. Anything else comes back to Generic.
(JSC::DFG::ArrayMode::originalArrayStructure):
To enable the structure check for Undecided array.
(JSC::DFG::ArrayMode::alreadyChecked):
* dfg/DFGArrayMode.h:
(JSC::DFG::ArrayMode::withProfile):
(JSC::DFG::ArrayMode::canCSEStorage):
(JSC::DFG::ArrayMode::benefitsFromOriginalArray):
(JSC::DFG::ArrayMode::lengthNeedsStorage): Deleted.
(JSC::DFG::ArrayMode::isSpecific): Deleted.A
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsic): Deleted.
This is somewhat unrelated.
Having Array::Undecided on ArrayPush was impossible before
since ArrayMode::fromObserved() used to return Array::Generic.
Now that Array::Undecided is possible, we must make sure not
to provide it to ArrayPush since there is no code to handle it
properly.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
The operation only depends on the index, it is pure.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode): Deleted.
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode):
(JSC::DFG::SpeculativeJIT::checkArray):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileGetByVal):
* tests/stress/get-by-val-on-undecided-array-type.js: Added.
* tests/stress/get-by-val-on-undecided-sane-chain-1.js: Added.
* tests/stress/get-by-val-on-undecided-sane-chain-2.js: Added.
* tests/stress/get-by-val-on-undecided-sane-chain-3.js: Added.
* tests/stress/get-by-val-on-undecided-sane-chain-4.js: Added.
* tests/stress/get-by-val-on-undecided-sane-chain-5.js: Added.
* tests/stress/get-by-val-on-undecided-sane-chain-6.js: Added.
2015-08-13 Simon Fraser <simon.fraser@apple.com>
Remove a few includes from JSGlobalObject.h
https://bugs.webkit.org/show_bug.cgi?id=148004
Reviewed by Tim Horton.
Remove 4 #includes from JSGlobalObject.h, and fix the fallout.
* parser/VariableEnvironment.cpp:
* parser/VariableEnvironment.h:
* runtime/JSGlobalObject.h:
* runtime/Structure.h:
* runtime/StructureInlines.h:
2015-08-13 Alex Christensen <achristensen@webkit.org>
Move some commands from ./CMakeLists.txt to Source/cmake
https://bugs.webkit.org/show_bug.cgi?id=148003
Reviewed by Brent Fulgham.
* CMakeLists.txt:
Added commands needed to build JSC by itself.
2015-08-13 Yusuke Suzuki <utatane.tea@gmail.com>
Unify JSParserCodeType, FunctionParseMode and ModuleParseMode into SourceParseMode
https://bugs.webkit.org/show_bug.cgi?id=147353
Reviewed by Saam Barati.
This is the follow-up patch after r188355.
It includes the following changes.
- Unify JSParserCodeType, FunctionParseMode and ModuleParseMode into SourceParseMode
- Make SourceParseMode to C++ strongly-typed enum.
- Fix the comments.
- Rename ModuleSpecifier to ModuleName.
- Add the type name `ImportEntry` before the C++11 uniform initialization.
- Fix the thrown message for duplicate 'default' names.
- Assert the all statements in the top-level source elements are the module declarations under the module analyzer phase.
* API/JSScriptRef.cpp:
(parseScript):
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createExecutableInternal):
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::generateFunctionCodeBlock):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::makeFunction):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionMetadata):
(JSC::ASTBuilder::createModuleName):
(JSC::ASTBuilder::createImportDeclaration):
(JSC::ASTBuilder::createExportAllDeclaration):
(JSC::ASTBuilder::createExportNamedDeclaration):
(JSC::ASTBuilder::createModuleSpecifier): Deleted.
* parser/ModuleAnalyzer.cpp:
(JSC::ModuleAnalyzer::analyze):
* parser/NodeConstructors.h:
(JSC::ModuleNameNode::ModuleNameNode):
(JSC::ImportDeclarationNode::ImportDeclarationNode):
(JSC::ExportAllDeclarationNode::ExportAllDeclarationNode):
(JSC::ExportNamedDeclarationNode::ExportNamedDeclarationNode):
(JSC::ModuleSpecifierNode::ModuleSpecifierNode): Deleted.
* parser/Nodes.cpp:
(JSC::FunctionMetadataNode::FunctionMetadataNode):
* parser/Nodes.h:
(JSC::StatementNode::isModuleDeclarationNode):
(JSC::ModuleDeclarationNode::isModuleDeclarationNode):
(JSC::ImportDeclarationNode::moduleName):
(JSC::ExportAllDeclarationNode::moduleName):
(JSC::ExportNamedDeclarationNode::moduleName):
(JSC::ImportDeclarationNode::moduleSpecifier): Deleted.
(JSC::ExportAllDeclarationNode::moduleSpecifier): Deleted.
(JSC::ExportNamedDeclarationNode::moduleSpecifier): Deleted.
* parser/NodesAnalyzeModule.cpp:
(JSC::SourceElements::analyzeModule):
(JSC::ImportDeclarationNode::analyzeModule):
(JSC::ExportAllDeclarationNode::analyzeModule):
(JSC::ExportNamedDeclarationNode::analyzeModule):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::Parser):
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseModuleSourceElements):
(JSC::Parser<LexerType>::parseFunctionBody):
(JSC::stringForFunctionMode):
(JSC::Parser<LexerType>::parseFunctionParameters):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseModuleName):
(JSC::Parser<LexerType>::parseImportDeclaration):
(JSC::Parser<LexerType>::parseExportDeclaration):
(JSC::Parser<LexerType>::parsePropertyMethod):
(JSC::Parser<LexerType>::parseGetterSetter):
(JSC::Parser<LexerType>::parsePrimaryExpression):
(JSC::Parser<LexerType>::parseArrowFunctionExpression):
(JSC::Parser<LexerType>::parseModuleSpecifier): Deleted.
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
(JSC::parse):
* parser/ParserModes.h:
(JSC::isFunctionParseMode):
(JSC::isModuleParseMode):
(JSC::isProgramParseMode):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionMetadata):
(JSC::SyntaxChecker::createModuleName):
(JSC::SyntaxChecker::createImportDeclaration):
(JSC::SyntaxChecker::createExportAllDeclaration):
(JSC::SyntaxChecker::createExportNamedDeclaration):
(JSC::SyntaxChecker::createModuleSpecifier): Deleted.
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/Completion.cpp:
(JSC::checkSyntax):
(JSC::checkModuleSyntax):
* runtime/Executable.cpp:
(JSC::ProgramExecutable::checkSyntax):
* tests/stress/modules-syntax-error-with-names.js:
2015-08-13 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: A {Map, WeakMap, Set, WeakSet} object contains itself will hang the console
https://bugs.webkit.org/show_bug.cgi?id=147966
Reviewed by Timothy Hatcher.
* inspector/InjectedScriptSource.js:
(InjectedScript.prototype._initialPreview):
Renamed to initial preview. This is not a complete preview for
this object, and it needs some processing in order to be a
complete accurate preview.
(InjectedScript.RemoteObject.prototype._emptyPreview):
This attempts to be an accurate empty preview for the given object.
For types with entries, it adds an empty entries list and updates
the overflow and lossless properties.
(InjectedScript.RemoteObject.prototype._createObjectPreviewForValue):
Take a generatePreview parameter to generate a full preview or empty preview.
(InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
(InjectedScript.RemoteObject.prototype._appendEntryPreviews):
(InjectedScript.RemoteObject.prototype._isPreviewableObject):
Take care to avoid cycles.
2015-08-13 Geoffrey Garen <ggaren@apple.com>
Periodic code deletion should delete RegExp code
https://bugs.webkit.org/show_bug.cgi?id=147990
Reviewed by Filip Pizlo.
The RegExp code cache was created for the sake of simple loops that
re-created the same RegExps. It's reasonable to delete it periodically.
* heap/Heap.cpp:
(JSC::Heap::deleteOldCode):
2015-08-13 Geoffrey Garen <ggaren@apple.com>
RegExpCache::finalize should not delete code
https://bugs.webkit.org/show_bug.cgi?id=147987
Reviewed by Mark Lam.
The RegExp object already knows how to delete its own code in its
destructor. Our job is just to clear our stale pointer.
* runtime/RegExpCache.cpp:
(JSC::RegExpCache::finalize):
(JSC::RegExpCache::addToStrongCache):
2015-08-13 Geoffrey Garen <ggaren@apple.com>
Standardize on the phrase "delete code"
https://bugs.webkit.org/show_bug.cgi?id=147984
Reviewed by Mark Lam.
Use "delete" when we talk about throwing away code, as opposed to
"invalidate" or "discard".
* debugger/Debugger.cpp:
(JSC::Debugger::forEachCodeBlock):
(JSC::Debugger::setSteppingMode):
(JSC::Debugger::recompileAllJSFunctions):
* heap/Heap.cpp:
(JSC::Heap::deleteAllCompiledCode):
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::recompileAllJSFunctionsForTypeProfiling):
* runtime/RegExp.cpp:
(JSC::RegExp::match):
(JSC::RegExp::deleteCode):
(JSC::RegExp::invalidateCode): Deleted.
* runtime/RegExp.h:
* runtime/RegExpCache.cpp:
(JSC::RegExpCache::finalize):
(JSC::RegExpCache::addToStrongCache):
(JSC::RegExpCache::deleteAllCode):
(JSC::RegExpCache::invalidateCode): Deleted.
* runtime/RegExpCache.h:
* runtime/VM.cpp:
(JSC::VM::stopSampling):
(JSC::VM::prepareToDeleteCode):
(JSC::VM::deleteAllCode):
(JSC::VM::setEnabledProfiler):
(JSC::VM::prepareToDiscardCode): Deleted.
(JSC::VM::discardAllCode): Deleted.
* runtime/VM.h:
(JSC::VM::apiLock):
(JSC::VM::codeCache):
* runtime/Watchdog.cpp:
(JSC::Watchdog::setTimeLimit):
2015-08-13 Yusuke Suzuki <utatane.tea@gmail.com>
X.[[SetPrototypeOf]](Y) should succeed if X.[[Prototype]] is already Y even if X is not extensible
https://bugs.webkit.org/show_bug.cgi?id=147930
Reviewed by Saam Barati.
When the passed prototype object to be set is the same to the existing
prototype object, [[SetPrototypeOf]] just finishes its operation even
if the extensibility of the target object is `false`.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncProtoSetter):
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorSetPrototypeOf):
* runtime/ReflectObject.cpp:
(JSC::reflectObjectSetPrototypeOf):
* tests/stress/set-same-prototype.js: Added.
(shouldBe):
(shouldThrow):
2015-08-12 Geoffrey Garen <ggaren@apple.com>
Removed clearEvalCodeCache()
https://bugs.webkit.org/show_bug.cgi?id=147957
Reviewed by Filip Pizlo.
It was unused.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::linkIncomingCall):
(JSC::CodeBlock::install):
(JSC::CodeBlock::clearEvalCache): Deleted.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::numberOfJumpTargets):
(JSC::CodeBlock::jumpTarget):
(JSC::CodeBlock::numberOfArgumentValueProfiles):
2015-08-12 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement Reflect.defineProperty
https://bugs.webkit.org/show_bug.cgi?id=147943
Reviewed by Saam Barati.
This patch implements Reflect.defineProperty.
The difference from the Object.defineProperty is,
1. Reflect.defineProperty does not perform ToObject operation onto the first argument.
2. Reflect.defineProperty does not throw a TypeError when the [[DefineOwnProperty]] operation fails.
3. Reflect.defineProperty returns the boolean value that represents whether [[DefineOwnProperty]] succeeded.
And this patch comments the links to the ES6 spec.
* builtins/ReflectObject.js:
* runtime/ObjectConstructor.cpp:
(JSC::toPropertyDescriptor):
* runtime/ObjectConstructor.h:
* runtime/ReflectObject.cpp:
(JSC::reflectObjectDefineProperty):
* tests/stress/reflect-define-property.js: Added.
(shouldBe):
(shouldThrow):
(.set getter):
(setter):
(.get testDescriptor):
(.set get var):
(.set testDescriptor):
(.set get testDescriptor):
(.set get shouldThrow):
(.get var):
2015-08-12 Filip Pizlo <fpizlo@apple.com>
DFG::ByteCodeParser should attempt constant folding on loads from structures that are DFG-watchable
https://bugs.webkit.org/show_bug.cgi?id=147950
Reviewed by Michael Saboff.
Previously we reduced the constant folding power of ByteCodeParser::load() because that code was
responsible for memory corruption, since it would sometimes install watchpoints on structures that
weren't being traced. It seemed like the safest fix was to remove the constant folding rule
entirely since later phases also do constant folding, and they do it without introducing the bug.
Well, that change (http://trac.webkit.org/changeset/188292) caused a big regression, because we
still have some constant folding rules that only exist in ByteCodeParser, and so ByteCodeParser must
be maximally aggressive in constant-folding whenever possible.
So, this change now brings back that constant folding rule - for loads from object constants that
have DFG-watchable structures - and implements it properly, by ensuring that we only call into
tryGetConstantProperty() if we have registered the structure set.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::load):
2015-08-12 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Add ES6 Modules preparsing phase to collect the dependencies
https://bugs.webkit.org/show_bug.cgi?id=147353
Reviewed by Geoffrey Garen.
This patch implements ModuleRecord and ModuleAnalyzer.
ModuleAnalyzer analyzes the produced AST from the parser.
By collaborating with the parser, ModuleAnalyzer collects the information
that is necessary to request the loading for the dependent modules and
construct module's environment and namespace object before executing the actual
module body.
In the parser, we annotate which variable is imported binding and which variable
is exported from the current module. This information is leveraged in the ModuleAnalyzer
to categorize the export entries.
To preparse the modules in the parser, we just add the new flag `ModuleParseMode`
instead of introducing a new TreeContext type. This is because only 2 users use the
parseModuleSourceElements; preparser and actual compiler. Adding the flag is simple
enough to switch the context to the SyntaxChecker when parsing the non-module related
statement in the preparsing phase.
To demonstrate the module analyzer, we added the new option dumpModuleRecord option
into the JSC shell. By specifying this, the result of analysis is dumped when the module
is parsed and analyzed.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/BuiltinNames.h:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createExportDefaultDeclaration):
* parser/ModuleAnalyzer.cpp: Added.
(JSC::ModuleAnalyzer::ModuleAnalyzer):
(JSC::ModuleAnalyzer::exportedBinding):
(JSC::ModuleAnalyzer::declareExportAlias):
(JSC::ModuleAnalyzer::exportVariable):
(JSC::ModuleAnalyzer::analyze):
* parser/ModuleAnalyzer.h: Added.
(JSC::ModuleAnalyzer::vm):
(JSC::ModuleAnalyzer::moduleRecord):
* parser/ModuleRecord.cpp: Added.
(JSC::printableName):
(JSC::ModuleRecord::dump):
* parser/ModuleRecord.h: Added.
(JSC::ModuleRecord::ImportEntry::isNamespace):
(JSC::ModuleRecord::create):
(JSC::ModuleRecord::appendRequestedModule):
(JSC::ModuleRecord::addImportEntry):
(JSC::ModuleRecord::addExportEntry):
(JSC::ModuleRecord::addStarExportEntry):
* parser/NodeConstructors.h:
(JSC::ModuleDeclarationNode::ModuleDeclarationNode):
(JSC::ImportDeclarationNode::ImportDeclarationNode):
(JSC::ExportAllDeclarationNode::ExportAllDeclarationNode):
(JSC::ExportDefaultDeclarationNode::ExportDefaultDeclarationNode):
(JSC::ExportLocalDeclarationNode::ExportLocalDeclarationNode):
(JSC::ExportNamedDeclarationNode::ExportNamedDeclarationNode):
* parser/Nodes.h:
(JSC::ExportDefaultDeclarationNode::localName):
* parser/NodesAnalyzeModule.cpp: Added.
(JSC::ScopeNode::analyzeModule):
(JSC::SourceElements::analyzeModule):
(JSC::ImportDeclarationNode::analyzeModule):
(JSC::ExportAllDeclarationNode::analyzeModule):
(JSC::ExportDefaultDeclarationNode::analyzeModule):
(JSC::ExportLocalDeclarationNode::analyzeModule):
(JSC::ExportNamedDeclarationNode::analyzeModule):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseModuleSourceElements):
(JSC::Parser<LexerType>::parseVariableDeclarationList):
(JSC::Parser<LexerType>::createBindingPattern):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseClassDeclaration):
(JSC::Parser<LexerType>::parseImportClauseItem):
(JSC::Parser<LexerType>::parseExportSpecifier):
(JSC::Parser<LexerType>::parseExportDeclaration):
* parser/Parser.h:
(JSC::Scope::lexicalVariables):
(JSC::Scope::declareLexicalVariable):
(JSC::Parser::declareVariable):
(JSC::Parser::exportName):
(JSC::Parser<LexerType>::parse):
(JSC::parse):
* parser/ParserModes.h:
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createExportDefaultDeclaration):
* parser/VariableEnvironment.cpp:
(JSC::VariableEnvironment::markVariableAsImported):
(JSC::VariableEnvironment::markVariableAsExported):
* parser/VariableEnvironment.h:
(JSC::VariableEnvironmentEntry::isExported):
(JSC::VariableEnvironmentEntry::isImported):
(JSC::VariableEnvironmentEntry::setIsExported):
(JSC::VariableEnvironmentEntry::setIsImported):
* runtime/CommonIdentifiers.h:
* runtime/Completion.cpp:
(JSC::checkModuleSyntax):
* runtime/Options.h:
2015-08-12 Geoffrey Garen <ggaren@apple.com>
Re-land r188339, since Alex fixed it in r188341 by landing the WebCore half.
* jit/ExecutableAllocator.h:
* jsc.cpp:
(GlobalObject::finishCreation):
(functionAddressOf):
(functionVersion):
(functionReleaseExecutableMemory): Deleted.
* runtime/VM.cpp:
(JSC::StackPreservingRecompiler::operator()):
(JSC::VM::throwException):
(JSC::VM::updateFTLLargestStackSize):
(JSC::VM::gatherConservativeRoots):
(JSC::VM::releaseExecutableMemory): Deleted.
(JSC::releaseExecutableMemory): Deleted.
* runtime/VM.h:
(JSC::VM::isCollectorBusy):
* runtime/Watchdog.cpp:
(JSC::Watchdog::setTimeLimit):
2015-08-12 Jon Honeycutt <jhoneycutt@apple.com>
Roll out r188339, which broke the build.
Unreviewed.
* jit/ExecutableAllocator.h:
* jsc.cpp:
(GlobalObject::finishCreation):
(functionReleaseExecutableMemory):
* runtime/VM.cpp:
(JSC::StackPreservingRecompiler::visit):
(JSC::StackPreservingRecompiler::operator()):
(JSC::VM::releaseExecutableMemory):
(JSC::releaseExecutableMemory):
* runtime/VM.h:
* runtime/Watchdog.cpp:
(JSC::Watchdog::setTimeLimit):
2015-08-12 Alex Christensen <achristensen@webkit.org>
Fix Debug CMake builds on Windows
https://bugs.webkit.org/show_bug.cgi?id=147940
Reviewed by Chris Dumez.
* PlatformWin.cmake:
Copy the plist to the JavaScriptCore.resources directory.
2015-08-11 Geoffrey Garen <ggaren@apple.com>
Remove VM::releaseExecutableMemory
https://bugs.webkit.org/show_bug.cgi?id=147915
Reviewed by Saam Barati.
releaseExecutableMemory() was only used in one place, where discardAllCode()
would work just as well.
It's confusing to have two slightly different ways to discard code. Also,
releaseExecutableMemory() is unused in any production code, and it seems
to have bit-rotted.
* jit/ExecutableAllocator.h:
* jsc.cpp:
(GlobalObject::finishCreation):
(functionAddressOf):
(functionVersion):
(functionReleaseExecutableMemory): Deleted.
* runtime/VM.cpp:
(JSC::StackPreservingRecompiler::operator()):
(JSC::VM::throwException):
(JSC::VM::updateFTLLargestStackSize):
(JSC::VM::gatherConservativeRoots):
(JSC::VM::releaseExecutableMemory): Deleted.
(JSC::releaseExecutableMemory): Deleted.
* runtime/VM.h:
(JSC::VM::isCollectorBusy):
* runtime/Watchdog.cpp:
(JSC::Watchdog::setTimeLimit):
2015-08-12 Mark Lam <mark.lam@apple.com>
Add a JSC option to enable the watchdog for testing.
https://bugs.webkit.org/show_bug.cgi?id=147939
Reviewed by Michael Saboff.
* API/JSContextRef.cpp:
(JSContextGroupSetExecutionTimeLimit):
(createWatchdogIfNeeded): Deleted.
* runtime/Options.h:
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::~VM):
(JSC::VM::sharedInstanceInternal):
(JSC::VM::ensureWatchdog):
(JSC::thunkGeneratorForIntrinsic):
* runtime/VM.h:
2015-08-11 Mark Lam <mark.lam@apple.com>
Implementation JavaScript watchdog using WTF::WorkQueue.
https://bugs.webkit.org/show_bug.cgi?id=147107
Reviewed by Geoffrey Garen.
How the Watchdog works?
======================
1. When do we start the Watchdog?
=============================
The watchdog should only be started if both the following conditions are true:
1. A time limit has been set.
2. We have entered the VM.
2. CPU time vs Wall Clock time
===========================
Why do we need 2 time deadlines: m_cpuDeadline and m_wallClockDeadline?
The watchdog uses WorkQueue dispatchAfter() to queue a timer to measure the watchdog time
limit. WorkQueue timers measure time in monotonic wall clock time. m_wallClockDeadline
indicates the wall clock time point when the WorkQueue timer is expected to fire.
The time limit for which we allow JS code to run should be measured in CPU time, which can
differ from wall clock time. m_cpuDeadline indicates the CPU time point when the watchdog
should fire.
Note: the timer firing is not the same thing as the watchdog firing. When the timer fires,
we need to check if m_cpuDeadline has been reached.
If m_cpuDeadline has been reached, the watchdog is considered to have fired.
If not, then we have a remaining amount of CPU time, Tremainder, that we should allow JS
code to continue to run for. Hence, we need to start a new timer to fire again after
Tremainder microseconds.
See Watchdog::didFireSlow().
3. Spurious wake ups
=================
Because the WorkQueue timer cannot be cancelled, the watchdog needs to ignore stale timers.
It does this by checking the m_wallClockDeadline. A wakeup that occurs right after
m_wallClockDeadline expires is considered to be the wakeup for the active timer. All other
wake ups are considered to be spurious and will be ignored.
See Watchdog::didFireSlow().
4. Minimizing Timer creation cost
==============================
Conceptually, we could start a new timer every time we start the watchdog. But we can do better
than this.
In practice, the time limit of a watchdog tends to be long, and the amount of time a watchdog
stays active tends to be short for well-behaved JS code. The user also tends to re-use the same
time limit. Consider the following example:
|---|-----|---|----------------|---------|
t0 t1 t2 t3 t0 + L t2 + L
|<--- T1 --------------------->|
|<--- T2 --------------------->|
|<-- Td ->| |<-- Td ->|
1. The user initializes the watchdog with time limit L.
2. At t0, we enter the VM to execute JS code, and starts the watchdog timer, T1.
The timer is set to expire at t0 + L.
3. At t1, we exit the VM.
4. At t2, we enter the VM again, and would like to start a new watchdog timer, T2.
However, we can note that the expiration time for T2 would be after the expiration time
of T1. Specifically, T2 would have expired at Td after T1 expires.
Hence, we can just wait for T1 to expire, and then start a new timer T2' at time t0 + L
for a period or Td instead.
Note that didFireSlow() already compensates for time differences between wall clock and CPU time,
as well as handle spurious wake ups (see note 2 and 3 above). As a result, didFireSlow() will
automatically take care of starting a new timer for the difference Td in the example above.
Instead of starting the new timer T2 and time t2, we just verify that if the active timer, T1's
expiration is less than T2s, then we are already covered by T1 and there's no need to start T2.
The benefit:
1. we minimize the number of timer instances we have queued in the workqueue at the same time
(ideally only 1 or 0), and use less peak memory usage.
2. we minimize the frequency of instantiating timer instances. By waiting for the current
active timer to expire first, on average, we get to start one timer per time limit
(which is infrequent because time limits tend to be long) instead of one timer per
VM entry (which tends to be frequent).
See Watchdog::startTimer().
* API/JSContextRef.cpp:
(createWatchdogIfNeeded):
(JSContextGroupClearExecutionTimeLimit):
- No need to create the watchdog (if not already created) just to clear it.
If the watchdog is not created yet, then it is effectively cleared.
* API/tests/ExecutionTimeLimitTest.cpp:
(currentCPUTimeAsJSFunctionCallback):
(testExecutionTimeLimit):
(currentCPUTime): Deleted.
* API/tests/testapi.c:
(main):
* JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
* JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters:
- Enable watchdog tests for all platforms.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
- Remove now unneeded WatchdogMac.cpp and WatchdogNone.cpp.
* PlatformEfl.cmake:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGSpeculativeJIT32_64.cpp:
* dfg/DFGSpeculativeJIT64.cpp:
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_loop_hint):
(JSC::JIT::emitSlow_op_loop_hint):
* jit/JITOperations.cpp:
* llint/LLIntOffsetsExtractor.cpp:
* llint/LLIntSlowPaths.cpp:
* runtime/VM.cpp:
- #include Watchdog.h in these files directly instead of doing it via VM.h.
These saves us from having to recompile the world when we change Watchdog.h.
* runtime/VM.h:
- See comment in Watchdog::startTimer() below for why the Watchdog needs to be
thread-safe ref counted.
* runtime/VMEntryScope.cpp:
(JSC::VMEntryScope::VMEntryScope):
(JSC::VMEntryScope::~VMEntryScope):
- We have done away with the WatchdogScope and arming/disarming of the watchdog.
Instead, the VMEntryScope will inform the watchdog of when we have entered and
exited the VM.
* runtime/Watchdog.cpp:
(JSC::currentWallClockTime):
(JSC::Watchdog::Watchdog):
(JSC::Watchdog::hasStartedTimer):
(JSC::Watchdog::setTimeLimit):
(JSC::Watchdog::didFireSlow):
(JSC::Watchdog::hasTimeLimit):
(JSC::Watchdog::fire):
(JSC::Watchdog::enteredVM):
(JSC::Watchdog::exitedVM):
(JSC::Watchdog::startTimer):
- The Watchdog is now thread-safe ref counted because the WorkQueue may access it
(from a different thread) even after the VM shuts down. We need to keep it
alive until the WorkQueue callback completes.
In Watchdog::startTimer(), we'll ref the Watchdog to keep it alive for each
WorkQueue callback we dispatch. The callback will deref the Watchdog after it
is done with it. This ensures that the Watchdog is kept alive until all
WorkQueue callbacks are done.
(JSC::Watchdog::stopTimer):
(JSC::Watchdog::~Watchdog): Deleted.
(JSC::Watchdog::didFire): Deleted.
(JSC::Watchdog::isEnabled): Deleted.
(JSC::Watchdog::arm): Deleted.
(JSC::Watchdog::disarm): Deleted.
(JSC::Watchdog::startCountdownIfNeeded): Deleted.
(JSC::Watchdog::startCountdown): Deleted.
(JSC::Watchdog::stopCountdown): Deleted.
* runtime/Watchdog.h:
(JSC::Watchdog::didFire):
(JSC::Watchdog::timerDidFireAddress):
(JSC::Watchdog::isArmed): Deleted.
(JSC::Watchdog::Scope::Scope): Deleted.
(JSC::Watchdog::Scope::~Scope): Deleted.
* runtime/WatchdogMac.cpp:
(JSC::Watchdog::initTimer): Deleted.
(JSC::Watchdog::destroyTimer): Deleted.
(JSC::Watchdog::startTimer): Deleted.
(JSC::Watchdog::stopTimer): Deleted.
* runtime/WatchdogNone.cpp:
(JSC::Watchdog::initTimer): Deleted.
(JSC::Watchdog::destroyTimer): Deleted.
(JSC::Watchdog::startTimer): Deleted.
(JSC::Watchdog::stopTimer): Deleted.
2015-08-11 Filip Pizlo <fpizlo@apple.com>
Always use a byte-sized lock implementation
https://bugs.webkit.org/show_bug.cgi?id=147908
Reviewed by Geoffrey Garen.
* runtime/ConcurrentJITLock.h: Lock is now byte-sized and ByteLock is gone, so use Lock.
2015-08-11 Alexey Proskuryakov <ap@apple.com>
Make ASan build not depend on asan.xcconfig
https://bugs.webkit.org/show_bug.cgi?id=147840
rdar://problem/21093702
Reviewed by Daniel Bates.
* dfg/DFGOSREntry.cpp:
(JSC::DFG::OSREntryData::dump):
(JSC::DFG::prepareOSREntry):
* ftl/FTLOSREntry.cpp:
(JSC::FTL::prepareOSREntry):
* heap/ConservativeRoots.cpp:
(JSC::ConservativeRoots::genericAddPointer):
(JSC::ConservativeRoots::genericAddSpan):
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::removeThreadIfFound):
(JSC::MachineThreads::gatherFromCurrentThread):
(JSC::MachineThreads::Thread::captureStack):
(JSC::copyMemory):
* interpreter/Register.h:
(JSC::Register::operator=):
(JSC::Register::asanUnsafeJSValue):
(JSC::Register::jsValue):
2015-08-11 Yusuke Suzuki <utatane.tea@gmail.com>
Introduce get_by_id like IC into get_by_val when the given name is String or Symbol
https://bugs.webkit.org/show_bug.cgi?id=147480
Reviewed by Filip Pizlo.
This patch adds get_by_id IC to get_by_val operation by caching the string / symbol id.
The IC site only caches one id. After checking that the given id is the same to the
cached one, we perform the get_by_id IC onto it.
And by collecting IC StructureStubInfo information, we pass it to the DFG and DFG
compiles get_by_val op code into CheckIdent (with edge type check) and GetById related
operations when the given get_by_val leverages the property load with the cached id.
To ensure the incoming value is the expected id, in DFG layer, we use SymbolUse and
StringIdentUse to enforce the type. To use it, this patch implements SymbolUse.
This can be leveraged to optimize symbol operations in DFG.
And since byValInfo is frequently used, we align the byValInfo design to the stubInfo like one.
Allocated by the Bag and operations take the raw byValInfo pointer directly instead of performing
binary search onto m_byValInfos. And by storing ArrayProfile* under the ByValInfo, we replaced the
argument ArrayProfile* in the operations with ByValInfo*.
* bytecode/ByValInfo.h:
(JSC::ByValInfo::ByValInfo):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::getByValInfoMap):
(JSC::CodeBlock::addByValInfo):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::getByValInfo): Deleted.
(JSC::CodeBlock::setNumberOfByValInfos): Deleted.
(JSC::CodeBlock::numberOfByValInfos): Deleted.
(JSC::CodeBlock::byValInfo): Deleted.
* bytecode/ExitKind.cpp:
(JSC::exitKindToString):
* bytecode/ExitKind.h:
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFor):
(JSC::GetByIdStatus::computeForStubInfo):
(JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
* bytecode/GetByIdStatus.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::observeUseKindOnNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasUidOperand):
(JSC::DFG::Node::uidOperand):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::SafeToExecuteEdge::operator()):
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCheckIdent):
(JSC::DFG::SpeculativeJIT::speculateSymbol):
(JSC::DFG::SpeculativeJIT::speculate):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGUseKind.cpp:
(WTF::printInternal):
* dfg/DFGUseKind.h:
(JSC::DFG::typeFilterFor):
(JSC::DFG::isCell):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCheckIdent):
(JSC::FTL::DFG::LowerDFGToLLVM::lowSymbol):
(JSC::FTL::DFG::LowerDFGToLLVM::speculate):
(JSC::FTL::DFG::LowerDFGToLLVM::isNotSymbol):
(JSC::FTL::DFG::LowerDFGToLLVM::speculateSymbol):
* jit/JIT.cpp:
(JSC::JIT::privateCompile):
* jit/JIT.h:
(JSC::ByValCompilationInfo::ByValCompilationInfo):
(JSC::JIT::compileGetByValWithCachedId):
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_has_indexed_property):
(JSC::JIT::emitSlow_op_has_indexed_property):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_has_indexed_property):
(JSC::JIT::emitSlow_op_has_indexed_property):
* jit/JITOperations.cpp:
(JSC::getByVal):
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emitGetByValWithCachedId):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emit_op_put_by_val):
(JSC::JIT::emitSlow_op_put_by_val):
(JSC::JIT::privateCompileGetByVal):
(JSC::JIT::privateCompileGetByValWithCachedId):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emitGetByValWithCachedId):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emit_op_put_by_val):
(JSC::JIT::emitSlow_op_put_by_val):
* runtime/Symbol.h:
* tests/stress/get-by-val-with-string-constructor.js: Added.
(Hello):
(get Hello.prototype.generate):
(ok):
* tests/stress/get-by-val-with-string-exit.js: Added.
(shouldBe):
(getByVal):
(getStr1):
(getStr2):
* tests/stress/get-by-val-with-string-generated.js: Added.
(shouldBe):
(getByVal):
(getStr1):
(getStr2):
* tests/stress/get-by-val-with-string-getter.js: Added.
(object.get hello):
(ok):
* tests/stress/get-by-val-with-string.js: Added.
(shouldBe):
(getByVal):
(getStr1):
(getStr2):
* tests/stress/get-by-val-with-symbol-constructor.js: Added.
(Hello):
(get Hello.prototype.generate):
(ok):
* tests/stress/get-by-val-with-symbol-exit.js: Added.
(shouldBe):
(getByVal):
(getSym1):
(getSym2):
* tests/stress/get-by-val-with-symbol-getter.js: Added.
(object.get hello):
(.get ok):
* tests/stress/get-by-val-with-symbol.js: Added.
(shouldBe):
(getByVal):
(getSym1):
(getSym2):
2015-08-11 Filip Pizlo <fpizlo@apple.com>
DFG::ByteCodeParser shouldn't call tryGetConstantProperty() with some StructureSet if it isn't checking that the base has a structure in that StructureSet
https://bugs.webkit.org/show_bug.cgi?id=147891
rdar://problem/22129447
Reviewed by Mark Lam.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleGetByOffset): Get rid of this.
(JSC::DFG::ByteCodeParser::load): Don't call the version of handleGetByOffset() that assumes that we had CheckStructure'd some StructureSet, since we may not have CheckStructure'd anything.
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::assertIsRegistered): Make this always assert even before the StructureRegistrationPhase.
* dfg/DFGStructureRegistrationPhase.cpp:
(JSC::DFG::StructureRegistrationPhase::run): Add a FIXME that notes that we no longer believe that structures should be registered only at this phase. They should be registered before this phase and this phase should be removed.
2015-08-11 Brent Fulgham <bfulgham@apple.com>
[Win] Switch Windows build to Visual Studio 2015
https://bugs.webkit.org/show_bug.cgi?id=147887
<rdar://problem/22235098>
Reviewed by Alex Christensen.
Update Visual Studio project file settings to use the current Visual
Studio and compiler. Continue targeting binaries to run on our minimum
supported configuration of Windows 7.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj:
* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj:
* JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj:
* JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj:
* JavaScriptCore.vcxproj/jsc/jsc.vcxproj:
* JavaScriptCore.vcxproj/jsc/jscLauncher.vcxproj:
* JavaScriptCore.vcxproj/libllvmForJSC/libllvmForJSC.vcxproj:
* JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj:
* JavaScriptCore.vcxproj/testRegExp/testRegExpLauncher.vcxproj:
* JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
* JavaScriptCore.vcxproj/testapi/testapiLauncher.vcxproj:
2015-08-10 Filip Pizlo <fpizlo@apple.com>
WTF should have a ParkingLot for parking sleeping threads, so that locks can fit in 1.6 bits
https://bugs.webkit.org/show_bug.cgi?id=147665
Reviewed by Mark Lam.
Replace ByteSpinLock with ByteLock.
* runtime/ConcurrentJITLock.h:
2015-08-11 Yusuke Suzuki <utatane.tea@gmail.com>
Numeric setter on prototype doesn't get called.
https://bugs.webkit.org/show_bug.cgi?id=144252
Reviewed by Darin Adler.
When switching the blank indexing type to the other one in putByIndex,
if the `structure(vm)->needsSlowPutIndexing()` is true, we need to switch
it to the slow put indexing type and reloop the putByIndex since there may
be some indexing accessor in the prototype chain. Previously, we just set
the value into the allocated vector.
In the putDirectIndex case, we just store the value to the vector.
This is because putDirectIndex is the operation to store the own property
and it does not check the accessors in the prototype chain.
* runtime/JSObject.cpp:
(JSC::JSObject::putByIndexBeyondVectorLength):
* tests/stress/injected-numeric-setter-on-prototype.js: Added.
(shouldBe):
(Trace):
(Trace.prototype.trace):
(Trace.prototype.get count):
(.):
* tests/stress/numeric-setter-on-prototype-non-blank-array.js: Added.
(shouldBe):
(Trace):
(Trace.prototype.trace):
(Trace.prototype.get count):
(.):
* tests/stress/numeric-setter-on-prototype.js: Added.
(shouldBe):
(Trace):
(Trace.prototype.trace):
(Trace.prototype.get count):
(.z.__proto__.set 3):
* tests/stress/numeric-setter-on-self.js: Added.
(shouldBe):
(Trace):
(Trace.prototype.trace):
(Trace.prototype.get count):
(.y.set 2):
2015-08-11 Brent Fulgham <bfulgham@apple.com>
[Win] Unreviewed gardening.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Add missing
file references so they appear in the proper IDE locations.
2015-08-11 Brent Fulgham <bfulgham@apple.com>
Unreviewed windows build fix for VS2015.
* bindings/ScriptValue.h: Add missing JSCJSValueInlines.h include.
2015-08-11 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement Reflect.has
https://bugs.webkit.org/show_bug.cgi?id=147875
Reviewed by Sam Weinig.
This patch implements Reflect.has[1].
Since the semantics is the same to the `in` operator in the JS[2],
we can implement it in builtin JS code.
[1]: http://www.ecma-international.org/ecma-262/6.0/#sec-reflect.has
[2]: http://www.ecma-international.org/ecma-262/6.0/#sec-relational-operators-runtime-semantics-evaluation
* builtins/ReflectObject.js:
(has):
* runtime/ReflectObject.cpp:
* tests/stress/reflect-has.js: Added.
(shouldBe):
(shouldThrow):
2015-08-11 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement Reflect.getPrototypeOf and Reflect.setPrototypeOf
https://bugs.webkit.org/show_bug.cgi?id=147874
Reviewed by Darin Adler.
This patch implements ES6 Reflect.{getPrototypeOf, setPrototypeOf}.
The difference from the Object.* one is
1. They dont not perform ToObject onto the non-object arguments. They make it as a TypeError.
2. Reflect.setPrototyeOf returns false when the operation is failed. In Object.setPrototypeOf, it raises a TypeError.
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructorGetPrototypeOfFunctor::ObjectConstructorGetPrototypeOfFunctor):
(JSC::ObjectConstructorGetPrototypeOfFunctor::result):
(JSC::ObjectConstructorGetPrototypeOfFunctor::operator()):
(JSC::objectConstructorGetPrototypeOf):
* runtime/ObjectConstructor.h:
* runtime/ReflectObject.cpp:
(JSC::reflectObjectGetPrototypeOf):
(JSC::reflectObjectSetPrototypeOf):
* tests/stress/reflect-get-prototype-of.js: Added.
(shouldBe):
(shouldThrow):
(Base):
(Derived):
* tests/stress/reflect-set-prototype-of.js: Added.
(shouldBe):
(shouldThrow):
2015-08-11 Ting-Wei Lan <lantw44@gmail.com>
Fix debug build when optimization is enabled
https://bugs.webkit.org/show_bug.cgi?id=147816
Reviewed by Alexey Proskuryakov.
* llint/LLIntEntrypoint.cpp:
* runtime/FunctionExecutableDump.cpp:
2015-08-11 Yusuke Suzuki <utatane.tea@gmail.com>
Ensure that Reflect.enumerate does not produce the deleted keys
https://bugs.webkit.org/show_bug.cgi?id=147677
Reviewed by Darin Adler.
Add tests for Reflect.enumerate that delete the property keys during the enumeration.
* tests/stress/reflect-enumerate.js:
2015-08-10 Geoffrey Garen <ggaren@apple.com>
Start beating UnlinkedCodeBlock.h/.cpp with the "One Class per File" stick
https://bugs.webkit.org/show_bug.cgi?id=147856
Reviewed by Saam Barati.
Split out UnlinkedFunctionExecutable.h/.cpp and ExecutableInfo.h into separate files.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/ExecutableInfo.h: Copied from Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.h.
(JSC::ExecutableInfo::ExecutableInfo):
(JSC::UnlinkedStringJumpTable::offsetForValue): Deleted.
(JSC::UnlinkedSimpleJumpTable::add): Deleted.
(JSC::UnlinkedInstruction::UnlinkedInstruction): Deleted.
(JSC::UnlinkedCodeBlock::isConstructor): Deleted.
(JSC::UnlinkedCodeBlock::isStrictMode): Deleted.
(JSC::UnlinkedCodeBlock::usesEval): Deleted.
(JSC::UnlinkedCodeBlock::needsFullScopeChain): Deleted.
(JSC::UnlinkedCodeBlock::hasExpressionInfo): Deleted.
(JSC::UnlinkedCodeBlock::setThisRegister): Deleted.
(JSC::UnlinkedCodeBlock::setScopeRegister): Deleted.
(JSC::UnlinkedCodeBlock::setActivationRegister): Deleted.
(JSC::UnlinkedCodeBlock::usesGlobalObject): Deleted.
(JSC::UnlinkedCodeBlock::setGlobalObjectRegister): Deleted.
(JSC::UnlinkedCodeBlock::globalObjectRegister): Deleted.
(JSC::UnlinkedCodeBlock::setNumParameters): Deleted.
(JSC::UnlinkedCodeBlock::addParameter): Deleted.
(JSC::UnlinkedCodeBlock::numParameters): Deleted.
(JSC::UnlinkedCodeBlock::addRegExp): Deleted.
(JSC::UnlinkedCodeBlock::numberOfRegExps): Deleted.
(JSC::UnlinkedCodeBlock::regexp): Deleted.
(JSC::UnlinkedCodeBlock::numberOfIdentifiers): Deleted.
(JSC::UnlinkedCodeBlock::addIdentifier): Deleted.
(JSC::UnlinkedCodeBlock::identifier): Deleted.
(JSC::UnlinkedCodeBlock::identifiers): Deleted.
(JSC::UnlinkedCodeBlock::addConstant): Deleted.
(JSC::UnlinkedCodeBlock::registerIndexForLinkTimeConstant): Deleted.
(JSC::UnlinkedCodeBlock::constantRegisters): Deleted.
(JSC::UnlinkedCodeBlock::constantRegister): Deleted.
(JSC::UnlinkedCodeBlock::isConstantRegisterIndex): Deleted.
(JSC::UnlinkedCodeBlock::constantsSourceCodeRepresentation): Deleted.
(JSC::UnlinkedCodeBlock::numberOfJumpTargets): Deleted.
(JSC::UnlinkedCodeBlock::addJumpTarget): Deleted.
(JSC::UnlinkedCodeBlock::jumpTarget): Deleted.
(JSC::UnlinkedCodeBlock::lastJumpTarget): Deleted.
(JSC::UnlinkedCodeBlock::isBuiltinFunction): Deleted.
(JSC::UnlinkedCodeBlock::constructorKind): Deleted.
(JSC::UnlinkedCodeBlock::shrinkToFit): Deleted.
(JSC::UnlinkedCodeBlock::numberOfSwitchJumpTables): Deleted.
(JSC::UnlinkedCodeBlock::addSwitchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::switchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::numberOfStringSwitchJumpTables): Deleted.
(JSC::UnlinkedCodeBlock::addStringSwitchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::stringSwitchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::addFunctionDecl): Deleted.
(JSC::UnlinkedCodeBlock::functionDecl): Deleted.
(JSC::UnlinkedCodeBlock::numberOfFunctionDecls): Deleted.
(JSC::UnlinkedCodeBlock::addFunctionExpr): Deleted.
(JSC::UnlinkedCodeBlock::functionExpr): Deleted.
(JSC::UnlinkedCodeBlock::numberOfFunctionExprs): Deleted.
(JSC::UnlinkedCodeBlock::numberOfExceptionHandlers): Deleted.
(JSC::UnlinkedCodeBlock::addExceptionHandler): Deleted.
(JSC::UnlinkedCodeBlock::exceptionHandler): Deleted.
(JSC::UnlinkedCodeBlock::vm): Deleted.
(JSC::UnlinkedCodeBlock::addArrayProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfArrayProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addArrayAllocationProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfArrayAllocationProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addObjectAllocationProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfObjectAllocationProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addValueProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfValueProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addLLIntCallLinkInfo): Deleted.
(JSC::UnlinkedCodeBlock::numberOfLLintCallLinkInfos): Deleted.
(JSC::UnlinkedCodeBlock::codeType): Deleted.
(JSC::UnlinkedCodeBlock::thisRegister): Deleted.
(JSC::UnlinkedCodeBlock::scopeRegister): Deleted.
(JSC::UnlinkedCodeBlock::activationRegister): Deleted.
(JSC::UnlinkedCodeBlock::hasActivationRegister): Deleted.
(JSC::UnlinkedCodeBlock::addPropertyAccessInstruction): Deleted.
(JSC::UnlinkedCodeBlock::numberOfPropertyAccessInstructions): Deleted.
(JSC::UnlinkedCodeBlock::propertyAccessInstructions): Deleted.
(JSC::UnlinkedCodeBlock::constantBufferCount): Deleted.
(JSC::UnlinkedCodeBlock::addConstantBuffer): Deleted.
(JSC::UnlinkedCodeBlock::constantBuffer): Deleted.
(JSC::UnlinkedCodeBlock::hasRareData): Deleted.
(JSC::UnlinkedCodeBlock::recordParse): Deleted.
(JSC::UnlinkedCodeBlock::codeFeatures): Deleted.
(JSC::UnlinkedCodeBlock::hasCapturedVariables): Deleted.
(JSC::UnlinkedCodeBlock::firstLine): Deleted.
(JSC::UnlinkedCodeBlock::lineCount): Deleted.
(JSC::UnlinkedCodeBlock::startColumn): Deleted.
(JSC::UnlinkedCodeBlock::endColumn): Deleted.
(JSC::UnlinkedCodeBlock::addOpProfileControlFlowBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::opProfileControlFlowBytecodeOffsets): Deleted.
(JSC::UnlinkedCodeBlock::finishCreation): Deleted.
(JSC::UnlinkedCodeBlock::createRareDataIfNecessary): Deleted.
(JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock): Deleted.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
(JSC::generateFunctionCodeBlock): Deleted.
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable): Deleted.
(JSC::UnlinkedFunctionExecutable::visitChildren): Deleted.
(JSC::UnlinkedFunctionExecutable::link): Deleted.
(JSC::UnlinkedFunctionExecutable::fromGlobalCode): Deleted.
(JSC::UnlinkedFunctionExecutable::codeBlockFor): Deleted.
* bytecode/UnlinkedCodeBlock.h:
(JSC::ExecutableInfo::ExecutableInfo): Deleted.
(JSC::ExecutableInfo::needsActivation): Deleted.
(JSC::ExecutableInfo::usesEval): Deleted.
(JSC::ExecutableInfo::isStrictMode): Deleted.
(JSC::ExecutableInfo::isConstructor): Deleted.
(JSC::ExecutableInfo::isBuiltinFunction): Deleted.
(JSC::ExecutableInfo::constructorKind): Deleted.
* bytecode/UnlinkedFunctionExecutable.cpp: Copied from Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.cpp.
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::codeBlockFor):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): Deleted.
(JSC::UnlinkedCodeBlock::visitChildren): Deleted.
(JSC::UnlinkedCodeBlock::lineNumberForBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::getLineAndColumn): Deleted.
(JSC::dumpLineColumnEntry): Deleted.
(JSC::UnlinkedCodeBlock::dumpExpressionRangeInfo): Deleted.
(JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::addExpressionInfo): Deleted.
(JSC::UnlinkedCodeBlock::typeProfilerExpressionInfoForBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::addTypeProfilerExpressionInfo): Deleted.
(JSC::UnlinkedProgramCodeBlock::visitChildren): Deleted.
(JSC::UnlinkedCodeBlock::~UnlinkedCodeBlock): Deleted.
(JSC::UnlinkedProgramCodeBlock::destroy): Deleted.
(JSC::UnlinkedEvalCodeBlock::destroy): Deleted.
(JSC::UnlinkedFunctionCodeBlock::destroy): Deleted.
(JSC::UnlinkedFunctionExecutable::destroy): Deleted.
(JSC::UnlinkedCodeBlock::setInstructions): Deleted.
(JSC::UnlinkedCodeBlock::instructions): Deleted.
* bytecode/UnlinkedFunctionExecutable.h: Copied from Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.h.
(JSC::ExecutableInfo::ExecutableInfo): Deleted.
(JSC::ExecutableInfo::needsActivation): Deleted.
(JSC::ExecutableInfo::usesEval): Deleted.
(JSC::ExecutableInfo::isStrictMode): Deleted.
(JSC::ExecutableInfo::isConstructor): Deleted.
(JSC::ExecutableInfo::isBuiltinFunction): Deleted.
(JSC::ExecutableInfo::constructorKind): Deleted.
(JSC::UnlinkedStringJumpTable::offsetForValue): Deleted.
(JSC::UnlinkedSimpleJumpTable::add): Deleted.
(JSC::UnlinkedInstruction::UnlinkedInstruction): Deleted.
(JSC::UnlinkedCodeBlock::isConstructor): Deleted.
(JSC::UnlinkedCodeBlock::isStrictMode): Deleted.
(JSC::UnlinkedCodeBlock::usesEval): Deleted.
(JSC::UnlinkedCodeBlock::needsFullScopeChain): Deleted.
(JSC::UnlinkedCodeBlock::hasExpressionInfo): Deleted.
(JSC::UnlinkedCodeBlock::setThisRegister): Deleted.
(JSC::UnlinkedCodeBlock::setScopeRegister): Deleted.
(JSC::UnlinkedCodeBlock::setActivationRegister): Deleted.
(JSC::UnlinkedCodeBlock::usesGlobalObject): Deleted.
(JSC::UnlinkedCodeBlock::setGlobalObjectRegister): Deleted.
(JSC::UnlinkedCodeBlock::globalObjectRegister): Deleted.
(JSC::UnlinkedCodeBlock::setNumParameters): Deleted.
(JSC::UnlinkedCodeBlock::addParameter): Deleted.
(JSC::UnlinkedCodeBlock::numParameters): Deleted.
(JSC::UnlinkedCodeBlock::addRegExp): Deleted.
(JSC::UnlinkedCodeBlock::numberOfRegExps): Deleted.
(JSC::UnlinkedCodeBlock::regexp): Deleted.
(JSC::UnlinkedCodeBlock::numberOfIdentifiers): Deleted.
(JSC::UnlinkedCodeBlock::addIdentifier): Deleted.
(JSC::UnlinkedCodeBlock::identifier): Deleted.
(JSC::UnlinkedCodeBlock::identifiers): Deleted.
(JSC::UnlinkedCodeBlock::addConstant): Deleted.
(JSC::UnlinkedCodeBlock::registerIndexForLinkTimeConstant): Deleted.
(JSC::UnlinkedCodeBlock::constantRegisters): Deleted.
(JSC::UnlinkedCodeBlock::constantRegister): Deleted.
(JSC::UnlinkedCodeBlock::isConstantRegisterIndex): Deleted.
(JSC::UnlinkedCodeBlock::constantsSourceCodeRepresentation): Deleted.
(JSC::UnlinkedCodeBlock::numberOfJumpTargets): Deleted.
(JSC::UnlinkedCodeBlock::addJumpTarget): Deleted.
(JSC::UnlinkedCodeBlock::jumpTarget): Deleted.
(JSC::UnlinkedCodeBlock::lastJumpTarget): Deleted.
(JSC::UnlinkedCodeBlock::isBuiltinFunction): Deleted.
(JSC::UnlinkedCodeBlock::constructorKind): Deleted.
(JSC::UnlinkedCodeBlock::shrinkToFit): Deleted.
(JSC::UnlinkedCodeBlock::numberOfSwitchJumpTables): Deleted.
(JSC::UnlinkedCodeBlock::addSwitchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::switchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::numberOfStringSwitchJumpTables): Deleted.
(JSC::UnlinkedCodeBlock::addStringSwitchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::stringSwitchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::addFunctionDecl): Deleted.
(JSC::UnlinkedCodeBlock::functionDecl): Deleted.
(JSC::UnlinkedCodeBlock::numberOfFunctionDecls): Deleted.
(JSC::UnlinkedCodeBlock::addFunctionExpr): Deleted.
(JSC::UnlinkedCodeBlock::functionExpr): Deleted.
(JSC::UnlinkedCodeBlock::numberOfFunctionExprs): Deleted.
(JSC::UnlinkedCodeBlock::numberOfExceptionHandlers): Deleted.
(JSC::UnlinkedCodeBlock::addExceptionHandler): Deleted.
(JSC::UnlinkedCodeBlock::exceptionHandler): Deleted.
(JSC::UnlinkedCodeBlock::vm): Deleted.
(JSC::UnlinkedCodeBlock::addArrayProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfArrayProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addArrayAllocationProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfArrayAllocationProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addObjectAllocationProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfObjectAllocationProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addValueProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfValueProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addLLIntCallLinkInfo): Deleted.
(JSC::UnlinkedCodeBlock::numberOfLLintCallLinkInfos): Deleted.
(JSC::UnlinkedCodeBlock::codeType): Deleted.
(JSC::UnlinkedCodeBlock::thisRegister): Deleted.
(JSC::UnlinkedCodeBlock::scopeRegister): Deleted.
(JSC::UnlinkedCodeBlock::activationRegister): Deleted.
(JSC::UnlinkedCodeBlock::hasActivationRegister): Deleted.
(JSC::UnlinkedCodeBlock::addPropertyAccessInstruction): Deleted.
(JSC::UnlinkedCodeBlock::numberOfPropertyAccessInstructions): Deleted.
(JSC::UnlinkedCodeBlock::propertyAccessInstructions): Deleted.
(JSC::UnlinkedCodeBlock::constantBufferCount): Deleted.
(JSC::UnlinkedCodeBlock::addConstantBuffer): Deleted.
(JSC::UnlinkedCodeBlock::constantBuffer): Deleted.
(JSC::UnlinkedCodeBlock::hasRareData): Deleted.
(JSC::UnlinkedCodeBlock::recordParse): Deleted.
(JSC::UnlinkedCodeBlock::codeFeatures): Deleted.
(JSC::UnlinkedCodeBlock::hasCapturedVariables): Deleted.
(JSC::UnlinkedCodeBlock::firstLine): Deleted.
(JSC::UnlinkedCodeBlock::lineCount): Deleted.
(JSC::UnlinkedCodeBlock::startColumn): Deleted.
(JSC::UnlinkedCodeBlock::endColumn): Deleted.
(JSC::UnlinkedCodeBlock::addOpProfileControlFlowBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::opProfileControlFlowBytecodeOffsets): Deleted.
(JSC::UnlinkedCodeBlock::finishCreation): Deleted.
(JSC::UnlinkedCodeBlock::createRareDataIfNecessary): Deleted.
(JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock): Deleted.
* runtime/Executable.h:
2015-08-10 Mark Lam <mark.lam@apple.com>
Refactor LiveObjectList and LiveObjectData into their own files.
https://bugs.webkit.org/show_bug.cgi?id=147843
Reviewed by Saam Barati.
There is no behavior change in this patch.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/HeapVerifier.cpp:
(JSC::HeapVerifier::HeapVerifier):
(JSC::LiveObjectList::findObject): Deleted.
* heap/HeapVerifier.h:
(JSC::LiveObjectData::LiveObjectData): Deleted.
(JSC::LiveObjectList::LiveObjectList): Deleted.
(JSC::LiveObjectList::reset): Deleted.
* heap/LiveObjectData.h: Added.
(JSC::LiveObjectData::LiveObjectData):
* heap/LiveObjectList.cpp: Added.
(JSC::LiveObjectList::findObject):
* heap/LiveObjectList.h: Added.
(JSC::LiveObjectList::LiveObjectList):
(JSC::LiveObjectList::reset):
2015-08-07 Geoffrey Garen <ggaren@apple.com>
Let's rename FunctionBodyNode
https://bugs.webkit.org/show_bug.cgi?id=147292
Reviewed by Mark Lam & Saam Barati.
FunctionBodyNode => FunctionMetadataNode
Make FunctionMetadataNode inherit from Node instead of StatementNode
because a FunctionMetadataNode can appear in expression context and does
not have a next statement.
(I decided to continue allocating FunctionMetadataNode in the AST arena,
and to retain "Node" in its name, because it really is a parsing
construct, and we transform its data before consuming it elsewhere.
There is still room for a future patch to distill and simplify the
metadata we track about functions between FunDeclNode/FuncExprNode,
FunctionMetadataNode, and UnlinkedFunctionExecutable. But this is a start.)
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createExecutableInternal):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedCodeBlock.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitNewArray):
(JSC::BytecodeGenerator::emitNewFunction):
(JSC::BytecodeGenerator::emitNewFunctionExpression):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::makeFunction):
* bytecompiler/NodesCodegen.cpp:
(JSC::EvalNode::emitBytecode):
(JSC::FunctionNode::emitBytecode):
(JSC::FunctionBodyNode::emitBytecode): Deleted.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionExpr):
(JSC::ASTBuilder::createFunctionBody):
* parser/NodeConstructors.h:
(JSC::FunctionParameters::FunctionParameters):
(JSC::FuncExprNode::FuncExprNode):
(JSC::FuncDeclNode::FuncDeclNode):
* parser/Nodes.cpp:
(JSC::EvalNode::EvalNode):
(JSC::FunctionMetadataNode::FunctionMetadataNode):
(JSC::FunctionMetadataNode::finishParsing):
(JSC::FunctionMetadataNode::setEndPosition):
(JSC::FunctionBodyNode::FunctionBodyNode): Deleted.
(JSC::FunctionBodyNode::finishParsing): Deleted.
(JSC::FunctionBodyNode::setEndPosition): Deleted.
* parser/Nodes.h:
(JSC::FuncExprNode::body):
(JSC::FuncDeclNode::body):
* parser/Parser.h:
(JSC::Parser::isFunctionMetadataNode):
(JSC::Parser::next):
(JSC::Parser<LexerType>::parse):
(JSC::Parser::isFunctionBodyNode): Deleted.
* runtime/CodeCache.cpp:
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
2015-08-09 Chris Dumez <cdumez@apple.com>
Regression(r188105): Seems to have caused crashes during PLT on some iPads
https://bugs.webkit.org/show_bug.cgi?id=147818
Unreviewed, roll out r188105.
* bytecode/ByValInfo.h:
(JSC::ByValInfo::ByValInfo):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::getByValInfoMap): Deleted.
(JSC::CodeBlock::addByValInfo): Deleted.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::getByValInfo):
(JSC::CodeBlock::setNumberOfByValInfos):
(JSC::CodeBlock::numberOfByValInfos):
(JSC::CodeBlock::byValInfo):
* bytecode/ExitKind.cpp:
(JSC::exitKindToString): Deleted.
* bytecode/ExitKind.h:
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFor):
(JSC::GetByIdStatus::computeForStubInfo):
(JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback): Deleted.
* bytecode/GetByIdStatus.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Deleted.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): Deleted.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize): Deleted.
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants): Deleted.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC): Deleted.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode): Deleted.
(JSC::DFG::FixupPhase::observeUseKindOnNode): Deleted.
* dfg/DFGNode.h:
(JSC::DFG::Node::hasUidOperand): Deleted.
(JSC::DFG::Node::uidOperand): Deleted.
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate): Deleted.
* dfg/DFGSafeToExecute.h:
(JSC::DFG::SafeToExecuteEdge::operator()): Deleted.
(JSC::DFG::safeToExecute): Deleted.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCheckIdent): Deleted.
(JSC::DFG::SpeculativeJIT::speculateSymbol): Deleted.
(JSC::DFG::SpeculativeJIT::speculate): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile): Deleted.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile): Deleted.
* dfg/DFGUseKind.cpp:
(WTF::printInternal): Deleted.
* dfg/DFGUseKind.h:
(JSC::DFG::typeFilterFor): Deleted.
(JSC::DFG::isCell): Deleted.
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile): Deleted.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode): Deleted.
(JSC::FTL::DFG::LowerDFGToLLVM::compileCheckIdent): Deleted.
(JSC::FTL::DFG::LowerDFGToLLVM::lowSymbol): Deleted.
(JSC::FTL::DFG::LowerDFGToLLVM::speculate): Deleted.
(JSC::FTL::DFG::LowerDFGToLLVM::isNotSymbol): Deleted.
(JSC::FTL::DFG::LowerDFGToLLVM::speculateSymbol): Deleted.
* jit/JIT.cpp:
(JSC::JIT::privateCompile):
* jit/JIT.h:
(JSC::ByValCompilationInfo::ByValCompilationInfo):
(JSC::JIT::compileGetByValWithCachedId): Deleted.
* jit/JITInlines.h:
(JSC::JIT::callOperation): Deleted.
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_has_indexed_property):
(JSC::JIT::emitSlow_op_has_indexed_property):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_has_indexed_property):
(JSC::JIT::emitSlow_op_has_indexed_property):
* jit/JITOperations.cpp:
(JSC::getByVal):
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emit_op_put_by_val):
(JSC::JIT::emitSlow_op_put_by_val):
(JSC::JIT::emitGetByValWithCachedId): Deleted.
(JSC::JIT::privateCompileGetByVal): Deleted.
(JSC::JIT::privateCompileGetByValWithCachedId): Deleted.
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emit_op_put_by_val):
(JSC::JIT::emitSlow_op_put_by_val):
(JSC::JIT::emitGetByValWithCachedId): Deleted.
* runtime/Symbol.h:
* tests/stress/get-by-val-with-string-constructor.js: Removed.
* tests/stress/get-by-val-with-string-exit.js: Removed.
* tests/stress/get-by-val-with-string-generated.js: Removed.
* tests/stress/get-by-val-with-string-getter.js: Removed.
* tests/stress/get-by-val-with-string.js: Removed.
* tests/stress/get-by-val-with-symbol-constructor.js: Removed.
* tests/stress/get-by-val-with-symbol-exit.js: Removed.
* tests/stress/get-by-val-with-symbol-getter.js: Removed.
* tests/stress/get-by-val-with-symbol.js: Removed.
2015-08-07 Gyuyoung Kim <gyuyoung.kim@webkit.org>
Reduce uses of PassRefPtr in bindings
https://bugs.webkit.org/show_bug.cgi?id=147781
Reviewed by Chris Dumez.
Use RefPtr when function can return null or an instance. If not, Ref is used.
* runtime/JSGenericTypedArrayView.h:
(JSC::toNativeTypedView):
2015-08-07 Alex Christensen <achristensen@webkit.org>
Build more testing binaries with CMake on Windows
https://bugs.webkit.org/show_bug.cgi?id=147799
Reviewed by Brent Fulgham.
* shell/PlatformWin.cmake: Added.
Build jsc.dll and jsc.exe to find Apple Application Support or WinCairo dlls before using them.
2015-08-07 Filip Pizlo <fpizlo@apple.com>
Lightweight locks should be adaptive
https://bugs.webkit.org/show_bug.cgi?id=147545
Reviewed by Geoffrey Garen.
* dfg/DFGCommon.cpp:
(JSC::DFG::startCrashing):
* heap/CopiedBlock.h:
(JSC::CopiedBlock::workListLock):
* heap/CopiedBlockInlines.h:
(JSC::CopiedBlock::shouldReportLiveBytes):
(JSC::CopiedBlock::reportLiveBytes):
* heap/CopiedSpace.cpp:
(JSC::CopiedSpace::doneFillingBlock):
* heap/CopiedSpace.h:
(JSC::CopiedSpace::CopiedGeneration::CopiedGeneration):
* heap/CopiedSpaceInlines.h:
(JSC::CopiedSpace::recycleEvacuatedBlock):
* heap/GCThreadSharedData.cpp:
(JSC::GCThreadSharedData::didStartCopying):
* heap/GCThreadSharedData.h:
(JSC::GCThreadSharedData::getNextBlocksToCopy):
* heap/ListableHandler.h:
(JSC::ListableHandler::List::addThreadSafe):
(JSC::ListableHandler::List::addNotThreadSafe):
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::tryCopyOtherThreadStacks):
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::copyLater):
* parser/SourceProvider.cpp:
(JSC::SourceProvider::~SourceProvider):
(JSC::SourceProvider::getID):
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::addDatabaseToAtExit):
(JSC::Profiler::Database::removeDatabaseFromAtExit):
(JSC::Profiler::Database::removeFirstAtExitDatabase):
* runtime/TypeProfilerLog.h:
2015-08-07 Mark Lam <mark.lam@apple.com>
Rename some variables in the JSC watchdog implementation.
https://bugs.webkit.org/show_bug.cgi?id=147790
Rubber stamped by Benjamin Poulain.
This is just a refactoring patch to give the variable better names that describe their
intended use. There is no behavior change.
* runtime/Watchdog.cpp:
(JSC::Watchdog::Watchdog):
(JSC::Watchdog::setTimeLimit):
(JSC::Watchdog::didFire):
(JSC::Watchdog::isEnabled):
(JSC::Watchdog::fire):
(JSC::Watchdog::startCountdownIfNeeded):
* runtime/Watchdog.h:
2015-08-07 Saam barati <saambarati1@gmail.com>
Interpreter::unwind shouldn't be responsible for assigning the correct scope.
https://bugs.webkit.org/show_bug.cgi?id=147666
Reviewed by Geoffrey Garen.
If we make the bytecode generator know about every local scope it
creates, and if we give each local scope a unique register, the
bytecode generator has all the information it needs to assign
the correct scope to a catch handler. Because the bytecode generator
knows this information, it's a better separation of responsibilties
for it to set up the proper scope instead of relying on the exception
handling runtime to find the scope.
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::CodeBlock):
* bytecode/HandlerInfo.h:
(JSC::UnlinkedHandlerInfo::UnlinkedHandlerInfo):
(JSC::HandlerInfo::initialize):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::pushLexicalScopeInternal):
(JSC::BytecodeGenerator::emitGetScope):
(JSC::BytecodeGenerator::emitPushWithScope):
(JSC::BytecodeGenerator::emitGetParentScope):
(JSC::BytecodeGenerator::emitPopScope):
(JSC::BytecodeGenerator::emitPopWithScope):
(JSC::BytecodeGenerator::allocateAndEmitScope):
(JSC::BytecodeGenerator::emitComplexPopScopes):
(JSC::BytecodeGenerator::pushTry):
(JSC::BytecodeGenerator::popTryAndEmitCatch):
(JSC::BytecodeGenerator::localScopeDepth):
(JSC::BytecodeGenerator::calculateTargetScopeDepthForExceptionHandler): Deleted.
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::WithNode::emitBytecode):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::unwind):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_push_with_scope):
(JSC::JIT::compileOpStrictEq):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_push_with_scope):
(JSC::JIT::emit_op_to_number):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* runtime/JSScope.cpp:
(JSC::JSScope::objectAtScope):
(JSC::isUnscopable):
(JSC::JSScope::depth): Deleted.
* runtime/JSScope.h:
2015-08-07 Yusuke Suzuki <utatane.tea@gmail.com>
Add MacroAssembler::patchableBranch64 and fix ARM64's patchableBranchPtr
https://bugs.webkit.org/show_bug.cgi?id=147761
Reviewed by Mark Lam.
This patch implements MacroAssembler::patchableBranch64 in 64bit environments.
And fix the existing MacroAssemblerARM64::patchableBranchPtr, before this patch,
it truncates the immediate pointer into the 32bit immediate.
And use patchableBranch64 in the baseline JIT under the JSVALUE64 configuration.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::patchableBranchPtr):
(JSC::MacroAssemblerARM64::patchableBranch64):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::patchableBranch64):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::emitPatchableJumpIfNotImmediateInteger):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_get_by_val):
2015-08-06 Yusuke Suzuki <utatane.tea@gmail.com>
Introduce get_by_id like IC into get_by_val when the given name is String or Symbol
https://bugs.webkit.org/show_bug.cgi?id=147480
Reviewed by Filip Pizlo.
This patch adds get_by_id IC to get_by_val operation by caching the string / symbol id.
The IC site only caches one id. After checking that the given id is the same to the
cached one, we perform the get_by_id IC onto it.
And by collecting IC StructureStubInfo information, we pass it to the DFG and DFG
compiles get_by_val op code into CheckIdent (with edge type check) and GetById related
operations when the given get_by_val leverages the property load with the cached id.
To ensure the incoming value is the expected id, in DFG layer, we use SymbolUse and
StringIdentUse to enforce the type. To use it, this patch implements SymbolUse.
This can be leveraged to optimize symbol operations in DFG.
And since byValInfo is frequently used, we align the byValInfo design to the stubInfo like one.
Allocated by the Bag and operations take the raw byValInfo pointer directly instead of performing
binary search onto m_byValInfos. And by storing ArrayProfile* under the ByValInfo, we replaced the
argument ArrayProfile* in the operations with ByValInfo*.
* bytecode/ByValInfo.h:
(JSC::ByValInfo::ByValInfo):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::getByValInfoMap):
(JSC::CodeBlock::addByValInfo):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::getByValInfo): Deleted.
(JSC::CodeBlock::setNumberOfByValInfos): Deleted.
(JSC::CodeBlock::numberOfByValInfos): Deleted.
(JSC::CodeBlock::byValInfo): Deleted.
* bytecode/ExitKind.cpp:
(JSC::exitKindToString):
* bytecode/ExitKind.h:
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFor):
(JSC::GetByIdStatus::computeForStubInfo):
(JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
* bytecode/GetByIdStatus.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::observeUseKindOnNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasUidOperand):
(JSC::DFG::Node::uidOperand):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::SafeToExecuteEdge::operator()):
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCheckIdent):
(JSC::DFG::SpeculativeJIT::speculateSymbol):
(JSC::DFG::SpeculativeJIT::speculate):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGUseKind.cpp:
(WTF::printInternal):
* dfg/DFGUseKind.h:
(JSC::DFG::typeFilterFor):
(JSC::DFG::isCell):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
(JSC::FTL::DFG::LowerDFGToLLVM::compileCheckIdent):
(JSC::FTL::DFG::LowerDFGToLLVM::lowSymbol):
(JSC::FTL::DFG::LowerDFGToLLVM::speculate):
(JSC::FTL::DFG::LowerDFGToLLVM::isNotSymbol):
(JSC::FTL::DFG::LowerDFGToLLVM::speculateSymbol):
* jit/JIT.cpp:
(JSC::JIT::privateCompile):
* jit/JIT.h:
(JSC::ByValCompilationInfo::ByValCompilationInfo):
(JSC::JIT::compileGetByValWithCachedId):
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_has_indexed_property):
(JSC::JIT::emitSlow_op_has_indexed_property):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_has_indexed_property):
(JSC::JIT::emitSlow_op_has_indexed_property):
* jit/JITOperations.cpp:
(JSC::getByVal):
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emitGetByValWithCachedId):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emit_op_put_by_val):
(JSC::JIT::emitSlow_op_put_by_val):
(JSC::JIT::privateCompileGetByVal):
(JSC::JIT::privateCompileGetByValWithCachedId):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emitGetByValWithCachedId):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emit_op_put_by_val):
(JSC::JIT::emitSlow_op_put_by_val):
* runtime/Symbol.h:
* tests/stress/get-by-val-with-string-constructor.js: Added.
(Hello):
(get Hello.prototype.generate):
(ok):
* tests/stress/get-by-val-with-string-exit.js: Added.
(shouldBe):
(getByVal):
(getStr1):
(getStr2):
* tests/stress/get-by-val-with-string-generated.js: Added.
(shouldBe):
(getByVal):
(getStr1):
(getStr2):
* tests/stress/get-by-val-with-string-getter.js: Added.
(object.get hello):
(ok):
* tests/stress/get-by-val-with-string.js: Added.
(shouldBe):
(getByVal):
(getStr1):
(getStr2):
* tests/stress/get-by-val-with-symbol-constructor.js: Added.
(Hello):
(get Hello.prototype.generate):
(ok):
* tests/stress/get-by-val-with-symbol-exit.js: Added.
(shouldBe):
(getByVal):
(getSym1):
(getSym2):
* tests/stress/get-by-val-with-symbol-getter.js: Added.
(object.get hello):
(.get ok):
* tests/stress/get-by-val-with-symbol.js: Added.
(shouldBe):
(getByVal):
(getSym1):
(getSym2):
2015-08-06 Sukolsak Sakshuwong <sukolsak@gmail.com>
Parse the entire WebAssembly modules
https://bugs.webkit.org/show_bug.cgi?id=147393
Reviewed by Geoffrey Garen.
Parse the entire WebAssembly modules from files produced by pack-asmjs
<https://github.com/WebAssembly/polyfill-prototype-1>. This patch can only
parse modules whose function definition section contains only functions that
have "return 0;" as their only statement. Parsing of any functions will be
implemented in a subsequent patch.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* wasm/JSWASMModule.cpp:
(JSC::JSWASMModule::destroy):
* wasm/JSWASMModule.h:
(JSC::JSWASMModule::i32Constants):
(JSC::JSWASMModule::f32Constants):
(JSC::JSWASMModule::f64Constants):
(JSC::JSWASMModule::signatures):
(JSC::JSWASMModule::functionImports):
(JSC::JSWASMModule::functionImportSignatures):
(JSC::JSWASMModule::globalVariableTypes):
(JSC::JSWASMModule::functionDeclarations):
(JSC::JSWASMModule::functionPointerTables):
* wasm/WASMFormat.h: Added.
* wasm/WASMModuleParser.cpp:
(JSC::WASMModuleParser::parse):
(JSC::WASMModuleParser::parseModule):
(JSC::WASMModuleParser::parseConstantPoolSection):
(JSC::WASMModuleParser::parseSignatureSection):
(JSC::WASMModuleParser::parseFunctionImportSection):
(JSC::WASMModuleParser::parseGlobalSection):
(JSC::WASMModuleParser::parseFunctionDeclarationSection):
(JSC::WASMModuleParser::parseFunctionPointerTableSection):
(JSC::WASMModuleParser::parseFunctionDefinitionSection):
(JSC::WASMModuleParser::parseFunctionDefinition):
(JSC::WASMModuleParser::parseExportSection):
* wasm/WASMModuleParser.h:
* wasm/WASMReader.cpp:
(JSC::WASMReader::readUInt32):
(JSC::WASMReader::readCompactUInt32):
(JSC::WASMReader::readString):
(JSC::WASMReader::readType):
(JSC::WASMReader::readExpressionType):
(JSC::WASMReader::readExportFormat):
(JSC::WASMReader::readByte):
(JSC::WASMReader::readUnsignedInt32): Deleted.
* wasm/WASMReader.h:
2015-08-06 Keith Miller <keith_miller@apple.com>
The typedArrayLength function in FTLLowerDFGToLLVM is dead code.
https://bugs.webkit.org/show_bug.cgi?id=147749
Reviewed by Filip Pizlo.
Removed dead code elimination. the TypedArray length is compiled in compileGetArrayLength()
thus no one calls this code.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::typedArrayLength): Deleted.
2015-08-06 Keith Miller <keith_miller@apple.com>
The JSONP parser incorrectly parsers -0 as +0.
https://bugs.webkit.org/show_bug.cgi?id=147590
Reviewed by Michael Saboff.
In the LiteralParser we should use a double to store the accumulator for numerical tokens
rather than an int. Using an int means that -0 is, incorrectly, parsed as +0.
* runtime/LiteralParser.cpp:
(JSC::LiteralParser<CharType>::Lexer::lexNumber):
2015-08-06 Filip Pizlo <fpizlo@apple.com>
Structures used for tryGetConstantProperty() should be registered first
https://bugs.webkit.org/show_bug.cgi?id=147750
Reviewed by Saam Barati and Michael Saboff.
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::tryGetConstantProperty): Add an assertion to that effect. This should catch the bug sooner.
* dfg/DFGGraph.h:
(JSC::DFG::Graph::addStructureSet): Register structures when we make a structure set. That ensures that we won't call tryGetConstantProperty() on a structure that hasn't been registered yet.
* dfg/DFGStructureRegistrationPhase.cpp:
(JSC::DFG::StructureRegistrationPhase::run): Don't register structure sets here anymore. Registering them before we get here means there is no chance of the code being DCE'd before the structures get registered. It also enables the tryGetConstantProperty() assertion, since that code runs before StructureRegisterationPhase.
(JSC::DFG::StructureRegistrationPhase::registerStructures):
(JSC::DFG::StructureRegistrationPhase::registerStructure):
(JSC::DFG::StructureRegistrationPhase::assertAreRegistered):
(JSC::DFG::StructureRegistrationPhase::assertIsRegistered):
(JSC::DFG::performStructureRegistration):
2015-08-06 Keith Miller <keith_miller@apple.com>
Remove UnspecifiedBoolType from JSC
https://bugs.webkit.org/show_bug.cgi?id=147597
Reviewed by Mark Lam.
We were using the safe bool pattern in the code base for implicit casting to booleans.
With C++11 this is no longer necessary and we can instead create an operator bool.
* API/JSRetainPtr.h:
(JSRetainPtr::operator bool):
(JSRetainPtr::operator UnspecifiedBoolType): Deleted.
* dfg/DFGEdge.h:
(JSC::DFG::Edge::operator bool):
(JSC::DFG::Edge::operator UnspecifiedBoolType*): Deleted.
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
* heap/Weak.h:
* heap/WeakInlines.h:
(JSC::bool):
(JSC::UnspecifiedBoolType): Deleted.
2015-08-05 Ryosuke Niwa <rniwa@webkit.org>
[ES6] Class parser does not allow methods named set and get.
https://bugs.webkit.org/show_bug.cgi?id=147150
Reviewed by Oliver Hunt.
The bug was caused by parseClass assuming identifiers "get" and "set" could only appear
as the leading token for getter and setter methods. Fixed the bug by generalizing the code
so that we only treat them as such when it's followed by another token that could be a method name.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
2015-08-05 Filip Pizlo <fpizlo@apple.com>
Unreviewed, roll out http://trac.webkit.org/changeset/187972.
* bytecode/SamplingTool.cpp:
(JSC::SamplingTool::doRun):
(JSC::SamplingTool::notifyOfScope):
* bytecode/SamplingTool.h:
* dfg/DFGThreadData.h:
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::~Worklist):
(JSC::DFG::Worklist::isActiveForVM):
(JSC::DFG::Worklist::enqueue):
(JSC::DFG::Worklist::compilationState):
(JSC::DFG::Worklist::waitUntilAllPlansForVMAreReady):
(JSC::DFG::Worklist::removeAllReadyPlansForVM):
(JSC::DFG::Worklist::completeAllReadyPlansForVM):
(JSC::DFG::Worklist::visitWeakReferences):
(JSC::DFG::Worklist::removeDeadPlans):
(JSC::DFG::Worklist::queueLength):
(JSC::DFG::Worklist::dump):
(JSC::DFG::Worklist::runThread):
* dfg/DFGWorklist.h:
* disassembler/Disassembler.cpp:
* heap/CopiedSpace.cpp:
(JSC::CopiedSpace::doneFillingBlock):
(JSC::CopiedSpace::doneCopying):
* heap/CopiedSpace.h:
* heap/CopiedSpaceInlines.h:
(JSC::CopiedSpace::recycleBorrowedBlock):
(JSC::CopiedSpace::allocateBlockForCopyingPhase):
* heap/HeapTimer.h:
* heap/MachineStackMarker.cpp:
(JSC::ActiveMachineThreadsManager::Locker::Locker):
(JSC::ActiveMachineThreadsManager::add):
(JSC::ActiveMachineThreadsManager::remove):
(JSC::ActiveMachineThreadsManager::ActiveMachineThreadsManager):
(JSC::MachineThreads::~MachineThreads):
(JSC::MachineThreads::addCurrentThread):
(JSC::MachineThreads::removeThreadIfFound):
(JSC::MachineThreads::tryCopyOtherThreadStack):
(JSC::MachineThreads::tryCopyOtherThreadStacks):
(JSC::MachineThreads::gatherConservativeRoots):
* heap/MachineStackMarker.h:
* interpreter/JSStack.cpp:
(JSC::stackStatisticsMutex):
(JSC::JSStack::addToCommittedByteCount):
(JSC::JSStack::committedByteCount):
* jit/JITThunks.h:
* profiler/ProfilerDatabase.h:
2015-08-05 Saam barati <saambarati1@gmail.com>
Bytecodegenerator emits crappy code for returns in a lexical scope.
https://bugs.webkit.org/show_bug.cgi?id=147688
Reviewed by Mark Lam.
When returning, we only need to emit complex pop scopes if we're in
a finally block. Otherwise, we can just return like normal. This saves
us from inefficiently emitting unnecessary pop scopes.
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::isInFinallyBlock):
(JSC::BytecodeGenerator::hasFinaliser): Deleted.
* bytecompiler/NodesCodegen.cpp:
(JSC::ReturnNode::emitBytecode):
2015-08-05 Benjamin Poulain <benjamin@webkit.org>
Add the Intl API to the status page
* features.json:
Andy VanWagoner landed the skeleton of the API and it is
enabled by default.
2015-08-04 Filip Pizlo <fpizlo@apple.com>
Rename Mutex to DeprecatedMutex
https://bugs.webkit.org/show_bug.cgi?id=147675
Reviewed by Geoffrey Garen.
* bytecode/SamplingTool.cpp:
(JSC::SamplingTool::doRun):
(JSC::SamplingTool::notifyOfScope):
* bytecode/SamplingTool.h:
* dfg/DFGThreadData.h:
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::~Worklist):
(JSC::DFG::Worklist::isActiveForVM):
(JSC::DFG::Worklist::enqueue):
(JSC::DFG::Worklist::compilationState):
(JSC::DFG::Worklist::waitUntilAllPlansForVMAreReady):
(JSC::DFG::Worklist::removeAllReadyPlansForVM):
(JSC::DFG::Worklist::completeAllReadyPlansForVM):
(JSC::DFG::Worklist::visitWeakReferences):
(JSC::DFG::Worklist::removeDeadPlans):
(JSC::DFG::Worklist::queueLength):
(JSC::DFG::Worklist::dump):
(JSC::DFG::Worklist::runThread):
* dfg/DFGWorklist.h:
* disassembler/Disassembler.cpp:
* heap/CopiedSpace.cpp:
(JSC::CopiedSpace::doneFillingBlock):
(JSC::CopiedSpace::doneCopying):
* heap/CopiedSpace.h:
* heap/CopiedSpaceInlines.h:
(JSC::CopiedSpace::recycleBorrowedBlock):
(JSC::CopiedSpace::allocateBlockForCopyingPhase):
* heap/HeapTimer.h:
* heap/MachineStackMarker.cpp:
(JSC::ActiveMachineThreadsManager::Locker::Locker):
(JSC::ActiveMachineThreadsManager::add):
(JSC::ActiveMachineThreadsManager::remove):
(JSC::ActiveMachineThreadsManager::ActiveMachineThreadsManager):
(JSC::MachineThreads::~MachineThreads):
(JSC::MachineThreads::addCurrentThread):
(JSC::MachineThreads::removeThreadIfFound):
(JSC::MachineThreads::tryCopyOtherThreadStack):
(JSC::MachineThreads::tryCopyOtherThreadStacks):
(JSC::MachineThreads::gatherConservativeRoots):
* heap/MachineStackMarker.h:
* interpreter/JSStack.cpp:
(JSC::stackStatisticsMutex):
(JSC::JSStack::addToCommittedByteCount):
(JSC::JSStack::committedByteCount):
* jit/JITThunks.h:
* profiler/ProfilerDatabase.h:
2015-08-05 Saam barati <saambarati1@gmail.com>
Replace JSFunctionNameScope with JSLexicalEnvironment for the function name scope.
https://bugs.webkit.org/show_bug.cgi?id=147657
Reviewed by Mark Lam.
This kills the last of the name scope objects. Function name scopes are
now built on top of the scoping mechanisms introduced with ES6 block scoping.
A name scope is now just a JSLexicalEnvironment. We treat assignments to the
function name scoped variable carefully depending on if the function is in
strict mode. If we're in strict mode, then we treat the variable exactly
like a "const" variable. If we're not in strict mode, we can't treat
this variable like like ES6 "const" because that would cause the bytecode
generator to throw an exception when it shouldn't.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
(JSC::BytecodeGenerator::pushLexicalScope):
(JSC::BytecodeGenerator::pushLexicalScopeInternal):
(JSC::BytecodeGenerator::variable):
(JSC::BytecodeGenerator::resolveType):
(JSC::BytecodeGenerator::emitThrowTypeError):
(JSC::BytecodeGenerator::emitPushFunctionNameScope):
(JSC::BytecodeGenerator::pushScopedControlFlowContext):
(JSC::BytecodeGenerator::emitPushCatchScope):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
* debugger/DebuggerScope.cpp:
* dfg/DFGOperations.cpp:
* interpreter/Interpreter.cpp:
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_to_string):
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_push_name_scope): Deleted.
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emitSlow_op_to_string):
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_push_name_scope): Deleted.
* jit/JITOperations.cpp:
(JSC::pushNameScope): Deleted.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
* parser/Nodes.cpp:
* runtime/CommonSlowPaths.cpp:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
* runtime/JSFunctionNameScope.cpp: Removed.
* runtime/JSFunctionNameScope.h: Removed.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::withScopeStructure):
(JSC::JSGlobalObject::strictEvalActivationStructure):
(JSC::JSGlobalObject::activationStructure):
(JSC::JSGlobalObject::directArgumentsStructure):
(JSC::JSGlobalObject::scopedArgumentsStructure):
(JSC::JSGlobalObject::outOfBandArgumentsStructure):
(JSC::JSGlobalObject::functionNameScopeStructure): Deleted.
* runtime/JSNameScope.cpp: Removed.
* runtime/JSNameScope.h: Removed.
* runtime/JSObject.cpp:
(JSC::JSObject::toThis):
(JSC::JSObject::seal):
(JSC::JSObject::isFunctionNameScopeObject): Deleted.
* runtime/JSObject.h:
* runtime/JSScope.cpp:
(JSC::JSScope::isCatchScope):
(JSC::JSScope::isFunctionNameScopeObject):
(JSC::resolveModeName):
* runtime/JSScope.h:
* runtime/JSSymbolTableObject.cpp:
* runtime/SymbolTable.h:
* runtime/VM.cpp:
2015-08-05 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Improve Support for PropertyName Iterator (Reflect.enumerate) in Inspector
https://bugs.webkit.org/show_bug.cgi?id=147679
Reviewed by Timothy Hatcher.
Improve native iterator support for the PropertyName Iterator by
allowing inspection of the internal object within the iterator
and peeking of the next upcoming values of the iterator.
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::subtype):
(Inspector::JSInjectedScriptHost::getInternalProperties):
(Inspector::JSInjectedScriptHost::iteratorEntries):
* runtime/JSPropertyNameIterator.h:
(JSC::JSPropertyNameIterator::iteratedValue):
2015-08-04 Brent Fulgham <bfulgham@apple.com>
[Win] Update Apple Windows build for VS2015
https://bugs.webkit.org/show_bug.cgi?id=147653
Reviewed by Dean Jackson.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Drive-by-fix.
Show JSC files in proper project locations in IDE.
2015-08-04 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Object previews for SVG elements shows SVGAnimatedString instead of text
https://bugs.webkit.org/show_bug.cgi?id=147328
Reviewed by Timothy Hatcher.
* inspector/InjectedScriptSource.js:
Use classList and classList.toString instead of className.
2015-08-04 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Support Module Syntax
https://bugs.webkit.org/show_bug.cgi?id=147422
Reviewed by Saam Barati.
This patch introduces ES6 Modules syntax parsing part.
In this patch, ASTBuilder just produces the corresponding nodes to the ES6 Modules syntax,
and this patch does not include the code generator part.
Modules require 2 phase parsing. In the first pass, we just analyze the dependent modules
and do not execute the body or construct the AST. And after analyzing all the dependent
modules, we will parse the dependent modules next.
After all analyzing part is done, we will start the second pass. In the second pass, we
will parse the module, produce the AST, and execute the body.
If we don't do so, we need to create all the ASTs in the module's dependent graph at first
because the given module can be executed after the all dependent modules are executed. It
means that we need to hold so many parser arenas. To avoid this, the first pass only extracts
the dependent modules' information.
In this patch, we don't add this analyzing part yet. This patch only implements the second pass.
This patch aims at just implementing the syntax parsing functionality correctly.
After this patch is landed, we will create the ModuleDependencyAnalyzer that inherits SyntaxChecker
to collect the dependent modules fast[1].
To test the parsing, we added the "checkModuleSyntax" function into jsc shell.
By using this, we can parse the given string as the module.
[1]: https://bugs.webkit.org/show_bug.cgi?id=147353
* bytecompiler/NodesCodegen.cpp:
(JSC::ModuleProgramNode::emitBytecode):
(JSC::ImportDeclarationNode::emitBytecode):
(JSC::ExportAllDeclarationNode::emitBytecode):
(JSC::ExportDefaultDeclarationNode::emitBytecode):
(JSC::ExportLocalDeclarationNode::emitBytecode):
(JSC::ExportNamedDeclarationNode::emitBytecode):
* jsc.cpp:
(GlobalObject::finishCreation):
(functionCheckModuleSyntax):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createModuleSpecifier):
(JSC::ASTBuilder::createImportSpecifier):
(JSC::ASTBuilder::createImportSpecifierList):
(JSC::ASTBuilder::appendImportSpecifier):
(JSC::ASTBuilder::createImportDeclaration):
(JSC::ASTBuilder::createExportAllDeclaration):
(JSC::ASTBuilder::createExportDefaultDeclaration):
(JSC::ASTBuilder::createExportLocalDeclaration):
(JSC::ASTBuilder::createExportNamedDeclaration):
(JSC::ASTBuilder::createExportSpecifier):
(JSC::ASTBuilder::createExportSpecifierList):
(JSC::ASTBuilder::appendExportSpecifier):
* parser/Keywords.table:
* parser/NodeConstructors.h:
(JSC::ModuleSpecifierNode::ModuleSpecifierNode):
(JSC::ImportSpecifierNode::ImportSpecifierNode):
(JSC::ImportDeclarationNode::ImportDeclarationNode):
(JSC::ExportAllDeclarationNode::ExportAllDeclarationNode):
(JSC::ExportDefaultDeclarationNode::ExportDefaultDeclarationNode):
(JSC::ExportLocalDeclarationNode::ExportLocalDeclarationNode):
(JSC::ExportNamedDeclarationNode::ExportNamedDeclarationNode):
(JSC::ExportSpecifierNode::ExportSpecifierNode):
* parser/Nodes.cpp:
(JSC::ModuleProgramNode::ModuleProgramNode):
* parser/Nodes.h:
(JSC::ModuleProgramNode::startColumn):
(JSC::ModuleProgramNode::endColumn):
(JSC::ModuleSpecifierNode::moduleName):
(JSC::ImportSpecifierNode::importedName):
(JSC::ImportSpecifierNode::localName):
(JSC::ImportSpecifierListNode::specifiers):
(JSC::ImportSpecifierListNode::append):
(JSC::ImportDeclarationNode::specifierList):
(JSC::ImportDeclarationNode::moduleSpecifier):
(JSC::ExportAllDeclarationNode::moduleSpecifier):
(JSC::ExportDefaultDeclarationNode::declaration):
(JSC::ExportLocalDeclarationNode::declaration):
(JSC::ExportSpecifierNode::exportedName):
(JSC::ExportSpecifierNode::localName):
(JSC::ExportSpecifierListNode::specifiers):
(JSC::ExportSpecifierListNode::append):
(JSC::ExportNamedDeclarationNode::specifierList):
(JSC::ExportNamedDeclarationNode::moduleSpecifier):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::Parser):
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseModuleSourceElements):
(JSC::Parser<LexerType>::parseVariableDeclaration):
(JSC::Parser<LexerType>::parseVariableDeclarationList):
(JSC::Parser<LexerType>::createBindingPattern):
(JSC::Parser<LexerType>::tryParseDestructuringPatternExpression):
(JSC::Parser<LexerType>::parseDestructuringPattern):
(JSC::Parser<LexerType>::parseForStatement):
(JSC::Parser<LexerType>::parseFormalParameters):
(JSC::Parser<LexerType>::parseFunctionParameters):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseClassDeclaration):
(JSC::Parser<LexerType>::parseModuleSpecifier):
(JSC::Parser<LexerType>::parseImportClauseItem):
(JSC::Parser<LexerType>::parseImportDeclaration):
(JSC::Parser<LexerType>::parseExportSpecifier):
(JSC::Parser<LexerType>::parseExportDeclaration):
(JSC::Parser<LexerType>::parseMemberExpression):
* parser/Parser.h:
(JSC::isIdentifierOrKeyword):
(JSC::ModuleScopeData::create):
(JSC::ModuleScopeData::exportedBindings):
(JSC::ModuleScopeData::exportName):
(JSC::ModuleScopeData::exportBinding):
(JSC::Scope::Scope):
(JSC::Scope::setIsModule):
(JSC::Scope::moduleScopeData):
(JSC::Parser::matchContextualKeyword):
(JSC::Parser::matchIdentifierOrKeyword):
(JSC::Parser::isofToken): Deleted.
* parser/ParserModes.h:
* parser/ParserTokens.h:
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createModuleSpecifier):
(JSC::SyntaxChecker::createImportSpecifier):
(JSC::SyntaxChecker::createImportSpecifierList):
(JSC::SyntaxChecker::appendImportSpecifier):
(JSC::SyntaxChecker::createImportDeclaration):
(JSC::SyntaxChecker::createExportAllDeclaration):
(JSC::SyntaxChecker::createExportDefaultDeclaration):
(JSC::SyntaxChecker::createExportLocalDeclaration):
(JSC::SyntaxChecker::createExportNamedDeclaration):
(JSC::SyntaxChecker::createExportSpecifier):
(JSC::SyntaxChecker::createExportSpecifierList):
(JSC::SyntaxChecker::appendExportSpecifier):
* runtime/CommonIdentifiers.cpp:
(JSC::CommonIdentifiers::CommonIdentifiers):
* runtime/CommonIdentifiers.h:
* runtime/Completion.cpp:
(JSC::checkModuleSyntax):
* runtime/Completion.h:
* tests/stress/modules-syntax-error-with-names.js: Added.
(shouldThrow):
* tests/stress/modules-syntax-error.js: Added.
(shouldThrow):
(checkModuleSyntaxError.checkModuleSyntaxError.checkModuleSyntaxError):
* tests/stress/modules-syntax.js: Added.
(prototype.checkModuleSyntax):
(checkModuleSyntax):
* tests/stress/tagged-templates-syntax.js:
2015-08-03 Csaba Osztrogonác <ossy@webkit.org>
Introduce COMPILER(GCC_OR_CLANG) guard and make COMPILER(GCC) true only for GCC
https://bugs.webkit.org/show_bug.cgi?id=146833
Reviewed by Alexey Proskuryakov.
* assembler/ARM64Assembler.h:
* assembler/ARMAssembler.h:
(JSC::ARMAssembler::cacheFlush):
* assembler/MacroAssemblerARM.cpp:
(JSC::isVFPPresent):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::isSSE2Present):
* heap/MachineStackMarker.h:
* interpreter/StackVisitor.cpp: Removed redundant COMPILER(CLANG) guards.
(JSC::logF):
* jit/HostCallReturnValue.h:
* jit/JIT.h:
* jit/JITOperations.cpp:
* jit/JITStubsARM.h:
* jit/JITStubsARMv7.h:
* jit/JITStubsX86.h:
* jit/JITStubsX86Common.h:
* jit/JITStubsX86_64.h:
* jit/ThunkGenerators.cpp:
* runtime/JSExportMacros.h:
* runtime/MathCommon.h: Removed redundant COMPILER(CLANG) guard.
(JSC::clz32):
2015-08-03 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix uninitialized property leading to an assert.
* runtime/PutPropertySlot.h:
(JSC::PutPropertySlot::PutPropertySlot):
2015-08-03 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix Windows.
* bytecode/ObjectPropertyConditionSet.h:
(JSC::ObjectPropertyConditionSet::fromRawPointer):
2015-07-31 Filip Pizlo <fpizlo@apple.com>
DFG should have adaptive structure watchpoints
https://bugs.webkit.org/show_bug.cgi?id=146929
Reviewed by Geoffrey Garen.
Before this change, if you wanted to efficiently validate whether an object has (or doesn't have) a
property, you'd check that the object still has the structure that you first saw the object have. We
optimized this a bit with transition watchpoints on the structure, which sometimes allowed us to
elide the structure check.
But this approach fails when that object frequently has new properties added to it. This would
change the structure and fire the transition watchpoint, so the code we emitted would be invalid and
we'd have to recompile either the IC or an entire code block.
This change introduces a new concept: an object property condition. This value describes some
condition involving a property on some object. There are four kinds: presence, absence,
absence-of-setter, and equivalence. For example, a presence condition says that we expect that the
object has some property at some offset with some attributes. This allows us to implement a new kind
of watchpoint, which knows about the object property condition that it's being used to enforce. If
the watchpoint fires because of a structure transition, the watchpoint may simply reinstall itself
on the new structure.
Object property conditions are used on the prototype chain of PutById transitions, GetById misses,
and prototype accesses. They are also used for any DFG accesses to object constants, including
global property accesses.
Mostly because of the effect on global property access, this is a 9% speed-up on Kraken. It's
neutral on most other things. It's a 68x speed-up on a microbenchmark that illustrates the prototype
chain situation. It's also a small speed-up on getter-richards.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::printGetByIdCacheStatus):
(JSC::CodeBlock::printPutByIdCacheStatus):
* bytecode/CodeBlockJettisoningWatchpoint.cpp:
(JSC::CodeBlockJettisoningWatchpoint::fireInternal):
* bytecode/ComplexGetStatus.cpp:
(JSC::ComplexGetStatus::computeFor):
* bytecode/ComplexGetStatus.h:
(JSC::ComplexGetStatus::ComplexGetStatus):
(JSC::ComplexGetStatus::takesSlowPath):
(JSC::ComplexGetStatus::kind):
(JSC::ComplexGetStatus::offset):
(JSC::ComplexGetStatus::conditionSet):
(JSC::ComplexGetStatus::attributes): Deleted.
(JSC::ComplexGetStatus::specificValue): Deleted.
(JSC::ComplexGetStatus::chain): Deleted.
* bytecode/ConstantStructureCheck.cpp: Removed.
* bytecode/ConstantStructureCheck.h: Removed.
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeForStubInfo):
* bytecode/GetByIdVariant.cpp:
(JSC::GetByIdVariant::GetByIdVariant):
(JSC::GetByIdVariant::~GetByIdVariant):
(JSC::GetByIdVariant::operator=):
(JSC::GetByIdVariant::attemptToMerge):
(JSC::GetByIdVariant::dumpInContext):
(JSC::GetByIdVariant::baseStructure): Deleted.
* bytecode/GetByIdVariant.h:
(JSC::GetByIdVariant::operator!):
(JSC::GetByIdVariant::structureSet):
(JSC::GetByIdVariant::conditionSet):
(JSC::GetByIdVariant::offset):
(JSC::GetByIdVariant::callLinkStatus):
(JSC::GetByIdVariant::constantChecks): Deleted.
(JSC::GetByIdVariant::alternateBase): Deleted.
* bytecode/ObjectPropertyCondition.cpp: Added.
(JSC::ObjectPropertyCondition::dumpInContext):
(JSC::ObjectPropertyCondition::dump):
(JSC::ObjectPropertyCondition::structureEnsuresValidityAssumingImpurePropertyWatchpoint):
(JSC::ObjectPropertyCondition::validityRequiresImpurePropertyWatchpoint):
(JSC::ObjectPropertyCondition::isStillValid):
(JSC::ObjectPropertyCondition::structureEnsuresValidity):
(JSC::ObjectPropertyCondition::isWatchableAssumingImpurePropertyWatchpoint):
(JSC::ObjectPropertyCondition::isWatchable):
(JSC::ObjectPropertyCondition::isStillLive):
(JSC::ObjectPropertyCondition::validateReferences):
(JSC::ObjectPropertyCondition::attemptToMakeEquivalenceWithoutBarrier):
* bytecode/ObjectPropertyCondition.h: Added.
(JSC::ObjectPropertyCondition::ObjectPropertyCondition):
(JSC::ObjectPropertyCondition::presenceWithoutBarrier):
(JSC::ObjectPropertyCondition::presence):
(JSC::ObjectPropertyCondition::absenceWithoutBarrier):
(JSC::ObjectPropertyCondition::absence):
(JSC::ObjectPropertyCondition::absenceOfSetterWithoutBarrier):
(JSC::ObjectPropertyCondition::absenceOfSetter):
(JSC::ObjectPropertyCondition::equivalenceWithoutBarrier):
(JSC::ObjectPropertyCondition::equivalence):
(JSC::ObjectPropertyCondition::operator!):
(JSC::ObjectPropertyCondition::object):
(JSC::ObjectPropertyCondition::condition):
(JSC::ObjectPropertyCondition::kind):
(JSC::ObjectPropertyCondition::uid):
(JSC::ObjectPropertyCondition::hasOffset):
(JSC::ObjectPropertyCondition::offset):
(JSC::ObjectPropertyCondition::hasAttributes):
(JSC::ObjectPropertyCondition::attributes):
(JSC::ObjectPropertyCondition::hasPrototype):
(JSC::ObjectPropertyCondition::prototype):
(JSC::ObjectPropertyCondition::hasRequiredValue):
(JSC::ObjectPropertyCondition::requiredValue):
(JSC::ObjectPropertyCondition::hash):
(JSC::ObjectPropertyCondition::operator==):
(JSC::ObjectPropertyCondition::isHashTableDeletedValue):
(JSC::ObjectPropertyCondition::isCompatibleWith):
(JSC::ObjectPropertyCondition::watchingRequiresStructureTransitionWatchpoint):
(JSC::ObjectPropertyCondition::watchingRequiresReplacementWatchpoint):
(JSC::ObjectPropertyCondition::isValidValueForPresence):
(JSC::ObjectPropertyConditionHash::hash):
(JSC::ObjectPropertyConditionHash::equal):
* bytecode/ObjectPropertyConditionSet.cpp: Added.
(JSC::ObjectPropertyConditionSet::forObject):
(JSC::ObjectPropertyConditionSet::forConditionKind):
(JSC::ObjectPropertyConditionSet::numberOfConditionsWithKind):
(JSC::ObjectPropertyConditionSet::hasOneSlotBaseCondition):
(JSC::ObjectPropertyConditionSet::slotBaseCondition):
(JSC::ObjectPropertyConditionSet::mergedWith):
(JSC::ObjectPropertyConditionSet::structuresEnsureValidity):
(JSC::ObjectPropertyConditionSet::structuresEnsureValidityAssumingImpurePropertyWatchpoint):
(JSC::ObjectPropertyConditionSet::needImpurePropertyWatchpoint):
(JSC::ObjectPropertyConditionSet::areStillLive):
(JSC::ObjectPropertyConditionSet::dumpInContext):
(JSC::ObjectPropertyConditionSet::dump):
(JSC::generateConditionsForPropertyMiss):
(JSC::generateConditionsForPropertySetterMiss):
(JSC::generateConditionsForPrototypePropertyHit):
(JSC::generateConditionsForPrototypePropertyHitCustom):
(JSC::generateConditionsForPropertySetterMissConcurrently):
* bytecode/ObjectPropertyConditionSet.h: Added.
(JSC::ObjectPropertyConditionSet::ObjectPropertyConditionSet):
(JSC::ObjectPropertyConditionSet::invalid):
(JSC::ObjectPropertyConditionSet::nonEmpty):
(JSC::ObjectPropertyConditionSet::isValid):
(JSC::ObjectPropertyConditionSet::isEmpty):
(JSC::ObjectPropertyConditionSet::begin):
(JSC::ObjectPropertyConditionSet::end):
(JSC::ObjectPropertyConditionSet::releaseRawPointer):
(JSC::ObjectPropertyConditionSet::adoptRawPointer):
(JSC::ObjectPropertyConditionSet::fromRawPointer):
(JSC::ObjectPropertyConditionSet::Data::Data):
* bytecode/PolymorphicGetByIdList.cpp:
(JSC::GetByIdAccess::GetByIdAccess):
(JSC::GetByIdAccess::~GetByIdAccess):
(JSC::GetByIdAccess::visitWeak):
* bytecode/PolymorphicGetByIdList.h:
(JSC::GetByIdAccess::GetByIdAccess):
(JSC::GetByIdAccess::structure):
(JSC::GetByIdAccess::conditionSet):
(JSC::GetByIdAccess::stubRoutine):
(JSC::GetByIdAccess::chain): Deleted.
(JSC::GetByIdAccess::chainCount): Deleted.
* bytecode/PolymorphicPutByIdList.cpp:
(JSC::PutByIdAccess::fromStructureStubInfo):
(JSC::PutByIdAccess::visitWeak):
* bytecode/PolymorphicPutByIdList.h:
(JSC::PutByIdAccess::PutByIdAccess):
(JSC::PutByIdAccess::transition):
(JSC::PutByIdAccess::setter):
(JSC::PutByIdAccess::newStructure):
(JSC::PutByIdAccess::conditionSet):
(JSC::PutByIdAccess::stubRoutine):
(JSC::PutByIdAccess::chain): Deleted.
(JSC::PutByIdAccess::chainCount): Deleted.
* bytecode/PropertyCondition.cpp: Added.
(JSC::PropertyCondition::dumpInContext):
(JSC::PropertyCondition::dump):
(JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint):
(JSC::PropertyCondition::validityRequiresImpurePropertyWatchpoint):
(JSC::PropertyCondition::isStillValid):
(JSC::PropertyCondition::isWatchableWhenValid):
(JSC::PropertyCondition::isWatchableAssumingImpurePropertyWatchpoint):
(JSC::PropertyCondition::isWatchable):
(JSC::PropertyCondition::isStillLive):
(JSC::PropertyCondition::validateReferences):
(JSC::PropertyCondition::isValidValueForAttributes):
(JSC::PropertyCondition::isValidValueForPresence):
(JSC::PropertyCondition::attemptToMakeEquivalenceWithoutBarrier):
(WTF::printInternal):
* bytecode/PropertyCondition.h: Added.
(JSC::PropertyCondition::PropertyCondition):
(JSC::PropertyCondition::presenceWithoutBarrier):
(JSC::PropertyCondition::presence):
(JSC::PropertyCondition::absenceWithoutBarrier):
(JSC::PropertyCondition::absence):
(JSC::PropertyCondition::absenceOfSetterWithoutBarrier):
(JSC::PropertyCondition::absenceOfSetter):
(JSC::PropertyCondition::equivalenceWithoutBarrier):
(JSC::PropertyCondition::equivalence):
(JSC::PropertyCondition::operator!):
(JSC::PropertyCondition::kind):
(JSC::PropertyCondition::uid):
(JSC::PropertyCondition::hasOffset):
(JSC::PropertyCondition::offset):
(JSC::PropertyCondition::hasAttributes):
(JSC::PropertyCondition::attributes):
(JSC::PropertyCondition::hasPrototype):
(JSC::PropertyCondition::prototype):
(JSC::PropertyCondition::hasRequiredValue):
(JSC::PropertyCondition::requiredValue):
(JSC::PropertyCondition::hash):
(JSC::PropertyCondition::operator==):
(JSC::PropertyCondition::isHashTableDeletedValue):
(JSC::PropertyCondition::isCompatibleWith):
(JSC::PropertyCondition::watchingRequiresStructureTransitionWatchpoint):
(JSC::PropertyCondition::watchingRequiresReplacementWatchpoint):
(JSC::PropertyConditionHash::hash):
(JSC::PropertyConditionHash::equal):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
(JSC::PutByIdStatus::computeFor):
(JSC::PutByIdStatus::computeForStubInfo):
* bytecode/PutByIdVariant.cpp:
(JSC::PutByIdVariant::operator=):
(JSC::PutByIdVariant::transition):
(JSC::PutByIdVariant::setter):
(JSC::PutByIdVariant::makesCalls):
(JSC::PutByIdVariant::attemptToMerge):
(JSC::PutByIdVariant::attemptToMergeTransitionWithReplace):
(JSC::PutByIdVariant::dumpInContext):
(JSC::PutByIdVariant::baseStructure): Deleted.
* bytecode/PutByIdVariant.h:
(JSC::PutByIdVariant::PutByIdVariant):
(JSC::PutByIdVariant::kind):
(JSC::PutByIdVariant::structure):
(JSC::PutByIdVariant::structureSet):
(JSC::PutByIdVariant::oldStructure):
(JSC::PutByIdVariant::conditionSet):
(JSC::PutByIdVariant::offset):
(JSC::PutByIdVariant::callLinkStatus):
(JSC::PutByIdVariant::constantChecks): Deleted.
(JSC::PutByIdVariant::alternateBase): Deleted.
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::~StructureStubClearingWatchpoint):
(JSC::StructureStubClearingWatchpoint::push):
(JSC::StructureStubClearingWatchpoint::fireInternal):
(JSC::WatchpointsOnStructureStubInfo::~WatchpointsOnStructureStubInfo):
(JSC::WatchpointsOnStructureStubInfo::addWatchpoint):
(JSC::WatchpointsOnStructureStubInfo::ensureReferenceAndAddWatchpoint):
* bytecode/StructureStubClearingWatchpoint.h:
(JSC::StructureStubClearingWatchpoint::StructureStubClearingWatchpoint):
(JSC::WatchpointsOnStructureStubInfo::codeBlock):
(JSC::WatchpointsOnStructureStubInfo::stubInfo):
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::deref):
(JSC::StructureStubInfo::visitWeakReferences):
* bytecode/StructureStubInfo.h:
(JSC::StructureStubInfo::initPutByIdTransition):
(JSC::StructureStubInfo::initPutByIdReplace):
(JSC::StructureStubInfo::setSeen):
(JSC::StructureStubInfo::addWatchpoint):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp: Added.
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::AdaptiveInferredPropertyValueWatchpoint):
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::install):
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::fire):
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::StructureWatchpoint::fireInternal):
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::PropertyWatchpoint::fireInternal):
* dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h: Added.
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::key):
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::StructureWatchpoint::StructureWatchpoint):
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::PropertyWatchpoint::PropertyWatchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.cpp: Added.
(JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
(JSC::DFG::AdaptiveStructureWatchpoint::install):
(JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
* dfg/DFGAdaptiveStructureWatchpoint.h: Added.
(JSC::DFG::AdaptiveStructureWatchpoint::key):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::cellConstantWithStructureCheck):
(JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
(JSC::DFG::ByteCodeParser::handleGetByOffset):
(JSC::DFG::ByteCodeParser::handlePutByOffset):
(JSC::DFG::ByteCodeParser::check):
(JSC::DFG::ByteCodeParser::promoteToConstant):
(JSC::DFG::ByteCodeParser::planLoad):
(JSC::DFG::ByteCodeParser::load):
(JSC::DFG::ByteCodeParser::presenceLike):
(JSC::DFG::ByteCodeParser::checkPresenceLike):
(JSC::DFG::ByteCodeParser::store):
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::handlePutById):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::emitChecks): Deleted.
* dfg/DFGCommonData.cpp:
(JSC::DFG::CommonData::validateReferences):
* dfg/DFGCommonData.h:
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
(JSC::DFG::ConstantFoldingPhase::emitGetByOffset):
(JSC::DFG::ConstantFoldingPhase::addBaseCheck):
(JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck):
(JSC::DFG::ConstantFoldingPhase::addChecks): Deleted.
* dfg/DFGDesiredWatchpoints.cpp:
(JSC::DFG::ArrayBufferViewWatchpointAdaptor::add):
(JSC::DFG::InferredValueAdaptor::add):
(JSC::DFG::AdaptiveStructureWatchpointAdaptor::add):
(JSC::DFG::DesiredWatchpoints::DesiredWatchpoints):
(JSC::DFG::DesiredWatchpoints::addLazily):
(JSC::DFG::DesiredWatchpoints::consider):
(JSC::DFG::DesiredWatchpoints::reallyAdd):
(JSC::DFG::DesiredWatchpoints::areStillValid):
(JSC::DFG::DesiredWatchpoints::dumpInContext):
* dfg/DFGDesiredWatchpoints.h:
(JSC::DFG::SetPointerAdaptor::add):
(JSC::DFG::SetPointerAdaptor::hasBeenInvalidated):
(JSC::DFG::SetPointerAdaptor::dumpInContext):
(JSC::DFG::InferredValueAdaptor::hasBeenInvalidated):
(JSC::DFG::InferredValueAdaptor::dumpInContext):
(JSC::DFG::ArrayBufferViewWatchpointAdaptor::hasBeenInvalidated):
(JSC::DFG::ArrayBufferViewWatchpointAdaptor::dumpInContext):
(JSC::DFG::AdaptiveStructureWatchpointAdaptor::hasBeenInvalidated):
(JSC::DFG::AdaptiveStructureWatchpointAdaptor::dumpInContext):
(JSC::DFG::GenericDesiredWatchpoints::reallyAdd):
(JSC::DFG::GenericDesiredWatchpoints::isWatched):
(JSC::DFG::GenericDesiredWatchpoints::dumpInContext):
(JSC::DFG::DesiredWatchpoints::isWatched):
(JSC::DFG::GenericSetAdaptor::add): Deleted.
(JSC::DFG::GenericSetAdaptor::hasBeenInvalidated): Deleted.
* dfg/DFGDesiredWeakReferences.cpp:
(JSC::DFG::DesiredWeakReferences::addLazily):
(JSC::DFG::DesiredWeakReferences::contains):
* dfg/DFGDesiredWeakReferences.h:
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
(JSC::DFG::Graph::clearFlagsOnAllNodes):
(JSC::DFG::Graph::watchCondition):
(JSC::DFG::Graph::isSafeToLoad):
(JSC::DFG::Graph::livenessFor):
(JSC::DFG::Graph::tryGetConstantProperty):
(JSC::DFG::Graph::visitChildren):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::identifiers):
(JSC::DFG::Graph::watchpoints):
* dfg/DFGMultiGetByOffsetData.cpp: Added.
(JSC::DFG::GetByOffsetMethod::dumpInContext):
(JSC::DFG::GetByOffsetMethod::dump):
(JSC::DFG::MultiGetByOffsetCase::dumpInContext):
(JSC::DFG::MultiGetByOffsetCase::dump):
(WTF::printInternal):
* dfg/DFGMultiGetByOffsetData.h: Added.
(JSC::DFG::GetByOffsetMethod::GetByOffsetMethod):
(JSC::DFG::GetByOffsetMethod::constant):
(JSC::DFG::GetByOffsetMethod::load):
(JSC::DFG::GetByOffsetMethod::loadFromPrototype):
(JSC::DFG::GetByOffsetMethod::operator!):
(JSC::DFG::GetByOffsetMethod::kind):
(JSC::DFG::GetByOffsetMethod::prototype):
(JSC::DFG::GetByOffsetMethod::offset):
(JSC::DFG::MultiGetByOffsetCase::MultiGetByOffsetCase):
(JSC::DFG::MultiGetByOffsetCase::set):
(JSC::DFG::MultiGetByOffsetCase::method):
* dfg/DFGNode.h:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGStructureRegistrationPhase.cpp:
(JSC::DFG::StructureRegistrationPhase::run):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileMultiGetByOffset):
* jit/Repatch.cpp:
(JSC::repatchByIdSelfAccess):
(JSC::checkObjectPropertyCondition):
(JSC::checkObjectPropertyConditions):
(JSC::replaceWithJump):
(JSC::generateByIdStub):
(JSC::actionForCell):
(JSC::tryBuildGetByIDList):
(JSC::emitPutReplaceStub):
(JSC::emitPutTransitionStub):
(JSC::tryCachePutByID):
(JSC::tryBuildPutByIdList):
(JSC::tryRepatchIn):
(JSC::addStructureTransitionCheck): Deleted.
(JSC::emitPutTransitionStubAndGetOldStructure): Deleted.
* runtime/IntendedStructureChain.cpp: Removed.
* runtime/IntendedStructureChain.h: Removed.
* runtime/JSCJSValue.h:
* runtime/JSObject.cpp:
(JSC::throwTypeError):
(JSC::JSObject::convertToDictionary):
(JSC::JSObject::shiftButterflyAfterFlattening):
* runtime/JSObject.h:
(JSC::JSObject::flattenDictionaryObject):
(JSC::JSObject::convertToDictionary): Deleted.
* runtime/Operations.h:
(JSC::normalizePrototypeChain):
(JSC::normalizePrototypeChainForChainAccess): Deleted.
(JSC::isPrototypeChainNormalized): Deleted.
* runtime/PropertySlot.h:
(JSC::PropertySlot::PropertySlot):
(JSC::PropertySlot::slotBase):
* runtime/Structure.cpp:
(JSC::Structure::addPropertyTransition):
(JSC::Structure::attributeChangeTransition):
(JSC::Structure::toDictionaryTransition):
(JSC::Structure::toCacheableDictionaryTransition):
(JSC::Structure::toUncacheableDictionaryTransition):
(JSC::Structure::ensurePropertyReplacementWatchpointSet):
(JSC::Structure::startWatchingPropertyForReplacements):
(JSC::Structure::didCachePropertyReplacement):
(JSC::Structure::dump):
* runtime/Structure.h:
* runtime/VM.h:
* tests/stress/fold-multi-get-by-offset-to-get-by-offset-without-folding-the-structure-check-new.js: Added.
(foo):
(bar):
(baz):
* tests/stress/multi-get-by-offset-self-or-proto.js: Added.
(foo):
* tests/stress/replacement-watchpoint-dictionary.js: Added.
(foo):
* tests/stress/replacement-watchpoint.js: Added.
(foo):
* tests/stress/undefined-access-dictionary-then-proto-change.js: Added.
(foo):
* tests/stress/undefined-access-then-proto-change.js: Added.
(foo):
2015-08-03 Yusuke Suzuki <utatane.tea@gmail.com>
JavascriptCore Crash in JSC::ASTBuilder::Property JSC::Parser<JSC::Lexer<unsigned char> >::parseProperty<JSC::ASTBuilder>(JSC::ASTBuilder&, bool)
https://bugs.webkit.org/show_bug.cgi?id=147538
Reviewed by Geoffrey Garen.
Due to the order of the ARROWFUNCTION token in JSTokenType enum, it is categorized as the one of the Keyword.
As a result, when lexing the property name that can take the keywords, the ARROWFUNCTION token is accidentally accepted.
This patch changes the order of the ARROWFUNCTION token in JSTokenType to make it the operator token.
* parser/ParserTokens.h:
* tests/stress/arrow-function-token-is-not-keyword.js: Added.
(testSyntaxError):
2015-08-03 Keith Miller <keith_miller@apple.com>
Clean up the naming for AST expression generation.
https://bugs.webkit.org/show_bug.cgi?id=147581
Reviewed by Yusuke Suzuki.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createThisExpr):
(JSC::ASTBuilder::createSuperExpr):
(JSC::ASTBuilder::createNewTargetExpr):
(JSC::ASTBuilder::thisExpr): Deleted.
(JSC::ASTBuilder::superExpr): Deleted.
(JSC::ASTBuilder::newTargetExpr): Deleted.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parsePrimaryExpression):
(JSC::Parser<LexerType>::parseMemberExpression):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createThisExpr):
(JSC::SyntaxChecker::createSuperExpr):
(JSC::SyntaxChecker::createNewTargetExpr):
(JSC::SyntaxChecker::thisExpr): Deleted.
(JSC::SyntaxChecker::superExpr): Deleted.
(JSC::SyntaxChecker::newTargetExpr): Deleted.
2015-08-03 Yusuke Suzuki <utatane.tea@gmail.com>
Don't set up the callsite to operationGetByValDefault when the optimization is already done
https://bugs.webkit.org/show_bug.cgi?id=147577
Reviewed by Filip Pizlo.
operationGetByValDefault should be called only when the IC is not set.
operationGetByValString breaks this invariant and `ASSERT(!byValInfo.stubRoutine)` in
operationGetByValDefault raises the assertion failure.
In this patch, we change the callsite setting up code in operationGetByValString when
the IC is already set. And to make the operation's meaning explicitly, we changed the
name operationGetByValDefault to operationGetByValOptimize, that is aligned to the
GetById case.
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitSlow_op_get_by_val):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emitSlow_op_get_by_val):
* tests/stress/operation-get-by-val-default-should-not-called-for-already-optimized-site.js: Added.
(hello):
2015-08-03 Csaba Osztrogonác <ossy@webkit.org>
[FTL] Remove unused scripts related to native call inlining
https://bugs.webkit.org/show_bug.cgi?id=147448
Reviewed by Filip Pizlo.
* build-symbol-table-index.py: Removed.
* copy-llvm-ir-to-derived-sources.sh: Removed.
* create-llvm-ir-from-source-file.py: Removed.
* create-symbol-table-index.py: Removed.
2015-08-02 Benjamin Poulain <bpoulain@apple.com>
Investigate HashTable::HashTable(const HashTable&) and HashTable::operator=(const HashTable&) performance for hash-based static analyses
https://bugs.webkit.org/show_bug.cgi?id=118455
Reviewed by Filip Pizlo.
LivenessAnalysisPhase lights up like a christmas tree in profiles.
This patch cuts its cost by 4.
About half of the gains come from removing many rehash() when copying
the HashSet.
The last quarter is achieved by having a special add() function for initializing
a HashSet.
This makes benchmarks progress by 1-2% here and there. Nothing massive.
* dfg/DFGLivenessAnalysisPhase.cpp:
(JSC::DFG::LivenessAnalysisPhase::process):
The m_live HashSet is only useful per block. When we are done with it,
we can transfer it to liveAtHead to avoid a copy.
2015-08-01 Saam barati <saambarati1@gmail.com>
Unreviewed. Remove unintentional "print" statement in test case.
https://bugs.webkit.org/show_bug.cgi?id=142567
* tests/stress/class-syntax-definition-semantics.js:
(shouldBeSyntaxError):
2015-07-31 Alex Christensen <achristensen@webkit.org>
Prepare for VS2015
https://bugs.webkit.org/show_bug.cgi?id=146579
Reviewed by Jon Honeycutt.
* heap/Heap.h:
Fix compiler error by explicitly casting zombifiedBits to the size of a pointer.
2015-07-31 Saam barati <saambarati1@gmail.com>
ES6 class syntax should use block scoping
https://bugs.webkit.org/show_bug.cgi?id=142567
Reviewed by Geoffrey Garen.
We treat class declarations like we do "let" declarations.
The class name is under TDZ until the class declaration
statement is evaluated. Class declarations also follow
the same rules as "let": No duplicate definitions inside
a lexical environment.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createClassDeclStatement):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClassDeclaration):
* tests/stress/class-syntax-block-scoping.js: Added.
(assert):
(truth):
(.):
* tests/stress/class-syntax-definition-semantics.js: Added.
(shouldBeSyntaxError):
(shouldNotBeSyntaxError):
(truth):
* tests/stress/class-syntax-tdz.js:
(assert):
(shouldThrowTDZ):
(truth):
(.):
2015-07-31 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement WebAssembly module parser
https://bugs.webkit.org/show_bug.cgi?id=147293
Reviewed by Mark Lam.
Re-landing after fix for the "..\..\jsc.cpp(46): fatal error C1083: Cannot open
include file: 'JSWASMModule.h'" issue on Windows.
Implement WebAssembly module parser for WebAssembly files produced by pack-asmjs
<https://github.com/WebAssembly/polyfill-prototype-1>. This patch only checks
the magic number at the beginning of the files. Parsing of the rest will be
implemented in a subsequent patch.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* jsc.cpp:
(GlobalObject::finishCreation):
(functionLoadWebAssembly):
* parser/SourceProvider.h:
(JSC::WebAssemblySourceProvider::create):
(JSC::WebAssemblySourceProvider::data):
(JSC::WebAssemblySourceProvider::WebAssemblySourceProvider):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::wasmModuleStructure):
* wasm/WASMMagicNumber.h: Added.
* wasm/WASMModuleParser.cpp: Added.
(JSC::WASMModuleParser::WASMModuleParser):
(JSC::WASMModuleParser::parse):
(JSC::WASMModuleParser::parseModule):
(JSC::parseWebAssembly):
* wasm/WASMModuleParser.h: Added.
* wasm/WASMReader.cpp: Added.
(JSC::WASMReader::readUnsignedInt32):
(JSC::WASMReader::readFloat):
(JSC::WASMReader::readDouble):
* wasm/WASMReader.h: Added.
(JSC::WASMReader::WASMReader):
2015-07-30 Sukolsak Sakshuwong <sukolsak@gmail.com>
Add the "wasm" directory to the Additional Include Directories for jsc.exe
https://bugs.webkit.org/show_bug.cgi?id=147443
Reviewed by Mark Lam.
This patch should fix the "..\..\jsc.cpp(46): fatal error C1083:
Cannot open include file: 'JSWASMModule.h'" error in the Windows build.
* JavaScriptCore.vcxproj/jsc/jscCommon.props:
2015-07-30 Chris Dumez <cdumez@apple.com>
Mark more classes as fast allocated
https://bugs.webkit.org/show_bug.cgi?id=147440
Reviewed by Sam Weinig.
Mark more classes as fast allocated for performance. We heap-allocate
objects of those types throughout the code base.
* API/JSCallbackObject.h:
* API/ObjCCallbackFunction.mm:
* bytecode/BytecodeKills.h:
* bytecode/BytecodeLivenessAnalysis.h:
* bytecode/CallLinkStatus.h:
* bytecode/FullBytecodeLiveness.h:
* bytecode/SamplingTool.h:
* bytecompiler/BytecodeGenerator.h:
* dfg/DFGBasicBlock.h:
* dfg/DFGBlockMap.h:
* dfg/DFGInPlaceAbstractState.h:
* dfg/DFGThreadData.h:
* heap/HeapVerifier.h:
* heap/SlotVisitor.h:
* parser/Lexer.h:
* runtime/ControlFlowProfiler.h:
* runtime/TypeProfiler.h:
* runtime/TypeProfilerLog.h:
* runtime/Watchdog.h:
2015-07-29 Filip Pizlo <fpizlo@apple.com>
DFG::ArgumentsEliminationPhase should emit a PutStack for all of the GetStacks that the ByteCodeParser emitted
https://bugs.webkit.org/show_bug.cgi?id=147433
rdar://problem/21668986
Reviewed by Mark Lam.
Ideally, the ByteCodeParser would only emit SetArgument nodes for named arguments. But
currently that's not what it does - it emits a SetArgument for every argument that a varargs
call may pass. Each SetArgument gets turned into a GetStack. This means that if
ArgumentsEliminationPhase optimizes away PutStacks for those varargs arguments that didn't
get passed or used, we get degenerate IR where we have a GetStack of something that didn't
have a PutStack.
This fixes the bug by removing the code to optimize away PutStacks in
ArgumentsEliminationPhase.
* dfg/DFGArgumentsEliminationPhase.cpp:
* tests/stress/varargs-inlining-underflow.js: Added.
(baz):
(bar):
(foo):
2015-07-29 Andy VanWagoner <thetalecrafter@gmail.com>
Implement basic types for ECMAScript Internationalization API
https://bugs.webkit.org/show_bug.cgi?id=146926
Reviewed by Benjamin Poulain.
Adds basic types for ECMA-402 2nd edition, but does not implement the full locale-aware features yet.
http://www.ecma-international.org/ecma-402/2.0/ECMA-402.pdf
* CMakeLists.txt: Added new Intl files.
* Configurations/FeatureDefines.xcconfig: Enable INTL.
* DerivedSources.make: Added Intl files.
* JavaScriptCore.xcodeproj/project.pbxproj: Added Intl files.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Added Intl files.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Added Intl files.
* runtime/CommonIdentifiers.h: Added Collator, NumberFormat, and DateTimeFormat.
* runtime/DateConstructor.cpp: Made Date.now public.
* runtime/DateConstructor.h: Made Date.now public.
* runtime/IntlCollator.cpp: Added.
(JSC::IntlCollator::create):
(JSC::IntlCollator::createStructure):
(JSC::IntlCollator::IntlCollator):
(JSC::IntlCollator::finishCreation):
(JSC::IntlCollator::destroy):
(JSC::IntlCollator::visitChildren):
(JSC::IntlCollator::setBoundCompare):
(JSC::IntlCollatorFuncCompare): Added placeholder implementation using codePointCompare.
* runtime/IntlCollator.h: Added.
(JSC::IntlCollator::constructor):
(JSC::IntlCollator::boundCompare):
* runtime/IntlCollatorConstructor.cpp: Added.
(JSC::IntlCollatorConstructor::create):
(JSC::IntlCollatorConstructor::createStructure):
(JSC::IntlCollatorConstructor::IntlCollatorConstructor):
(JSC::IntlCollatorConstructor::finishCreation):
(JSC::constructIntlCollator): Added Collator constructor (10.1.2).
(JSC::callIntlCollator): Added Collator constructor (10.1.2).
(JSC::IntlCollatorConstructor::getConstructData):
(JSC::IntlCollatorConstructor::getCallData):
(JSC::IntlCollatorConstructor::getOwnPropertySlot):
(JSC::IntlCollatorConstructorFuncSupportedLocalesOf): Added placeholder implementation returning [].
(JSC::IntlCollatorConstructor::visitChildren):
* runtime/IntlCollatorConstructor.h: Added.
(JSC::IntlCollatorConstructor::collatorStructure):
* runtime/IntlCollatorPrototype.cpp: Added.
(JSC::IntlCollatorPrototype::create):
(JSC::IntlCollatorPrototype::createStructure):
(JSC::IntlCollatorPrototype::IntlCollatorPrototype):
(JSC::IntlCollatorPrototype::finishCreation):
(JSC::IntlCollatorPrototype::getOwnPropertySlot):
(JSC::IntlCollatorPrototypeGetterCompare): Added compare getter (10.3.3)
(JSC::IntlCollatorPrototypeFuncResolvedOptions): Added placeholder implementation returning {}.
* runtime/IntlCollatorPrototype.h: Added.
* runtime/IntlDateTimeFormat.cpp: Added.
(JSC::IntlDateTimeFormat::create):
(JSC::IntlDateTimeFormat::createStructure):
(JSC::IntlDateTimeFormat::IntlDateTimeFormat):
(JSC::IntlDateTimeFormat::finishCreation):
(JSC::IntlDateTimeFormat::destroy):
(JSC::IntlDateTimeFormat::visitChildren):
(JSC::IntlDateTimeFormat::setBoundFormat):
(JSC::IntlDateTimeFormatFuncFormatDateTime): Added placeholder implementation returning new Date(value).toString().
* runtime/IntlDateTimeFormat.h: Added.
(JSC::IntlDateTimeFormat::constructor):
(JSC::IntlDateTimeFormat::boundFormat):
* runtime/IntlDateTimeFormatConstructor.cpp: Added.
(JSC::IntlDateTimeFormatConstructor::create):
(JSC::IntlDateTimeFormatConstructor::createStructure):
(JSC::IntlDateTimeFormatConstructor::IntlDateTimeFormatConstructor):
(JSC::IntlDateTimeFormatConstructor::finishCreation):
(JSC::constructIntlDateTimeFormat): Added DateTimeFormat constructor (12.1.2).
(JSC::callIntlDateTimeFormat): Added DateTimeFormat constructor (12.1.2).
(JSC::IntlDateTimeFormatConstructor::getConstructData):
(JSC::IntlDateTimeFormatConstructor::getCallData):
(JSC::IntlDateTimeFormatConstructor::getOwnPropertySlot):
(JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf): Added placeholder implementation returning [].
(JSC::IntlDateTimeFormatConstructor::visitChildren):
* runtime/IntlDateTimeFormatConstructor.h: Added.
(JSC::IntlDateTimeFormatConstructor::dateTimeFormatStructure):
* runtime/IntlDateTimeFormatPrototype.cpp: Added.
(JSC::IntlDateTimeFormatPrototype::create):
(JSC::IntlDateTimeFormatPrototype::createStructure):
(JSC::IntlDateTimeFormatPrototype::IntlDateTimeFormatPrototype):
(JSC::IntlDateTimeFormatPrototype::finishCreation):
(JSC::IntlDateTimeFormatPrototype::getOwnPropertySlot):
(JSC::IntlDateTimeFormatPrototypeGetterFormat): Added format getter (12.3.3).
(JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions): Added placeholder implementation returning {}.
* runtime/IntlDateTimeFormatPrototype.h: Added.
* runtime/IntlNumberFormat.cpp: Added.
(JSC::IntlNumberFormat::create):
(JSC::IntlNumberFormat::createStructure):
(JSC::IntlNumberFormat::IntlNumberFormat):
(JSC::IntlNumberFormat::finishCreation):
(JSC::IntlNumberFormat::destroy):
(JSC::IntlNumberFormat::visitChildren):
(JSC::IntlNumberFormat::setBoundFormat):
(JSC::IntlNumberFormatFuncFormatNumber): Added placeholder implementation returning Number(value).toString().
* runtime/IntlNumberFormat.h: Added.
(JSC::IntlNumberFormat::constructor):
(JSC::IntlNumberFormat::boundFormat):
* runtime/IntlNumberFormatConstructor.cpp: Added.
(JSC::IntlNumberFormatConstructor::create):
(JSC::IntlNumberFormatConstructor::createStructure):
(JSC::IntlNumberFormatConstructor::IntlNumberFormatConstructor):
(JSC::IntlNumberFormatConstructor::finishCreation):
(JSC::constructIntlNumberFormat): Added NumberFormat constructor (11.1.2).
(JSC::callIntlNumberFormat): Added NumberFormat constructor (11.1.2).
(JSC::IntlNumberFormatConstructor::getConstructData):
(JSC::IntlNumberFormatConstructor::getCallData):
(JSC::IntlNumberFormatConstructor::getOwnPropertySlot):
(JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf): Added placeholder implementation returning [].
(JSC::IntlNumberFormatConstructor::visitChildren):
* runtime/IntlNumberFormatConstructor.h: Added.
(JSC::IntlNumberFormatConstructor::numberFormatStructure):
* runtime/IntlNumberFormatPrototype.cpp: Added.
(JSC::IntlNumberFormatPrototype::create):
(JSC::IntlNumberFormatPrototype::createStructure):
(JSC::IntlNumberFormatPrototype::IntlNumberFormatPrototype):
(JSC::IntlNumberFormatPrototype::finishCreation):
(JSC::IntlNumberFormatPrototype::getOwnPropertySlot):
(JSC::IntlNumberFormatPrototypeGetterFormat): Added format getter (11.3.3).
(JSC::IntlNumberFormatPrototypeFuncResolvedOptions): Added placeholder implementation returning {}.
* runtime/IntlNumberFormatPrototype.h: Added.
* runtime/IntlObject.cpp:
(JSC::IntlObject::create):
(JSC::IntlObject::finishCreation): Added Collator, NumberFormat, and DateTimeFormat properties (8.1).
(JSC::IntlObject::visitChildren):
* runtime/IntlObject.h:
(JSC::IntlObject::collatorConstructor):
(JSC::IntlObject::collatorPrototype):
(JSC::IntlObject::collatorStructure):
(JSC::IntlObject::numberFormatConstructor):
(JSC::IntlObject::numberFormatPrototype):
(JSC::IntlObject::numberFormatStructure):
(JSC::IntlObject::dateTimeFormatConstructor):
(JSC::IntlObject::dateTimeFormatPrototype):
(JSC::IntlObject::dateTimeFormatStructure):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
2015-07-29 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r187550.
https://bugs.webkit.org/show_bug.cgi?id=147420
Broke Windows build (again) (Requested by smfr on #webkit).
Reverted changeset:
"Implement WebAssembly module parser"
https://bugs.webkit.org/show_bug.cgi?id=147293
http://trac.webkit.org/changeset/187550
2015-07-29 Basile Clement <basile_clement@apple.com>
Remove native call inlining
https://bugs.webkit.org/show_bug.cgi?id=147417
Rubber Stamped by Filip Pizlo.
* CMakeLists.txt:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Deleted.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleCall): Deleted.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize): Deleted.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC): Deleted.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode): Deleted.
* dfg/DFGNode.h:
(JSC::DFG::Node::hasHeapPrediction): Deleted.
(JSC::DFG::Node::hasCellOperand): Deleted.
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate): Deleted.
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute): Deleted.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile): Deleted.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile): Deleted.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile): Deleted.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::lower): Deleted.
(JSC::FTL::DFG::LowerDFGToLLVM::compileNode): Deleted.
(JSC::FTL::DFG::LowerDFGToLLVM::compileNativeCallOrConstruct): Deleted.
(JSC::FTL::DFG::LowerDFGToLLVM::getFunctionBySymbol): Deleted.
(JSC::FTL::DFG::LowerDFGToLLVM::getModuleByPathForSymbol): Deleted.
(JSC::FTL::DFG::LowerDFGToLLVM::didOverflowStack): Deleted.
* ftl/FTLState.cpp:
(JSC::FTL::State::State): Deleted.
* ftl/FTLState.h:
* runtime/BundlePath.cpp: Removed.
(JSC::bundlePath): Deleted.
* runtime/JSDataViewPrototype.cpp:
(JSC::getData):
(JSC::setData):
* runtime/Options.h:
2015-07-29 Basile Clement <basile_clement@apple.com>
Unreviewed, skipping a test that is too complex for its own good
https://bugs.webkit.org/show_bug.cgi?id=147167
* tests/stress/math-pow-coherency.js:
2015-07-29 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement WebAssembly module parser
https://bugs.webkit.org/show_bug.cgi?id=147293
Reviewed by Mark Lam.
Reupload the patch, since r187539 should fix the "Cannot open include file:
'JSWASMModule.h'" issue in the Windows build.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* jsc.cpp:
(GlobalObject::finishCreation):
(functionLoadWebAssembly):
* parser/SourceProvider.h:
(JSC::WebAssemblySourceProvider::create):
(JSC::WebAssemblySourceProvider::data):
(JSC::WebAssemblySourceProvider::WebAssemblySourceProvider):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::wasmModuleStructure):
* wasm/WASMMagicNumber.h: Added.
* wasm/WASMModuleParser.cpp: Added.
(JSC::WASMModuleParser::WASMModuleParser):
(JSC::WASMModuleParser::parse):
(JSC::WASMModuleParser::parseModule):
(JSC::parseWebAssembly):
* wasm/WASMModuleParser.h: Added.
* wasm/WASMReader.cpp: Added.
(JSC::WASMReader::readUnsignedInt32):
(JSC::WASMReader::readFloat):
(JSC::WASMReader::readDouble):
* wasm/WASMReader.h: Added.
(JSC::WASMReader::WASMReader):
2015-07-29 Basile Clement <basile_clement@apple.com>
Unreviewed, lower the number of test iterations to prevent timing out on Debug builds
https://bugs.webkit.org/show_bug.cgi?id=147167
* tests/stress/math-pow-coherency.js:
2015-07-28 Sukolsak Sakshuwong <sukolsak@gmail.com>
Add the "wasm" directory to Visual Studio project files
https://bugs.webkit.org/show_bug.cgi?id=147400
Reviewed by Simon Fraser.
This patch should fix the "Cannot open include file: 'JSWASMModule.h'" issue
in the Windows build.
* JavaScriptCore.vcxproj/JavaScriptCoreCommon.props:
* JavaScriptCore.vcxproj/copy-files.cmd:
2015-07-28 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r187531.
https://bugs.webkit.org/show_bug.cgi?id=147397
Broke Windows bild (Requested by smfr on #webkit).
Reverted changeset:
"Implement WebAssembly module parser"
https://bugs.webkit.org/show_bug.cgi?id=147293
http://trac.webkit.org/changeset/187531
2015-07-28 Benjamin Poulain <bpoulain@apple.com>
Speed up the Stringifier::toJSON() fast case
https://bugs.webkit.org/show_bug.cgi?id=147383
Reviewed by Andreas Kling.
* runtime/JSONObject.cpp:
(JSC::Stringifier::toJSON):
(JSC::Stringifier::toJSONImpl):
2015-07-28 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement WebAssembly module parser
https://bugs.webkit.org/show_bug.cgi?id=147293
Reviewed by Geoffrey Garen.
Implement WebAssembly module parser for WebAssembly files produced by pack-asmjs
<https://github.com/WebAssembly/polyfill-prototype-1>. This patch only checks
the magic number at the beginning of the files. Parsing of the rest will be
implemented in a subsequent patch.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* jsc.cpp:
(GlobalObject::finishCreation):
(functionLoadWebAssembly):
* parser/SourceProvider.h:
(JSC::WebAssemblySourceProvider::create):
(JSC::WebAssemblySourceProvider::data):
(JSC::WebAssemblySourceProvider::WebAssemblySourceProvider):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::wasmModuleStructure):
* wasm/WASMMagicNumber.h: Added.
* wasm/WASMModuleParser.cpp: Added.
(JSC::WASMModuleParser::WASMModuleParser):
(JSC::WASMModuleParser::parse):
(JSC::WASMModuleParser::parseModule):
(JSC::parseWebAssembly):
* wasm/WASMModuleParser.h: Added.
* wasm/WASMReader.cpp: Added.
(JSC::WASMReader::readUnsignedInt32):
(JSC::WASMReader::readFloat):
(JSC::WASMReader::readDouble):
* wasm/WASMReader.h: Added.
(JSC::WASMReader::WASMReader):
2015-07-28 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Add ENABLE_ES6_MODULES compile time flag with the default value "false"
https://bugs.webkit.org/show_bug.cgi?id=147350
Reviewed by Sam Weinig.
* Configurations/FeatureDefines.xcconfig:
2015-07-28 Saam barati <saambarati1@gmail.com>
Make the type profiler work with lexical scoping and add tests
https://bugs.webkit.org/show_bug.cgi?id=145438
Reviewed by Geoffrey Garen.
op_profile_type now knows how to resolve variables allocated within
the local scope stack. This means it knows how to resolve "let"
and "const" variables. Also, some refactoring was done inside
the BytecodeGenerator to make writing code to support the type
profiler much simpler and clearer.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::symbolTable): Deleted.
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::addExceptionHandler):
(JSC::UnlinkedCodeBlock::exceptionHandler):
(JSC::UnlinkedCodeBlock::vm):
(JSC::UnlinkedCodeBlock::addArrayProfile):
(JSC::UnlinkedCodeBlock::setSymbolTableConstantIndex): Deleted.
(JSC::UnlinkedCodeBlock::symbolTableConstantIndex): Deleted.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitMove):
(JSC::BytecodeGenerator::emitTypeProfilerExpressionInfo):
(JSC::BytecodeGenerator::emitProfileType):
(JSC::BytecodeGenerator::emitProfileControlFlow):
(JSC::BytecodeGenerator::pushLexicalScopeInternal):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::emitNodeForLeftHandSide):
* bytecompiler/NodesCodegen.cpp:
(JSC::ThisNode::emitBytecode):
(JSC::ResolveNode::emitBytecode):
(JSC::BracketAccessorNode::emitBytecode):
(JSC::DotAccessorNode::emitBytecode):
(JSC::FunctionCallValueNode::emitBytecode):
(JSC::FunctionCallResolveNode::emitBytecode):
(JSC::FunctionCallBracketNode::emitBytecode):
(JSC::FunctionCallDotNode::emitBytecode):
(JSC::CallFunctionCallDotNode::emitBytecode):
(JSC::ApplyFunctionCallDotNode::emitBytecode):
(JSC::PostfixNode::emitResolve):
(JSC::PostfixNode::emitBracket):
(JSC::PostfixNode::emitDot):
(JSC::PrefixNode::emitResolve):
(JSC::PrefixNode::emitBracket):
(JSC::PrefixNode::emitDot):
(JSC::ReadModifyResolveNode::emitBytecode):
(JSC::AssignResolveNode::emitBytecode):
(JSC::AssignDotNode::emitBytecode):
(JSC::ReadModifyDotNode::emitBytecode):
(JSC::AssignBracketNode::emitBytecode):
(JSC::ReadModifyBracketNode::emitBytecode):
(JSC::EmptyVarExpression::emitBytecode):
(JSC::EmptyLetExpression::emitBytecode):
(JSC::ForInNode::emitLoopHeader):
(JSC::ForOfNode::emitBytecode):
(JSC::ReturnNode::emitBytecode):
(JSC::FunctionNode::emitBytecode):
(JSC::BindingNode::bindValue):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_profile_type):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_profile_type):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* tests/typeProfiler/es6-block-scoping.js: Added.
(noop):
(arr):
(wrapper.changeFoo):
(wrapper.scoping):
(wrapper.scoping2):
(wrapper):
* tests/typeProfiler/es6-classes.js: Added.
(noop):
(wrapper.Animal):
(wrapper.Animal.prototype.methodA):
(wrapper.Dog):
(wrapper.Dog.prototype.methodB):
(wrapper):
2015-07-28 Saam barati <saambarati1@gmail.com>
Implement catch scope using lexical scoping constructs introduced with "let" scoping patch
https://bugs.webkit.org/show_bug.cgi?id=146979
Reviewed by Geoffrey Garen.
Now that BytecodeGenerator has a notion of local scope depth,
we can easily implement a catch scope that doesn't claim that
all variables are dynamically scoped. This means that functions
that use try/catch can have local variable resolution. This also
means that all functions that use try/catch don't have all
their variables marked as being captured.
Catch scopes now behave like a "let" scope (sans the TDZ logic) with a
single variable. Catch scopes are now just JSLexicalEnvironments and the
symbol table backing the catch scope knows that it corresponds to a catch scope.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecode/EvalCodeCache.h:
(JSC::EvalCodeCache::isCacheable):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
(JSC::BytecodeGenerator::emitLoadGlobalObject):
(JSC::BytecodeGenerator::pushLexicalScope):
(JSC::BytecodeGenerator::pushLexicalScopeInternal):
(JSC::BytecodeGenerator::popLexicalScope):
(JSC::BytecodeGenerator::popLexicalScopeInternal):
(JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
(JSC::BytecodeGenerator::variable):
(JSC::BytecodeGenerator::resolveType):
(JSC::BytecodeGenerator::emitResolveScope):
(JSC::BytecodeGenerator::emitPopScope):
(JSC::BytecodeGenerator::emitPopWithScope):
(JSC::BytecodeGenerator::emitDebugHook):
(JSC::BytecodeGenerator::popScopedControlFlowContext):
(JSC::BytecodeGenerator::emitPushCatchScope):
(JSC::BytecodeGenerator::emitPopCatchScope):
(JSC::BytecodeGenerator::beginSwitch):
(JSC::BytecodeGenerator::emitPopWithOrCatchScope): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::lastOpcodeID):
* bytecompiler/NodesCodegen.cpp:
(JSC::AssignResolveNode::emitBytecode):
(JSC::WithNode::emitBytecode):
(JSC::TryNode::emitBytecode):
* debugger/DebuggerScope.cpp:
(JSC::DebuggerScope::isCatchScope):
(JSC::DebuggerScope::isFunctionNameScope):
(JSC::DebuggerScope::isFunctionOrEvalScope):
(JSC::DebuggerScope::caughtValue):
* debugger/DebuggerScope.h:
* inspector/ScriptDebugServer.cpp:
(Inspector::ScriptDebugServer::exceptionOrCaughtValue):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_push_name_scope):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_push_name_scope):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createContinueStatement):
(JSC::ASTBuilder::createTryStatement):
* parser/NodeConstructors.h:
(JSC::ThrowNode::ThrowNode):
(JSC::TryNode::TryNode):
(JSC::FunctionParameters::FunctionParameters):
* parser/Nodes.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseTryStatement):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createBreakStatement):
(JSC::SyntaxChecker::createContinueStatement):
(JSC::SyntaxChecker::createTryStatement):
(JSC::SyntaxChecker::createSwitchStatement):
(JSC::SyntaxChecker::createWhileStatement):
(JSC::SyntaxChecker::createWithStatement):
* runtime/JSCatchScope.cpp:
* runtime/JSCatchScope.h:
(JSC::JSCatchScope::JSCatchScope): Deleted.
(JSC::JSCatchScope::create): Deleted.
(JSC::JSCatchScope::createStructure): Deleted.
* runtime/JSFunctionNameScope.h:
(JSC::JSFunctionNameScope::JSFunctionNameScope):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::withScopeStructure):
(JSC::JSGlobalObject::strictEvalActivationStructure):
(JSC::JSGlobalObject::activationStructure):
(JSC::JSGlobalObject::functionNameScopeStructure):
(JSC::JSGlobalObject::directArgumentsStructure):
(JSC::JSGlobalObject::scopedArgumentsStructure):
(JSC::JSGlobalObject::catchScopeStructure): Deleted.
* runtime/JSNameScope.cpp:
(JSC::JSNameScope::create):
(JSC::JSNameScope::toThis):
* runtime/JSNameScope.h:
* runtime/JSObject.cpp:
(JSC::JSObject::toThis):
(JSC::JSObject::isFunctionNameScopeObject):
(JSC::JSObject::isCatchScopeObject): Deleted.
* runtime/JSObject.h:
* runtime/JSScope.cpp:
(JSC::JSScope::collectVariablesUnderTDZ):
(JSC::JSScope::isLexicalScope):
(JSC::JSScope::isCatchScope):
(JSC::resolveModeName):
* runtime/JSScope.h:
* runtime/SymbolTable.cpp:
(JSC::SymbolTable::SymbolTable):
(JSC::SymbolTable::cloneScopePart):
* runtime/SymbolTable.h:
* tests/stress/const-semantics.js:
(.):
2015-07-28 Filip Pizlo <fpizlo@apple.com>
DFG::ArgumentsEliminationPhase has a redundant check for inserting CheckInBounds when converting GetByVal to GetStack in the inline non-varargs case
https://bugs.webkit.org/show_bug.cgi?id=147373
Reviewed by Mark Lam.
The code was doing a check for "index >= inlineCallFrame->arguments.size() - 1" in code where
safeToGetStack is true and we aren't in varargs context, but in a non-varargs context,
safeToGetStack can only be true if "index < inlineCallFrame->arguments.size() - 1".
When converting a GetByVal to GetStack, there are three possibilities:
1) Impossible to convert. This can happen if the GetByVal is out-of-bounds of the things we
know to have stored to the stack. For example, if we inline a function that does
"arguments[42]" at a call that passes no arguments.
2) Possible to convert, but we cannot prove statically that the GetByVal was in bounds. This
can happen for "arguments[42]" with no inline call frame (since we don't know statically
how many arguments we will be passed) or in a varargs call frame.
3) Possible to convert, and we know statically that the GetByVal is in bounds. This can
happen for "arguments[42]" if we have an inline call frame, and it's not a varargs call
frame, and we know that the caller passed 42 or more arguments.
The way the phase handles this is it first determines that we're not in case (1). This is
called safeToGetStack. safeToGetStack is true if we have case (2) or (3). For inline call
frames that have no varargs, this means that safeToGetStack is true exactly when the GetByVal
is in-bounds (i.e. case (3)).
But the phase was again doing a check for whether the index is in-bounds for non-varargs
inline call frames even when safeToGetStack was true. That check is redundant and should be
eliminated, since it makes the code confusing.
* dfg/DFGArgumentsEliminationPhase.cpp:
2015-07-28 Filip Pizlo <fpizlo@apple.com>
DFG::PutStackSinkingPhase should be more aggressive about its "no GetStack until put" rule
https://bugs.webkit.org/show_bug.cgi?id=147371
Reviewed by Mark Lam.
Two fixes:
- Make ConflictingFlush really mean that you can't load from the stack slot. This means not
using ConflictingFlush for arguments.
- Assert that a GetStack never sees ConflictingFlush.
* dfg/DFGPutStackSinkingPhase.cpp:
2015-07-28 Basile Clement <basile_clement@apple.com>
Misleading error message: "At least one digit must occur after a decimal point"
https://bugs.webkit.org/show_bug.cgi?id=146238
Reviewed by Geoffrey Garen.
Interestingly, we had a comment explaining what this error message was
about that is much clearer than the error message itself. This patch
simply replaces the error message with the explanation from the
comment.
* parser/Lexer.cpp:
(JSC::Lexer<T>::lex):
2015-07-28 Basile Clement <basile_clement@apple.com>
Simplify call linking
https://bugs.webkit.org/show_bug.cgi?id=147363
Reviewed by Filip Pizlo.
Previously, we were passing both the CallLinkInfo and a
(CodeSpecializationKind, RegisterPreservationMode) pair to the
different call linking slow paths. However, the CallLinkInfo already
has all of that information, and we don't gain anything by having them
in additional static parameters - except possibly a very small
performance gain in presence of inlining. However since those are
already slow paths, this performance loss (if it exists) will not be
visible in practice.
This patch removes the various specialized thunks and JIT operations
for regular and polymorphic call linking with a single thunk and
operation for each case. Moreover, it removes the four specialized
virtual call thunks and operations with one virtual call thunk for each
call link info, allowing for better branch prediction by the CPU and
fixing a pre-existing FIXME.
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::unlink):
(JSC::CallLinkInfo::dummy): Deleted.
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::CallLinkInfo):
(JSC::CallLinkInfo::registerPreservationMode):
(JSC::CallLinkInfo::setUpCallFromFTL):
(JSC::CallLinkInfo::setSlowStub):
(JSC::CallLinkInfo::clearSlowStub):
(JSC::CallLinkInfo::slowStub):
* dfg/DFGDriver.cpp:
(JSC::DFG::compileImpl):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
* ftl/FTLJSCallBase.cpp:
(JSC::FTL::JSCallBase::link):
* jit/JITCall.cpp:
(JSC::JIT::compileCallEvalSlowCase):
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
* jit/JITCall32_64.cpp:
(JSC::JIT::compileCallEvalSlowCase):
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
(JSC::operationLinkFor): Deleted.
(JSC::operationVirtualFor): Deleted.
(JSC::operationLinkPolymorphicCallFor): Deleted.
* jit/Repatch.cpp:
(JSC::generateByIdStub):
(JSC::linkSlowFor):
(JSC::linkFor):
(JSC::revertCall):
(JSC::unlinkFor):
(JSC::linkVirtualFor):
(JSC::linkPolymorphicCall):
* jit/Repatch.h:
* jit/ThunkGenerators.cpp:
(JSC::linkCallThunkGenerator):
(JSC::linkPolymorphicCallThunkGenerator):
(JSC::virtualThunkFor):
(JSC::linkForThunkGenerator): Deleted.
(JSC::linkConstructThunkGenerator): Deleted.
(JSC::linkCallThatPreservesRegsThunkGenerator): Deleted.
(JSC::linkConstructThatPreservesRegsThunkGenerator): Deleted.
(JSC::linkPolymorphicCallForThunkGenerator): Deleted.
(JSC::linkPolymorphicCallThatPreservesRegsThunkGenerator): Deleted.
(JSC::virtualForThunkGenerator): Deleted.
(JSC::virtualCallThunkGenerator): Deleted.
(JSC::virtualConstructThunkGenerator): Deleted.
(JSC::virtualCallThatPreservesRegsThunkGenerator): Deleted.
(JSC::virtualConstructThatPreservesRegsThunkGenerator): Deleted.
* jit/ThunkGenerators.h:
(JSC::linkThunkGeneratorFor): Deleted.
(JSC::linkPolymorphicCallThunkGeneratorFor): Deleted.
(JSC::virtualThunkGeneratorFor): Deleted.
2015-07-28 Basile Clement <basile_clement@apple.com>
stress/math-pow-with-constants.js fails in cloop
https://bugs.webkit.org/show_bug.cgi?id=147167
Reviewed by Geoffrey Garen.
Baseline JIT, DFG and FTL are using a fast exponentiation fast path
when computing Math.pow() with an integer exponent that is not taken in
the LLInt (or the DFG abstract interpreter). This leads to the result
of pow changing depending on the compilation tier or the fact that
constant propagation kicks in, which is undesirable.
This patch adds the fast path to the slow operationMathPow in order to
maintain an illusion of consistency.
* runtime/MathCommon.cpp:
(JSC::operationMathPow):
* tests/stress/math-pow-coherency.js: Added.
(pow42):
(build42AsDouble.opaqueAdd):
(build42AsDouble):
(powDouble42):
(clobber):
(pow42NoConstantFolding):
(powDouble42NoConstantFolding):
2015-07-28 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Show Pseudo Elements in DOM Tree
https://bugs.webkit.org/show_bug.cgi?id=139612
Reviewed by Timothy Hatcher.
* inspector/protocol/DOM.json:
Add new properties to DOMNode if it is a pseudo element or if it has
pseudo element children. Add new events for if a pseudo element is
added or removed dynamically to an existing DOMNode.
2015-07-27 Filip Pizlo <fpizlo@apple.com>
Add logging when executable code gets deallocated
https://bugs.webkit.org/show_bug.cgi?id=147355
Reviewed by Mark Lam.
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::~JITCode): Print something when this is freed.
* jit/JITCode.cpp:
(JSC::JITCodeWithCodeRef::~JITCodeWithCodeRef): Print something when this is freed.
2015-07-27 Filip Pizlo <fpizlo@apple.com>
DFG::safeToExecute() cases for GetByOffset/PutByOffset don't handle clobbered structure abstract values correctly
https://bugs.webkit.org/show_bug.cgi?id=147354
Reviewed by Michael Saboff.
If m_structure.isClobbered(), it means that we had a side effect that clobbered
the abstract value but it may recover back to its original value at the next
invalidation point. Since the invalidation point hasn't been reached yet, we need
to conservatively treat the clobbered state as if it was top. At the invalidation
point, the clobbered set will return back to being unclobbered.
In addition to fixing the bug, this introduces isInfinite(), which should be used
in places where it's tempting to just use isTop().
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute): Fix the bug.
* dfg/DFGStructureAbstractValue.cpp:
(JSC::DFG::StructureAbstractValue::contains): Switch to using isInfinite().
(JSC::DFG::StructureAbstractValue::isSubsetOf): Switch to using isInfinite().
(JSC::DFG::StructureAbstractValue::isSupersetOf): Switch to using isInfinite().
(JSC::DFG::StructureAbstractValue::overlaps): Switch to using isInfinite().
* dfg/DFGStructureAbstractValue.h:
(JSC::DFG::StructureAbstractValue::isFinite): New convenience method.
(JSC::DFG::StructureAbstractValue::isInfinite): New convenience method.
(JSC::DFG::StructureAbstractValue::onlyStructure): Switch to using isInfinite().
2015-07-27 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement Reflect.enumerate
https://bugs.webkit.org/show_bug.cgi?id=147347
Reviewed by Sam Weinig.
This patch implements Reflect.enumerate.
It returns the iterator that iterates the enumerable keys of the given object.
It follows the for-in's enumeration order.
To implement it, we write down the same logic to the for-in's enumeration code in C++.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::propertyNameIteratorStructure):
* runtime/JSPropertyNameIterator.cpp: Added.
(JSC::JSPropertyNameIterator::JSPropertyNameIterator):
(JSC::JSPropertyNameIterator::clone):
(JSC::JSPropertyNameIterator::create):
(JSC::JSPropertyNameIterator::finishCreation):
(JSC::JSPropertyNameIterator::visitChildren):
(JSC::JSPropertyNameIterator::next):
(JSC::propertyNameIteratorFuncNext):
* runtime/JSPropertyNameIterator.h: Added.
(JSC::JSPropertyNameIterator::createStructure):
* runtime/ReflectObject.cpp:
(JSC::reflectObjectEnumerate):
* tests/stress/reflect-enumerate.js: Added.
(shouldBe):
(shouldThrow):
2015-07-27 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement Reflect.preventExtensions
https://bugs.webkit.org/show_bug.cgi?id=147331
Reviewed by Sam Weinig.
Implement Reflect.preventExtensions.
This is different from Object.preventExensions.
1. When preventExtensions is called onto the non-object, it raises the TypeError.
2. Reflect.preventExtensions does not raise the TypeError when the preventExtensions operation is failed.
For the (2) case, since there is no Proxy implementation currently, Reflect.preventExtensions always succeed.
* runtime/ReflectObject.cpp:
(JSC::reflectObjectPreventExtensions):
* tests/stress/reflect-prevent-extensions.js: Added.
(shouldBe):
(shouldThrow):
2015-07-27 Alex Christensen <achristensen@webkit.org>
Use Ninja on Windows.
https://bugs.webkit.org/show_bug.cgi?id=147228
Reviewed by Martin Robinson.
* CMakeLists.txt:
Set the working directory when generating LowLevelInterpreterWin.asm to put LowLevelInterpreterWin.asm.sym in the right place.
2015-07-27 Yusuke Suzuki <utatane.tea@gmail.com>
SparseValueMap check is skipped when the butterfly's vectorLength is larger than the access-requested index
https://bugs.webkit.org/show_bug.cgi?id=147265
Reviewed by Geoffrey Garen.
JSObject's vector holds the indexed values and we leverage it to represent stored values and holes.
By checking that the given index is in-bound of the vector's length, we can look up the property fast.
And for the sparse array, we have also the separated SparseValueMap to hold the pairs.
And we need to take care that the length of the vector should not overlap the indices stored in the SparseValueMap.
The vector only holds the pure JS values to avoid additional checking for accessors when looking up the value
from the vector. To achieve this, we also store the accessors (and attributed properties) to SparseValueMap
even the index is less than MIN_SPARSE_ARRAY_INDEX.
As a result, if the length of the vector overlaps the indices of the accessors stored in the SparseValueMap,
we accidentally skip the phase looking up from the SparseValueMap. Instead, we just load from the vector and
if the loaded value is an array hole, we decide the given object does not have the value for the given index.
This patch fixes the problem.
When defining the attributed value that index is smaller than the length of the vector, we throw away the vector
and change the object to DictionaryIndexingMode. Since we can assume that indexed accessors rarely exist in
practice, we expect this does not hurt the performance while keeping the fast property access system without
checking the sparse map.
* runtime/JSObject.cpp:
(JSC::JSObject::putDirectIndexBeyondVectorLength):
* tests/stress/sparse-map-non-overlapping.js: Added.
(shouldBe):
(testing):
(object.get 1000):
* tests/stress/sparse-map-non-skip-getter-overriding.js: Added.
(shouldBe):
(obj.get 1):
(testing):
* tests/stress/sparse-map-non-skip.js: Added.
(shouldBe):
(testing):
(testing2):
(.get for):
2015-07-27 Saam barati <saambarati1@gmail.com>
Reduce execution time for "let" and "const" tests
https://bugs.webkit.org/show_bug.cgi?id=147291
Reviewed by Geoffrey Garen.
We don't need to loop so many times for things that will not make it
into the DFG. Also, we can loop a lot less for almost all the tests
because they're mostly testing the bytecode generator.
* tests/stress/const-and-with-statement.js:
* tests/stress/const-exception-handling.js:
* tests/stress/const-loop-semantics.js:
* tests/stress/const-not-strict-mode.js:
* tests/stress/const-semantics.js:
* tests/stress/const-tdz.js:
* tests/stress/lexical-let-and-with-statement.js:
* tests/stress/lexical-let-exception-handling.js:
(assert):
* tests/stress/lexical-let-loop-semantics.js:
(assert):
(shouldThrowTDZ):
(.):
* tests/stress/lexical-let-not-strict-mode.js:
* tests/stress/lexical-let-semantics.js:
(.):
* tests/stress/lexical-let-tdz.js:
(shouldThrowTDZ):
(.):
2015-07-26 Yusuke Suzuki <utatane.tea@gmail.com>
Rename PropertyNameMode::Both to PropertyNameMode::StringsAndSymbols
https://bugs.webkit.org/show_bug.cgi?id=147311
Reviewed by Sam Weinig.
To make the meaning clear in the user side (PropertyNameArray array(exec, PropertyNameMode::StringsAndSymbols)),
this patch renames PropertyNameMode::Both to PropertyNameMode::StringsAndSymbols.
* bytecode/ObjectAllocationProfile.h:
(JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
* runtime/EnumerationMode.h:
* runtime/ObjectConstructor.cpp:
(JSC::ownEnumerablePropertyKeys):
(JSC::defineProperties):
(JSC::objectConstructorSeal):
(JSC::objectConstructorFreeze):
(JSC::objectConstructorIsSealed):
(JSC::objectConstructorIsFrozen):
(JSC::ownPropertyKeys):
* runtime/ReflectObject.cpp:
(JSC::reflectObjectOwnKeys):
2015-07-27 Saam barati <saambarati1@gmail.com>
Added a comment explaining that all "addVar()"s should happen before
emitting bytecode for a function's default parameter expressions
Rubber Stamped by Mark Lam.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
2015-07-26 Sam Weinig <sam@webkit.org>
Add missing builtin files to the JavaScriptCore Xcode project
https://bugs.webkit.org/show_bug.cgi?id=147312
Reviewed by Darin Adler.
* JavaScriptCore.xcodeproj/project.pbxproj:
Add missing files.
2015-07-26 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement Reflect.isExtensible
https://bugs.webkit.org/show_bug.cgi?id=147308
Reviewed by Sam Weinig.
This patch implements Reflect.isExtensible.
It is similar to Object.isExtensible.
The difference is that it raises an error if the first argument is not an object.
* runtime/ReflectObject.cpp:
(JSC::reflectObjectIsExtensible):
* tests/stress/reflect-is-extensible.js: Added.
(shouldBe):
(shouldThrow):
2015-07-26 Yusuke Suzuki <utatane.tea@gmail.com>
Unreviewed, fix the debug build due to touching the non-declared variable in ASSERT
https://bugs.webkit.org/show_bug.cgi?id=147307
* runtime/ObjectConstructor.cpp:
(JSC::ownPropertyKeys):
2015-07-25 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement Reflect.ownKeys
https://bugs.webkit.org/show_bug.cgi?id=147307
Reviewed by Sam Weinig.
This patch implements Reflect.ownKeys.
In this patch, we refactor the existing code to list up own keys in the object.
Such code is used by Object.getOwnPropertyNames, Object.getOwnPropertyKeys, Object.keys and @ownEnumerableKeys.
We factor out the listing up own keys as ownPropertyKeys function and also use it in Reflect.ownKeys.
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorGetOwnPropertyNames):
(JSC::objectConstructorGetOwnPropertySymbols):
(JSC::objectConstructorKeys):
(JSC::ownEnumerablePropertyKeys):
(JSC::ownPropertyKeys):
* runtime/ObjectConstructor.h:
* runtime/ReflectObject.cpp:
(JSC::reflectObjectOwnKeys):
* tests/stress/reflect-own-keys.js: Added.
(shouldBe):
(shouldThrow):
(shouldBeArray):
2015-07-26 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement Reflect.apply
https://bugs.webkit.org/show_bug.cgi?id=147306
Reviewed by Sam Weinig.
Implement Reflect.apply.
The large part of this can be implemented by the @apply builtin annotation.
The only thing which is different from the Funciton.prototype.apply is the third parameter,
"argumentsList" is needed to be an object.
* builtins/ReflectObject.js:
(apply):
(deleteProperty):
* runtime/ReflectObject.cpp:
* tests/stress/reflect-apply.js: Added.
(shouldBe):
(shouldThrow):
(get shouldThrow):
(.get shouldThrow):
(get var.array.get length):
(get var.array.get 0):
(.get var):
* tests/stress/reflect-delete-property.js:
2015-07-25 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Add Reflect namespace and add Reflect.deleteProperty
https://bugs.webkit.org/show_bug.cgi?id=147287
Reviewed by Sam Weinig.
This patch just creates the namespace for ES6 Reflect APIs.
And add template files to implement the actual code.
Not to keep the JS generated properties C array empty,
we added one small method, Reflect.deleteProperty in this patch.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/ReflectObject.js: Added.
(deleteProperty):
* runtime/CommonIdentifiers.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/ReflectObject.cpp: Added.
(JSC::ReflectObject::ReflectObject):
(JSC::ReflectObject::finishCreation):
(JSC::ReflectObject::getOwnPropertySlot):
* runtime/ReflectObject.h: Added.
(JSC::ReflectObject::create):
(JSC::ReflectObject::createStructure):
* tests/stress/reflect-delete-property.js: Added.
(shouldBe):
(shouldThrow):
2015-07-24 Yusuke Suzuki <utatane.tea@gmail.com>
Avoid 2 times name iteration in Object.assign
https://bugs.webkit.org/show_bug.cgi?id=147268
Reviewed by Geoffrey Garen.
Object.assign calls Object.getOwnPropertyNames & Object.getOwnPropertySymbols to collect all the names.
But exposing the private API that collects both at the same time makes the API efficient when the given Object has so many non-indexed properties.
Since Object.assign is so generic API (some form of utility API), the form of the given Object is not expected.
So the taken object may have so many non-indexed properties.
In this patch, we introduce `ownEnumerablePropertyKeys` private function.
It is minor changed version of `[[OwnPropertyKeys]]` in the ES6 spec;
It only includes enumerable properties.
By filtering out the non-enumerable properties in the exposed private function,
we avoid calling @objectGetOwnPropertyDescriptor for each property at the same time.
* builtins/ObjectConstructor.js:
(assign):
* runtime/CommonIdentifiers.h:
* runtime/EnumerationMode.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/ObjectConstructor.cpp:
(JSC::ownEnumerablePropertyKeys):
* runtime/ObjectConstructor.h:
* tests/stress/object-assign-enumerable.js: Added.
(shouldBe):
* tests/stress/object-assign-order.js: Added.
(shouldBe):
2015-07-24 Yusuke Suzuki <utatane.tea@gmail.com>
Remove runtime flags for symbols
https://bugs.webkit.org/show_bug.cgi?id=147246
Reviewed by Alex Christensen.
* runtime/ArrayPrototype.cpp:
(JSC::ArrayPrototype::finishCreation):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init): Deleted.
* runtime/JSGlobalObject.h:
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructor::finishCreation):
* runtime/RuntimeFlags.h:
2015-07-24 Yusuke Suzuki <utatane.tea@gmail.com>
Object.getOwnPropertySymbols on large list takes very long
https://bugs.webkit.org/show_bug.cgi?id=146137
Reviewed by Mark Lam.
Before this patch, Object.getOwnPropertySymbols collects all the names including strings.
And after it's done, filter the names to only retrieve the symbols.
But it's so time consuming if the given object is a large non-holed array since it has
many indexed properties and all the indexes have to be converted to uniqued_strings and
added to the collection of property names (though they may not be of the requested type
and will be filtered out later)
This patch introduces PropertyNameMode.
We leverage this mode in 2 places.
1. PropertyNameArray side
It is set in PropertyNameArray and it filters the incoming added identifiers based on the mode.
It ensures that PropertyNameArray doesn't become so large in the pathological case.
And it ensures that non-expected typed keys by the filter (Symbols or Strings) are never added
to the property name array collections.
However it does not solve the whole problem because the huge array still incurs the many
"indexed property to uniqued string" conversion and the large iteration before adding the keys
to the property name array.
2. getOwnPropertyNames side
So we can use the PropertyNameMode in the caller side (getOwnPropertyNames) as a **hint**.
When the large iteration may occur, the caller side can use the PropertyNameMode as a hint to
avoid the iteration.
But we cannot exclusively rely on these caller side checks because it would require that we
exhaustively add the checks to all custom implementations of getOwnPropertyNames as well.
This process requires manual inspection of many pieces of code, and is error prone. Instead,
we only apply the caller side check in a few strategic places where it is known to yield
performance benefits; and we rely on the filter in PropertyNameArray::add() to reject the wrong
types of properties for all other calls to PropertyNameArray::add().
In this patch, there's a concept in use that is not clear just from reading the code, and hence
should be documented here. When selecting the PropertyNameMode for the PropertyNameArray to be
instantiated, we apply the following logic:
1. Only JavaScriptCore code is aware of ES6 Symbols.
We can assume that pre-existing external code that interfaces JSC are only looking for string named properties. This includes:
a. WebCore bindings
b. Serializer bindings
c. NPAPI bindings
d. Objective C bindings
2. In JSC, code that compute object storage space needs to iterate both Symbol and String named properties. Hence, use PropertyNameMode::Both.
3. In JSC, ES6 APIs that work with Symbols should use PropertyNameMode::Symbols.
4. In JSC, ES6 APIs that work with String named properties should use PropertyNameMode::Strings.
* API/JSObjectRef.cpp:
(JSObjectCopyPropertyNames):
* bindings/ScriptValue.cpp:
(Deprecated::jsToInspectorValue):
* bytecode/ObjectAllocationProfile.h:
(JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
* runtime/EnumerationMode.h:
(JSC::EnumerationMode::EnumerationMode):
(JSC::EnumerationMode::includeSymbolProperties): Deleted.
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments<Type>::getOwnPropertyNames):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertyNames):
* runtime/JSLexicalEnvironment.cpp:
(JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames):
* runtime/JSONObject.cpp:
(JSC::Stringifier::Stringifier):
(JSC::Stringifier::Holder::appendNextProperty):
(JSC::Walker::walk):
* runtime/JSObject.cpp:
(JSC::JSObject::getOwnPropertyNames):
* runtime/JSPropertyNameEnumerator.cpp:
(JSC::JSPropertyNameEnumerator::create):
* runtime/JSPropertyNameEnumerator.h:
(JSC::propertyNameEnumerator):
* runtime/JSSymbolTableObject.cpp:
(JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorGetOwnPropertyNames):
(JSC::objectConstructorGetOwnPropertySymbols):
(JSC::objectConstructorKeys):
(JSC::defineProperties):
(JSC::objectConstructorSeal):
(JSC::objectConstructorFreeze):
(JSC::objectConstructorIsSealed):
(JSC::objectConstructorIsFrozen):
* runtime/PropertyNameArray.h:
(JSC::PropertyNameArray::PropertyNameArray):
(JSC::PropertyNameArray::mode):
(JSC::PropertyNameArray::addKnownUnique):
(JSC::PropertyNameArray::add):
(JSC::PropertyNameArray::isUidMatchedToTypeMode):
(JSC::PropertyNameArray::includeSymbolProperties):
(JSC::PropertyNameArray::includeStringProperties):
* runtime/StringObject.cpp:
(JSC::StringObject::getOwnPropertyNames):
* runtime/Structure.cpp:
(JSC::Structure::getPropertyNamesFromStructure):
2015-07-24 Saam barati <saambarati1@gmail.com>
[ES6] Add support for default parameters
https://bugs.webkit.org/show_bug.cgi?id=38409
Reviewed by Filip Pizlo.
This patch implements ES6 default parameters according to the ES6
specification. This patch builds off the components introduced with
"let" scoping and parsing function parameters in the same parser
arena as the function itself. "let" scoping allows functions with default
parameter values to place their parameters under the TDZ. Parsing function
parameters in the same parser arena allows the FunctionParameters AST node
refer to ExpressionNodes.
The most subtle part of this patch is how we allocate lexical environments
when functions have default parameter values. If a function has default
parameter values then there must be a separate lexical environment for
its parameters. Then, the function's "var" lexical environment must have
the parameter lexical environment as its parent. The BytecodeGenerator
takes great care to not allocate the "var" lexical environment before its
really needed.
The "arguments" object for a function with default parameters will never be
a mapped arugments object. It will always be a cloned arugments object.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::~BytecodeGenerator):
(JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
(JSC::BytecodeGenerator::initializeNextParameter):
(JSC::BytecodeGenerator::initializeVarLexicalEnvironment):
(JSC::BytecodeGenerator::visibleNameForParameter):
(JSC::BytecodeGenerator::emitLoadGlobalObject):
(JSC::BytecodeGenerator::pushLexicalScopeInternal):
(JSC::BytecodeGenerator::pushLexicalScope):
(JSC::BytecodeGenerator::popLexicalScope):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::lastOpcodeID):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionNode::emitBytecode):
* jit/JITOperations.cpp:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createElementList):
(JSC::ASTBuilder::createFormalParameterList):
(JSC::ASTBuilder::appendParameter):
(JSC::ASTBuilder::createClause):
(JSC::ASTBuilder::createClauseList):
* parser/Nodes.h:
(JSC::FunctionParameters::size):
(JSC::FunctionParameters::at):
(JSC::FunctionParameters::hasDefaultParameterValues):
(JSC::FunctionParameters::append):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseVariableDeclarationList):
(JSC::Parser<LexerType>::createBindingPattern):
(JSC::Parser<LexerType>::tryParseDestructuringPatternExpression):
(JSC::Parser<LexerType>::parseDestructuringPattern):
(JSC::Parser<LexerType>::parseFormalParameters):
(JSC::Parser<LexerType>::parseFunctionParameters):
* parser/Parser.h:
(JSC::Scope::declareParameter):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createElementList):
(JSC::SyntaxChecker::createFormalParameterList):
(JSC::SyntaxChecker::appendParameter):
(JSC::SyntaxChecker::createClause):
(JSC::SyntaxChecker::createClauseList):
* tests/stress/es6-default-parameters.js: Added.
(assert):
(shouldThrow):
(shouldThrowSyntaxError):
(shouldThrowTDZ):
(basic):
(basicFunctionCaptureInDefault.basicFunctionCaptureInDefault.basicCaptured):
(basicCaptured.basicCaptured.tricky):
(strict):
(playground):
(scoping):
(augmentsArguments1):
(augmentsArguments2):
(augmentsArguments3):
(augmentsArguments4):
(augmentsArguments5):
2015-07-24 Xabier Rodriguez Calvar <calvaris@igalia.com>
Remove JS Promise constructor unused piece of code
https://bugs.webkit.org/show_bug.cgi?id=147262
Reviewed by Geoffrey Garen.
* runtime/JSPromiseConstructor.cpp:
(JSC::constructPromise): Deleted.
* runtime/JSPromiseConstructor.h: Removed JSC::constructPromise.
2015-07-24 Mark Lam <mark.lam@apple.com>
Add WASM files to vcxproj files.
https://bugs.webkit.org/show_bug.cgi?id=147264
Reviewed by Geoffrey Garen.
This is a follow up to http://trac.webkit.org/changeset/187254 where WASM files
were introduced but were not able to be added to the vcxproj files yet.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2015-07-23 Filip Pizlo <fpizlo@apple.com>
DFG::safeToExecute() is wrong for MultiGetByOffset, doesn't consider the structures of the prototypes that get loaded from
https://bugs.webkit.org/show_bug.cgi?id=147250
Reviewed by Geoffrey Garen.
This fixes a nasty - but currently benign - bug in DFG::safeToExecute(). That function
will tell you if hoisting a node to some point is safe in the sense that the node will
not crash the VM if it executes at that point. A node may be unsafe to execute if we
cannot prove that at that point, the memory it is loading is not garbage. This is a
necessarily loose notion - for example it's OK to hoist a load if we haven't proved
that the load makes semantic sense at that point, since anyway the place where the node
did get used will still be guarded by any such semantic checks. But because we may also
hoist uses of the load, we need to make sure that it doesn't produce a garbage value.
Also, we need to ensure that the load won't trap. Hence safeToExecute() returns true
anytime we can be sure that a node will not produce a garbage result (i.e. a malformed
JSValue or object pointer) and will not trap when executed at the point in question.
The bug is that this verification isn't performed for the loads from prototypes inside
MultiGetByOffset. DFG::ByteCodeParser will guard MultiGetByOffset with CheckStructure's
on the prototypes. So, hypothetically, you might end up hoisting a MultiGetByOffset
above those structure checks, which would mean that we might load a value from a memory
location without knowing that the location is valid. It might then return the value
loaded.
This never happens in practice. Those structure checks are more hoistable that the
MultiGetByOffset, since they read a strict subset of the MultiGetByOffset's abstract
heap reads. Also, we hoist in program order. So, those CheckStructure's will always be
hoisted before the MultiGetByOffset gets hoisted.
But we should fix this anyway. DFG::safeToExecute() has a clear definition of what a
"true" return means for IR transformations, and it fails in satisfying that definition
for MultiGetByOffset.
There are various approaches we can use for making this safe. I considered two:
1) Have MultiGetByOffset refer to the prototypes it is loading from in IR, so that we
can check if it's safe to load from them.
2) Turn off MultiGetByOffset hoisting when it will emit loads from prototypes, and the
prototype structure isn't being watched.
I ended up using (2), because it will be the most natural solution once I finish
https://bugs.webkit.org/show_bug.cgi?id=146929. Already now, it's somewhat more natural
than (1) since that requires more extensive IR changes. Also, (2) will give us what we
want in *most* cases: we will usually watch the prototype structure, and we will
usually constant-fold loads from prototypes. Both of these usually-true things would
have to become false for MultiGetByOffset hoisting to be disabled by this change.
This change also adds my attempt at a test, though it's not really a test of this bug.
This bug is currently benign. But, the test does at least trigger the logic to run,
which is better than nothing.
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* tests/stress/multi-get-by-offset-hoist-around-structure-check.js: Added.
(foo):
2015-07-23 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement WebAssembly modules
https://bugs.webkit.org/show_bug.cgi?id=147222
Reviewed by Filip Pizlo.
Make JSWASMModule inherit from JSDestructibleObject so that the destructor is called.
* wasm/JSWASMModule.h:
2015-07-23 Alex Christensen <achristensen@webkit.org>
Remove compile and runtime flags for promises.
https://bugs.webkit.org/show_bug.cgi?id=147244
Reviewed by Yusuke Suzuki.
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::JSCallbackObject):
* API/JSContextRef.cpp:
(JSGlobalContextCreateInGroup):
* Configurations/FeatureDefines.xcconfig:
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::getInternalProperties):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::create):
(JSC::JSGlobalObject::syntaxErrorConstructor):
(JSC::JSGlobalObject::typeErrorConstructor):
(JSC::JSGlobalObject::URIErrorConstructor):
(JSC::JSGlobalObject::promiseConstructor):
(JSC::JSGlobalObject::nullGetterFunction):
(JSC::JSGlobalObject::nullSetterFunction):
(JSC::JSGlobalObject::applyFunction):
(JSC::JSGlobalObject::definePropertyFunction):
(JSC::JSGlobalObject::arrayProtoValuesFunction):
(JSC::JSGlobalObject::initializePromiseFunction):
(JSC::JSGlobalObject::newPromiseDeferredFunction):
(JSC::JSGlobalObject::throwTypeErrorGetterSetter):
(JSC::JSGlobalObject::regExpPrototype):
(JSC::JSGlobalObject::errorPrototype):
(JSC::JSGlobalObject::iteratorPrototype):
(JSC::JSGlobalObject::promisePrototype):
(JSC::JSGlobalObject::debuggerScopeStructure):
(JSC::JSGlobalObject::withScopeStructure):
(JSC::JSGlobalObject::iteratorResultStructure):
(JSC::JSGlobalObject::iteratorResultStructureOffset):
(JSC::JSGlobalObject::regExpMatchesArrayStructure):
(JSC::JSGlobalObject::promiseStructure):
* runtime/JSPromise.cpp:
(JSC::JSPromise::result):
* runtime/JSPromise.h:
* runtime/JSPromiseConstructor.cpp:
(JSC::constructPromise):
* runtime/JSPromiseConstructor.h:
* runtime/JSPromiseDeferred.cpp:
(JSC::JSPromiseDeferred::visitChildren):
* runtime/JSPromiseDeferred.h:
* runtime/JSPromisePrototype.cpp:
(JSC::JSPromisePrototype::getOwnPropertySlot):
* runtime/JSPromisePrototype.h:
* runtime/RuntimeFlags.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2015-07-23 Sukolsak Sakshuwong <sukolsak@gmail.com>
Implement WebAssembly modules
https://bugs.webkit.org/show_bug.cgi?id=147222
Reviewed by Mark Lam.
Introducing the boilerplate data structure for the WebAssembly module.
WebAssembly functionality will be added in a subsequent patch.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* wasm/JSWASMModule.cpp: Added.
(JSC::JSWASMModule::visitChildren):
* wasm/JSWASMModule.h: Added.
(JSC::JSWASMModule::create):
(JSC::JSWASMModule::createStructure):
(JSC::JSWASMModule::JSWASMModule):
2015-07-23 Devin Rousso <drousso@apple.com>
Web Inspector: Add a function to CSSCompletions to get a list of supported system fonts
https://bugs.webkit.org/show_bug.cgi?id=147009
Reviewed by Joseph Pecoraro.
* inspector/protocol/CSS.json: Added getSupportedSystemFontFamilyNames function.
2015-07-22 Sukolsak Sakshuwong <sukolsak@gmail.com>
Add ENABLE_WEBASSEMBLY feature flag for WebAssembly
https://bugs.webkit.org/show_bug.cgi?id=147212
Reviewed by Filip Pizlo.
* Configurations/FeatureDefines.xcconfig:
2015-07-22 Filip Pizlo <fpizlo@apple.com>
Simplify DFG::DesiredIdentifiers and make it possible to turn a UniquedStringImpl* into an identifierNumber at any time
https://bugs.webkit.org/show_bug.cgi?id=147218
Reviewed by Sam Weinig.
I want to be able to take a UniquedStringImpl* and turn it into an identifierNumber at
various points in my work on https://bugs.webkit.org/show_bug.cgi?id=146929. Currently,
most Nodes that deal with identifiers use identifierNumbers and you can only create an
identifierNumber in BytecodeGenerator. DFG::ByteCodeParser does sort of have the
ability to create new identifierNumbers when inlining - it takes the inlined code's
identifiers and either gives them new numbers or reuses numbers from the enclosing
code.
This patch takes that basic functionality and puts it in
DFG::DesiredIdentifiers::ensure(). Anyone can call this at any time to turn a
UniquedStringImpl* into an identifierNumber. This data structure is already used by
Plan to properly install any newly created identifier table entries into the CodeBlock.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::ByteCodeParser):
(JSC::DFG::ByteCodeParser::noticeArgumentsUse):
(JSC::DFG::ByteCodeParser::linkBlocks):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
(JSC::DFG::ByteCodeParser::buildOperandMapsIfNecessary): Deleted.
* dfg/DFGDesiredIdentifiers.cpp:
(JSC::DFG::DesiredIdentifiers::DesiredIdentifiers):
(JSC::DFG::DesiredIdentifiers::numberOfIdentifiers):
(JSC::DFG::DesiredIdentifiers::ensure):
(JSC::DFG::DesiredIdentifiers::at):
(JSC::DFG::DesiredIdentifiers::addLazily): Deleted.
* dfg/DFGDesiredIdentifiers.h:
2015-07-22 Filip Pizlo <fpizlo@apple.com>
Simplify things like CompareEq(@x,@x)
https://bugs.webkit.org/show_bug.cgi?id=145850
Reviewed by Sam Weinig.
This simplifies x==x to true, except in cases where x might be a double (in which case this
might still be false if x is NaN).
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* tests/stress/nan-equal-untyped.js: Added.
(foo):
(test):
* tests/stress/nan-equal.js: Added.
(foo):
2015-07-22 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Timeline should immediately start moving play head when starting a new recording
https://bugs.webkit.org/show_bug.cgi?id=147210
Reviewed by Timothy Hatcher.
* inspector/protocol/Timeline.json:
Add timestamps to recordingStarted and recordingStopped events.
2015-07-22 Yusuke Suzuki <utatane.tea@gmail.com>
Introducing construct ability into JS executables
https://bugs.webkit.org/show_bug.cgi?id=147183
Reviewed by Geoffrey Garen.
Decouple the construct ability from the builtin functions.
Currently, all builtin functions are not constructors after r182995.
In that patch, when the given function is builtin JS function, we recognize it as the non-constructor function.
But, we need to relax it to implement some constructors in builtins JS.
By decoupling the construct ability from whether the function is builtin or not, we can provide
1. constructors written in builtin JS
2. non-constructors in normal JS functions
(1) is needed for Promise constructor.
And (2) is needed for method functions and arrow functions.
This patch introduces ConstructAbility into the unlinked function executables.
It holds whether the given JS function has the construct ability or not.
By leveraging this, this patch disables the construct ability of the method definitions, setters, getters and arrow functions.
And at the same time, this patch introduces the annotation for constructor in builtin JS.
We can define the function as follows,
constructor Promise(executor)
{
...
}
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createDefaultConstructor):
(JSC::BuiltinExecutables::createExecutableInternal):
* builtins/BuiltinExecutables.h:
* builtins/Iterator.prototype.js:
(symbolIterator):
(SymbolIterator): Deleted.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedCodeBlock.h:
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::makeFunction):
* generate-js-builtins:
(getCopyright):
(Function):
(Function.__init__):
(Function.mangleName):
(getFunctions):
(mangleName): Deleted.
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setUpCall):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CommonIdentifiers.h:
* runtime/ConstructAbility.h: Copied from Source/JavaScriptCore/builtins/Iterator.prototype.js.
* runtime/Executable.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::getConstructData):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* tests/stress/non-constructors.js: Added.
(shouldThrow):
(.prototype.method):
(.prototype.get getter):
(.prototype.set setter):
(.method):
(.get shouldThrow):
(.set shouldThrow):
(set var.test.get getter):
(set var.test.set setter):
(set var.test.normal):
(.set var):
(.set new):
2015-07-22 Csaba Osztrogonác <ossy@webkit.org>
[JSC] Enable exception fuzzing for GCC too
https://bugs.webkit.org/show_bug.cgi?id=146831
Reviewed by Darin Adler.
* jit/JITOperations.cpp:
2015-07-22 Filip Pizlo <fpizlo@apple.com>
Fixed pool allocation should always be aligned
https://bugs.webkit.org/show_bug.cgi?id=147201
Reviewed by Simon Fraser.
Passing an unaligned size to the allocator can cause asserts or even worse things. The
Options reservation value isn't going to be aligned.
* jit/ExecutableAllocatorFixedVMPool.cpp:
(JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
2015-07-22 Csaba Osztrogonác <ossy@webkit.org>
Enable STATIC_ASSERT_IS_TRIVIALLY_DESTRUCTIBLE for GCC
https://bugs.webkit.org/show_bug.cgi?id=146829
Reviewed by Brent Fulgham.
* heap/GCAssertions.h:
2015-07-22 Alex Christensen <achristensen@webkit.org>
Fix quirks in CMake build on Mac and Windows
https://bugs.webkit.org/show_bug.cgi?id=147174
Reviewed by Gyuyoung Kim.
* PlatformMac.cmake:
Add JSRemoteInspector.cpp and remove semicolon from command to make it actually run.
2015-07-21 Yusuke Suzuki <utatane.tea@gmail.com>
Add newTarget accessor to JS constructor written in C++
https://bugs.webkit.org/show_bug.cgi?id=147160
Reviewed by Geoffrey Garen.
This patch adds `ExecState#newTarget()` which returns `new.target` defined in ECMA262 6th.
It enables some C++ constructors (like Intl.XXX constructors) to leverage this to complete
its implementation.
When the constructor is called, |this| in the arguments is used for storing new.target instead.
So by adding the accessor for |this|, JS constructor written in C++ can access new.target.
And at the same time, this patch extends the existing `construct` to accept new.target value.
It is corresponding to the spec's Construct abstract operation.
* interpreter/CallFrame.h:
(JSC::ExecState::newTarget):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::executeConstruct):
* interpreter/Interpreter.h:
* runtime/ConstructData.cpp:
(JSC::construct):
* runtime/ConstructData.h:
(JSC::construct):
2015-07-21 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix a lot of tests. Need to initialize WTF threading sooner.
* jsc.cpp:
(main):
2015-07-21 Filip Pizlo <fpizlo@apple.com>
Fixed VM pool allocation should have a reserve for allocations that cannot fail
https://bugs.webkit.org/show_bug.cgi?id=147154
rdar://problem/21847618
Reviewed by Geoffrey Garen.
This adds the notion of a JIT pool reserve fraction. Some fraction, currently 1/4, of
the JIT pool is reserved for allocations that cannot fail. It makes sense to make this
a fraction rather than a constant because each allocation that can fail may cause some
number of allocations that cannot fail (for example, the OSR exit thunks that we
compile when we exit from some CodeBlock cannot fail).
I've tested this by adding a test mode where we artificially limit the JIT pool size.
Prior to the fix, we had >20 failures. Now we have none.
* heap/GCLogging.cpp:
(WTF::printInternal): I needed a dump method on Options members when debugging this.
* heap/GCLogging.h:
* jit/ExecutableAllocator.h: Raise the ARM64 limit to 32MB because 16MB is cutting it too close.
* jit/ExecutableAllocatorFixedVMPool.cpp:
(JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): Add the ability to artificially limit JIT pool size for testing.
(JSC::ExecutableAllocator::memoryPressureMultiplier): Implement the reserve when computing memory pressure for JIT tier-up heuristics.
(JSC::ExecutableAllocator::allocate): Implement the reserve when allocating can-fail things.
* jsc.cpp: Rewire some options parsing so that CommandLine happens before we create the JIT pool.
(main):
(CommandLine::parseArguments):
(jscmain):
* runtime/Options.cpp:
(JSC::OptionRange::dump): I needed a dump method on Options members when debugging this.
(JSC::Options::initialize): This can now be called more than once.
* runtime/Options.h:
2015-07-21 Saam barati <saambarati1@gmail.com>
ObjectPatternNode's entry should use "const Identifier&" instead of "Identifier"
https://bugs.webkit.org/show_bug.cgi?id=147156
Reviewed by Andreas Kling.
* parser/Nodes.h:
2015-07-21 Basile Clement <basile_clement@apple.com>
Object allocation sinking phase is performing needless HashMap copies
https://bugs.webkit.org/show_bug.cgi?id=147159
Reviewed by Geoffrey Garen.
The points-to analyzer in the object allocation sinking phase is
currently performing copies of its allocation and pointers tables in
several places. While this is not a huge problem since those tables are
usually small and we are in the FTL path anyway, we still shouldn't be
doing such useless copying.
This patch also removes the DFGInsertOSRHintsForUpdate files that are
no longer needed with the new object sinking phase and should have been
removed in r186795.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGInsertOSRHintsForUpdate.cpp: Removed.
(JSC::DFG::insertOSRHintsForUpdate): Deleted.
* dfg/DFGInsertOSRHintsForUpdate.h: Removed.
* dfg/DFGObjectAllocationSinkingPhase.cpp:
2015-07-21 Saam barati <saambarati1@gmail.com>
DestructuringPatternNode and DestructuringAssignmentNode should be ParserArenaFreeable
https://bugs.webkit.org/show_bug.cgi?id=147140
Reviewed by Geoffrey Garen.
The descendants of DestructuringPatternNode that need destruction also
inherit from ParserArenaDeletable.
* parser/Nodes.h:
(JSC::DestructuringPatternNode::~DestructuringPatternNode):
(JSC::ObjectPatternNode::appendEntry):
(JSC::DestructuringAssignmentNode::bindings):
2015-07-21 Keith Miller <keith_miller@apple.com>
Add support for the new.target syntax.
https://bugs.webkit.org/show_bug.cgi?id=147051
Reviewed by Yusuke Suzuki.
Add support for new.target. Essentially the implementation is, before constructor calls,
the target of a "new" is placed where "this" noramlly goes in the calling convention.
Then in the constructor before object is initialized we move the target of the "new"
into a local variable.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
* bytecompiler/NodesCodegen.cpp:
(JSC::NewTargetNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::newTargetExpr):
* parser/NodeConstructors.h:
(JSC::NewTargetNode::NewTargetNode):
* parser/Nodes.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseMemberExpression):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::newTargetExpr):
* runtime/CommonIdentifiers.h:
* tests/stress/new-target.js: Added.
(test):
(call):
(Constructor.subCall):
(Constructor.SubConstructor):
(Constructor):
(noAssign):
(doWeirdThings):
(SuperClass):
(SubClass):
2015-07-20 Saam barati <saambarati1@gmail.com>
"let" scoping introduced incoherent story about symbol table cloning
https://bugs.webkit.org/show_bug.cgi?id=147046
Reviewed by Filip Pizlo.
This patch now establishes a clear set of rules for how SymbolTables
are owned by CodeBlock. Every SymbolTable that is used by a bytecode
instruction must live in CodeBlock's constant register pool. When CodeBlock
is being linked, it ensures that every SymbolTable in the constant pool is cloned.
This leaves no room for an un-cloned symbol table to be used by a bytecode instruction.
Some instructions may refer to SymbolTable's indirectly through a JSLexicalEnvironment.
This is fine, all JSLexicalEnvironment's are allocated with references to cloned symbol tables.
Another goal of this patch is to remove the notion that a SymbolTable is 1 to 1
with a CodeBlock. With lexical scoping, this view of the world is no longer
correct. This patch begins to remove this assumption by making CodeBlock's
symbolTable() getter method private. There is still one place where we need
to purge our codebase of this assumption and that is the type profiler. It
has not been updated for lexical scoping. After it is updated in
https://bugs.webkit.org/show_bug.cgi?id=145438
we will be able to remove CodeBlock's symbolTable() getter entirely.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::nameForRegister):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::addStringSwitchJumpTable):
(JSC::CodeBlock::stringSwitchJumpTable):
(JSC::CodeBlock::evalCodeCache):
(JSC::CodeBlock::symbolTable):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedFunctionExecutable::visitChildren):
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::codeBlockFor):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::addExceptionHandler):
(JSC::UnlinkedCodeBlock::exceptionHandler):
(JSC::UnlinkedCodeBlock::setSymbolTableConstantIndex):
(JSC::UnlinkedCodeBlock::symbolTableConstantIndex):
(JSC::UnlinkedCodeBlock::symbolTable): Deleted.
(JSC::UnlinkedCodeBlock::setSymbolTable): Deleted.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::pushLexicalScope):
(JSC::BytecodeGenerator::variableForLocalEntry):
(JSC::BytecodeGenerator::createVariable):
(JSC::BytecodeGenerator::resolveType):
(JSC::BytecodeGenerator::emitResolveScope):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::thisRegister):
(JSC::BytecodeGenerator::instructions):
(JSC::BytecodeGenerator::symbolTable): Deleted.
* dfg/DFGGraph.h:
(JSC::DFG::Graph::baselineCodeBlockFor):
(JSC::DFG::Graph::isStrictModeFor):
(JSC::DFG::Graph::symbolTableFor): Deleted.
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::baselineCodeBlock):
(JSC::AssemblyHelpers::argumentsStart):
(JSC::AssemblyHelpers::symbolTableFor): Deleted.
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/Executable.cpp:
(JSC::FunctionExecutable::visitChildren):
(JSC::FunctionExecutable::clearUnlinkedCodeForRecompilation):
(JSC::FunctionExecutable::symbolTable): Deleted.
* runtime/Executable.h:
2015-07-18 Filip Pizlo <fpizlo@apple.com>
REGRESSION(186691): OSR entry is broken on loop headers that have no live variables
https://bugs.webkit.org/show_bug.cgi?id=147074
rdar://problem/21869970
Reviewed by Michael Saboff.
The OSR entry must-handle block/value widening introduced in r186691 would cause the
CFA to reexecute if it caused any live local variables to change value. But this fails
if the must-handle block has no live local variables, and the entry block otherwise
appears to be unreachable.
This fixes the bug by having the change detection include whether the block hadn't been
visited in addition to whether any local variable values got widened.
This is a ~4% speed-up on SunSpider in browser.
* dfg/DFGCFAPhase.cpp:
(JSC::DFG::CFAPhase::run):
2015-07-20 Mark Lam <mark.lam@apple.com>
Rollout r187020 and r187021: breaks JSC API tests on debug builds.
https://bugs.webkit.org/show_bug.cgi?id=147110
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::addCurrentThread):
* runtime/JSLock.cpp:
(JSC::JSLockHolder::~JSLockHolder):
(JSC::JSLock::JSLock):
(JSC::JSLock::willDestroyVM):
(JSC::JSLock::setExclusiveThread):
(JSC::JSLock::lock):
(JSC::JSLock::unlock):
(JSC::JSLock::currentThreadIsHoldingLock):
(JSC::JSLock::dropAllLocks):
* runtime/JSLock.h:
(JSC::JSLock::vm):
(JSC::JSLock::hasExclusiveThread):
(JSC::JSLock::exclusiveThread):
* runtime/VM.h:
(JSC::VM::hasExclusiveThread):
(JSC::VM::exclusiveThread):
(JSC::VM::setExclusiveThread):
2015-07-20 Per Arne Vollan <peavo@outlook.com>
Unreviewed debug build fix after r187020.
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::addCurrentThread):
VM::exclusiveThread() has changed return type to ThreadIdentifier.
2015-07-20 Per Arne Vollan <peavo@outlook.com>
JavaScriptCore performance is very bad on Windows
https://bugs.webkit.org/show_bug.cgi?id=146448
Reviewed by Mark Lam.
Profiling shows that std::this_thread::get_id() is slow on Windows.
Use WTF::currentThread() instead, which calls GetCurrentThreadId().
This is faster on Windows. The issue has been reported to Microsoft,
https://connect.microsoft.com/VisualStudio/feedback/details/1558211.
* runtime/JSLock.cpp:
(JSC::JSLockHolder::~JSLockHolder):
(JSC::JSLock::JSLock):
(JSC::JSLock::willDestroyVM):
(JSC::JSLock::setExclusiveThread):
(JSC::JSLock::lock):
(JSC::JSLock::unlock):
(JSC::JSLock::currentThreadIsHoldingLock):
* runtime/JSLock.h:
(JSC::JSLock::vm):
(JSC::JSLock::hasExclusiveThread):
(JSC::JSLock::exclusiveThread):
* runtime/VM.h:
(JSC::VM::hasExclusiveThread):
(JSC::VM::exclusiveThread):
(JSC::VM::setExclusiveThread):
2015-07-19 Yusuke Suzuki <utatane.tea@gmail.com>
In strict mode, `Object.keys(arguments)` includes "length"
https://bugs.webkit.org/show_bug.cgi?id=147071
Reviewed by Darin Adler.
ClonedAguments didn't set the "length" with DontEnum.
* runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::createWithInlineFrame):
(JSC::ClonedArguments::createByCopyingFrom):
* tests/stress/arguments-length-always-dont-enum.js: Added.
(shouldBe):
(argsSloppy):
(argsStrict):
2015-07-19 Jordan Harband <ljharb@gmail.com>
new Date(NaN).toJSON() must return null instead of throwing a TypeError
https://bugs.webkit.org/show_bug.cgi?id=141115
Reviewed by Yusuke Suzuki.
* runtime/DatePrototype.cpp:
(JSC::dateProtoFuncToJSON):
2015-07-19 Saam barati <saambarati1@gmail.com>
Parser::parseFunctionInfo hits RELEASE_ASSERT for Arrow Functions
https://bugs.webkit.org/show_bug.cgi?id=147090
Reviewed by Yusuke Suzuki.
ArrowFunction's have there ParserFunctionInfo "name" field to
be a non-null pointer. This is obviously allowed and valid except we
had a RELEASE_ASSERT that claimed otherwise. This is a mistake.
Note: ArrowFunction's will never actually have a function name;
there ParserFunctionInfo "name" field will be the empty string.
This is not be mistaken with the name field being a null pointer.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionInfo):
2015-07-18 Saam barati <saambarati1@gmail.com>
[ES6] Add support for block scope const
https://bugs.webkit.org/show_bug.cgi?id=31813
Reviewed by Filip Pizlo.
'const' is now implemented in an ES6 spec compliant manner.
'const' variables are always block scoped and always live
either on the stack or in a JSLexicalEnvironment. 'const'
variables never live on the global object.
Inside the BytecodeGenerator, when assigning to a stack
'const' variable or a LocalClosureVar 'const' variable,
we will emit code that just throws a type error.
When assigning to a ClosureVar const variable, CodeBlock linking
will ensure that we perform a dynamic lookup of that variable so
that put_to_scope's slow path throws a type error.
The old 'const' implementation has been removed in this patch.
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::CodeBlock):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::pushLexicalScope):
(JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
(JSC::BytecodeGenerator::variable):
(JSC::BytecodeGenerator::variableForLocalEntry):
(JSC::BytecodeGenerator::createVariable):
(JSC::BytecodeGenerator::emitResolveScope):
(JSC::BytecodeGenerator::emitInstanceOf):
(JSC::BytecodeGenerator::emitGetById):
(JSC::BytecodeGenerator::isArgumentNumber):
(JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
(JSC::BytecodeGenerator::emitEnumeration):
(JSC::BytecodeGenerator::variablePerSymbolTable): Deleted.
(JSC::BytecodeGenerator::emitInitGlobalConst): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::Variable::Variable):
(JSC::Variable::isReadOnly):
(JSC::Variable::isSpecial):
(JSC::Variable::isConst):
(JSC::BytecodeGenerator::thisRegister):
(JSC::BytecodeGenerator::emitTypeOf):
(JSC::BytecodeGenerator::emitIn):
* bytecompiler/NodesCodegen.cpp:
(JSC::PostfixNode::emitResolve):
(JSC::PrefixNode::emitResolve):
(JSC::ReadModifyResolveNode::emitBytecode):
(JSC::AssignResolveNode::emitBytecode):
(JSC::CommaNode::emitBytecode):
(JSC::BindingNode::bindValue):
(JSC::ConstDeclNode::emitCodeSingle): Deleted.
(JSC::ConstDeclNode::emitBytecode): Deleted.
(JSC::ConstStatementNode::emitBytecode): Deleted.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_put_to_arguments):
(JSC::JIT::emit_op_init_global_const): Deleted.
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_put_to_arguments):
(JSC::JIT::emit_op_init_global_const): Deleted.
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createDeclarationStatement):
(JSC::ASTBuilder::createEmptyVarExpression):
(JSC::ASTBuilder::createDebugger):
(JSC::ASTBuilder::appendStatement):
(JSC::ASTBuilder::createVarStatement): Deleted.
(JSC::ASTBuilder::createLetStatement): Deleted.
(JSC::ASTBuilder::createConstStatement): Deleted.
(JSC::ASTBuilder::appendConstDecl): Deleted.
* parser/NodeConstructors.h:
(JSC::CommaNode::CommaNode):
(JSC::SourceElements::SourceElements):
(JSC::SwitchNode::SwitchNode):
(JSC::BlockNode::BlockNode):
(JSC::ConstStatementNode::ConstStatementNode): Deleted.
(JSC::ConstDeclNode::ConstDeclNode): Deleted.
* parser/Nodes.h:
(JSC::ConstDeclNode::hasInitializer): Deleted.
(JSC::ConstDeclNode::ident): Deleted.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseStatementListItem):
(JSC::Parser<LexerType>::parseVariableDeclaration):
(JSC::Parser<LexerType>::parseWhileStatement):
(JSC::Parser<LexerType>::parseVariableDeclarationList):
(JSC::Parser<LexerType>::createBindingPattern):
(JSC::Parser<LexerType>::parseDestructuringPattern):
(JSC::Parser<LexerType>::parseDefaultValueForDestructuringPattern):
(JSC::Parser<LexerType>::parseForStatement):
(JSC::Parser<LexerType>::parseTryStatement):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseConstDeclaration): Deleted.
(JSC::Parser<LexerType>::parseConstDeclarationList): Deleted.
* parser/Parser.h:
(JSC::isEvalNode):
(JSC::isEvalNode<EvalNode>):
(JSC::isArguments):
(JSC::isEval):
(JSC::isEvalOrArgumentsIdentifier):
(JSC::Scope::Scope):
(JSC::Scope::declareCallee):
(JSC::Scope::declareVariable):
(JSC::Scope::declareLexicalVariable):
(JSC::Scope::hasDeclaredVariable):
(JSC::Scope::allowsVarDeclarations):
(JSC::Scope::allowsLexicalDeclarations):
(JSC::Scope::declareParameter):
(JSC::Scope::declareBoundParameter):
(JSC::Parser::destructuringKindFromDeclarationType):
(JSC::Parser::assignmentContextFromDeclarationType):
(JSC::Parser::isEvalOrArguments):
(JSC::Parser::currentScope):
(JSC::Parser::popScope):
(JSC::Parser::declareVariable):
(JSC::Parser::hasDeclaredVariable):
(JSC::Parser::setStrictMode):
(JSC::Parser::strictMode):
(JSC::Parser::isValidStrictMode):
(JSC::Parser::declareParameter):
(JSC::Parser::declareBoundParameter):
(JSC::Parser::breakIsValid):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createForInLoop):
(JSC::SyntaxChecker::createForOfLoop):
(JSC::SyntaxChecker::createEmptyStatement):
(JSC::SyntaxChecker::createDeclarationStatement):
(JSC::SyntaxChecker::createReturnStatement):
(JSC::SyntaxChecker::createBreakStatement):
(JSC::SyntaxChecker::createVarStatement): Deleted.
(JSC::SyntaxChecker::createLetStatement): Deleted.
* parser/VariableEnvironment.h:
(JSC::VariableEnvironmentEntry::isCaptured):
(JSC::VariableEnvironmentEntry::isConst):
(JSC::VariableEnvironmentEntry::isVar):
(JSC::VariableEnvironmentEntry::isLet):
(JSC::VariableEnvironmentEntry::setIsCaptured):
(JSC::VariableEnvironmentEntry::setIsConst):
(JSC::VariableEnvironmentEntry::setIsVar):
(JSC::VariableEnvironmentEntry::setIsLet):
(JSC::VariableEnvironmentEntry::isConstant): Deleted.
(JSC::VariableEnvironmentEntry::setIsConstant): Deleted.
* runtime/Executable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::defineOwnProperty):
(JSC::JSGlobalObject::addGlobalVar):
(JSC::JSGlobalObject::addFunction):
(JSC::lastInPrototypeChain):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::finishCreation):
(JSC::JSGlobalObject::addVar):
(JSC::JSGlobalObject::addConst): Deleted.
* runtime/JSLexicalEnvironment.cpp:
(JSC::JSLexicalEnvironment::symbolTablePut):
* tests/stress/const-and-with-statement.js: Added.
(truth):
(assert):
(shouldThrowInvalidConstAssignment):
(.):
* tests/stress/const-exception-handling.js: Added.
(truth):
(assert):
(.):
* tests/stress/const-loop-semantics.js: Added.
(truth):
(assert):
(shouldThrowInvalidConstAssignment):
(.):
* tests/stress/const-not-strict-mode.js: Added.
(truth):
(assert):
(shouldThrowTDZ):
(.):
* tests/stress/const-semantics.js: Added.
(truth):
(assert):
(shouldThrowInvalidConstAssignment):
(.):
* tests/stress/const-tdz.js: Added.
(truth):
(assert):
(shouldThrowTDZ):
(.):
2015-07-18 Saam barati <saambarati1@gmail.com>
lexical scoping is broken with respect to "break" and "continue"
https://bugs.webkit.org/show_bug.cgi?id=147063
Reviewed by Filip Pizlo.
Bug #142944 which introduced "let" and lexical scoping
didn't properly hook into the bytecode generator's machinery
for calculating scope depth deltas for "break" and "continue". This
resulted in the bytecode generator popping an incorrect number
of scopes when lexical scopes were involved.
This patch fixes this problem and generalizes this machinery a bit.
This patch also renames old functions in a sensible way that is more
coherent in a world with lexical scoping.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::newLabelScope):
(JSC::BytecodeGenerator::emitProfileType):
(JSC::BytecodeGenerator::pushLexicalScope):
(JSC::BytecodeGenerator::popLexicalScope):
(JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
(JSC::BytecodeGenerator::resolveType):
(JSC::BytecodeGenerator::emitResolveScope):
(JSC::BytecodeGenerator::emitGetFromScope):
(JSC::BytecodeGenerator::emitPutToScope):
(JSC::BytecodeGenerator::emitPushWithScope):
(JSC::BytecodeGenerator::emitGetParentScope):
(JSC::BytecodeGenerator::emitPopScope):
(JSC::BytecodeGenerator::emitPopWithOrCatchScope):
(JSC::BytecodeGenerator::emitPopScopes):
(JSC::BytecodeGenerator::calculateTargetScopeDepthForExceptionHandler):
(JSC::BytecodeGenerator::localScopeDepth):
(JSC::BytecodeGenerator::labelScopeDepth):
(JSC::BytecodeGenerator::emitThrowReferenceError):
(JSC::BytecodeGenerator::emitPushFunctionNameScope):
(JSC::BytecodeGenerator::pushScopedControlFlowContext):
(JSC::BytecodeGenerator::popScopedControlFlowContext):
(JSC::BytecodeGenerator::emitPushCatchScope):
(JSC::BytecodeGenerator::currentScopeDepth): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::hasFinaliser):
(JSC::BytecodeGenerator::scopeDepth): Deleted.
* bytecompiler/NodesCodegen.cpp:
(JSC::ContinueNode::trivialTarget):
(JSC::BreakNode::trivialTarget):
(JSC::ReturnNode::emitBytecode):
(JSC::WithNode::emitBytecode):
(JSC::TryNode::emitBytecode):
* tests/stress/lexical-scoping-break-continue.js: Added.
(assert):
(.):
2015-07-18 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r186996.
https://bugs.webkit.org/show_bug.cgi?id=147070
Broke JSC tests (Requested by smfr on #webkit).
Reverted changeset:
"lexical scoping is broken with respect to "break" and
"continue""
https://bugs.webkit.org/show_bug.cgi?id=147063
http://trac.webkit.org/changeset/186996
2015-07-18 Saam barati <saambarati1@gmail.com>
lexical scoping is broken with respect to "break" and "continue"
https://bugs.webkit.org/show_bug.cgi?id=147063
Reviewed by Filip Pizlo.
Bug #142944 which introduced "let" and lexical scoping
didn't properly hook into the bytecode generator's machinery
for calculating scope depth deltas for "break" and "continue". This
resulted in the bytecode generator popping an incorrect number
of scopes when lexical scopes were involved.
This patch fixes this problem and generalizes this machinery a bit.
This patch also renames old functions in a sensible way that is more
coherent in a world with lexical scoping.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::newLabelScope):
(JSC::BytecodeGenerator::emitProfileType):
(JSC::BytecodeGenerator::pushLexicalScope):
(JSC::BytecodeGenerator::popLexicalScope):
(JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
(JSC::BytecodeGenerator::resolveType):
(JSC::BytecodeGenerator::emitResolveScope):
(JSC::BytecodeGenerator::emitGetFromScope):
(JSC::BytecodeGenerator::emitPutToScope):
(JSC::BytecodeGenerator::emitPushWithScope):
(JSC::BytecodeGenerator::emitGetParentScope):
(JSC::BytecodeGenerator::emitPopScope):
(JSC::BytecodeGenerator::emitPopWithOrCatchScope):
(JSC::BytecodeGenerator::emitPopScopes):
(JSC::BytecodeGenerator::calculateTargetScopeDepthForExceptionHandler):
(JSC::BytecodeGenerator::localScopeDepth):
(JSC::BytecodeGenerator::labelScopeDepth):
(JSC::BytecodeGenerator::emitThrowReferenceError):
(JSC::BytecodeGenerator::emitPushFunctionNameScope):
(JSC::BytecodeGenerator::pushScopedControlFlowContext):
(JSC::BytecodeGenerator::popScopedControlFlowContext):
(JSC::BytecodeGenerator::emitPushCatchScope):
(JSC::BytecodeGenerator::currentScopeDepth): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::hasFinaliser):
(JSC::BytecodeGenerator::scopeDepth): Deleted.
* bytecompiler/NodesCodegen.cpp:
(JSC::ContinueNode::trivialTarget):
(JSC::BreakNode::trivialTarget):
(JSC::ReturnNode::emitBytecode):
(JSC::WithNode::emitBytecode):
(JSC::TryNode::emitBytecode):
* tests/stress/lexical-scoping-break-continue.js: Added.
(assert):
(.):
2015-07-17 Filip Pizlo <fpizlo@apple.com>
DFG should have some obvious mitigations against watching structures that are unprofitable to watch
https://bugs.webkit.org/show_bug.cgi?id=147034
Reviewed by Mark Lam and Michael Saboff.
This implements two guards against the DFG watching structures that are likely to fire
their watchpoints:
- Don't watch dictionaries or any structure that had a dictionary in its past. Dictionaries
can be flattened, and then they can transform back to dictionaries.
- Don't watch structures whose past structures were transitioned-away from while their
transition watchpoints were being watched. This property gives us monotonicity: if we
recompile because we watched structure S1 of object O, then we won't make the same mistake
again when object O has structure S2, S3, and so on.
This is a 1.5% speed-up on Kraken. It does penalize some Octane tests, but it also seems to
help some of them, so on Octane it's basically neutral.
* bytecode/Watchpoint.h:
(JSC::WatchpointSet::invalidate):
(JSC::WatchpointSet::isBeingWatched):
(JSC::WatchpointSet::addressOfState):
(JSC::WatchpointSet::addressOfSetIsNotEmpty):
(JSC::InlineWatchpointSet::touch):
(JSC::InlineWatchpointSet::isBeingWatched):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::createStructure):
(JSC::JSGlobalObject::registerWeakMap):
* runtime/Structure.cpp:
(JSC::Structure::Structure):
(JSC::Structure::toDictionaryTransition):
(JSC::Structure::didTransitionFromThisStructure):
* runtime/Structure.h:
2015-07-16 Filip Pizlo <fpizlo@apple.com>
Remove DFG::DesiredWriteBarriers because it's just a very difficult way of saying "please barrier the machine code block owner"
https://bugs.webkit.org/show_bug.cgi?id=147030
Reviewed by Andreas Kling.
All of the users of DesiredWriteBarriers were just using it to request that Plan
finalization executes a barrier on codeBlock->ownerExecutable. Indeed, that's the only
owning cell in the heap that compilation affects. So, we might as well just have Plan
unconditionally execute that barrier and then we don't need DesiredWriteBarriers at
all.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGDesiredWriteBarriers.cpp: Removed.
* dfg/DFGDesiredWriteBarriers.h: Removed.
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::registerFrozenValues):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::reallyAdd):
(JSC::DFG::Plan::notifyCompiling):
(JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
(JSC::DFG::Plan::checkLivenessAndVisitChildren):
(JSC::DFG::Plan::cancel):
* dfg/DFGPlan.h:
2015-07-17 Yusuke Suzuki <utatane.tea@gmail.com>
Integrate automatic microtask draining into JSC framework and re-enable Promise
https://bugs.webkit.org/show_bug.cgi?id=146828
Reviewed by Sam Weinig.
Add automatic microtask draining system into JSC framework.
When the depth of VM lock becomes 0, before this, we drain the queued microtasks.
Enqueuing behavior can be injected by the JSGlobalObject's method table.
It is utilized in WebCore to post the microtask to WebCore's event loop.
In the case of JSC interactive shell, VM depth is always greater than 0.
So we manually drains the queued microtasks after evaluating the written line.
Since now JSC framework has the microtask queue, we can drain the queued microtasks.
So re-enable the Promise in the JSC framework context.
* API/JSContextRef.cpp:
(javaScriptRuntimeFlags): Deleted.
* API/tests/testapi.c:
(main):
* API/tests/testapi.mm:
(testObjectiveCAPIMain):
* jsc.cpp:
(runInteractive):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::queueMicrotask):
* runtime/JSLock.cpp:
(JSC::JSLock::willReleaseLock):
* runtime/VM.cpp:
(JSC::VM::queueMicrotask):
(JSC::VM::drainMicrotasks):
(JSC::QueuedTask::run):
* runtime/VM.h:
(JSC::QueuedTask::QueuedTask):
2015-07-17 Saam barati <saambarati1@gmail.com>
Function parameters should be parsed in the same parser arena as the function body
https://bugs.webkit.org/show_bug.cgi?id=145995
Reviewed by Yusuke Suzuki.
This patch changes how functions are parsed in JSC. A function's
parameters are now parsed in the same arena as the function itself.
This allows us to arena allocate all destructuring AST nodes and
the FunctionParameters node. This will help make implementing ES6
default parameter values sane.
A source code that represents a function now includes the text of the function's
parameters. The starting offset is at the opening parenthesis of the parameter
list or at the starting character of the identifier for arrow functions that
have single arguments and don't start with parenthesis.
For example:
"function (param1, param2) { ... }"
^
| This offset used to be the starting offset of a function's SourceCode
^
| This is the new starting offset for a function's SourceCode.
This requires us to change how some offsets are calculated
and also requires us to report some different line numbers for internal
metrics that use a SourceCode's starting line and column numbers.
This patch also does a bit of cleanup with regards to how
functions are parsed in general (especially arrow functions).
It removes some unnecessary #ifdefs and the likes for arrow
to make things clearer and more deliberate.
* API/JSScriptRef.cpp:
(parseScript):
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createExecutableInternal):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::UnlinkedFunctionExecutable::visitChildren):
(JSC::UnlinkedFunctionExecutable::parameterCount): Deleted.
* bytecode/UnlinkedCodeBlock.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::DestructuringAssignmentNode::emitBytecode):
(JSC::assignDefaultValueIfUndefined):
(JSC::ArrayPatternNode::collectBoundIdentifiers):
(JSC::DestructuringPatternNode::~DestructuringPatternNode): Deleted.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createClassExpr):
(JSC::ASTBuilder::createFunctionExpr):
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::createArrowFunctionExpr):
(JSC::ASTBuilder::createGetterOrSetterProperty):
(JSC::ASTBuilder::createElementList):
(JSC::ASTBuilder::createFormalParameterList):
(JSC::ASTBuilder::appendParameter):
(JSC::ASTBuilder::createClause):
(JSC::ASTBuilder::createClauseList):
(JSC::ASTBuilder::createFuncDeclStatement):
(JSC::ASTBuilder::createForInLoop):
(JSC::ASTBuilder::createForOfLoop):
(JSC::ASTBuilder::isResolve):
(JSC::ASTBuilder::createDestructuringAssignment):
(JSC::ASTBuilder::createArrayPattern):
(JSC::ASTBuilder::appendArrayPatternSkipEntry):
(JSC::ASTBuilder::appendArrayPatternEntry):
(JSC::ASTBuilder::appendArrayPatternRestEntry):
(JSC::ASTBuilder::finishArrayPattern):
(JSC::ASTBuilder::createObjectPattern):
(JSC::ASTBuilder::appendObjectPatternEntry):
(JSC::ASTBuilder::createBindingLocation):
(JSC::ASTBuilder::setEndOffset):
* parser/Lexer.cpp:
(JSC::Lexer<T>::Lexer):
(JSC::Lexer<T>::nextTokenIsColon):
(JSC::Lexer<T>::setTokenPosition):
(JSC::Lexer<T>::lex):
(JSC::Lexer<T>::clear):
* parser/Lexer.h:
(JSC::Lexer::setIsReparsingFunction):
(JSC::Lexer::isReparsingFunction):
(JSC::Lexer::lineNumber):
(JSC::Lexer::setIsReparsing): Deleted.
(JSC::Lexer::isReparsing): Deleted.
* parser/NodeConstructors.h:
(JSC::TryNode::TryNode):
(JSC::FunctionParameters::FunctionParameters):
(JSC::FuncExprNode::FuncExprNode):
(JSC::FuncDeclNode::FuncDeclNode):
(JSC::ArrayPatternNode::ArrayPatternNode):
(JSC::ObjectPatternNode::ObjectPatternNode):
(JSC::BindingNode::BindingNode):
(JSC::DestructuringAssignmentNode::DestructuringAssignmentNode):
(JSC::ParameterNode::ParameterNode): Deleted.
(JSC::ArrayPatternNode::create): Deleted.
(JSC::ObjectPatternNode::create): Deleted.
(JSC::BindingNode::create): Deleted.
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::EvalNode::EvalNode):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::finishParsing):
(JSC::FunctionNode::FunctionNode):
(JSC::FunctionNode::finishParsing):
(JSC::FunctionParameters::create): Deleted.
(JSC::FunctionParameters::FunctionParameters): Deleted.
(JSC::FunctionParameters::~FunctionParameters): Deleted.
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionParameters::size):
(JSC::FunctionParameters::at):
(JSC::FunctionParameters::append):
(JSC::FuncExprNode::body):
(JSC::DestructuringPatternNode::~DestructuringPatternNode):
(JSC::DestructuringPatternNode::isBindingNode):
(JSC::DestructuringPatternNode::emitDirectBinding):
(JSC::ArrayPatternNode::appendIndex):
(JSC::ObjectPatternNode::appendEntry):
(JSC::BindingNode::boundProperty):
(JSC::BindingNode::divotStart):
(JSC::BindingNode::divotEnd):
(JSC::DestructuringAssignmentNode::bindings):
(JSC::FuncDeclNode::body):
(JSC::ParameterNode::pattern): Deleted.
(JSC::ParameterNode::nextParam): Deleted.
(JSC::FunctionParameters::patterns): Deleted.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::Parser):
(JSC::Parser<LexerType>::~Parser):
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::allowAutomaticSemicolon):
(JSC::Parser<LexerType>::parseSourceElements):
(JSC::Parser<LexerType>::createBindingPattern):
(JSC::Parser<LexerType>::parseArrowFunctionSingleExpressionBodySourceElements):
(JSC::Parser<LexerType>::tryParseDestructuringPatternExpression):
(JSC::Parser<LexerType>::parseSwitchClauses):
(JSC::Parser<LexerType>::parseSwitchDefaultClause):
(JSC::Parser<LexerType>::parseBlockStatement):
(JSC::Parser<LexerType>::parseStatement):
(JSC::Parser<LexerType>::parseFormalParameters):
(JSC::Parser<LexerType>::parseFunctionBody):
(JSC::stringForFunctionMode):
(JSC::Parser<LexerType>::parseFunctionParameters):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parsePrimaryExpression):
(JSC::Parser<LexerType>::parseMemberExpression):
(JSC::Parser<LexerType>::parseArrowFunctionExpression):
(JSC::operatorString):
(JSC::Parser<LexerType>::parseArrowFunctionSingleExpressionBody): Deleted.
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::Parser::locationBeforeLastToken):
(JSC::Parser::findCachedFunctionInfo):
(JSC::Parser::isofToken):
(JSC::Parser::isEndOfArrowFunction):
(JSC::Parser::isArrowFunctionParamters):
(JSC::Parser::tokenStart):
(JSC::Parser::isLETMaskedAsIDENT):
(JSC::Parser::autoSemiColon):
(JSC::Parser::setEndOfStatement):
(JSC::Parser::canRecurse):
(JSC::Parser<LexerType>::parse):
(JSC::parse):
* parser/ParserFunctionInfo.h:
* parser/ParserModes.h:
(JSC::functionNameIsInScope):
* parser/SourceCode.h:
(JSC::makeSource):
(JSC::SourceCode::subExpression):
(JSC::SourceCode::subArrowExpression): Deleted.
* parser/SourceProviderCache.h:
(JSC::SourceProviderCache::get):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::endFunctionToken):
(JSC::SourceProviderCacheItem::usedVariables):
(JSC::SourceProviderCacheItem::writtenVariables):
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::SyntaxChecker):
(JSC::SyntaxChecker::createClassExpr):
(JSC::SyntaxChecker::createFunctionExpr):
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::createArrowFunctionExpr):
(JSC::SyntaxChecker::setFunctionNameStart):
(JSC::SyntaxChecker::createArguments):
(JSC::SyntaxChecker::createPropertyList):
(JSC::SyntaxChecker::createElementList):
(JSC::SyntaxChecker::createFormalParameterList):
(JSC::SyntaxChecker::appendParameter):
(JSC::SyntaxChecker::createClause):
(JSC::SyntaxChecker::createClauseList):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/Completion.cpp:
(JSC::checkSyntax):
* runtime/Executable.cpp:
(JSC::ProgramExecutable::checkSyntax):
* tests/controlFlowProfiler/conditional-expression.js:
(testConditionalFunctionCall):
2015-07-16 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix build for newer LLVMs.
* llvm/LLVMHeaders.h:
* llvm/library/LLVMExports.cpp:
2015-07-16 Mark Lam <mark.lam@apple.com>
RegExp::match() should set m_state to ByteCode if compilation fails.
https://bugs.webkit.org/show_bug.cgi?id=147023
Reviewed by Michael Saboff.
A RegExp has a YarrCodeBlock that has 4 MacroAssemblerCodeRefs for compiled code.
If one of these compilations succeeds, RegExp::m_state will be set to JITCode.
Subsequently, if RegExp tries to compile another one of these but fails, m_state
will be left untouched i.e. it still says JITCode. As a result, when
RegExp::match() later tries to execute the non-existant compiled code, it will
crash.
The fix is to downgrade m_state to ByteCode if RegExp ever fails to compile.
This failure should be rare. We'll do the minimal work here to fix the issue and
keep an eye on the perf bots. If perf regresses, we can do some optimization work then.
This issue is difficult to test for since it either requires a low memory condition
to trigger a failed RegExp compilation at the right moment, or for the RegExp to
succeed compilation in the MatchedOnly mode but fail in IncludeSubpatterns mode.
Instead, I manually tested it by instrumenting RegExp::compile() to fail once in every
10 compilation attempts.
* runtime/RegExp.cpp:
(JSC::RegExp::compile):
(JSC::RegExp::compileMatchOnly):
2015-07-15 Brent Fulgham <bfulgham@apple.com>
[Win] Fix armv7 build.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState): The 64-bit argument
version of poke is not available on armv7 builds.
2015-07-15 Brent Fulgham <bfulgham@apple.com>
[Win] 64-bit Build Failure
https://bugs.webkit.org/show_bug.cgi?id=146989
Reviewed by Mark Lam.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState): Add missing
declaration for 64-bit type on 4-argument register machines (like
Windows).
2015-07-15 Saam barati <saambarati1@gmail.com>
[ES6] implement block scoping to enable 'let'
https://bugs.webkit.org/show_bug.cgi?id=142944
Reviewed by Filip Pizlo.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createExecutableInternal):
* bytecode/BytecodeList.json:
This patch adds a new opcode and removes op_pop_scope:
1) op_get_parent_scope returns the parent scope but doesn't
implicitly write that scope into the scope register. op_pop_scope
is now reduced to op_get_parent_scope followed by op_mov.
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::stronglyVisitStrongReferences):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::addStringSwitchJumpTable):
(JSC::CodeBlock::stringSwitchJumpTable):
(JSC::CodeBlock::symbolTable):
(JSC::CodeBlock::evalCodeCache):
(JSC::CodeBlock::setConstantRegisters):
(JSC::CodeBlock::replaceConstant):
op_put_to_scope for LocalClosureVar now takes as an argument
the constant index for the Symbol Table it will be putting into.
This argument is only used to communicate from the BytecodeGenerator
to CodeBlock linking time and it is not present in the linked bytecode.
op_put_to_scope for non LocalClosureVar takes, at the same index, an
argument that represents the local scope depth which it uses for
JSScope::abstractResolve to know how many scopes it needs to skip.
Again, this is not in the linked code.
op_get_from_scope and op_resolve_scope also take as an argument
the local scope depth to use in JSScope::abstractResolve. Again,
this is not used in the linked code.
* bytecode/EvalCodeCache.h:
(JSC::EvalCodeCache::tryGet):
(JSC::EvalCodeCache::getSlow):
(JSC::EvalCodeCache::clear):
(JSC::EvalCodeCache::isCacheable):
When direct eval is called and passed a scope that
corresponds to a lexical scope, we can't safely cache
that code because we won't be able to guarantee
that the cached code is always executed in the same scope.
Consider this example:
function foo() {
let x = 20;
eval("x;");
if (b) {
let x = 30;
if (b) {
let y = 40;
eval("x;")
}
}
}
We can't reuse resolution depth when linking get_from_scope in evals.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::UnlinkedFunctionExecutable::parameterCount):
* bytecode/UnlinkedCodeBlock.h:
Unlinked functions now know the variables that were under TDZ in their parent
scope.
(JSC::UnlinkedCodeBlock::symbolTable):
(JSC::UnlinkedCodeBlock::setSymbolTable):
(JSC::UnlinkedCodeBlock::setSymbolTableConstantIndex):
(JSC::UnlinkedCodeBlock::symbolTableConstantIndex):
(JSC::UnlinkedCodeBlock::vm):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::~BytecodeGenerator):
(JSC::BytecodeGenerator::newRegister):
(JSC::BytecodeGenerator::reclaimFreeRegisters):
(JSC::BytecodeGenerator::newBlockScopeVariable):
(JSC::BytecodeGenerator::newTemporary):
(JSC::BytecodeGenerator::emitProfileType):
(JSC::BytecodeGenerator::emitLoadGlobalObject):
(JSC::BytecodeGenerator::pushLexicalScope):
(JSC::BytecodeGenerator::popLexicalScope):
(JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
(JSC::BytecodeGenerator::variable):
(JSC::BytecodeGenerator::variablePerSymbolTable):
(JSC::BytecodeGenerator::variableForLocalEntry):
(JSC::BytecodeGenerator::createVariable):
(JSC::BytecodeGenerator::emitResolveScope):
(JSC::BytecodeGenerator::emitGetFromScope):
(JSC::BytecodeGenerator::emitPutToScope):
(JSC::BytecodeGenerator::initializeVariable):
(JSC::BytecodeGenerator::emitTDZCheck):
(JSC::BytecodeGenerator::needsTDZCheck):
(JSC::BytecodeGenerator::emitTDZCheckIfNecessary):
(JSC::BytecodeGenerator::liftTDZCheckIfPossible):
(JSC::BytecodeGenerator::getVariablesUnderTDZ):
(JSC::BytecodeGenerator::emitNewObject):
(JSC::BytecodeGenerator::emitPushWithScope):
(JSC::BytecodeGenerator::emitGetParentScope):
(JSC::BytecodeGenerator::emitPopScope):
(JSC::BytecodeGenerator::emitDebugHook):
(JSC::BytecodeGenerator::pushFinallyContext):
(JSC::BytecodeGenerator::pushIteratorCloseContext):
(JSC::BytecodeGenerator::emitComplexPopScopes):
(JSC::BytecodeGenerator::emitPopScopes):
(JSC::BytecodeGenerator::popTryAndEmitCatch):
(JSC::BytecodeGenerator::calculateTargetScopeDepthForExceptionHandler):
(JSC::BytecodeGenerator::currentScopeDepth):
(JSC::BytecodeGenerator::emitThrowReferenceError):
(JSC::BytecodeGenerator::emitPushCatchScope):
(JSC::BytecodeGenerator::beginSwitch):
(JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
(JSC::BytecodeGenerator::emitEnumeration):
* bytecompiler/BytecodeGenerator.h:
(JSC::Variable::Variable):
(JSC::Variable::isResolved):
(JSC::Variable::symbolTableConstantIndex):
(JSC::Variable::ident):
(JSC::BytecodeGenerator::ignoredResult):
(JSC::BytecodeGenerator::tempDestination):
(JSC::BytecodeGenerator::lastOpcodeID):
(JSC::BytecodeGenerator::makeFunction):
(JSC::BytecodeGenerator::symbolTable):
(JSC::BytecodeGenerator::shouldOptimizeLocals): Deleted.
(JSC::BytecodeGenerator::canOptimizeNonLocals): Deleted.
The heart of the changes in this patch are in the bytecode generator.
The bytecode generator now keeps a stack of tuples of
{symbol table, scope register, flag indicating catch or with scope, symbol table index in constant pool}
that models the runtime scope stack. This symbol table stack is used
in resolving local variables.
Also, the bytecode generator handles pushing and popping of lexical scopes.
This is relatively straight forward:
Captured 'let' variables end up in the JSLexicalEnvironment scope and non-captured
variables end up on the stack. Some trickiness is involved in generating
code for 'for' loops that have captured variables (I'm talking about variables in the loop
header, not the loop body). Each iteration of the for loop ends up with
its own JSLexicalEnvironment. Static code must be generated in such a way
to create this runtime behavior. This is done by emitting instructions to
push and pop a lexical scope at the end of each loop and copying values
from the previous loop's scope into the new scope. This code must also
ensure that each loop iteration's scope refers to the same underlying
SymbolTable so that no scope is accidentally mistaken as being a singleton scope.
When the debugger is enabled, all lexically defined variables will end up in the
JSLexicalEnvironment.
* bytecompiler/NodesCodegen.cpp:
(JSC::ResolveNode::emitBytecode):
(JSC::FunctionCallResolveNode::emitBytecode):
(JSC::PostfixNode::emitResolve):
(JSC::DeleteResolveNode::emitBytecode):
(JSC::TypeOfResolveNode::emitBytecode):
(JSC::PrefixNode::emitResolve):
(JSC::ReadModifyResolveNode::emitBytecode):
(JSC::AssignResolveNode::emitBytecode):
(JSC::BlockNode::emitBytecode):
(JSC::ExprStatementNode::emitBytecode):
(JSC::DeclarationStatement::emitBytecode):
(JSC::EmptyVarExpression::emitBytecode):
(JSC::EmptyLetExpression::emitBytecode):
(JSC::ForNode::emitBytecode):
(JSC::ForInNode::emitMultiLoopBytecode):
(JSC::ForOfNode::emitBytecode):
(JSC::SwitchNode::emitBytecode):
(JSC::BindingNode::bindValue):
(JSC::VarStatementNode::emitBytecode): Deleted.
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::evaluate):
* debugger/DebuggerScope.cpp:
(JSC::DebuggerScope::getOwnPropertySlot):
(JSC::DebuggerScope::put):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGNode.h:
(JSC::DFG::Node::castConstant):
(JSC::DFG::Node::initializationValueForActivation):
(JSC::DFG::Node::containsMovHint):
* dfg/DFGObjectAllocationSinkingPhase.cpp:
CreateActivation nodes now have a second OpInfo that tracks the
initial value that needs to be placed in the activation. This initial value
is also used in allocation sinking to create proper bottom values for all
scope variables.
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCreateActivation):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* ftl/FTLIntrinsicRepository.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileCreateActivation):
(JSC::FTL::DFG::LowerDFGToLLVM::compileMaterializeCreateActivation):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_push_with_scope):
(JSC::JIT::compileOpStrictEq):
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_create_lexical_environment):
(JSC::JIT::emit_op_get_parent_scope):
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emit_op_enter):
(JSC::JIT::emit_op_get_scope):
(JSC::JIT::emit_op_pop_scope): Deleted.
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_push_with_scope):
(JSC::JIT::emit_op_to_number):
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_create_lexical_environment):
(JSC::JIT::emit_op_get_parent_scope):
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emit_op_enter):
(JSC::JIT::emit_op_get_scope):
(JSC::JIT::emit_op_pop_scope): Deleted.
* jit/JITOperations.cpp:
(JSC::canAccessArgumentIndexQuickly):
* jit/JITOperations.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createSourceElements):
(JSC::ASTBuilder::funcDeclarations):
(JSC::ASTBuilder::features):
(JSC::ASTBuilder::numConstants):
(JSC::ASTBuilder::createConditionalExpr):
(JSC::ASTBuilder::createAssignResolve):
(JSC::ASTBuilder::createClassDeclStatement):
(JSC::ASTBuilder::createBlockStatement):
(JSC::ASTBuilder::createIfStatement):
(JSC::ASTBuilder::createForLoop):
(JSC::ASTBuilder::createForInLoop):
(JSC::ASTBuilder::createForOfLoop):
(JSC::ASTBuilder::isBindingNode):
(JSC::ASTBuilder::createEmptyStatement):
(JSC::ASTBuilder::createDeclarationStatement):
(JSC::ASTBuilder::createVarStatement):
(JSC::ASTBuilder::createLetStatement):
(JSC::ASTBuilder::createEmptyVarExpression):
(JSC::ASTBuilder::createEmptyLetExpression):
(JSC::ASTBuilder::createReturnStatement):
(JSC::ASTBuilder::createTryStatement):
(JSC::ASTBuilder::createSwitchStatement):
(JSC::ASTBuilder::appendStatement):
(JSC::ASTBuilder::createCommaExpr):
(JSC::ASTBuilder::appendObjectPatternEntry):
(JSC::ASTBuilder::createBindingLocation):
(JSC::ASTBuilder::setEndOffset):
(JSC::ASTBuilder::Scope::Scope):
(JSC::ASTBuilder::makeAssignNode):
(JSC::ASTBuilder::varDeclarations): Deleted.
(JSC::ASTBuilder::addVar): Deleted.
* parser/Keywords.table:
* parser/NodeConstructors.h:
(JSC::ReadModifyResolveNode::ReadModifyResolveNode):
(JSC::AssignResolveNode::AssignResolveNode):
(JSC::ExprStatementNode::ExprStatementNode):
(JSC::DeclarationStatement::DeclarationStatement):
(JSC::EmptyVarExpression::EmptyVarExpression):
(JSC::EmptyLetExpression::EmptyLetExpression):
(JSC::IfElseNode::IfElseNode):
(JSC::WhileNode::WhileNode):
(JSC::ForNode::ForNode):
(JSC::CaseBlockNode::CaseBlockNode):
(JSC::SwitchNode::SwitchNode):
(JSC::ConstDeclNode::ConstDeclNode):
(JSC::BlockNode::BlockNode):
(JSC::EnumerationNode::EnumerationNode):
(JSC::ForInNode::ForInNode):
(JSC::ForOfNode::ForOfNode):
(JSC::ObjectPatternNode::create):
(JSC::BindingNode::create):
(JSC::BindingNode::BindingNode):
(JSC::VarStatementNode::VarStatementNode): Deleted.
* parser/Nodes.cpp:
(JSC::ScopeNode::ScopeNode):
(JSC::ScopeNode::singleStatement):
(JSC::ProgramNode::ProgramNode):
(JSC::EvalNode::EvalNode):
(JSC::FunctionNode::FunctionNode):
(JSC::FunctionNode::finishParsing):
(JSC::VariableEnvironmentNode::VariableEnvironmentNode):
* parser/Nodes.h:
(JSC::VariableEnvironmentNode::VariableEnvironmentNode):
(JSC::VariableEnvironmentNode::lexicalVariables):
(JSC::ScopeNode::usesThis):
(JSC::ScopeNode::needsActivationForMoreThanVariables):
(JSC::ScopeNode::needsActivation):
(JSC::ScopeNode::hasCapturedVariables):
(JSC::ScopeNode::captures):
(JSC::ScopeNode::varDeclarations):
(JSC::ScopeNode::functionStack):
(JSC::ScopeNode::neededConstants):
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::BindingNode::boundProperty):
(JSC::BindingNode::divotStart):
(JSC::BindingNode::divotEnd):
(JSC::ScopeNode::capturedVariableCount): Deleted.
(JSC::ScopeNode::capturedVariables): Deleted.
(JSC::ScopeNode::varStack): Deleted.
There is a new class called 'VariableEnvironmentNode' that has the
necessary fields to model a lexical scope. Multiple AST nodes now
also inherit from VariableEnvironmentNode.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::didFinishParsing):
(JSC::Parser<LexerType>::parseStatementListItem):
(JSC::Parser<LexerType>::parseVariableDeclaration):
(JSC::Parser<LexerType>::parseWhileStatement):
(JSC::Parser<LexerType>::parseVariableDeclarationList):
(JSC::Parser<LexerType>::createBindingPattern):
(JSC::Parser<LexerType>::tryParseDestructuringPatternExpression):
(JSC::Parser<LexerType>::parseDestructuringPattern):
(JSC::Parser<LexerType>::parseConstDeclarationList):
(JSC::Parser<LexerType>::parseForStatement):
(JSC::Parser<LexerType>::parseBreakStatement):
(JSC::Parser<LexerType>::parseContinueStatement):
(JSC::Parser<LexerType>::parseSwitchStatement):
(JSC::Parser<LexerType>::parseTryStatement):
(JSC::Parser<LexerType>::parseBlockStatement):
(JSC::Parser<LexerType>::parseStatement):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseClassDeclaration):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
(JSC::Parser<LexerType>::parseAssignmentExpression):
(JSC::Parser<LexerType>::parseGetterSetter):
(JSC::Parser<LexerType>::parsePrimaryExpression):
(JSC::Parser<LexerType>::parseVarDeclaration): Deleted.
(JSC::Parser<LexerType>::parseVarDeclarationList): Deleted.
* parser/Parser.h:
(JSC::Scope::Scope):
(JSC::Scope::setIsFunction):
(JSC::Scope::isFunction):
(JSC::Scope::isFunctionBoundary):
(JSC::Scope::setIsLexicalScope):
(JSC::Scope::isLexicalScope):
(JSC::Scope::declaredVariables):
(JSC::Scope::finalizeLexicalEnvironment):
(JSC::Scope::computeLexicallyCapturedVariablesAndPurgeCandidates):
(JSC::Scope::declareCallee):
(JSC::Scope::declareVariable):
(JSC::Scope::declareLexicalVariable):
(JSC::Scope::hasDeclaredVariable):
(JSC::Scope::hasLexicallyDeclaredVariable):
(JSC::Scope::hasDeclaredParameter):
(JSC::Scope::declareWrite):
(JSC::Scope::preventAllVariableDeclarations):
(JSC::Scope::preventVarDeclarations):
(JSC::Scope::allowsVarDeclarations):
(JSC::Scope::allowsLexicalDeclarations):
(JSC::Scope::declareParameter):
(JSC::Scope::declareBoundParameter):
(JSC::Scope::useVariable):
(JSC::Scope::setNeedsFullActivation):
(JSC::Scope::needsFullActivation):
(JSC::Scope::hasDirectSuper):
(JSC::Scope::setNeedsSuperBinding):
(JSC::Scope::collectFreeVariables):
(JSC::Scope::getCapturedVars):
(JSC::Scope::copyCapturedVariablesToVector):
(JSC::Parser::AutoCleanupLexicalScope::AutoCleanupLexicalScope):
(JSC::Parser::AutoCleanupLexicalScope::~AutoCleanupLexicalScope):
(JSC::Parser::AutoCleanupLexicalScope::setIsValid):
(JSC::Parser::AutoCleanupLexicalScope::isValid):
(JSC::Parser::AutoCleanupLexicalScope::setPopped):
(JSC::Parser::AutoCleanupLexicalScope::scope):
(JSC::Parser::currentScope):
(JSC::Parser::pushScope):
(JSC::Parser::popScopeInternal):
(JSC::Parser::popScope):
(JSC::Parser::declareVariable):
(JSC::Parser::hasDeclaredVariable):
(JSC::Parser::hasDeclaredParameter):
(JSC::Parser::declareWrite):
(JSC::Parser::findCachedFunctionInfo):
(JSC::Parser::isFunctionBodyNode):
(JSC::Parser::continueIsValid):
(JSC::Parser::pushLabel):
(JSC::Parser::popLabel):
(JSC::Parser::getLabel):
(JSC::Parser::isLETMaskedAsIDENT):
(JSC::Parser<LexerType>::parse):
(JSC::Scope::preventNewDecls): Deleted.
(JSC::Scope::allowsNewDecls): Deleted.
(JSC::Scope::getCapturedVariables): Deleted.
There are basic parser changes that now allow for the 'let'
keyword. The trickiest change is how we will still treat 'let'
as an identifier for sloppy-mode code sometimes. For example,
"var let = ..." is allowed but "let let" or "const let" is not.
The most significant change to the parser made for this patch
is appropriating the Scope struct to also also model a lexical
scope. Changes were made in how we track captured variables to
account for this. In general, I think some of this code could
benefit from a slight refactoring to make things cleaner.
* parser/ParserTokens.h:
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createNewExpr):
(JSC::SyntaxChecker::createConditionalExpr):
(JSC::SyntaxChecker::createAssignResolve):
(JSC::SyntaxChecker::createEmptyVarExpression):
(JSC::SyntaxChecker::createEmptyLetExpression):
(JSC::SyntaxChecker::createClassExpr):
(JSC::SyntaxChecker::createClassDeclStatement):
(JSC::SyntaxChecker::createBlockStatement):
(JSC::SyntaxChecker::createExprStatement):
(JSC::SyntaxChecker::createIfStatement):
(JSC::SyntaxChecker::createForLoop):
(JSC::SyntaxChecker::createForInLoop):
(JSC::SyntaxChecker::createForOfLoop):
(JSC::SyntaxChecker::createEmptyStatement):
(JSC::SyntaxChecker::createVarStatement):
(JSC::SyntaxChecker::createLetStatement):
(JSC::SyntaxChecker::createReturnStatement):
(JSC::SyntaxChecker::createBreakStatement):
(JSC::SyntaxChecker::createContinueStatement):
(JSC::SyntaxChecker::createTryStatement):
(JSC::SyntaxChecker::createSwitchStatement):
(JSC::SyntaxChecker::createWhileStatement):
(JSC::SyntaxChecker::createWithStatement):
(JSC::SyntaxChecker::createDoWhileStatement):
(JSC::SyntaxChecker::createGetterOrSetterProperty):
(JSC::SyntaxChecker::appendStatement):
(JSC::SyntaxChecker::combineCommaNodes):
(JSC::SyntaxChecker::evalCount):
(JSC::SyntaxChecker::appendBinaryExpressionInfo):
(JSC::SyntaxChecker::operatorStackPop):
(JSC::SyntaxChecker::addVar): Deleted.
* parser/VariableEnvironment.cpp: Added.
(JSC::VariableEnvironment::markVariableAsCapturedIfDefined):
(JSC::VariableEnvironment::markVariableAsCaptured):
(JSC::VariableEnvironment::markAllVariablesAsCaptured):
(JSC::VariableEnvironment::hasCapturedVariables):
(JSC::VariableEnvironment::captures):
(JSC::VariableEnvironment::swap):
* parser/VariableEnvironment.h: Added.
(JSC::VariableEnvironmentEntry::isCaptured):
(JSC::VariableEnvironmentEntry::isConstant):
(JSC::VariableEnvironmentEntry::isVar):
(JSC::VariableEnvironmentEntry::isLet):
(JSC::VariableEnvironmentEntry::setIsCaptured):
(JSC::VariableEnvironmentEntry::setIsConstant):
(JSC::VariableEnvironmentEntry::setIsVar):
(JSC::VariableEnvironmentEntry::setIsLet):
(JSC::VariableEnvironmentEntry::clearIsVar):
(JSC::VariableEnvironment::begin):
(JSC::VariableEnvironment::end):
(JSC::VariableEnvironment::add):
(JSC::VariableEnvironment::size):
(JSC::VariableEnvironment::contains):
(JSC::VariableEnvironment::remove):
VariableEnvironment is a new class that keeps track
of the static environment in the parser and the bytecode generator.
VariableEnvironment behaves like SymbolTable but for the bytecode generator.
It keeps track of variable types, i.e, if a variable is a "var", "let", "const"
and whether or not its captured.
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
(JSC::CodeCache::clear):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* runtime/ExceptionHelpers.cpp:
(JSC::createErrorForInvalidGlobalAssignment):
(JSC::createTDZError):
(JSC::throwOutOfMemoryError):
* runtime/ExceptionHelpers.h:
* runtime/Executable.cpp:
(JSC::EvalExecutable::create):
(JSC::ProgramExecutable::initializeGlobalProperties):
* runtime/Executable.h:
* runtime/JSCJSValue.h:
(JSC::jsUndefined):
(JSC::jsTDZValue):
(JSC::jsBoolean):
* runtime/JSEnvironmentRecord.h:
(JSC::JSEnvironmentRecord::finishCreationUninitialized):
(JSC::JSEnvironmentRecord::finishCreation):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::weakRandomInteger):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncEval):
* runtime/JSLexicalEnvironment.cpp:
(JSC::JSLexicalEnvironment::symbolTableGet):
* runtime/JSLexicalEnvironment.h:
(JSC::JSLexicalEnvironment::create):
* runtime/JSScope.cpp:
(JSC::JSScope::resolve):
(JSC::JSScope::abstractResolve):
(JSC::JSScope::collectVariablesUnderTDZ):
(JSC::JSScope::isLexicalScope):
(JSC::resolveModeName):
* runtime/JSScope.h:
* runtime/PropertySlot.h:
(JSC::PropertySlot::setValue):
* runtime/SymbolTable.cpp:
(JSC::SymbolTable::SymbolTable):
(JSC::SymbolTable::cloneScopePart):
* runtime/SymbolTable.h:
SymbolTable now uses an extra bit to know if it corresponds
to a "let"-like environment or not.
* runtime/WriteBarrier.h:
(JSC::WriteBarrierBase<Unknown>::get):
(JSC::WriteBarrierBase<Unknown>::clear):
(JSC::WriteBarrierBase<Unknown>::setUndefined):
(JSC::WriteBarrierBase<Unknown>::setStartingValue):
(JSC::WriteBarrierBase<Unknown>::isNumber):
(JSC::WriteBarrierBase<Unknown>::isObject):
(JSC::WriteBarrierBase<Unknown>::isNull):
* tests/stress/activation-sink-default-value-tdz-error.js: Added.
(shouldThrowTDZ):
(bar):
(foo.cap):
* tests/stress/activation-sink-osrexit-default-value-tdz-error.js: Added.
(shouldThrowTDZ):
(bar):
* tests/stress/lexical-let-and-with-statement.js: Added.
(truth):
(assert):
(.):
* tests/stress/lexical-let-exception-handling.js: Added.
(truth):
(assert):
(.):
* tests/stress/lexical-let-global-not-captured-variables.js: Added.
(truth):
(assert):
(foo):
(.let.capY):
* tests/stress/lexical-let-loop-semantics.js: Added.
(truth):
(assert):
(shouldThrowTDZ):
(.):
* tests/stress/lexical-let-not-strict-mode.js: Added.
(truth):
(assert):
(shouldThrowTDZ):
(.):
* tests/stress/lexical-let-semantics.js: Added.
(truth):
(assert):
(let.globalFunction):
(let.retGlobalNumberCaptured):
(let.setGlobalNumberCaptured):
(.):
* tests/stress/lexical-let-tdz.js: Added.
(truth):
(assert):
(shouldThrowTDZ):
(.):
2015-07-15 Anders Carlsson <andersca@apple.com>
Make JavaScriptCore SPI headers used by WebCore SPI headers self-contained
https://bugs.webkit.org/show_bug.cgi?id=146978
Reviewed by Dan Bernstein.
* debugger/DebuggerPrimitives.h:
* disassembler/Disassembler.h:
* heap/Weak.h:
* inspector/InspectorValues.h:
* runtime/JSCJSValue.h:
2015-07-14 Anders Carlsson <andersca@apple.com>
Assertions.h should include ExportMacros.h
https://bugs.webkit.org/show_bug.cgi?id=146948
Reviewed by Tim Horton.
Remove now unneeded WTF_EXPORT_PRIVATE define.
* API/JSBase.h:
2015-07-14 Matthew Mirman <mmirman@apple.com>
Repatch. Makes compileArithSub in the DFG ensure that the constant is an int32.
https://bugs.webkit.org/show_bug.cgi?id=146910
rdar://problem/21729083
Reviewed by Filip Pizlo.
Also fixes the debug build problem where all edges are assumed to
have UntypedUse before the fixup phase.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithSub):
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::validateEdgeWithDoubleResultIfNecessary):
* tests/stress/arith-add-with-constants.js: Added some tests for this case.
(arithAdd42WrittenAsInteger):
(testArithAdd42WrittenAsInteger):
(arithSub42WrittenAsDouble):
(testArithSub42WrittenAsDouble):
(doubleConstant):
(testDoubleConstant): Added test for the case of +0.0 and Math.min(0.0)
(arithAdd42WrittenAsDouble): Deleted.
(testArithAdd42WrittenAsDouble): Deleted.
2015-07-14 Matthew Mirman <mmirman@apple.com>
Unreviewed, rolling out r186805.
Made raytracer on octane 80% slower
Reverted changeset:
"Makes compileArithSub in the DFG ensure that the constant is
an int32."
https://bugs.webkit.org/show_bug.cgi?id=146910
http://trac.webkit.org/changeset/186805
2015-07-13 Matthew Mirman <mmirman@apple.com>
Makes compileArithSub in the DFG ensure that the constant is an int32.
https://bugs.webkit.org/show_bug.cgi?id=146910
rdar://problem/21729083
Reviewed by Filip Pizlo.
Also fixes the debug build problem where all edges are assumed to
have UntypedUse before the fixup phase.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithSub):
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::validateEdgeWithDoubleResultIfNecessary):
* tests/stress/arith-add-with-constants.js: Added some tests for this case.
(arithAdd42WrittenAsInteger):
(testArithAdd42WrittenAsInteger):
(arithSub42WrittenAsDouble):
(testArithSub42WrittenAsDouble):
(doubleConstant):
(testDoubleConstant): Added test for the case of +0.0 and Math.min(0.0)
(arithAdd42WrittenAsDouble): Deleted.
(testArithAdd42WrittenAsDouble): Deleted.
2015-07-13 Basile Clement <basile_clement@apple.com>
Object cycles should not prevent allocation elimination/sinking
https://bugs.webkit.org/show_bug.cgi?id=143073
Reviewed by Filip Pizlo.
This patch introduces a new allocation sinking phase that is able to
sink cycles, in DFGAllocationCycleSinkingPhase.cpp. This phase
supersedes the old allocation sinking phase in
DFGObjectAllocationSinkingPhase.cpp, as that previous phase was never
able to sink allocation cycles while the new phase sometimes can; see
DFGAllocationCycleSinkingPhase.cpp for details.
For now, the new sinking phase is kept behind a
JSC_enableAllocationCycleSinking flag that reverts to the old sinking
phase when false (i.e., by default). This also removes the old
JSC_enableObjectAllocationSinking flag. run-javascriptcore-tests
defaults to using the new sinking phase.
* dfg/DFGGraph.h:
(JSC::DFG::Graph::addStructureSet): Allow empty structure sets
* dfg/DFGLazyNode.cpp:
(JSC::DFG::LazyNode::dump): Prettier dump
* dfg/DFGNode.h:
(JSC::DFG::Node::cellOperand): Move to opInfo for MaterializeCreateActivation
(JSC::DFG::Node::hasStructureSet): Add MaterializeNewObject
(JSC::DFG::Node::objectMaterializationData): Move to opInfo2
* dfg/DFGOSRAvailabilityAnalysisPhase.cpp: Remove unused header
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::ObjectAllocationSinkingPhase::ObjectAllocationSinkingPhase): Deleted.
(JSC::DFG::ObjectAllocationSinkingPhase::run): Deleted.
(JSC::DFG::ObjectAllocationSinkingPhase::performSinking): Deleted.
(JSC::DFG::ObjectAllocationSinkingPhase::determineMaterializationPoints): Deleted.
(JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints): Deleted.
(JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations): Deleted.
(JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields): Deleted.
(JSC::DFG::ObjectAllocationSinkingPhase::resolve): Deleted.
(JSC::DFG::ObjectAllocationSinkingPhase::handleNode): Deleted.
(JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize): Deleted.
(JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize): Deleted.
* dfg/DFGObjectAllocationSinkingPhase.h:
* dfg/DFGPromotedHeapLocation.h: Add a hash and a helper function to PromotedLocationDescriptor
(JSC::DFG::PromotedLocationDescriptor::PromotedLocationDescriptor):
(JSC::DFG::PromotedLocationDescriptor::operator bool):
(JSC::DFG::PromotedLocationDescriptor::neededForMaterialization):
(JSC::DFG::PromotedLocationDescriptorHash::hash):
(JSC::DFG::PromotedLocationDescriptorHash::equal):
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::validateSSA): Assert that most nodes never see a phantom allocation
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileMaterializeNewObject): Use the new structureSet() operand
(JSC::FTL::DFG::LowerDFGToLLVM::compileMaterializeCreateActivation): Node has a new child
* ftl/FTLOSRExitCompiler.cpp: Handle materialization cycles
(JSC::FTL::compileStub):
* ftl/FTLOperations.cpp: Handle materialization cycles
(JSC::FTL::operationPopulateObjectInOSR):
(JSC::FTL::operationMaterializeObjectInOSR):
* ftl/FTLOperations.h: Handle materialization cycles
* tests/stress/correctly-sink-object-even-though-it-dies.js: Added.
(clobber):
(foo):
* tests/stress/eliminate-object-read-over-call.js: Added.
(clobber):
(foo):
* tests/stress/materialize-object-on-edge.js: Added.
(call):
(foo):
* tests/stress/object-sinking-stress.js: Added.
(foo):
* tests/stress/sink-object-cycle.js: Added.
(clobber):
(foo):
* tests/stress/sink-object-past-put.js: Added.
(clobber):
(foo):
* tests/stress/sinkable-new-object-in-loop.js: Added.
(foo):
2015-07-13 Daniel Bates <dabates@apple.com>
Cleanup: Avoid extraneous increment and decrement of reference count of ScriptArguments in ConsoleClient
https://bugs.webkit.org/show_bug.cgi?id=146920
Reviewed by Brian Burg.
Remove local variable RefPtr<ScriptArguments> and copy constructor call with an argument that
was initialized with an rvalue reference. The argument itself is an lvalue reference.
* runtime/ConsoleClient.cpp:
(JSC::ConsoleClient::printConsoleMessageWithArguments):
(JSC::ConsoleClient::internalMessageWithTypeAndLevel):
2015-07-13 Anders Carlsson <andersca@apple.com>
Apps linked with a deployment target of iOS 7.x or earlier crash when using modern WebKit API
https://bugs.webkit.org/show_bug.cgi?id=146913
rdar://problem/21789252
Reviewed by Dan Bernstein.
Make a top-level symlink from /System/Library/PrivateFrameworks/JavaScriptCore.framework to
/System/Library/Frameworks/JavaScriptCore.framework.
* JavaScriptCore.xcodeproj/project.pbxproj:
2015-07-12 Filip Pizlo <fpizlo@apple.com>
If Watchpoint::fire() looks at the state of the world, it should definitely see its set invalidated, and maybe it should see the object of interest in the transitioned-to state
https://bugs.webkit.org/show_bug.cgi?id=146897
Reviewed by Mark Lam.
The idea is to eventually support adaptive watchpoints. An adaptive watchpoint will be
able to watch for a condition that is more fine-grained than any one watchpoint set. For
example, we might watch a singleton object to see if it ever acquires a property called
"foo". So long as it doesn't have such a property, we don't want to invalidate any code.
But if it gets that property, then we should deoptimize. Current watchpoints will
invalidate code as soon as any property is added (or deleted), because they will use the
transition watchpoint set of the singleton object's structure, and that fires anytime
there is any transition.
An adaptive watchpoint would remember the singleton object, and when it got fired, it
would check if the object's new structure has the property "foo". If not, it would check
if the object's new structure is watchable (i.e. has a valid transition watchpoint set).
If the property is missing and the structure is watchable, it would add itself to the
watchpoint set of the new structure. Otherwise, it would deoptimize.
There are two problems with this idea, and this patch fixes these problems. First, we
usually fire the transition watchpoint before we do the structure transition. This means
that if the fire() method looked at the singleton object's structure, it would see the old
structure, not the new one. It would have no way of knowing what the new structure is.
Second, inside the fire() method, the watchpoint set being invalidated still appears
valid, since we change the state after we fire all watchpoints.
This patch addresses both issues. Now, in the most important case (addPropertyTransition),
we fire the watchpoint set after we have modified the object. This is accomplished using
a deferral scope called DeferredStructureTransitionWatchpointFire. In cases where there is
no deferral, the adaptive watchpoint will conservatively resort to deoptimization because
it would find that the singleton object's structure is no longer watchable. This is
because in the absence of deferral, the singleton object would still have the original
structure, but that structure's watchpoint set would now report itself as having been
invalidated.
* bytecode/Watchpoint.cpp:
(JSC::WatchpointSet::fireAllSlow): Change the state of the set before firing all watchpoints.
(JSC::WatchpointSet::fireAllWatchpoints):
* runtime/JSObject.h:
(JSC::JSObject::putDirectInternal): Use the deferral scope.
* runtime/Structure.cpp:
(JSC::Structure::Structure): Pass the deferral scope to didTransitionFromThisStructure.
(JSC::Structure::addPropertyTransition): Pass the deferral scope to create().
(JSC::StructureFireDetail::dump): This is no longer anonymous.
(JSC::DeferredStructureTransitionWatchpointFire::DeferredStructureTransitionWatchpointFire): Start with a null structure.
(JSC::DeferredStructureTransitionWatchpointFire::~DeferredStructureTransitionWatchpointFire): Fire the watchpoint if there is a structure.
(JSC::DeferredStructureTransitionWatchpointFire::add): Add a structure. Logically this is a list of deferred things, but we assert that there only will be one (happens to be true now).
(JSC::Structure::didTransitionFromThisStructure): Defer the watchpoint firing if there is a deferral scope.
* runtime/Structure.h:
(JSC::StructureFireDetail::StructureFireDetail): Move this to the header.
* runtime/StructureInlines.h:
(JSC::Structure::create): Pass the deferral scope to the constructor.
2015-07-12 Filip Pizlo <fpizlo@apple.com>
Watchpoints should be removed from their owning WatchpointSet before they are fired
https://bugs.webkit.org/show_bug.cgi?id=146895
Reviewed by Sam Weinig.
This simplifies the WatchpointSet API by making it so that when Watchpoint::fire() is
called, the Watchpoint is no longer in the set. This means that you don't have to remember
to remove it from the set's list (currently we do that implicitly as part of whatever
any particular Watchpoint::fireInternal() does), and you can now write adaptive
watchpoints that re-add themselves to a different set if they determine that the thing
they are actually watching is still intact but now needs to be watched in a different way
(like watching for whether some singleton object has a property of some name).
* bytecode/Watchpoint.cpp:
(JSC::Watchpoint::~Watchpoint): Add a comment about why this is necessary.
(JSC::Watchpoint::fire): Make this out-of-line, private, and make it assert that we're no longer on the list.
(JSC::WatchpointSet::fireAllWatchpoints): Make this remove the watchpoint from the list before firing it.
* bytecode/Watchpoint.h:
(JSC::Watchpoint::fire): Deleted. I moved this to Watchpoint.cpp.
2015-07-10 Filip Pizlo <fpizlo@apple.com>
DFG::DesiredWatchpoints should accept WatchpointSetType's that aren't necessarily pointers
https://bugs.webkit.org/show_bug.cgi?id=146875
Reviewed by Dan Bernstein.
In the future we'll want to add a desired watchpoint set that's something like "please
watch property 'Foo' for 'deletion' on structure 'S1'", so that the "set type" is struct
like "struct MySet { StringImpl* property; Mode mode; Structure* structure };".
This is a very mechanical change for now - all of the current users happen to use sets
that are pointer typed, so it's just a matter of moving some "*"'s around.
* dfg/DFGDesiredWatchpoints.h:
(JSC::DFG::GenericSetAdaptor::add):
(JSC::DFG::GenericSetAdaptor::hasBeenInvalidated):
(JSC::DFG::GenericDesiredWatchpoints::GenericDesiredWatchpoints):
(JSC::DFG::GenericDesiredWatchpoints::addLazily):
(JSC::DFG::GenericDesiredWatchpoints::reallyAdd):
(JSC::DFG::GenericDesiredWatchpoints::areStillValid):
(JSC::DFG::GenericDesiredWatchpoints::isWatched):
(JSC::DFG::DesiredWatchpoints::isWatched):
2015-07-10 Filip Pizlo <fpizlo@apple.com>
Watchpoints should be allocated with FastMalloc
https://bugs.webkit.org/show_bug.cgi?id=146874
Reviewed by Dan Bernstein.
This is in preparation for adding new subclasses of Watchpoint. While starting to do this
I realized that the way Watchpoints allocated themselves was unusual.
* bytecode/CodeBlockJettisoningWatchpoint.h:
(JSC::CodeBlockJettisoningWatchpoint::CodeBlockJettisoningWatchpoint): No need for the default constructor.
* bytecode/Watchpoint.h:
(JSC::Watchpoint::Watchpoint): This should be noncopyable and fast-allocated.
* dfg/DFGCommonData.h: Use a Bag<> instead of SegmentedVector<>. Bag means "malloc things but allow me to free them all at once", which is what we are doing here.
* dfg/DFGDesiredWatchpoints.h:
(JSC::DFG::GenericDesiredWatchpoints::reallyAdd): Use the Bag<> API rather than the very awkward SegmentedVector<> API.
2015-07-10 Filip Pizlo <fpizlo@apple.com>
AI folding of IsObjectOrNull is broken for non-object types that may be null
https://bugs.webkit.org/show_bug.cgi?id=146867
Reviewed by Ryosuke Niwa.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Fix the bug and add some text describing what is going on.
* tests/stress/misc-is-object-or-null.js: Added. Test for the bug.
(foo):
* tests/stress/other-is-object-or-null.js: Added. Test for a bug I almost introduced.
(foo):
2015-07-10 Filip Pizlo <fpizlo@apple.com>
It should be easy to measure total compile times.
https://bugs.webkit.org/show_bug.cgi?id=146857
Reviewed by Sam Weinig.
This gives DFG::Plan the ability to track total compile times, and return them in a map
of stats that jsc.cpp can display.
I want to do some work to bring down DFG compile times. This will help me measure whether
I'm making a difference or not.
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::Plan):
(JSC::DFG::Plan::~Plan):
(JSC::DFG::Plan::computeCompileTimes):
(JSC::DFG::Plan::reportCompileTimes):
(JSC::DFG::Plan::compileInThread):
(JSC::DFG::Plan::compileInThreadImpl):
(JSC::DFG::Plan::cancel):
(JSC::DFG::Plan::compileTimeStats):
(JSC::DFG::dumpAndVerifyGraph): Deleted.
(JSC::DFG::profilerCompilationKindForMode): Deleted.
* dfg/DFGPlan.h:
(JSC::DFG::Plan::compileTimeStats):
* jsc.cpp:
(jscmain):
* runtime/Options.h:
2015-07-04 Filip Pizlo <fpizlo@apple.com>
DFG fragile frozen values are fundamentally broken
https://bugs.webkit.org/show_bug.cgi?id=146602
Reviewed by Mark Lam.
This change gets rid of the FragileValue value strength, because it was fundamentally
broken.
FragileValue was a value known to the compiler but not tracked by the GC in any way -
it wasn't marked and it wasn't weak. This was used to support AI bootstrap for OSR
must-handle values. The philosophy was that if the compiler did use the value for
optimization, it would have been strengthened to a weak value (or maybe even a strong
value, though we probably won't do that). But this was too much of a pipe dream. I've
found at least one case where the compiler did use the value, but never strengthened
it: it would happen if the value ended up in an OSR entry data expected value. Then if
we GCed, we might have killed the value, but OSR entry would still try to use it for
validation. That might have sort of just worked, but it's clearly shady.
The reason why we made must-handle values fragile and not weak is that most of the time
the values disappear from the abstract state: they are LUBed to a non-constant. If we
kept them around as weak, we'd have too many cases of the GC killing the code because
it thought that the value was somehow meaningful to the code when it was only used as a
temporary artifact of optimization.
So, it's true that it's very important for must-handle values not to automatically be
weak or strong. It's also true that the values are necessary for AI bootstrap because
we need to know what values OSR entry will require. But we shouldn't accomplish these
goals by having the compiler hold onto what are essentially dangling pointers.
This implements a better solution: instead of having InPlaceAbstractState bootstrap the
AI with must-handle values at the beginning, we now widen the valuesAtHead of the
must-handle block after AI converges. This widening is done in CFAPhase. This allows us
to see if the must-handle values are necessary at all. In most cases, the widening
takes a non-constant abstract value and simply amends something to its type based on
the type of the must-handle value, and so the must-handle value never actually shows up
in either the IR or any abstract value. In the unlikely event that the value at head is
bottom, we freeze the must-handle value. This change removes FragileValue, and this
freezing uses WeakValue as the strength. That makes sense: since the abstract value was
bottom, the must-handle value becomes integral to the IR and so it makes no sense for
the GC to keep the resulting CodeBlock alive if that must-handle value dies. This will
sometimes happen for example if you have a very long-running loop whose pre-header
allocates some object, but that pre-header appears to always exit to the optimizing JIT
because it was only profiled once in the LLInt and that profiling appears insufficient
to the DFG. In that case, we'll effectively constant-fold the references to the object
inside the loop, which is both efficient (yay constant folding!) and necessary
(otherwise we wouldn't know what the type of the variable should have been).
Testing and debugging this is complicated. So, this adds some new capabilities:
- DFG IR dumps also dump all of the FrozenValues that point to the heap along with
their strengths, so that it's easy to see what GC objects the DFG feels are necessary
for the compilation.
- DFG OSR entry preparation prints out the OSR entry data structures, so that it's easy
to see what GC pointers (and other things) are used for OSR entry validation. The
printouts are quite detailed, and should also help other kinds of OSR entry
debugging.
- DFG::Plan now validates whether all of the GC pointers planted in the various JITCode
data structures are also properly registered as either weak or strong pointers in the
CodeBlock. This validation check previously failed due to fragile values ending up in
the OSR entry data structures, both in the newly added test (dead-osr-entry-value.js)
and in some pre-existing tests (like earley-boyer and 3d-raytrace).
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::stronglyVisitStrongReferences):
* bytecode/CodeOrigin.cpp:
(JSC::InlineCallFrame::visitAggregate):
* bytecode/Operands.h:
(JSC::Operands::operand):
(JSC::Operands::hasOperand):
* bytecode/StructureSet.cpp:
(JSC::StructureSet::dump):
(JSC::StructureSet::validateReferences):
* bytecode/StructureSet.h:
* bytecode/TrackedReferences.cpp: Added.
(JSC::TrackedReferences::TrackedReferences):
(JSC::TrackedReferences::~TrackedReferences):
(JSC::TrackedReferences::add):
(JSC::TrackedReferences::check):
(JSC::TrackedReferences::dump):
* bytecode/TrackedReferences.h: Added.
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::observeTransitions):
(JSC::DFG::AbstractValue::set):
(JSC::DFG::AbstractValue::fixTypeForRepresentation):
(JSC::DFG::AbstractValue::mergeOSREntryValue):
(JSC::DFG::AbstractValue::filter):
(JSC::DFG::AbstractValue::dumpInContext):
(JSC::DFG::AbstractValue::validateReferences):
(JSC::DFG::AbstractValue::setOSREntryValue): Deleted.
* dfg/DFGAbstractValue.h:
(JSC::DFG::AbstractValue::fullTop):
(JSC::DFG::AbstractValue::merge):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGCFAPhase.cpp:
(JSC::DFG::CFAPhase::run):
* dfg/DFGCommonData.cpp:
(JSC::DFG::CommonData::invalidate):
(JSC::DFG::CommonData::validateReferences):
* dfg/DFGCommonData.h:
(JSC::DFG::CommonData::requiredRegisterCountForExecutionAndExit):
* dfg/DFGFrozenValue.h:
(JSC::DFG::FrozenValue::FrozenValue):
(JSC::DFG::FrozenValue::strengthenTo):
(JSC::DFG::FrozenValue::pointsToHeap):
(JSC::DFG::FrozenValue::strength):
(JSC::DFG::FrozenValue::freeze):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::Graph):
(JSC::DFG::Graph::dump):
(JSC::DFG::Graph::registerFrozenValues):
(JSC::DFG::Graph::visitChildren):
(JSC::DFG::Graph::freeze):
(JSC::DFG::Graph::freezeStrong):
(JSC::DFG::Graph::freezeFragile): Deleted.
* dfg/DFGGraph.h:
* dfg/DFGInPlaceAbstractState.cpp:
(JSC::DFG::InPlaceAbstractState::initialize):
* dfg/DFGJITCode.cpp:
(JSC::DFG::JITCode::setOptimizationThresholdBasedOnCompilationResult):
(JSC::DFG::JITCode::validateReferences):
* dfg/DFGJITCode.h:
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::addressOfDoubleConstant):
(JSC::DFG::JITCompiler::noticeOSREntry):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::branchStructurePtr):
(JSC::DFG::JITCompiler::jitCode):
(JSC::DFG::JITCompiler::noticeOSREntry): Deleted.
* dfg/DFGMinifiedGraph.cpp: Added.
(JSC::DFG::MinifiedGraph::prepareAndShrink):
(JSC::DFG::MinifiedGraph::validateReferences):
* dfg/DFGMinifiedGraph.h:
(JSC::DFG::MinifiedGraph::append):
(JSC::DFG::MinifiedGraph::prepareAndShrink): Deleted.
* dfg/DFGOSREntry.cpp:
(JSC::DFG::OSREntryData::dumpInContext):
(JSC::DFG::OSREntryData::dump):
(JSC::DFG::prepareOSREntry):
* dfg/DFGOSREntry.h:
(JSC::DFG::getOSREntryDataBytecodeIndex):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::linkOSREntries):
(JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
* dfg/DFGStructureAbstractValue.cpp:
(JSC::DFG::StructureAbstractValue::dump):
(JSC::DFG::StructureAbstractValue::validateReferences):
* dfg/DFGStructureAbstractValue.h:
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::validate):
* dfg/DFGValueStrength.cpp:
(WTF::printInternal):
* dfg/DFGValueStrength.h:
(JSC::DFG::merge):
* ftl/FTLExitPropertyValue.cpp:
(JSC::FTL::ExitPropertyValue::dump):
(JSC::FTL::ExitPropertyValue::validateReferences):
* ftl/FTLExitPropertyValue.h:
* ftl/FTLExitTimeObjectMaterialization.cpp:
(JSC::FTL::ExitTimeObjectMaterialization::dump):
(JSC::FTL::ExitTimeObjectMaterialization::validateReferences):
* ftl/FTLExitTimeObjectMaterialization.h:
* ftl/FTLExitValue.cpp:
(JSC::FTL::ExitValue::dump):
(JSC::FTL::ExitValue::validateReferences):
* ftl/FTLExitValue.h:
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::dfgCommon):
(JSC::FTL::JITCode::validateReferences):
* ftl/FTLJITCode.h:
(JSC::FTL::JITCode::handles):
(JSC::FTL::JITCode::dataSections):
* ftl/FTLOSRExit.cpp:
(JSC::FTL::OSRExit::codeLocationForRepatch):
(JSC::FTL::OSRExit::validateReferences):
* ftl/FTLOSRExit.h:
(JSC::FTL::OSRExit::considerAddingAsFrequentExitSite):
* jit/JITCode.cpp:
(JSC::JITCode::typeName):
(JSC::JITCode::validateReferences):
(JSC::JITCode::execute):
* jit/JITCode.h:
(JSC::JITCode::start):
* tests/stress/dead-osr-entry-value.js: Added.
(foo):
2015-07-09 Filip Pizlo <fpizlo@apple.com>
It should be possible to run the OSR exit fuzzer
https://bugs.webkit.org/show_bug.cgi?id=146814
Reviewed by Mark Lam.
Fix a silly bug: the option matching was accidentally allowing a prefix match, which
always did the wrong thing for --fireOSRExitFuzzAt and --fireOSRExitFuzzAtStatic. Make
this an exact match instead.
* runtime/Options.cpp:
(JSC::Options::setOption):
2015-07-09 Mark Lam <mark.lam@apple.com>
SymbolTable::entryFor() should do a bounds check before indexing into the localToEntry vector.
https://bugs.webkit.org/show_bug.cgi?id=146807
Reviewed by Filip Pizlo.
When we capture an argument by name and we use "arguments", we put all of the
arguments into the scope. But destructured arguments are put into the scope
anonymously i.e. the SymbolTable knows that the scope offset is in use via
SymbolTable::m_maxScopeOffset, but that ScopeOffset won't appear in
SymbolTable::m_map.
The SymbolTable's m_localToEntry vector is synthesized from its m_map, and will
have a size which is based on the largest ScopeOffset in the m_map. If we have a
scenario where the anonymous argument is at a higher ScopeOffset than all the
named arguments, then the m_localsToEntry vector will not have an entry for it
i.e. the m_localsToEntry vector will have a size that is <= the ScopeOffset of
the anonymous argument.
Hence, SymbolTable::entryFor() should ensure that the requested ScopeOffset is
within the bounds of the m_localToEntry vector before indexing into it.
* runtime/SymbolTable.cpp:
(JSC::SymbolTable::entryFor):
2015-07-09 Michael Saboff <msaboff@apple.com>
REGRESSION (r180248): Repro Crash: com.apple.WebKit.WebContent at com.apple.JavaScriptCore: JSC::createRangeError + 20
https://bugs.webkit.org/show_bug.cgi?id=146767
Reviewed by Geoffrey Garen.
If the stack check fails at the top most frame, we must use that frame to
generate the exception. Reverted the code to always use the current frame to
throw an out of stack exception.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
2015-07-03 Filip Pizlo <fpizlo@apple.com>
OSR exit fuzzing should allow us to select a static exit site
https://bugs.webkit.org/show_bug.cgi?id=146601
Reviewed by Geoffrey Garen.
The original implementation of the fuzzer allows us to trigger an exit based on its index
in the dynamic sequence of exit sites encountered. But there are usually millions of
dynamically encountered exit sites, even if the program only has thousands of static exit
sites. That means that we would at best be able to do a random sampling of exits, and
those would be biased to the hottest exit sites.
This change allows us to also select exit sites based on their index in the static
sequence of exit sites that the compiler compiled. Then, once that static exit site is
selected, we can select which dynamic exit at that exit site we should trigger. Since the
number of static exit sites is usually smallish (it's bounded by program size), we can do
an exhaustive search over all exit sites in most programs.
* dfg/DFGOSRExitFuzz.cpp:
(JSC::numberOfStaticOSRExitFuzzChecks):
(JSC::numberOfOSRExitFuzzChecks):
* dfg/DFGOSRExitFuzz.h:
(JSC::DFG::doOSRExitFuzzing):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitOSRExitFuzzCheck):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
* jsc.cpp:
(jscmain):
* runtime/Options.h:
* runtime/TestRunnerUtils.h:
2015-07-08 Joseph Pecoraro <pecoraro@apple.com>
Fix grammar issue in TypeError attempting to change an unconfigurable property
https://bugs.webkit.org/show_bug.cgi?id=146774
Reviewed by Brent Fulgham.
* runtime/JSFunction.cpp:
(JSC::JSFunction::defineOwnProperty):
* runtime/JSObject.cpp:
(JSC::JSObject::defineOwnNonIndexProperty):
* runtime/StringObject.cpp:
(JSC::StringObject::defineOwnProperty):
2015-07-06 Csaba Osztrogonác <ossy@webkit.org>
Remove the unused HeapBlock.h
https://bugs.webkit.org/show_bug.cgi?id=146580
Reviewed by Andreas Kling.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/CopiedBlock.h:
* heap/CopiedSpace.h:
* heap/CopiedSpaceInlines.h:
* heap/HandleBlock.h:
* heap/HeapBlock.h: Removed.
* heap/MarkedBlock.h:
2015-07-06 Saam barati <saambarati1@gmail.com>
JSC's parser should follow the ES6 spec with respect to parsing Declarations
https://bugs.webkit.org/show_bug.cgi?id=146621
Reviewed by Mark Lam.
There were a few locations where JSC would allow declaration statements
in incorrect ways. JSC didn't distinguish between 'Statement' and
'StatementListItem' grammar productions. The relevant grammar is here:
http://www.ecma-international.org/ecma-262/6.0/index.html#sec-statements
From the ECMA Script 6.0 spec:
1. Section 13.6 The if Statement (http://www.ecma-international.org/ecma-262/6.0/index.html#sec-if-statement)
says that IfStatements only takes Statements for the "then-else" clauses, not StatementListItems.
(Same with 'while/for/do-while' loop bodies).
2. Section 13 ECMAScript Language: Statements and Declarations
(http://www.ecma-international.org/ecma-262/6.0/index.html#sec-ecmascript-language-statements-and-declarations)
defines the syntax of Statements, and they do not include ClassDeclarations and LexicalDeclarations
(const, let, see 13.3.1 Let and Const Declarations).
Declarations can only be in the “then-else” clauses when embedded in a StatementListItem in a BlockStatement (see 13.2).
Hence, the following style of declarations are no longer allowed:
'if/for/while (condition) const x = 40;'
'if/for/while (condition) class C { }'
Instead, we mandate such declaration constructs are within a StatementList
(which is the production that JSC's Parser::parseSourceElements function parses):
'if/for/while (condition) { const x = 40; }'
'if/for/while (condition) { class C { } }'
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseSourceElements):
(JSC::Parser<LexerType>::parseStatementListItem):
(JSC::Parser<LexerType>::parseVarDeclaration):
(JSC::Parser<LexerType>::parseStatement):
(JSC::Parser<LexerType>::parseExpressionStatement):
* parser/Parser.h:
(JSC::Parser::getLabel):
2015-07-06 Alex Christensen <achristensen@webkit.org>
Unreviewed debug build fix after r186358.
* runtime/JSArray.cpp:
(JSC::JSArray::fastConcatWith):
Pass vm parameter to fastConcatType.
2015-07-06 Ryosuke Niwa <rniwa@webkit.org>
Array.concat should be fast for integer or double arrays
https://bugs.webkit.org/show_bug.cgi?id=146260
Reviewed by Darin Adler.
Added a fast path to Array.prototype.concat. When concatenating two Int32, Double, or Contiguous
arrays, simply memcopy the arrays into a new uninitialized buffer.
This improves huffman encoding in CompressionBench by 3.7x on a Mid 2014 MacBookPro.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncConcat):
* runtime/JSArray.cpp:
(JSC::JSArray::fastConcatWith): Added.
* runtime/JSArray.h:
(JSC::JSArray::fastConcatType): Added. Returns the resultant array's indexing type if we can use
the fact path. Returns NonArray otherwise.
2015-07-06 Youenn Fablet <youenn.fablet@crf.canon.fr>
[Streams API] Remove ReadableStream custom constructor
https://bugs.webkit.org/show_bug.cgi?id=146547
Reviewed by Darin Adler.
Adding helper function to throw range errors.
* runtime/Error.h:
(JSC::throwRangeError):
(JSC::throwVMRangeError):
2015-07-05 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement the latest Promise spec in JS
https://bugs.webkit.org/show_bug.cgi?id=146229
Reviewed by Sam Weinig.
Updated the Promise implementation to meet to the ES6 spec.
This patch
1. Implement ES6 Promise and related abstract operations in builtins JS
2. Expose @enqueueJob private function to JS world to post the microtask
Updated implementation has one-on-one correspondence to the ES6 spec description.
And keep the JSPromiseDeferred because it is the interface used from the WebCore.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/Array.prototype.js:
(reduce):
(reduceRight):
(every):
(forEach):
(filter):
(map):
(some):
(fill):
(find):
(findIndex):
(includes):
(copyWithin):
ToInteger / ToLength are renamed to toInteger and toLength.
* builtins/ArrayConstructor.js:
(from):
ToInteger / ToLength are renamed to toInteger and toLength.
* builtins/GlobalObject.js:
(toInteger):
(toLength):
(isObject):
(ToInteger): Deleted.
(ToLength): Deleted.
ToInteger / ToLength are renamed to toInteger and toLength.
Add new abstract operation, isObject.
* builtins/Operations.Promise.js: Added.
(isPromise):
(newPromiseReaction):
(newPromiseDeferred):
(newPromiseCapability.executor):
(newPromiseCapability):
(triggerPromiseReactions):
(rejectPromise):
(fulfillPromise):
(createResolvingFunctions.resolve):
(createResolvingFunctions.reject):
(createResolvingFunctions):
(promiseReactionJob):
(promiseResolveThenableJob):
(initializePromise):
Added Promise related abstract operations.
* builtins/Promise.prototype.js:
(catch):
(.onFulfilled):
(.onRejected):
(then):
Promise#then implementation in JS.
* builtins/PromiseConstructor.js: Added.
(all.newResolveElement):
(all):
(race):
(reject):
(resolve):
Promise static functions implementations in JS.
* builtins/StringConstructor.js:
(raw):
ToInteger / ToLength are renamed to toInteger and toLength.
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::getInternalProperties):
* runtime/CommonIdentifiers.h:
* runtime/JSGlobalObject.cpp:
(JSC::enqueueJob):
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::initializePromiseFunction):
(JSC::JSGlobalObject::newPromiseDeferredFunction):
* runtime/JSJob.cpp: Renamed from Source/JavaScriptCore/runtime/JSPromiseReaction.h.
(JSC::createJSJob):
(JSC::JSJobMicrotask::run):
* runtime/JSJob.h: Renamed from Source/JavaScriptCore/runtime/JSPromiseFunctions.h.
* runtime/JSPromise.cpp:
(JSC::JSPromise::create):
(JSC::JSPromise::JSPromise):
(JSC::JSPromise::finishCreation):
(JSC::JSPromise::result):
(JSC::JSPromise::destroy): Deleted.
(JSC::JSPromise::visitChildren): Deleted.
(JSC::JSPromise::reject): Deleted.
(JSC::JSPromise::resolve): Deleted.
(JSC::JSPromise::appendResolveReaction): Deleted.
(JSC::JSPromise::appendRejectReaction): Deleted.
(JSC::triggerPromiseReactions): Deleted.
* runtime/JSPromise.h:
(JSC::JSPromise::status): Deleted.
(JSC::JSPromise::result): Deleted.
(JSC::JSPromise::constructor): Deleted.
* runtime/JSPromiseConstructor.cpp:
(JSC::constructPromise):
(JSC::JSPromiseConstructorFuncResolve): Deleted.
(JSC::JSPromiseConstructorFuncReject): Deleted.
(JSC::performPromiseRaceLoop): Deleted.
(JSC::JSPromiseConstructorFuncRace): Deleted.
(JSC::performPromiseAll): Deleted.
(JSC::JSPromiseConstructorFuncAll): Deleted.
* runtime/JSPromiseDeferred.cpp:
(JSC::JSPromiseDeferred::create):
(JSC::createJSPromiseDeferredFromConstructor): Deleted.
(JSC::updateDeferredFromPotentialThenable): Deleted.
(JSC::performDeferredResolve): Deleted.
(JSC::performDeferredReject): Deleted.
(JSC::abruptRejection): Deleted.
* runtime/JSPromiseDeferred.h:
* runtime/JSPromiseFunctions.cpp: Removed.
(JSC::deferredConstructionFunction): Deleted.
(JSC::createDeferredConstructionFunction): Deleted.
(JSC::identifyFunction): Deleted.
(JSC::createIdentifyFunction): Deleted.
(JSC::promiseAllCountdownFunction): Deleted.
(JSC::createPromiseAllCountdownFunction): Deleted.
(JSC::promiseResolutionHandlerFunction): Deleted.
(JSC::createPromiseResolutionHandlerFunction): Deleted.
(JSC::rejectPromiseFunction): Deleted.
(JSC::createRejectPromiseFunction): Deleted.
(JSC::resolvePromiseFunction): Deleted.
(JSC::createResolvePromiseFunction): Deleted.
(JSC::throwerFunction): Deleted.
(JSC::createThrowerFunction): Deleted.
* runtime/JSPromisePrototype.cpp:
(JSC::JSPromisePrototypeFuncThen): Deleted.
* runtime/JSPromiseReaction.cpp: Removed.
(JSC::createExecutePromiseReactionMicrotask): Deleted.
(JSC::ExecutePromiseReactionMicrotask::run): Deleted.
(JSC::JSPromiseReaction::create): Deleted.
(JSC::JSPromiseReaction::JSPromiseReaction): Deleted.
(JSC::JSPromiseReaction::finishCreation): Deleted.
(JSC::JSPromiseReaction::visitChildren): Deleted.
* runtime/VM.cpp:
(JSC::VM::VM): Deleted.
* runtime/VM.h:
2015-07-04 Chris Dumez <cdumez@apple.com>
Drop RefPtr::clear() method
https://bugs.webkit.org/show_bug.cgi?id=146556
Reviewed by Brady Eidson.
Drop RefPtr::clear() method in favor of "= nullptr;" pattern.
2015-07-03 Dan Bernstein <mitz@apple.com>
Just give up on -Wunreachable-code in JavaScriptCore.
* Configurations/Base.xcconfig:
* llint/LowLevelInterpreter.cpp:
(JSC::CLoop::execute):
2015-07-03 Dan Bernstein <mitz@apple.com>
Fixed the LLINT CLoop build.
* llint/LowLevelInterpreter.cpp:
(JSC::CLoop::execute):
2015-07-03 Dan Bernstein <mitz@apple.com>
[Xcode] Update some build settings as recommended by Xcode 7
https://bugs.webkit.org/show_bug.cgi?id=146597
Reviewed by Sam Weinig.
* Configurations/Base.xcconfig: Enabled CLANG_WARN_UNREACHABLE_CODE and
GCC_NO_COMMON_BLOCKS. Removed GCC_MODEL_TUNING.
* JavaScriptCore.xcodeproj/project.pbxproj: Updated LastUpgradeCheck.
* dfg/DFGGraph.h: Tweaked the definition of DFG_CRASH to suppress unreachable code warnings.
2015-07-03 Yusuke Suzuki <utatane.tea@gmail.com>
Relax builtin JS restriction about try-catch
https://bugs.webkit.org/show_bug.cgi?id=146555
Reviewed by Sam Weinig.
When retrieving the captured variables from the full activated scope,
it swapped the given vector with the stored declared variables vector.
This is because retrieving the captured variables are executed in the
last sequence of the parser, so declared variables are no longer used.
However, in builtins functions case, after retrieving the captured
variables, we check the variables by using declared variables vector.
So at that time, the declared variables vector becomes empty and it
raises assertion failures when the builtins function contains the full
activated scope. try-catch's catch scope requires the upper scope full
activated, so JS code in the builtins cannot use the try-catch.
This patch relaxes this restriction. When retrieving the captured
variables from the scope, just copy to the given vector.
* parser/Parser.h:
(JSC::Scope::getCapturedVariables):
2015-07-02 Filip Pizlo <fpizlo@apple.com>
DFG and FTL should have an OSR exit fuzzer
https://bugs.webkit.org/show_bug.cgi?id=146562
Reviewed by Benjamin Poulain.
Adds a basic OSR exit fuzzer to JSC. This isn't hooked into any test harnesses yet, but I
spot-checked it on v8-earley-boyer.js and so far found no bugs. I'd like to figure out how
to harness this after I land it.
Since it's turned off by default, it should have no effect on behavior.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGOSRExitFuzz.cpp: Added.
(JSC::numberOfOSRExitFuzzChecks):
* dfg/DFGOSRExitFuzz.h: Added.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitGetArgumentStart):
(JSC::DFG::SpeculativeJIT::emitOSRExitFuzzCheck):
(JSC::DFG::SpeculativeJIT::speculationCheck):
* dfg/DFGSpeculativeJIT.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
* jsc.cpp:
(jscmain):
* runtime/Options.h:
* runtime/TestRunnerUtils.h:
2015-07-02 Saam barati <saambarati1@gmail.com>
Rename "Deconstruction" to "Destructuring" throughout JSC
https://bugs.webkit.org/show_bug.cgi?id=146100
Reviewed by Mark Lam.
It is good to use the same naming conventions as the ES6
spec because it is the de facto way of speaking about these
language features. This also has the benefit of improving JSC's
hackability because it improves code readability for newcomers
to JSC or newcomers to this part of the code base.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeNextParameter):
(JSC::BytecodeGenerator::visibleNameForParameter):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::registerFor):
* bytecompiler/NodesCodegen.cpp:
(JSC::ForInNode::tryGetBoundLocal):
(JSC::ForInNode::emitLoopHeader):
(JSC::ForOfNode::emitBytecode):
(JSC::ClassExprNode::emitBytecode):
(JSC::DestructuringAssignmentNode::emitBytecode):
(JSC::DestructuringPatternNode::~DestructuringPatternNode):
(JSC::ArrayPatternNode::collectBoundIdentifiers):
(JSC::DeconstructingAssignmentNode::emitBytecode): Deleted.
(JSC::DeconstructionPatternNode::~DeconstructionPatternNode): Deleted.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createElementList):
(JSC::ASTBuilder::createFormalParameterList):
(JSC::ASTBuilder::createClause):
(JSC::ASTBuilder::createClauseList):
(JSC::ASTBuilder::createForInLoop):
(JSC::ASTBuilder::createForOfLoop):
(JSC::ASTBuilder::isBindingNode):
(JSC::ASTBuilder::isResolve):
(JSC::ASTBuilder::createDestructuringAssignment):
(JSC::ASTBuilder::createArrayPattern):
(JSC::ASTBuilder::appendArrayPatternSkipEntry):
(JSC::ASTBuilder::appendArrayPatternEntry):
(JSC::ASTBuilder::appendArrayPatternRestEntry):
(JSC::ASTBuilder::createObjectPattern):
(JSC::ASTBuilder::appendObjectPatternEntry):
(JSC::ASTBuilder::createDeconstructingAssignment): Deleted.
* parser/NodeConstructors.h:
(JSC::TryNode::TryNode):
(JSC::ParameterNode::ParameterNode):
(JSC::ForOfNode::ForOfNode):
(JSC::DestructuringPatternNode::DestructuringPatternNode):
(JSC::ArrayPatternNode::ArrayPatternNode):
(JSC::ArrayPatternNode::create):
(JSC::ObjectPatternNode::ObjectPatternNode):
(JSC::BindingNode::create):
(JSC::BindingNode::BindingNode):
(JSC::DestructuringAssignmentNode::DestructuringAssignmentNode):
(JSC::DeconstructionPatternNode::DeconstructionPatternNode): Deleted.
(JSC::DeconstructingAssignmentNode::DeconstructingAssignmentNode): Deleted.
* parser/Nodes.cpp:
(JSC::FunctionParameters::create):
* parser/Nodes.h:
(JSC::ExpressionNode::isResolveNode):
(JSC::ExpressionNode::isBracketAccessorNode):
(JSC::ExpressionNode::isDotAccessorNode):
(JSC::ExpressionNode::isDestructuringNode):
(JSC::ExpressionNode::isFuncExprNode):
(JSC::ExpressionNode::isCommaNode):
(JSC::ExpressionNode::isSimpleArray):
(JSC::ParameterNode::pattern):
(JSC::ParameterNode::nextParam):
(JSC::FunctionParameters::size):
(JSC::FunctionParameters::at):
(JSC::FunctionParameters::patterns):
(JSC::DestructuringPatternNode::isBindingNode):
(JSC::DestructuringPatternNode::emitDirectBinding):
(JSC::ArrayPatternNode::appendIndex):
(JSC::ObjectPatternNode::appendEntry):
(JSC::BindingNode::boundProperty):
(JSC::DestructuringAssignmentNode::bindings):
(JSC::ExpressionNode::isDeconstructionNode): Deleted.
(JSC::DeconstructionPatternNode::isBindingNode): Deleted.
(JSC::DeconstructionPatternNode::emitDirectBinding): Deleted.
(JSC::DeconstructingAssignmentNode::bindings): Deleted.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseVarDeclaration):
(JSC::Parser<LexerType>::parseWhileStatement):
(JSC::Parser<LexerType>::parseVarDeclarationList):
(JSC::Parser<LexerType>::createBindingPattern):
(JSC::Parser<LexerType>::tryParseDestructuringPatternExpression):
(JSC::Parser<LexerType>::parseDestructuringPattern):
(JSC::Parser<LexerType>::parseDefaultValueForDestructuringPattern):
(JSC::Parser<LexerType>::parseForStatement):
(JSC::Parser<LexerType>::parseFormalParameters):
(JSC::Parser<LexerType>::parseFunctionParameters):
(JSC::Parser<LexerType>::parseAssignmentExpression):
(JSC::Parser<LexerType>::tryParseDeconstructionPatternExpression): Deleted.
(JSC::Parser<LexerType>::parseDeconstructionPattern): Deleted.
(JSC::Parser<LexerType>::parseDefaultValueForDeconstructionPattern): Deleted.
* parser/Parser.h:
(JSC::isEvalNode):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createPropertyList):
(JSC::SyntaxChecker::createElementList):
(JSC::SyntaxChecker::createFormalParameterList):
(JSC::SyntaxChecker::createClause):
(JSC::SyntaxChecker::createClauseList):
(JSC::SyntaxChecker::operatorStackPop):
* tests/stress/reserved-word-with-escape.js:
* tests/stress/rest-elements.js:
2015-07-02 Mark Lam <mark.lam@apple.com>
Build fix for Win EWS bot.
https://bugs.webkit.org/show_bug.cgi?id=146551
Not reviewed.
* tools/JSDollarVMPrototype.cpp:
(JSC::functionCrash):
2015-07-02 Dan Bernstein <mitz@apple.com>
<rdar://problem/21429613> [iOS] Stop making symlinks from PrivateFrameworks to Frameworks
https://bugs.webkit.org/show_bug.cgi?id=146542
Reviewed by Sam Weinig.
* JavaScriptCore.xcodeproj/project.pbxproj: Removed the build phase that makes the symlink.
2015-07-01 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Aggregate profile call information on the backend to drastically reduce profile sizes
https://bugs.webkit.org/show_bug.cgi?id=146536
Reviewed by Timothy Hatcher.
* inspector/protocol/Timeline.json:
Change a CPUProfile from sending a required "calls" param to sending a required
"callInfo" param which includes aggregated information about the calls.
2015-06-30 Filip Pizlo <fpizlo@apple.com>
DFG::freezeFragile should register the frozen value's structure
https://bugs.webkit.org/show_bug.cgi?id=136055
rdar://problem/21042120
Reviewed by Mark Lam and Geoffrey Garen.
This fixes weird concurrency bugs where the constant folding phase tries to convert
something to a constant but then crashes because the constant's structure wasn't
registered. The AI was registering the structure of any value it saw, but constant folding
wasn't - and that's fine so long as there ain't no concurrency.
The best fix is to just make it impossible to introduce a constant into the IR without
registering its structure. That's what this change does. This is not only a great
concurrency fix - it also makes the compiler somewhat easier to hack on because it's one
less case of structure registering that you have to remember about.
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::setOSREntryValue): No need to register.
(JSC::DFG::AbstractValue::set): We still call register, but just to get the watchpoint state.
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::freezeFragile): Register the structure.
* dfg/DFGStructureRegistrationPhase.cpp:
(JSC::DFG::StructureRegistrationPhase::run): Assert that these are all registered.
2015-07-01 Matthew Mirman <mmirman@apple.com>
Unreviewed, rolling out r185889
https://bugs.webkit.org/show_bug.cgi?id=146528
rdar://problem/21573959
Patch breaks chromeexperiments.com
Reverted changeset:
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* inspector/InjectedScriptSource.js:
(.):
* runtime/JSBoundSlotBaseFunction.cpp: Removed.
* runtime/JSBoundSlotBaseFunction.h: Removed.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init): Deleted.
(JSC::JSGlobalObject::visitChildren): Deleted.
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::boundSlotBaseFunctionStructure): Deleted.
* runtime/JSObject.cpp:
(JSC::JSObject::getOwnPropertyDescriptor):
(JSC::getBoundSlotBaseFunctionForGetterSetter): Deleted.
* runtime/VM.cpp:
(JSC::VM::VM): Deleted.
* runtime/VM.h:
2015-07-01 Dean Jackson <dino@apple.com>
Disable the experimental WebGL2 implementation
https://bugs.webkit.org/show_bug.cgi?id=146526
<rdar://problem/21641235>
Reviewed by Myles Maxfield.
Add (and disable) an ENABLE_WEBGL2 flag.
* Configurations/FeatureDefines.xcconfig:
2015-07-01 Matthew Daiter <mdaiter@apple.com>
Enable MEDIA_STREAM flag
https://bugs.webkit.org/show_bug.cgi?id=145947
<rdar://problem/21365829>
Reviewed by Eric Carlson.
* Configurations/FeatureDefines.xcconfig: Added MEDIA_STREAM flag
2015-06-30 Andy VanWagoner <thetalecrafter@gmail.com>
Implement ECMAScript Internationalization API
https://bugs.webkit.org/show_bug.cgi?id=90906
Reviewed by Benjamin Poulain.
* CMakeLists.txt: add IntlObject.cpp
* Configurations/FeatureDefines.xcconfig: add ENABLE_INTL flag
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: add IntlObject
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: add IntlObject
* JavaScriptCore.xcodeproj/project.pbxproj: add IntlObject
* runtime/CommonIdentifiers.h: add "Intl" name
* runtime/IntlObject.cpp: Added.
(JSC::IntlObject::IntlObject):
(JSC::IntlObject::create):
(JSC::IntlObject::finishCreation):
(JSC::IntlObject::createStructure):
* runtime/IntlObject.h: Added.
* runtime/JSGlobalObject.cpp: Add global Intl
(JSC::JSGlobalObject::init):
2015-06-30 Basile Clement <basile_clement@apple.com>
Allow object allocation sinking through GetScope, GetExecutable and SkipScope nodes
https://bugs.webkit.org/show_bug.cgi?id=146431
Reviewed by Filip Pizlo.
* dfg/DFGNode.h:
(JSC::DFG::Node::isFunctionAllocation):
(JSC::DFG::Node::isPhantomFunctionAllocation):
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
* dfg/DFGPromoteHeapAccess.h:
(JSC::DFG::promoteHeapAccess):
2015-06-30 Matt Baker <mattbaker@apple.com>
Web Inspector: Reduce rendering frames "Other" time by instrumenting compositing
https://bugs.webkit.org/show_bug.cgi?id=146168
Reviewed by Brian Burg.
* inspector/protocol/Timeline.json:
New timeline record type for compositing events.
2015-06-29 Dean Jackson <dino@apple.com>
Temporarily disable PICTURE_SIZES
https://bugs.webkit.org/show_bug.cgi?id=146435
<rdar://problem/21087013>
Reviewed by Tim Horton.
Temporarily disable PICTURE_SIZES because it causes problems with out
of date <picture> polyfills.
* Configurations/FeatureDefines.xcconfig:
2015-06-29 Youenn Fablet <youenn.fablet@crf.canon.fr>
Binding generator should allow using JSC::Value for "any" parameter in lieu of ScriptValue
https://bugs.webkit.org/show_bug.cgi?id=146403
Reviewed by Darin Adler.
* bindings/ScriptValue.h: Added implicit conversion to JSC::JSValue.
2015-06-28 Aleksandr Skachkov <gskachkov@gmail.com>
[ES6] Implement ES6 arrow function syntax. No Line terminator between function parameters and =>
https://bugs.webkit.org/show_bug.cgi?id=146394
Reviewed by Yusuke Suzuki.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionInfo):
2015-06-27 Darin Adler <darin@apple.com>
Make converting JSString to StringView idiomatically safe
https://bugs.webkit.org/show_bug.cgi?id=146387
Reviewed by Anders Carlsson.
* jsc.cpp:
(functionPrint): Add explicit call to SafeView::get, needed since there
is no StringView temporary.
(functionDebug): Ditto.
* runtime/ArrayPrototype.cpp:
(JSC::holesMustForwardToPrototype): Refactored into helper function.
(JSC::join): Refactored so that StringView is a function argument, making
the lifetime simpler.
(JSC::arrayProtoFuncJoin): Ditto.
(JSC::arrayProtoFuncReverse): Use new holesMustForwardToPrototype helper.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::encode): Add explicit call to SafeView::get.
* runtime/JSString.h: Moved declarations of functions to the top of the
file instead of mixing them in with the function definitions. Changed
return type of the view function to return a JSString::SafeView so that
the JSString's lifetime will last as long as the StringView does in
typical coding idioms.
(JSC::JSString::getIndex): Use unsafeView so we can index into the
view; could also have used view.get but here in this class this seems fine.
(JSC::JSRopeString::unsafeView): Renamed existing view function to this.
(JSC::JSString::unsafeView): Ditto.
(JSC::JSString::SafeView::SafeView): Contains reference to an ExecState
and a JSString. The ExecState is needed to create the StringView, and the
JSString needs to be kept alive as long as the StringView is.
(JSC::JSString::SafeView::operator StringView): Call unsafeView.
(JSC::JSString::SafeView::get): Convenience for when we want to call
StringView member functions.
(JSC::JSString::view): Added. Returns a SafeView.
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncIndexOf): Add explicit call to SafeView::get.
2015-06-26 Csaba Osztrogonác <ossy@webkit.org>
Remove ARMv7Assembler.cpp
https://bugs.webkit.org/show_bug.cgi?id=146340
Reviewed by Filip Pizlo.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/ARMv7Assembler.cpp: Removed.
2015-06-26 Csaba Osztrogonác <ossy@webkit.org>
Fix the !ENABLE(ES6_ARROWFUNCTION_SYNTAX) build after r185989
https://bugs.webkit.org/show_bug.cgi?id=146344
Reviewed by Yusuke Suzuki.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseSourceElements):
2015-06-26 Aleksandr Skachkov <gskachkov@gmail.com>
[ES6] Implement ES6 arrow function syntax. Parser of arrow function with execution as common function.
https://bugs.webkit.org/show_bug.cgi?id=144955
Reviewed by Yusuke Suzuki.
Added support of ES6 arrow function. Changes were made according to following spec http://wiki.ecmascript.org/doku.php?id=harmony:arrow_function_syntax. Patch does not include any arrow function specific behavior e.g. lexical bind this, arguments and etc.
This patch implements the simplest cases of arrow function declaration:
parameters () => 10 + 20
parameter x => x + 20
parameters (x, y) => x + y
function with block x => { return x*10; }
Not implemented:
bind of the this, arguments, super and etc.
exception in case of trying to use 'new' with arrow function
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionExpr):
(JSC::ASTBuilder::createArrowFunctionExpr):
(JSC::ASTBuilder::createGetterOrSetterProperty):
(JSC::ASTBuilder::createFuncDeclStatement):
* parser/Lexer.cpp:
(JSC::Lexer<T>::setTokenPosition):
(JSC::Lexer<T>::lex):
* parser/Lexer.h:
(JSC::Lexer::lastTokenLocation):
(JSC::Lexer::setTerminator):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseSourceElements):
(JSC::Parser<LexerType>::parseArrowFunctionSingleExpressionBody):
(JSC::Parser<LexerType>::parseSwitchClauses):
(JSC::Parser<LexerType>::parseSwitchDefaultClause):
(JSC::Parser<LexerType>::parseBlockStatement):
(JSC::Parser<LexerType>::parseFunctionBody):
(JSC::stringForFunctionMode):
(JSC::Parser<LexerType>::parseFunctionParameters):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseAssignmentExpression):
(JSC::Parser<LexerType>::parsePropertyMethod):
(JSC::Parser<LexerType>::parseGetterSetter):
(JSC::Parser<LexerType>::parseArrowFunctionExpression):
* parser/Parser.h:
(JSC::Parser::locationBeforeLastToken):
(JSC::Parser::isEndOfArrowFunction):
(JSC::Parser::isArrowFunctionParamters):
(JSC::Parser::setEndOfStatement):
* parser/ParserFunctionInfo.h:
* parser/ParserTokens.h:
* parser/SourceCode.h:
(JSC::SourceCode::subArrowExpression):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::endFunctionToken):
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createArrowFunctionExpr):
(JSC::SyntaxChecker::setFunctionNameStart):
2015-06-25 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Support rest element in destructuring assignments
https://bugs.webkit.org/show_bug.cgi?id=146206
Reviewed by Oliver Hunt.
This patch enables rest element (...rest) in array binding patterns.
It generates array from the iterables.
In variable declarations and parameters, `[...identifier]` form is only allowed,
while expressions can take `[...[...rest]]` pattern.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitEnumeration):
(JSC::BytecodeGenerator::emitIteratorNext):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ArrayPatternNode::bindValue):
(JSC::ArrayPatternNode::toString):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::appendArrayPatternSkipEntry):
(JSC::ASTBuilder::appendArrayPatternEntry):
(JSC::ASTBuilder::appendArrayPatternRestEntry):
* parser/Nodes.h:
(JSC::ArrayPatternNode::appendIndex):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseDeconstructionPattern):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::operatorStackPop):
* tests/stress/rest-elements.js: Added.
(shouldBe):
(shouldThrow):
2015-06-25 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r185956.
https://bugs.webkit.org/show_bug.cgi?id=146321
Causes massive crashes on test bots (Requested by bfulgham on
#webkit).
Reverted changeset:
"Enabling MEDIA_STREAM"
https://bugs.webkit.org/show_bug.cgi?id=145947
http://trac.webkit.org/changeset/185956
2015-06-25 Michael Saboff <msaboff@apple.com>
Minor fix to idx bounds check after 185954
Rubber Stamped by Ryosuke Niwa.
Changed "idx > 1" to "idx > 0" in two places.
* runtime/ExceptionHelpers.cpp:
(JSC::functionCallBase):
2015-06-25 Keith Miller <keith_miller@apple.com>
Address Sanitizer does not play well with memcpy in JSC::MachineThreads::tryCopyOtherThreadStack.
https://bugs.webkit.org/show_bug.cgi?id=146297
Reviewed by Filip Pizlo.
Since we cannot blacklist the system memcpy we must use our own naive implementation,
copyMemory. This is not a significant performance loss as tryCopyOtherThreadStack is
only called as part of an O(heapsize) operation. As the heap is generally much larger
than the stack the performance hit is minimal.
* heap/MachineStackMarker.cpp:
(JSC::copyMemory):
(JSC::MachineThreads::tryCopyOtherThreadStack):
(JSC::asanUnsafeMemcpy): Deleted.
2015-06-25 Matthew Daiter <mdaiter@apple.com>
Enabling MEDIA_STREAM
https://bugs.webkit.org/show_bug.cgi?id=145947
<rdar://problem/21365829>
Reviewed by Brent Fulgham.
* Configurations/FeatureDefines.xcconfig:
2015-06-25 Michael Saboff <msaboff@apple.com>
REGRESSION (r181889): basspro.com hangs on load under JSC::ErrorInstance::finishCreation(JSC::ExecState*, JSC::VM&, WTF::String const&, bool) + 2801 (JavaScriptCore + 3560689)
https://bugs.webkit.org/show_bug.cgi?id=146298
Reviewed by Mark Lam.
We were underflowing in ExceptionHelpers.cpp::functionCallBase() with a right to left
string index. Added checks that idx stays within the string. Also added a termination
condition when idx is 0.
* runtime/ExceptionHelpers.cpp:
(JSC::functionCallBase):
2015-06-24 Chris Dumez <cdumez@apple.com>
Unreviewed, speculative build fix after r185942.
Add missing include for StrongInlines.h.
* runtime/ArrayPrototype.cpp:
2015-06-24 Darin Adler <darin@apple.com>
Optimize Array.join and Array.reverse for high speed array types
https://bugs.webkit.org/show_bug.cgi?id=146275
Reviewed by Mark Lam.
This seems to yield another 17% speed improvement in the array
test from the Peacekeeper benchmark.
* runtime/ArrayPrototype.cpp:
(JSC::isHole): Added. Helper to check for holes.
(JSC::containsHole): Ditto.
(JSC::arrayProtoFuncJoin): Added special cases for the various types
of arrays that could be in a butterfly.
(JSC::arrayProtoFuncReverse): Ditto.
* runtime/JSStringJoiner.h: Made appendEmptyString public so we can
call it from the new parts of Array.join.
2015-06-24 Filip Pizlo <fpizlo@apple.com>
DFG::SpeculativeJIT shouldn't use filter==Contradiction when it meant isClear
https://bugs.webkit.org/show_bug.cgi?id=146291
rdar://problem/21435366
Reviewed by Michael Saboff.
The filter() method returns Contradiction only when a value *becomes* clear. This is
necessary for supporting the convention that non-JSValue nodes have a bottom proved
type. (We should fix that convention eventually, but for now let's just be consistent
about it.)
* dfg/DFGFiltrationResult.h: Document the issue.
* dfg/DFGSpeculativeJIT32_64.cpp: Work around the issue.
(JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
(JSC::DFG::SpeculativeJIT::fillSpeculateCell):
(JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
* dfg/DFGSpeculativeJIT64.cpp: Work around the issue.
(JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
(JSC::DFG::SpeculativeJIT::fillSpeculateInt52):
(JSC::DFG::SpeculativeJIT::fillSpeculateCell):
(JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
2015-06-24 Michael Saboff <msaboff@apple.com>
Crash on gog.com due to PolymorphicCallNode's having stale references to CallLinkInfo
https://bugs.webkit.org/show_bug.cgi?id=146285
Reviewed by Filip Pizlo.
CallLinkInfo's contain a RefPtr to a PolymorphicCallStubRoutine, named stub, which contains
a collection of PolymorphicCallNode. Those PolymorphicCallNodes have a reference back to the
CallLinkInfo. When a CallLinkInfo replaces or clears "stub", the ref count of the
PolymorphicCallStubRoutine is decremented as expected, but since it inherits from
GCAwareJITStubRoutine, it isn't actually deleted until GC. In the mean time, the original
CallLinkInfo can go away. If PolymorphicCallNode::unlink() is called at that point,
it will try to unlink a now deleted CallLinkInfo and crash as a result.
The fix is to clear the CallLinkInfo references from any PolymorphicCallNode objects when
when we set a new stub or clear an existing stub for a CallLinkInfo. This is done by
calling PolymorphicCallNode::clearCallNodesFor() on the old stub.
The prior code would only call clearCallNodesFor() from the CallLinkInfo destructor.
This only took care of the last PolymorphicCallStubRoutine held in the CallLinkInfo.
Any prior PolymorphicCallStubRoutine would still have a, now bad, reference to the CallLinkInfo.
In the process I refactored CallLinkInfo from a struct to a class with proper accessors and
made all the data elements private.
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::clearStub): Updated to call PolymorphicCallStubRoutine::clearCallNodesFor()
to clear the back references to this CallLinkInfo.
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::~CallLinkInfo): Moved clearCallNodesFor() call to clearStub().
(JSC::CallLinkInfo::setStub): Clear any prior stub before changing to the new stub.
2015-06-24 Michael Saboff <msaboff@apple.com>
Refactor CallLinkInfo from a struct to a class
https://bugs.webkit.org/show_bug.cgi?id=146292
Rubber stamped by Filip Pizlo.
Refactored CallLinkInfo from a struct to a class with proper accessors and made all the
data elements private.
Done in preparation for fixing https://bugs.webkit.org/show_bug.cgi?id=146285.
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::clearStub):
(JSC::CallLinkInfo::unlink):
(JSC::CallLinkInfo::visitWeak):
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::callTypeFor):
(JSC::CallLinkInfo::CallLinkInfo):
(JSC::CallLinkInfo::~CallLinkInfo):
(JSC::CallLinkInfo::specializationKindFor):
(JSC::CallLinkInfo::specializationKind):
(JSC::CallLinkInfo::isLinked):
(JSC::CallLinkInfo::setUpCall):
(JSC::CallLinkInfo::setCallLocations):
(JSC::CallLinkInfo::setUpCallFromFTL):
(JSC::CallLinkInfo::callReturnLocation):
(JSC::CallLinkInfo::hotPathBegin):
(JSC::CallLinkInfo::hotPathOther):
(JSC::CallLinkInfo::setCallee):
(JSC::CallLinkInfo::clearCallee):
(JSC::CallLinkInfo::callee):
(JSC::CallLinkInfo::setLastSeenCallee):
(JSC::CallLinkInfo::clearLastSeenCallee):
(JSC::CallLinkInfo::lastSeenCallee):
(JSC::CallLinkInfo::haveLastSeenCallee):
(JSC::CallLinkInfo::setStub):
(JSC::CallLinkInfo::stub):
(JSC::CallLinkInfo::seenOnce):
(JSC::CallLinkInfo::clearSeen):
(JSC::CallLinkInfo::setSeen):
(JSC::CallLinkInfo::hasSeenClosure):
(JSC::CallLinkInfo::setHasSeenClosure):
(JSC::CallLinkInfo::clearedByGC):
(JSC::CallLinkInfo::setCallType):
(JSC::CallLinkInfo::callType):
(JSC::CallLinkInfo::addressOfMaxNumArguments):
(JSC::CallLinkInfo::maxNumArguments):
(JSC::CallLinkInfo::offsetOfSlowPathCount):
(JSC::CallLinkInfo::setCalleeGPR):
(JSC::CallLinkInfo::calleeGPR):
(JSC::CallLinkInfo::slowPathCount):
(JSC::CallLinkInfo::setCodeOrigin):
(JSC::CallLinkInfo::codeOrigin):
(JSC::getCallLinkInfoCodeOrigin):
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFor):
(JSC::CallLinkStatus::computeFromCallLinkInfo):
(JSC::CallLinkStatus::computeDFGStatuses):
* bytecode/CallLinkStatus.h:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::printCallOp):
(JSC::CodeBlock::getCallLinkInfoForBytecodeIndex):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* ftl/FTLJSCallBase.cpp:
(JSC::FTL::JSCallBase::link):
* jit/AccessorCallJITStubRoutine.h:
* jit/JIT.cpp:
(JSC::JIT::privateCompile):
* jit/JIT.h:
* jit/JITCall.cpp:
(JSC::JIT::compileSetupVarargsFrame):
(JSC::JIT::compileOpCall):
* jit/JITCall32_64.cpp:
(JSC::JIT::compileSetupVarargsFrame):
(JSC::JIT::compileOpCall):
* jit/JITOperations.cpp:
* jit/PolymorphicCallStubRoutine.cpp:
(JSC::PolymorphicCallNode::unlink):
(JSC::PolymorphicCallNode::clearCallLinkInfo):
* jit/PolymorphicCallStubRoutine.h:
* jit/Repatch.cpp:
(JSC::generateByIdStub):
(JSC::linkSlowFor):
(JSC::linkFor):
(JSC::revertCall):
(JSC::unlinkFor):
(JSC::linkPolymorphicCall):
* jit/ThunkGenerators.cpp:
(JSC::virtualForThunkGenerator):
2015-06-24 Doug Russell <d_russell@apple.com>
Bug 146177 - AX: AXObjectCache should try to use an unignored accessibilityObject
when posting a selection notification when on the border between two accessibilityObjects
https://bugs.webkit.org/show_bug.cgi?id=146177
Add an adopt() function to simplify JSRetainPtr<JSStringRef> { Adopt, string } to adopt(string).
Reviewed by Darin Adler.
* API/JSRetainPtr.h:
(adopt):
2015-06-24 Keith Miller <keith_miller@apple.com>
Strict Equality on objects should only check that one of the two sides is an object.
https://bugs.webkit.org/show_bug.cgi?id=145992
This patch adds a new optimization for checking strict equality on objects.
If we speculate that a strict equality comparison has an object on one side
we only need to type check that side. Equality is then determined by a pointer
comparison between the two values (although in the 32-bit case we must also check
that the other side is a cell). Once LICM hoists type checks out of a loop we
can be cleverer about how we choose the operand we type check if both are
speculated to be objects.
For testing I added the addressOf function, which returns the address
of a Cell to the runtime.
Reviewed by Mark Lam.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileStrictEq):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compileObjectStrictEquality):
(JSC::DFG::SpeculativeJIT::compilePeepHoleObjectStrictEquality):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compileObjectStrictEquality):
(JSC::DFG::SpeculativeJIT::compilePeepHoleObjectStrictEquality):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compileCompareStrictEq):
* jsc.cpp:
(GlobalObject::finishCreation):
(functionAddressOf):
* tests/stress/equality-type-checking.js: Added.
(Foo):
(checkStrictEq):
(checkStrictEqOther):
2015-06-24 Mark Lam <mark.lam@apple.com>
Fixed assertion in JSStringJoiner::join() (regression from r185899).
Not reviewed.
JSStringJoiner did not account for the case where the array being joined can
have null or undefined elements. As a result, its size may be less than
its initially reserved capacity (which was estimated based on the array length).
* runtime/JSStringJoiner.cpp:
(JSC::JSStringJoiner::join):
2015-06-24 Darin Adler <darin@apple.com>
Fix Array.concat with RuntimeArray (regression from my last patch)
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncConcat): Use getLength instead of JSArray::length.
* runtime/JSArray.cpp:
(JSC::JSArray::defineOwnProperty): Added comment about use of
JSArray::length here that is incorrect (in a really non-obvious way).
(JSC::JSArray::fillArgList): Ditto.
(JSC::JSArray::copyToArguments): Ditto.
* runtime/JSArray.h: Added a comment explaining that it is not always
safe to use JSArray::length.
2015-06-23 Mark Lam <mark.lam@apple.com>
Gardening: Fixing 2 bad asserts from r185889.
https://bugs.webkit.org/show_bug.cgi?id=140575
Not reviewed.
* runtime/JSBoundSlotBaseFunction.cpp:
(JSC::JSBoundSlotBaseFunction::finishCreation):
2015-06-23 Dan Bernstein <mitz@apple.com>
Fixed iOS production builds.
* JavaScriptCore.xcodeproj/project.pbxproj:
2015-06-22 Darin Adler <darin@apple.com>
Make Array.join work directly on substrings without reifying them
https://bugs.webkit.org/show_bug.cgi?id=146191
Reviewed by Andreas Kling.
Besides the Array.join change, this has other optimizations based on
profiling the Peacekeeper array benchmark.
I measured a 14% speed improvement in the Peacekeeper array benchmark.
Still a lot of low hanging fruit in that test because so many of functions
on the array prototype are not optimizing for simple cases. For example,
the reverse function does individual get and put calls even when the array
is entirely made up of integers in contiguous storage.
* runtime/ArrayPrototype.cpp:
(JSC::getProperty): Use tryGetIndexQuickly first before getPropertySlot.
(JSC::argumentClampedIndexFromStartOrEnd): Marked inline.
(JSC::shift): Use the getProperty helper in this file instead of using
getPropertySlot. Use putByIndexInline instead of calling putByIndex directly.
In both cases this can yield a faster code path.
(JSC::unshift): Ditto.
(JSC::arrayProtoFuncToString): Updated to use the new JSStringJoiner
interface. Changed local variable name to thisArray since it's not a
JSObject*. Changed loop index to i instead of k.
(JSC::arrayProtoFuncToLocaleString): Updated to use the new JSStringJoiner
interface. Renamed thisObj to thisObject. Added a missing exception check
after the toLocaleString function is called, but before toString is called
the result of that function.
(JSC::arrayProtoFuncJoin): Updated to use the new JSStringJointer interface.
Added a missing exception check after calling toString on the separator
but before calling get to get the first element in the array-like object
being joined. Changed loop index to i instead of k. Added missing exception
check after calling toString on each string from the array before calling
get for the next element.
(JSC::arrayProtoFuncConcat): Use JSArray::length instead of using the
getLength function.
(JSC::arrayProtoFuncReverse): Ditto. Also use putByIndexInline.
(JSC::arrayProtoFuncShift): Ditto.
(JSC::arrayProtoFuncSplice): Use getIndex instead of get, which includes some
additional optimizations.
(JSC::getOrHole): Deleted. Unused function.
(JSC::arrayProtoFuncUnShift): Use putByIndexInline.
* runtime/ExceptionHelpers.cpp:
(JSC::errorDescriptionForValue): Removed the duplicate copy of the the logic
from JSValue::toString.
* runtime/JSCJSValue.cpp:
(JSC::JSValue::toStringSlowCase): Improved the performance when converting a
small integer to a single character string.
(JSC::JSValue::toWTFStringSlowCase): Moved the contents of the
inlineJSValueNotStringtoString function here.
* runtime/JSCJSValue.h: Removed no longer used toWTFStringInline and fixed
a comment with a typo.
* runtime/JSObject.h:
(JSC::JSObject::putByIndexInline): Marked ALWAYS_INLINE because this was not
getting inlined at some call sites.
(JSC::JSObject::indexingData): Deleted. Unused function.
(JSC::JSObject::currentIndexingData): Deleted. Unused function.
(JSC::JSObject::getHolyIndexQuickly): Deleted. Unused function.
(JSC::JSObject::relevantLength): Deleted. Unused function.
(JSC::JSObject::currentRelevantLength): Deleted. Unused function.
* runtime/JSString.h: Added the StringViewWithUnderlyingString struct and
the viewWithUnderlyingString function. Removed the inlineJSValueNotStringtoString
and toWTFStringInline functions.
* runtime/JSStringJoiner.cpp:
(JSC::appendStringToData): Changed this to be a template instead of writing
it out, since StringView::getCharactersWithUpconvert does almsot exactly what
this function was trying to do.
(JSC::joinStrings): Rewrote this to use StringView.
(JSC::JSStringJoiner::joinedLength): Added. Factored out from the join function.
(JSC::JSStringJoiner::join): Rewrote to make it a bit simpler. Added an assertion
that we entirely filled capacity, since we are now reserving capacity and using
uncheckedAppend. Use String instead of RefPtr<StringImpl> because there was no
particular value to using the impl directly.
* runtime/JSStringJoiner.h: Changed the interface to the class to use StringView.
Also changed this class so it now has the responsibility to convert each JSValue
into a string. This let us share more code between toString and join, and also
lets us use the new viewWithUnderlyingString function, which could be confusing at
all the call sites, but is easier to understand here.
2015-06-23 Matthew Mirman <mmirman@apple.com>
Completes native binding descriptors with native getters and potentially setters.
https://bugs.webkit.org/show_bug.cgi?id=140575
rdar://problem/19506502
Reviewed by Mark Lam.
* CMakeLists.txt: Added JSBoundSlotBaseFunction.cpp
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* inspector/InjectedScriptSource.js: Added case for descriptor having a native getter.
* runtime/JSBoundSlotBaseFunction.cpp: Added.
(JSC::boundSlotBaseFunctionCall):
(JSC::JSBoundSlotBaseFunction::JSBoundSlotBaseFunction):
Necessary wrapper for custom getters and setters as objects.
(JSC::JSBoundSlotBaseFunction::create):
(JSC::JSBoundSlotBaseFunction::visitChildren):
(JSC::JSBoundSlotBaseFunction::finishCreation):
* runtime/JSBoundSlotBaseFunction.h: Added.
(JSC::JSBoundSlotBaseFunction::createStructure):
(JSC::JSBoundSlotBaseFunction::boundSlotBase):
(JSC::JSBoundSlotBaseFunction::customGetterSetter):
(JSC::JSBoundSlotBaseFunction::isGetter):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init): Added a globally initialized structure for JSBoundSlotBaseFunction
(JSC::JSGlobalObject::visitChildren): visits that structure
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::boundSlotBaseFunctionStructure): added a getter for that structure
* runtime/JSObject.cpp:
(JSC::JSObject::getOwnPropertyDescriptor): extends the case for CustomGetterSetter to
actually include GetterSetter as a JSBoundSlotBaseFunction
* runtime/VM.cpp: Added initializer for customGetterSetterFunctionMap
* runtime/VM.h: Added cache for JSBoundSlotBaseFunction
2015-06-22 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Allow trailing comma in ArrayBindingPattern and ObjectBindingPattern
https://bugs.webkit.org/show_bug.cgi?id=146192
Reviewed by Darin Adler.
According to the ES6 spec, trailing comma in ArrayBindingPattern and ObjectBindingPattern is allowed.
And empty ArrayBindingPattern and ObjectBindingPattern is also allowed.
This patch allows trailing comma and empty binding patterns.
* bytecompiler/NodesCodegen.cpp:
(JSC::ArrayPatternNode::bindValue):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseDeconstructionPattern):
* tests/stress/trailing-comma-in-patterns.js: Added.
(shouldBe):
(iterator):
2015-06-20 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Destructuring assignment need to accept iterables
https://bugs.webkit.org/show_bug.cgi?id=144111
Reviewed by Darin Adler.
This patch makes that destructuring assignments to array binding patterns accept iterables.
Previously, it just access the indexed properties.
After this patch, it iterates the given value by using ES6 iterator protocol.
The iteration becomes different from the for-of case.
1. Since there's no break/continue case, finally scope is not necessary.
2. When the error is raised, the close status of the iterator becomes true. So IteratorClose is not called for that.
3. Since the array binding patterns requires a limited count of iterations (if there is no rest(...rest) case), IteratorClose is called when the iteration does not consume the all values of the iterator.
4. Since the array binding patterns requires a specified count of iterations, iterator's next call is skipped when iterator becomes closed.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitIteratorClose):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ArrayPatternNode::bindValue):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::finishArrayPattern):
* parser/Nodes.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseDeconstructionPattern):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::operatorStackPop):
* tests/stress/destructuring-assignment-accepts-iterables.js: Added.
(shouldBe):
(shouldThrow):
(.set shouldThrow):
2015-06-19 Devin Rousso <drousso@apple.com>
Web Inspector: Highlight currently edited CSS selector
https://bugs.webkit.org/show_bug.cgi?id=145658
Reviewed by Joseph Pecoraro.
* inspector/protocol/DOM.json: Added highlightSelector to show highlight over multiple nodes.
2015-06-19 Mark Lam <mark.lam@apple.com>
Gardening: fix build for EWS bots.
Not reviewed.
* runtime/JSArray.cpp:
(JSC::JSArray::setLengthWithArrayStorage):
2015-06-19 Michael Saboff <msaboff@apple.com>
Crash in com.apple.WebKit.WebContent at com.apple.JavaScriptCore: JSC::FTL::fixFunctionBasedOnStackMaps + 17225
https://bugs.webkit.org/show_bug.cgi?id=146133
Reviewed by Geoffrey Garen.
When generating code to put in inline caching areas, if there isn't enough space,
then create and link to an out of line area. We connect the inline code to this
out of line code area by planting a jump from the inline area to the out of line
code and appending a jump at the end of the out of line code bck to the instruction
following the inline area. We fill the unused inline area with nops, primarily to
ensure the disassembler doesn't get confused.
* ftl/FTLCompile.cpp:
(generateInlineIfPossibleOutOfLineIfNot): New function that determines if there is enough space
in the inline code area for the code to link. If so, it links inline, otherwise it links the
code out of line and plants appropriate jumps to/from the out of line code.
(generateICFastPath):
(generateCheckInICFastPath):
(fixFunctionBasedOnStackMaps):
Use generateInlineIfPossibleOutOfLineIfNot() to link code intended for inline cache space.
* ftl/FTLJITFinalizer.cpp:
(JSC::FTL::JITFinalizer::finalizeFunction):
* ftl/FTLJITFinalizer.h:
(JSC::FTL::OutOfLineCodeInfo::OutOfLineCodeInfo):
Added code to finalize any out of line LinkBuffer created by generateInlineIfPossibleOutOfLineIfNot().
2015-06-19 Geoffrey Garen <ggaren@apple.com>
WebKit crash while loading nytimes at JavaScriptCore: JSC::ExecutableAllocator::allocate + 276
https://bugs.webkit.org/show_bug.cgi?id=146163
<rdar://problem/20392986>
Reviewed by Michael Saboff.
There's no good way to test this in our test harness because we don't
have a way to simulate executable memory pressure, and doing so would
cause the cases that still use JITCompilationMustSucceed to crash.
Instead, I tested by manually forcing all regexp JIT compilation to
fail and running the JavaScriptCore tests.
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::compile): Allow compilation to fail. We can
fall back to the regexp interpreter if we need to.
2015-06-19 Mark Lam <mark.lam@apple.com>
Employ explicit operator bool() instead of using the UnspecifiedBoolType workaround.
https://bugs.webkit.org/show_bug.cgi?id=146154
Reviewed by Darin Adler.
* assembler/MacroAssemblerCodeRef.h:
(JSC::MacroAssemblerCodePtr::dataLocation):
(JSC::MacroAssemblerCodePtr::operator bool):
(JSC::MacroAssemblerCodePtr::operator==):
(JSC::MacroAssemblerCodeRef::tryToDisassemble):
(JSC::MacroAssemblerCodeRef::operator bool):
(JSC::MacroAssemblerCodeRef::dump):
(JSC::MacroAssemblerCodePtr::operator UnspecifiedBoolType*): Deleted.
(JSC::MacroAssemblerCodeRef::operator UnspecifiedBoolType*): Deleted.
* bytecode/CodeOrigin.cpp:
(JSC::CodeOrigin::isApproximatelyEqualTo):
- Fixed a bug here where we were expecting to compare Executable pointers, but
ended up comparing a (UnspecifiedBoolType*)1 with another
(UnspecifiedBoolType*)1.
* bytecode/LLIntCallLinkInfo.h:
(JSC::LLIntCallLinkInfo::~LLIntCallLinkInfo):
(JSC::LLIntCallLinkInfo::isLinked):
(JSC::LLIntCallLinkInfo::unlink):
* dfg/DFGBlockWorklist.h:
(JSC::DFG::BlockWith::BlockWith):
(JSC::DFG::BlockWith::operator bool):
(JSC::DFG::BlockWithOrder::BlockWithOrder):
(JSC::DFG::BlockWithOrder::operator bool):
(JSC::DFG::BlockWith::operator UnspecifiedBoolType*): Deleted.
(JSC::DFG::BlockWithOrder::operator UnspecifiedBoolType*): Deleted.
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
* dfg/DFGLazyNode.h:
(JSC::DFG::LazyNode::operator!):
(JSC::DFG::LazyNode::operator bool):
(JSC::DFG::LazyNode::operator UnspecifiedBoolType*): Deleted.
* heap/CopyWriteBarrier.h:
(JSC::CopyWriteBarrier::operator!):
(JSC::CopyWriteBarrier::operator bool):
(JSC::CopyWriteBarrier::get):
(JSC::CopyWriteBarrier::operator UnspecifiedBoolType*): Deleted.
* heap/Handle.h:
(JSC::HandleBase::operator!):
(JSC::HandleBase::operator bool):
(JSC::HandleBase::slot):
(JSC::HandleBase::operator UnspecifiedBoolType*): Deleted.
* heap/Strong.h:
(JSC::Strong::operator!):
(JSC::Strong::operator bool):
(JSC::Strong::swap):
(JSC::Strong::operator UnspecifiedBoolType*): Deleted.
* jit/JITWriteBarrier.h:
(JSC::JITWriteBarrierBase::operator bool):
(JSC::JITWriteBarrierBase::operator!):
(JSC::JITWriteBarrierBase::setFlagOnBarrier):
(JSC::JITWriteBarrierBase::operator UnspecifiedBoolType*): Deleted.
* runtime/JSArray.cpp:
(JSC::JSArray::setLengthWithArrayStorage):
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::JSValue):
(JSC::JSValue::operator bool):
(JSC::JSValue::operator==):
(JSC::JSValue::operator UnspecifiedBoolType*): Deleted.
* runtime/JSObject.h:
(JSC::JSObject::hasSparseMap):
* runtime/PropertyDescriptor.h:
(JSC::PropertyDescriptor::writablePresent):
(JSC::PropertyDescriptor::enumerablePresent):
(JSC::PropertyDescriptor::configurablePresent):
(JSC::PropertyDescriptor::setterPresent):
(JSC::PropertyDescriptor::getterPresent):
* runtime/WriteBarrier.h:
(JSC::WriteBarrierBase::slot):
(JSC::WriteBarrierBase::operator bool):
(JSC::WriteBarrierBase::operator!):
(JSC::WriteBarrierBase<Unknown>::tagPointer):
(JSC::WriteBarrierBase<Unknown>::payloadPointer):
(JSC::WriteBarrierBase<Unknown>::operator bool):
(JSC::WriteBarrierBase<Unknown>::operator!):
(JSC::WriteBarrierBase::operator UnspecifiedBoolType*): Deleted.
(JSC::WriteBarrierBase<Unknown>::operator UnspecifiedBoolType*): Deleted.
2015-06-19 Anders Carlsson <andersca@apple.com>
Add a JSC symlink in /System/Library/PrivateFrameworks
https://bugs.webkit.org/show_bug.cgi?id=146158
rdar://problem/21465968
Reviewed by Dan Bernstein.
* JavaScriptCore.xcodeproj/project.pbxproj:
2015-06-19 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Avoid getOwnPropertyNames/Symbols on very large lists
https://bugs.webkit.org/show_bug.cgi?id=146141
Reviewed by Timothy Hatcher.
* inspector/InjectedScriptSource.js:
(InjectedScript.prototype._propertyDescriptors):
Avoid calling getOwnPropertyNames/Symbols on very large lists. Instead
just generate property descriptors for the first 100 indexes. Note
this would behave poorly for sparse arrays with a length > 100, but
general support for lists with more than 100 elements is poor. See:
<https://webkit.org/b/143589> Web Inspector: Better handling for large collections in Object Trees
2015-06-18 Yusuke Suzuki <utatane.tea@gmail.com>
[DFG] Avoid OSR exit in the middle of string concatenation
https://bugs.webkit.org/show_bug.cgi?id=145820
Reviewed by Filip Pizlo.
DFG attempt to compile ValueAdd with String type into MakeRope(left, ToString(ToPrimitive(right))).
So when right is speculated as SpecObject, ToPrimitive(SpecObject) is speculated as SpecString.
It leads ToString to become Identity with a speculated type check.
However, ToPrimitive and ToString are originated from the same bytecode. And ToPrimitive may have
an observable side effect when the given parameter is an object (calling object.{toString,valueOf}).
So when object.toString() returns a number (it is allowed in the ES spec), ToPrimitive performs
observable `object.toString()` calling. But ToString is converted into a speculated type check for
SpecString and it raises OSR exit. And we exit to the original ValueAdd's bytecode position and
it redundantly performs an observable ToPrimitive execution.
To fix this, this patch avoid fixing up for newly introduced ToString node.
Since fix up phase is not iterated repeatedly, by avoiding fixing up when generating the node,
we can avoid conversion from ToString to Check.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
* tests/stress/toprimitive-speculated-types.js: Added.
(shouldBe):
(raw):
(Counter):
2015-06-18 Brian J. Burg <burg@cs.washington.edu>
Web Inspector: improve generated types for objects passed to backend commands
https://bugs.webkit.org/show_bug.cgi?id=146091
Reviewed by Joseph Pecoraro.
The main change is that objects passed in will have a type like const T& or const T*,
rather than const RefPtr<T>&&. These protocol objects are owned by the generated dispatcher
methods and only exist to pass data to backend command implementations. So, there is no
reason for callees to add a reference or take ownership of these inputs.
Some small improvements were made in the code generator to standardize how these
expressions are generated for parameters. Optional in parameters are now prefixed with
'opt_in_' to make the generated method signatures and implementations clearer.
* inspector/InspectorValues.cpp:
(Inspector::InspectorArrayBase::get): Add const qualifier.
* inspector/InspectorValues.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
(Inspector::parseLocation):
(Inspector::InspectorDebuggerAgent::setBreakpoint):
(Inspector::InspectorDebuggerAgent::continueToLocation):
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::callFunctionOn):
(Inspector::InspectorRuntimeAgent::saveResult):
(Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
* inspector/agents/InspectorRuntimeAgent.h:
* inspector/scripts/codegen/cpp_generator.py: Always generate PrimitiveType('array').
(CppGenerator.cpp_type_for_unchecked_formal_in_parameter): Alter the type signature
for an unchecked input to use pointers or references.
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
(CppBackendDispatcherHeaderGenerator._generate_handler_declaration_for_command):
(CppBackendDispatcherHeaderGenerator._generate_async_handler_declaration_for_command):
Local variables for optional parameters now have the 'opt_' prefix.
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
(CppBackendDispatcherImplementationGenerator._generate_async_dispatcher_class_for_domain):
(CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
Local variables for optional parameters now have the 'opt_' prefix.
Split parameterName and parameterKey into two separate template variables to avoid mixups.
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
2015-06-18 Joseph Pecoraro <pecoraro@apple.com>
Unreviewed. Rollout r185670 as it caused some tests to be flakey.
* debugger/Debugger.cpp:
2015-06-17 Alex Christensen <achristensen@webkit.org>
[Content Extensions] Log blocked loads to the WebInspector console
https://bugs.webkit.org/show_bug.cgi?id=146089
Reviewed by Joseph Pecoraro.
* inspector/ConsoleMessage.cpp:
(Inspector::messageSourceValue):
* inspector/protocol/Console.json:
* runtime/ConsoleTypes.h:
Add content blocker message source.
2015-06-18 Saam Barati <saambarati1@gmail.com>
[ES6] support default values in deconstruction parameter nodes
https://bugs.webkit.org/show_bug.cgi?id=142679
Reviewed by Darin Adler.
ES6 destructuring allows destructuring properties to assign
default values. A link to the spec:
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-destructuring-binding-patterns
This patch implements default values for all places where deconstruction
is allowed besides function parameters. This is because function
parameters are parsed in a separate parser arena than the function
body itself and ExpresionNode's which are default values for
deconstruction parameters will be deallocated by the time we parse the body
of the function. I have opened a bug to address this problem:
https://bugs.webkit.org/show_bug.cgi?id=145995
* bytecompiler/NodesCodegen.cpp:
(JSC::DeconstructionPatternNode::~DeconstructionPatternNode):
(JSC::assignDefaultValueIfUndefined):
(JSC::ArrayPatternNode::bindValue):
(JSC::ArrayPatternNode::emitDirectBinding):
(JSC::ArrayPatternNode::toString):
(JSC::ArrayPatternNode::collectBoundIdentifiers):
(JSC::ObjectPatternNode::bindValue):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::appendArrayPatternSkipEntry):
(JSC::ASTBuilder::appendArrayPatternEntry):
(JSC::ASTBuilder::createObjectPattern):
(JSC::ASTBuilder::appendObjectPatternEntry):
(JSC::ASTBuilder::createBindingLocation):
* parser/Nodes.h:
(JSC::ArrayPatternNode::appendIndex):
(JSC::ObjectPatternNode::appendEntry):
(JSC::ObjectPatternNode::Entry::Entry): Deleted.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseDeconstructionPattern):
(JSC::Parser<LexerType>::parseDefaultValueForDeconstructionPattern):
(JSC::Parser<LexerType>::parseConstDeclarationList):
* parser/Parser.h:
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::operatorStackPop):
2015-06-17 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Do not show JavaScriptCore builtins in inspector
https://bugs.webkit.org/show_bug.cgi?id=146049
Reviewed by Timothy Hatcher.
* debugger/Debugger.cpp:
2015-06-17 Andreas Kling <akling@apple.com>
[JSC] jsSubstring() should have a fast path for 0..baseLength "substrings."
<https://webkit.org/b/146051>
Reviewed by Anders Carlsson.
If asked to make a substring that actually spans the entire base string,
have jsSubstring() just return the base instead of allocating a new JSString.
3% speed-up on Octane/regexp.
* runtime/JSString.h:
(JSC::jsSubstring):
2015-06-16 Alex Christensen <achristensen@webkit.org>
32-bit build fix after r185640.
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
Explicitly cast clamped int64_t to an int.
2015-06-09 Filip Pizlo <fpizlo@apple.com>
FTL should eliminate array bounds checks in loops
https://bugs.webkit.org/show_bug.cgi?id=145768
Reviewed by Benjamin Poulain.
This adds a phase that does forward propagation of integer inequalities. This allows us
to do the algebraic reasoning we need to eliminate array bounds checks in loops. It
also eliminates overflow checks on ArithAdd with a constant.
The phase's analysis produces results that are powerful enough to do speculative bounds
check hoisting, but this phase currently only does elimination. We can implement
hoisting later.
On programs that just loop over an array like:
for (var i = 0; i < array.length; ++i)
thingy += array[i]
This change is a 60% speed-up.
This is also a ~3% speed-up on Kraken, and it shows various speed-ups on individual
tests in Octane.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGIntegerRangeOptimizationPhase.cpp: Added.
(JSC::DFG::performIntegerRangeOptimization):
* dfg/DFGIntegerRangeOptimizationPhase.h: Added.
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* tests/stress/add-overflows-after-not-equal.js: Added.
* tests/stress/no-abc-skippy-loop.js: Added.
* tests/stress/no-abc-skippy-paired-loop.js: Added.
* tests/stress/sub-overflows-after-not-equal.js: Added.
2015-06-16 Andreas Kling <akling@apple.com>
Remove unused template parameter InlineCapacity from SegmentedVector.
<https://webkit.org/b/146044>
Reviewed by Anders Carlsson.
* bytecode/ArrayProfile.h:
* dfg/DFGCommonData.h:
2015-06-16 Michael Saboff <msaboff@apple.com>
Inlining in the DFG trashes ByteCodeParser::m_currentInstruction for the calling function
https://bugs.webkit.org/show_bug.cgi?id=146029
Reviewed by Benjamin Poulain.
Save and restore m_currentInstruction around call to ByteCodeParser::inlineCall() as it will
use m_currentInstruction during its own parsing. This happens because inlineCall() parses the
inlined callee's bytecodes by calling parseCodeBlock() which calls parseBlock() on each block.
It is in parseBlock() that we set m_currentInstruction to an instruction before we parse it.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::attemptToInlineCall):
(JSC::DFG::ByteCodeParser::parseBlock): Added an ASSERT to catch this issue.
2015-06-16 Filip Pizlo <fpizlo@apple.com>
Unreviewed, roll out unintended JSC change from https://trac.webkit.org/changeset/185425.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::hasExitSite):
(JSC::CodeBlock::exitProfile):
(JSC::CodeBlock::numberOfExitSites): Deleted.
* bytecode/DFGExitProfile.cpp:
(JSC::DFG::ExitProfile::add):
* bytecode/DFGExitProfile.h:
(JSC::DFG::ExitProfile::hasExitSite):
(JSC::DFG::ExitProfile::size): Deleted.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::inliningCost):
* runtime/Options.h:
2015-06-16 Mark Lam <mark.lam@apple.com>
Use NakedPtr<Exception>& to return exception results.
https://bugs.webkit.org/show_bug.cgi?id=145870
Reviewed by Anders Carlsson and Filip Pizlo.
Before r185259, calls into the VM takes a JSValue* exception result argument for
returning any uncaught exception that may have been thrown while executing JS code.
As a result, clients of the VM functions will declare a local JSValue exception
result which is automatically initialized to a null value (i.e. the empty value,
not the JS null value).
With r185259, the VM functions were changed to take an Exception*& exception result
instead, and the VM functions are responsible for initializing the exception result
to null if no exception is thrown.
This introduces 2 issues:
1. the VM functions are vulnerable to modifications that may add early returns
before the exception result is nullified. This can result in the exception
result being used without initialization.
2. Previously, a client could technically use the same exception result for more
than one calls into the VM functions. If an earlier call sets it to a thrown
value, the thrown value will stick unless a subsequent call throws a different
exception.
With the new Exception*& exception result, the VM functions will always clear
the exception result before proceeding. As a result, the client's exception
result will be null after the second call even though the first call saw an
exception thrown. This is a change in the expected behavior.
To fix these issues, we'll introduce a NakedPtr smart pointer whose sole purpose
is to guarantee that the pointer is initialized. The VM functions will now take
a NakedPtr<Exception>& instead of the Exception*&. This ensures that the
exception result is initialized.
The VM functions be also reverted to only set the exception result if a new
exception is thrown.
* API/JSBase.cpp:
(JSEvaluateScript):
* API/JSScriptRef.cpp:
* bindings/ScriptFunctionCall.cpp:
(Deprecated::ScriptFunctionCall::call):
* bindings/ScriptFunctionCall.h:
* debugger/Debugger.cpp:
(JSC::Debugger::hasBreakpoint):
* debugger/Debugger.h:
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::thisValue):
(JSC::DebuggerCallFrame::evaluate):
* debugger/DebuggerCallFrame.h:
(JSC::DebuggerCallFrame::isValid):
* inspector/InjectedScriptManager.cpp:
(Inspector::InjectedScriptManager::createInjectedScript):
* inspector/InspectorEnvironment.h:
* inspector/JSJavaScriptCallFrame.cpp:
(Inspector::JSJavaScriptCallFrame::evaluate):
* inspector/JavaScriptCallFrame.h:
(Inspector::JavaScriptCallFrame::vmEntryGlobalObject):
(Inspector::JavaScriptCallFrame::thisValue):
(Inspector::JavaScriptCallFrame::evaluate):
* inspector/ScriptDebugServer.cpp:
(Inspector::ScriptDebugServer::evaluateBreakpointAction):
* jsc.cpp:
(functionRun):
(functionLoad):
(runWithScripts):
(runInteractive):
* runtime/CallData.cpp:
(JSC::call):
* runtime/CallData.h:
* runtime/Completion.cpp:
(JSC::checkSyntax):
(JSC::evaluate):
* runtime/Completion.h:
(JSC::evaluate):
2015-06-15 Filip Pizlo <fpizlo@apple.com>
FTL boolify() UntypedUse is wrong in the masquerades-as-undefined case
https://bugs.webkit.org/show_bug.cgi?id=146002
Reviewed by Darin Adler.
* ftl/FTLLowerDFGToLLVM.cpp: Put this in an anonymous namespace. We should have done that all along. It makes it easier to add debug code.
(JSC::FTL::DFG::LowerDFGToLLVM::boolify): Fix the bug.
* tests/stress/logical-not-masquerades.js: Added. This test creates a masquerader so that the watchpoint is invalid. Previously this would fail for the normal object cases.
(foo):
2015-06-16 Andreas Kling <akling@apple.com>
[JSC] Pre-bake final Structure for RegExp matches arrays.
<https://webkit.org/b/146006>
Reviewed by Darin Adler.
Since we always add the "index" and "input" fields to RegExp matches arrays,
cache a finished structure on the global object so we can create these arrays without
starting from scratch with a bare array every time.
10% progression on Octane/regexp (on my MBP.)
* runtime/JSArray.h:
(JSC::JSArray::create):
(JSC::JSArray::tryCreateUninitialized):
(JSC::JSArray::createWithButterfly): Factored out JSArray construction into a helper
so we can call this from RegExpMatchesArray.cpp.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::regExpMatchesArrayStructure): Add a cached Structure for RegExp
subpattern matches arrays.
* runtime/JSObject.h:
(JSC::JSNonFinalObject::finishCreation): Tweak assertion that used to check that
JSNonFinalObjects always start out with zero capacity. Since RegExp matches arrays now
start out with capacity for 2 properties, that won't work. Change it to check that we
don't have inline storage instead, since that should only be used by final objects.
* runtime/RegExpMatchesArray.h:
* runtime/RegExpMatchesArray.cpp:
(JSC::tryCreateUninitializedRegExpMatchesArray): Helper to construct a JSArray with
the cached Structure and a Butterfly with 2 slots of property storage.
(JSC::createRegExpMatchesArray):
(JSC::createRegExpMatchesArrayStructure): Creates the array Structure that gets cached
by the JSGlobalObject.
2015-06-16 Saam Barati <saambarati1@gmail.com>
LLInt's code path for get_from_scope with case GlobalVarWithVarInjectionChecks has dead code
https://bugs.webkit.org/show_bug.cgi?id=144268
Reviewed by Darin Adler.
The call to loadVariable(.) both for 32bit and 64bit is unnecessary.
It grabs a value that is immediately overwritten by a call to getGlobalVar().
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2015-06-14 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Introduce %IteratorPrototype% and drop all XXXIteratorConstructor
https://bugs.webkit.org/show_bug.cgi?id=145963
Reviewed by Darin Adler.
ES6 iterators inherit %IteratorPrototype%.
And these prototype objects of derived iterators don't have @@iterator methods.
Instead they use the %IteratorPrototype%[@@iterator] method.
To encourage inlining in for-of statement, we define this method in JS builtins.
And these iterator prototype objects don't have any constructor function.
This patch drops them (like StringIteratorConstructor).
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/Iterator.prototype.js: Renamed from Source/JavaScriptCore/runtime/StringIteratorConstructor.cpp.
(SymbolIterator):
* runtime/ArrayIteratorConstructor.cpp:
(JSC::ArrayIteratorConstructor::finishCreation): Deleted.
* runtime/ArrayIteratorConstructor.h: Removed.
(JSC::ArrayIteratorConstructor::create): Deleted.
(JSC::ArrayIteratorConstructor::createStructure): Deleted.
(JSC::ArrayIteratorConstructor::ArrayIteratorConstructor): Deleted.
* runtime/ArrayIteratorPrototype.cpp:
(JSC::ArrayIteratorPrototype::finishCreation):
(JSC::arrayIteratorProtoFuncIterator): Deleted.
* runtime/IteratorPrototype.cpp: Renamed from Source/JavaScriptCore/runtime/ArrayIteratorConstructor.cpp.
(JSC::IteratorPrototype::finishCreation):
* runtime/IteratorPrototype.h: Renamed from Source/JavaScriptCore/runtime/SetIteratorConstructor.h.
(JSC::IteratorPrototype::create):
(JSC::IteratorPrototype::createStructure):
(JSC::IteratorPrototype::IteratorPrototype):
* runtime/JSFunction.cpp:
(JSC::JSFunction::createBuiltinFunction):
* runtime/JSFunction.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::iteratorPrototype):
* runtime/MapIteratorConstructor.cpp: Removed.
(JSC::MapIteratorConstructor::finishCreation): Deleted.
* runtime/MapIteratorConstructor.h: Removed.
(JSC::MapIteratorConstructor::create): Deleted.
(JSC::MapIteratorConstructor::createStructure): Deleted.
(JSC::MapIteratorConstructor::MapIteratorConstructor): Deleted.
* runtime/MapIteratorPrototype.cpp:
(JSC::MapIteratorPrototype::finishCreation): Deleted.
(JSC::MapIteratorPrototypeFuncIterator): Deleted.
* runtime/SetIteratorConstructor.cpp: Removed.
(JSC::SetIteratorConstructor::finishCreation): Deleted.
* runtime/SetIteratorConstructor.h:
(JSC::SetIteratorConstructor::create): Deleted.
(JSC::SetIteratorConstructor::createStructure): Deleted.
(JSC::SetIteratorConstructor::SetIteratorConstructor): Deleted.
* runtime/SetIteratorPrototype.cpp:
(JSC::SetIteratorPrototype::finishCreation): Deleted.
(JSC::SetIteratorPrototypeFuncIterator): Deleted.
* runtime/StringIteratorConstructor.cpp:
(JSC::StringIteratorConstructor::finishCreation): Deleted.
* runtime/StringIteratorConstructor.h: Removed.
(JSC::StringIteratorConstructor::create): Deleted.
(JSC::StringIteratorConstructor::createStructure): Deleted.
(JSC::StringIteratorConstructor::StringIteratorConstructor): Deleted.
* runtime/StringIteratorPrototype.cpp:
(JSC::StringIteratorPrototype::finishCreation):
(JSC::stringIteratorPrototypeIterator): Deleted.
* tests/stress/iterator-prototype.js: Added.
(shouldBe):
(inheritIteratorPrototype):
(testChain):
2015-06-15 Michael Saboff <msaboff@apple.com>
JIT bug - fails when inspector closed, works when open
https://bugs.webkit.org/show_bug.cgi?id=145243
Reviewed by Oliver Hunt.
We need to provide the Arguments object as the base when creating the HeapLocation for
GetFromArguments and PutToArguments. Otherwise we endup creating a HeapLocation for
any arguments object, not the one we need.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
2015-06-13 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: console.table() with a list of objects no longer works
https://bugs.webkit.org/show_bug.cgi?id=145952
Reviewed by Timothy Hatcher.
* inspector/InjectedScriptSource.js:
(InjectedScript.RemoteObject.prototype._generatePreview):
Calling generatePreview again was actually starting with a preview
of the current object instead of the sub-value. Go down the other
path that correctly generates sub-previews. Leave filtering on the
backend unimplemented, which we were already ignoring.
2015-06-13 Youenn Fablet <youenn.fablet@crf.canon.fr>
[Streams API] ReadableJSStream should handle promises returned by JS source start callback
https://bugs.webkit.org/show_bug.cgi?id=145792
Reviewed by Darin Adler.
Added support for JSFunction implemented by std::function.
* runtime/JSFunction.cpp:
(JSC::getNativeExecutable): Refactored code to share it with the two JSFunction::create
(JSC::JSFunction::create):
(JSC::runStdFunction):
* runtime/JSFunction.h: Added std::function based JSFunction::create prototype.
* runtime.JSPromise.h:
2015-06-12 Gyuyoung Kim <gyuyoung.kim@webkit.org>
Purge PassRefPtr in JavaScriptCore - 2
https://bugs.webkit.org/show_bug.cgi?id=145834
Reviewed by Darin Adler.
As a step to remove PassRefPtr, this patch cleans up PassRefPtr as much as possible
in JavaScriptCore.
* API/JSClassRef.cpp:
(OpaqueJSClass::create):
* API/JSClassRef.h:
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::callerFrame):
* debugger/DebuggerCallFrame.h:
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::jitCode):
* inspector/ScriptCallStackFactory.cpp:
(Inspector::createScriptCallStack):
(Inspector::createScriptCallStackForConsole):
(Inspector::createScriptCallStackFromException):
(Inspector::createScriptArguments):
* inspector/ScriptCallStackFactory.h:
* jit/ExecutableAllocator.cpp:
(JSC::ExecutableAllocator::allocate):
* jit/ExecutableAllocator.h:
* jit/ExecutableAllocatorFixedVMPool.cpp:
(JSC::ExecutableAllocator::allocate):
* profiler/LegacyProfiler.cpp:
(JSC::LegacyProfiler::stopProfiling):
* profiler/LegacyProfiler.h:
* runtime/DateInstanceCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
* runtime/Executable.h:
* runtime/GenericTypedArrayView.h:
* runtime/GenericTypedArrayViewInlines.h:
(JSC::GenericTypedArrayView<Adaptor>::create):
(JSC::GenericTypedArrayView<Adaptor>::createUninitialized):
2015-06-12 Darin Adler <darin@apple.com>
Fix minor ES6 compliance issue in RegExp.prototype.toString and optimize performance a little
https://bugs.webkit.org/show_bug.cgi?id=145935
Reviewed by Anders Carlsson.
Test: js/regexp-toString.html
* runtime/RegExpPrototype.cpp:
(JSC::getFlags): Avoid memory allocation for the flags string by returning it in a character
buffer instead of constructing a WTF::String for it.
(JSC::regExpProtoFuncToString): Require only that the this value be an object; don't require
that it is actually a regular expression object. This is covered in the ES6 specification.
Also removed comment about the "/(?:)/" trick since that is now the repsonsibility of the
getter for the "source" property. Updated to use getFlags so we do one less memory allocation.
(JSC::regExpProtoGetterFlags): Chagned to use getFlags instead of the old flagsString.
2015-06-12 Basile Clement <basile_clement@apple.com>
DFG Object Allocation Sinking should not consider GetClosureVar as escapes
https://bugs.webkit.org/show_bug.cgi?id=145904
Reviewed by Filip Pizlo.
The object allocation sinking phase is currently able to sink
CreateActivation nodes, but will consider any GetClosureVar node as
escaping.
This is not problematic in general as most of the GetClosureVar nodes
we would have been able to sink over will have been eliminated by CSE
anyway. Still, this is an oversight that we should fix since the
machinery is already in place.
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
* dfg/DFGPromoteHeapAccess.h:
(JSC::DFG::promoteHeapAccess):
2015-06-11 Mark Lam <mark.lam@apple.com>
WebCore::reportException() needs to be able to accept a raw thrown value in addition to Exception objects.
https://bugs.webkit.org/show_bug.cgi?id=145872
Reviewed by Michael Saboff.
In r185259, we changed exception handling code inside the VM to work with
Exception objects instead of the thrown JSValue. The handling code will get the
exception stack trace from the Exception object.
However, there is some code that cannot be updated to pass the Exception object.
An example of this are the ObjC API functions. Those functions are specified to
return any thrown exception JSValue in a JSValueRef. Since these APIs are
public, we cannot arbitrarily change them to use the Exception object.
There are client code that calls these APIs and then passes the returned exception
JSValue to WebCore::reportException() to be reported. WebCore::reportException()
previously relied on the VM::exceptionStackTrace() to provide a cache of the
stack trace of the last thrown exception. VM::exceptionStackTrace() no longer
exists in the current code.
To restore this functionality, we will introduce VM::lastException() which
caches the last thrown Exception object. With this, if the exception passed to
WebCore::reportException() to be reported isn't an Exception object (which has its
own stack trace), reportException() can again use the cached exception stack trace
which is available from VM::lastException().
* heap/Heap.cpp:
(JSC::Heap::visitException):
- visit VM::m_lastException on GCs.
* interpreter/CallFrame.h:
(JSC::ExecState::lastException):
(JSC::ExecState::clearLastException):
- convenience functions to get and clear the last exception.
* runtime/Exception.cpp:
(JSC::Exception::create):
(JSC::Exception::finishCreation):
- add support to create an Exception object without capturing the JS stack trace.
This is needed for making an Exception object to wrap a thrown value that does
not have a stack trace.
Currently, this is only used by WebCore::reportException() when there is no
Exception object and no last exception available to provide a stack trace.
* runtime/Exception.h:
(JSC::Exception::cast): Deleted. No longer needed.
* runtime/VM.h:
(JSC::VM::clearLastException):
(JSC::VM::setException):
(JSC::VM::lastException):
(JSC::VM::addressOfLastException):
- Added support for VM::m_lastException.
VM::m_lastException serves to cache the exception stack of the most recently
thrown exception like VM::exceptionStackTrace() used to before r185259.
* runtime/VMEntryScope.cpp:
(JSC::VMEntryScope::VMEntryScope):
- Clear VM::m_lastException when we re-enter the VM. Exceptions should have been
handled before we re-enter the VM anyway. So, this is a good place to release
the cached last exception.
NOTE: this is also where the old code before r185259 clears the last exception
stack trace. So, we're just restoring the previous behavior here in terms of
the lifecycle of the last exception stack.
2015-06-11 Andreas Kling <akling@apple.com>
jsSubstring() should support creating substrings from substrings.
<https://webkit.org/b/145427>
Reviewed by Geoffrey Garen
Tweak jsSubstring() to support base strings that are themselves substrings.
They will now share the same grandparent base. This avoids creating a new StringImpl.
* runtime/JSString.h:
(JSC::jsSubstring): Don't force rope resolution here. Instead do that in finishCreation()
if the base string is a non-substring rope. Note that resolveRope() is the very last thing
called, since it may allocate and the JSRopeString needs to be ready for marking.
(JSC::JSString::isSubstring): Added a helper to find out if a JSString is
a substring. This is just for internal use, so you don't have to cast to
JSRopeString for the real substringness flag.
2015-06-11 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r185465.
https://bugs.webkit.org/show_bug.cgi?id=145893
"This patch is breaking 32bit mac build" (Requested by youenn
on #webkit).
Reverted changeset:
"[Streams API] ReadableJSStream should handle promises
returned by JS source start callback"
https://bugs.webkit.org/show_bug.cgi?id=145792
http://trac.webkit.org/changeset/185465
2015-06-11 Youenn Fablet <youenn.fablet@crf.canon.fr>
[Streams API] ReadableJSStream should handle promises returned by JS source start callback
https://bugs.webkit.org/show_bug.cgi?id=145792
Reviewed by Darin Adler.
Added support for JSFunction implemented by std::function.
* runtime/JSFunction.cpp:
(JSC::getNativeExecutable): Refactored code to share it with the two JSFunction::create
(JSC::JSFunction::create):
(JSC::runStdFunction):
* runtime/JSFunction.h: Added std::function based JSFunction::create prototype.
* runtime.JSPromise.h:
2015-06-10 Yusuke Suzuki <utatane.tea@gmail.com>
ASSERTION FAILED: s.length() > 1 on LayoutTests/js/regexp-flags.html
https://bugs.webkit.org/show_bug.cgi?id=145599
Unreviewed, simple follow up patch.
use jsString instead of jsMakeNontrivialString
since the flag string may be trivial (0 or 1 length).
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoGetterFlags):
2015-06-10 Yusuke Suzuki <utatane.tea@gmail.com>
JavaScript: Drop the “escaped reserved words as identifiers” compatibility measure
https://bugs.webkit.org/show_bug.cgi?id=90678
Reviewed by Darin Adler.
After ES6, escaped reserved words in identifiers are prohibited.
After parsing Identifier, we should perform `m_buffer16.shrink(0)`.
* parser/Lexer.cpp:
(JSC::Lexer<CharacterType>::parseIdentifierSlowCase):
* tests/mozilla/ecma_3/Unicode/uc-003.js:
(test): Deleted.
* tests/stress/reserved-word-with-escape.js: Added.
(testSyntax):
(testSyntaxError):
2015-06-10 Jordan Harband <ljharb@gmail.com>
Implement RegExp.prototype.flags
https://bugs.webkit.org/show_bug.cgi?id=145599
Reviewed by Geoffrey Garen.
Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-get-regexp.prototype.flags
* runtime/CommonIdentifiers.h:
* runtime/RegExpPrototype.cpp:
(JSC::flagsString):
(JSC::regExpProtoFuncToString):
(JSC::regExpProtoGetterFlags):
* tests/stress/static-getter-in-names.js:
2015-06-10 Filip Pizlo <fpizlo@apple.com>
DFG ASSERTION FAILED: !iterate() on stress/singleton-scope-then-overwrite.js.ftl-eager
https://bugs.webkit.org/show_bug.cgi?id=145853
Unreviewed, remove the assertion.
* dfg/DFGCSEPhase.cpp:
2015-06-10 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r185414.
https://bugs.webkit.org/show_bug.cgi?id=145844
broke debug and jsc tests (Requested by alexchristensen on
#webkit).
Reverted changeset:
"JavaScript: Drop the “escaped reserved words as identifiers”
compatibility measure"
https://bugs.webkit.org/show_bug.cgi?id=90678
http://trac.webkit.org/changeset/185414
2015-06-10 Yusuke Suzuki <utatane.tea@gmail.com>
JavaScript: Drop the “escaped reserved words as identifiers” compatibility measure
https://bugs.webkit.org/show_bug.cgi?id=90678
Reviewed by Darin Adler.
After ES6, escaped reserved words in identifiers are prohibited.
* parser/Lexer.cpp:
(JSC::Lexer<CharacterType>::parseIdentifierSlowCase):
* tests/stress/reserved-word-with-escape.js: Added.
(testSyntax):
(testSyntaxError):
2015-06-10 Andreas Kling <akling@apple.com>
[JSC] InlineCallFrame::arguments should be sized-to-fit.
<https://webkit.org/b/145782>
Reviewed by Darin Adler.
I spotted this Vector<ValueRecovery> looking a bit chubby in Instruments,
with 354 kB of memory allocated on cnet.com.
Use resizeToFit() instead of resize() since we know the final size up front.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
2015-06-09 Chris Dumez <cdumez@apple.com>
Allow one sync GC per gcTimer interval on critical memory pressure warning
https://bugs.webkit.org/show_bug.cgi?id=145773
Reviewed by Geoffrey Garen.
On critical memory pressure warning, we were calling GCController::garbageCollectSoon(),
which does not offer any guarantee on when the garbage collection will actually take
place.
On critical memory pressure, we need to free up memory as soon as possible to avoid
getting killed so this is an issue. Also, the fact that we clear the PageCache on
critical memory pressure means a GC would likely be useful, even if the last
collection did not free much memory.
This patch adds a new GCController::garbageCollectNowIfNotDoneRecently() API that allows
one synchronous GC per gcTimer interval on critical memory pressure warning. This makes
us more responsive to critical memory pressure and avoids doing synchronous GCs too
often.
* heap/FullGCActivityCallback.cpp:
(JSC::FullGCActivityCallback::doCollection):
* heap/FullGCActivityCallback.h:
(JSC::GCActivityCallback::createFullTimer):
* heap/GCActivityCallback.h:
* heap/Heap.cpp:
(JSC::Heap::collectAllGarbageIfNotDoneRecently):
* heap/Heap.h:
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::doWork): Deleted.
* heap/IncrementalSweeper.h:
Drop fullSweep() API as it no longer seems useful. garbageCollectNow()
already does a sweep after the full collection.
2015-06-09 Andreas Kling <akling@apple.com>
[JSC] CodeBlock::m_constantRegisters should be sized-to-fit.
<https://webkit.org/b/145784>
Reviewed by Darin Adler.
Spotted this Vector looking chubby on cnet.com, with 1.23 MB of memory
allocated below CodeBlock::setConstantRegisters().
Use resizeToFit() instead since we know the final size up front.
Also removed some unused functions that operated on this constants vector
and the corresponding one in UnlinkedCodeBlock.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::addOrFindConstant): Deleted.
(JSC::CodeBlock::findConstant): Deleted.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::setConstantRegisters):
(JSC::CodeBlock::numberOfConstantRegisters): Deleted.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::addOrFindConstant): Deleted.
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::numberOfConstantRegisters): Deleted.
(JSC::UnlinkedCodeBlock::getConstant): Deleted.
2015-06-09 Andreas Kling <akling@apple.com>
[JSC] Polymorphic{Get,Put}ByIdList::addAccess() should optimize for size, not speed.
<https://webkit.org/b/145786>
Reviewed by Darin Adler.
These functions already contained comments saying they optimize for size over speed,
but they were using Vector::resize() which adds the usual slack for faster append().
Switch them over to using Vector::resizeToFit() instead, which makes the Vector
allocate a perfectly sized backing store.
Spotted 670 kB of the GetById ones, and 165 kB of PutById on cnet.com, so these
Vectors are definitely worth shrink-wrapping.
* bytecode/PolymorphicGetByIdList.cpp:
(JSC::PolymorphicGetByIdList::addAccess):
* bytecode/PolymorphicPutByIdList.cpp:
(JSC::PolymorphicPutByIdList::addAccess):
2015-06-09 Andreas Kling <akling@apple.com>
[JSC] JSPropertyNameEnumerator's property name vector should be sized-to-fit.
<https://webkit.org/b/145787>
Reviewed by Darin Adler.
Saw 108 kB worth of JSPropertyNameEnumerator backing store Vectors on cnet.com.
Use Vector::resizeToFit() since we know the perfect size up front.
* runtime/JSPropertyNameEnumerator.cpp:
(JSC::JSPropertyNameEnumerator::finishCreation):
2015-06-09 Andreas Kling <akling@apple.com>
FunctionExecutable::isCompiling() is weird and wrong.
<https://webkit.org/b/145689>
Reviewed by Geoffrey Garen.
Remove FunctionExecutable::isCompiling() and the clearCodeIfNotCompiling() style
functions that called it before throwing away code.
isCompiling() would consider the executable to be "compiling" if it had a CodeBlock
but no JITCode. In practice, every executable gets a JITCode at the same time as it
gets a CodeBlock, by way of prepareForExecutionImpl().
* debugger/Debugger.cpp:
* heap/Heap.cpp:
(JSC::Heap::deleteAllCompiledCode):
(JSC::Heap::deleteAllUnlinkedFunctionCode):
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::TypeRecompiler::visit):
* runtime/Executable.cpp:
(JSC::FunctionExecutable::clearUnlinkedCodeForRecompilation):
(JSC::FunctionExecutable::clearCodeIfNotCompiling): Deleted.
(JSC::FunctionExecutable::clearUnlinkedCodeForRecompilationIfNotCompiling): Deleted.
* runtime/Executable.h:
* runtime/VM.cpp:
(JSC::StackPreservingRecompiler::visit):
2015-06-09 Yusuke Suzuki <utatane.tea@gmail.com>
Introduce getter definition into static hash tables and use it for getters in RegExp.prototype.
https://bugs.webkit.org/show_bug.cgi?id=145705
Reviewed by Darin Adler.
In this patch, we introduce Accessor type into property tables.
With Accessor type, create_hash_table creates a static getter property.
This getter property is reified as the same to the static functions.
In the mean time, we only support getter because `putEntry` and `lookupPut`
only work with null setter currently. However, in the spec, there's
no need to add static setter properties. So we will add it if it becomes
necessary in the future.
And at the same time, this patch fixes the issue 145738. Before this patch,
`putEntry` in `JSObject::deleteProperty` adds `undefined` property if
`isValidOffset(...)` is false (deleted). As the result, deleting twice
revives the property with `undefined` value.
If the static functions are reified and the entry is
`BuiltinOrFunctionOrAccessor`, there's no need to execute `putEntry` with
static hash table entry. They should be handled in the normal structure's
looking up because they should be already reified. So added guard for this.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* create_hash_table:
* runtime/JSObject.cpp:
(JSC::getClassPropertyNames):
(JSC::JSObject::put):
(JSC::JSObject::deleteProperty):
(JSC::JSObject::reifyStaticFunctionsForDelete):
* runtime/Lookup.cpp:
(JSC::reifyStaticAccessor):
(JSC::setUpStaticFunctionSlot):
* runtime/Lookup.h:
(JSC::HashTableValue::propertyGetter):
(JSC::HashTableValue::propertyPutter):
(JSC::HashTableValue::accessorGetter):
(JSC::HashTableValue::accessorSetter):
(JSC::getStaticPropertySlot):
(JSC::getStaticValueSlot):
(JSC::putEntry):
(JSC::reifyStaticProperties):
* runtime/PropertySlot.h:
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::getOwnPropertySlot):
(JSC::regExpObjectGlobal): Deleted.
(JSC::regExpObjectIgnoreCase): Deleted.
(JSC::regExpObjectMultiline): Deleted.
(JSC::appendLineTerminatorEscape<LChar>): Deleted.
(JSC::appendLineTerminatorEscape<UChar>): Deleted.
(JSC::regExpObjectSourceInternal): Deleted.
(JSC::regExpObjectSource): Deleted.
* runtime/RegExpPrototype.cpp:
(JSC::RegExpPrototype::getOwnPropertySlot):
(JSC::regExpProtoGetterGlobal):
(JSC::regExpProtoGetterIgnoreCase):
(JSC::regExpProtoGetterMultiline):
(JSC::appendLineTerminatorEscape<LChar>):
(JSC::appendLineTerminatorEscape<UChar>):
(JSC::regExpProtoGetterSourceInternal):
(JSC::regExpProtoGetterSource):
* tests/stress/static-function-delete.js: Added.
(shouldBe):
* tests/stress/static-function-put.js: Added.
(shouldBe):
* tests/stress/static-getter-delete.js: Added.
(shouldBe):
(shouldThrow):
* tests/stress/static-getter-descriptors.js: Added.
(shouldBe):
* tests/stress/static-getter-enumeration.js: Added.
(shouldBe):
* tests/stress/static-getter-get.js: Added.
(shouldBe):
* tests/stress/static-getter-in-names.js: Added.
(shouldBe):
* tests/stress/static-getter-names.js: Added.
(shouldBe):
* tests/stress/static-getter-put.js: Added.
(shouldBe):
(shouldThrow):
2015-06-09 Andreas Kling <akling@apple.com>
[JSC] JSString::getIndex() should avoid reifying substrings.
<https://webkit.org/b/145803>
Reviewed by Darin Adler.
Implement getIndex() using JSString::view(), which cuts it down to a one-liner
and also avoids reifying substrings.
I saw 178 kB of reified substrings below operationGetByVal -> getIndex()
on cnet.com, so this should help.
* runtime/JSString.cpp:
(JSC::JSRopeString::getIndexSlowCase): Deleted.
* runtime/JSString.h:
(JSC::JSString::getIndex):
2015-06-09 Andreas Kling <akling@apple.com>
[JSC] String.prototype.indexOf() should use StringView.
<https://webkit.org/b/145351>
Reviewed by Darin Adler.
Use StringView::find() to implement String.prototype.indexOf().
This avoids reifying the needle and haystack JSStrings in case they
are substrings.
Reduces malloc memory by ~190 kB on cnet.com.
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncIndexOf):
2015-06-09 Csaba Osztrogonác <ossy@webkit.org>
[cmake] Fix the style issues in cmake project files
https://bugs.webkit.org/show_bug.cgi?id=145755
Reviewed by Darin Adler.
* CMakeLists.txt:
2015-06-08 Gyuyoung Kim <gyuyoung.kim@webkit.org>
Purge PassRefPtr in JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=145750
As a step to purge PassRefPtr, this patch replaces PassRefPtr with Ref or RefPtr.
Reviewed by Darin Adler.
* API/JSClassRef.cpp:
(OpaqueJSClass::createNoAutomaticPrototype):
* API/JSClassRef.h:
* API/JSContextRef.cpp:
* API/JSScriptRef.cpp:
(OpaqueJSScript::create):
* API/JSStringRef.cpp:
(JSStringCreateWithCharacters):
(JSStringCreateWithUTF8CString):
* API/OpaqueJSString.cpp:
(OpaqueJSString::create):
* API/OpaqueJSString.h:
(OpaqueJSString::create):
* bytecompiler/StaticPropertyAnalysis.h:
(JSC::StaticPropertyAnalysis::create):
* debugger/DebuggerCallFrame.h:
(JSC::DebuggerCallFrame::create):
* dfg/DFGToFTLDeferredCompilationCallback.cpp:
(JSC::DFG::ToFTLDeferredCompilationCallback::create):
* dfg/DFGToFTLDeferredCompilationCallback.h:
* dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
(JSC::DFG::Ref<ToFTLForOSREntryDeferredCompilationCallback>ToFTLForOSREntryDeferredCompilationCallback::create):
(JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::create): Deleted.
* dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h:
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::create):
(JSC::DFG::ensureGlobalDFGWorklist):
(JSC::DFG::ensureGlobalFTLWorklist):
* dfg/DFGWorklist.h:
* heap/EdenGCActivityCallback.h:
(JSC::GCActivityCallback::createEdenTimer):
* heap/FullGCActivityCallback.h:
(JSC::GCActivityCallback::createFullTimer):
* heap/GCActivityCallback.h:
* inspector/InjectedScriptHost.h:
* inspector/JavaScriptCallFrame.h:
(Inspector::JavaScriptCallFrame::create):
* inspector/ScriptArguments.cpp:
(Inspector::ScriptArguments::create):
* inspector/ScriptArguments.h:
* jit/JITStubRoutine.h:
(JSC::JITStubRoutine::createSelfManagedRoutine):
* jit/JITToDFGDeferredCompilationCallback.cpp:
(JSC::JITToDFGDeferredCompilationCallback::create):
* jit/JITToDFGDeferredCompilationCallback.h:
* jsc.cpp:
(jscmain):
* parser/NodeConstructors.h:
(JSC::ArrayPatternNode::create):
(JSC::ObjectPatternNode::create):
(JSC::BindingNode::create):
* parser/Nodes.cpp:
(JSC::FunctionParameters::create):
* parser/Nodes.h:
* parser/SourceProvider.h:
(JSC::StringSourceProvider::create):
* profiler/Profile.cpp:
(JSC::Profile::create):
* profiler/Profile.h:
* profiler/ProfileGenerator.cpp:
(JSC::ProfileGenerator::create):
* profiler/ProfileGenerator.h:
* profiler/ProfileNode.h:
(JSC::ProfileNode::create):
* runtime/DataView.cpp:
(JSC::DataView::create):
* runtime/DataView.h:
* runtime/DateInstanceCache.h:
(JSC::DateInstanceData::create):
* runtime/JSPromiseReaction.cpp:
(JSC::createExecutePromiseReactionMicrotask):
* runtime/JSPromiseReaction.h:
* runtime/PropertyNameArray.h:
(JSC::PropertyNameArrayData::create):
* runtime/TypeSet.h:
(JSC::StructureShape::create):
(JSC::TypeSet::create):
* runtime/TypedArrayBase.h:
(JSC::TypedArrayBase::create):
(JSC::TypedArrayBase::createUninitialized):
(JSC::TypedArrayBase::subarrayImpl):
* runtime/VM.cpp:
(JSC::VM::createContextGroup):
(JSC::VM::create):
(JSC::VM::createLeaked):
* runtime/VM.h:
* yarr/RegularExpression.cpp:
(JSC::Yarr::RegularExpression::Private::create):
2015-06-08 Filip Pizlo <fpizlo@apple.com>
It should be possible to hoist all constants in DFG SSA
https://bugs.webkit.org/show_bug.cgi?id=145769
Reviewed by Geoffrey Garen.
It's sometimes somewhat more efficient, and convenient, to have all constants at the
top of the root block. We don't require this as an IR invariant because too many phases
want to be able to insert constants in weird places. But, this phase will be great for
preparing for https://bugs.webkit.org/show_bug.cgi?id=145768.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGConstantHoistingPhase.cpp: Added.
(JSC::DFG::performConstantHoisting):
* dfg/DFGConstantHoistingPhase.h: Added.
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
2015-06-07 Filip Pizlo <fpizlo@apple.com>
The tiny set magic in StructureSet should be available in WTF
https://bugs.webkit.org/show_bug.cgi?id=145722
Reviewed by Geoffrey Garen.
I moved the generic logic of small sets of pointers and moved it into WTF. Now,
StructureSet is a subclass of TinyPtrSet<Structure*>. There shouldn't be any functional
change.
* bytecode/StructureSet.cpp:
(JSC::StructureSet::filter):
(JSC::StructureSet::filterArrayModes):
(JSC::StructureSet::speculationFromStructures):
(JSC::StructureSet::arrayModesFromStructures):
(JSC::StructureSet::dumpInContext):
(JSC::StructureSet::dump):
(JSC::StructureSet::clear): Deleted.
(JSC::StructureSet::add): Deleted.
(JSC::StructureSet::remove): Deleted.
(JSC::StructureSet::contains): Deleted.
(JSC::StructureSet::merge): Deleted.
(JSC::StructureSet::exclude): Deleted.
(JSC::StructureSet::isSubsetOf): Deleted.
(JSC::StructureSet::overlaps): Deleted.
(JSC::StructureSet::operator==): Deleted.
(JSC::StructureSet::addOutOfLine): Deleted.
(JSC::StructureSet::containsOutOfLine): Deleted.
(JSC::StructureSet::copyFromOutOfLine): Deleted.
(JSC::StructureSet::OutOfLineList::create): Deleted.
(JSC::StructureSet::OutOfLineList::destroy): Deleted.
* bytecode/StructureSet.h:
(JSC::StructureSet::onlyStructure):
(JSC::StructureSet::StructureSet): Deleted.
(JSC::StructureSet::operator=): Deleted.
(JSC::StructureSet::~StructureSet): Deleted.
(JSC::StructureSet::isEmpty): Deleted.
(JSC::StructureSet::genericFilter): Deleted.
(JSC::StructureSet::isSupersetOf): Deleted.
(JSC::StructureSet::size): Deleted.
(JSC::StructureSet::at): Deleted.
(JSC::StructureSet::operator[]): Deleted.
(JSC::StructureSet::last): Deleted.
(JSC::StructureSet::iterator::iterator): Deleted.
(JSC::StructureSet::iterator::operator*): Deleted.
(JSC::StructureSet::iterator::operator++): Deleted.
(JSC::StructureSet::iterator::operator==): Deleted.
(JSC::StructureSet::iterator::operator!=): Deleted.
(JSC::StructureSet::begin): Deleted.
(JSC::StructureSet::end): Deleted.
(JSC::StructureSet::ContainsOutOfLine::ContainsOutOfLine): Deleted.
(JSC::StructureSet::ContainsOutOfLine::operator()): Deleted.
(JSC::StructureSet::copyFrom): Deleted.
(JSC::StructureSet::OutOfLineList::list): Deleted.
(JSC::StructureSet::OutOfLineList::OutOfLineList): Deleted.
(JSC::StructureSet::deleteStructureListIfNecessary): Deleted.
(JSC::StructureSet::isThin): Deleted.
(JSC::StructureSet::pointer): Deleted.
(JSC::StructureSet::singleStructure): Deleted.
(JSC::StructureSet::structureList): Deleted.
(JSC::StructureSet::set): Deleted.
(JSC::StructureSet::setEmpty): Deleted.
(JSC::StructureSet::getReservedFlag): Deleted.
(JSC::StructureSet::setReservedFlag): Deleted.
* dfg/DFGStructureAbstractValue.cpp:
(JSC::DFG::StructureAbstractValue::clobber):
(JSC::DFG::StructureAbstractValue::filter):
(JSC::DFG::StructureAbstractValue::filterSlow):
(JSC::DFG::StructureAbstractValue::contains):
* dfg/DFGStructureAbstractValue.h:
(JSC::DFG::StructureAbstractValue::makeTop):
2015-06-08 Csaba Osztrogonác <ossy@webkit.org>
[ARM] Add the missing setupArgumentsWithExecState functions after r185240
https://bugs.webkit.org/show_bug.cgi?id=145754
Reviewed by Benjamin Poulain.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState):
2015-06-08 Brady Eidson <beidson@apple.com>
Completely remove all IDB properties/constructors when it is disabled at runtime.
rdar://problem/18429374 and https://bugs.webkit.org/show_bug.cgi?id=137034
Reviewed by Geoffrey Garen.
* runtime/CommonIdentifiers.h:
2015-06-06 Mark Lam <mark.lam@apple.com>
Returned Exception* values need to be initialized to nullptr when no exceptions are thrown.
https://bugs.webkit.org/show_bug.cgi?id=145720
Reviewed by Dan Bernstein.
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::evaluate):
2015-06-05 Mark Lam <mark.lam@apple.com>
Subclasses of JSNonFinalObject with gc'able children need to implement visitChildren().
https://bugs.webkit.org/show_bug.cgi?id=145709
Reviewed by Geoffrey Garen.
* jsc.cpp:
(functionSetElementRoot):
- The Element class has a member of type Root which extends JSDestructibleObject.
It should be stored in a WriteBarrier, and visited by visitChildren().
* runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::materializeSpecialsIfNecessary):
(JSC::ClonedArguments::visitChildren):
* runtime/ClonedArguments.h:
- Add missing visitChildren().
* tests/stress/cloned-arguments-should-visit-callee-during-gc.js: Added.
(makeTransientFunction.transientFunc):
(makeTransientFunction):
2015-06-05 Geoffrey Garen <ggaren@apple.com>
DropAllLocks RELEASE_ASSERT on iOS
https://bugs.webkit.org/show_bug.cgi?id=139654
Reviewed by Mark Lam.
* runtime/JSLock.cpp:
(JSC::JSLock::dropAllLocks): Removed a comment because it duplicated
the code beneath it. Removed a FIXME because we can't ASSERT that
we're holding the lock. WebKit1 on iOS drops the lock before calling to
delegates, not knowing whether it holds the lock or not.
(JSC::JSLock::DropAllLocks::DropAllLocks): Only ASSERT that we are not
GC'ing if we hold the lock. If we do not hold the lock, it is perfectly
valid for some other thread, which does hold the lock, to be GC'ing.
What is not valid is to drop the lock in the middle of GC, since GC
must be atomic.
2015-06-05 Filip Pizlo <fpizlo@apple.com>
speculateRealNumber() should early exit if you're already a real number, not if you're already a real double.
Rubber stamped by Mark Lam.
This was causing: https://build.webkit.org/results/Apple%20Yosemite%20Debug%20WK1%20(Tests)/r185261%20(5180)/webaudio/note-grain-on-timing-crash-log.txt
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::speculateRealNumber):
2015-06-05 Mark Lam <mark.lam@apple.com>
finally blocks should not set the exception stack trace when re-throwing the exception.
https://bugs.webkit.org/show_bug.cgi?id=145525
Reviewed by Geoffrey Garen.
How exceptions presently work:
=============================
1. op_throw can throw any JSValue.
2. the VM tries to capture the stack at the throw point and propagate that as needed.
3. finally blocks are implemented using op_catch to catch the thrown value, and throws it again using op_throw.
What's wrong with how it presently works:
========================================
1. finally's makes for bad exception throw line numbers in the Inspector console.
The op_throw in finally will throw the value anew i.e. it captures a stack from the re-throw point.
As a result, the Inspector sees the finally block as the throw point. The original stack is lost.
2. finally's breaks the Inspector's "Breaks on Uncaught Exception"
This is because finally blocks are indistinguishable from catch blocks. As a result, a try-finally,
which should break in the Inspector on the throw, does not because the Inspector thought the
exception was "caught".
3. finally's yields confusing break points when the Inspector "Breaks on All Exceptions"
a. In a try-finally scenario, the Inspector breaks 2 times: 1 at the throw, 1 at the finally.
b. In a for-of loop (which has synthesized finallys), the Inspector will do another break.
Similarly for other cases of JS code which synthesize finallys.
c. At VM re-entry boundaries (e.g. js throws & returns to native code, which returns to js),
the Inspector will do another break if there's an uncaught exception.
How this patch fixes the issues:
===============================
1. We introduce an Exception object that wraps the thrown value and the exception stack.
When throwing an exception, the VM will check if the thrown value is an Exception
object or not. If it is not an Exception object, then we must be throwing a new
exception. The VM will create an Exception object to wrap the thrown value and
capture the current stack for it.
If the thrown value is already an Exception object, then the requested throw operation
must be a re-throw. The VM will not capture a new stack for it.
2. op_catch will now populate 2 locals: 1 for the Exception, 1 for the thrown JSValue.
The VM is aware of the Exception object and uses it for rethrows in finally blocks.
JS source code is never aware of the Exception object.
JS code is aware of the thrown value. If it throws the caught thrown value, that
constitutes a new throw, and a new Exception object will be created for it.
3. The VM no longer tracks the thrown JSValue and the exception stack. It will only
track a m_exception field which is an Exception*.
4. The BytecodeGenerator has already been updated in a prior patch to distinguish
between Catch, Finally, and SynthesizedFinally blocks. The interpreter runtime will
now report to the debugger whether we have a Catch handler, not just any handlers.
The debugger will use this detail to determine whether to break or not. "Break on
uncaught exceptions" will only break if no Catch handler was found.
This solves the issue of the debugger breaking at finally blocks, and for-of statements.
5. The Exception object will also have a flag to indicate whether the debugger has been
notified of the Exception being thrown. Once the Interpreter notifies the debugger
of the Exception object, it will mark this flag and not repeat the notify the debugger
again of the same Exception.
This solves the issue of the debugger breaking at VM re-entry points due to uncaught
exceptions.
6. The life-cycle of the captured exception stack trace will now follow the life-cycle
of the Exception object.
Other changes:
7. Change all clients of the VM::exception() to expect an Exception* instead of JSValue.
8. Fixed a few bugs where thrown exceptions are not cleared before exiting the VM.
9. Also renamed some variables and classes to better describe what they are.
* API/JSBase.cpp:
(JSEvaluateScript):
(JSCheckScriptSyntax):
* API/JSObjectRef.cpp:
(handleExceptionIfNeeded):
- The functions below all do the same exception check. Added this helper
to simplify the code.
(JSClassCreate):
(JSObjectMakeFunction):
(JSObjectMakeArray):
(JSObjectMakeDate):
(JSObjectMakeError):
(JSObjectMakeRegExp):
(JSObjectGetProperty):
(JSObjectSetProperty):
(JSObjectGetPropertyAtIndex):
(JSObjectSetPropertyAtIndex):
(JSObjectDeleteProperty):
(JSObjectCallAsFunction):
(JSObjectCallAsConstructor):
* API/JSScriptRef.cpp:
* API/JSValue.mm:
(JSContainerConvertor::take):
(reportExceptionToInspector):
* API/JSValueRef.cpp:
(handleExceptionIfNeeded):
- The functions below all do the same exception check. Added this helper
to simplify the code.
(evernoteHackNeeded):
(JSValueIsEqual):
(JSValueIsInstanceOfConstructor):
(JSValueCreateJSONString):
(JSValueToNumber):
(JSValueToStringCopy):
(JSValueToObject):
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
- Added new files Exception.h and Exception.cpp.
* bindings/ScriptFunctionCall.cpp:
(Deprecated::ScriptFunctionCall::call):
* bindings/ScriptFunctionCall.h:
* bytecode/BytecodeList.json:
- op_catch now had 2 operands: the exception register, and the thrown value register.
* bytecode/BytecodeUseDef.h:
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::handlerForBytecodeOffset):
* bytecode/CodeBlock.h:
- handlerForBytecodeOffset() now can look for just Catch handlers only.
* bytecode/HandlerInfo.h:
- Cleaned up some white space I accidentally added in a previous patch.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::pushTry):
(JSC::BytecodeGenerator::popTryAndEmitCatch):
(JSC::BytecodeGenerator::emitThrowReferenceError):
(JSC::BytecodeGenerator::emitEnumeration):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::emitThrow):
* bytecompiler/NodesCodegen.cpp:
(JSC::TryNode::emitBytecode):
- Adding support for op_catch's 2 operands.
* debugger/Debugger.cpp:
(JSC::Debugger::hasBreakpoint):
(JSC::Debugger::pauseIfNeeded):
(JSC::Debugger::exception):
* debugger/Debugger.h:
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::thisValue):
(JSC::DebuggerCallFrame::evaluate):
* debugger/DebuggerCallFrame.h:
(JSC::DebuggerCallFrame::isValid):
* inspector/InjectedScriptManager.cpp:
(Inspector::InjectedScriptManager::createInjectedScript):
* inspector/InspectorEnvironment.h:
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace):
(Inspector::JSGlobalObjectInspectorController::reportAPIException):
* inspector/JSGlobalObjectInspectorController.h:
* inspector/JSGlobalObjectScriptDebugServer.h:
* inspector/JSJavaScriptCallFrame.cpp:
(Inspector::JSJavaScriptCallFrame::evaluate):
* inspector/JavaScriptCallFrame.h:
(Inspector::JavaScriptCallFrame::vmEntryGlobalObject):
(Inspector::JavaScriptCallFrame::thisValue):
(Inspector::JavaScriptCallFrame::evaluate):
* inspector/ScriptCallStackFactory.cpp:
(Inspector::extractSourceInformationFromException):
(Inspector::createScriptCallStackFromException):
* inspector/ScriptCallStackFactory.h:
* inspector/ScriptDebugServer.cpp:
(Inspector::ScriptDebugServer::evaluateBreakpointAction):
(Inspector::ScriptDebugServer::handleBreakpointHit):
(Inspector::ScriptDebugServer::handleExceptionInBreakpointCondition):
* inspector/ScriptDebugServer.h:
* interpreter/CallFrame.h:
(JSC::ExecState::clearException):
(JSC::ExecState::exception):
(JSC::ExecState::hadException):
(JSC::ExecState::atomicStringTable):
(JSC::ExecState::propertyNames):
(JSC::ExecState::clearSupplementaryExceptionInfo): Deleted.
* interpreter/Interpreter.cpp:
(JSC::unwindCallFrame):
(JSC::Interpreter::stackTraceAsString):
(JSC::GetCatchHandlerFunctor::GetCatchHandlerFunctor):
(JSC::GetCatchHandlerFunctor::operator()):
(JSC::Interpreter::unwind):
- Added a check for didNotifyInspectorOfThrow() here to prevent duplicate reports
of the same Exception to the debugger.
(JSC::GetExceptionHandlerFunctor::GetExceptionHandlerFunctor): Deleted.
(JSC::GetExceptionHandlerFunctor::operator()): Deleted.
- Renamed GetExceptionHandlerFunctor to GetCatchHandlerFunctor since the debugger
is only interested in knowing whether we have Catch handlers.
* interpreter/Interpreter.h:
(JSC::SuspendExceptionScope::SuspendExceptionScope):
(JSC::SuspendExceptionScope::~SuspendExceptionScope):
(JSC::Interpreter::sampler):
(JSC::ClearExceptionScope::ClearExceptionScope): Deleted.
(JSC::ClearExceptionScope::~ClearExceptionScope): Deleted.
- Renamed ClearExceptionScope to SuspendExceptionScope because "clear" implies that
we're purging the exception. Instead, we're merely suspending any handling of
that exception for a period defined by the scope.
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitExceptionCheck):
* jit/JITExceptions.cpp:
(JSC::genericUnwind):
- Removed the exception argument. It is always the value in VM::exception() anyway.
genericUnwind() can just get it from the VM, and save everyone some work.
* jit/JITExceptions.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_catch):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::privateCompileCTINativeCall):
(JSC::JIT::emit_op_catch):
- Add support for the new op_catch operands.
* jit/JITOperations.cpp:
* jit/ThunkGenerators.cpp:
(JSC::nativeForGenerator):
* jsc.cpp:
(functionRun):
(functionLoad):
(runWithScripts):
(runInteractive):
* llint/LLIntOffsetsExtractor.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
- Add support for the new op_catch operands. Also update the code to handle
VM::m_exception being an Exception pointer, not a JSValue.
* parser/NodeConstructors.h:
(JSC::TryNode::TryNode):
* parser/Nodes.h:
* runtime/CallData.cpp:
(JSC::call):
* runtime/CallData.h:
* runtime/Completion.cpp:
(JSC::evaluate):
* runtime/Completion.h:
(JSC::evaluate):
- Change evaluate() to take a reference to the returned exception value instead
of a pointer. In all but 2 or 3 cases, we want the returned exception anyway.
Might as well simplify the code by requiring the reference.
* runtime/Error.h:
(JSC::throwVMError):
(JSC::throwVMTypeError):
* runtime/Exception.cpp: Added.
(JSC::Exception::create):
(JSC::Exception::destroy):
(JSC::Exception::createStructure):
(JSC::Exception::visitChildren):
(JSC::Exception::Exception):
(JSC::Exception::~Exception):
* runtime/Exception.h: Added.
(JSC::Exception::valueOffset):
(JSC::Exception::cast):
(JSC::Exception::value):
(JSC::Exception::stack):
(JSC::Exception::didNotifyInspectorOfThrow):
(JSC::Exception::setDidNotifyInspectorOfThrow):
* runtime/ExceptionHelpers.cpp:
(JSC::createTerminatedExecutionException):
(JSC::isTerminatedExecutionException):
(JSC::createStackOverflowError):
* runtime/ExceptionHelpers.h:
* runtime/GetterSetter.cpp:
(JSC::callGetter):
* runtime/IteratorOperations.cpp:
(JSC::iteratorClose):
* runtime/JSObject.cpp:
* runtime/JSPromiseConstructor.cpp:
(JSC::constructPromise):
* runtime/JSPromiseDeferred.cpp:
(JSC::updateDeferredFromPotentialThenable):
(JSC::abruptRejection):
* runtime/JSPromiseReaction.cpp:
(JSC::ExecutePromiseReactionMicrotask::run):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::releaseExecutableMemory):
(JSC::VM::throwException):
(JSC::VM::setStackPointerAtVMEntry):
(JSC::VM::getExceptionInfo): Deleted.
(JSC::VM::setExceptionInfo): Deleted.
(JSC::VM::clearException): Deleted.
(JSC::clearExceptionStack): Deleted.
* runtime/VM.h:
(JSC::VM::targetMachinePCForThrowOffset):
(JSC::VM::clearException):
(JSC::VM::setException):
(JSC::VM::exception):
(JSC::VM::addressOfException):
(JSC::VM::exceptionStack): Deleted.
* runtime/VMEntryScope.cpp:
(JSC::VMEntryScope::VMEntryScope):
(JSC::VMEntryScope::setEntryScopeDidPopListener):
2015-06-04 Benjamin Poulain <bpoulain@apple.com>
[JSC] Always track out-of-bounds array access explicitly instead of relying on the slow case
https://bugs.webkit.org/show_bug.cgi?id=145673
Reviewed by Geoffrey Garen.
Previously, we were deciding to use out-of-bounds speculation based on two informations:
-Explicitly detected out-of-bounds accesses tracked on ArrayProfile.
-The number of time we took the slow cases in the baseline JIT.
The heuristic based on slow cases was a little too fragile.
In some cases, we were running into that limit just because the indexing type changes between
two values (typically Int32Array and DoubleArray). Sometimes we were just unlucky on what
we used for the inline cache.
In Kraken, this was hurting us on "audio-beat-detection" and "audio-fft". The array types we see
change between Int32 and Double. We run into the slow path a bit but never hit
out-of-bounds.
By the time we compile in DFG, we have stable Double Arrays but we speculate out-of-bounds based
on the number of slow cases we took. Because of that, we start boxing the double on GetByVal,
using DoubleRep, etc. adding a ton of overhead over otherwise very simple operations.
WebXPRT was also suffering from this problem but the other way arround: we were missing
the out-of-bounds accesses due to changes in indexing types, we were below the threshold
of slow-path access, thus we predicted in-bounds accesses for code that was doing plenty
of out-of-bands.
This patch fixes the problem by tracking the out-of-bounds access explicitly any time we go
into the slow path in baseline JIT. Since we no longer miss any out-of-bounds, we can remove
the slow-path heuristic.
There is new additional special case in the C code regarding out-of-bounds: Arguments access.
Mispredicting out-of-bounds accesses on arguments is a disaster for performance, so those are
tracked in the way DFG expect it.
There are a few important cases that are still not covered optimally:
-PutByVal on Arguments.
-Get/Put ByVal on TypedArray.
Those are simply not used by DFG in any way. TypedArrays should probably be looked at in the future.
* bytecode/ArrayProfile.cpp:
(JSC::ArrayProfile::computeUpdatedPrediction):
The inline-cache repatch cases now update the ArrayProfile information. This has no value in baseline
JIT but it helps avoiding one recompile in DFG for the missing ArrayProfile information.
* bytecode/ArrayProfile.h:
(JSC::ArrayProfile::setOutOfBounds):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::getArrayMode):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::getArrayModeConsideringSlowPath): Deleted.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* jit/JITOpcodes.cpp:
(JSC::JIT::emitSlow_op_has_indexed_property):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emitSlow_op_has_indexed_property):
* jit/JITOperations.cpp:
(JSC::canUseFastArgumentAccess):
This is not my favorite part of this patch.
I tried having JSObject::canGetIndexQuickly() handle arguments which would put everything
on the generic path. Unfortunately, that code is very performance sensitive and some benchmarks were
impacted by over 10%
I left JSObject::canGetIndexQuickly() alone, and I added the canUseFastArgumentAccess() mirroring
how DFG uses out-of-bounds for Arguments.
(JSC::getByVal):
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emitSlow_op_put_by_val):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emitSlow_op_put_by_val):
* runtime/JSPromiseFunctions.cpp:
* tests/stress/get-by-val-out-of-bounds-basics.js: Added.
(opaqueGetByValOnInt32ArrayEarlyOutOfBounds):
(testInt32ArrayEarlyOutOfBounds):
(testIndexingTypeChangesOnInt32Array):
(opaqueGetByValOnStringArrayHotOutOfBounds):
(testStringArrayHotOutOfBounds):
(testIndexingTypeChangesOnStringArray):
(opaqueGetByValOnStringAndInt32ArrayHotOutOfBounds):
(testStringAndInt32ArrayHotOutOfBounds):
(opaqueGetByValOnDoubleArrayHotOutOfBounds):
* tests/stress/put-by-val-out-of-bounds-basics.js: Added.
(opaquePutByValOnInt32ArrayEarlyOutOfBounds):
(testInt32ArrayEarlyOutOfBounds):
(opaquePutByValOnStringArrayHotOutOfBounds):
(testStringArrayHotOutOfBounds):
2015-06-03 Filip Pizlo <fpizlo@apple.com>
Simplify unboxing of double JSValues known to be not NaN and not Int32
https://bugs.webkit.org/show_bug.cgi?id=145618
Reviewed by Geoffrey Garen.
In many cases we know that we most likely loaded a non-NaN double value from the heap.
Prior to this patch, we would do two branches before unboxing the double. This patch
reduces this to one branch in the common case. Before:
if (is int32)
unbox int32 and convert to double
else if (is number)
unbox double
else
exit
After:
tmp = unbox double
if (tmp == tmp)
done
else if (is int32)
unbox int32 and convert to double
else
exit
We only use the new style if we have profiling that tells us that we are unlikely to see
either Int32 or NaN - since we will now exit on NaN and int32 requires an extra branch.
This is a 8% speed-up on Octane/box2d. On one microbenchmark this is a 25% speed-up.
Rolling this back in after I made DFG::SpeculativeJIT call a new version of unboxDouble()
that doesn't assert that the JSValue is a double, since we are intentionally using it
before doing the "is a double" test. This wasn't a problem on 32-bit since unboxDouble()
does no such assertion on 32-bit.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::observeUseKindOnNode):
(JSC::DFG::FixupPhase::fixEdgeRepresentation):
(JSC::DFG::FixupPhase::injectTypeConversionsForEdge):
* dfg/DFGNode.h:
(JSC::DFG::Node::shouldSpeculateDouble):
(JSC::DFG::Node::shouldSpeculateDoubleReal):
(JSC::DFG::Node::shouldSpeculateNumber):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::SafeToExecuteEdge::operator()):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileDoubleRep):
(JSC::DFG::SpeculativeJIT::speculateNumber):
(JSC::DFG::SpeculativeJIT::speculateRealNumber):
(JSC::DFG::SpeculativeJIT::speculateDoubleRepReal):
(JSC::DFG::SpeculativeJIT::speculate):
(JSC::DFG::SpeculativeJIT::speculateDoubleReal): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGUseKind.cpp:
(WTF::printInternal):
* dfg/DFGUseKind.h:
(JSC::DFG::typeFilterFor):
(JSC::DFG::isNumerical):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileDoubleRep):
(JSC::FTL::LowerDFGToLLVM::boxDouble):
(JSC::FTL::LowerDFGToLLVM::jsValueToStrictInt52):
(JSC::FTL::LowerDFGToLLVM::speculate):
(JSC::FTL::LowerDFGToLLVM::speculateNumber):
(JSC::FTL::LowerDFGToLLVM::speculateRealNumber):
(JSC::FTL::LowerDFGToLLVM::speculateDoubleRepReal):
(JSC::FTL::LowerDFGToLLVM::jsValueToDouble): Deleted.
(JSC::FTL::LowerDFGToLLVM::speculateDoubleReal): Deleted.
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::branchIfNotOther):
(JSC::AssemblyHelpers::branchIfInt32):
(JSC::AssemblyHelpers::branchIfNotInt32):
(JSC::AssemblyHelpers::branchIfNumber):
2015-06-04 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Class constructor appearing as Object Tree property does not include parameters
https://bugs.webkit.org/show_bug.cgi?id=145661
Reviewed by Timothy Hatcher.
* inspector/InjectedScriptSource.js:
(InjectedScript.prototype._classPreview):
(InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
The string we will return for previews of class constructor functions.
(InjectedScript.RemoteObject):
(InjectedScript.RemoteObject.prototype._describe):
No longer return the class name as the description string.
Instead return the class name for the RemoteObject.className.
2015-06-04 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r185216.
https://bugs.webkit.org/show_bug.cgi?id=145666
it caused a bunch of debug crashes (Requested by pizlo on
#webkit).
Reverted changeset:
"Simplify unboxing of double JSValues known to be not NaN and
not Int32"
https://bugs.webkit.org/show_bug.cgi?id=145618
http://trac.webkit.org/changeset/185216
2015-06-03 Filip Pizlo <fpizlo@apple.com>
Simplify unboxing of double JSValues known to be not NaN and not Int32
https://bugs.webkit.org/show_bug.cgi?id=145618
Reviewed by Geoffrey Garen.
In many cases we know that we most likely loaded a non-NaN double value from the heap.
Prior to this patch, we would do two branches before unboxing the double. This patch
reduces this to one branch in the common case. Before:
if (is int32)
unbox int32 and convert to double
else if (is number)
unbox double
else
exit
After:
tmp = unbox double
if (tmp == tmp)
done
else if (is int32)
unbox int32 and convert to double
else
exit
We only use the new style if we have profiling that tells us that we are unlikely to see
either Int32 or NaN - since we will now exit on NaN and int32 requires an extra branch.
This is a 8% speed-up on Octane/box2d. On one microbenchmark this is a 25% speed-up.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::observeUseKindOnNode):
(JSC::DFG::FixupPhase::fixEdgeRepresentation):
(JSC::DFG::FixupPhase::injectTypeConversionsForEdge):
* dfg/DFGNode.h:
(JSC::DFG::Node::shouldSpeculateDouble):
(JSC::DFG::Node::shouldSpeculateDoubleReal):
(JSC::DFG::Node::shouldSpeculateNumber):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::SafeToExecuteEdge::operator()):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileDoubleRep):
(JSC::DFG::SpeculativeJIT::speculateNumber):
(JSC::DFG::SpeculativeJIT::speculateRealNumber):
(JSC::DFG::SpeculativeJIT::speculateDoubleRepReal):
(JSC::DFG::SpeculativeJIT::speculate):
(JSC::DFG::SpeculativeJIT::speculateDoubleReal): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGUseKind.cpp:
(WTF::printInternal):
* dfg/DFGUseKind.h:
(JSC::DFG::typeFilterFor):
(JSC::DFG::isNumerical):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileDoubleRep):
(JSC::FTL::LowerDFGToLLVM::boxDouble):
(JSC::FTL::LowerDFGToLLVM::jsValueToStrictInt52):
(JSC::FTL::LowerDFGToLLVM::speculate):
(JSC::FTL::LowerDFGToLLVM::speculateNumber):
(JSC::FTL::LowerDFGToLLVM::speculateRealNumber):
(JSC::FTL::LowerDFGToLLVM::speculateDoubleRepReal):
(JSC::FTL::LowerDFGToLLVM::jsValueToDouble): Deleted.
(JSC::FTL::LowerDFGToLLVM::speculateDoubleReal): Deleted.
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::branchIfNotOther):
(JSC::AssemblyHelpers::branchIfInt32):
(JSC::AssemblyHelpers::branchIfNotInt32):
(JSC::AssemblyHelpers::branchIfNumber):
2015-06-04 Filip Pizlo <fpizlo@apple.com>
SideState should be a distinct abstract heap from Heap and Stack
https://bugs.webkit.org/show_bug.cgi?id=145653
Reviewed by Geoffrey Garen.
Before, SideState fit into the hierarchy like so:
World
|
+-- Stack
|
+-- Heap
|
+-- SideState
Now we will have:
World
|
+-- Stack
|
+-- Heap
|
+-- SideState
This makes it easy to ask if a writing operation wrote to anything that is observable even
if we don't exit. SideState is only observable if we exit.
* dfg/DFGAbstractHeap.h:
(JSC::DFG::AbstractHeap::AbstractHeap):
(JSC::DFG::AbstractHeap::supertype):
2015-06-04 Chris Dumez <cdumez@apple.com>
[WK2] Prune more resources from the MemoryCache before process suspension
https://bugs.webkit.org/show_bug.cgi?id=145633
Reviewed by Andreas Kling.
No longer move protect IncrementalSweeper::fullSweep() behind
USE(CF) so we don't need #ifdefs at call sites, similarly to what is
done for the rest of the IncrementalSweeper API.
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::fullSweep):
* heap/IncrementalSweeper.h:
2015-06-01 Filip Pizlo <fpizlo@apple.com>
CallLinkStatus should return takesSlowPath if the GC often cleared the IC
https://bugs.webkit.org/show_bug.cgi?id=145502
Reviewed by Geoffrey Garen.
CallLinkInfo now remembers when it has been cleared by GC. This has some safeguards for when
a call gets cleared by GC only because we hadn't converted it into a closure call; in that
case the GC will just tell us that it should be a closure call. The DFG will not optimize
a call that was cleared by GC, and the DFG will always prefer a closure call if the GC told
us that the specific callee was dead but the executable wasn't.
This guards us from some scenarios that came up in Speedometer. It's neutral on the pure JS
benchmarks, most likely just because those benchmarks aren't real enough to have interesting
GC of code.
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::visitWeak):
(JSC::CallLinkInfo::dummy):
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::CallLinkInfo):
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFromCallLinkInfo):
2015-06-02 Filip Pizlo <fpizlo@apple.com>
GetById and PutById profiling should be more precise about it takes slow path
https://bugs.webkit.org/show_bug.cgi?id=145590
Reviewed by Geoffrey Garen.
If a ById access ever takes slow path, we want the DFG and FTL to know this. Previously we
were relying on slow path counts, which conflate slow paths taken due to a megamorphic
access and slow paths taken due to IC building.
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFor):
(JSC::GetByIdStatus::computeForStubInfo):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFor):
(JSC::PutByIdStatus::computeForStubInfo):
* bytecode/StructureStubInfo.h:
(JSC::StructureStubInfo::StructureStubInfo):
* ftl/FTLIntrinsicRepository.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileGetById):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
2015-06-03 Michael Saboff <msaboff@apple.com>
Improve test coverage for changes made in 145527
https://bugs.webkit.org/show_bug.cgi?id=145578
Reviewed by Geoffrey Garen.
Added more complexity to poly-setter-combo.js stress test to create more turmoil in the
polymorphic get-by-id / put-by-id with getters and setters to exercise the code change in
https://bugs.webkit.org/show_bug.cgi?id=145527. By changing the objects that the main test
function sees, we are able to test those paths. Verified with temporary logging code.
* tests/stress/poly-setter-combo.js:
(Cons2):
(Cons3):
(Cons4):
(foo):
(test):
(runTestWithConstructors):
2015-06-02 Mark Lam <mark.lam@apple.com>
Gardening: fix broken CLoop build.
Not reviewed.
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeExitSiteData):
2015-06-02 Keith Miller <keith_miller@apple.com>
JavaScriptCore: JSExport protocol with an NSInteger property converts negative values to 18446744073709552000
https://bugs.webkit.org/show_bug.cgi?id=145563
Reviewed by Darin Adler.
The Objective-C bindings were improperly converting negative
long long/NSIntegers to 18446744073709552000 because they
were converted to unsigned numbers.
* API/ObjcRuntimeExtras.h:
(parseObjCType):
* API/tests/testapi.mm:
(testObjectiveCAPIMain):
(checkNegativeNSIntegers):
(testObjectiveCAPI):
2015-06-02 Yusuke Suzuki <utatane.tea@gmail.com>
Heap-use-after-free read of size 4 in JavaScriptCore: WTF::StringImpl::isSymbol() (StringImpl.h:496)
https://bugs.webkit.org/show_bug.cgi?id=145532
Reviewed by Geoffrey Garen.
AtomicStringImpl::lookUp returns AtomicStringImpl*,
it doesn't give any ownership to the caller.
Originally, this is ok because the ownership is taken
by AtomicStringImpl's table (& the register side).
But if we would like to use this returned AtomicStringImpl*,
we should take its ownership immediately.
Because if the register side releases its ownership (ref count),
it will be destroyed.
In JSString::toExistingAtomicString, it returns AtomicStringImpl*.
But it's not appropriate.
If the owner of AtomicStringImpl* is always JSString*, it is ok.
But it looks up the table-registered AtomicStringImpl* from
the AtomicStringImpl table. So JSString* may not have the ownership
of the returned AtomicStringImpl*.
The failure situation is the following.
1. A creates AtomicStringImpl. A has its ownership.
And A registers it to AtomicStringImpl table.
2. JSString looks up the AtomicStringImpl from the table.
It gets AtomicStringImpl*. And JSString doesn't have its ownership.
It returns the raw pointer immediately to the users
3. A is released. There's no owner for AtomicStringImpl*.
So it's also destroyed.
4. Use looked up AtomicStringImpl in (2). It becomes use-after-free.
This patch fixes it by the following changes.
1. Change the signature of `AtomicStringImpl* AtomicStringImpl::lookUp(...)`
to `RefPtr<AtomicStringImpl> AtomicStringImpl::lookUp(..)`.
Use `RefPtr` because it may return `nullptr`.
2. Change the signature of `AtomicStringImpl* JSString::toExistingAtomicString(...)`
to `RefPtr<AtomicStringImpl> JSString::toExistingAtomicString(...)`.
Using `RefPtr` is the same reason.
3. Receive the result with `RefPtr<AtomicStringImpl>` in the caller side.
* dfg/DFGOperations.cpp:
* jit/JITOperations.cpp:
(JSC::getByVal):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::getByVal):
* runtime/JSString.cpp:
(JSC::JSRopeString::resolveRopeToExistingAtomicString):
* runtime/JSString.h:
(JSC::JSString::toExistingAtomicString):
2015-05-30 Filip Pizlo <fpizlo@apple.com>
Any exit from any JIT due to profiling for an inline cache should force all future compilations to be wary
https://bugs.webkit.org/show_bug.cgi?id=145496
Reviewed by Geoffrey Garen.
This pessimizes compilation a bit, but it reduces the likelihood of exiting from FTL. I
couldn't find any convincing reason not to do this, and we know from Speedometer that this
change is necessary for weirder code.
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFor):
(JSC::CallLinkStatus::computeExitSiteData):
(JSC::CallLinkStatus::computeDFGStatuses):
* bytecode/CallLinkStatus.h:
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::appendVariant):
(JSC::GetByIdStatus::hasExitSite):
(JSC::GetByIdStatus::computeFor):
* bytecode/GetByIdStatus.h:
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::appendVariant):
(JSC::PutByIdStatus::hasExitSite):
(JSC::PutByIdStatus::computeFor):
* bytecode/PutByIdStatus.h:
2015-05-31 Filip Pizlo <fpizlo@apple.com>
If a call has ever taken the virtual slow path, make sure that the DFG knows this
https://bugs.webkit.org/show_bug.cgi?id=145501
Reviewed by Geoffrey Garen.
Now now return higher fidelity information in the case of no polymorphic call stub. If the
virtual slow path was ever taken, we note this, and we note either zero or one call variant
based on the IC's last callee.
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFromCallLinkInfo):
(JSC::CallLinkStatus::computeFor):
2015-06-01 Michael Saboff <msaboff@apple.com>
Crash in com.apple.WebKit.WebContent at com.apple.JavaScriptCore: JSC::revertCall + 24
https://bugs.webkit.org/show_bug.cgi?id=145527
Reviewed by Filip Pizlo.
If a CallLinkInfo is GC'ed, we need to notify any PolymorphicCallNode's that reference it.
Added plumbling to clear the m_callLinkInfo of a PolymorphicCallNode when that CallLinkInfo
is going away.
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::~CallLinkInfo):
* jit/PolymorphicCallStubRoutine.cpp:
(JSC::PolymorphicCallNode::unlink):
(JSC::PolymorphicCallNode::clearCallLinkInfo):
(JSC::PolymorphicCallCase::dump):
(JSC::PolymorphicCallStubRoutine::edges):
(JSC::PolymorphicCallStubRoutine::clearCallNodesFor):
(JSC::PolymorphicCallStubRoutine::visitWeak):
* jit/PolymorphicCallStubRoutine.h:
(JSC::PolymorphicCallNode::hasCallLinkInfo):
2015-06-01 Mark Lam <mark.lam@apple.com>
Add the ability to tell between Catch and Finally blocks.
https://bugs.webkit.org/show_bug.cgi?id=145524
Reviewed by Michael Saboff.
... and also SynthesizedFinally blocks too. A SynthesizedFinally block
is a finally block that is synthesized by the bytecode generator but
does not actually correspond to any exception handling construct at the
JS source code level. An example of this is the "for ... of" statement
where it needs to do some "final" clean up before passing on the
exception.
Manually tested by inspecting the bytecode dump of functions with
try-catch-finally blocks as well as for of statements which have
synthesized finally blocks. The bytecode dumps contains the exception
handlers table which has these blocks labelled with their newly added
types. No automatic test because this type info is not visible to JS
code.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecode/HandlerInfo.h:
(JSC::HandlerInfoBase::type):
(JSC::HandlerInfoBase::setType):
(JSC::HandlerInfoBase::typeName):
(JSC::HandlerInfoBase::isCatchHandler):
(JSC::UnlinkedHandlerInfo::UnlinkedHandlerInfo):
(JSC::HandlerInfo::initialize):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::pushTry):
(JSC::BytecodeGenerator::popTryAndEmitCatch):
(JSC::BytecodeGenerator::emitEnumeration):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::emitThrow):
* bytecompiler/NodesCodegen.cpp:
(JSC::TryNode::emitBytecode):
2015-05-29 Geoffrey Garen <ggaren@apple.com>
REGRESSION: These sorting idioms used by Peacekeeper and Browsermark are ~20X slower
https://bugs.webkit.org/show_bug.cgi?id=145412
Reviewed by Darin Adler.
Moar speedup.
Added a bucket sort for string sorting.
* builtins/Array.prototype.js:
(sort.compactSparse):
(sort.compactSlow):
(sort.compact): Split out a compaction fast path for dense arrays. Without
it, compaction can increase sort time by 2X for simple sorts.
(sort.bucketSort):
(sort.stringSort): Use a bucket sorting algorithm if we know we're sorting
strings. This makes average case string sorting O(N) with O(N) additional
memory use.
The worst case bucket sort can require O(M * N) additional
space. We avoid this by falling back to merge sort when things are
simple or overly duplicative. These are the two cases that accumulate
excessive -- and potentially pathological -- bucketing overhead.
2015-06-01 Mark Lam <mark.lam@apple.com>
HandlerInfo::initialize() should not assume that CodeLocationLabel is available.
https://bugs.webkit.org/show_bug.cgi?id=145515
Reviewed by Csaba Osztrogonác.
CodeLocationLabel is only defined for ENABLE(ASSEMBLER) builds. r185022's
attempt at simplifying code to increase readability failed to take this into
account. This patch fixes it.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
* bytecode/HandlerInfo.h:
(JSC::HandlerInfo::initialize):
2015-05-31 Filip Pizlo <fpizlo@apple.com>
Unreviewed, add a FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=145503.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::inliningCost):
2015-05-31 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Drop WeakMap#clear
https://bugs.webkit.org/show_bug.cgi?id=145489
Reviewed by Mark Lam.
ES6 spec intentionally drops the WeakMap#clear
to allow engine to implement WeakMap as a per-object table.
This patch drops WeakMap.prototype.clear.
* runtime/WeakMapPrototype.cpp:
(JSC::WeakMapPrototype::finishCreation): Deleted.
(JSC::protoFuncWeakMapClear): Deleted.
2015-05-31 Jordan Harband <ljharb@gmail.com>
Array#reduce and reduceRight don't follow ToLength
https://bugs.webkit.org/show_bug.cgi?id=145364
Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-tolength
Reviewed by Yusuke Suzuki.
* builtins/Array.prototype.js:
(reduce):
(reduceRight):
* runtime/ArrayPrototype.cpp:
(JSC::ArrayPrototype::finishCreation):
(JSC::arrayProtoFuncReduce): Deleted.
(JSC::arrayProtoFuncReduceRight): Deleted.
2015-05-29 Filip Pizlo <fpizlo@apple.com>
FTL codegen for MultiGetByOffset and MultiPutByOffset where the structure set is already proved should have an unreachable default case instead of an exit
https://bugs.webkit.org/show_bug.cgi?id=145469
Reviewed by Geoffrey Garen.
Omitting the speculation on the fail path when the speculation is guaranteed not to be
taken hints to LLVM that the default case is impossible. This enables some useful
optimizations.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileMultiGetByOffset):
(JSC::FTL::LowerDFGToLLVM::compileMultiPutByOffset):
2015-05-29 Mark Lam <mark.lam@apple.com>
Refactoring HandlerInfo and UnlinkedHandlerInfo.
https://bugs.webkit.org/show_bug.cgi?id=145480
Reviewed by Benjamin Poulain.
HandlerInfo and UnlinkedHandlerInfo have common parts, but are not currently
expressed as 2 unrelated structs that happen to have near identical fields.
We can refactor them to better express their relationship. We can also add
some convenience functions to make the code that uses them a little more
readable.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::handlerForBytecodeOffset):
* bytecode/HandlerInfo.h:
(JSC::UnlinkedHandlerInfo::UnlinkedHandlerInfo):
(JSC::HandlerInfo::initialize):
- I chose to include CodeLocationLabel arg even though it is unused by
by non-JIT builds. This makes the call site cleaner to read.
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedSimpleJumpTable::add):
(JSC::UnlinkedInstruction::UnlinkedInstruction):
(JSC::UnlinkedCodeBlock::numberOfExceptionHandlers):
(JSC::UnlinkedCodeBlock::addExceptionHandler):
(JSC::UnlinkedCodeBlock::exceptionHandler):
(JSC::UnlinkedCodeBlock::symbolTable):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
2015-05-28 Filip Pizlo <fpizlo@apple.com>
Non-speculative Branch should be fast in the FTL
https://bugs.webkit.org/show_bug.cgi?id=145452
Reviewed by Andreas Kling.
Inlines the code for convertJSValueToBoolean into the FTL. This also includes some other
clean-ups that I found along the way.
I found this by looking at the hottest functions in DeltaBlue. Despite having so many
Branch specializations, apparently there was still a hot one that we missed that was going
down the untyped path. It was either Int32 or Other. Maybe we could specialize for that
combo, but it makes so much sense to just make all of this nonsense fast.
* dfg/DFGWatchpointCollectionPhase.cpp:
(JSC::DFG::WatchpointCollectionPhase::handle): Need to watch the masquerades watchpoint on UntypedUse: forms of Branch now.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::boolify): The actual fix.
(JSC::FTL::LowerDFGToLLVM::int52ToStrictInt52):
(JSC::FTL::LowerDFGToLLVM::isInt32):
(JSC::FTL::LowerDFGToLLVM::isNotInt32):
(JSC::FTL::LowerDFGToLLVM::unboxInt32):
* runtime/JSCellInlines.h:
(JSC::JSCell::toBoolean): Symbol is always true.
(JSC::JSCell::pureToBoolean): Symbol is always true.
* runtime/JSString.cpp:
(JSC::JSString::getPrimitiveNumber):
(JSC::JSString::toNumber):
(JSC::JSString::toBoolean): Deleted. This is a tiny method. It doesn't need to be out-of-line.
* runtime/JSString.h:
(JSC::JSString::length):
(JSC::JSString::toBoolean): This method shouldbe inline.
* runtime/Symbol.cpp:
(JSC::Symbol::toPrimitive):
(JSC::Symbol::getPrimitiveNumber):
(JSC::Symbol::toBoolean): Deleted. A Symbol is always true, so we don't need a method for this.
* runtime/Symbol.h:
2015-05-29 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r184860.
https://bugs.webkit.org/show_bug.cgi?id=145456
May have caused ~1% Octane regression (Requested by kling on
#webkit).
Reverted changeset:
"Try to use StringView when comparing JSStrings for equality."
https://bugs.webkit.org/show_bug.cgi?id=145379
http://trac.webkit.org/changeset/184860
2015-05-28 Michael Saboff <msaboff@apple.com>
mozilla/js1_5/Array/regress-154338.js test causes ARM 32 bit iOS devices to run out of memory
https://bugs.webkit.org/show_bug.cgi?id=145444
Reviewed by Geoffrey Garen.
Disabled mozilla/js1_5/Array/regress-154338.js when run on iOS ARM 32 bit devices and
the --memory-limited option is passed to run-jsc-stress-tests.
* tests/mozilla/mozilla-tests.yaml:
2015-05-28 Benjamin Poulain <benjamin@webkit.org>
[iOS8][ARMv7(s)] Optimized Object.create in 'use strict' context sometimes breaks.
https://bugs.webkit.org/show_bug.cgi?id=138038
Reviewed by Michael Saboff.
TL;DR: sometimes the baseline JIT could accidentally nuke the tag before calling
to C++, making put_by_id behave erratically.
The bug was that put_by_id would randomly not work correctly in 32bits. It happened
in the baseline JIT if we were unlucky enough:
-The code get hot enough and the structure is stable so we get a fast path for
put_by_id.
-We repatch the fast-path branch with a stub generated by
emitPutTransitionStubAndGetOldStructure().
-In emitPutTransitionStubAndGetOldStructure(), we only preserve the payload of the base
register, the tag register is ignored.
-emitPutTransitionStubAndGetOldStructure() allocate 2 to 3 registers. Any of those
could be the one used for the base's tag before the fast path and the value is trashed.
-If we hit one of the failure case, we fallback to the slow path, but we destroyed
the tag pointer.
-We now have unrelated bits in the tag, the most likely value type is now "double"
and we fail the put_by_id because we try to set a property on a number.
The most obvious solution would be to change emitPutTransitionStubAndGetOldStructure()
to preserve the tag register in addition to the value register.
I decided against that option because of the added complexity. The DFG does not need
that case, so I would have to add branches everywhere to distinguish the cases
were we need to preserve the tag or not.
Instead, I just load the tag back from memory in the slow path. The function in the slow
path is several order of magnitude slower than a load, it is not worth eliminating it,
especially in baseline JIT.
I also discovered 4 useless loads in the fast path, so even with my extra load, this patch
makes the baseline faster :)
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emitSlow_op_put_by_id):
(JSC::JIT::emit_op_put_by_id): Deleted.
* tests/stress/put-by-id-on-new-object-after-prototype-transition-non-strict.js: Added.
(opaqueNewObject):
(putValueOnNewObject):
* tests/stress/put-by-id-on-new-object-after-prototype-transition-strict.js: Added.
(string_appeared_here.opaqueNewObject):
(putValueOnNewObject):
2015-05-28 Benjamin Poulain <benjamin@webkit.org>
[JSC] reduction the iteration count of the DoubleRep stress tests
Once again, I used big numbers for manual testing and I forgot to fix them before landing.
* tests/stress/double-rep-with-non-cell.js:
* tests/stress/double-rep-with-null.js:
* tests/stress/double-rep-with-undefined.js:
2015-05-28 Basile Clement <basile_clement@apple.com>
Add debug mode assertions for accessors casting JSC::DFG::Node.m_opInfo
https://bugs.webkit.org/show_bug.cgi?id=145441
Reviewed by Filip Pizlo.
Most accessor functions casting m_opInfo in JSC::DFG::Node are
performing debug checks that they are only accessed for node types that
should have them. This patch adds similar checks for the accessors that
were missing them.
* dfg/DFGNode.h:
(JSC::DFG::Node::watchpointSet):
(JSC::DFG::Node::storagePointer):
(JSC::DFG::Node::multiGetByOffsetData):
(JSC::DFG::Node::multiPutByOffsetData):
(JSC::DFG::Node::hasTypeLocation):
(JSC::DFG::Node::typeLocation):
(JSC::DFG::Node::hasBasicBlockLocation):
(JSC::DFG::Node::basicBlockLocation):
2015-05-28 Matt Rajca <mrajca@apple.com>
Add ENABLE_MEDIA_SESSION feature flag (which is off by default).
https://bugs.webkit.org/show_bug.cgi?id=145415
Reviewed by Eric Carlson.
* Configurations/FeatureDefines.xcconfig:
2015-05-27 Jordan Harband <ljharb@gmail.com>
Array.of should work with other constructors
https://bugs.webkit.org/show_bug.cgi?id=145365
Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.of
step 4
Reviewed by Yusuke Suzuki.
* builtins/ArrayConstructor.js:
(of):
* runtime/ArrayConstructor.cpp:
(JSC::arrayConstructorOf): Deleted.
2015-05-27 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add undefined->double conversion to DoubleRep
https://bugs.webkit.org/show_bug.cgi?id=145293
Reviewed by Filip Pizlo.
This patch adds undefined to double conversion to the DoubleRep
node for the cases were we speculate "undefined" as part of the types
processed.
The use case is doing math with accidental out-of-bounds access. For example,
something like:
for (var i = 0; i <= length; ++i)
ouptput += array[i];
would cause us to OSR exit every time i === length.
When hitting one of those cases, we would already speculate double math,
but the DoubleRep node was unable to convert the undefined and would exit.
With this patch the use kind NotCellUse cover this conversion for DoubleRep.
I have been quite conservative so in general we will not find "undefined"
until a few recompile but being optimistic seems better since this is a corner case.
This patch is a 80% progression on WebXPRT's DNA Sequencing test.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::injectTypeConversionsForEdge):
* dfg/DFGNode.h:
(JSC::DFG::Node::sawUndefined):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::SafeToExecuteEdge::operator()):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileDoubleRep):
* dfg/DFGUseKind.cpp:
(WTF::printInternal):
* dfg/DFGUseKind.h:
(JSC::DFG::typeFilterFor):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileDoubleRep):
(JSC::FTL::LowerDFGToLLVM::jsValueToDouble):
* tests/stress/double-rep-with-undefined.js: Added.
(addArgsNumberAndUndefined):
(addArgsInt32AndUndefined):
(testFallbackWithDouble):
(addArgsDoubleAndUndefined):
(testFallbackWithObject.):
(testFallbackWithObject):
(addArgsOnlyUndefined):
(testFallbackWithString):
2015-05-27 Dean Jackson <dino@apple.com>
img.currentSrc problem in strict mode with old picturefill
https://bugs.webkit.org/show_bug.cgi?id=144095
<rdar://problem/21087013>
Reviewed by Simon Fraser.
Add a PICTURE_SIZES flag.
* Configurations/FeatureDefines.xcconfig:
2015-05-27 Basile Clement <basile_clement@apple.com>
LazyNode comparison can return incorrect results when comparing an empty value
https://bugs.webkit.org/show_bug.cgi?id=145421
Reviewed by Geoffrey Garen.
When comparing a LazyNode to another, we compare the value pointers if
we have one, and otherwise compare the nodes.
We should be comparing value pointers if the other LazyNode has one as
well, otherwise we risk an incoherency when we are a empty LazyNode
being compared to a FrozenValue without node.
Note that this is not a problem in any other case because if we don't
have a FrozenValue and we are not an empty LazyNode, we are a
non-constant node, and comparing the node pointers is correct.
* dfg/DFGLazyNode.h:
(JSC::DFG::LazyNode::operator==):
2015-05-27 Geoffrey Garen <ggaren@apple.com>
REGRESSION: These sorting idioms used by Peacekeeper and Browsermark are ~20X slower
https://bugs.webkit.org/show_bug.cgi?id=145412
Reviewed by Benjamin Poulain.
Cache strings when doing a string-converting sort.
This is a 21% speedup.
* builtins/Array.prototype.js:
(sort.stringComparator): Use subtraction instead of branching because
it's slightly faster.
(sort.comparatorSort):
(sort.stringSort):
(sort): Add a special case for string sorting to avoid redundant string
conversion.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::createBindingPattern): Names can be empty if
they are private names.
2015-05-26 Filip Pizlo <fpizlo@apple.com>
JIT-generated store barrier code should assume the buffer pointer and capacity to be compile-time constants
https://bugs.webkit.org/show_bug.cgi?id=145404
Reviewed by Andreas Kling.
We never change the capacity of a write barrier buffer. We never repoint the buffer
pointer. So, the JIT shouldn't load those from memory; it should take advantage of the
fact that these are compile-time constants.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::storeToWriteBarrierBuffer):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::emitStoreBarrier):
* heap/WriteBarrierBuffer.h:
(JSC::WriteBarrierBuffer::currentIndexAddress):
(JSC::WriteBarrierBuffer::capacity):
(JSC::WriteBarrierBuffer::buffer):
(JSC::WriteBarrierBuffer::currentIndexOffset): Deleted.
(JSC::WriteBarrierBuffer::capacityOffset): Deleted.
(JSC::WriteBarrierBuffer::bufferOffset): Deleted.
* jit/Repatch.cpp:
(JSC::emitPutTransitionStubAndGetOldStructure):
2015-05-27 Geoffrey Garen <ggaren@apple.com>
REGRESSION: These sorting idioms used by Peacekeeper and Browsermark are ~20X slower
https://bugs.webkit.org/show_bug.cgi?id=145412
Reviewed by Darin Adler.
Use @toString instead of the String constructor because calls to the
String constructor are never optimized. (See
https://bugs.webkit.org/show_bug.cgi?id=144458.)
This is a ~2X speedup.
* builtins/Array.prototype.js:
(sort.stringComparator):
2015-05-27 Dan Bernstein <mitz@apple.com>
Remove JSC_OBJC_API_AVAILABLE_MAC_OS_X_1080
https://bugs.webkit.org/show_bug.cgi?id=145403
Reviewed by Anders Carlsson.
JSC_OBJC_API_AVAILABLE_MAC_OS_X_1080 was used to enable the JavaScriptCore Objective-C API
for WebKit and Safari projects building with JavaScriptCore targeting OS X 10.8. We don’t
need it anymore.
* API/JSBase.h:
* API/JSContext.h:
* API/JSManagedValue.h:
* API/JSValue.h:
* API/JSVirtualMachine.h:
* Configurations/Base.xcconfig:
* postprocess-headers.sh:
2015-05-26 Geoffrey Garen <ggaren@apple.com>
Photo Booth hangs under JSC::MachineThreads::tryCopyOtherThreadStacks
https://bugs.webkit.org/show_bug.cgi?id=145395
Reviewed by Mark Hahnenberg.
No test case because we already have --threaded mode, which runs lots of
parallel GC, but it (and the original in-app test case) can't reproduce
this bug.
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::tryCopyOtherThreadStacks): Use a lock to prevent
two threads from mutually suspending each other.
2015-05-26 Yusuke Suzuki <utatane.tea@gmail.com>
Add Array.prototype.copyWithin to JSC features.json
https://bugs.webkit.org/show_bug.cgi?id=145387
Reviewed by Darin Adler.
* features.json:
2015-05-26 Yusuke Suzuki <utatane.tea@gmail.com>
Reflect nits for r184863
https://bugs.webkit.org/show_bug.cgi?id=145107
Reviewed by Darin Adler.
1. Added the copyright line.
2. Added an optional argument (/*, end */). To do so, fixed generate-js-builtins.
3. Dropped the unnecessary variable `thisValue`.
4. Fix the type error messages. This is also found in StringIterator.prototype.js.
5. Added tests for 0 arguments.
* builtins/Array.prototype.js:
(copyWithin):
* builtins/StringIterator.prototype.js:
(next):
* generate-js-builtins:
* tests/stress/array-copywithin.js:
* tests/stress/string-iterators.js:
2015-05-26 Yusuke Suzuki <utatane.tea@gmail.com>
Inline @Array / @Object callsites
https://bugs.webkit.org/show_bug.cgi?id=145382
Reviewed by Geoffrey Garen.
As the same to Array/Object callsite inlining, @Array/@Object also
should be inlined in bytecode level.
While `new @Object` style is not encouraged in the builtins,
`@Array(len)` is already used at least in Array.from code.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::expectedFunctionForIdentifier):
2015-05-26 Andreas Kling <akling@apple.com>
String.prototype.charCodeAt() should use StringView.
<https://webkit.org/b/145353>
Reviewed by Darin Adler.
Use JSString::view() in charCodeAt() to avoid reifying the JSString if it's
a substring. This avoids StringImpl allocation in some cases and ref churn
in all cases.
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncCharCodeAt):
2015-05-26 Andreas Kling <akling@apple.com>
String.prototype.charAt() should use StringView.
<https://webkit.org/b/145352>
Reviewed by Darin Adler.
Remove the jsSingleCharacterSubstring() function since it's actually completely
counter-productive: it could create a single-character string that would retain
a much larger string for the duration of its lifetime.
This made sense before StringImpl learned to put its characters at the tail end
of its own allocation. Now that it does, it's far better to just create a new
single-character StringImpl.
With that out of the way, we can make String.prototype.charAt() use StringView
to avoid reifying substring JSStrings (and avoid some ref churn too.)
* runtime/JSString.cpp:
(JSC::JSRopeString::getIndexSlowCase):
* runtime/JSString.h:
(JSC::JSString::getIndex):
(JSC::jsSingleCharacterSubstring): Deleted.
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncCharAt):
(JSC::stringProtoFuncSplit):
2015-05-26 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement Array.prototype.copyWithin
https://bugs.webkit.org/show_bug.cgi?id=145107
Reviewed by Darin Adler.
This patch implements ES6 Array.prototype.copyWithin.
It is intended to be used for copying the region to the other region
in the callee array itself safely (like memmove, not memcpy).
This function is proposed in the context of WebGL.
* builtins/Array.prototype.js:
(.maxWithPositives):
(.minWithMaybeNegativeZeroAndPositive):
(copyWithin):
* runtime/ArrayPrototype.cpp:
(JSC::ArrayPrototype::finishCreation):
* tests/stress/array-copywithin.js: Added.
(shouldBe):
(shouldBeArray):
(shouldThrow):
(arrayToObject):
(valueOf):
2015-05-26 Dan Bernstein <mitz@apple.com>
<rdar://problem/21104551> Update build settings
Reviewed by Anders Carlsson.
* Configurations/DebugRelease.xcconfig:
* Configurations/FeatureDefines.xcconfig:
* Configurations/Version.xcconfig:
2015-05-26 Andreas Kling <akling@apple.com>
Try to use StringView when comparing JSStrings for equality.
<https://webkit.org/b/145379>
Reviewed by Darin Adler.
Use JSString::view() when sending two JSStrings to WTF::equal()
for comparison. This avoids creating new objects in the case where
the strings are actually substrings.
* jit/JITOperations.cpp:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::equalSlowCaseInline):
(JSC::JSValue::strictEqualSlowCaseInline):
2015-05-26 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Generate put_by_val_direct for indexed identifiers instead of put_by_id with direct postfix
https://bugs.webkit.org/show_bug.cgi?id=145360
Reviewed by Darin Adler.
JSObject::putDirect only accepts non-indexed properties.
So when generating put_by_id (with direct postfix) for indexed property,
we should generate put_by_val_direct instead.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitDirectPutById):
* bytecompiler/NodesCodegen.cpp:
(JSC::PropertyListNode::emitPutConstantProperty):
* tests/stress/put-by-id-direct-should-be-done-for-non-index-property.js: Added.
2015-05-24 Jordan Harband <ljharb@gmail.com>
Array#findIndex/find should not skip holes
https://bugs.webkit.org/show_bug.cgi?id=145361
per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.findindex
and https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.find
Reviewed by Yusuke Suzuki.
* builtins/Array.prototype.js:
(find): Deleted.
(findIndex): Deleted.
2015-05-24 Brian J. Burg <burg@cs.washington.edu>
Web Inspector: Uncaught exception when using Inspect tool on SVG elements
https://bugs.webkit.org/show_bug.cgi?id=145363
Reviewed by Joseph Pecoraro.
The injected script failed by chaining a call to String.prototype.trim to the result of
SVG*Element.className, which is an SVGAnimatedString and lacks useful methods. So, obtain
the class name using Node.getAttribute, which always returns a DOMString.
* inspector/InjectedScriptSource.js:
(InjectedScriptSource.prototype._getDescription): use getAttribute instead of className.
2015-05-23 Dan Bernstein <mitz@apple.com>
Remove unused definitions of WEBKIT_VERSION_MIN_REQUIRED
https://bugs.webkit.org/show_bug.cgi?id=145345
Reviewed by Sam Weinig.
* Configurations/Base.xcconfig: Also changed to use $(inherited).
2015-05-23 Yusuke Suzuki <utatane.tea@gmail.com>
Introduce UniquedStringImpl and SymbolImpl to separate symbolic strings from AtomicStringImpl
https://bugs.webkit.org/show_bug.cgi?id=144848
Reviewed by Darin Adler.
Use UniquedStringImpl, SymbolImpl and AtomicStringImpl.
* API/JSCallbackObject.h:
* builtins/BuiltinNames.h:
(JSC::BuiltinNames::isPrivateName):
* bytecode/BytecodeIntrinsicRegistry.h:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
* bytecode/ComplexGetStatus.cpp:
(JSC::ComplexGetStatus::computeFor):
* bytecode/ComplexGetStatus.h:
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFromLLInt):
(JSC::GetByIdStatus::computeFor):
(JSC::GetByIdStatus::computeForStubInfo):
* bytecode/GetByIdStatus.h:
* bytecode/Instruction.h:
(JSC::Instruction::Instruction):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
(JSC::PutByIdStatus::computeFor):
(JSC::PutByIdStatus::computeForStubInfo):
* bytecode/PutByIdStatus.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::visibleNameForParameter):
(JSC::BytecodeGenerator::hasConstant):
(JSC::BytecodeGenerator::addConstant):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::PropertyListNode::emitBytecode):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGDesiredIdentifiers.cpp:
(JSC::DFG::DesiredIdentifiers::addLazily):
(JSC::DFG::DesiredIdentifiers::at):
(JSC::DFG::DesiredIdentifiers::reallyAdd):
* dfg/DFGDesiredIdentifiers.h:
(JSC::DFG::DesiredIdentifiers::operator[]):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::isStringPrototypeMethodSane):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileIn):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::identifierUID):
(JSC::DFG::SpeculativeJIT::callOperation):
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLInlineCacheDescriptor.h:
(JSC::FTL::InlineCacheDescriptor::InlineCacheDescriptor):
(JSC::FTL::InlineCacheDescriptor::uid):
(JSC::FTL::GetByIdDescriptor::GetByIdDescriptor):
(JSC::FTL::PutByIdDescriptor::PutByIdDescriptor):
(JSC::FTL::CheckInDescriptor::CheckInDescriptor):
* ftl/FTLIntrinsicRepository.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compilePutById):
(JSC::FTL::LowerDFGToLLVM::compileIn):
(JSC::FTL::LowerDFGToLLVM::compileMaterializeCreateActivation):
(JSC::FTL::LowerDFGToLLVM::getById):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
* ftl/FTLSlowPathCall.cpp:
(JSC::FTL::callOperation):
* ftl/FTLSlowPathCall.h:
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* parser/Nodes.cpp:
(JSC::ProgramNode::setClosedVariables):
* parser/Nodes.h:
(JSC::ScopeNode::captures):
(JSC::ScopeNode::setClosedVariables):
(JSC::ProgramNode::closedVariables):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::didFinishParsing):
(JSC::Parser<LexerType>::parseContinueStatement):
* parser/Parser.h:
(JSC::Scope::Scope):
(JSC::Scope::pushLabel):
(JSC::Scope::getLabel):
(JSC::Scope::declareCallee):
(JSC::Scope::declareVariable):
(JSC::Scope::declareParameter):
(JSC::Scope::declareBoundParameter):
(JSC::Scope::useVariable):
(JSC::Scope::copyCapturedVariablesToVector):
(JSC::Parser::closedVariables):
(JSC::ScopeLabelInfo::ScopeLabelInfo): Deleted.
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::usedVariables):
(JSC::SourceProviderCacheItem::writtenVariables):
(JSC::SourceProviderCacheItem::create):
* runtime/CommonIdentifiers.cpp:
(JSC::CommonIdentifiers::isPrivateName):
* runtime/CommonIdentifiers.h:
* runtime/Identifier.h:
(JSC::Identifier::impl):
(JSC::Identifier::Identifier):
(JSC::parseIndex):
(JSC::IdentifierRepHash::hash):
* runtime/IdentifierInlines.h:
(JSC::Identifier::fromUid):
* runtime/IntendedStructureChain.cpp:
(JSC::IntendedStructureChain::mayInterceptStoreTo):
* runtime/IntendedStructureChain.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/Lookup.h:
(JSC::HashTable::entry):
* runtime/MapData.h:
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorGetOwnPropertySymbols):
* runtime/PrivateName.h:
(JSC::PrivateName::PrivateName):
(JSC::PrivateName::uid):
* runtime/PropertyMapHashTable.h:
* runtime/PropertyName.h:
(JSC::PropertyName::PropertyName):
(JSC::PropertyName::uid):
(JSC::PropertyName::publicName):
(JSC::parseIndex):
* runtime/PropertyNameArray.h:
(JSC::PropertyNameArray::addKnownUnique):
(JSC::PropertyNameArray::add):
* runtime/Structure.cpp:
(JSC::StructureTransitionTable::contains):
(JSC::StructureTransitionTable::get):
(JSC::StructureTransitionTable::add):
(JSC::Structure::addPropertyTransitionToExistingStructureImpl):
(JSC::Structure::addPropertyTransitionToExistingStructureConcurrently):
(JSC::Structure::getConcurrently):
(JSC::Structure::add):
(JSC::Structure::remove):
(JSC::Structure::toStructureShape):
* runtime/Structure.h:
(JSC::PropertyMapEntry::PropertyMapEntry):
* runtime/StructureInlines.h:
(JSC::Structure::getConcurrently):
* runtime/StructureTransitionTable.h:
(JSC::StructureTransitionTable::Hash::hash):
* runtime/Symbol.cpp:
(JSC::Symbol::Symbol):
* runtime/Symbol.h:
* runtime/SymbolConstructor.cpp:
(JSC::symbolConstructorFor):
(JSC::symbolConstructorKeyFor):
* runtime/SymbolTable.cpp:
(JSC::SymbolTable::uniqueIDForVariable):
(JSC::SymbolTable::globalTypeSetForVariable):
* runtime/SymbolTable.h:
* runtime/TypeSet.cpp:
(JSC::StructureShape::addProperty):
(JSC::StructureShape::propertyHash):
* runtime/TypeSet.h:
2015-05-21 Filip Pizlo <fpizlo@apple.com>
Arguments elimination phase mishandles arity check failure in its reduction of LoadVarargs to GetStack/PutStacks
https://bugs.webkit.org/show_bug.cgi?id=145298
Reviewed by Geoffrey Garen.
* dfg/DFGArgumentsEliminationPhase.cpp: Fix the bug. I restructured the loop to make it more obvious that we're initializing everything that we're supposed to initialize.
* dfg/DFGNode.h: Add a comment to clarify something I was confused about while writing this code.
* dfg/DFGPutStackSinkingPhase.cpp: Hacking on PutStacks made me think deep thoughts, and I added some FIXMEs.
* tests/stress/fold-load-varargs-arity-check-fail-barely.js: Added. This test crashes or fails before this patch.
* tests/stress/fold-load-varargs-arity-check-fail.js: Added. This is even more sure to crash or fail.
* tests/stress/simplify-varargs-mandatory-minimum-smaller-than-limit.js: Added. Not sure if we had coverage for this case before.
2015-05-22 Basile Clement <basile_clement@apple.com>
Allow DFGClobberize to return non-node constants that must be later created
https://bugs.webkit.org/show_bug.cgi?id=145272
Reviewed by Filip Pizlo.
This adds a new LazyNode class in DFG that represents either a Node*,
or a FrozenValue* with a way to convert it to a Node* provided a block
to insert it into. DFGClobberize is converted to use LazyNode instead
of Node* when def()'ing values, which allows to now define the array's
length as well as the value of its various fields in NewArray and
NewArrayBuffer nodes.
We also introduce a Vector<uint32_t> in DFG::Graph to collect all the
values that can be used as index, in order to avoid def()'ing too many
values at once for big NewArrayBuffers.
HeapLocation had to be updated to use a LazyNode as its index to be
able to define array values.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGCSEPhase.cpp:
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
(JSC::DFG::DefMethodClobberize::operator()):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::freezeFragile):
* dfg/DFGGraph.h:
* dfg/DFGHeapLocation.h:
(JSC::DFG::HeapLocation::HeapLocation):
(JSC::DFG::HeapLocation::index):
(JSC::DFG::HeapLocation::hash):
* dfg/DFGLazyNode.cpp: Added.
(JSC::DFG::LazyNode::dump):
* dfg/DFGLazyNode.h: Added.
(JSC::DFG::LazyNode::LazyNode):
(JSC::DFG::LazyNode::setNode):
(JSC::DFG::LazyNode::isHashTableDeletedValue):
(JSC::DFG::LazyNode::isNode):
(JSC::DFG::LazyNode::op):
(JSC::DFG::LazyNode::asNode):
(JSC::DFG::LazyNode::asValue):
(JSC::DFG::LazyNode::hash):
(JSC::DFG::LazyNode::operator==):
(JSC::DFG::LazyNode::operator!=):
(JSC::DFG::LazyNode::ensureIsNode):
(JSC::DFG::LazyNode::operator->):
(JSC::DFG::LazyNode::operator*):
(JSC::DFG::LazyNode::operator!):
(JSC::DFG::LazyNode::operator UnspecifiedBoolType*):
(JSC::DFG::LazyNode::setFrozenValue):
* dfg/DFGPreciseLocalClobberize.h:
(JSC::DFG::PreciseLocalClobberizeAdaptor::def):
* dfg/DFGPutStackSinkingPhase.cpp:
2015-05-22 Andreas Kling <akling@apple.com>
[JSC] Speed up new array construction in Array.prototype.splice().
<https://webkit.org/b/145303>
Reviewed by Benjamin Poulain.
Give splice() a fast path just like slice(), for indexing types where the backing
store can be memcpy'd. I generalized JSArray::fastSlice() a little bit so it works
for this optimization as well.
7% progression on Kraken/stanford-crypto-pbkdf2.
* runtime/JSArray.h:
* runtime/JSArray.cpp:
(JSC::JSArray::fastSlice): Tweak this to return JSArray*, and don't bother throwing
out-of-memory exceptions. Let the caller worry about that.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncSlice): Update for fastSlice() changes.
(JSC::arrayProtoFuncSplice): If the object we're splicing out of is a bona fide
JSArray, use fastSlice() to create the returned array instead of doing a generic
get/put loop.
2015-05-21 Filip Pizlo <fpizlo@apple.com>
CPS rethreading should really get rid of GetLocals
https://bugs.webkit.org/show_bug.cgi?id=145290
Reviewed by Benjamin Poulain.
CPS rethreading is intended to get rid of redundant GetLocals. CSE can also do it, but
the idea is that you should be able to disable CSE and everything would still work. This
fixes a bug in CPS rethreading's GetLocal elimination: we should be calling replaceWith
rather than setReplacement, since setReplacement still leaves the original node.
* dfg/DFGCPSRethreadingPhase.cpp:
(JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor): Fix the bug.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode): Eliminating GetLocals means that they turn into Check. We should handle Checks that have zero inputs.
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::validateCPS): Add a validation for what a GetLocal should look like in ThreadedCPS.
* tests/stress/get-local-elimination.js: Added.
(foo):
2015-05-21 Saam Barati <saambarati1@gmail.com>
Object allocation sinking phase should explicitly create bottom values for CreateActivation sink candidates and CreateActivation should have SymbolTable as a child node
https://bugs.webkit.org/show_bug.cgi?id=145192
Reviewed by Filip Pizlo.
When we sink CreateActivation and generate MaterializeCreateActivation
in the object allocation sinking phase, we now explictly add PutHints for
all variables on the activation setting those variables to their default value
(undefined for Function activations and soon to be JS Empty Value for block scope activations).
This allows us to remove code that fills FTL fast activation allocations with Undefined.
This patch also adds the constant SymbolTable as an OpInfo of CreateActivation and MaterializeCreateActivation
nodes. This is in preparation for ES6 block scoping which will introduce a new
op code that gets lowered to CreateActivation.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasCellOperand):
(JSC::DFG::Node::cellOperand):
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
(JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
(JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
(JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
* dfg/DFGPromotedHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGPromotedHeapLocation.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCreateActivation):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileCreateActivation):
(JSC::FTL::LowerDFGToLLVM::compileMaterializeCreateActivation):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
* tests/stress/activation-sink-default-value.js: Added.
(bar):
* tests/stress/activation-sink-osrexit-default-value.js: Added.
(foo.set result):
2015-05-21 Per Arne Vollan <peavo@outlook.com>
MSVC internal compiler error when compiling TemplateRegistryKey class.
https://bugs.webkit.org/show_bug.cgi?id=145259
Reviewed by Alex Christensen.
MSVC is not able to handle the brace initialization of a class member in this case.
* runtime/TemplateRegistryKey.h:
2015-05-21 Csaba Osztrogonác <ossy@webkit.org>
Fix the !ENABLE(ES6_TEMPLATE_LITERAL_SYNTAX) build after r184337
https://bugs.webkit.org/show_bug.cgi?id=145248
Reviewed by Yusuke Suzuki.
* bytecompiler/BytecodeGenerator.cpp:
* bytecompiler/BytecodeGenerator.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseMemberExpression):
2015-05-20 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: array previews should have a much smaller cap on values
https://bugs.webkit.org/show_bug.cgi?id=145195
Reviewed by Timothy Hatcher.
* inspector/InjectedScriptSource.js:
(InjectedScript.RemoteObject.prototype._generatePreview):
Reduce the indexes threshold for previews.
2015-05-20 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Use native Arguments detection instead of using toString
https://bugs.webkit.org/show_bug.cgi?id=145235
Reviewed by Timothy Hatcher.
* inspector/InjectedScriptSource.js:
(InjectedScript.prototype._subtype):
Deleted the old string code.
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::subtype):
Replaced with a stricter, more accurate check.
2015-05-20 Andreas Kling <akling@apple.com>
Remove unused MarkedBlock::m_rememberedSet.
<https://webkit.org/b/145224>
Reviewed by Mark Hahnenberg.
The MarkedBlock had a copy of the remembered bit for each of its cells,
and we were maintaining that bitmap despite no one actually ever consulting it.
This patch removes MarkedBlock::m_rememberedSet, freeing up 128 bytes in each
block and making write barriers a little faster.
* heap/Heap.cpp:
(JSC::Heap::clearRememberedSet):
(JSC::Heap::addToRememberedSet):
* heap/HeapInlines.h:
(JSC::Heap::isRemembered):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::clearRememberedSet): Deleted.
(JSC::MarkedBlock::clearMarksWithCollectionType):
* heap/MarkedBlock.h:
(JSC::MarkedBlock::setRemembered): Deleted.
(JSC::MarkedBlock::clearRemembered): Deleted.
(JSC::MarkedBlock::atomicClearRemembered): Deleted.
(JSC::MarkedBlock::isRemembered): Deleted.
* heap/MarkedSpace.h:
(JSC::ClearRememberedSet::operator()): Deleted.
(JSC::MarkedSpace::clearRememberedSet): Deleted.
2015-05-20 Andreas Kling <akling@apple.com>
Eden collections should extend the IncrementalSweeper work list, not replace it.
<https://webkit.org/b/145213>
<rdar://problem/21002666>
Reviewed by Geoffrey Garen.
After an eden collection, the garbage collector was adding all MarkedBlocks containing
new objects to the IncrementalSweeper's work list, to make sure they didn't have to
wait until the next full collection before getting swept.
Or at least, that's what it thought it was doing. It turns out that IncrementalSweeper's
internal work list is really just a reference to Heap::m_blockSnapshot. I didn't realize
this when writing the post-eden sweep code, and instead made eden collections cancel
all pending sweeps and *replace* them with the list of blocks with new objects.
This made it so that rapidly occurring eden collections could prevent large numbers of
heap blocks from ever getting swept. This would manifest as accumulation of MarkedBlocks
when a system under heavy load was also allocating short lived objects at a high rate.
Things would eventually get cleaned up when there was a lull and a full collection was
allowed to run its heap sweep to completion.
Fix this by moving all management of the block snapshot to Heap. snapshotMarkedSpace()
now handles eden collections by merging the list of blocks with new objects into the
existing block snapshot.
* heap/Heap.cpp:
(JSC::Heap::snapshotMarkedSpace):
(JSC::Heap::notifyIncrementalSweeper):
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::startSweeping):
(JSC::IncrementalSweeper::addBlocksAndContinueSweeping): Deleted.
* heap/IncrementalSweeper.h:
2015-05-20 Youenn Fablet <youenn.fablet@crf.canon.fr>
AudioContext resume/close/suspend should reject promises with a DOM exception in lieu of throwing exceptions
https://bugs.webkit.org/show_bug.cgi?id=145064
Reviewed by Darin Adler.
Added default message for TypeError.
* runtime/Error.cpp:
(JSC::throwTypeError):
* runtime/Error.h:
2015-05-20 Joseph Pecoraro <pecoraro@apple.com>
No LLInt Test Failure: jsc-layout-tests.yaml/js/script-tests/object-literal-duplicate-properties.js.layout-no-llint
https://bugs.webkit.org/show_bug.cgi?id=145219
Reviewed by Mark Lam.
* jit/JITOperations.cpp:
Throw the error we just got, instead of a stack overflow exception.
This matches other error handling for callers of prepareForExecution.
2015-05-19 Filip Pizlo <fpizlo@apple.com>
Add some assertions about the CFG in the loop pre-header creation phase
https://bugs.webkit.org/show_bug.cgi?id=145205
Reviewed by Geoffrey Garen.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::currentNodeOrigin): Add a FIXME.
* dfg/DFGLICMPhase.cpp:
(JSC::DFG::LICMPhase::run): Add a FIXME.
* dfg/DFGLoopPreHeaderCreationPhase.cpp:
(JSC::DFG::LoopPreHeaderCreationPhase::run): Add the assertions.
2015-05-20 Joseph Pecoraro <pecoraro@apple.com>
ES6: Implement Object.setPrototypeOf
https://bugs.webkit.org/show_bug.cgi?id=145202
Reviewed by Darin Adler.
* runtime/JSGlobalObjectFunctions.h:
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncProtoSetter):
(JSC::checkProtoSetterAccessAllowed):
Extract a helper to share this code between __proto__ setter and setPrototypeOf.
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorSetPrototypeOf):
Implementation is very similiar to __proto__ setter.
2015-05-20 Joseph Pecoraro <pecoraro@apple.com>
ES6: Should not allow duplicate basic __proto__ properties in Object Literals
https://bugs.webkit.org/show_bug.cgi?id=145138
Reviewed by Darin Adler.
Implement ES6 Annex B.3.1, which disallows duplicate basic __proto__
properties in object literals. This doesn't affect computed properties,
shorthand properties, or getters/setters all of which avoid setting
the actual prototype of the object anyway.
* interpreter/Interpreter.cpp:
(JSC::eval):
Remove out of date comment. Duplicate property names are allowed
now in ES6, they were not in ES5 strict mode.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::getName):
(JSC::ASTBuilder::getType):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::getName):
Add back getName to get the property name depending on the tree builder.
Also tighten up the parameter types.
* runtime/LiteralParser.cpp:
(JSC::LiteralParser<CharType>::parse):
In quick JSON literal parsing for eval, we actually need to evaluate
the __proto__ property assignment, instead of just building up a list
of direct properties. Only do this when not doing a strict JSON parse.
* parser/Nodes.h:
Add "Shorthand" to the list of PropertyNode types to allow it to
be distinguished without relying on other information.
* parser/Parser.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseProperty):
Add the Shorthand type when parsing a shorthand property.
(JSC::Parser<LexerType>::shouldCheckPropertyForUnderscoreProtoDuplicate):
(JSC::Parser<LexerType>::parseObjectLiteral):
(JSC::Parser<LexerType>::parseStrictObjectLiteral):
Check for duplicate __proto__ properties, and throw a SyntaxError
if that was the case.
2015-05-20 Csaba Osztrogonác <ossy@webkit.org>
[JSC] Add missing copyrights and licenses for some scripts
https://bugs.webkit.org/show_bug.cgi?id=145044
Reviewed by Darin Adler.
* build-symbol-table-index.py:
* create-llvm-ir-from-source-file.py:
* create-symbol-table-index.py:
2015-05-20 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Slightly better node previews in arrays
https://bugs.webkit.org/show_bug.cgi?id=145188
Reviewed by Timothy Hatcher.
* inspector/InjectedScriptSource.js:
(InjectedScript.prototype._nodeDescription):
(InjectedScript.prototype._nodePreview):
Different stringified representations for a basic object description or in a preview.
(InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
Use the node preview string representation inside previews.
2015-05-19 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r184613 and r184614.
https://bugs.webkit.org/show_bug.cgi?id=145206
Broke 10 tests :| (Requested by kling on #webkit).
Reverted changesets:
"[JSC] Speed up URL encode/decode by using bitmaps instead of
strchr()."
https://bugs.webkit.org/show_bug.cgi?id=145115
http://trac.webkit.org/changeset/184613
"[JSC] Speed up URL encode/decode by using bitmaps instead of
strchr()."
https://bugs.webkit.org/show_bug.cgi?id=145115
http://trac.webkit.org/changeset/184614
2015-05-19 Andreas Kling <akling@apple.com>
Give StringView a utf8() API.
<https://webkit.org/b/145201>
Reviewed by Anders Carlsson.
Use JSString::view() in a few places where we couldn't before due to StringView
lacking a utf8() API. This is a minor speed-up on Kraken's crypto subtests,
which like to call encode() with substring JSStrings.
* jsc.cpp:
(functionPrint):
(functionDebug):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::encode):
2015-05-19 Andreas Kling <akling@apple.com>
[JSC] Speed up URL encode/decode by using bitmaps instead of strchr().
<https://webkit.org/b/145115>
Incorporate review feedback from Darin, removing some unnecessary zero checks.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::encode):
(JSC::decode):
(JSC::globalFuncEscape):
2015-05-19 Yusuke Suzuki <utatane.tea@gmail.com>
Move AtomicStringImpl table related operations from AtomicString to AtomicStringImpl
https://bugs.webkit.org/show_bug.cgi?id=145109
Reviewed by Darin Adler.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::nameForRegister):
* runtime/Identifier.cpp:
(JSC::Identifier::add):
(JSC::Identifier::add8):
* runtime/Identifier.h:
(JSC::Identifier::add):
* runtime/IdentifierInlines.h:
(JSC::Identifier::Identifier):
(JSC::Identifier::add):
* runtime/JSString.cpp:
(JSC::JSRopeString::resolveRopeToExistingAtomicString):
* runtime/JSString.h:
(JSC::JSString::toExistingAtomicString):
* runtime/SmallStrings.cpp:
(JSC::SmallStringsStorage::SmallStringsStorage):
* runtime/TypeSet.cpp:
(JSC::StructureShape::propertyHash):
2015-05-19 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Improve Preview for NodeList / array like collections
https://bugs.webkit.org/show_bug.cgi?id=145177
Reviewed by Timothy Hatcher.
* inspector/InjectedScriptSource.js:
(InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
For "array" like object previews skip over non-index properties.
We are not marking the object as lossless by choice, but we
may return to this decision later.
2015-05-19 Michael Saboff <msaboff@apple.com>
REGRESSION(183787): JIT is enabled for all builds
https://bugs.webkit.org/show_bug.cgi?id=145179
Reviewed by Geoffrey Garen.
Eliminated the setting of ENABLE_JIT, as wtf/Platform.h has appropriate logic to
set it depending on OS and CPU type.
* Configurations/FeatureDefines.xcconfig:
2015-05-19 Youenn Fablet <youenn.fablet@crf.canon.fr>
Rename createIterResultObject as createIteratorResultObject
https://bugs.webkit.org/show_bug.cgi?id=145116
Reviewed by Darin Adler.
Renamed createIterResultObject as createIteratorResultObject.
Made this function exportable for future use by streams API.
* runtime/IteratorOperations.cpp:
(JSC::createIteratorResultObject):
* runtime/IteratorOperations.h:
* runtime/MapIteratorPrototype.cpp:
(JSC::MapIteratorPrototypeFuncNext):
* runtime/SetIteratorPrototype.cpp:
(JSC::SetIteratorPrototypeFuncNext):
2015-05-19 Yusuke Suzuki <utatane.tea@gmail.com>
Array.prototype methods must use ToLength
https://bugs.webkit.org/show_bug.cgi?id=144128
Reviewed by Oliver Hunt.
Patch by Jordan Harband <ljharb@gmail.com> and Yusuke Suzuki <utatane.tea@gmail.com>
Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-tolength
This patch introduces ToLength and ToInteger JS implementation to encourage the DFG/FTL's inlining.
These implementations are located in GlobalObject.js.
And set to the JSGlobalObject with the private symbols @ToLength and @ToInteger manually.
* builtins/Array.prototype.js:
(every):
(forEach):
(filter):
(map):
(some):
(fill):
(find):
(findIndex):
(includes):
* builtins/ArrayConstructor.js:
(from):
* builtins/GlobalObject.js: Copied from Source/JavaScriptCore/builtins/StringConstructor.js.
(ToInteger):
(ToLength):
* builtins/StringConstructor.js:
(raw):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObjectFunctions.h:
2015-05-19 Mark Lam <mark.lam@apple.com>
Fix the build of a universal binary with ARMv7k of JavaScriptCore.
https://bugs.webkit.org/show_bug.cgi?id=145143
Reviewed by Geoffrey Garen.
The offlineasm works in 3 phases:
Phase 1:
Parse the llint asm files for config options and desired offsets.
Let's say the offlineasm discovers C unique options and O unique offsets.
The offlineasm will then generate a LLIntDesiredOffsets.h file with
C x C build configurations, each with a set of O offsets.
Each of these build configurations is given a unique configuration index number.
Phase 2:
Compile the LLIntDesiredOffsets.h file into a JSCLLIntOffsetsExtractor binary.
If we're building a fat binary with 2 configurations: armv7, and armv7k,
then the fat binary will contain 2 blobs of offsets, one for each of these
build configurations.
Phase 3:
Parse the llint asm files and emit asm code using the offsets that are
extracted from the JSCLLIntOffsetsExtractor binary for the corresponding
configuration index number.
In the pre-existing code, there are no "if ARMv7k" statements in the llint asm
source. As a result, OFFLINE_ASM_ARMv7k is not one of the config options in
the set of C unique options.
For armv7k builds, OFFLINE_ASM_ARMv7 is also true. As a result, for an armv7k
target, we will end up building armv7 source. In general, this is fine except:
1. armv7k has different alignment requirements from armv7. Hence, their offset
values (in JSCLLIntOffsetsExtractor) will be different.
2. The offlineasm was never told that it needed to make a different configuration
for armv7k builds. Hence, the armv7k build of LLIntDesiredOffsets.h will
build the armv7 configuration, and consequently, the armv7k blob of offsets in
JSCLLIntOffsetsExtractor will have the same configuration index number as
the armv7 blob of offsets.
In phase 3, when the offlineasm parses the JSCLLIntOffsetsExtractor fat binary
looking for the armv7 build's configuration index number, it discovers the
armv7k blob which has the same configuration number. As a result, it
erroneously thinks the armv7k offsets are appropriate for emitting armv7 code.
Needless to say, armv7 code using armv7k offsets will lead to incorrect behavior
and all round badness.
The fix is to add a simple "if ARMv7k" statement to the llint asm files. While
the if statement has no body, it does make the offlineasm aware of the need for
ARMv7k as a configuration option. As a result, it will generate an armv7k
variant configuration in the LLIntDesiredOffsets.h file with its own unique
configuration index number. With that, the JSCLLIntOffsetsExtractor fat binary
will no longer have duplicate configuration index numbers for the armv7 and
armv7k blobs of offsets, and the issue is resolved.
* llint/LLIntOfflineAsmConfig.h:
* llint/LowLevelInterpreter.asm:
2015-05-19 Andreas Kling <akling@apple.com>
Give JSString a StringView getter and start using it.
<https://webkit.org/b/145131>
Reviewed by Anders Carlsson.
When JSString is a substring internally, calling value(ExecState*) on it
will reify the baseString/start/length tuple into a new StringImpl.
For clients that only want to look at the characters of a JSString, but
don't actually need a reffable StringImpl, adding a light-weight StringView
getter lets them avoid constructing anything.
This patch adds JSString::view(ExecState*) and uses it in a few places.
There are many more opportunities to use this API, but let's do a few things
at a time.
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::decode):
(JSC::parseInt):
(JSC::jsToNumber):
(JSC::parseFloat):
(JSC::globalFuncParseInt):
(JSC::globalFuncParseFloat):
(JSC::globalFuncEscape):
(JSC::globalFuncUnescape):
* runtime/JSGlobalObjectFunctions.h:
* runtime/JSONObject.cpp:
(JSC::JSONProtoFuncParse):
* runtime/JSString.cpp:
(JSC::JSString::getPrimitiveNumber):
(JSC::JSString::toNumber):
* runtime/JSString.h:
(JSC::JSRopeString::view):
(JSC::JSString::view):
2015-05-18 Filip Pizlo <fpizlo@apple.com>
Better optimize 'if' with ternaries conditional tests.
https://bugs.webkit.org/show_bug.cgi?id=144136
Reviewed by Benjamin Poulain.
This is the last fix I'll do for this for now. BooleanToNumber(Untyped:) where the input
is proved to be either BoolInt32 or Boolean should be optimized to just masking the
lowest bit.
This is another 37% speed-up on JSRegress/slow-ternaries.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileBooleanToNumber):
2015-05-18 Benjamin Poulain <bpoulain@apple.com>
<rdar://problem/21003555> cloberrize() is wrong for ArithRound because it doesn't account for the arith mode
https://bugs.webkit.org/show_bug.cgi?id=145147
Reviewed by Filip Pizlo.
Really stupid bug: ArithRound nodes with different rounding modes
were not distinguished and CSE would happily unify with a node of
a different rounding mode.
DFG::clobberize() already support additional data but I was not using it.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* tests/stress/math-round-arith-rounding-mode.js: Added.
(firstCareAboutZeroSecondDoesNot):
(firstDoNotCareAboutZeroSecondDoes):
(warmup):
(verifyNegativeZeroIsPreserved):
2015-05-18 Filip Pizlo <fpizlo@apple.com>
Add SpecBoolInt32 type that means "I'm an int and I'm either 0 or 1"
https://bugs.webkit.org/show_bug.cgi?id=145137
Reviewed by Benjamin Poulain.
It's super useful to know if an integer value could be either zero or one. We have an
immediate need for this because of Int32|Boolean uses, where knowing that the Int32 is
either 0 or 1 means that there is no actual polymorphism if you just look at the low bit
(1 behaves like true, 0 behaves like false, and the low bit of 1|true is 1, and the low
bit of 0|false is 0).
We do this by splitting the SpecInt32 type into SpecBoolInt32 and SpecNonBoolInt32. This
change doesn't have any effect on behavior, yet. But it does give us the ability to
predict and prove when values are SpecBoolInt32; it's just we don't leverage this yet.
This is perf-neutral.
* bytecode/SpeculatedType.cpp:
(JSC::dumpSpeculation):
(JSC::speculationToAbbreviatedString):
(JSC::speculationFromValue):
* bytecode/SpeculatedType.h:
(JSC::isStringOrStringObjectSpeculation):
(JSC::isBoolInt32Speculation):
(JSC::isInt32Speculation):
(JSC::isInt32OrBooleanSpeculation):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2015-05-18 Michael Catanzaro <mcatanzaro@igalia.com>
[CMake] Ignore warnings in system headers
https://bugs.webkit.org/show_bug.cgi?id=144747
Reviewed by Darin Adler.
Separate include directories into WebKit project includes and system includes. Suppress all
warnings from headers in system include directories using the SYSTEM argument to
the include_directories command.
* CMakeLists.txt:
* PlatformGTK.cmake:
2015-05-18 Skachkov Alexandr <gskachkov@gmail.com>
[ES6] Arrow function syntax. Feature flag for arrow function
https://bugs.webkit.org/show_bug.cgi?id=145108
Reviewed by Ryosuke Niwa.
Added feature flag ENABLE_ES6_ARROWFUNCTION_SYNTAX for arrow function
* Configurations/FeatureDefines.xcconfig:
2015-05-18 Benjamin Poulain <benjamin@webkit.org>
[JSC] When entering a CheckTierUp without OSREntry, force the CheckTierUp for the outer loops with OSR Entry
https://bugs.webkit.org/show_bug.cgi?id=145092
Reviewed by Filip Pizlo.
When we have a hot loop without OSR Entry inside a slower loop that support OSR Entry,
we get the inside loop driving the tierUpCounter and we have very little chance of
doing a CheckTierUp on the outer loop. In turn, this give almost no opportunity to tier
up in the outer loop and OSR Enter there.
This patches changes CheckTierUp to force its outer loops to do a CheckTierUp themselves.
To do that, CheckTierUp sets a flag "nestedTriggerIsSet" to force the outer loop to
enter their CheckTierUp regardless of the tier-up counter.
* bytecode/ExecutionCounter.cpp:
(JSC::ExecutionCounter<countingVariant>::setThreshold):
This is somewhat unrelated. This assertion is incorrect because it relies on
m_counter, which changes on an other thread.
I have hit it a couple of times with this patch because we are a bit more aggressive
on CheckTierUp. What happens is:
1) ExecutionCounter<countingVariant>::checkIfThresholdCrossedAndSet() first checks
hasCrossedThreshold(), and it is false.
2) On the main thread, the hot loops keeps running and the counter becomes large
enough to cross the threshold.
3) ExecutionCounter<countingVariant>::checkIfThresholdCrossedAndSet() runs the next
test, setThreshold(), where the assertion is. Since the counter is now large enough,
the assertion fails.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGJITCode.h:
I used a uint8_t instead of a boolean to make the code generation clearer
in DFGSpeculativeJIT64.
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
This is a bit annoying: we have the NaturalLoops analysis that provides us
everything we need to know about loops, but the TierUpCheck are conservative
and set on LoopHint.
To make the two work together, we first find all the CheckTierUp that cannot
OSR enter and we keep a list of all the natural loops containing them.
Then we do a second pass over the LoopHints, get their NaturalLoop, and check
if it contains a loop that cannot OSR enter.
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGTierUpCheckInjectionPhase.cpp:
(JSC::DFG::TierUpCheckInjectionPhase::run):
(JSC::DFG::TierUpCheckInjectionPhase::canOSREnterAtLoopHint):
2015-05-18 Filip Pizlo <fpizlo@apple.com>
Add a Int-or-Boolean speculation to Branch
https://bugs.webkit.org/show_bug.cgi?id=145134
Reviewed by Benjamin Poulain.
After https://bugs.webkit.org/show_bug.cgi?id=126778 we no longer have a reason not to do the
int-or-boolean optimization that we already do everywhere else.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
2015-05-18 Andreas Kling <akling@apple.com>
[JSC] Speed up URL encode/decode by using bitmaps instead of strchr().
<https://webkit.org/b/145115>
Reviewed by Anders Carlsson.
We were calling strchr() for every character when doing URL encoding/decoding and it stood out
like a sore O(n) thumb in Instruments. Optimize this by using a Bitmap<256> instead.
5.5% progression on Kraken/stanford-crypto-sha256-iterative.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::makeCharacterBitmap):
(JSC::encode):
(JSC::decode):
(JSC::globalFuncDecodeURI):
(JSC::globalFuncDecodeURIComponent):
(JSC::globalFuncEncodeURI):
(JSC::globalFuncEncodeURIComponent):
(JSC::globalFuncEscape):
2015-05-17 Benjamin Poulain <benjamin@webkit.org>
Do not use fastMallocGoodSize anywhere
https://bugs.webkit.org/show_bug.cgi?id=145103
Reviewed by Michael Saboff.
* assembler/AssemblerBuffer.h:
(JSC::AssemblerData::AssemblerData):
(JSC::AssemblerData::grow):
2015-05-17 Benjamin Poulain <benjamin@webkit.org>
[JSC] Make StringRecursionChecker faster in the simple cases without any recursion
https://bugs.webkit.org/show_bug.cgi?id=145102
Reviewed by Darin Adler.
In general, the array targeted by Array.toString() or Array.join() are pretty
simple. In those simple cases, we spend as much time in StringRecursionChecker
as we do on the actual operation.
The reason for this is the HashSet stringRecursionCheckVisitedObjects used
to detect recursion. We are constantly adding and removing objects which
dirty buckets and force constant rehash.
This patch adds a simple shortcut for those simple case: in addition to the HashSet,
we keep a pointer to the root object of the recursion.
In the vast majority of cases, we no longer touch the HashSet at all.
This patch is a 12% progression on the overall score of ArrayWeighted.
* runtime/StringRecursionChecker.h:
(JSC::StringRecursionChecker::performCheck):
(JSC::StringRecursionChecker::~StringRecursionChecker):
* runtime/VM.h:
2015-05-17 Filip Pizlo <fpizlo@apple.com>
Insert store barriers late so that IR transformations don't have to worry about them
https://bugs.webkit.org/show_bug.cgi?id=145015
Reviewed by Geoffrey Garen.
We have had three kinds of bugs with store barriers. For the sake of discussion we say
that a store barrier is needed when we have something like:
base.field = value
- We sometimes fail to realize that we could remove a barrier when value is a non-cell.
This might happen if we prove value to be a non-cell even though in the FixupPhase it
wasn't predicted non-cell.
- We sometimes have a barrier in the wrong place after object allocation sinking. We
might sink an allocation to just above the store, but that puts it just after the
StoreBarrier that FixupPhase inserted.
- We don't remove redundant barriers across basic blocks.
This comprehensively fixes these issues by doing store barrier insertion late, and
removing the store barrier elision phase. Store barrier insertion uses an epoch-based
algorithm to determine when stores need barriers. Briefly, a barrier is not needed if
base is in the current GC epoch (i.e. was the last object that we allocated or had a
barrier since last GC) or if base has a newer GC epoch than value (i.e. value would have
always been allocated before base). We do conservative things when merging epoch state
between basic blocks, and we only do such inter-block removal in the FTL. FTL also
queries AI to determine what type we've proved about value, and avoids barriers when
value is not a cell. FixupPhase still inserts type checks on some stores, to maximize
the likelihood that this AI-based removal is effective.
Rolling back in after fixing some debug build test failures.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGBlockMap.h:
(JSC::DFG::BlockMap::at):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
* dfg/DFGEpoch.h:
(JSC::DFG::Epoch::operator<):
(JSC::DFG::Epoch::operator>):
(JSC::DFG::Epoch::operator<=):
(JSC::DFG::Epoch::operator>=):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::speculateForBarrier):
(JSC::DFG::FixupPhase::insertStoreBarrier): Deleted.
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGStoreBarrierElisionPhase.cpp: Removed.
* dfg/DFGStoreBarrierElisionPhase.h: Removed.
* dfg/DFGStoreBarrierInsertionPhase.cpp: Added.
(JSC::DFG::performFastStoreBarrierInsertion):
(JSC::DFG::performGlobalStoreBarrierInsertion):
* dfg/DFGStoreBarrierInsertionPhase.h: Added.
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR): Fix an unrelated debug-only bug.
* tests/stress/load-varargs-then-inlined-call-and-exit.js: Test for that debug-only bug.
* tests/stress/load-varargs-then-inlined-call-and-exit-strict.js: Strict version of that test.
2015-05-16 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r184415.
https://bugs.webkit.org/show_bug.cgi?id=145096
Broke several tests (Requested by msaboff on #webkit).
Reverted changeset:
"Insert store barriers late so that IR transformations don't
have to worry about them"
https://bugs.webkit.org/show_bug.cgi?id=145015
http://trac.webkit.org/changeset/184415
2015-05-14 Filip Pizlo <fpizlo@apple.com>
Insert store barriers late so that IR transformations don't have to worry about them
https://bugs.webkit.org/show_bug.cgi?id=145015
Reviewed by Geoffrey Garen.
We have had three kinds of bugs with store barriers. For the sake of discussion we say
that a store barrier is needed when we have something like:
base.field = value
- We sometimes fail to realize that we could remove a barrier when value is a non-cell.
This might happen if we prove value to be a non-cell even though in the FixupPhase it
wasn't predicted non-cell.
- We sometimes have a barrier in the wrong place after object allocation sinking. We
might sink an allocation to just above the store, but that puts it just after the
StoreBarrier that FixupPhase inserted.
- We don't remove redundant barriers across basic blocks.
This comprehensively fixes these issues by doing store barrier insertion late, and
removing the store barrier elision phase. Store barrier insertion uses an epoch-based
algorithm to determine when stores need barriers. Briefly, a barrier is not needed if
base is in the current GC epoch (i.e. was the last object that we allocated or had a
barrier since last GC) or if base has a newer GC epoch than value (i.e. value would have
always been allocated before base). We do conservative things when merging epoch state
between basic blocks, and we only do such inter-block removal in the FTL. FTL also
queries AI to determine what type we've proved about value, and avoids barriers when
value is not a cell. FixupPhase still inserts type checks on some stores, to maximize
the likelihood that this AI-based removal is effective.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGBlockMap.h:
(JSC::DFG::BlockMap::at):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
* dfg/DFGEpoch.h:
(JSC::DFG::Epoch::operator<):
(JSC::DFG::Epoch::operator>):
(JSC::DFG::Epoch::operator<=):
(JSC::DFG::Epoch::operator>=):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::speculateForBarrier):
(JSC::DFG::FixupPhase::insertStoreBarrier): Deleted.
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGStoreBarrierElisionPhase.cpp: Removed.
* dfg/DFGStoreBarrierElisionPhase.h: Removed.
* dfg/DFGStoreBarrierInsertionPhase.cpp: Added.
(JSC::DFG::performFastStoreBarrierInsertion):
(JSC::DFG::performGlobalStoreBarrierInsertion):
* dfg/DFGStoreBarrierInsertionPhase.h: Added.
2015-05-15 Benjamin Poulain <bpoulain@apple.com>
[ARM64] Do not fail branchConvertDoubleToInt32 when the result is zero and not negative zero
https://bugs.webkit.org/show_bug.cgi?id=144976
Reviewed by Michael Saboff.
Failing the conversion on zero is pretty dangerous as we discovered on x86.
This patch does not really impact performance significantly because
r184220 removed the zero checks from Kraken. This patch is just to be
on the safe side for cases not covered by existing benchmarks.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::branchConvertDoubleToInt32):
2015-05-15 Sungmann Cho <sungmann.cho@navercorp.com>
Remove unnecessary forward declarations in PropertyNameArray.h.
https://bugs.webkit.org/show_bug.cgi?id=145058
Reviewed by Andreas Kling.
No new tests, no behavior change.
* runtime/PropertyNameArray.h:
2015-05-15 Mark Lam <mark.lam@apple.com>
JSArray::setLength() should reallocate instead of zero-filling if the reallocation would be small enough.
https://bugs.webkit.org/show_bug.cgi?id=144622
Reviewed by Geoffrey Garen.
When setting the array to a new length that is shorter, we now check if it is worth
just making a new butterfly instead of clearing out the slots in the old butterfly
that resides beyond the new length. If so, we will make a new butterfly instead.
There is no perf differences in the benchmark results. However, this does benefit
the perf of pathological cases where we need to shorten the length of a very large
array, as is the case in tests/mozilla/js1_5/Array/regress-101964.js. With this
patch, we can expect that test to complete in a short time again.
* runtime/JSArray.cpp:
(JSC::JSArray::setLength):
* runtime/JSObject.cpp:
(JSC::JSObject::reallocateAndShrinkButterfly):
- makes a new butterfly with a new shorter length.
* runtime/JSObject.h:
* tests/mozilla/js1_5/Array/regress-101964.js:
- Undo this test change since this patch will prevent us from spending a lot of time
clearing a large butterfly.
2015-05-15 Basile Clement <basile_clement@apple.com>
DFGLICMPhase shouldn't create NodeOrigins with forExit but without semantic
https://bugs.webkit.org/show_bug.cgi?id=145062
Reviewed by Filip Pizlo.
We assert in various places (including NodeOrigin::isSet()) that a
NodeOrigin's semantic and forExit must be either both set, or both
unset. However, LICM'ing a node with unset NodeOrigin would only set
forExit, and leave semantic unset. This can for instance happen when a
Phi node is constant-folded into a JSConstant, which in turn gets
LICM'd.
This patch changes DFGLICMPhase to set the NodeOrigin's semantic in
addition to its forExit if semantic was previously unset.
It also adds two validators to DFGValidate.cpp:
- In both SSA and CPS form, a NodeOrigin semantic and forExit must be either both set or both unset
- In CPS form, all nodes must have a set NodeOrigin forExit (this is
the CPS counterpart to the SSA validator that checks that all nodes
must have a set NodeOrigin except possibly for a continuous chunk of
nodes at the top of a block)
* dfg/DFGLICMPhase.cpp:
(JSC::DFG::LICMPhase::attemptHoist):
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::validate):
(JSC::DFG::Validate::validateCPS):
2015-05-15 Filip Pizlo <fpizlo@apple.com>
Unreviewed, remove an unused declaration.
* dfg/DFGSpeculativeJIT.h:
2015-05-14 Filip Pizlo <fpizlo@apple.com>
Remove unused constant-base and constant-value store barrier code in the DFG
https://bugs.webkit.org/show_bug.cgi?id=145039
Reviewed by Andreas Kling.
Just killing dead code.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::storeToWriteBarrierBuffer): Deleted.
(JSC::DFG::SpeculativeJIT::writeBarrier): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::writeBarrier):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::writeBarrier):
2015-05-15 Alexandr Skachkov <gskachkov@gmail.com>
Fix typo in function name parseFunctionParamters -> parseFunctionParameters
https://bugs.webkit.org/show_bug.cgi?id=145040
Reviewed by Mark Lam.
* parser/Parser.h:
* parser/Parser.cpp:
2015-05-14 Filip Pizlo <fpizlo@apple.com>
Remove StoreBarrierWithNullCheck, nobody ever generates this.
Rubber stamped by Benjamin Poulain and Michael Saboff.
If we did bring something like this back in the future, we would just use UntypedUse instead
of CellUse to indicate that this is what we want.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::isStoreBarrier):
* dfg/DFGNodeType.h:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
(JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileStoreBarrier):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileStoreBarrierWithNullCheck): Deleted.
2015-05-14 Filip Pizlo <fpizlo@apple.com>
PutGlobalVar should reference the global object it's storing into
https://bugs.webkit.org/show_bug.cgi?id=145036
Reviewed by Michael Saboff.
This makes it easier to reason about store barrier insertion and elimination. This changes
the format of PutGlobalVar so that child1 is the global object and child2 is the value.
Previously it just had child1, and that was the value.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compilePutGlobalVar):
2015-05-14 Michael Catanzaro <mcatanzaro@igalia.com>
[CMake] Error out when ruby is too old
https://bugs.webkit.org/show_bug.cgi?id=145014
Reviewed by Martin Robinson.
Don't enforce the check for the Ruby executable here; it's now enforced in the top-level
CMakeLists.txt instead.
* CMakeLists.txt:
2015-05-12 Basile Clement <basile_clement@apple.com>
Enforce options coherency
https://bugs.webkit.org/show_bug.cgi?id=144921
Reviewed by Mark Lam.
JavaScriptCore should be failing early when the options are set in such
a way that we don't have a meaningful way to execute JavaScript, rather
than failing for obscure reasons at some point during execution.
This patch adds a new function that checks whether the options are set
in a coherent way, and makes JSC::Options::initialize() crash when the
environment enforces incoherent options.
Client applications able to add or change additional options are
responsible to check for coherency again before starting to actually
execute JavaScript, if any additional options have been set. This is
implemented for the jsc executable in this patch.
* jsc.cpp:
(CommandLine::parseArguments):
* runtime/Options.cpp:
(JSC::Options::initialize):
(JSC::Options::ensureOptionsAreCoherent): Added.
* runtime/Options.h:
(JSC::Options::ensureOptionsAreCoherent): Added.
2015-05-14 Yusuke Suzuki <utatane.tea@gmail.com>
REGRESSION (r184337): [EFL] unresolved reference errors in ARM builds
https://bugs.webkit.org/show_bug.cgi?id=145019
Reviewed by Ryosuke Niwa.
Attempt to fix compile errors in EFL ARM buildbots.
By executing `nm`, found JSTemplateRegistryKey.cpp.o and TemplateRegistry.cpp.o have
unresolved reference to Structure::get. That is inlined function in StructureInlines.h.
* runtime/JSTemplateRegistryKey.cpp:
* runtime/TemplateRegistry.cpp:
2015-05-14 Alexandr Skachkov <gskachkov@gmail.com>
Small refactoring before implementation of the ES6 arrow function.
https://bugs.webkit.org/show_bug.cgi?id=144954
Reviewed by Ryosuke Niwa.
* parser/Parser.h:
* parser/Parser.cpp:
2015-05-14 Yusuke Suzuki <utatane.tea@gmail.com>
REGRESSION (r184337): ASSERT failed in debug builds for tagged templates
https://bugs.webkit.org/show_bug.cgi?id=145013
Reviewed by Filip Pizlo.
Fix the regression introduced by r184337.
1. JSTemporaryRegistryKey::s_info should inherit the Base::s_info,
JSDestructibleObject::s_info.
2. The first register argument of BytecodeGenerator::emitNode
should be a referenced register if it is a temporary register.
* bytecompiler/NodesCodegen.cpp:
(JSC::TaggedTemplateNode::emitBytecode):
* runtime/JSTemplateRegistryKey.cpp:
2015-05-14 Andreas Kling <akling@apple.com>
String.prototype.split() should create efficient substrings.
<https://webkit.org/b/144985>
<rdar://problem/20949344>
Reviewed by Geoffrey Garen.
Teach split() how to make substring JSStrings instead of relying on StringImpl's
substring sharing mechanism. The optimization works by deferring the construction
of a StringImpl until the substring's value is actually needed.
This knocks ~2MB off of theverge.com by avoiding the extra StringImpl allocations.
Out of ~70000 substrings created by split(), only ~2000 of them get reified.
* runtime/StringPrototype.cpp:
(JSC::jsSubstring):
(JSC::splitStringByOneCharacterImpl):
(JSC::stringProtoFuncSplit):
2015-05-14 Yusuke Suzuki <utatane.tea@gmail.com>
Change the status of ES6 tagged templates to Done in features.json
https://bugs.webkit.org/show_bug.cgi?id=145003
Reviewed by Benjamin Poulain.
Now it's implemented in r184337.
* features.json:
2015-05-14 Yusuke Suzuki <utatane.tea@gmail.com>
Introduce SymbolType into SpeculativeTypes
https://bugs.webkit.org/show_bug.cgi?id=142651
Reviewed by Filip Pizlo.
Introduce SpecSymbol type into speculative types.
Previously symbol type is categorized into SpecCellOther.
But SpecCellOther is not intended to be used for such cells.
This patch just introduces SpecSymbol.
It represents the type of target value is definitely the symbol type.
It is the part of SpecCell.
In this patch, we do not introduce SymbolUse tracking.
It will be added in the separate patch.
* bytecode/SpeculatedType.cpp:
(JSC::dumpSpeculation):
(JSC::speculationFromStructure):
* bytecode/SpeculatedType.h:
(JSC::isSymbolSpeculation):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::setType):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* tests/stress/typeof-symbol.js: Added.
2015-05-14 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement tagged templates
https://bugs.webkit.org/show_bug.cgi?id=143183
Reviewed by Oliver Hunt.
This patch implements ES6 tagged templates.
In tagged templates, the function takes the template object.
The template object contains the raw and cooked template strings,
so when parsing the tagged templates, we need to tokenize the raw and cooked strings.
While tagged templates require the both strings, the template literal only requires
the cooked strings. So when tokenizing under the template literal context,
we only builds the cooked strings.
As per ES6 spec, the template objects for the same raw strings are shared in the same realm.
The template objects is cached. And every time we evaluate the same tagged templates,
the same (cached) template objects are used.
Since the spec freezes this template objects completely,
we cannot attach some properties to it.
So we can say that it behaves as if the template objects are the primitive values (like JSString).
Since we cannot attach properties, the only way to test the identity of the template object is comparing. (===)
As the result, when there is no reference to the template object, we can garbage collect it
because the user has no way to test that the newly created template object does not equal
to the already collected template object.
So, to implement tagged templates, we implement the following components.
1. JSTemplateRegistryKey
It holds the template registry key and it does not exposed to users.
TemplateRegistryKey holds the vector of raw and cooked strings with the pre-computed hash value.
When obtaining the template object for the (statically, a.k.a. at the parsing time) given raw string vectors,
we use this JSTemplateRegistryKey as a key to the map and look up the template object from
TemplateRegistry.
JSTemplateRegistryKey is created at the bytecode compiling time and
stored in the CodeBlock as like as JSString content values.
2. TemplateRegistry
This manages the cached template objects.
It holds the weak map (JSTemplateRegistryKey -> the template object).
The template object is weakly referenced.
So if there is no reference to the template object,
the template object is automatically GC-ed.
When looking up the template object, it searches the cached template object.
If it is found, it is returned to the users.
If there is no cached template objects, it creates the new template object and
stores it with the given template registry key.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::addTemplateRegistryKeyConstant):
(JSC::BytecodeGenerator::emitGetTemplateObject):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::TaggedTemplateNode::emitBytecode):
(JSC::TemplateLiteralNode::emitBytecode): Deleted.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createTaggedTemplate):
(JSC::ASTBuilder::createTemplateLiteral): Deleted.
* parser/Lexer.cpp:
(JSC::Lexer<T>::setCode):
(JSC::Lexer<T>::parseTemplateLiteral):
(JSC::Lexer<T>::lex):
(JSC::Lexer<T>::scanTrailingTemplateString):
(JSC::Lexer<T>::clear):
* parser/Lexer.h:
(JSC::Lexer<T>::makeEmptyIdentifier):
* parser/NodeConstructors.h:
(JSC::TaggedTemplateNode::TaggedTemplateNode):
(JSC::TemplateLiteralNode::TemplateLiteralNode): Deleted.
* parser/Nodes.h:
(JSC::TemplateLiteralNode::templateStrings):
(JSC::TemplateLiteralNode::templateExpressions):
(JSC::TaggedTemplateNode::templateLiteral):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseTemplateString):
(JSC::Parser<LexerType>::parseTemplateLiteral):
(JSC::Parser<LexerType>::parsePrimaryExpression):
(JSC::Parser<LexerType>::parseMemberExpression):
* parser/Parser.h:
* parser/ParserArena.h:
(JSC::IdentifierArena::makeEmptyIdentifier):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createTaggedTemplate):
(JSC::SyntaxChecker::createTemplateLiteral): Deleted.
* runtime/CommonIdentifiers.h:
* runtime/JSGlobalObject.cpp:
(JSC::getTemplateObject):
(JSC::JSGlobalObject::JSGlobalObject):
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::templateRegistry):
* runtime/JSTemplateRegistryKey.cpp: Added.
(JSC::JSTemplateRegistryKey::JSTemplateRegistryKey):
(JSC::JSTemplateRegistryKey::create):
(JSC::JSTemplateRegistryKey::destroy):
* runtime/JSTemplateRegistryKey.h: Added.
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorFreeze):
* runtime/ObjectConstructor.h:
* runtime/TemplateRegistry.cpp: Added.
(JSC::TemplateRegistry::TemplateRegistry):
(JSC::TemplateRegistry::getTemplateObject):
* runtime/TemplateRegistry.h: Added.
* runtime/TemplateRegistryKey.h: Added.
(JSC::TemplateRegistryKey::isDeletedValue):
(JSC::TemplateRegistryKey::isEmptyValue):
(JSC::TemplateRegistryKey::hash):
(JSC::TemplateRegistryKey::rawStrings):
(JSC::TemplateRegistryKey::cookedStrings):
(JSC::TemplateRegistryKey::operator==):
(JSC::TemplateRegistryKey::operator!=):
(JSC::TemplateRegistryKey::Hasher::hash):
(JSC::TemplateRegistryKey::Hasher::equal):
(JSC::TemplateRegistryKey::TemplateRegistryKey):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
* tests/stress/tagged-templates-identity.js: Added.
(shouldBe):
* tests/stress/tagged-templates-raw-strings.js: Added.
(shouldBe):
(tag):
(testEval):
* tests/stress/tagged-templates-syntax.js: Added.
(tag):
(testSyntax):
(testSyntaxError):
* tests/stress/tagged-templates-template-object.js: Added.
(shouldBe):
(tag):
* tests/stress/tagged-templates-this.js: Added.
(shouldBe):
(tag):
* tests/stress/tagged-templates.js: Added.
(shouldBe):
(raw):
(cooked):
(Counter):
2015-05-13 Ryosuke Niwa <rniwa@webkit.org>
REGRESSION(r180595): same-callee profiling no longer works
https://bugs.webkit.org/show_bug.cgi?id=144787
Reviewed by Filip Pizlo.
This patch introduces a DFG optimization to use NewObject node when the callee of op_create_this is
always the same JSFunction. This condition doesn't hold when the byte code creates multiple
JSFunction objects at runtime as in: function y() { return function () {} }; new y(); new y();
To enable this optimization, LLint and baseline JIT now store the last callee we saw in the newly
added fourth operand of op_create_this. We use this JSFunction's structure in DFG after verifying
our speculation that the callee is the same. To avoid recompiling the same code for different callee
objects in the polymorphic case, the special value of seenMultipleCalleeObjects() is set in
LLint and baseline JIT when multiple callees are observed.
Tests: stress/create-this-with-callee-variants.js
* bytecode/BytecodeList.json: Increased the number of operands to 5.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode): Dump the newly added callee cache.
(JSC::CodeBlock::finalizeUnconditionally): Clear the callee cache if the callee is no longer alive.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitCreateThis): Add the instruction to propertyAccessInstructions so that
we can clear the callee cache in CodeBlock::finalizeUnconditionally. Also initialize the newly added
operand.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock): Implement the optimization. Speculate the actual callee to
match the cache. Use the cached callee's structure if the speculation succeeds. Otherwise, OSR exit.
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_create_this): Go to the slow path to update the cache unless it's already marked
as seenMultipleCalleeObjects() to indicate the polymorphic behavior and/or we've OSR exited here.
(JSC::JIT::emitSlow_op_create_this):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_create_this): Ditto.
(JSC::JIT::emitSlow_op_create_this):
* llint/LowLevelInterpreter32_64.asm:
(_llint_op_create_this): Ditto.
* llint/LowLevelInterpreter64.asm:
(_llint_op_create_this): Ditto.
* runtime/CommonSlowPaths.cpp:
(slow_path_create_this): Set the callee cache to the actual callee if it's not set. If the cache has
been set to a JSFunction* different from the actual callee, set it to seenMultipleCalleeObjects().
* runtime/JSCell.h:
(JSC::JSCell::seenMultipleCalleeObjects): Added.
* runtime/WriteBarrier.h:
(JSC::WriteBarrierBase::unvalidatedGet): Removed the compile guard around it.
* tests/stress/create-this-with-callee-variants.js: Added.
2015-05-13 Joseph Pecoraro <pecoraro@apple.com>
Clean up some possible RefPtr to PassRefPtr churn
https://bugs.webkit.org/show_bug.cgi?id=144779
Reviewed by Darin Adler.
* runtime/GenericTypedArrayViewInlines.h:
(JSC::GenericTypedArrayView<Adaptor>::create):
(JSC::GenericTypedArrayView<Adaptor>::createUninitialized):
* runtime/JSArrayBufferConstructor.cpp:
(JSC::constructArrayBuffer):
* runtime/Structure.cpp:
(JSC::Structure::toStructureShape):
* runtime/TypedArrayBase.h:
(JSC::TypedArrayBase::create):
(JSC::TypedArrayBase::createUninitialized):
* tools/FunctionOverrides.cpp:
(JSC::initializeOverrideInfo):
Release the last use of a RefPtr as it is passed on.
2015-05-13 Joseph Pecoraro <pecoraro@apple.com>
ES6: Allow duplicate property names
https://bugs.webkit.org/show_bug.cgi?id=142895
Reviewed by Geoffrey Garen.
Introduce new `op_put_getter_by_id` and `op_put_setter_by_id` opcodes
that will define a single getter or setter property on an object.
The existing `op_put_getter_setter` opcode is still preferred for
putting both a getter and setter at the same time but cannot be used
for putting an individual getter or setter which is needed in
some cases.
Add a new slow path when generating bytecodes for a property list
with computed properties, as computed properties are the only time
the list of properties cannot be determined statically.
* bytecompiler/NodesCodegen.cpp:
(JSC::PropertyListNode::emitBytecode):
- fast path for all constant properties
- slow but paired getter/setter path if there are no computed properties
- slow path, individual put operation for every property, if there are computed properties
* parser/Nodes.h:
Distinguish a Computed property from a Constant property.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseProperty):
(JSC::Parser<LexerType>::parsePropertyMethod):
Distingish Computed and Constant properties.
(JSC::Parser<LexerType>::parseObjectLiteral):
When we drop into strict mode it is because we saw a getter
or setter, so be more explicit.
(JSC::Parser<LexerType>::parseStrictObjectLiteral):
Eliminate duplicate property syntax error exception.
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::getName):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::getName): Deleted.
No longer used.
* runtime/JSObject.h:
(JSC::JSObject::putDirectInternal):
When updating a property. If the Accessor attribute changed
update the Structure.
* runtime/JSObject.cpp:
(JSC::JSObject::putGetter):
(JSC::JSObject::putSetter):
Called by the opcodes, just perform the same operation that
__defineGetter__ or __defineSetter__ would do.
(JSC::JSObject::putDirectNonIndexAccessor):
This transition is now handled in putDirectInternal.
* runtime/Structure.h:
Add needed export.
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitPutGetterById):
(JSC::BytecodeGenerator::emitPutSetterById):
* bytecompiler/BytecodeGenerator.h:
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_put_getter_by_id):
(JSC::JIT::emit_op_put_setter_by_id):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_put_getter_by_id):
(JSC::JIT::emit_op_put_setter_by_id):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
New bytecodes. Modelled after existing op_put_getter_setter.
2015-05-13 Filip Pizlo <fpizlo@apple.com>
Creating a new blank document in icloud pages causes an AI error: Abstract value (CellBytecodedoubleBoolOther, TOP, TOP) for double node has type outside SpecFullDouble.
https://bugs.webkit.org/show_bug.cgi?id=144856
Reviewed by Benjamin Poulain.
First I made fixTypeForRepresentation() print out better diagnostics when it dies.
Then I fixed the bug: Node::convertToIdentityOn(Node*) needs to make sure that when it
converts to a representation-changing node, it needs to use one of the UseKinds that such
a node expects. For example, DoubleRep(UntypedUse:) doesn't make sense; it needs to be
something like DoubleRep(NumberUse:) since it will speculate that the input is a number.
* dfg/DFGAbstractInterpreter.h:
(JSC::DFG::AbstractInterpreter::setBuiltInConstant):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::fixTypeForRepresentation):
* dfg/DFGAbstractValue.h:
* dfg/DFGInPlaceAbstractState.cpp:
(JSC::DFG::InPlaceAbstractState::initialize):
* dfg/DFGNode.cpp:
(JSC::DFG::Node::convertToIdentityOn):
* tests/stress/cloned-arguments-get-by-val-double-array.js: Added.
(foo):
2015-05-13 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r184313.
https://bugs.webkit.org/show_bug.cgi?id=144974
Introduced an assertion failure in class-syntax-
declaration.js, class-syntax-expression.js, and object-
literal-syntax.js (Requested by rniwa on #webkit).
Reverted changeset:
"Small refactoring before ES6 Arrow function implementation."
https://bugs.webkit.org/show_bug.cgi?id=144954
http://trac.webkit.org/changeset/184313
2015-05-13 Oliver Hunt <oliver@apple.com>
Ensure that all the smart pointer types in WTF clear their pointer before deref
https://bugs.webkit.org/show_bug.cgi?id=143789
Reviewed by Ryosuke Niwa.
One of the simpler cases of this in JavaScriptCore. There
are other cases where we need to guard the derefs but they
are more complex cases.
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::releaseImpl):
* inspector/JSJavaScriptCallFrame.cpp:
(Inspector::JSJavaScriptCallFrame::releaseImpl):
2015-05-13 Alexandr Skachkov <gskachkov@gmail.com>
Small refactoring before ES6 Arrow function implementation.
https://bugs.webkit.org/show_bug.cgi?id=144954
Reviewed by Filip Pizlo.
* parser/Parser.h:
* parser/Parser.cpp:
2015-05-13 Filip Pizlo <fpizlo@apple.com>
The liveness pruning done by ObjectAllocationSinkingPhase ignores the possibility of an object's bytecode liveness being longer than its DFG liveness
https://bugs.webkit.org/show_bug.cgi?id=144945
Reviewed by Michael Saboff.
We were making the mistake of using DFG liveness for object allocation sinking decisions.
This is wrong. In fact we almost never want to use DFG liveness directly. The only place
where that makes sense is pruning in DFG AI.
So, I created a CombinedLiveness class that combines the DFG liveness with bytecode
liveness.
In the process of doing this, I realized that the DFGForAllKills definition of combined
liveness at block tail was not strictly right; it was using the bytecode liveness at the
block terminal instead of the union of the bytecode live-at-heads of successor blocks. So,
I changed DFGForAllKills to work in terms of CombinedLiveness.
This allows me to unskip the test I added in r184260. I also added a new test that tries to
trigger this bug more directly.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGCombinedLiveness.cpp: Added.
(JSC::DFG::liveNodesAtHead):
(JSC::DFG::CombinedLiveness::CombinedLiveness):
* dfg/DFGCombinedLiveness.h: Added.
(JSC::DFG::CombinedLiveness::CombinedLiveness):
* dfg/DFGForAllKills.h:
(JSC::DFG::forAllKillsInBlock):
(JSC::DFG::forAllLiveNodesAtTail): Deleted.
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::ObjectAllocationSinkingPhase::performSinking):
(JSC::DFG::ObjectAllocationSinkingPhase::determineMaterializationPoints):
(JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
(JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
* tests/stress/escape-object-in-diamond-then-exit.js: Added.
* tests/stress/sink-object-past-invalid-check-sneaky.js:
2015-05-13 Ryosuke Niwa <rniwa@webkit.org>
I skipped a wrong test in r184270. Fix that.
The failure is tracked by webkit.org/b/144947.
* tests/stress/arith-modulo-node-behaviors.js:
* tests/stress/arith-mul-with-constants.js:
2015-05-13 Joseph Pecoraro <pecoraro@apple.com>
Avoid always running some debug code in type profiling
https://bugs.webkit.org/show_bug.cgi?id=144775
Reviewed by Daniel Bates.
* runtime/TypeProfilerLog.cpp:
(JSC::TypeProfilerLog::processLogEntries):
2015-05-13 Joseph Pecoraro <pecoraro@apple.com>
Pass String as reference in more places
https://bugs.webkit.org/show_bug.cgi?id=144769
Reviewed by Daniel Bates.
* debugger/Breakpoint.h:
(JSC::Breakpoint::Breakpoint):
* parser/Parser.h:
(JSC::Parser::setErrorMessage):
(JSC::Parser::updateErrorWithNameAndMessage):
* parser/ParserError.h:
(JSC::ParserError::ParserError):
* runtime/RegExp.cpp:
(JSC::RegExpFunctionalTestCollector::outputOneTest):
* runtime/RegExpObject.cpp:
(JSC::regExpObjectSourceInternal):
* runtime/TypeProfiler.cpp:
(JSC::TypeProfiler::typeInformationForExpressionAtOffset):
* runtime/TypeProfilerLog.cpp:
(JSC::TypeProfilerLog::processLogEntries):
* runtime/TypeProfilerLog.h:
* tools/FunctionOverrides.cpp:
(JSC::initializeOverrideInfo):
* inspector/scripts/codegen/generate_objc_conversion_helpers.py:
(ObjCConversionHelpersGenerator._generate_enum_from_protocol_string):
* inspector/scripts/codegen/objc_generator_templates.py:
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
Rebaseline tests after updating the generator.
2015-05-13 Michael Saboff <msaboff@apple.com>
com.apple.WebKit.WebContent crashed at JavaScriptCore: JSC::CodeBlock::finalizeUnconditionally
https://bugs.webkit.org/show_bug.cgi?id=144933
Changed the RELEASE_ASSERT_NOT_REACHED into an ASSERT. Added some diagnostic messages to
help determine the cause for any crash.
Reviewed by Geoffrey Garen.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finalizeUnconditionally):
2015-05-13 Filip Pizlo <fpizlo@apple.com>
REGRESSION(r184260): arguments elimination has stopped working because of Check(UntypedUse:) from SSAConversionPhase
https://bugs.webkit.org/show_bug.cgi?id=144951
Reviewed by Michael Saboff.
There were two issues here:
- In r184260 we expected a small number of possible use kinds in Check nodes, and
UntypedUse was not one of them. That seemed like a sensible assumption because we don't
create Check nodes unless it's to have a check. But, SSAConversionPhase was creating a
Check that could have UntypedUse. I fixed this. It's cleaner for SSAConversionPhase to
follow the same idiom as everyone else and not create tautological checks.
- It's clearly not very robust to assume that Checks will not be used tautologically. So,
this changes how we validate Checks in the escape analyses. We now use willHaveCheck,
which catches cases that AI would have already marked as unnecessary. It then also uses
a new helper called alreadyChecked(), which allows us to just ask if the check is
unnecessary for objects. That's a good fall-back in case AI hadn't run yet.
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGMayExit.cpp:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
* dfg/DFGSSAConversionPhase.cpp:
(JSC::DFG::SSAConversionPhase::run):
* dfg/DFGUseKind.h:
(JSC::DFG::alreadyChecked):
* dfg/DFGVarargsForwardingPhase.cpp:
k
2015-05-13 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement String.raw
https://bugs.webkit.org/show_bug.cgi?id=144330
Reviewed by Filip Pizlo.
Implement String.raw. It is intended to be used with tagged-templates syntax.
To implement ToString abstract operation efficiently,
we introduce @toString bytecode intrinsic. It emits op_to_string directly.
* CMakeLists.txt:
* builtins/StringConstructor.js: Added.
(raw):
* bytecompiler/NodesCodegen.cpp:
(JSC::BytecodeIntrinsicNode::emit_intrinsic_toString):
* runtime/CommonIdentifiers.h:
* runtime/StringConstructor.cpp:
* tests/stress/string-raw.js: Added.
(shouldBe):
(.get shouldBe):
(Counter):
2015-05-12 Ryosuke Niwa <rniwa@webkit.org>
Temporarily disable the test on Windows. The failure is tracked in webkit.org/b/144897.
* tests/stress/arith-mul-with-constants.js:
2015-05-12 Filip Pizlo <fpizlo@apple.com>
js/dom/stack-trace.html fails with eager compilation
https://bugs.webkit.org/show_bug.cgi?id=144853
Reviewed by Benjamin Poulain.
All of our escape analyses were mishandling Check(). They were assuming that this is a
non-escaping operation. But, if we do for example a Check(Int32:@x) and @x is an escape
candidate, then we need to do something: if we eliminate or sink @x, then the check no
longer makes any sense since a phantom allocation has no type. This will make us forget
that this operation would have exited. This was causing us to not call a valueOf method in
js/dom/stack-trace.html with eager compilation enabled, because it was doing something like
+o where o had a valueOf method, and o was otherwise sinkable.
This changes our escape analyses to basically pretend that any Check() that isn't obviously
unnecessary is an escape. We don't have to be super careful here. Most checks will be
completely eliminated by constant-folding. If that doesn't run in time, then the most
common check we will see is CellUse. So, we just recognize some very obvious check kinds
that we know would have passed, and for all of the rest we just assume that it's an escape.
This was super tricky to test. The obvious way to test it is to use +o like
stack-trace.html, except that doing so relies on the fact that we still haven't implemented
the optimal behavior for op_to_number. So, I take four approaches in testing this patch:
1) Use +o. These will test what we want it to test for now, but at some point in the future
these tests will just be a good sanity-check that our op_to_number implementation is
right.
2) Do fancy control flow tricks to fool the profiling into thinking that some arithmetic
operation always sees integers even though we eventually feed it an object and that
object is a sink candidate.
3) Introduce a new jsc.cpp intrinsic called isInt32() which returns true if the incoming
value is an int32. This intrinsic is required to be implemented by DFG by
unconditionally speculating that the input is int32. This allows us to write much more
targetted tests of the underlying issue.
4) I made a version of stack-trace.html that runs in run-jsc-stress-tests, so that we can
get regression test coverage of this test in eager mode.
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsic):
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
* dfg/DFGVarargsForwardingPhase.cpp:
* ftl/FTLExitValue.cpp:
(JSC::FTL::ExitValue::dumpInContext):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::buildExitArguments):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileFTLOSRExit):
* jsc.cpp:
(GlobalObject::finishCreation):
(functionIsInt32):
* runtime/Intrinsic.h:
* tests/stress/sink-arguments-past-invalid-check-dfg.js: Added.
* tests/stress/sink-arguments-past-invalid-check-int32-dfg.js: Added.
* tests/stress/sink-arguments-past-invalid-check-int32.js: Added.
* tests/stress/sink-arguments-past-invalid-check-sneakier.js: Added.
* tests/stress/sink-arguments-past-invalid-check.js: Added.
* tests/stress/sink-function-past-invalid-check-sneakier.js: Added.
* tests/stress/sink-function-past-invalid-check-sneaky.js: Added.
* tests/stress/sink-object-past-invalid-check-int32.js: Added.
* tests/stress/sink-object-past-invalid-check-sneakier.js: Added.
* tests/stress/sink-object-past-invalid-check-sneaky.js: Added.
* tests/stress/sink-object-past-invalid-check.js: Added.
2015-05-12 Benjamin Poulain <benjamin@webkit.org>
Fix the iteration count of arith-modulo-node-behaviors.js
* tests/stress/arith-modulo-node-behaviors.js:
No need for big numbers for the real testing.
2015-05-12 Mark Lam <mark.lam@apple.com>
Windows: Cannot use HANDLE from GetCurrentThread() to get the CONTEXT of another thread.
https://bugs.webkit.org/show_bug.cgi?id=144924
Reviewed by Alex Christensen.
The present stack scanning code in the Windows port is expecting that the
GetCurrentThread() API will provide a unique HANDLE for each thread. The code
then saves and later uses that HANDLE with GetThreadContext() to get the
runtime state of the target thread from the GC thread. According to
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683182(v=vs.85).aspx,
GetCurrentThread() does not provide this unique HANDLE that we expect:
"The function cannot be used by one thread to create a handle that can
be used by other threads to refer to the first thread. The handle is
always interpreted as referring to the thread that is using it. A
thread can create a "real" handle to itself that can be used by other
threads, or inherited by other processes, by specifying the pseudo
handle as the source handle in a call to the DuplicateHandle function."
As a result of this, GetCurrentThread() always returns the same HANDLE value, and
we end up never scanning the stacks of other threads because we wrongly think that
they are all equal (in identity) to the scanning thread. This, in turn, results
in crashes due to objects that are incorrectly collected.
The fix is to call DuplicateHandle() to create a HANDLE that we can use. The
MachineThreads::Thread class already accurately tracks the period of time when
we need that HANDLE for the VM. Hence, the life-cycle of the HANDLE can be tied
to the life-cycle of the MachineThreads::Thread object for the corresponding thread.
* heap/MachineStackMarker.cpp:
(JSC::getCurrentPlatformThread):
(JSC::MachineThreads::Thread::Thread):
(JSC::MachineThreads::Thread::~Thread):
(JSC::MachineThreads::Thread::suspend):
(JSC::MachineThreads::Thread::resume):
(JSC::MachineThreads::Thread::getRegisters):
2015-05-12 Benjamin Poulain <bpoulain@apple.com>
[JSC] Make the NegZero backward propagated flags of ArithMod stricter
https://bugs.webkit.org/show_bug.cgi?id=144897
Reviewed by Geoffrey Garen.
The NegZero flags of ArithMod were the same as ArithDiv: both children were
marked as needing to handle NegativeZero.
Lucky for us, ArithMod is quite a bit different than ArithDiv.
First, the sign of the result is completely independent from
the sign of the divisor. A zero on the divisor always produces a NaN.
That's great, we can remove the NodeBytecodeNeedsNegZero
from the flags propagated to child2.
Second, the sign of the result is always the same as the sign of
the dividend. A dividend of zero produces a zero of same sign
unless the divisor is zero (in which case the result is NaN).
This is great too: we can just pass the flags we got into
ArithMod.
With those two out of the way, we can make a faster version of ArithRound
for Kraken's oscillator. Since we no longer care about negative zero,
rounding becomes cast<int32>(value + 0.5). This gives ~3% faster runtime
on the benchmark.
Unfortunatelly, most of the time is spent in FTL and the same optimization
does not apply well just yet: rdar://problem/20904149.
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
Never add NodeBytecodeNeedsNegZero unless needed by the users of this node.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithRound):
Faster Math.round() when negative zero is not important.
* tests/stress/arith-modulo-node-behaviors.js: Added.
(moduloWithNegativeZeroDividend):
(moduloWithUnusedNegativeZeroDividend):
(moduloWithNegativeZeroDivisor):
2015-05-12 Mark Lam <mark.lam@apple.com>
Refactor MachineStackMarker.cpp so that it's easier to reason about MachineThreads::Thread.
https://bugs.webkit.org/show_bug.cgi?id=144925
Reviewed by Michael Saboff.
Currently, the code in MachineStackMarker.cpp is written as a bunch of functions that
operate on the platformThread value in the MachineThreads::Thread struct. Instead, we
can apply better OO encapsulation and convert all these functions into methods of the
MachineThreads::Thread struct.
This will also make it easier to reason about the fix for
https://bugs.webkit.org/show_bug.cgi?id=144924 later.
* heap/MachineStackMarker.cpp:
(JSC::getCurrentPlatformThread):
(JSC::MachineThreads::Thread::createForCurrentThread):
(JSC::MachineThreads::Thread::operator!=):
(JSC::MachineThreads::Thread::operator==):
(JSC::MachineThreads::addCurrentThread):
(JSC::MachineThreads::removeThreadIfFound):
(JSC::MachineThreads::Thread::suspend):
(JSC::MachineThreads::Thread::resume):
(JSC::MachineThreads::Thread::getRegisters):
(JSC::MachineThreads::Thread::Registers::stackPointer):
(JSC::MachineThreads::Thread::freeRegisters):
(JSC::MachineThreads::Thread::captureStack):
(JSC::MachineThreads::tryCopyOtherThreadStack):
(JSC::MachineThreads::tryCopyOtherThreadStacks):
(JSC::equalThread): Deleted.
(JSC::suspendThread): Deleted.
(JSC::resumeThread): Deleted.
(JSC::getPlatformThreadRegisters): Deleted.
(JSC::otherThreadStackPointer): Deleted.
(JSC::freePlatformThreadRegisters): Deleted.
(JSC::otherThreadStack): Deleted.
2015-05-12 Ryosuke Niwa <rniwa@webkit.org>
Array.slice should have a fast path like Array.splice
https://bugs.webkit.org/show_bug.cgi?id=144901
Reviewed by Geoffrey Garen.
Add a fast memcpy path to Array.prototype.slice as done for Array.prototype.splice.
In Kraken, this appears to be 30% win on stanford-crypto-ccm and 10% win on stanford-crypto-pbkdf2.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncSlice):
* runtime/JSArray.cpp:
(JSC::JSArray::fastSlice): Added.
* runtime/JSArray.h:
2015-05-11 Filip Pizlo <fpizlo@apple.com>
OSR availability analysis would be more scalable (and correct) if it did more liveness pruning
https://bugs.webkit.org/show_bug.cgi?id=143078
Reviewed by Andreas Kling.
In https://bugs.webkit.org/show_bug.cgi?id=144883, we found an example of where liveness
pruning is actually necessary. Well, not quite: we just need to prune out keys from the
heap availability map where the base node doesn't dominate the point where we are asking
for availability. If we don't do this, then eventually the IR gets corrupt because we'll
insert PutHints that reference the base node in places where the base node doesn't
dominate. But if we're going to do any pruning, then it makes sense to prune by bytecode
liveness. This is the strongest possible pruning we can do, and it should be sound. We
shouldn't have a node available for a virtual register if that register is live and the
node doesn't dominate.
Making this work meant reusing the prune-to-liveness algorithm from the FTL backend. So, I
abstracted this a bit better. You can now availabilityMap.pruneByLiveness(graph, origin).
* dfg/DFGAvailabilityMap.cpp:
(JSC::DFG::AvailabilityMap::pruneHeap):
(JSC::DFG::AvailabilityMap::pruneByLiveness):
(JSC::DFG::AvailabilityMap::prune): Deleted.
* dfg/DFGAvailabilityMap.h:
* dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
(JSC::DFG::OSRAvailabilityAnalysisPhase::run):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::buildExitArguments):
* tests/stress/liveness-pruning-needed-for-osr-availability.js: Added. This is a proper regression test.
* tests/stress/liveness-pruning-needed-for-osr-availability-eager.js: Added. This is the original reduced test case, requires eager-no-cjit to fail prior to this changeset.
2015-05-12 Gabor Loki <loki@webkit.org>
Workaround for Cortex-A53 erratum 843419
https://bugs.webkit.org/show_bug.cgi?id=144680
Reviewed by Michael Saboff.
This patch is about to give simple workaround for Cortex-A53 erratum 843419.
It inserts nops after ADRP instruction to avoid wrong address accesses.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::adrp):
(JSC::ARM64Assembler::nopCortexA53Fix843419):
2015-05-11 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r184009.
https://bugs.webkit.org/show_bug.cgi?id=144900
Caused crashes on inspector tests (Requested by ap on
#webkit).
Reverted changeset:
"MapDataImpl::add() shouldn't do the same hash lookup twice."
https://bugs.webkit.org/show_bug.cgi?id=144759
http://trac.webkit.org/changeset/184009
2015-05-11 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r184123.
https://bugs.webkit.org/show_bug.cgi?id=144899
Seems to have introduced flaky crashes in many JS tests
(Requested by rniwa on #webkit).
Reverted changeset:
"REGRESSION(r180595): same-callee profiling no longer works"
https://bugs.webkit.org/show_bug.cgi?id=144787
http://trac.webkit.org/changeset/184123
2015-05-11 Brent Fulgham <bfulgham@apple.com>
[Win] Move Windows build target to Windows 7 (or newer)
https://bugs.webkit.org/show_bug.cgi?id=144890
<rdar://problem/20707307>
Reviewed by Anders Carlsson.
Update linked SDK and minimal Windows level to be compatible with
Windows 7 or newer.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj:
* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj:
* JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj:
* JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj:
* JavaScriptCore.vcxproj/jsc/jsc.vcxproj:
* JavaScriptCore.vcxproj/jsc/jscLauncher.vcxproj:
* JavaScriptCore.vcxproj/libllvmForJSC/libllvmForJSC.vcxproj:
* JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj:
* JavaScriptCore.vcxproj/testRegExp/testRegExpLauncher.vcxproj:
* JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
* JavaScriptCore.vcxproj/testapi/testapiLauncher.vcxproj:
* config.h:
2015-05-08 Filip Pizlo <fpizlo@apple.com>
CPS rethreading phase's flush detector flushes way too many SetLocals
https://bugs.webkit.org/show_bug.cgi?id=144819
Reviewed by Geoffrey Garen.
After probably unrelated changes, this eventually caused some arguments elimination to stop
working because it would cause more SetLocals to turn into PutStacks. But it was a bug for
a long time. Basically, we don't want the children of a SetLocal to be flushed. Flushing is
meant to only affect the SetLocal itself.
This is a speed-up on Octane/earley.
* dfg/DFGCPSRethreadingPhase.cpp:
(JSC::DFG::CPSRethreadingPhase::computeIsFlushed):
2015-05-11 Filip Pizlo <fpizlo@apple.com>
gmail and google maps fail to load with eager compilation: Failed to insert inline cache for varargs call (specifically, CallForwardVarargs) because we thought the size would be 250 but it ended up being 262 prior to compaction.
https://bugs.webkit.org/show_bug.cgi?id=144854
Reviewed by Oliver Hunt.
This is easy: just lift the threshold. Also remove the need for some duplicate thresholds.
It used to be that Construct required less code, but that's not the case for now.
* ftl/FTLInlineCacheSize.cpp:
(JSC::FTL::sizeOfCallForwardVarargs):
(JSC::FTL::sizeOfConstructVarargs):
(JSC::FTL::sizeOfConstructForwardVarargs):
2015-05-11 Ryosuke Niwa <rniwa@webkit.org>
REGRESSION(r180595): same-callee profiling no longer works
https://bugs.webkit.org/show_bug.cgi?id=144787
Reviewed by Michael Saboff.
This patch introduces a DFG optimization to use NewObject node when the callee of op_create_this is
always the same JSFunction. This condition doesn't hold when the byte code creates multiple
JSFunction objects at runtime as in: function y() { return function () {} }; new y(); new y();
To enable this optimization, LLint and baseline JIT now store the last callee we saw in the newly
added fourth operand of op_create_this. We use this JSFunction's structure in DFG after verifying
our speculation that the callee is the same. To avoid recompiling the same code for different callee
objects in the polymorphic case, the special value of seenMultipleCalleeObjects() is set in
LLint and baseline JIT when multiple callees are observed.
Tests: stress/create-this-with-callee-variants.js
* bytecode/BytecodeList.json: Increased the number of operands to 5.
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset): op_create_this uses 2nd (constructor) and 4th (callee cache)
operands.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode): Dump the newly added callee cache.
(JSC::CodeBlock::finalizeUnconditionally): Clear the callee cache if the callee is no longer alive.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitCreateThis): Add the instruction to propertyAccessInstructions so that
we can clear the callee cache in CodeBlock::finalizeUnconditionally. Also initialize the newly added
operand.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock): Implement the optimization. Speculate the actual callee to
match the cache. Use the cached callee's structure if the speculation succeeds. Otherwise, OSR exit.
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_create_this): Go to the slow path to update the cache unless it's already marked
as seenMultipleCalleeObjects() to indicate the polymorphic behavior.
(JSC::JIT::emitSlow_op_create_this):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_create_this): Ditto.
(JSC::JIT::emitSlow_op_create_this):
* llint/LowLevelInterpreter32_64.asm:
(_llint_op_create_this): Ditto.
* llint/LowLevelInterpreter64.asm:
(_llint_op_create_this): Ditto.
* runtime/CommonSlowPaths.cpp:
(slow_path_create_this): Set the callee cache to the actual callee if it's not set. If the cache has
been set to a JSFunction* different from the actual callee, set it to seenMultipleCalleeObjects().
* runtime/JSCell.h:
(JSC::JSCell::seenMultipleCalleeObjects): Added.
* runtime/WriteBarrier.h:
(JSC::WriteBarrierBase::unvalidatedGet): Removed the compile guard around it.
* tests/stress/create-this-with-callee-variants.js: Added.
2015-05-11 Andreas Kling <akling@apple.com>
PropertyNameArray should use a Vector when there are few entries.
<https://webkit.org/b/144874>
Reviewed by Geoffrey Garen.
Bring back an optimization that was lost in the for-in refactoring.
PropertyNameArray now holds a Vector<AtomicStringImpl*> until there are
enough (20) entries to justify converting to a HashSet for contains().
Also inlined the code while we're here, since it has so few clients and
the call overhead adds up.
~5% progression on Kraken/json-stringify-tinderbox.
* runtime/PropertyNameArray.cpp: Removed.
* runtime/PropertyNameArray.h:
(JSC::PropertyNameArray::canAddKnownUniqueForStructure):
(JSC::PropertyNameArray::add):
(JSC::PropertyNameArray::addKnownUnique):
2015-05-11 Matt Baker <mattbaker@apple.com>
Web Inspector: REGRESSION (r175203): No profile information is shown in Inspector
https://bugs.webkit.org/show_bug.cgi?id=144808
Reviewed by Darin Adler.
Since a profile can be started after a timeline recording has already begun, we can't assume a zero start time.
The start time for the root node's call entry should be based on the stopwatch used by the ProfileGenerator.
* profiler/Profile.cpp:
(JSC::Profile::create):
(JSC::Profile::Profile):
* profiler/Profile.h:
* profiler/ProfileGenerator.cpp:
(JSC::ProfileGenerator::ProfileGenerator):
(JSC::AddParentForConsoleStartFunctor::operator()):
2015-05-11 Basile Clement <basile_clement@apple.com>
Unreviewed, remove unintended change.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2015-05-11 Filip Pizlo <fpizlo@apple.com>
Make it easy to enable eager/non-concurrent JIT compilation
https://bugs.webkit.org/show_bug.cgi?id=144877
Reviewed by Michael Saboff.
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/Options.h:
2015-05-10 Filip Pizlo <fpizlo@apple.com>
We shouldn't promote LoadVarargs to a sequence of GetStacks and PutStacks if doing so would exceed the LoadVarargs' limit
https://bugs.webkit.org/show_bug.cgi?id=144851
Reviewed by Michael Saboff.
LoadVarargs loads arguments from some object and puts them on the stack. The region of
stack is controlled by a bunch of meta-data, including InlineCallFrame. InlineCallFrame
shouldn't really be edited after ByteCodeParser, so we cannot convert LoadVarargs to
something that uses more stack than the LoadVarargs wanted to.
This check was missing in the ArgumentsEliminationPhase's LoadVarargs->GetStack+PutStack
promoter. This is an important promotion rule for performance, and in cases where we are
compiling truly hot code, the LoadVarargs limit will be at least as big as the length of
the phantom arguments array that this phase sees. The LoadVarargs limit is based on
profiling and the phantom arguments array is a proof; in most cases the profiling is more
conservative.
But, you could write some crazy code where the statically obvious arguments array value is
bigger than what the profiling would have told you. When this happens, this promotion
effectively removes a bounds check. This either results in us clobbering a bunch of stack,
or it means that we never initialize a region of the stack that a later operation will read
(the uninitialization happens because PutStackSinkingPhase removes PutStacks that appear
unnecessary, and a GetMyArgumentByVal will claim not to use the region of the stack outside
the original LoadVarargs limit).
* dfg/DFGArgumentsEliminationPhase.cpp:
* tests/stress/load-varargs-elimination-bounds-check-barely.js: Added.
(foo):
(bar):
(baz):
* tests/stress/load-varargs-elimination-bounds-check.js: Added.
(foo):
(bar):
(baz):
2015-05-11 Andreas Kling <akling@apple.com>
JSON.stringify shouldn't use generic get() to access Array.length
<https://webkit.org/b/144847>
Reviewed by Geoffrey Garen.
If the value being serialized is a JSArray object, we can downcast and call its
length() directly instead of doing a generic property lookup.
0.5% progression on Kraken/json-stringify-tinderbox.
* runtime/JSONObject.cpp:
(JSC::Stringifier::Holder::appendNextProperty):
2015-05-10 Andreas Kling <akling@apple.com>
Remove unnecessary AtomicStringImpl* hash specification in PropertyNameArray.
Follow up to r184050 suggested by Darin.
* runtime/PropertyNameArray.h:
2015-05-10 Andreas Kling <akling@apple.com>
Remove unused things from PropertyNameArray.
<https://webkit.org/b/144834>
Reviewed by Filip Pizlo.
PropertyNameArray had a bunch of bells and whistles added to it when for-in iteration
was refactored and optimized last year. Then more refactoring happened and this class
doesn't need to ring and toot anymore.
The RefCountedIdentifierSet class disappears since the JSPropertyNameEnumerator wasn't
actually using it for anything and we were just wasting time creating these.
Also made the member functions take AtomicStringImpl* instead of plain StringImpl*.
* runtime/JSObject.cpp:
(JSC::JSObject::getPropertyNames):
* runtime/JSPropertyNameEnumerator.cpp:
(JSC::JSPropertyNameEnumerator::create):
(JSC::JSPropertyNameEnumerator::JSPropertyNameEnumerator):
* runtime/JSPropertyNameEnumerator.h:
* runtime/PropertyNameArray.cpp:
(JSC::PropertyNameArray::add):
(JSC::PropertyNameArray::setPreviouslyEnumeratedProperties): Deleted.
* runtime/PropertyNameArray.h:
(JSC::PropertyNameArray::PropertyNameArray):
(JSC::PropertyNameArray::add):
(JSC::PropertyNameArray::addKnownUnique):
(JSC::PropertyNameArray::canAddKnownUniqueForStructure):
(JSC::RefCountedIdentifierSet::contains): Deleted.
(JSC::RefCountedIdentifierSet::size): Deleted.
(JSC::RefCountedIdentifierSet::add): Deleted.
(JSC::PropertyNameArray::identifierSet): Deleted.
(JSC::PropertyNameArray::numCacheableSlots): Deleted.
(JSC::PropertyNameArray::setNumCacheableSlotsForObject): Deleted.
(JSC::PropertyNameArray::setBaseObject): Deleted.
(JSC::PropertyNameArray::setPreviouslyEnumeratedLength): Deleted.
2015-05-09 Yoav Weiss <yoav@yoav.ws>
Remove the PICTURE_SIZES build flag
https://bugs.webkit.org/show_bug.cgi?id=144679
Reviewed by Benjamin Poulain.
Removed the PICTURE_SIZES build time flag.
* Configurations/FeatureDefines.xcconfig:
2015-05-08 Filip Pizlo <fpizlo@apple.com>
Extend the SaneChain optimization to Contiguous arrays
https://bugs.webkit.org/show_bug.cgi?id=144664
Reviewed by Mark Lam.
Previously if you loaded from a hole, you'd either have to take slow path for the array
load (which means C++ calls and prototype chain walks) or you'd exit (if you hadn't
gathered the necessary profiling yet). But that's unnecessary if we know that the
prototype chain is sane - i.e. has no indexed properties. Then we can just return
Undefined for the hole.
Making this change requires setting more watchpoints on the array prototype chain. But
that hit a horrible bug: ArrayPrototype still uses the static lookup tables and builds
itself up lazily. This means that this increased the number of recompilations we'd get
due to the array prototype chain being built up.
So, this change also removes the laziness and static tables from ArrayPrototype.
But to make that change, I also had to add a helper for eagerly building up a prototype
that has builtin functions.
* CMakeLists.txt:
* DerivedSources.make:
* dfg/DFGArrayMode.h:
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileGetByVal):
* runtime/ArrayPrototype.cpp:
(JSC::ArrayPrototype::finishCreation):
(JSC::ArrayPrototype::getOwnPropertySlot): Deleted.
* runtime/ArrayPrototype.h:
* runtime/JSObject.h:
2015-05-08 Michael Saboff <msaboff@apple.com>
Creating a large MarkedBlock sometimes results in more than one cell in the block
https://bugs.webkit.org/show_bug.cgi?id=144815
Reviewed by Mark Lam.
Large MarkedBlocks should have one and only one cell. Changed the calculation of
m_endAtom for large blocks to use the location of the first cell + 1. This
assures that large blocks only have one cell.
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::MarkedBlock):
2015-05-08 Oliver Hunt <oliver@apple.com>
MapDataImpl::add() shouldn't do the same hash lookup twice.
https://bugs.webkit.org/show_bug.cgi?id=144759
Reviewed by Gavin Barraclough.
We don't actually need to do a double lookup here, all we need to
do is update the index to point to the correct m_size.
* runtime/MapDataInlines.h:
(JSC::JSIterator>::add):
2015-05-08 Andreas Kling <akling@apple.com>
Micro-optimize JSON serialization of string primitives.
<https://webkit.org/b/144800>
Reviewed by Sam Weinig.
Don't use the out-of-line JSValue::getString() to grab at string primitives
in serialization. Just check if it's a JSString and then downcast to grab at
the WTF::String inside.
2% progression on Kraken/json-stringify-tinderbox.
* runtime/JSONObject.cpp:
(JSC::Stringifier::appendStringifiedValue):
2015-05-08 Andreas Kling <akling@apple.com>
Optimize serialization of quoted JSON strings.
<https://webkit.org/b/144754>
Reviewed by Darin Adler.
Optimized the serialization of quoted strings into JSON by moving the logic into
StringBuilder so it can make smarter decisions about buffering.
12% progression on Kraken/json-stringify-tinderbox (on my Mac Pro.)
* bytecompiler/NodesCodegen.cpp:
(JSC::ObjectPatternNode::toString): Use the new StringBuilder API.
* runtime/JSONObject.h:
* runtime/JSONObject.cpp:
(JSC::Stringifier::Holder::appendNextProperty):
(JSC::appendStringToStringBuilder): Deleted.
(JSC::appendQuotedJSONStringToBuilder): Deleted.
(JSC::Stringifier::appendQuotedString): Deleted.
(JSC::Stringifier::appendStringifiedValue): Moved the bulk of this logic
to StringBuilder and call that from here.
2015-05-07 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r183961.
https://bugs.webkit.org/show_bug.cgi?id=144784
Broke js/dom/JSON-stringify.html (Requested by kling on
#webkit).
Reverted changeset:
"Optimize serialization of quoted JSON strings."
https://bugs.webkit.org/show_bug.cgi?id=144754
http://trac.webkit.org/changeset/183961
2015-05-07 Filip Pizlo <fpizlo@apple.com>
GC has trouble with pathologically large array allocations
https://bugs.webkit.org/show_bug.cgi?id=144609
Reviewed by Geoffrey Garen.
The bug was that SlotVisitor::copyLater() would return early for oversize blocks (right
after pinning them), and would skip the accounting. The GC calculates the size of the heap
in tandem with the scan to save time, and that accounting was part of how the GC would
know how big the heap was. The GC would then think that oversize copied blocks use no
memory, and would then mess up its scheduling of the next GC.
Fixing this bug is harder than it seems. When running an eden GC, we figure out the heap
size by summing the size from the last collection and the size by walking the eden heap.
But this breaks when we eagerly delete objects that the last collection touched. We can do
that in one corner case: copied block reallocation. The old block will be deleted from old
space during the realloc and a new block will be allocated in new space. In order for the
GC to know that the size of old space actually shrank, we need a field to tell us how much
such shrinkage could occur. Since this is a very dirty corner case and it only works for
very particular reasons arising from the special properties of copied space (single owner,
and the realloc is used in places where the compiler already knows that it cannot register
allocate a pointer to the old block), I opted for an equally dirty shrinkage counter
devoted just to this case. It's called bytesRemovedFromOldSpaceDueToReallocation.
To test this, I needed to add an Option to force a particular RAM size in the GC. This
allows us to write tests that assert that the GC heap size is some value X, without
worrying about machine-to-machine variations due to GC heuristics changing based on RAM
size.
* heap/CopiedSpace.cpp:
(JSC::CopiedSpace::CopiedSpace): Initialize the dirty shrinkage counter.
(JSC::CopiedSpace::tryReallocateOversize): Bump the dirty shrinkage counter.
* heap/CopiedSpace.h:
(JSC::CopiedSpace::takeBytesRemovedFromOldSpaceDueToReallocation): Swap out the counter. Used by the GC when it does its accounting.
* heap/Heap.cpp:
(JSC::Heap::Heap): Allow the user to force the RAM size.
(JSC::Heap::updateObjectCounts): Use the dirty shrinkage counter to good effect. Also, make this code less confusing.
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::copyLater): The early return for isOversize() was the bug. We still need to report these bytes as live. Otherwise the GC doesn't know that it owns this memory.
* jsc.cpp: Add size measuring hooks to write the largeish test.
(GlobalObject::finishCreation):
(functionGCAndSweep):
(functionFullGC):
(functionEdenGC):
(functionHeapSize):
* runtime/Options.h:
* tests/stress/new-array-storage-array-with-size.js: Fix this so that it actually allocates ArrayStorage arrays and tests the thing it was supposed to test.
* tests/stress/new-largeish-contiguous-array-with-size.js: Added. This tests what the other test accidentally started testing, but does so without running your system out of memory.
(foo):
(test):
2015-05-07 Saam Barati <saambarati1@gmail.com>
Global functions should be initialized as JSFunctions in byte code
https://bugs.webkit.org/show_bug.cgi?id=144178
Reviewed by Geoffrey Garen.
This patch makes the initialization of global functions more explicit by
moving initialization into bytecode. It also prepares JSC for having ES6
style lexical scoping because initializing global functions in bytecode
easily allows global functions to be initialized with the proper scope that
will have access to global lexical variables. Global lexical variables
should be visible to global functions but don't live on the global object.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedProgramCodeBlock::visitChildren):
* bytecode/UnlinkedCodeBlock.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::BytecodeGenerator):
* bytecompiler/BytecodeGenerator.h:
* runtime/Executable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::addGlobalVar):
(JSC::JSGlobalObject::addFunction):
* runtime/JSGlobalObject.h:
2015-05-07 Benjamin Poulain <bpoulain@apple.com>
Fix the x86 32bits build
* assembler/X86Assembler.h:
2015-05-07 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add basic DFG/FTL support for Math.round
https://bugs.webkit.org/show_bug.cgi?id=144725
Reviewed by Filip Pizlo.
This patch adds two optimizations targeting Math.round():
-Add a DFGNode ArithRound corresponding to the intrinsic RoundIntrinsic.
-Change the MacroAssembler to be stricter on how we fail to convert a double
to ingeter. Previously, any number valued zero would fail, now we only
fail for -0.
Since ArithRound speculate it produces int32, the MacroAssembler assembler
part became necessary because zero is a pretty common output of Math.round()
and we would OSR exit a lot (and eventually recompile for doubles).
The implementation itself of the inline Math.round() is exactly the same
as the C function that exists for Math.round(). We can very likely do better
but it is a good start known to be valid and inlining alone alread provides
significant speedups.
* assembler/X86Assembler.h:
(JSC::X86Assembler::movmskpd_rr):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::branchConvertDoubleToInt32):
When we have a zero, get the sign bit out of the double and check if is one.
I'll look into doing the same improvement for ARM.
* bytecode/SpeculatedType.cpp:
(JSC::typeOfDoubleRounding):
(JSC::typeOfDoubleFRound): Deleted.
* bytecode/SpeculatedType.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsic):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::roundShouldSpeculateInt32):
(JSC::DFG::Graph::negateShouldSpeculateMachineInt): Deleted.
* dfg/DFGNode.h:
(JSC::DFG::Node::arithNodeFlags):
(JSC::DFG::Node::hasHeapPrediction):
(JSC::DFG::Node::hasArithMode):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithRound):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLIntrinsicRepository.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::convertDoubleToInt32):
(JSC::FTL::LowerDFGToLLVM::compileDoubleAsInt32):
(JSC::FTL::LowerDFGToLLVM::compileArithRound):
* ftl/FTLOutput.h:
(JSC::FTL::Output::ceil64):
* jit/ThunkGenerators.cpp:
* runtime/MathCommon.cpp:
* runtime/MathCommon.h:
* runtime/MathObject.cpp:
(JSC::mathProtoFuncRound):
* tests/stress/math-round-basics.js: Added.
(mathRoundOnIntegers):
(mathRoundOnDoubles):
(mathRoundOnBooleans):
(uselessMathRound):
(mathRoundWithOverflow):
(mathRoundConsumedAsDouble):
(mathRoundDoesNotCareAboutMinusZero):
(mathRoundNoArguments):
(mathRoundTooManyArguments):
(testMathRoundOnConstants):
(mathRoundStructTransition):
(Math.round):
2015-05-07 Saam Barati <saambarati1@gmail.com>
exceptionFuzz tests should explicitly initialize the exceptionFuzz boolean in JavaScript code through a function in jsc.cpp
https://bugs.webkit.org/show_bug.cgi?id=144753
Reviewed by Mark Lam.
This allows the BytecodeGenerator to freely emit startup code that "may"
throw exceptions without worrying that this startup code will trigger
the exceptionFuzz exception. The exceptionFuzz counter will only begin
ticking when the 'enableExceptionFuzz' function is explicitly called in
the exceptionFuzz tests.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionEnableExceptionFuzz):
* tests/exceptionFuzz/3d-cube.js:
* tests/exceptionFuzz/date-format-xparb.js:
* tests/exceptionFuzz/earley-boyer.js:
2015-05-07 Andreas Kling <akling@apple.com>
Optimize serialization of quoted JSON strings.
<https://webkit.org/b/144754>
Reviewed by Darin Adler.
Optimized the serialization of quoted strings into JSON by moving the logic into
StringBuilder so it can make smarter decisions about buffering.
12% progression on Kraken/json-stringify-tinderbox (on my Mac Pro.)
* bytecompiler/NodesCodegen.cpp:
(JSC::ObjectPatternNode::toString): Use the new StringBuilder API.
* runtime/JSONObject.h:
* runtime/JSONObject.cpp:
(JSC::Stringifier::Holder::appendNextProperty):
(JSC::appendStringToStringBuilder): Deleted.
(JSC::appendQuotedJSONStringToBuilder): Deleted.
(JSC::Stringifier::appendQuotedString): Deleted.
(JSC::Stringifier::appendStringifiedValue): Moved the bulk of this logic
to StringBuilder and call that from here.
2015-05-07 Yusuke Suzuki <utatane.tea@gmail.com>
FunctionCallBracketNode should store the base value to the temporary when subscript has assignment
https://bugs.webkit.org/show_bug.cgi?id=144678
Reviewed by Geoffrey Garen.
Currently, FunctionCallBracketNode directly use the RegisterID returned by emitNode.
But if the base part is the local register and the subscript part has assignment to it, the base result is accidentally rewritten.
function t() { var ok = {null: function () { } }; ok[ok = null](); }
t(); // Should not throw error.
This patch takes care about `subscriptHasAssignment`.
By using `emitNodeForLeftHandSide`, when there's assignment to local variables in RHS,
it correctly moves the LHS value to a temporary register.
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionCallBracketNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::makeFunctionCallNode):
* parser/NodeConstructors.h:
(JSC::FunctionCallBracketNode::FunctionCallBracketNode):
* parser/Nodes.h:
* tests/stress/assignment-in-function-call-bracket-node.js: Added.
(shouldBe):
(shouldBe.):
2015-05-07 Basile Clement <basile_clement@apple.com>
Unreviewed, add missing braces on a single-line if that got expanded in r183939
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::buildExitArguments):
2015-05-05 Myles C. Maxfield <mmaxfield@apple.com>
Revert "Introducing the Platform Abstraction Layer (PAL)"
https://bugs.webkit.org/show_bug.cgi?id=144751
Unreviewed.
PAL should be a new target inside WebCore, rather than a top-level folder.
* Configurations/FeatureDefines.xcconfig: Updated
2015-05-07 Basile Clement <basile_clement@apple.com>
Dumping OSR ExitValue should expand materializations only once
https://bugs.webkit.org/show_bug.cgi?id=144694
Reviewed by Filip Pizlo.
Currently, dumping OSR exit values will print the full materialization
information each time it is encountered. We change it to print only a
brief description (only the materialization's address), and print the
whole set of materializations later on.
This makes the dump less confusing (less likely to think that two
instances of the same materialization are different), and will be a
necessary change if/when we support materialization cycles.
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLExitValue.cpp:
(JSC::FTL::ExitValue::dumpInContext):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::buildExitArguments):
2015-05-07 Andreas Kling <akling@apple.com>
Worker threads leak WeakBlocks (as seen on leaks bot)
<https://webkit.org/b/144721>
<rdar://problem/20848288>
Reviewed by Darin Adler.
Nuke any remaining empty WeakBlocks when the Heap is being torn down.
Trying to peek into these blocks after the VM is dead would be a bug anyway.
This fixes a ~750 KB leak seen on the leaks bot.
* heap/Heap.cpp:
(JSC::Heap::~Heap):
2015-05-05 Geoffrey Garen <ggaren@apple.com>
Don't branch when accessing the callee
https://bugs.webkit.org/show_bug.cgi?id=144645
Reviewed by Michael Saboff.
The branch was added in <http://trac.webkit.org/changeset/81040> without
explanation.
kling found it to be a performance problem. See <https://webkit.org/b/144586>.
Our theory of access to Registers is that it's up to the client to access
them in the right way. So, let's do that.
* interpreter/CallFrame.h:
(JSC::ExecState::callee):
(JSC::ExecState::setCallee): Call the field object instead of function
because nothing guarantees that it's a function.
* interpreter/ProtoCallFrame.h:
(JSC::ProtoCallFrame::callee):
(JSC::ProtoCallFrame::setCallee):
* interpreter/Register.h:
* runtime/JSObject.h:
(JSC::Register::object): Just do a cast like our other accessors do.
(JSC::Register::operator=):
(JSC::Register::function): Deleted.
(JSC::Register::withCallee): Deleted.
2015-05-07 Dan Bernstein <mitz@apple.com>
<rdar://problem/19317140> [Xcode] Remove usage of AspenFamily.xcconfig in Source/
https://bugs.webkit.org/show_bug.cgi?id=144727
Reviewed by Darin Adler.
* Configurations/Base.xcconfig: Don’t include AspenFamily.xcconfig, and define
INSTALL_PATH_PREFIX and LD_DYLIB_INSTALL_NAME for the iOS 8.x Simulator.
2015-05-07 Andreas Kling <akling@apple.com>
Special-case Int32 values in JSON.stringify().
<https://webkit.org/b/144731>
Reviewed by Michael Saboff.
Add a fast path for serializing Int32 values to JSON. This is far faster than dragging
simple integers through the full-blown dtoa() machinery.
~50% speedup on Kraken/json-stringify-tinderbox.
* runtime/JSONObject.cpp:
(JSC::Stringifier::appendStringifiedValue):
2015-05-06 Ryosuke Niwa <rniwa@webkit.org>
ToT WebKit crashes while loading ES6 compatibility table
https://bugs.webkit.org/show_bug.cgi?id=144726
Reviewed by Filip Pizlo.
The bug was caused by parseClass superfluously avoiding to build up the string after seeing {.
Always build the identifier here as it could be a method name.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
2015-05-05 Filip Pizlo <fpizlo@apple.com>
Sane chain and string watchpoints should be set in FixupPhase or the backend rather than WatchpointCollectionPhase
https://bugs.webkit.org/show_bug.cgi?id=144665
Reviewed by Michael Saboff.
This is a step towards getting rid of WatchpointCollectionPhase. It's also a step towards
extending SaneChain to all indexing shapes.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
(JSC::DFG::FixupPhase::checkArray): Clarify the need for checking the structure. We often forget why we do this instead of always using CheckArray.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByValOnString): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
* dfg/DFGWatchpointCollectionPhase.cpp:
(JSC::DFG::WatchpointCollectionPhase::handle): Remove some code.
(JSC::DFG::WatchpointCollectionPhase::handleStringGetByVal): Deleted.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileStringCharAt): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
2015-04-02 Myles C. Maxfield <mmaxfield@apple.com>
Introducing the Platform Abstraction Layer (PAL)
https://bugs.webkit.org/show_bug.cgi?id=143358
Reviewed by Simon Fraser.
* Configurations/FeatureDefines.xcconfig: Updated
2015-05-06 Andreas Kling <akling@apple.com>
Don't allocate a StringImpl for every Number JSValue in JSON.stringify().
<https://webkit.org/b/144676>
Reviewed by Darin Adler.
We were creating a new String for every number JSValue passing through the JSON stringifier.
These StringImpl allocations were dominating one of the Kraken JSON benchmarks.
Optimize this by using StringBuilder::appendECMAScriptNumber() which uses a stack buffer
for the conversion instead.
13% progression on Kraken/json-stringify-tinderbox.
* runtime/JSONObject.cpp:
(JSC::Stringifier::appendStringifiedValue):
2015-05-06 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r183847.
https://bugs.webkit.org/show_bug.cgi?id=144691
Caused many assertion failures (Requested by ap on #webkit).
Reverted changeset:
"GC has trouble with pathologically large array allocations"
https://bugs.webkit.org/show_bug.cgi?id=144609
http://trac.webkit.org/changeset/183847
2015-05-05 Filip Pizlo <fpizlo@apple.com>
PutGlobalVar shouldn't have an unconditional store barrier
https://bugs.webkit.org/show_bug.cgi?id=133104
Reviewed by Benjamin Poulain.
We don't need a store barrier on PutGlobalVar if the value being stored can be
speculated to not be a cell.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
2015-05-05 Filip Pizlo <fpizlo@apple.com>
CopiedBlock::reportLiveBytes() should be totally cool with oversize blocks
https://bugs.webkit.org/show_bug.cgi?id=144667
Reviewed by Andreas Kling.
We are now calling this method for oversize blocks. It had an assertion that indirectly
implied that the block is not oversize, because it was claiming that the number of live
bytes should be smaller than the non-oversize-block size.
* heap/CopiedBlockInlines.h:
(JSC::CopiedBlock::reportLiveBytes):
2015-05-05 Filip Pizlo <fpizlo@apple.com>
GC has trouble with pathologically large array allocations
https://bugs.webkit.org/show_bug.cgi?id=144609
Reviewed by Mark Lam.
* heap/Heap.cpp:
(JSC::Heap::updateObjectCounts): Make this code less confusing.
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::copyLater): The early return for isOversize() was the bug. We still need to report these bytes as live. Otherwise the GC doesn't know that it owns this memory.
* jsc.cpp: Add size measuring hooks to write the largeish test.
(GlobalObject::finishCreation):
(functionGCAndSweep):
(functionFullGC):
(functionEdenGC):
(functionHeapSize):
* tests/stress/new-array-storage-array-with-size.js: Fix this so that it actually allocates ArrayStorage arrays and tests the thing it was supposed to test.
* tests/stress/new-largeish-contiguous-array-with-size.js: Added. This tests what the other test accidentally started testing, but does so without running your system out of memory.
(foo):
(test):
2015-05-05 Filip Pizlo <fpizlo@apple.com>
FTL SwitchString slow case creates duplicate switch cases
https://bugs.webkit.org/show_bug.cgi?id=144634
Reviewed by Geoffrey Garen.
The problem of duplicate switches is sufficiently annoying that I fixed the issue and also
added mostly-debug-only asserts to catch such issues earlier.
* bytecode/CallVariant.cpp:
(JSC::variantListWithVariant): Assertion to prevent similar bugs.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::switchStringRecurse): Assertion to prevent similar bugs.
(JSC::FTL::LowerDFGToLLVM::switchStringSlow): This is the bug.
* jit/BinarySwitch.cpp:
(JSC::BinarySwitch::BinarySwitch): Assertion to prevent similar bugs.
* jit/Repatch.cpp:
(JSC::linkPolymorphicCall): Assertion to prevent similar bugs.
* tests/stress/ftl-switch-string-slow-duplicate-cases.js: Added. This tests the FTL SwitchString bug. It was previously crashing every time.
(foo):
(cat):
2015-05-05 Basile Clement <basile_clement@apple.com>
Fix debug builds after r183812
https://bugs.webkit.org/show_bug.cgi?id=144300
Rubber stamped by Andreas Kling and Filip Pizlo.
hasObjectMaterializationData() didn't treat MaterializeCreateActivation
as having materialization data, which was causing an assertion failure when
sinking CreateActivations on debug builds.
* dfg/DFGNode.h:
(JSC::DFG::Node::hasObjectMaterializationData):
2015-05-04 Basile Clement <basile_clement@apple.com>
Allow CreateActivation sinking
https://bugs.webkit.org/show_bug.cgi?id=144300
Reviewed by Filip Pizlo.
This pursues the work started in
https://bugs.webkit.org/show_bug.cgi?id=144016 to expand the set of
allocations we are able to sink by allowing sinking of CreateActivation
node.
This is achieved by following closely the way NewObject is currently
sunk: we add a new PhantomCreateActivation node to record the initial
position of the CreateActivation node, new ClosureVarPLoc promoted heap
locations to keep track of the variables put in the activation, and a
new MaterializeCreateActivation node to allocate and populate the sunk
activation.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.cpp:
(JSC::DFG::Node::convertToPutClosureVarHint):
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToPhantomCreateActivation):
(JSC::DFG::Node::isActivationAllocation):
(JSC::DFG::Node::isPhantomActivationAllocation):
(JSC::DFG::Node::isPhantomAllocation):
* dfg/DFGNodeType.h:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
(JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
(JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
(JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGPromotedHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGPromotedHeapLocation.h:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::validateCPS):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileMaterializeCreateActivation):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
* tests/stress/activation-sink-osrexit.js: Added.
(bar):
(foo.set result):
* tests/stress/activation-sink.js: Added.
(bar):
2015-05-04 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix stale comment.
* tests/mozilla/js1_5/Array/regress-101964.js:
2015-05-04 Filip Pizlo <fpizlo@apple.com>
Large array shouldn't be slow
https://bugs.webkit.org/show_bug.cgi?id=144617
Rubber stamped by Mark Lam.
* tests/mozilla/js1_5/Array/regress-101964.js: 500ms isn't enough in debug mode. We don't care how long this takes so long as we run it to completion. I've raised the limit much higher.
2015-05-04 Filip Pizlo <fpizlo@apple.com>
Large array shouldn't be slow
https://bugs.webkit.org/show_bug.cgi?id=144617
Rubber stamped by Mark Lam.
* tests/mozilla/js1_5/Array/regress-101964.js: Mozilla may have cared about this being fast a decade ago (or more), but we don't care. We've consistently found that an array implementation that punishes this case to get speed on common-case array accesses is better. This should fix some test failures on the bots.
2015-05-04 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r183789.
https://bugs.webkit.org/show_bug.cgi?id=144620
Causing flakiness on exceptionFuzz tests locally on 32-bit
build (Requested by saamyjoon on #webkit).
Reverted changeset:
"Global functions should be initialized as JSFunctions in byte
code"
https://bugs.webkit.org/show_bug.cgi?id=144178
http://trac.webkit.org/changeset/183789
2015-05-04 Saam Barati <saambarati1@gmail.com>
Global functions should be initialized as JSFunctions in byte code
https://bugs.webkit.org/show_bug.cgi?id=144178
Reviewed by Geoffrey Garen.
This patch makes the initialization of global functions more explicit by
moving initialization into bytecode. It also prepares JSC for having ES6
style lexical scoping because initializing global functions in bytecode
easily allows global functions to be initialized with the proper scope that
will have access to global lexical variables. Global lexical variables
should be visible to global functions but don't live on the global object.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedProgramCodeBlock::visitChildren):
* bytecode/UnlinkedCodeBlock.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::BytecodeGenerator):
* bytecompiler/BytecodeGenerator.h:
* runtime/Executable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::addGlobalVar):
(JSC::JSGlobalObject::addFunction):
* runtime/JSGlobalObject.h:
2015-05-04 Filip Pizlo <fpizlo@apple.com>
Large array shouldn't be slow
https://bugs.webkit.org/show_bug.cgi?id=144617
Reviewed by Geoffrey Garen.
Decouple MIN_SPARSE_ARRAY_INDEX, which is the threshold for storing to the sparse map when
you're already using ArrayStorage mode, from the minimul array length required to use
ArrayStorage in a new Array(length) allocation.
Lift the array allocation length threshold to something very high. If this works, we'll
probably remove that threshold entirely.
This is a 27% speed-up on JetStream/hash-map. Because run-jsc-benchmarks still can't run
JetStream as a discrete suite, this adds hash-map to LongSpider so that we run it somewhere
for now.
* dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNewArrayWithSize):
* runtime/ArrayConventions.h:
* runtime/JSArray.h:
(JSC::JSArray::create):
* runtime/JSGlobalObject.h:
(JSC::constructEmptyArray):
* tests/stress/new-array-storage-array-with-size.js: Skip this test until we fix https://bugs.webkit.org/show_bug.cgi?id=144609.
2015-05-03 Yusuke Suzuki <utatane.tea@gmail.com>
Add backed intrinsics to private functions exposed with private symbols in global object
https://bugs.webkit.org/show_bug.cgi?id=144545
Reviewed by Darin Adler.
Math.abs and Math.floor have ASM intrinsics And it is further accelerated in DFG/FTL layers.
This patch adds intrinsic to private functions exposed with private symbols in global object,
@floor and @abs.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalPrivateFuncAbs): Deleted.
(JSC::globalPrivateFuncFloor): Deleted.
* runtime/MathObject.cpp:
* runtime/MathObject.h:
* tests/stress/array-from-abs-and-floor.js: Added.
(target1):
(target2):
(target3):
2015-05-04 Csaba Osztrogonác <ossy@webkit.org>
[cmake] ARM related build system cleanup
https://bugs.webkit.org/show_bug.cgi?id=144566
Reviewed by Darin Adler.
* CMakeLists.txt:
2015-05-04 Andreas Kling <akling@apple.com>
Optimize WeakBlock's "reap" and "visit" operations.
<https://webkit.org/b/144585>
Reviewed by Geoffrey Garen.
WeakBlock was using Heap::isLive(void*) to determine the liveness of weak pointees.
That function was really written with conservative roots marking in mind, and will do a bunch
of sanity and bounds checks.
For weaks, we know that the pointer will have been a valid cell pointer into a block
of appropriate cell size, so we can skip a lot of the checks.
We now keep a pointer to the MarkedBlock in each WeakBlock. That way we no longer have to do
MarkedBlock::blockFor() for every single cell when iterating.
Note that a WeakBlock's MarkedBlock pointer becomes null when we detach a logically empty
WeakBlock from its WeakSet and transfer ownership to Heap. At that point, the block will never
be pointing to any live cells, and the only operation that will run on the block is sweep().
Finally, MarkedBlock allows liveness queries in three states: Marked, Retired, and Allocated.
In Allocated state, all cells are reported as live. This state will reset to Marked on next GC.
This patch uses that knowledge to avoid branching on the MarkedBlock's state for every cell.
This is a ~3x speedup of visit() and a ~2x speedup of reap() on Dromaeo/dom-modify, netting
what looks like a 1% speedup locally.
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::MarkedBlock): Pass *this to the WeakSet's ctor.
* heap/MarkedBlock.h:
(JSC::MarkedBlock::isMarkedOrNewlyAllocated): Added, stripped-down version of isLive() when the
block's state is known to be either Marked or Retired.
(JSC::MarkedBlock::isAllocated): Added, tells WeakBlock it's okay to skip reap/visit since isLive()
would report that all cells are live anyway.
* heap/WeakBlock.cpp:
(JSC::WeakBlock::create):
(JSC::WeakBlock::WeakBlock): Stash a MarkedBlock* on each WeakBlock.
(JSC::WeakBlock::visit):
(JSC::WeakBlock::reap): Optimized these two to avoid a bunch of pointer arithmetic and branches.
* heap/WeakBlock.h:
(JSC::WeakBlock::disconnectMarkedBlock): Added.
* heap/WeakSet.cpp:
(JSC::WeakSet::sweep): Call the above when removing a WeakBlock from WeakSet and transferring
ownership to Heap until it can die peacefully.
(JSC::WeakSet::addAllocator):
* heap/WeakSet.h:
(JSC::WeakSet::WeakSet): Give WeakSet a MarkedBlock& for passing on to WeakBlocks.
2015-05-04 Basile Clement <basile_clement@apple.com>
Allocation sinking is prohibiting the creation of phis between a Phantom object and its materialization
https://bugs.webkit.org/show_bug.cgi?id=144587
Rubber stamped by Filip Pizlo.
When sinking object allocations, we ensure in
determineMaterializationPoints that whenever an allocation is
materialized on a path to a block, it is materialized in all such
paths. Thus when running the SSA calculator to place Phis in
placeMaterializationPoints, we can't encounter a situation where some
Upsilons are referring to a materialization while others are referring
to the phantom object.
This replaces the code that was adding a materialization late in
placeMaterializationPoints to handle that case by an assertion that it
does not happen, which will make
https://bugs.webkit.org/show_bug.cgi?id=143073 easier to implement.
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
2015-05-04 Ryosuke Niwa <rniwa@webkit.org>
Extending undefined in class syntax should throw a TypeError
https://bugs.webkit.org/show_bug.cgi?id=144284
Reviewed by Darin Adler.
The bug was caused by op_eq_null evaluating to true when compared to undefined.
Explicitly check op_eq_undefined first to detect the case where we're extending undefined.
We also had bogus test cases checked in class-syntax-extends.html. This patch also fixes them.
* bytecompiler/NodesCodegen.cpp:
(JSC::ClassExprNode::emitBytecode):
2015-05-04 Ryosuke Niwa <rniwa@webkit.org>
new super should be a syntax error
https://bugs.webkit.org/show_bug.cgi?id=144282
Reviewed by Joseph Pecoraro.
Disallow "new super" as ES6 spec doesn't allow this.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseMemberExpression):
2015-05-04 Saam Barati <saambarati1@gmail.com>
JSCallbackObject does not maintain symmetry between accesses for getOwnPropertySlot and put
https://bugs.webkit.org/show_bug.cgi?id=144265
Reviewed by Geoffrey Garen.
JSCallbackObject will defer to a parent's implementation of getOwnPropertySlot
for a static function if the parent has that property slot. JSCallbackObject::put
did not maintain this symmetry of also calling ::put on the parent if the parent
has the property. We should ensure that this symmetry exists.
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::put):
* API/tests/testapi.c:
* API/tests/testapi.js:
(globalStaticFunction2):
(this.globalStaticFunction2):
(iAmNotAStaticFunction):
(this.iAmNotAStaticFunction):
2015-05-04 Andreas Kling <akling@apple.com>
Make ExecState::vm() branchless in release builds.
<https://webkit.org/b/144586>
Reviewed by Geoffrey Garen.
Avoid null checking the ExecState's callee() before getting the
VM from it. The code was already dereferencing it anyway, since we
know it's not gonna be null.
* runtime/JSCellInlines.h:
(JSC::ExecState::vm):
2015-05-04 Basile Clement <basile_clement@apple.com>
Object allocation not sinking properly through CheckStructure
https://bugs.webkit.org/show_bug.cgi?id=144465
Reviewed by Filip Pizlo.
Currently, sinking an allocation through a CheckStructure will
completely ignore all structure checking, which is obviously wrong.
A CheckStructureImmediate node type was present for that purpose, but
the CheckStructures were not properly replaced. This ensures that
CheckStructure nodes are replaced by CheckStructureImmediate nodes when
sunk through, and that structure checking happens correctly.
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToCheckStructureImmediate): Added.
(JSC::DFG::Node::hasStructureSet):
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileCheckStructure):
(JSC::FTL::LowerDFGToLLVM::compileCheckStructureImmediate):
(JSC::FTL::LowerDFGToLLVM::checkStructure):
* tests/stress/sink_checkstructure.js: Added.
(foo):
2015-05-01 Geoffrey Garen <ggaren@apple.com>
REGRESSION(r183570): jslib-traverse-jquery is 22% slower
https://bugs.webkit.org/show_bug.cgi?id=144476
Reviewed by Sam Weinig.
jslib-traverse-jquery is now 31% faster than its unregressed baseline.
The jQuery algorithm for sorting DOM nodes is so pathologically slow that,
to my knowledge, the topic of how to optimize it is not covered in any
literature about sorting.
On the slowest jQuery sorting test -- prevAll -- our new
Array.prototype.sort, compared to its predecessor, performed 12% fewer
comparisons and requireed 10X less overhead per comparison. Yet, it was
slower.
It was slower because it inadvertantly increased the average cost of the
comparison function by 2X. jQuery uses compareDocumentPosition to compare
DOM nodes, and compareDocumentPosition(a, b) is O(N) in the distance
required to traverse backwards from b to a. In prevAll, we encounter the
worst case for merge sort of compareDocumentPosition: A long list of DOM
nodes in mostly reverse order. In this case, merge sort will sequentially
compareDocumentPosition(a, b), where a is not reachable backwards from
b, and therefore compareDocumentPosition will traverse the whole sibling
list.
The solution is simple enough: Call compareDocumentPosition(b, a) instead.
This is a pretty silly thing to do, but it is harmless, and jQuery is
popular, so let's do it.
We do not risk suffering the same problem in reverse when sorting a long
list of DOM nodes in forward order. (We still have a 37% speedup on the
nextAll benchmark.) The reason is that merge sort performs 2X fewer
comparisons when the list is already sorted, so we can worry less about
the cost of each comparison.
A fully principled soultion to this problem would probably do something
like Python's timsort, which special-cases ordered ranges to perform
only O(n) comparisons. But that would contradict our original
goal of just having something simple that works.
Another option is for elements to keep a compareDocumentPosition cache,
like a node list cache, which allows you to determine the absolute
position of a node using a hash lookup. I will leave this as an exercise
for kling.
* builtins/Array.prototype.js:
(sort.merge): Compare in an order that is favorable to a comparator
that calls compareDocumentPosition.
2015-05-04 Csaba Osztrogonác <ossy@webkit.org>
[cmake] Fix generate-js-builtins related incremental build issue
https://bugs.webkit.org/show_bug.cgi?id=144094
Reviewed by Michael Saboff.
* CMakeLists.txt: Generated JSCBuiltins.<cpp|h> should depend on Source/JavaScriptCore/builtins directory.
Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
* DerivedSources.make:
Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
* generate-js-builtins: Accept input files and input directory too.
2015-05-03 Simon Fraser <simon.fraser@apple.com>
Make some static data const
https://bugs.webkit.org/show_bug.cgi?id=144552
Reviewed by Andreas Kling.
Turn characterSetInfo into const data.
* yarr/YarrCanonicalizeUCS2.cpp:
* yarr/YarrCanonicalizeUCS2.h:
2015-05-01 Filip Pizlo <fpizlo@apple.com>
TypeOf should be fast
https://bugs.webkit.org/show_bug.cgi?id=144396
Reviewed by Geoffrey Garen.
Adds comprehensive support for fast typeof to the optimizing JITs. Calls into the runtime
are only used for very exotic objects - they must have either the MasqueradesAsUndefined or
TypeOfShouldCallGetCallData type flags set. All other cases are handled inline.
This means optimizing IsObjectOrNull, IsFunction, and TypeOf - all node types that used to
rely heavily on C++ calls to fulfill their function.
Because TypeOf is now so fast, we no longer need to do any speculations on this node.
In the FTL, we take this further by querying AI for each branch in the TypeOf decision tree.
This means that if the TypeOf is dominated by any type checks, we will automatically prune
out cases that are redundant.
This patch anticipates the addition of SwitchTypeOf or something like that. So, the TypeOf
code generation is designed to be reusable.
This is a speed-up on most typeof benchmarks. But, it is a slow-down on benchmarks that take
the exotic call trap hook. That hook is now in a deeper slow path than before.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize): TypeOf was pure all along, but we failed to realize this.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGHeapLocation.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileIsObjectOrNull):
(JSC::DFG::SpeculativeJIT::compileIsFunction):
(JSC::DFG::SpeculativeJIT::compileTypeOf):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::blessedBooleanResult):
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLIntrinsicRepository.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileIsObjectOrNull):
(JSC::FTL::LowerDFGToLLVM::compileIsFunction):
(JSC::FTL::LowerDFGToLLVM::compileTypeOf):
(JSC::FTL::LowerDFGToLLVM::buildTypeOf): Reusable TypeOf building for the FTL.
(JSC::FTL::LowerDFGToLLVM::isExoticForTypeof):
* ftl/FTLSwitchCase.h:
(JSC::FTL::SwitchCase::SwitchCase):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::branchIfNotEqual):
(JSC::AssemblyHelpers::branchIfEqual):
(JSC::AssemblyHelpers::branchIfNumber):
(JSC::AssemblyHelpers::branchIfNotNumber):
(JSC::AssemblyHelpers::branchIfBoolean):
(JSC::AssemblyHelpers::branchIfNotBoolean):
(JSC::AssemblyHelpers::boxBooleanPayload):
(JSC::AssemblyHelpers::boxBoolean):
(JSC::AssemblyHelpers::emitTypeOf): Reusable TypeOf building for assembly JITs.
* jit/JITOperations.h:
* runtime/SmallStrings.h:
(JSC::SmallStrings::typeString):
* runtime/TypeofType.cpp: Added.
(WTF::printInternal):
* runtime/TypeofType.h: Added.
* tests/stress/type-of-functions-and-objects.js: Modified this test to give more comprehensive feedback.
2015-05-02 Filip Pizlo <fpizlo@apple.com>
Unreviewed, add a FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=144527.
* dfg/DFGLICMPhase.cpp:
(JSC::DFG::LICMPhase::attemptHoist):
2015-05-02 Filip Pizlo <fpizlo@apple.com>
Unreviewed, add FIXMEs referencing https://bugs.webkit.org/show_bug.cgi?id=144524 and
https://bugs.webkit.org/show_bug.cgi?id=144525.
* dfg/DFGLICMPhase.cpp:
(JSC::DFG::LICMPhase::attemptHoist):
* dfg/DFGPhantomInsertionPhase.cpp:
2015-05-02 Yusuke Suzuki <utatane.tea@gmail.com>
Static property hashtable should only lookup with non-symbol key
https://bugs.webkit.org/show_bug.cgi?id=144438
Reviewed by Darin Adler.
Static property hashtable compares the Identifier's uid
with the normal C string without interning it.
So this comparison is performed in their contents.
As the result, in this comparison, symbol-ness is not considered.
So if accidentally the hash collision occur with the symbol and the string
and they have the same contents, the hash table entry is looked up incorrectly.
* runtime/Lookup.h:
(JSC::HashTable::entry):
2015-05-01 Ryosuke Niwa <rniwa@webkit.org>
Class syntax should allow string and numeric identifiers for method names
https://bugs.webkit.org/show_bug.cgi?id=144254
Reviewed by Darin Adler.
Added the support for string and numeric identifiers in class syntax.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionInfo): Instead of using ConstructorKind to indicate whether we're
inside a class or not, use the newly added SuperBinding argument instead. ConstructorKind is now None
outside a class constructor as it should be.
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseClass): No longer expects an identifier at the beginning of every class
element to allow numeric and string method names. For both of those method names, parse it here instead
of parseFunctionInfo since it doesn't support either type. Also pass in SuperBinding::Needed.
(JSC::Parser<LexerType>::parsePropertyMethod): Call parseFunctionInfo with SuperBinding::NotNeeded since
this function is never used to parse a class method.
(JSC::Parser<LexerType>::parseGetterSetter): Pass in superBinding argument to parseFunctionInfo.
(JSC::Parser<LexerType>::parsePrimaryExpression): Call parseFunctionInfo with SuperBinding::NotNeeded.
* parser/Parser.h:
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createProperty):
2015-05-01 Filip Pizlo <fpizlo@apple.com>
FTL should use AI more
https://bugs.webkit.org/show_bug.cgi?id=144500
Reviewed by Oliver Hunt.
This makes our type check folding even more comprehensive by ensuring that even if the FTL
decides to emit some checks, it will still do another query to the abstract interpreter to
see if the check is necessary. This helps with cases where we decided early on to speculate
one way, but later proved a more specific type of the value in question, and the constant
folder didn't catch it.
This also makes it more natural to query the abstract interpreter. For example, if you just
want the proven type, you can now say provenType(node) or provenType(edge).
* dfg/DFGArrayMode.cpp:
(JSC::DFG::ArrayMode::alreadyChecked):
* dfg/DFGArrayMode.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileBooleanToNumber):
(JSC::FTL::LowerDFGToLLVM::compileToThis):
(JSC::FTL::LowerDFGToLLVM::compileValueAdd):
(JSC::FTL::LowerDFGToLLVM::compileArithAddOrSub):
(JSC::FTL::LowerDFGToLLVM::compileArithPow):
(JSC::FTL::LowerDFGToLLVM::compileArithNegate):
(JSC::FTL::LowerDFGToLLVM::compileGetById):
(JSC::FTL::LowerDFGToLLVM::compileCheckArray):
(JSC::FTL::LowerDFGToLLVM::compilePutByVal):
(JSC::FTL::LowerDFGToLLVM::compileToStringOrCallStringConstructor):
(JSC::FTL::LowerDFGToLLVM::compileToPrimitive):
(JSC::FTL::LowerDFGToLLVM::compileStringCharAt):
(JSC::FTL::LowerDFGToLLVM::compileStringCharCodeAt):
(JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
(JSC::FTL::LowerDFGToLLVM::compileSwitch):
(JSC::FTL::LowerDFGToLLVM::compileIsBoolean):
(JSC::FTL::LowerDFGToLLVM::compileIsNumber):
(JSC::FTL::LowerDFGToLLVM::compileIsString):
(JSC::FTL::LowerDFGToLLVM::compileIsObject):
(JSC::FTL::LowerDFGToLLVM::compileInstanceOf):
(JSC::FTL::LowerDFGToLLVM::numberOrNotCellToInt32):
(JSC::FTL::LowerDFGToLLVM::baseIndex):
(JSC::FTL::LowerDFGToLLVM::compareEqObjectOrOtherToObject):
(JSC::FTL::LowerDFGToLLVM::typedArrayLength):
(JSC::FTL::LowerDFGToLLVM::boolify):
(JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
(JSC::FTL::LowerDFGToLLVM::lowInt32):
(JSC::FTL::LowerDFGToLLVM::lowInt52):
(JSC::FTL::LowerDFGToLLVM::lowCell):
(JSC::FTL::LowerDFGToLLVM::lowBoolean):
(JSC::FTL::LowerDFGToLLVM::lowDouble):
(JSC::FTL::LowerDFGToLLVM::isCellOrMisc):
(JSC::FTL::LowerDFGToLLVM::isNotCellOrMisc):
(JSC::FTL::LowerDFGToLLVM::isNumber):
(JSC::FTL::LowerDFGToLLVM::isNotNumber):
(JSC::FTL::LowerDFGToLLVM::isNotCell):
(JSC::FTL::LowerDFGToLLVM::isCell):
(JSC::FTL::LowerDFGToLLVM::isNotMisc):
(JSC::FTL::LowerDFGToLLVM::isMisc):
(JSC::FTL::LowerDFGToLLVM::isNotBoolean):
(JSC::FTL::LowerDFGToLLVM::isBoolean):
(JSC::FTL::LowerDFGToLLVM::isNotOther):
(JSC::FTL::LowerDFGToLLVM::isOther):
(JSC::FTL::LowerDFGToLLVM::isProvenValue):
(JSC::FTL::LowerDFGToLLVM::isObject):
(JSC::FTL::LowerDFGToLLVM::isNotObject):
(JSC::FTL::LowerDFGToLLVM::isNotString):
(JSC::FTL::LowerDFGToLLVM::isString):
(JSC::FTL::LowerDFGToLLVM::isFunction):
(JSC::FTL::LowerDFGToLLVM::isNotFunction):
(JSC::FTL::LowerDFGToLLVM::speculateObjectOrOther):
(JSC::FTL::LowerDFGToLLVM::speculateStringObjectForStructureID):
(JSC::FTL::LowerDFGToLLVM::speculateNotStringVar):
(JSC::FTL::LowerDFGToLLVM::abstractValue):
(JSC::FTL::LowerDFGToLLVM::provenType):
(JSC::FTL::LowerDFGToLLVM::provenValue):
(JSC::FTL::LowerDFGToLLVM::abstractStructure):
2015-05-01 Martin Robinson <mrobinson@igalia.com>
USE(...) macro should expect unprefixed variables
https://bugs.webkit.org/show_bug.cgi?id=144454
Reviewed by Daniel Bates.
* CMakeLists.txt: Replace all occurrences WTF_USE with USE.
2015-05-01 Jordan Harband <ljharb@gmail.com>
String#startsWith/endsWith/includes don't handle Infinity position/endPosition args correctly
https://bugs.webkit.org/show_bug.cgi?id=144314
Reviewed by Darin Adler.
Fixing handling of Infinity position args, per
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.includes
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.startswith
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.endswith
* runtime/StringPrototype.cpp:
(JSC::clampInt32):
(JSC::stringProtoFuncStartsWith):
(JSC::stringProtoFuncEndsWith):
(JSC::stringProtoFuncIncludes):
2015-05-01 Basile Clement <basile_clement@apple.com>
Math.abs() returns negative
https://bugs.webkit.org/show_bug.cgi?id=137827
Reviewed by Michael Saboff.
Math.abs() on doubles was mistakenly assumed by the DFG AI to be the
identity function.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* tests/stress/math-abs-positive.js: Added, was previously failing.
(foo):
2015-05-01 Basile Clement <basile_clement@apple.com>
Function allocation sinking shouldn't be performed on singleton functions
https://bugs.webkit.org/show_bug.cgi?id=144166
Reviewed by Geoffrey Garen.
Function allocations usually are free of any other side effects, but
this is not the case for allocations performed while the underlying
FunctionExecutable is still a singleton (as this allogation will fire
watchpoints invalidating code that depends on it being a singleton).
As the object allocation sinking phase assumes object allocation is
free of side-effects, sinking these allocations is not correct.
This also means that when materializing a function allocation on OSR
exit, that function's executable will never be a singleton, and we don't have
to worry about its watchpoint, allowing us to use
JSFunction::createWithInvalidatedRellocationWatchpoint instead of
JSFunction::create.
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
2015-04-30 Jon Davis <jond@apple.com>
Web Inspector: console should show an icon for console.info() messages
https://bugs.webkit.org/show_bug.cgi?id=18530
Reviewed by Timothy Hatcher.
* inspector/ConsoleMessage.cpp:
(Inspector::messageLevelValue):
* inspector/protocol/Console.json:
* runtime/ConsoleClient.cpp:
(JSC::appendMessagePrefix):
* runtime/ConsolePrototype.cpp:
(JSC::ConsolePrototype::finishCreation):
(JSC::consoleProtoFuncInfo):
* runtime/ConsoleTypes.h:
2015-04-30 Filip Pizlo <fpizlo@apple.com>
Move all of the branchIs<type> helpers from SpeculativeJIT into AssemblyHelpers
https://bugs.webkit.org/show_bug.cgi?id=144462
Reviewed by Geoffrey Garen and Mark Lam.
At some point we started adding representation-agnostic helpers for doing common type tests.
We added some in SpeculativeJIT, and then some in AssemblyHelpers. Prior to this change,
they had overlapping powers, though SpeculativeJIT was a bit better.
This removes SpeculativeJIT's helpers and strengthens AssemblyHelpers' helpers. This is
better because now all of these helpers can be used in all of the assembly-based JITs, not
just the DFG. It also settles on what I find to be a slightly better naming convention.
For example where we previously would have said branchIsString, now we say
branchIfString. Similarly, branchNotString becomes branchIfNotString.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
(JSC::DFG::SpeculativeJIT::compileValueToInt32):
(JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
(JSC::DFG::SpeculativeJIT::compileInstanceOf):
(JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
(JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
(JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
(JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
(JSC::DFG::SpeculativeJIT::speculateObject):
(JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
(JSC::DFG::SpeculativeJIT::speculateString):
(JSC::DFG::SpeculativeJIT::speculateNotStringVar):
(JSC::DFG::SpeculativeJIT::speculateNotCell):
(JSC::DFG::SpeculativeJIT::speculateOther):
(JSC::DFG::SpeculativeJIT::emitSwitchChar):
(JSC::DFG::SpeculativeJIT::emitSwitchString):
(JSC::DFG::SpeculativeJIT::branchIsObject): Deleted.
(JSC::DFG::SpeculativeJIT::branchNotObject): Deleted.
(JSC::DFG::SpeculativeJIT::branchIsString): Deleted.
(JSC::DFG::SpeculativeJIT::branchNotString): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
(JSC::DFG::SpeculativeJIT::emitCall):
(JSC::DFG::SpeculativeJIT::fillSpeculateCell):
(JSC::DFG::SpeculativeJIT::compileObjectEquality):
(JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
(JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
(JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
(JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
(JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
(JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
(JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
(JSC::DFG::SpeculativeJIT::fillSpeculateCell):
(JSC::DFG::SpeculativeJIT::compileObjectEquality):
(JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
(JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
(JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
(JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::writeBarrier):
(JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
(JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
(JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
(JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::branchIfCell):
(JSC::AssemblyHelpers::branchIfOther):
(JSC::AssemblyHelpers::branchIfNotOther):
(JSC::AssemblyHelpers::branchIfObject):
(JSC::AssemblyHelpers::branchIfNotObject):
(JSC::AssemblyHelpers::branchIfType):
(JSC::AssemblyHelpers::branchIfNotType):
(JSC::AssemblyHelpers::branchIfString):
(JSC::AssemblyHelpers::branchIfNotString):
(JSC::AssemblyHelpers::branchIfSymbol):
(JSC::AssemblyHelpers::branchIfNotSymbol):
(JSC::AssemblyHelpers::branchIfFunction):
(JSC::AssemblyHelpers::branchIfNotFunction):
(JSC::AssemblyHelpers::branchIfEmpty):
(JSC::AssemblyHelpers::branchIsEmpty): Deleted.
(JSC::AssemblyHelpers::branchIfCellNotObject): Deleted.
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitScopedArgumentsGetByVal):
2015-04-30 Filip Pizlo <fpizlo@apple.com>
js/regress/is-string-fold-tricky.html and js/regress/is-string-fold.html are crashing
https://bugs.webkit.org/show_bug.cgi?id=144463
Reviewed by Benjamin Poulain.
Fixup phase was super cleverly folding an IsString(@x) when @x is predicted SpecString
into a Check(String:@x) followed by JSConstant(true). Then in these tests the
ValueAdd(IsString(@x), @stuff) would try to turn this into an integer add by cleverly
converting the boolean into an integer. But as part of doing that, it would try to
short-circuit any profiling by leveraging the fact that the IsString is now a constant,
and it would try to figure out if the addition might overflow. Part of that logic
involved checking if the immediate is either a boolean or a sufficiently small integer.
But: it would check if it's a sufficiently small integer before checking if it was a
boolean, so it would try to call asNumber() on the boolean.
All of this cleverness was very deliberate, but apparently the @stuff + booleanConstant
case was previously never hit until I wrote these tests, and so we never knew that
calling asNumber() on a boolean was wrong.
The fix is super simple: the expression should just check for boolean first.
This bug was benign in release builds. JSValue::asNumber() on a boolean would return
garbage, and that's OK, since we'd take the boolean case anyway.
* dfg/DFGGraph.h:
(JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
2015-04-30 Filip Pizlo <fpizlo@apple.com>
Unreviewed, add a FIXME comment referencing https://bugs.webkit.org/show_bug.cgi?id=144458.
* jit/JITOperations.cpp:
2015-04-30 Filip Pizlo <fpizlo@apple.com>
Add a comment clarifying the behavior and semantics of getCallData/getConstructData, in
particular that they cannot change their minds and may be called from compiler threads.
Rubber stamped by Geoffrey Garen.
* runtime/JSCell.h:
2015-04-29 Filip Pizlo <fpizlo@apple.com>
DFG Is<Blah> versions of TypeOf should fold based on proven input type
https://bugs.webkit.org/show_bug.cgi?id=144409
Reviewed by Geoffrey Garen.
We were missing some obvious folding opportunities here. I don't know how this affects real
code, but in general, we like to ensure that our constant folding is comprehensive. So this
is more about placating my static analysis OCD than anything else.
I added a bunch of speed/correctness tests for this in LayoutTests/js/regress.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2015-04-30 Yusuke Suzuki <utatane.tea@gmail.com>
Use the default hash value for Symbolized StringImpl
https://bugs.webkit.org/show_bug.cgi?id=144347
Reviewed by Darin Adler.
Before this patch, symbolized StringImpl* has a special hash value
to avoid the hash collision with the other normal StringImpl*.
I guess that it is introduced when private symbols are introduced.
However, it prevents using symbolized StringImpl* in the other place
For example, using it as WTFString cause a problem because of its special hash value.
When only using private symbols, they are not exposed to the outside of JSC,
so we can handle it carefully. But now, it's extended to symbols.
So I think storing a special hash value in StringImpl* causes an error.
To avoid this, I propose using the usual hash value in symbolized StringImpl*.
And to provide significantly different hash value when using it as symbol,
store the additional hash value in symbolized StringImpl*. It is used when
the hash value is required by IdentifierRepHash.
* runtime/Identifier.h:
(JSC::IdentifierRepHash::hash):
* runtime/Lookup.h:
(JSC::HashTable::entry):
* runtime/PropertyMapHashTable.h:
(JSC::PropertyTable::find):
(JSC::PropertyTable::get):
* runtime/Structure.cpp:
(JSC::PropertyTable::checkConsistency):
2015-04-29 Benjamin Poulain <bpoulain@apple.com>
[JSC] Remove RageConvert array conversion
https://bugs.webkit.org/show_bug.cgi?id=144433
Reviewed by Filip Pizlo.
RageConvert was causing a subtle bug that was hitting the Kraken crypto tests
pretty hard:
-The indexing types shows that the array access varies between Int32 and DoubleArray.
-ArrayMode::fromObserved() decided to use the most generic type: DoubleArray.
An Arrayify node would convert the Int32 to that type.
-Somewhere, a GetByVal or PutByVal would have the flag NodeBytecodeUsesAsInt. That
node would use RageConvert instead of Convert.
-The Arrayify for that GetByVal with RageConvert would not convert the array to
Contiguous.
-All the following array access that do not have the flag NodeBytecodeUsesAsInt would
now expect a DoubleArray and always get a Contiguous Array. The CheckStructure
fail systematically and we never get to run the later code.
Getting rid of RageConvert fixes the problem and does not seems to have any
negative side effect on other benchmarks.
The improvments on Kraken are:
-stanford-crypto-aes: definitely 1.0915x faster.
-stanford-crypto-pbkdf2: definitely 1.2446x faster.
-stanford-crypto-sha256-iterative: definitely 1.0544x faster.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGArrayMode.cpp:
(JSC::DFG::ArrayMode::refine):
(JSC::DFG::arrayConversionToString):
* dfg/DFGArrayMode.h:
* dfg/DFGArrayifySlowPathGenerator.h:
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):
* runtime/JSObject.cpp:
(JSC::JSObject::convertDoubleToContiguous):
(JSC::JSObject::ensureContiguousSlow):
(JSC::JSObject::genericConvertDoubleToContiguous): Deleted.
(JSC::JSObject::rageConvertDoubleToContiguous): Deleted.
(JSC::JSObject::rageEnsureContiguousSlow): Deleted.
* runtime/JSObject.h:
(JSC::JSObject::rageEnsureContiguous): Deleted.
2015-04-29 Joseph Pecoraro <pecoraro@apple.com>
Gracefully handle missing auto pause key on remote inspector setup
https://bugs.webkit.org/show_bug.cgi?id=144411
Reviewed by Timothy Hatcher.
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::receivedSetupMessage):
2015-04-29 Joseph Pecoraro <pecoraro@apple.com>
NodeList has issues with Symbol and empty string
https://bugs.webkit.org/show_bug.cgi?id=144310
Reviewed by Darin Adler.
* runtime/PropertyName.h:
(JSC::PropertyName::isSymbol):
Helper to check if the PropertyName is a string or symbol property.
2015-04-29 Alex Christensen <achristensen@webkit.org>
Fix non-cygwin incremental builds on Windows.
https://bugs.webkit.org/show_bug.cgi?id=143264
Reviewed by Brent Fulgham.
* generate-js-builtins:
Remove stale headers before calling os.rename to replace them.
2015-04-29 Filip Pizlo <fpizlo@apple.com>
JSTypeInfo should have an inline type flag to indicate of getCallData() has been overridden
https://bugs.webkit.org/show_bug.cgi?id=144397
Reviewed by Andreas Kling.
Add the flag to JSTypeInfo. It's an inline flag so that it's fast to query. Slap the flag on
callback objects and internal functions. Modify the TypeOf operation to use this flag to avoid
making a getCallData() call if it isn't necessary.
* API/JSCallbackObject.h:
* runtime/InternalFunction.h:
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::typeOfShouldCallGetCallData):
* runtime/Operations.cpp:
(JSC::jsTypeStringForValue):
* tests/stress/type-of-functions-and-objects.js: Added.
(foo):
(bar):
(baz):
(fuzz):
(expect):
(test):
2015-04-28 Geoffrey Garen <ggaren@apple.com>
It shouldn't take 1846 lines of code and 5 FIXMEs to sort an array.
https://bugs.webkit.org/show_bug.cgi?id=144013
Reviewed by Mark Lam.
This patch implements Array.prototype.sort in JavaScript, removing the
C++ implementations. It is simpler and less error-prone to express our
operations in JavaScript, which provides memory safety, exception safety,
and recursion safety.
The performance result is mixed, but net positive in my opinion. It's
difficult to enumerate all the results, since we used to have so many
different sorting modes, and there are lots of different data patterns
across which you might want to measure sorting. Suffice it to say:
(*) The benchmarks we track are faster or unchanged.
(*) Sorting random input using a comparator -- which we think is
common -- is 3X faster.
(*) Sorting random input in a non-array object -- which jQuery does
-- is 4X faster.
(*) Sorting random input in a compact array of integers using a
trivial pattern-matchable comparator is 2X *slower*.
* builtins/Array.prototype.js:
(sort.min):
(sort.stringComparator):
(sort.compactSparse): Special case compaction for sparse arrays because
we don't want to hang when sorting new Array(BIG).
(sort.compact):
(sort.merge):
(sort.mergeSort): Use merge sort because it's a reasonably efficient
stable sort. We have evidence that some sites depend on stable sort,
even though the ES6 spec does not mandate it. (See
<http://trac.webkit.org/changeset/33967>.)
This is a textbook implementation of merge sort with three optimizations:
(1) Use iteration instead of recursion;
(2) Use array subscripting instead of array copying in order to
create logical sub-lists without creating physical sub-lists;
(3) Swap src and dst at each iteration instead of copying src into
dst, and only copy src into the subject array at the end if src is
not the subject array.
(sort.inflate):
(sort.comparatorSort):
(sort): Sort in JavaScript for the win.
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createExecutableInternal): Allow non-private
names so we can use helper functions.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::isNumericCompareFunction): Deleted.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::setIsNumericCompareFunction): Deleted.
(JSC::UnlinkedCodeBlock::isNumericCompareFunction): Deleted.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::setIsNumericCompareFunction): Deleted.
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionNode::emitBytecode): We don't do this special casing based
on pattern matching anymore. This was mainly an optimization to avoid
the overhead of calling from C++ to JS, which we now avoid by
sorting in JS.
* heap/Heap.cpp:
(JSC::Heap::markRoots):
(JSC::Heap::pushTempSortVector): Deleted.
(JSC::Heap::popTempSortVector): Deleted.
(JSC::Heap::visitTempSortVectors): Deleted.
* heap/Heap.h: We don't have temp sort vectors anymore because we sort
in JavaScript using a normal JavaScript array for our temporary storage.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner): Allow capturing so we can use
helper functions.
* runtime/ArrayPrototype.cpp:
(JSC::isNumericCompareFunction): Deleted.
(JSC::attemptFastSort): Deleted.
(JSC::performSlowSort): Deleted.
(JSC::arrayProtoFuncSort): Deleted.
* runtime/CommonIdentifiers.h: New strings used by sort.
* runtime/JSArray.cpp:
(JSC::compareNumbersForQSortWithInt32): Deleted.
(JSC::compareNumbersForQSortWithDouble): Deleted.
(JSC::compareNumbersForQSort): Deleted.
(JSC::compareByStringPairForQSort): Deleted.
(JSC::JSArray::sortNumericVector): Deleted.
(JSC::JSArray::sortNumeric): Deleted.
(JSC::ContiguousTypeAccessor::getAsValue): Deleted.
(JSC::ContiguousTypeAccessor::setWithValue): Deleted.
(JSC::ContiguousTypeAccessor::replaceDataReference): Deleted.
(JSC::ContiguousTypeAccessor<ArrayWithDouble>::getAsValue): Deleted.
(JSC::ContiguousTypeAccessor<ArrayWithDouble>::setWithValue): Deleted.
(JSC::ContiguousTypeAccessor<ArrayWithDouble>::replaceDataReference): Deleted.
(JSC::JSArray::sortCompactedVector): Deleted.
(JSC::JSArray::sort): Deleted.
(JSC::AVLTreeAbstractorForArrayCompare::get_less): Deleted.
(JSC::AVLTreeAbstractorForArrayCompare::set_less): Deleted.
(JSC::AVLTreeAbstractorForArrayCompare::get_greater): Deleted.
(JSC::AVLTreeAbstractorForArrayCompare::set_greater): Deleted.
(JSC::AVLTreeAbstractorForArrayCompare::get_balance_factor): Deleted.
(JSC::AVLTreeAbstractorForArrayCompare::set_balance_factor): Deleted.
(JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): Deleted.
(JSC::AVLTreeAbstractorForArrayCompare::compare_key_node): Deleted.
(JSC::AVLTreeAbstractorForArrayCompare::compare_node_node): Deleted.
(JSC::AVLTreeAbstractorForArrayCompare::null): Deleted.
(JSC::JSArray::sortVector): Deleted.
(JSC::JSArray::compactForSorting): Deleted.
* runtime/JSArray.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructor::finishCreation): Provide some builtins used
by sort.
2015-04-29 Mark Lam <mark.lam@apple.com>
Safari WebKit crash when loading Google Spreadsheet.
https://bugs.webkit.org/show_bug.cgi?id=144020
Reviewed by Filip Pizlo.
The bug is that the object allocation sinking phase did not account for a case
where a property of a sunken object is only initialized on one path and not
another. As a result, on the path where the property is not initialized, we'll
encounter an Upsilon with a BottomValue (which is not allowed by definition).
The fix is to use a JSConstant(undefined) as the bottom value instead (of
BottomValue). If the property is uninitialized, it should still be accessible
and have the value undefined.
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
* tests/stress/object-allocation-sinking-with-uninitialized-property-on-one-path.js: Added.
(foo):
(foo2):
2015-04-29 Yusuke Suzuki <utatane.tea@gmail.com>
REGRESSION (r183373): ASSERT failed in wtf/SHA1.h
https://bugs.webkit.org/show_bug.cgi?id=144257
Reviewed by Darin Adler.
SHA1 is used to calculate CodeBlockHash.
To calculate hash value, we pass the source code UTF-8 CString to SHA1::addBytes.
However, the source code can contain null character.
So when performing `strlen` on the source code's CString, it returns the incorrect length.
In SHA1::addBytes, there's assertion `input.length() == strlen(string)` and it fails.
In the template-literal-syntax.js, we perform `eval` with the script contains "\0".
As the result, `strlen(string)` accidentally shortened by the contained "\0", and assertion fails.
CString will be changed not to contain a null-character[1]. However, inserting the assertion here
is not correct. Because
1. If CString should not contain a null character, this should be asserted in CString side instead of SHA1::addBytes.
2. If CString can contain a null character, this assertion becomes incorrect.
So this patch just drops the assertion.
In the current implementation, we once convert the entire source code to the newly allocated
UTF-8 string and pass it to the SHA1 processing. However, this is memory consuming.
Ideally, we should stream the decoded bytes into the SHA1 processing iteratively.
We'll implement it in the separate patch[2].
[1]: https://bugs.webkit.org/show_bug.cgi?id=144339
[2]: https://bugs.webkit.org/show_bug.cgi?id=144263
* tests/stress/eval-script-contains-null-character.js: Added.
(shouldBe):
(test):
* tests/stress/template-literal-line-terminators.js:
* tests/stress/template-literal-syntax.js:
* tests/stress/template-literal.js:
2015-04-29 Filip Pizlo <fpizlo@apple.com>
Evict IsEnvironmentRecord from inline type flags
https://bugs.webkit.org/show_bug.cgi?id=144398
Reviewed by Mark Lam and Michael Saboff.
In https://bugs.webkit.org/show_bug.cgi?id=144397, we'll need an extra bit in the inline
type flags. This change picks the least important inline type flag - IsEnvironmentRecord -
and evicts it into the out-of-line type flags. This change has no performance implications
because we never even accessed IsEnvironmentRecord via the StructureIDBlob. The only place
where we access it at all is in String.prototype.repeat, and there we already load the
structure anyway.
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::implementsHasInstance):
(JSC::TypeInfo::structureIsImmortal):
(JSC::TypeInfo::isEnvironmentRecord):
2015-04-29 Darin Adler <darin@apple.com>
[ES6] Implement Unicode code point escapes
https://bugs.webkit.org/show_bug.cgi?id=144377
Reviewed by Antti Koivisto.
* parser/Lexer.cpp: Moved the UnicodeHexValue class in here from
the header. Made it a non-member class so it doesn't need to be part
of a template. Made it use UChar32 instead of int for the value to
make it clearer what goes into this class.
(JSC::ParsedUnicodeEscapeValue::isIncomplete): Added. Replaces the
old type() function.
(JSC::Lexer<CharacterType>::parseUnicodeEscape): Renamed from
parseFourDigitUnicodeHex and added support for code point escapes.
(JSC::isLatin1): Added an overload for UChar32.
(JSC::isIdentStart): Changed this to take UChar32; no caller tries
to call it with a UChar, so no need to overload for that type for now.
(JSC::isNonLatin1IdentPart): Changed argument type to UChar32 for clarity.
Also added FIXME about a subtle ES6 change that we might want to make later.
(JSC::isIdentPart): Changed this to take UChar32; no caller tries
to call it with a UChar, so no need to overload for that type for now.
(JSC::isIdentPartIncludingEscapeTemplate): Made this a template so that we
don't need to repeat the code twice. Added code to handle code point escapes.
(JSC::isIdentPartIncludingEscape): Call the template instead of having the
code in line.
(JSC::Lexer<CharacterType>::recordUnicodeCodePoint): Added.
(JSC::Lexer<CharacterType>::parseIdentifierSlowCase): Made small tweaks and
updated to call parseUnicodeEscape instead of parseFourDigitUnicodeHex.
(JSC::Lexer<CharacterType>::parseComplexEscape): Call parseUnicodeEscape
instead of parseFourDigitUnicodeHex. Move the code to handle "\u" before
the code that handles the escapes, since the code point escape code now
consumes characters while parsing rather than peeking ahead. Test case
covers this: Symptom would be that "\u{" would evaluate to "u" instead of
giving a syntax error.
* parser/Lexer.h: Updated for above changes.
* runtime/StringConstructor.cpp:
(JSC::stringFromCodePoint): Use ICU's UCHAR_MAX_VALUE instead of writing
out 0x10FFFF; clearer this way.
2015-04-29 Martin Robinson <mrobinson@igalia.com>
[CMake] [GTK] Organize and clean up unused CMake variables
https://bugs.webkit.org/show_bug.cgi?id=144364
Reviewed by Gyuyoung Kim.
* PlatformGTK.cmake: Add variables specific to this project.
2015-04-28 Filip Pizlo <fpizlo@apple.com>
TypeOf should return SpecStringIdent and the DFG should know this
https://bugs.webkit.org/show_bug.cgi?id=144376
Reviewed by Andreas Kling.
Make TypeOf return atomic strings. That's a simple change in SmallStrings.
Make the DFG know this and use it for optimization. This makes Switch(TypeOf) a bit less
bad.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::setType):
* dfg/DFGAbstractValue.h:
(JSC::DFG::AbstractValue::setType):
* dfg/DFGInPlaceAbstractState.cpp:
(JSC::DFG::InPlaceAbstractState::initialize):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* runtime/SmallStrings.cpp:
(JSC::SmallStrings::initialize):
* tests/stress/switch-typeof-indirect.js: Added.
(bar):
(foo):
(test):
* tests/stress/switch-typeof-slightly-indirect.js: Added.
(foo):
(test):
* tests/stress/switch-typeof.js: Added.
(foo):
(test):
2015-04-29 Joseph Pecoraro <pecoraro@apple.com>
REGRESSION(181868): Windows Live SkyDrive cannot open an excel file
https://bugs.webkit.org/show_bug.cgi?id=144373
Reviewed by Darin Adler.
Revert r181868 as it caused a failure on live.com. We can try
re-enabling this exception after we make idl attributes configurable,
which may have prevented this particular failure.
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncDefineGetter):
(JSC::objectProtoFuncDefineSetter):
2015-04-28 Joseph Pecoraro <pecoraro@apple.com>
Deadlock on applications using JSContext on non-main thread
https://bugs.webkit.org/show_bug.cgi?id=144370
Reviewed by Timothy Hatcher.
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::singleton):
Prevent a possible deadlock by assuming we can synchronously
run something on the main queue at this time.
2015-04-28 Filip Pizlo <fpizlo@apple.com>
FTL should fully support Switch (it currently lacks the SwitchString variant)
https://bugs.webkit.org/show_bug.cgi?id=144348
Reviewed by Benjamin Poulain.
This adds SwitchString support to the FTL. This is already tested by switch microbenchmarks
in LayoutTests/js/regress.
* dfg/DFGCommon.cpp:
(JSC::DFG::stringLessThan):
* dfg/DFGCommon.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<): Deleted.
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLIntrinsicRepository.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileSwitch):
(JSC::FTL::LowerDFGToLLVM::switchString):
(JSC::FTL::LowerDFGToLLVM::StringSwitchCase::StringSwitchCase):
(JSC::FTL::LowerDFGToLLVM::StringSwitchCase::operator<):
(JSC::FTL::LowerDFGToLLVM::CharacterCase::CharacterCase):
(JSC::FTL::LowerDFGToLLVM::CharacterCase::operator<):
(JSC::FTL::LowerDFGToLLVM::switchStringRecurse):
(JSC::FTL::LowerDFGToLLVM::switchStringSlow):
(JSC::FTL::LowerDFGToLLVM::appendOSRExit):
* ftl/FTLOutput.cpp:
(JSC::FTL::Output::check):
* ftl/FTLOutput.h:
* ftl/FTLWeight.h:
(JSC::FTL::Weight::inverse):
* jit/JITOperations.h:
2015-04-28 Michael Catanzaro <mcatanzaro@igalia.com>
Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT
https://bugs.webkit.org/show_bug.cgi?id=144304
Reviewed by Geoffrey Garen.
* Configurations/FeatureDefines.xcconfig: Define ENABLE_JIT, enabled by default, instead of
ENABLE_LLINT_C_LOOP, disabled by default.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL): Check ENABLE_JIT instead of ENABLE_LLINT_C_LOOP.
2015-04-28 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r183514.
https://bugs.webkit.org/show_bug.cgi?id=144359
It broke cloop test bots (Requested by mcatanzaro on #webkit).
Reverted changeset:
"Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT"
https://bugs.webkit.org/show_bug.cgi?id=144304
http://trac.webkit.org/changeset/183514
2015-04-28 Michael Catanzaro <mcatanzaro@igalia.com>
Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT
https://bugs.webkit.org/show_bug.cgi?id=144304
Reviewed by Geoffrey Garen.
* Configurations/FeatureDefines.xcconfig: Define ENABLE_JIT, enabled by default, instead of
ENABLE_LLINT_C_LOOP, disabled by default.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL): Check ENABLE_JIT instead of ENABLE_LLINT_C_LOOP.
2015-04-28 Joseph Pecoraro <pecoraro@apple.com>
Fix common typo "targetting" => "targeting"
https://bugs.webkit.org/show_bug.cgi?id=144349
Reviewed by Daniel Bates.
* bytecode/ExecutionCounter.h:
2015-04-28 Yusuke Suzuki <utatane.tea@gmail.com>
Update the features.json for WeakSet, WeakMap, Template literals, Tagged templates
https://bugs.webkit.org/show_bug.cgi?id=144328
Reviewed by Andreas Kling.
Update the status of ES6 features.
* features.json:
2015-04-28 Filip Pizlo <fpizlo@apple.com>
DFG should not use or preserve Phantoms during transformations
https://bugs.webkit.org/show_bug.cgi?id=143736
Reviewed by Geoffrey Garen.
Since http://trac.webkit.org/changeset/183207 and http://trac.webkit.org/changeset/183406, it is
no longer necessary to preserve Phantoms during transformations. They are still useful just
before FixupPhase to support backwards propagation analyses. They are still inserted late in the
game in the DFG backend. But transformations don't need to worry about them. Inside a basic
block, we can be sure that so long as the IR pinpoints the place where the value becomes
available in a bytecode register (using MovHint) and so long as there is a SetLocal anytime some
other block would need the value (either for OSR or for DFG execution), then we don't need any
liveness markers.
So, this removes any places where we inserted Phantoms just for liveness during transformation
and it replaces convertToPhantom() with remove(), which just converts the node to a Check. A
Check node only keeps its children so long as those children have checks.
The fact that we no longer convertToPhantom() means that we have to be more careful when
constant-folding GetLocal. Previously we would convertToPhantom() and use the fact that
Phantom(Phi) was a valid construct. It's not valid anymore. So, when constant folding encounters
a GetLocal it needs to insert a PhantomLocal directly. This allows us to simplify
Graph::convertToConstant() a bit. Luckily, none of the other users of this method would see
GetLocals.
The only Phantom-like cruft left over after this patch is:
- Phantoms before FixupPhase. I kind of like these. It means that before FixupPhase, we can do
backwards analyses and rely on the fact that the users of a node in DFG IR are a superset of
the users of the original local's live range in bytecode. This is essential for supporting our
BackwardsPropagationPhase, which is an important optimization for things like asm.js.
- PhantomLocals and GetLocals being NodeMustGenerate. See discussion in
https://bugs.webkit.org/show_bug.cgi?id=144086. It appears that this is not as evil as the
alternatives. The best long-term plan is to simply ditch the ThreadedCPS IR entirely and have
the DFG use SSA. For now, so long as any new DFG optimizations we add are block-local and
treat GetLocal/SetLocal conservatively, this should all be sound.
This change should be perf-neutral although it does reduce the total work that the compiler
does.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAdjacencyList.h:
(JSC::DFG::AdjacencyList::justChecks):
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGBasicBlock.cpp:
(JSC::DFG::BasicBlock::replaceTerminal):
* dfg/DFGBasicBlock.h:
(JSC::DFG::BasicBlock::findTerminal):
* dfg/DFGCFGSimplificationPhase.cpp:
(JSC::DFG::CFGSimplificationPhase::keepOperandAlive):
(JSC::DFG::CFGSimplificationPhase::mergeBlocks):
* dfg/DFGCPSRethreadingPhase.cpp:
(JSC::DFG::CPSRethreadingPhase::CPSRethreadingPhase):
(JSC::DFG::CPSRethreadingPhase::clearVariables):
(JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
(JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
* dfg/DFGCSEPhase.cpp:
* dfg/DFGCleanUpPhase.cpp: Copied from Source/JavaScriptCore/dfg/DFGPhantomRemovalPhase.cpp.
(JSC::DFG::CleanUpPhase::CleanUpPhase):
(JSC::DFG::CleanUpPhase::run):
(JSC::DFG::performCleanUp):
(JSC::DFG::PhantomRemovalPhase::PhantomRemovalPhase): Deleted.
(JSC::DFG::PhantomRemovalPhase::run): Deleted.
(JSC::DFG::performPhantomRemoval): Deleted.
* dfg/DFGCleanUpPhase.h: Copied from Source/JavaScriptCore/dfg/DFGPhantomRemovalPhase.h.
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
(JSC::DFG::ConstantFoldingPhase::addBaseCheck):
(JSC::DFG::ConstantFoldingPhase::fixUpsilons):
* dfg/DFGDCEPhase.cpp:
(JSC::DFG::DCEPhase::run):
(JSC::DFG::DCEPhase::fixupBlock):
(JSC::DFG::DCEPhase::cleanVariables):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupBlock):
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::convertStringAddUse):
(JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
(JSC::DFG::FixupPhase::checkArray):
(JSC::DFG::FixupPhase::fixIntConvertingEdge):
(JSC::DFG::FixupPhase::fixIntOrBooleanEdge):
(JSC::DFG::FixupPhase::fixDoubleOrBooleanEdge):
(JSC::DFG::FixupPhase::injectTypeConversionsInBlock):
(JSC::DFG::FixupPhase::tryToRelaxRepresentation):
(JSC::DFG::FixupPhase::injectTypeConversionsForEdge):
(JSC::DFG::FixupPhase::addRequiredPhantom): Deleted.
(JSC::DFG::FixupPhase::addPhantomsIfNecessary): Deleted.
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::convertToConstant):
(JSC::DFG::Graph::mergeRelevantToOSR): Deleted.
* dfg/DFGGraph.h:
* dfg/DFGInsertionSet.h:
(JSC::DFG::InsertionSet::insertCheck):
* dfg/DFGIntegerCheckCombiningPhase.cpp:
(JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
* dfg/DFGLICMPhase.cpp:
(JSC::DFG::LICMPhase::attemptHoist):
* dfg/DFGNode.cpp:
(JSC::DFG::Node::remove):
* dfg/DFGNode.h:
(JSC::DFG::Node::replaceWith):
(JSC::DFG::Node::convertToPhantom): Deleted.
(JSC::DFG::Node::convertToCheck): Deleted.
(JSC::DFG::Node::willHaveCodeGenOrOSR): Deleted.
* dfg/DFGNodeFlags.h:
* dfg/DFGNodeType.h:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
(JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
* dfg/DFGPhantomCanonicalizationPhase.cpp: Removed.
* dfg/DFGPhantomCanonicalizationPhase.h: Removed.
* dfg/DFGPhantomRemovalPhase.cpp: Removed.
* dfg/DFGPhantomRemovalPhase.h: Removed.
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGPutStackSinkingPhase.cpp:
* dfg/DFGResurrectionForValidationPhase.cpp: Removed.
* dfg/DFGResurrectionForValidationPhase.h: Removed.
* dfg/DFGSSAConversionPhase.cpp:
(JSC::DFG::SSAConversionPhase::run):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
* dfg/DFGStoreBarrierElisionPhase.cpp:
(JSC::DFG::StoreBarrierElisionPhase::elideBarrier):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
(JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild):
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::validate):
(JSC::DFG::Validate::validateCPS):
(JSC::DFG::Validate::validateSSA):
* dfg/DFGVarargsForwardingPhase.cpp:
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileNoOp):
(JSC::FTL::LowerDFGToLLVM::compilePhantom): Deleted.
2015-04-28 Andreas Kling <akling@apple.com>
DFG+FTL should generate efficient code for branching on a string's boolean value.
<https://webkit.org/b/144317>
Reviewed by Geoff Garen & Filip Pizlo
Teach Branch nodes about StringUse and have them generate an efficient zero-length string check
instead of dropping out to C++ whenever we branch on a string.
The FTL JIT already handled Branch nodes with StringUse through its use of boolify(), so only
the DFG JIT gets some new codegen logic in this patch.
Test: js/regress/branch-on-string-as-boolean.js (~4.5x speedup)
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitStringBranch):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::emitBranch):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitBranch):
2015-04-28 Filip Pizlo <fpizlo@apple.com>
VarargsForwardingPhase should only consider MovHints that have the candidate as a child
https://bugs.webkit.org/show_bug.cgi?id=144340
Reviewed by Michael Saboff and Mark Lam.
Since we were considering all MovHints, we'd assume that the CreateDirectArguments or
CreateClosedArguments node was live so long as any MovHinted bytecode variable was alive.
Basically, we'd keep it alive until the end of the block. This maximized the chances of
there being an interfering operation, which would prevent elimination.
The fix is to only consider MovHints that have the arguments candidate as a child. We only
care to track the liveness of those bytecode locals that would need an arguments object
recovery on OSR exit.
This is a speed-up on V8Spider/raytrace and Octane/raytrace because it undoes the regression
introduced in http://trac.webkit.org/changeset/183406.
* dfg/DFGVarargsForwardingPhase.cpp:
2015-04-28 Csaba Osztrogonác <ossy@webkit.org>
Remove WinCE cruft from cmake build system
https://bugs.webkit.org/show_bug.cgi?id=144325
Reviewed by Gyuyoung Kim.
* CMakeLists.txt:
* create_jit_stubs: Removed.
2015-04-27 Andreas Kling <akling@apple.com>
RegExp matches arrays should use contiguous indexing.
<https://webkit.org/b/144286>
Reviewed by Geoffrey Garen.
We had a custom Structure being used for RegExp matches arrays that would
put the arrays into SlowPutArrayStorageShape mode. This was just left
from when matches arrays were custom, lazily initialized objects.
This change removes that Structure and switches the matches arrays to
using the default ContiguousShape Structure. This allows the FTL JIT
to compile the inner loop of the Octane/regexp benchmark.
Also made a version of initializeIndex() [inline] that takes the indexing
type in an argument, allowing createRegExpMatchesArray() to initialize
the entire array without branching on the indexing type for each entry.
~3% progression on Octane/regexp.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::mapStructure):
(JSC::JSGlobalObject::regExpMatchesArrayStructure): Deleted.
* runtime/JSObject.h:
(JSC::JSObject::initializeIndex):
* runtime/RegExpMatchesArray.cpp:
(JSC::createRegExpMatchesArray):
2015-04-27 Filip Pizlo <fpizlo@apple.com>
FTL failed to initialize arguments.callee on the slow path as well as the fast path
https://bugs.webkit.org/show_bug.cgi?id=144293
Reviewed by Mark Lam.
The slow path doesn't fully initialize DirectArguments - it leaves callee blank. So, we need
to initialize the callee on the common path after the fast and slow path.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileCreateDirectArguments):
* tests/stress/arguments-callee-uninitialized.js: Added.
(foo):
2015-04-27 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add support for typed arrays to the Array profiling
https://bugs.webkit.org/show_bug.cgi?id=143913
Reviewed by Filip Pizlo.
This patch adds ArrayModes for every typed arrays. Having that information
let us generate better GetByVal and PutByVal when the type speculation
are not good enough.
A typical case where this is useful is any basic block for which the type
of the object is always more restrictive than the speculation (for example,
a basic block gated by a branch only taken for on type).
* bytecode/ArrayProfile.cpp:
(JSC::dumpArrayModes):
* bytecode/ArrayProfile.h:
(JSC::arrayModeFromStructure):
* dfg/DFGArrayMode.cpp:
(JSC::DFG::ArrayMode::fromObserved):
(JSC::DFG::ArrayMode::refine):
Maintain the refine() semantic. We do not support OutOfBounds access
for GetByVal on typed array.
* runtime/IndexingType.h:
* tests/stress/typed-array-get-by-val-profiling.js: Added.
(testArray.testCode):
(testArray):
* tests/stress/typed-array-put-by-val-profiling.js: Added.
(testArray.testCode):
(testArray):
2015-04-27 Filip Pizlo <fpizlo@apple.com>
Unreviewed, roll out r183438 "RegExp matches arrays should use contiguous indexing". It
causes many debug test failures.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::regExpMatchesArrayStructure):
* runtime/JSObject.h:
(JSC::JSObject::initializeIndex):
* runtime/RegExpMatchesArray.cpp:
(JSC::createRegExpMatchesArray):
2015-04-27 Andreas Kling <akling@apple.com>
RegExp matches arrays should use contiguous indexing.
<https://webkit.org/b/144286>
Reviewed by Geoffrey Garen.
We had a custom Structure being used for RegExp matches arrays that would
put the arrays into SlowPutArrayStorageShape mode. This was just left
from when matches arrays were custom, lazily initialized objects.
This change removes that Structure and switches the matches arrays to
using the default ContiguousShape Structure. This allows the FTL JIT
to compile the inner loop of the Octane/regexp benchmark.
Also made a version of initializeIndex() [inline] that takes the indexing
type in an argument, allowing createRegExpMatchesArray() to initialize
the entire array without branching on the indexing type for each entry.
~3% progression on Octane/regexp.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::mapStructure):
(JSC::JSGlobalObject::regExpMatchesArrayStructure): Deleted.
* runtime/JSObject.h:
(JSC::JSObject::initializeIndex):
* runtime/RegExpMatchesArray.cpp:
(JSC::createRegExpMatchesArray):
2015-04-27 Ryosuke Niwa <rniwa@webkit.org>
REGRESSION (r183373): ASSERT failed in wtf/SHA1.h
https://bugs.webkit.org/show_bug.cgi?id=144257
Temporarily disable skip these tests.
* tests/stress/template-literal-line-terminators.js:
* tests/stress/template-literal-syntax.js:
* tests/stress/template-literal.js:
2015-04-27 Basile Clement <basile_clement@apple.com>
Function allocations shouldn't sink through Put operations
https://bugs.webkit.org/show_bug.cgi?id=144176
Reviewed by Filip Pizlo.
By design, we don't support function allocation sinking through any
related operation ; however object allocation can sink through PutByOffset et
al.
Currently, the checks to prevent function allocation to sink through
these are misguided and do not prevent anything ; function allocation sinking
through these operations is prevented as a side effect of requiring an
AllocatePropertyStorage through which the function allocation is seen as
escaping.
This changes it so that ObjectAllocationSinkingPhase::handleNode()
checks properly that only object allocations sink through related write
operations.
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
(JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
2015-04-25 Filip Pizlo <fpizlo@apple.com>
VarargsForwardingPhase should use bytecode liveness in addition to other uses to determine the last point that a candidate is used
https://bugs.webkit.org/show_bug.cgi?id=143843
Reviewed by Geoffrey Garen.
It will soon come to pass that Phantom isn't available at the time that
VarargsForwardingPhase runs. So, it needs to use some other mechanism for discovering when
a value dies for OSR.
This is simplified by two things:
1) The bytecode kill analysis is now reusable. This patch makes it even more reusable than
before by polishing the API.
2) This phase already operates on one node at a time and allows itself to do a full search
of the enclosing basic block for that node. This is fine because CreateDirectArguments
and friends is a rarely occurring node. The fact that it operates on one node at a time
makes it even easier to reason about OSR liveness - we just track the list of locals in
which it is live.
This change has no effect right now but it is a necessary prerequisite to implementing
https://bugs.webkit.org/show_bug.cgi?id=143736.
* dfg/DFGBasicBlock.h:
(JSC::DFG::BasicBlock::tryAt):
* dfg/DFGForAllKills.h:
(JSC::DFG::forAllKilledOperands):
* dfg/DFGPhantomInsertionPhase.cpp:
* dfg/DFGVarargsForwardingPhase.cpp:
2015-04-27 Jordan Harband <ljharb@gmail.com>
Map#entries and Map#keys error for non-Maps is swapped
https://bugs.webkit.org/show_bug.cgi?id=144253
Reviewed by Simon Fraser.
Correcting error messages on Set/Map methods when called on
incompatible objects.
* runtime/MapPrototype.cpp:
(JSC::mapProtoFuncEntries):
(JSC::mapProtoFuncKeys):
* runtime/SetPrototype.cpp:
(JSC::setProtoFuncEntries):
2015-04-24 Filip Pizlo <fpizlo@apple.com>
Rationalize DFG DCE handling of nodes that perform checks that propagate through AI
https://bugs.webkit.org/show_bug.cgi?id=144186
Reviewed by Geoffrey Garen.
If I do ArithAdd(Int32Use, Int32Use, CheckOverflow) then AI will prove that this returns
Int32. We may later perform code simplifications based on the proof that this is Int32, and
we may kill all DFG users of this ArithAdd. Then we may prove that there is no exit site at
which the ArithAdd is live. This seems like it is sufficient to then kill the ArithAdd,
except that we still need the overflow check!
Previously we mishandled this:
- In places where we want the overflow check we need to use MustGenerate(@ArithAdd) as a hack
to keep it alive. That's dirty and it's just indicative of a deeper issue.
- Our MovHint removal doesn't do Phantom canonicalization which essentially makes it
powerless. This was sort of hiding the bug.
- Nodes that have checks that AI leverages should always be NodeMustGenerate. You can't kill
something that you are relying on for subsequent simplifications.
This fixes MovHint removal to also canonicalize Phantoms. This also adds ModeMustGenerate to
nodes that may perform checks that are used by AI to guarantee the result type. As a result,
we no longer need the weird MustGenerate node.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDCEPhase.cpp:
(JSC::DFG::DCEPhase::run):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::tryToRelaxRepresentation):
* dfg/DFGIntegerCheckCombiningPhase.cpp:
(JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
(JSC::DFG::IntegerCheckCombiningPhase::insertMustAdd): Deleted.
* dfg/DFGMayExit.cpp:
(JSC::DFG::mayExit):
* dfg/DFGNode.h:
(JSC::DFG::Node::willHaveCodeGenOrOSR):
* dfg/DFGNodeType.h:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
* dfg/DFGPhantomCanonicalizationPhase.cpp:
(JSC::DFG::PhantomCanonicalizationPhase::run):
* dfg/DFGPhantomRemovalPhase.cpp:
(JSC::DFG::PhantomRemovalPhase::run):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
* dfg/DFGVarargsForwardingPhase.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
* tests/stress/fold-based-on-int32-proof-mul-branch.js: Added.
(foo):
* tests/stress/fold-based-on-int32-proof-mul.js: Added.
(foo):
* tests/stress/fold-based-on-int32-proof-or-zero.js: Added.
(foo):
* tests/stress/fold-based-on-int32-proof.js: Added.
(foo):
2015-04-26 Ryosuke Niwa <rniwa@webkit.org>
Class body ending with a semicolon throws a SyntaxError
https://bugs.webkit.org/show_bug.cgi?id=144244
Reviewed by Darin Adler.
The bug was caused by parseClass's inner loop for method definitions not moving onto the next iteration
it encounters a semicolon. As a result, we always expected a method to appear after a semicolon. Fixed
it by continue'ing when it encounters a semicolon.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
2015-04-26 Ryosuke Niwa <rniwa@webkit.org>
Getter or setter method named "prototype" or "constrcutor" should throw SyntaxError
https://bugs.webkit.org/show_bug.cgi?id=144243
Reviewed by Darin Adler.
Fixed the bug by adding explicit checks in parseGetterSetter when we're parsing class methods.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseGetterSetter):
2015-04-26 Jordan Harband <ljharb@gmail.com>
Map#forEach does not pass "map" argument to callback.
https://bugs.webkit.org/show_bug.cgi?id=144187
Reviewed by Darin Adler.
Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-map.prototype.foreach
step 7.a.i., the callback should be called with three arguments.
* runtime/MapPrototype.cpp:
(JSC::mapProtoFuncForEach):
2015-04-26 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement ES6 template literals
https://bugs.webkit.org/show_bug.cgi?id=142691
Reviewed by Darin Adler.
This patch implements TemplateLiteral.
Since TaggedTemplate requires some global states and
primitive operations like GetTemplateObject,
we separate the patch. It will be implemented in a subsequent patch.
Template Literal Syntax is guarded by ENABLE_ES6_TEMPLATE_LITERAL_SYNTAX compile time flag.
By disabling it, we can disable Template Literal support.
To implement template literals, in this patch,
we newly introduces bytecode op_to_string.
In template literals, we alternately evaluate the expression and
perform ToString onto the result of evaluation.
For example,
`${f1()} ${f2()}`
In this template literal, execution order is the following,
1. calling f1()
2. ToString(the result of f1())
3. calling f2()
4. ToString(the result of f2())
op_strcat also performs ToString. However, performing ToString
onto expressions are batched in op_strcat, it's not the same to the
template literal spec. In the above example,
ToString(f1()) should be called before calling f2().
* Configurations/FeatureDefines.xcconfig:
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::emitToString):
(JSC::BytecodeGenerator::emitToNumber): Deleted.
* bytecompiler/NodesCodegen.cpp:
(JSC::TemplateStringNode::emitBytecode):
(JSC::TemplateLiteralNode::emitBytecode):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_to_string):
(JSC::JIT::emitSlow_op_to_string):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_to_string):
(JSC::JIT::emitSlow_op_to_string):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createTemplateString):
(JSC::ASTBuilder::createTemplateStringList):
(JSC::ASTBuilder::createTemplateExpressionList):
(JSC::ASTBuilder::createTemplateLiteral):
* parser/Lexer.cpp:
(JSC::Lexer<T>::Lexer):
(JSC::Lexer<T>::parseIdentifierSlowCase):
(JSC::Lexer<T>::parseString):
(JSC::LineNumberAdder::LineNumberAdder):
(JSC::LineNumberAdder::clear):
(JSC::LineNumberAdder::add):
(JSC::Lexer<T>::parseTemplateLiteral):
(JSC::Lexer<T>::lex):
(JSC::Lexer<T>::scanRegExp):
(JSC::Lexer<T>::scanTrailingTemplateString):
(JSC::Lexer<T>::parseStringSlowCase): Deleted.
* parser/Lexer.h:
* parser/NodeConstructors.h:
(JSC::TemplateExpressionListNode::TemplateExpressionListNode):
(JSC::TemplateStringNode::TemplateStringNode):
(JSC::TemplateStringListNode::TemplateStringListNode):
(JSC::TemplateLiteralNode::TemplateLiteralNode):
* parser/Nodes.h:
(JSC::TemplateExpressionListNode::value):
(JSC::TemplateExpressionListNode::next):
(JSC::TemplateStringNode::cooked):
(JSC::TemplateStringNode::raw):
(JSC::TemplateStringListNode::value):
(JSC::TemplateStringListNode::next):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseTemplateString):
(JSC::Parser<LexerType>::parseTemplateLiteral):
(JSC::Parser<LexerType>::parsePrimaryExpression):
* parser/Parser.h:
* parser/ParserTokens.h:
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createTemplateString):
(JSC::SyntaxChecker::createTemplateStringList):
(JSC::SyntaxChecker::createTemplateExpressionList):
(JSC::SyntaxChecker::createTemplateLiteral):
(JSC::SyntaxChecker::createSpreadExpression): Deleted.
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* tests/stress/template-literal-line-terminators.js: Added.
(test):
(testEval):
(testEvalLineNumber):
* tests/stress/template-literal-syntax.js: Added.
(testSyntax):
(testSyntaxError):
* tests/stress/template-literal.js: Added.
(test):
(testEval):
(testEmbedded):
2015-04-26 Jordan Harband <ljharb@gmail.com>
Set#forEach does not pass "key" or "set" arguments to callback.
https://bugs.webkit.org/show_bug.cgi?id=144188
Reviewed by Darin Adler.
Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype.foreach
Set#forEach should pass 3 arguments to the callback.
* runtime/SetPrototype.cpp:
(JSC::setProtoFuncForEach):
2015-04-26 Benjamin Poulain <benjamin@webkit.org>
[JSC] Implement Math.clz32(), remove Number.clz()
https://bugs.webkit.org/show_bug.cgi?id=144205
Reviewed by Michael Saboff.
This patch adds the ES6 function Math.clz32(), and remove the non-standard
Number.clz(). Number.clz() probably came from an older draft.
The new function has a corresponding instrinsic: Clz32Intrinsic,
and a corresponding DFG node: ArithClz32, optimized all the way to LLVM.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::countLeadingZeros32):
* assembler/X86Assembler.h:
(JSC::X86Assembler::bsr_rr):
The x86 assembler did not have countLeadingZeros32() because there is
no native CLZ instruction on that architecture.
I have added the version with bsr + branches for the case of zero.
An other popular version uses cmov to handle the case of zero. I kept
it simple since the Assembler has no support for cmov.
It is unlikely to matter much. If the code is hot enough, LLVM picks
something good based on the surrounding code.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
Constant handling + effect propagation. The node only produces integer (between 0 and 32).
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
Thanks to the definition of toUint32(), we can ignore plenty of details
from doubles.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsic):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithClz32):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLIntrinsicRepository.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileArithClz32):
* ftl/FTLOutput.h:
(JSC::FTL::Output::ctlz32):
* jit/ThunkGenerators.cpp:
(JSC::clz32ThunkGenerator):
* jit/ThunkGenerators.h:
* runtime/Intrinsic.h:
* runtime/MathCommon.h:
(JSC::clz32):
Fun fact: InstCombine does not recognize this pattern to eliminate
the branch which makes our FTL version better than the C version.
* runtime/MathObject.cpp:
(JSC::MathObject::finishCreation):
(JSC::mathProtoFuncClz32):
* runtime/NumberPrototype.cpp:
(JSC::clz): Deleted.
(JSC::numberProtoFuncClz): Deleted.
* runtime/VM.cpp:
(JSC::thunkGeneratorForIntrinsic):
* tests/stress/math-clz32-basics.js: Added.
(mathClz32OnInteger):
(testMathClz32OnIntegers):
(verifyMathClz32OnIntegerWithOtherTypes):
(mathClz32OnDouble):
(testMathClz32OnDoubles):
(verifyMathClz32OnDoublesWithOtherTypes):
(mathClz32NoArguments):
(mathClz32TooManyArguments):
(testMathClz32OnConstants):
(mathClz32StructTransition):
(Math.clz32):
2015-04-26 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Array.from need to accept iterables
https://bugs.webkit.org/show_bug.cgi?id=141055
Reviewed by Darin Adler.
ES6 spec requires that Array.from accepts iterable objects.
This patch introduces this functionality, Array.from accepting iterable objects.
Currently, `isConstructor` is not used. Instead of it, `typeof thiObj === "function"` is used.
However, it doesn't conform to the spec. While `isConstructor` queries the given object has `[[Construct]]`,
`typeof thisObj === "function"` queries the given object has `[[Call]]`.
This will be fixed in the subsequent patch[1].
[1]: https://bugs.webkit.org/show_bug.cgi?id=144093
* builtins/ArrayConstructor.js:
(from):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
* runtime/CommonIdentifiers.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* tests/stress/array-from-with-iterable.js: Added.
(shouldBe):
(.set for):
(.set var):
(.get var):
(argumentsGenerators):
(.set shouldBe):
(.set new):
* tests/stress/array-from-with-iterator.js: Added.
(shouldBe):
(shouldThrow):
(createIterator.iterator.return):
(createIterator):
(.):
2015-04-25 Jordan Harband <ljharb@gmail.com>
Set#keys !== Set#values
https://bugs.webkit.org/show_bug.cgi?id=144190
Reviewed by Darin Adler.
per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype.keys
Set#keys should === Set#values
* runtime/SetPrototype.cpp:
(JSC::SetPrototype::finishCreation):
(JSC::setProtoFuncValues):
(JSC::setProtoFuncEntries):
(JSC::setProtoFuncKeys): Deleted.
2015-04-25 Joseph Pecoraro <pecoraro@apple.com>
Allow for pausing a JSContext when opening a Web Inspector
<rdar://problem/20564788>
Reviewed by Timothy Hatcher.
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::receivedSetupMessage):
* inspector/remote/RemoteInspectorConstants.h:
* inspector/remote/RemoteInspectorDebuggable.h:
* inspector/remote/RemoteInspectorDebuggableConnection.h:
* inspector/remote/RemoteInspectorDebuggableConnection.mm:
(Inspector::RemoteInspectorDebuggableConnection::setup):
On any incoming setup message, we may want to automatically
pause the debuggable. If requested, pause the debuggable
after we have setup the frontend connection.
* runtime/JSGlobalObjectDebuggable.h:
* runtime/JSGlobalObjectDebuggable.cpp:
(JSC::JSGlobalObjectDebuggable::pause):
Pass through to the inspector controller.
* inspector/JSGlobalObjectInspectorController.h:
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::pause):
Enable pause on next statement.
2015-04-23 Ryosuke Niwa <rniwa@webkit.org>
class methods should be non-enumerable
https://bugs.webkit.org/show_bug.cgi?id=143181
Reviewed by Darin Adler.
Fixed the bug by using Object.defineProperty to define methods.
This patch adds the concept of link time constants and uses it to resolve Object.defineProperty
inside CodeBlock's constructor since bytecode can be linked against multiple global objects.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock): Resolve link time constants that are used. Ignore ones with register
index of zero.
* bytecode/SpecialPointer.h: Added a new enum for link time constants. It currently contains
exactly one entry for Object.defineProperty.
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::addConstant): Added. Like addConstant that takes JSValue, allocate a new
constant register for the link time constant we're adding.
(JSC::UnlinkedCodeBlock::registerIndexForLinkTimeConstant): Added.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitMoveLinkTimeConstant): Added. Like addConstantValue, allocate a new
register for the specified link time constant and notify UnlinkedCodeBlock about it.
(JSC::BytecodeGenerator::emitCallDefineProperty): Added. Create a new property descriptor and call
Object.defineProperty with it.
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::PropertyListNode::emitBytecode): Make static and non-static getters and setters for classes
non-enumerable by using emitCallDefineProperty to define them.
(JSC::PropertyListNode::emitPutConstantProperty): Ditto for a non-accessor properties.
(JSC::ClassExprNode::emitBytecode): Make prototype.constructor non-enumerable and make prototype
property on the class non-writable, non-configurable, and non-enumerable by using defineProperty.
* runtime/CommonIdentifiers.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init): Set m_definePropertyFunction.
(JSC::JSGlobalObject::visitChildren): Visit m_definePropertyFunction.
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::definePropertyFunction): Added.
(JSC::JSGlobalObject::actualPointerFor): Added a variant that takes LinkTimeConstant.
(JSC::JSGlobalObject::jsCellForLinkTimeConstant): Like actualPointerFor, takes LinkTimeConstant and
returns a JSCell; e.g. Object.defineProperty.
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructor::addDefineProperty): Added. Returns Object.defineProperty.
* runtime/ObjectConstructor.h:
2015-04-25 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement String.fromCodePoint
https://bugs.webkit.org/show_bug.cgi?id=144160
Reviewed by Darin Adler.
This patch implements String.fromCodePoint.
It accepts multiple code points and generates a string that consists of given code points.
The range [0x0000 - 0x10FFFF] is valid for code points.
If the given value is out of range, throw a range error.
When a 0xFFFF <= valid code point is given,
String.fromCodePoint generates a string that contains surrogate pairs.
* runtime/StringConstructor.cpp:
(JSC::stringFromCodePoint):
(JSC::constructWithStringConstructor):
* tests/stress/string-from-code-point.js: Added.
(shouldBe):
(shouldThrow):
(toCodePoints):
(passThrough):
2015-04-25 Martin Robinson <mrobinson@igalia.com>
Rename ENABLE_3D_RENDERING to ENABLE_3D_TRANSFORMS
https://bugs.webkit.org/show_bug.cgi?id=144182
Reviewed by Simon Fraser.
* Configurations/FeatureDefines.xcconfig: Replace all instances of 3D_RENDERING with 3D_TRANSFORMS.
2015-04-25 Mark Lam <mark.lam@apple.com>
mayExit() is wrong about Branch nodes with ObjectOrOtherUse: they can exit.
https://bugs.webkit.org/show_bug.cgi?id=144152
Reviewed by Filip Pizlo.
Changed the EdgeMayExit functor to recognize ObjectUse, ObjectOrOtherUse,
StringObjectUse, and StringOrStringObjectUse kinds as potentially triggering
OSR exits. This was overlooked in the original code.
While only the ObjectOrOtherUse kind is relevant for manifesting this bug with
the Branch node, the other 3 may also trigger the same bug for other nodes.
To prevent this bug from manifesting with other nodes (and future ones that
are yet to be added to mayExits()'s "potential won't exit" set), we fix the
EdgeMayExit functor to handle all 4 use kinds (instead of just ObjectOrOtherUse).
Also added a test to exercise a code path that will trigger this bug with
the Branch node before the fix is applied.
* dfg/DFGMayExit.cpp:
* tests/stress/branch-may-exit-due-to-object-or-other-use-kind.js: Added.
(inlinedFunction):
(foo):
2015-04-24 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r183288.
https://bugs.webkit.org/show_bug.cgi?id=144189
Made js/sort-with-side-effecting-comparisons.html time out in
debug builds (Requested by ap on #webkit).
Reverted changeset:
"It shouldn't take 1846 lines of code and 5 FIXMEs to sort an
array."
https://bugs.webkit.org/show_bug.cgi?id=144013
http://trac.webkit.org/changeset/183288
2015-04-24 Filip Pizlo <fpizlo@apple.com>
CRASH in operationCreateDirectArgumentsDuringExit()
https://bugs.webkit.org/show_bug.cgi?id=143962
Reviewed by Geoffrey Garen.
We shouldn't assume that constant-like OSR exit values are always recoverable. They are only
recoverable so long as they are live. Therefore, OSR exit should track liveness of
constants instead of assuming that they are always live.
* dfg/DFGGenerationInfo.h:
(JSC::DFG::GenerationInfo::noticeOSRBirth):
(JSC::DFG::GenerationInfo::appendBirth):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCurrentBlock):
* dfg/DFGVariableEvent.cpp:
(JSC::DFG::VariableEvent::dump):
* dfg/DFGVariableEvent.h:
(JSC::DFG::VariableEvent::birth):
(JSC::DFG::VariableEvent::id):
(JSC::DFG::VariableEvent::dataFormat):
* dfg/DFGVariableEventStream.cpp:
(JSC::DFG::VariableEventStream::reconstruct):
* tests/stress/phantom-direct-arguments-clobber-argument-count.js: Added.
(foo):
(bar):
* tests/stress/phantom-direct-arguments-clobber-callee.js: Added.
(foo):
(bar):
2015-04-24 Benjamin Poulain <bpoulain@apple.com>
[JSC] When inserting a NaN into a Int32 array, we convert it to DoubleArray then to ContiguousArray
https://bugs.webkit.org/show_bug.cgi?id=144169
Reviewed by Geoffrey Garen.
* runtime/JSObject.cpp:
(JSC::JSObject::convertInt32ForValue):
DoubleArray do not store NaN, they are used for holes.
What happened was:
1) We fail to insert the NaN in the Int32 array because it is a double.
2) We were converting the array to DoubleArray.
3) We were trying to insert the value again. We would fail again because
DoubleArray does not store NaN.
4) We would convert the DoubleArrayt to Contiguous Array, converting the values
to boxed values.
* tests/stress/int32array-transition-on-nan.js: Added.
The behavior is not really observable. This only test nothing crashes in those
cases.
(insertNaNWhileFilling):
(testInsertNaNWhileFilling):
(insertNaNAfterFilling):
(testInsertNaNAfterFilling):
(pushNaNWhileFilling):
(testPushNaNWhileFilling):
2015-04-21 Geoffrey Garen <ggaren@apple.com>
It shouldn't take 1846 lines of code and 5 FIXMEs to sort an array.
https://bugs.webkit.org/show_bug.cgi?id=144013
Reviewed by Mark Lam.
This patch implements Array.prototype.sort in JavaScript, removing the
C++ implementations. It is simpler and less error-prone to express our
operations in JavaScript, which provides memory safety, exception safety,
and recursion safety.
The performance result is mixed, but net positive in my opinion. It's
difficult to enumerate all the results, since we used to have so many
different sorting modes, and there are lots of different data patterns
across which you might want to measure sorting. Suffice it to say:
(*) The benchmarks we track are faster or unchanged.
(*) Sorting random input using a comparator -- which we think is
common -- is 3X faster.
(*) Sorting random input in a non-array object -- which jQuery does
-- is 4X faster.
(*) Sorting random input in a compact array of integers using a
trivial pattern-matchable comparator is 2X *slower*.
* builtins/Array.prototype.js:
(sort.min):
(sort.stringComparator):
(sort.compactSparse): Special case compaction for sparse arrays because
we don't want to hang when sorting new Array(BIG).
(sort.compact):
(sort.merge):
(sort.mergeSort): Use merge sort because it's a reasonably efficient
stable sort. We have evidence that some sites depend on stable sort,
even though the ES6 spec does not mandate it. (See
<http://trac.webkit.org/changeset/33967>.)
This is a textbook implementation of merge sort with three optimizations:
(1) Use iteration instead of recursion;
(2) Use array subscripting instead of array copying in order to
create logical sub-lists without creating physical sub-lists;
(3) Swap src and dst at each iteration instead of copying src into
dst, and only copy src into the subject array at the end if src is
not the subject array.
(sort.inflate):
(sort.comparatorSort):
(sort): Sort in JavaScript for the win.
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createExecutableInternal): Allow non-private
names so we can use helper functions.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::isNumericCompareFunction): Deleted.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::setIsNumericCompareFunction): Deleted.
(JSC::UnlinkedCodeBlock::isNumericCompareFunction): Deleted.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::setIsNumericCompareFunction): Deleted.
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionNode::emitBytecode): We don't do this special casing based
on pattern matching anymore. This was mainly an optimization to avoid
the overhead of calling from C++ to JS, which we now avoid by
sorting in JS.
* heap/Heap.cpp:
(JSC::Heap::markRoots):
(JSC::Heap::pushTempSortVector): Deleted.
(JSC::Heap::popTempSortVector): Deleted.
(JSC::Heap::visitTempSortVectors): Deleted.
* heap/Heap.h: We don't have temp sort vectors anymore because we sort
in JavaScript using a normal JavaScript array for our temporary storage.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner): Allow capturing so we can use
helper functions.
* runtime/ArrayPrototype.cpp:
(JSC::isNumericCompareFunction): Deleted.
(JSC::attemptFastSort): Deleted.
(JSC::performSlowSort): Deleted.
(JSC::arrayProtoFuncSort): Deleted.
* runtime/CommonIdentifiers.h: New strings used by sort.
* runtime/JSArray.cpp:
(JSC::compareNumbersForQSortWithInt32): Deleted.
(JSC::compareNumbersForQSortWithDouble): Deleted.
(JSC::compareNumbersForQSort): Deleted.
(JSC::compareByStringPairForQSort): Deleted.
(JSC::JSArray::sortNumericVector): Deleted.
(JSC::JSArray::sortNumeric): Deleted.
(JSC::ContiguousTypeAccessor::getAsValue): Deleted.
(JSC::ContiguousTypeAccessor::setWithValue): Deleted.
(JSC::ContiguousTypeAccessor::replaceDataReference): Deleted.
(JSC::ContiguousTypeAccessor<ArrayWithDouble>::getAsValue): Deleted.
(JSC::ContiguousTypeAccessor<ArrayWithDouble>::setWithValue): Deleted.
(JSC::ContiguousTypeAccessor<ArrayWithDouble>::replaceDataReference): Deleted.
(JSC::JSArray::sortCompactedVector): Deleted.
(JSC::JSArray::sort): Deleted.
(JSC::AVLTreeAbstractorForArrayCompare::get_less): Deleted.
(JSC::AVLTreeAbstractorForArrayCompare::set_less): Deleted.
(JSC::AVLTreeAbstractorForArrayCompare::get_greater): Deleted.
(JSC::AVLTreeAbstractorForArrayCompare::set_greater): Deleted.
(JSC::AVLTreeAbstractorForArrayCompare::get_balance_factor): Deleted.
(JSC::AVLTreeAbstractorForArrayCompare::set_balance_factor): Deleted.
(JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): Deleted.
(JSC::AVLTreeAbstractorForArrayCompare::compare_key_node): Deleted.
(JSC::AVLTreeAbstractorForArrayCompare::compare_node_node): Deleted.
(JSC::AVLTreeAbstractorForArrayCompare::null): Deleted.
(JSC::JSArray::sortVector): Deleted.
(JSC::JSArray::compactForSorting): Deleted.
* runtime/JSArray.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructor::finishCreation): Provide some builtins used
by sort.
2015-04-24 Matthew Mirman <mmirman@apple.com>
Made Object.prototype.__proto__ native getter and setter check that this object not null or undefined
https://bugs.webkit.org/show_bug.cgi?id=141865
rdar://problem/19927273
Reviewed by Filip Pizlo.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncProtoGetter):
(JSC::globalFuncProtoSetter):
2015-04-23 Benjamin Poulain <bpoulain@apple.com>
Remove a useless branch on DFGGraph::addShouldSpeculateMachineInt()
https://bugs.webkit.org/show_bug.cgi?id=144118
Reviewed by Geoffrey Garen.
* dfg/DFGGraph.h:
(JSC::DFG::Graph::addShouldSpeculateMachineInt):
Both block do the same thing.
2015-04-23 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Speculative fix for non-main thread auto-attach failures
https://bugs.webkit.org/show_bug.cgi?id=144134
Reviewed by Timothy Hatcher.
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::singleton):
2015-04-23 Basile Clement <basile_clement@apple.com>
Allow function allocation sinking
https://bugs.webkit.org/show_bug.cgi?id=144016
Reviewed by Filip Pizlo.
This adds the ability to sink function allocations in the
DFGObjectAllocationSinkingPhase.
In order to enable this, we add a new PhantomNewFunction node that is
used similarily to the PhantomNewObject node, i.e. as a placeholder to replace
a sunk NewFunction and keep track of the allocations that have to be performed
in case of OSR exit after the sunk allocation but before the real one.
The FunctionExecutable and JSLexicalEnvironment (activation) of the function
are stored onto the PhantomNewFunction through PutHints in order for them
to be recovered on OSR exit.
Contrary to sunk object allocations, sunk function allocations do not
support any kind of operations (e.g. storing into a field) ; any such operation
will mark the function allocation as escaping and trigger materialization. As
such, function allocations can only be sunk to places where it would have been
correct to syntactically move them, and we don't need a special
MaterializeNewFunction node to recover possible operations on the function. A
sunk NewFunction node will simply create new NewFunction nodes, then replace
itself with a PhantomNewFunction node.
In itself, this change is not expected to have a significant impact on
performances other than in degenerate cases (see e.g.
JSRegress/sink-function), but it is a step towards being able to sink recursive
closures onces we support CreateActivation sinking as well as allocation cycles
sinking.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToPhantomNewFunction):
(JSC::DFG::Node::isPhantomAllocation):
* dfg/DFGNodeType.h:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
(JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
(JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
(JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGPromotedHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGPromotedHeapLocation.h:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::validateCPS):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
* tests/stress/function-sinking-no-double-allocate.js: Added.
(call):
(.f):
(sink):
* tests/stress/function-sinking-osrexit.js: Added.
(.g):
(sink):
* tests/stress/function-sinking-put.js: Added.
(.g):
(sink):
2015-04-23 Basile Clement <basile_clement@apple.com>
Make FunctionRareData allocation thread-safe
https://bugs.webkit.org/show_bug.cgi?id=144001
Reviewed by Mark Lam.
The two things we want to prevent are:
1. A thread seeing a pointer to a not-yet-fully-created rare data from
a JSFunction
2. A thread seeing a pointer to a not-yet-fully-created Structure from
an ObjectAllocationProfile
For 1., only the JS thread can be creating the rare data (in
runtime/CommonSlowPaths.cpp or in dfg/DFGOperations.cpp), so we don't need to
worry about concurrent writes, and we don't need any fences when *reading* the
rare data from the JS thread. Thus we only need a storeStoreFence between the
rare data creation and assignment to m_rareData in
JSFunction::createAndInitializeRareData() to ensure that when the store to
m_rareData is issued, the rare data has been properly created.
For the DFG compilation threads, the only place they can access the
rare data is through JSFunction::rareData(), and so we only need a
loadLoadFence there to ensure that when we see a non-null pointer in
m_rareData, the pointed object will be seen as a fully created
FunctionRareData.
For 2., the structure is created in
ObjectAllocationProfile::initialize() (which appears to be called only by the
JS thread as well, in bytecode/CodeBlock.cpp and on rare data initialization,
which always happen in the JS thread), and read through
ObjectAllocationProfile::structure() and
ObjectAllocationProfile::inlineCapacity(), so following the same reasoning we
put a storeStoreFence in ObjectAllocationProfile::initialize() and a
loadLoadFence in ObjectAllocationProfile::structure() (and change
ObjectAllocationProfile::inlineCapacity() to go through
ObjectAllocationProfile::structure()).
We don't need a fence in ObjectAllocationProfile::clear() because
clearing the structure is already as atomic as it gets.
Finally, notice that we don't care about the ObjectAllocationProfile's
m_allocator as that is only used by ObjectAllocationProfile::initialize() and
ObjectAllocationProfile::clear() that are always run in the JS thread.
ObjectAllocationProfile::isNull() could cause some trouble, but it is
currently only used in the ObjectAllocationProfile::clear()'s ASSERT in the JS
thread. Doing isNull()-style pre-checks would be wrong in any other concurrent
thread anyway.
* bytecode/ObjectAllocationProfile.h:
(JSC::ObjectAllocationProfile::initialize):
(JSC::ObjectAllocationProfile::structure):
(JSC::ObjectAllocationProfile::inlineCapacity):
* runtime/JSFunction.cpp:
(JSC::JSFunction::allocateAndInitializeRareData):
* runtime/JSFunction.h:
(JSC::JSFunction::rareData):
(JSC::JSFunction::allocationStructure): Deleted.
This is no longer used, as all the accesses to the ObjectAllocationProfile go through the rare data.
2015-04-22 Filip Pizlo <fpizlo@apple.com>
DFG should insert Phantoms late using BytecodeKills and block-local OSR availability
https://bugs.webkit.org/show_bug.cgi?id=143735
Reviewed by Geoffrey Garen.
We've always had bugs arising from the fact that we would MovHint something into a local,
and then fail to keep it alive. We would then try to keep things alive by putting Phantoms
on those Nodes that were MovHinted. But this became increasingly tricky. Given the
sophistication of the transformations we are doing today, this approach is just not sound
anymore.
This comprehensively fixes these bugs by having the DFG backend automatically insert
Phantoms just before codegen based on bytecode liveness. To make this practical, this also
makes it much faster to query bytecode liveness.
It's about as perf-neutral as it gets for a change that increases compiler work without
actually optimizing anything. Later changes will remove the old Phantom-preserving logic,
which should then speed us up. I can't really report concrete slow-down numbers because
they are low enough to basically be in the noise. For example, a 20-iteration run of
SunSpider yields "maybe 0.8% slower", whatever that means.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/BytecodeLivenessAnalysis.cpp:
(JSC::BytecodeLivenessAnalysis::computeFullLiveness):
* bytecode/FullBytecodeLiveness.h:
(JSC::FullBytecodeLiveness::getLiveness):
* bytecode/VirtualRegister.h:
(JSC::VirtualRegister::operator+):
(JSC::VirtualRegister::operator-):
* dfg/DFGForAllKills.h:
(JSC::DFG::forAllLiveNodesAtTail):
(JSC::DFG::forAllKilledOperands):
(JSC::DFG::forAllKilledNodesAtNodeIndex):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::isLiveInBytecode):
(JSC::DFG::Graph::localsLiveInBytecode):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::forAllLocalsLiveInBytecode):
(JSC::DFG::Graph::forAllLiveInBytecode):
* dfg/DFGMayExit.cpp:
(JSC::DFG::mayExit):
* dfg/DFGMovHintRemovalPhase.cpp:
* dfg/DFGNodeType.h:
* dfg/DFGPhantomInsertionPhase.cpp: Added.
(JSC::DFG::performPhantomInsertion):
* dfg/DFGPhantomInsertionPhase.h: Added.
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGScoreBoard.h:
(JSC::DFG::ScoreBoard::sortFree):
(JSC::DFG::ScoreBoard::assertClear):
* dfg/DFGVirtualRegisterAllocationPhase.cpp:
(JSC::DFG::VirtualRegisterAllocationPhase::run):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::buildExitArguments):
* tests/stress/phantom-inadequacy.js: Added.
(bar):
(baz):
(foo):
2015-04-23 Filip Pizlo <fpizlo@apple.com>
Rename HardPhantom to MustGenerate.
Rubber stamped by Geoffrey Garen.
We are steadily moving towards Phantom just being a backend hack in the DFG. HardPhantom
is more than that; it's a utility for forcing the execution of otherwise killable nodes.
NodeMustGenerate is the flag we use to indicate that something isn't killable. So this
node should just be called MustGenerate.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDCEPhase.cpp:
(JSC::DFG::DCEPhase::run):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::tryToRelaxRepresentation):
* dfg/DFGIntegerCheckCombiningPhase.cpp:
(JSC::DFG::IntegerCheckCombiningPhase::insertMustAdd):
* dfg/DFGMayExit.cpp:
(JSC::DFG::mayExit):
* dfg/DFGNode.h:
(JSC::DFG::Node::willHaveCodeGenOrOSR):
* dfg/DFGNodeType.h:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
* dfg/DFGPhantomCanonicalizationPhase.cpp:
(JSC::DFG::PhantomCanonicalizationPhase::run):
* dfg/DFGPhantomRemovalPhase.cpp:
(JSC::DFG::PhantomRemovalPhase::run):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
* dfg/DFGVarargsForwardingPhase.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
2015-04-23 Jordan Harband <ljharb@gmail.com>
Implement `Object.assign`
https://bugs.webkit.org/show_bug.cgi?id=143980
Reviewed by Filip Pizlo.
per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.assign
* builtins/ObjectConstructor.js: Added.
(assign):
* runtime/CommonIdentifiers.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/ObjectConstructor.cpp:
* runtime/ObjectConstructor.h:
2015-04-22 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix debug build.
* dfg/DFGGraph.h:
(JSC::DFG::Graph::performSubstitutionForEdge):
2015-04-22 Filip Pizlo <fpizlo@apple.com>
Nodes should have an optional epoch field
https://bugs.webkit.org/show_bug.cgi?id=144084
Reviewed by Ryosuke Niwa and Mark Lam.
This makes it easier to do epoch-based analyses on nodes. I plan to do just that in
https://bugs.webkit.org/show_bug.cgi?id=143735. Currently the epoch field is not yet
used.
* dfg/DFGCPSRethreadingPhase.cpp:
(JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
* dfg/DFGCSEPhase.cpp:
* dfg/DFGEpoch.h:
(JSC::DFG::Epoch::fromUnsigned):
(JSC::DFG::Epoch::toUnsigned):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::clearReplacements):
(JSC::DFG::Graph::clearEpochs):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::performSubstitutionForEdge):
* dfg/DFGNode.h:
(JSC::DFG::Node::Node):
(JSC::DFG::Node::replaceWith):
(JSC::DFG::Node::replacement):
(JSC::DFG::Node::setReplacement):
(JSC::DFG::Node::epoch):
(JSC::DFG::Node::setEpoch):
* dfg/DFGSSAConversionPhase.cpp:
(JSC::DFG::SSAConversionPhase::run):
2015-04-22 Mark Lam <mark.lam@apple.com>
Fix assertion failure and race condition in Options::dumpSourceAtDFGTime().
https://bugs.webkit.org/show_bug.cgi?id=143898
Reviewed by Filip Pizlo.
CodeBlock::dumpSource() will access SourceCode strings in a way that requires
ref'ing of the underlying StringImpls. This is unsafe to do from arbitrary
compilation threads because StringImpls are not thread safe. As a result, we get
an assertion failure when we run with JSC_dumpSourceAtDFGTime=true on a debug
build.
This patch fixes the issue by only collecting the CodeBlock (and associated info)
into a DeferredSourceDump record while compiling, and stashing it away in a
deferredSourceDump list in the DeferredCompilationCallback object to be dumped
later.
When compilation is done, the callback object will be notified that
compilationDidComplete(). We will dump the SourceCode strings from there.
Since compilationDidComplete() is guaranteed to only be called on the thread
doing JS execution, it is safe to access the SourceCode strings there and ref
their underlying StringImpls as needed.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/DeferredCompilationCallback.cpp:
(JSC::DeferredCompilationCallback::compilationDidComplete):
(JSC::DeferredCompilationCallback::sourceDumpInfo):
(JSC::DeferredCompilationCallback::dumpCompiledSources):
* bytecode/DeferredCompilationCallback.h:
* bytecode/DeferredSourceDump.cpp: Added.
(JSC::DeferredSourceDump::DeferredSourceDump):
(JSC::DeferredSourceDump::dump):
* bytecode/DeferredSourceDump.h: Added.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseCodeBlock):
* dfg/DFGDriver.cpp:
(JSC::DFG::compileImpl):
2015-04-22 Benjamin Poulain <benjamin@webkit.org>
Implement String.codePointAt()
https://bugs.webkit.org/show_bug.cgi?id=143934
Reviewed by Darin Adler.
This patch adds String.codePointAt() as defined by ES6.
I opted for a C++ implementation for now.
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
(JSC::codePointAt):
(JSC::stringProtoFuncCodePointAt):
2015-04-22 Mark Lam <mark.lam@apple.com>
SparseArrayEntry's write barrier owner should be the SparseArrayValueMap.
https://bugs.webkit.org/show_bug.cgi?id=144067
Reviewed by Michael Saboff.
Currently, there are a few places where the JSObject that owns the
SparseArrayValueMap is designated as the owner of the SparseArrayEntry
write barrier. This is a bug and can result in the GC collecting the
SparseArrayEntry even though it is being referenced by the
SparseArrayValueMap. This patch fixes the bug.
* runtime/JSObject.cpp:
(JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists):
(JSC::JSObject::putIndexedDescriptor):
* tests/stress/sparse-array-entry-update-144067.js: Added.
(useMemoryToTriggerGCs):
(foo):
2015-04-22 Mark Lam <mark.lam@apple.com>
Give the heap object iterators the ability to return early.
https://bugs.webkit.org/show_bug.cgi?id=144011
Reviewed by Michael Saboff.
JSDollarVMPrototype::isValidCell() uses a heap object iterator to validate
candidate cell pointers, and, when in use, is called a lot more often than
the normal way those iterators are used. As a result, I see my instrumented
VM killed with a SIGXCPU (CPU time limit exceeded). This patch gives the
callback functor the ability to tell the iterators to return early when the
functor no longer needs to continue iterating. With this, my instrumented
VM is useful again for debugging.
Since heap iteration is not something that we do in a typical fast path,
I don't expect this to have any noticeable impact on performance.
I also renamed ObjectAddressCheckFunctor to CellAddressCheckFunctor since
it checks JSCell addresses, not just JSObjects.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* debugger/Debugger.cpp:
* heap/GCLogging.cpp:
(JSC::LoggingFunctor::operator()):
* heap/Heap.cpp:
(JSC::Zombify::visit):
(JSC::Zombify::operator()):
* heap/HeapStatistics.cpp:
(JSC::StorageStatistics::visit):
(JSC::StorageStatistics::operator()):
* heap/HeapVerifier.cpp:
(JSC::GatherLiveObjFunctor::visit):
(JSC::GatherLiveObjFunctor::operator()):
* heap/MarkedBlock.cpp:
(JSC::SetNewlyAllocatedFunctor::operator()):
* heap/MarkedBlock.h:
(JSC::MarkedBlock::forEachCell):
(JSC::MarkedBlock::forEachLiveCell):
(JSC::MarkedBlock::forEachDeadCell):
* heap/MarkedSpace.h:
(JSC::MarkedSpace::forEachLiveCell):
(JSC::MarkedSpace::forEachDeadCell):
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::TypeRecompiler::visit):
(Inspector::TypeRecompiler::operator()):
* runtime/IterationStatus.h: Added.
* runtime/JSGlobalObject.cpp:
* runtime/VM.cpp:
(JSC::StackPreservingRecompiler::visit):
(JSC::StackPreservingRecompiler::operator()):
* tools/JSDollarVMPrototype.cpp:
(JSC::CellAddressCheckFunctor::CellAddressCheckFunctor):
(JSC::CellAddressCheckFunctor::operator()):
(JSC::JSDollarVMPrototype::isValidCell):
(JSC::ObjectAddressCheckFunctor::ObjectAddressCheckFunctor): Deleted.
(JSC::ObjectAddressCheckFunctor::operator()): Deleted.
2015-04-22 Yusuke Suzuki <utatane.tea@gmail.com>
[[Set]] should be properly executed in JS builtins
https://bugs.webkit.org/show_bug.cgi?id=143996
Reviewed by Geoffrey Garen.
Currently, all assignments in builtins JS code is compiled into put_by_val_direct.
However,
1. Some functions (like Array.from) needs [[Set]]. (but it is now compiled into put_by_val_direct, [[DefineOwnProperty]]).
2. It's different from the default JS behavior.
In this patch, we implement the bytecode intrinsic emitting put_by_val_direct and use it explicitly.
And dropping the current hack for builtins.
* builtins/Array.prototype.js:
(filter):
(map):
(find):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitPutByVal):
* tests/stress/array-fill-put-by-val.js: Added.
(shouldThrow):
(.set get array):
* tests/stress/array-filter-put-by-val-direct.js: Added.
(shouldBe):
(.set get var):
* tests/stress/array-find-does-not-lookup-twice.js: Added.
(shouldBe):
(shouldThrow):
(.get shouldBe):
* tests/stress/array-from-put-by-val-direct.js: Added.
(shouldBe):
(.set get var):
* tests/stress/array-from-set-length.js: Added.
(shouldBe):
(ArrayLike):
(ArrayLike.prototype.set length):
(ArrayLike.prototype.get length):
* tests/stress/array-map-put-by-val-direct.js: Added.
(shouldBe):
(.set get var):
2015-04-22 Basile Clement <basile_clement@apple.com>
Don't de-allocate FunctionRareData
https://bugs.webkit.org/show_bug.cgi?id=144000
Reviewed by Michael Saboff.
A function rare data (containing most notably its allocation profile) is currently
freed and re-allocated each time the function's prototype is cleared.
This is not optimal as it means we are invalidating the watchpoint and recompiling the
scope each time the prototype is cleared.
This makes it so that a single rare data is reused, clearing the underlying
ObjectAllocationProfile instead of throwing away the whole rare data on
.prototype updates.
* runtime/FunctionRareData.cpp:
(JSC::FunctionRareData::create):
(JSC::FunctionRareData::finishCreation):
* runtime/FunctionRareData.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::allocateAndInitializeRareData):
(JSC::JSFunction::initializeRareData):
2015-04-21 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix 32-bit. Forgot to make this simple change to 32_64 as well.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
2015-04-21 Filip Pizlo <fpizlo@apple.com>
DFG should allow Phantoms after terminals
https://bugs.webkit.org/show_bug.cgi?id=126778
Reviewed by Mark Lam.
It's important for us to be able to place liveness-marking nodes after nodes that do
things. These liveness-marking nodes are nops. Previously, we disallowed such nodes after
terminals. That made things awkward, especially for Switch and Branch, which may do
things that necessitate liveness markers (for example they might want to use a converted
version of a value rather than the value that was MovHinted). We previously made this
work by disallowing certain optimizations on Switch and Branch, which was probably a bad
thing.
This changes our IR to allow for the terminal to not be the last node in a block. Asking
for the terminal involves a search. DFG::validate() checks that the nodes after the
terminal are liveness markers that have no effects or checks.
This is perf-neutral but will allow more optimizations in the future. It will also make
it cleaner to fix https://bugs.webkit.org/show_bug.cgi?id=143735.
* dfg/DFGBasicBlock.cpp:
(JSC::DFG::BasicBlock::replaceTerminal):
* dfg/DFGBasicBlock.h:
(JSC::DFG::BasicBlock::findTerminal):
(JSC::DFG::BasicBlock::terminal):
(JSC::DFG::BasicBlock::insertBeforeTerminal):
(JSC::DFG::BasicBlock::numSuccessors):
(JSC::DFG::BasicBlock::successor):
(JSC::DFG::BasicBlock::successorForCondition):
(JSC::DFG::BasicBlock::successors):
(JSC::DFG::BasicBlock::last): Deleted.
(JSC::DFG::BasicBlock::takeLast): Deleted.
(JSC::DFG::BasicBlock::insertBeforeLast): Deleted.
(JSC::DFG::BasicBlock::SuccessorsIterable::SuccessorsIterable): Deleted.
(JSC::DFG::BasicBlock::SuccessorsIterable::iterator::iterator): Deleted.
(JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator*): Deleted.
(JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator++): Deleted.
(JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator==): Deleted.
(JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator!=): Deleted.
(JSC::DFG::BasicBlock::SuccessorsIterable::begin): Deleted.
(JSC::DFG::BasicBlock::SuccessorsIterable::end): Deleted.
* dfg/DFGBasicBlockInlines.h:
(JSC::DFG::BasicBlock::appendNonTerminal):
(JSC::DFG::BasicBlock::replaceTerminal):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addToGraph):
(JSC::DFG::ByteCodeParser::inlineCall):
(JSC::DFG::ByteCodeParser::handleInlining):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::linkBlock):
(JSC::DFG::ByteCodeParser::parseCodeBlock):
* dfg/DFGCFGSimplificationPhase.cpp:
(JSC::DFG::CFGSimplificationPhase::run):
(JSC::DFG::CFGSimplificationPhase::convertToJump):
(JSC::DFG::CFGSimplificationPhase::mergeBlocks):
* dfg/DFGCPSRethreadingPhase.cpp:
(JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
* dfg/DFGCommon.h:
(JSC::DFG::NodeAndIndex::NodeAndIndex):
(JSC::DFG::NodeAndIndex::operator!):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupBlock):
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::injectTypeConversionsInBlock):
(JSC::DFG::FixupPhase::clearPhantomsAtEnd): Deleted.
* dfg/DFGForAllKills.h:
(JSC::DFG::forAllLiveNodesAtTail):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::terminalsAreValid):
(JSC::DFG::Graph::dumpBlockHeader):
* dfg/DFGGraph.h:
* dfg/DFGInPlaceAbstractState.cpp:
(JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
* dfg/DFGLICMPhase.cpp:
(JSC::DFG::LICMPhase::run):
(JSC::DFG::LICMPhase::attemptHoist):
* dfg/DFGMovHintRemovalPhase.cpp:
* dfg/DFGNode.h:
(JSC::DFG::Node::SuccessorsIterable::SuccessorsIterable):
(JSC::DFG::Node::SuccessorsIterable::iterator::iterator):
(JSC::DFG::Node::SuccessorsIterable::iterator::operator*):
(JSC::DFG::Node::SuccessorsIterable::iterator::operator++):
(JSC::DFG::Node::SuccessorsIterable::iterator::operator==):
(JSC::DFG::Node::SuccessorsIterable::iterator::operator!=):
(JSC::DFG::Node::SuccessorsIterable::begin):
(JSC::DFG::Node::SuccessorsIterable::end):
(JSC::DFG::Node::successors):
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::ObjectAllocationSinkingPhase::determineMaterializationPoints):
(JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
(JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
* dfg/DFGPhantomRemovalPhase.cpp:
(JSC::DFG::PhantomRemovalPhase::run):
* dfg/DFGPutStackSinkingPhase.cpp:
* dfg/DFGSSAConversionPhase.cpp:
(JSC::DFG::SSAConversionPhase::run):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::detectPeepHoleBranch):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStaticExecutionCountEstimationPhase.cpp:
(JSC::DFG::StaticExecutionCountEstimationPhase::run):
* dfg/DFGTierUpCheckInjectionPhase.cpp:
(JSC::DFG::TierUpCheckInjectionPhase::run):
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::validate):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
* tests/stress/closure-call-exit.js: Added.
(foo):
2015-04-21 Basile Clement <basile_clement@apple.com>
PhantomNewObject should be marked NodeMustGenerate
https://bugs.webkit.org/show_bug.cgi?id=143974
Reviewed by Filip Pizlo.
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToPhantomNewObject):
Was not properly marking NodeMustGenerate when converting.
2015-04-21 Filip Pizlo <fpizlo@apple.com>
DFG Call/ConstructForwardVarargs fails to restore the stack pointer
https://bugs.webkit.org/show_bug.cgi?id=144007
Reviewed by Mark Lam.
We were conditioning the stack pointer restoration on isVarargs, but we also need to do it
if isForwardVarargs.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* tests/stress/varargs-then-slow-call.js: Added.
(foo):
(bar):
(fuzz):
(baz):
2015-04-21 Basile Clement <basile_clement@apple.com>
Remove AllocationProfileWatchpoint node
https://bugs.webkit.org/show_bug.cgi?id=143999
Reviewed by Filip Pizlo.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGHeapLocation.h:
* dfg/DFGNode.h:
(JSC::DFG::Node::hasCellOperand):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGWatchpointCollectionPhase.cpp:
(JSC::DFG::WatchpointCollectionPhase::handle):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
* runtime/JSFunction.h:
(JSC::JSFunction::rareData):
(JSC::JSFunction::allocationProfileWatchpointSet): Deleted.
2015-04-19 Filip Pizlo <fpizlo@apple.com>
MovHint should be a strong use
https://bugs.webkit.org/show_bug.cgi?id=143734
Reviewed by Geoffrey Garen.
This disables any DCE that assumes equivalence between DFG IR uses and bytecode uses. Doing
so is a major step towards allowing more fancy DFG transformations and also probably fixing
some bugs.
Just making MovHint a strong use would also completely disable DCE. So we mitigate this by
introducing a MovHint removal phase that runs in FTL.
This is a slight slowdown on Octane/gbemu, but it's basically neutral on suite averages.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeOrigin.cpp:
(JSC::InlineCallFrame::dumpInContext):
* dfg/DFGDCEPhase.cpp:
(JSC::DFG::DCEPhase::fixupBlock):
* dfg/DFGDisassembler.cpp:
(JSC::DFG::Disassembler::createDumpList):
* dfg/DFGEpoch.cpp: Added.
(JSC::DFG::Epoch::dump):
* dfg/DFGEpoch.h: Added.
(JSC::DFG::Epoch::Epoch):
(JSC::DFG::Epoch::first):
(JSC::DFG::Epoch::operator!):
(JSC::DFG::Epoch::next):
(JSC::DFG::Epoch::bump):
(JSC::DFG::Epoch::operator==):
(JSC::DFG::Epoch::operator!=):
* dfg/DFGMayExit.cpp:
(JSC::DFG::mayExit):
* dfg/DFGMovHintRemovalPhase.cpp: Added.
(JSC::DFG::performMovHintRemoval):
* dfg/DFGMovHintRemovalPhase.h: Added.
* dfg/DFGNodeType.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCurrentBlock):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* runtime/Options.h:
2015-04-21 Basile Clement <basile_clement@apple.com>
REGRESSION (r182899): icloud.com crashes
https://bugs.webkit.org/show_bug.cgi?id=143960
Reviewed by Filip Pizlo.
* runtime/JSFunction.h:
(JSC::JSFunction::allocationStructure):
* tests/stress/dfg-rare-data.js: Added.
(F): Regression test
2015-04-21 Michael Saboff <msaboff@apple.com>
Crash in JSC::Interpreter::execute
https://bugs.webkit.org/show_bug.cgi?id=142625
Reviewed by Filip Pizlo.
We need to keep the FunctionExecutables in the code block for the eval flavor of
Interpreter::execute() in order to create the scope used to eval.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::jettisonFunctionDeclsAndExprs): Deleted.
* bytecode/CodeBlock.h:
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::registerFrozenValues):
2015-04-21 Chris Dumez <cdumez@apple.com>
Make Vector(const Vector<T, otherCapacity, otherOverflowBehaviour>&) constructor explicit
https://bugs.webkit.org/show_bug.cgi?id=143970
Reviewed by Darin Adler.
Make Vector(const Vector<T, otherCapacity, otherOverflowBehaviour>&)
constructor explicit as it copies the vector and it is easy to call it
by mistake.
* bytecode/UnlinkedInstructionStream.cpp:
(JSC::UnlinkedInstructionStream::UnlinkedInstructionStream):
* bytecode/UnlinkedInstructionStream.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::lower):
2015-04-20 Basile Clement <basile_clement@apple.com>
PhantomNewObject should be marked NodeMustGenerate
https://bugs.webkit.org/show_bug.cgi?id=143974
Reviewed by Filip Pizlo.
* dfg/DFGNodeType.h: Mark PhantomNewObject as NodeMustGenerate
2015-04-20 Joseph Pecoraro <pecoraro@apple.com>
Cleanup some StringBuilder use
https://bugs.webkit.org/show_bug.cgi?id=143550
Reviewed by Darin Adler.
* runtime/Symbol.cpp:
(JSC::Symbol::descriptiveString):
* runtime/TypeProfiler.cpp:
(JSC::TypeProfiler::typeInformationForExpressionAtOffset):
* runtime/TypeSet.cpp:
(JSC::TypeSet::toJSONString):
(JSC::StructureShape::propertyHash):
(JSC::StructureShape::stringRepresentation):
(JSC::StructureShape::toJSONString):
2015-04-20 Mark Lam <mark.lam@apple.com>
Add debugging tools to test if a given pointer is a valid object and in the heap.
https://bugs.webkit.org/show_bug.cgi?id=143910
Reviewed by Geoffrey Garen.
When doing debugging from lldb, sometimes, it is useful to be able to tell if a
purported JSObject is really a valid object in the heap or not. We can add the
following utility functions to help:
isValidCell(heap, candidate) - returns true if the candidate is a "live" cell in the heap.
isInHeap(heap, candidate) - returns true if the candidate is the heap's Object space or Storage space.
isInObjectSpace(heap, candidate) - returns true if the candidate is the heap's Object space.
isInStorageSpace(heap, candidate) - returns true if the candidate is the heap's Storage space.
Also moved lldb callable debug utility function prototypes from
JSDollarVMPrototype.cpp to JSDollarVMPrototype.h as static members of the
JSDollarVMPrototype class. This is so that we can conveniently #include that
file to get the prototypes when we need to call them programmatically from
instrumentation that we add while debugging an issue.
* heap/Heap.h:
(JSC::Heap::storageSpace):
* tools/JSDollarVMPrototype.cpp:
(JSC::JSDollarVMPrototype::currentThreadOwnsJSLock):
(JSC::ensureCurrentThreadOwnsJSLock):
(JSC::JSDollarVMPrototype::gc):
(JSC::functionGC):
(JSC::JSDollarVMPrototype::edenGC):
(JSC::functionEdenGC):
(JSC::JSDollarVMPrototype::isInHeap):
(JSC::JSDollarVMPrototype::isInObjectSpace):
(JSC::JSDollarVMPrototype::isInStorageSpace):
(JSC::ObjectAddressCheckFunctor::ObjectAddressCheckFunctor):
(JSC::ObjectAddressCheckFunctor::operator()):
(JSC::JSDollarVMPrototype::isValidCell):
(JSC::JSDollarVMPrototype::isValidCodeBlock):
(JSC::JSDollarVMPrototype::codeBlockForFrame):
(JSC::functionCodeBlockForFrame):
(JSC::codeBlockFromArg):
(JSC::JSDollarVMPrototype::printCallFrame):
(JSC::JSDollarVMPrototype::printStack):
(JSC::JSDollarVMPrototype::printValue):
(JSC::currentThreadOwnsJSLock): Deleted.
(JSC::gc): Deleted.
(JSC::edenGC): Deleted.
(JSC::isValidCodeBlock): Deleted.
(JSC::codeBlockForFrame): Deleted.
(JSC::printCallFrame): Deleted.
(JSC::printStack): Deleted.
(JSC::printValue): Deleted.
* tools/JSDollarVMPrototype.h:
2015-04-20 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Improve Support for WeakSet in Console
https://bugs.webkit.org/show_bug.cgi?id=143951
Reviewed by Darin Adler.
* inspector/InjectedScriptSource.js:
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::subtype):
(Inspector::JSInjectedScriptHost::weakSetSize):
(Inspector::JSInjectedScriptHost::weakSetEntries):
* inspector/JSInjectedScriptHost.h:
* inspector/JSInjectedScriptHostPrototype.cpp:
(Inspector::JSInjectedScriptHostPrototype::finishCreation):
(Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetSize):
(Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetEntries):
Treat WeakSets like special sets.
* inspector/protocol/Runtime.json:
Add a new object subtype, "weakset".
2015-04-20 Yusuke Suzuki <utatane.tea@gmail.com>
HashMap storing PropertyKey StringImpl* need to use IdentifierRepHash to handle Symbols
https://bugs.webkit.org/show_bug.cgi?id=143947
Reviewed by Darin Adler.
Type profiler has map between PropertyKey (StringImpl*) and offset.
StringImpl* is also used for Symbol PropertyKey.
So equality of hash tables is considered by interned StringImpl*'s pointer value.
To do so, use IdentifierRepHash instead of StringHash.
* runtime/SymbolTable.h:
2015-04-20 Jordan Harband <ljharb@gmail.com>
Implement `Object.is`
https://bugs.webkit.org/show_bug.cgi?id=143865
Reviewed by Darin Adler.
Expose sameValue to JS, via Object.is
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.is
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorIs):
* runtime/PropertyDescriptor.cpp:
(JSC::sameValue):
2015-04-19 Darin Adler <darin@apple.com>
Remove all the remaining uses of OwnPtr and PassOwnPtr in JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=143941
Reviewed by Gyuyoung Kim.
* API/JSCallbackObject.h: Use unique_ptr for m_callbackObjectData.
* API/JSCallbackObjectFunctions.h: Ditto.
* API/ObjCCallbackFunction.h: Use unique_ptr for the arguments to the
create function and the constructor and for m_impl.
* API/ObjCCallbackFunction.mm:
(CallbackArgumentOfClass::CallbackArgumentOfClass): Streamline this
class by using RetainPtr<Class>.
(ArgumentTypeDelegate::typeInteger): Use make_unique.
(ArgumentTypeDelegate::typeDouble): Ditto.
(ArgumentTypeDelegate::typeBool): Ditto.
(ArgumentTypeDelegate::typeVoid): Ditto.
(ArgumentTypeDelegate::typeId): Ditto.
(ArgumentTypeDelegate::typeOfClass): Ditto.
(ArgumentTypeDelegate::typeBlock): Ditto.
(ArgumentTypeDelegate::typeStruct): Ditto.
(ResultTypeDelegate::typeInteger): Ditto.
(ResultTypeDelegate::typeDouble): Ditto.
(ResultTypeDelegate::typeBool): Ditto.
(ResultTypeDelegate::typeVoid): Ditto.
(ResultTypeDelegate::typeId): Ditto.
(ResultTypeDelegate::typeOfClass): Ditto.
(ResultTypeDelegate::typeBlock): Ditto.
(ResultTypeDelegate::typeStruct): Ditto.
(JSC::ObjCCallbackFunctionImpl::ObjCCallbackFunctionImpl): Use
unique_ptr for the arguments to the constructor, m_arguments, and m_result.
Use RetainPtr<Class> for m_instanceClass.
(JSC::objCCallbackFunctionCallAsConstructor): Use nullptr instead of nil or 0
for non-Objective-C object pointer null.
(JSC::ObjCCallbackFunction::ObjCCallbackFunction): Use unique_ptr for
the arguments to the constructor and for m_impl.
(JSC::ObjCCallbackFunction::create): Use unique_ptr for arguments.
(skipNumber): Mark this static since it's local to this source file.
(objCCallbackFunctionForInvocation): Call parseObjCType without doing any
explicit adoptPtr since the types in the traits are now unique_ptr. Also use
nullptr instead of nil for JSObjectRef values.
(objCCallbackFunctionForMethod): Tweaked comment.
(objCCallbackFunctionForBlock): Use nullptr instead of 0 for JSObjectRef.
* bytecode/CallLinkInfo.h: Removed unneeded include of OwnPtr.h.
* heap/GCThread.cpp:
(JSC::GCThread::GCThread): Use unique_ptr.
* heap/GCThread.h: Use unique_ptr for arguments to the constructor and for
m_slotVisitor and m_copyVisitor.
* heap/GCThreadSharedData.cpp:
(JSC::GCThreadSharedData::GCThreadSharedData): Ditto.
* parser/SourceProvider.h: Removed unneeded include of PassOwnPtr.h.
2015-04-19 Benjamin Poulain <benjamin@webkit.org>
Improve the feature.json files
* features.json:
2015-04-19 Yusuke Suzuki <utatane.tea@gmail.com>
Introduce bytecode intrinsics
https://bugs.webkit.org/show_bug.cgi?id=143926
Reviewed by Filip Pizlo.
This patch introduces bytecode level intrinsics into builtins/*.js JS code.
When implementing functions in builtins/*.js,
sometimes we require lower level functionality.
For example, in the current Array.from, we use `result[k] = value`.
The spec requires `[[DefineOwnProperty]]` operation here.
However, usual `result[k] = value` is evaluated as `[[Set]]`. (`PutValue` => `[[Set]]`)
So if we implement `Array.prototype[k]` getter/setter, the difference is observable.
Ideally, reaching here, we would like to use put_by_val_direct bytecode.
However, there's no syntax to generate it directly.
This patch introduces bytecode level intrinsics into JSC BytecodeCompiler.
Like @call, @apply, we introduce a new node, Intrinsic.
These are generated when calling appropriate private symbols in privileged code.
AST parser detects them and generates Intrinsic nodes and
BytecodeCompiler detects them and generate required bytecodes.
Currently, Array.from implementation works fine without this patch.
This is because when the target code is builtin JS,
BytecodeGenerator emits put_by_val_direct instead of put_by_val.
This solves the above issue. However, instead of solving this issue,
it raises another issue; There's no way to emit `[[Set]]` operation.
`[[Set]]` operation is actually used in the spec (Array.from's "length" is set by `[[Set]]`).
So to implement it precisely, introducing bytecode level intrinsics is necessary.
In the subsequent fixes, we'll remove that special path emitting put_by_val_direct
for `result[k] = value` under builtin JS environment. Instead of that special handling,
use bytecode intrinsics instead. It solves problems and it is more intuitive
because written JS code in builtin works as the same to the usual JS code.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/ArrayConstructor.js:
(from):
* bytecode/BytecodeIntrinsicRegistry.cpp: Added.
(JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
(JSC::BytecodeIntrinsicRegistry::lookup):
* bytecode/BytecodeIntrinsicRegistry.h: Added.
* bytecompiler/NodesCodegen.cpp:
(JSC::BytecodeIntrinsicNode::emitBytecode):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_putByValDirect):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::makeFunctionCallNode):
* parser/NodeConstructors.h:
(JSC::BytecodeIntrinsicNode::BytecodeIntrinsicNode):
* parser/Nodes.h:
(JSC::BytecodeIntrinsicNode::identifier):
* runtime/CommonIdentifiers.cpp:
(JSC::CommonIdentifiers::CommonIdentifiers):
* runtime/CommonIdentifiers.h:
(JSC::CommonIdentifiers::bytecodeIntrinsicRegistry):
* tests/stress/array-from-with-accessors.js: Added.
(shouldBe):
2015-04-19 Yusuke Suzuki <utatane.tea@gmail.com>
Make Builtin functions non constructible
https://bugs.webkit.org/show_bug.cgi?id=143923
Reviewed by Darin Adler.
Builtin functions defined by builtins/*.js accidentally have [[Construct]].
According to the spec, these functions except for explicitly defined as a constructor do not have [[Construct]].
This patch fixes it. When the JS function used for a construction is builtin function, throw not a constructor error.
Ideally, returning ConstructTypeNone in JSFunction::getConstructData is enough.
However, to avoid calling getConstructData (it involves indirect call of function pointer of getConstructData), some places do not check ConstructType.
In these places, they only check the target function is JSFunction because previously JSFunction always has [[Construct]].
So in this patch, we check `isBuiltinFunction()` in those places.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::inliningCost):
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setUpCall):
* runtime/JSFunction.cpp:
(JSC::JSFunction::getConstructData):
* tests/stress/builtin-function-is-construct-type-none.js: Added.
(shouldThrow):
2015-04-19 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement WeakSet
https://bugs.webkit.org/show_bug.cgi?id=142408
Reviewed by Darin Adler.
This patch implements ES6 WeakSet.
Current implementation simply leverages WeakMapData with undefined value.
This WeakMapData should be optimized in the same manner as MapData/SetData in the subsequent patch[1].
And in this patch, we also fix WeakMap/WeakSet behavior to conform the ES6 spec.
Except for adders (WeakMap.prototype.set/WeakSet.prototype.add),
methods return false (or undefined for WeakMap.prototype.get)
when a key is not Object instead of throwing a type error.
[1]: https://bugs.webkit.org/show_bug.cgi?id=143919
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/CommonIdentifiers.h:
* runtime/JSGlobalObject.cpp:
* runtime/JSGlobalObject.h:
* runtime/JSWeakSet.cpp: Added.
(JSC::JSWeakSet::finishCreation):
(JSC::JSWeakSet::visitChildren):
* runtime/JSWeakSet.h: Added.
(JSC::JSWeakSet::createStructure):
(JSC::JSWeakSet::create):
(JSC::JSWeakSet::weakMapData):
(JSC::JSWeakSet::JSWeakSet):
* runtime/WeakMapPrototype.cpp:
(JSC::getWeakMapData):
(JSC::protoFuncWeakMapDelete):
(JSC::protoFuncWeakMapGet):
(JSC::protoFuncWeakMapHas):
* runtime/WeakSetConstructor.cpp: Added.
(JSC::WeakSetConstructor::finishCreation):
(JSC::callWeakSet):
(JSC::constructWeakSet):
(JSC::WeakSetConstructor::getConstructData):
(JSC::WeakSetConstructor::getCallData):
* runtime/WeakSetConstructor.h: Added.
(JSC::WeakSetConstructor::create):
(JSC::WeakSetConstructor::createStructure):
(JSC::WeakSetConstructor::WeakSetConstructor):
* runtime/WeakSetPrototype.cpp: Added.
(JSC::WeakSetPrototype::finishCreation):
(JSC::getWeakMapData):
(JSC::protoFuncWeakSetDelete):
(JSC::protoFuncWeakSetHas):
(JSC::protoFuncWeakSetAdd):
* runtime/WeakSetPrototype.h: Added.
(JSC::WeakSetPrototype::create):
(JSC::WeakSetPrototype::createStructure):
(JSC::WeakSetPrototype::WeakSetPrototype):
* tests/stress/weak-set-constructor-adder.js: Added.
(WeakSet.prototype.add):
* tests/stress/weak-set-constructor.js: Added.
2015-04-17 Alexey Proskuryakov <ap@apple.com>
Remove unused BoundsCheckedPointer
https://bugs.webkit.org/show_bug.cgi?id=143896
Reviewed by Geoffrey Garen.
* bytecode/SpeculatedType.cpp: The header was included here.
2015-04-17 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Fix name enumeration of static functions for Symbol constructor
https://bugs.webkit.org/show_bug.cgi?id=143891
Reviewed by Geoffrey Garen.
Fix missing symbolPrototypeTable registration to the js class object.
This patch fixes name enumeration of static functions (Symbol.key, Symbol.keyFor) for Symbol constructor.
* runtime/SymbolConstructor.cpp:
2015-04-17 Basile Clement <basile_clement@apple.com>
Inline JSFunction allocation in DFG
https://bugs.webkit.org/show_bug.cgi?id=143858
Reviewed by Filip Pizlo.
Followup to my previous patch which inlines JSFunction allocation when
using FTL, now also enabled in DFG.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewFunction):
2015-04-16 Jordan Harband <ljharb@gmail.com>
Number.parseInt is not === global parseInt in nightly r182673
https://bugs.webkit.org/show_bug.cgi?id=143799
Reviewed by Darin Adler.
Ensuring parseInt === Number.parseInt, per spec
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-number.parseint
* runtime/CommonIdentifiers.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::parseIntFunction):
* runtime/NumberConstructor.cpp:
(JSC::NumberConstructor::finishCreation):
2015-04-16 Mark Lam <mark.lam@apple.com>
Gardening: fix CLOOP build after r182927.
Not reviewed.
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::print):
2015-04-16 Basile Clement <basile_clement@apple.com>
Inline JSFunction allocation in FTL
https://bugs.webkit.org/show_bug.cgi?id=143851
Reviewed by Filip Pizlo.
JSFunction allocation is a simple operation that should be inlined when possible.
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNewFunction):
* runtime/JSFunction.h:
(JSC::JSFunction::allocationSize):
2015-04-16 Mark Lam <mark.lam@apple.com>
Add $vm debugging tool.
https://bugs.webkit.org/show_bug.cgi?id=143809
Reviewed by Geoffrey Garen.
For debugging VM bugs, it would be useful to be able to dump VM data structures
from JS code that we instrument. To this end, let's introduce a
JS_enableDollarVM option that, if true, installs an $vm property into each JS
global object at creation time. The $vm property refers to an object that
provides a collection of useful utility functions. For this initial
implementation, $vm will have the following:
crash() - trigger an intentional crash.
dfgTrue() - returns true if the current function is DFG compiled, else returns false.
jitTrue() - returns true if the current function is compiled by the baseline JIT, else returns false.
llintTrue() - returns true if the current function is interpreted by the LLINT, else returns false.
gc() - runs a full GC.
edenGC() - runs an eden GC.
codeBlockForFrame(frameNumber) - gets the codeBlock at the specified frame (0 = current, 1 = caller, etc).
printSourceFor(codeBlock) - prints the source code for the codeBlock.
printByteCodeFor(codeBlock) - prints the bytecode for the codeBlock.
print(str) - prints a string to dataLog output.
printCallFrame() - prints the current CallFrame.
printStack() - prints the JS stack.
printInternal(value) - prints the JSC internal info for the specified value.
With JS_enableDollarVM=true, JS code can use the above functions like so:
$vm.print("Using $vm features\n");
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::printCallOp):
- FTL compiled functions don't like it when we try to compute the CallLinkStatus.
Hence, we skip this step if we're dumping an FTL codeBlock.
* heap/Heap.cpp:
(JSC::Heap::collectAndSweep):
(JSC::Heap::collectAllGarbage): Deleted.
* heap/Heap.h:
(JSC::Heap::collectAllGarbage):
- Add ability to do an Eden collection and sweep.
* interpreter/StackVisitor.cpp:
(JSC::printIndents):
(JSC::log):
(JSC::logF):
(JSC::StackVisitor::Frame::print):
(JSC::jitTypeName): Deleted.
(JSC::printif): Deleted.
- Modernize the implementation of StackVisitor::Frame::print(), and remove some
now redundant code.
- Also fix it so that it downgrades gracefully when encountering inlined DFG
and compiled FTL functions.
(DebugPrintFrameFunctor::DebugPrintFrameFunctor): Deleted.
(DebugPrintFrameFunctor::operator()): Deleted.
(debugPrintCallFrame): Deleted.
(debugPrintStack): Deleted.
- these have been moved into JSDollarVMPrototype.cpp.
* interpreter/StackVisitor.h:
- StackVisitor::Frame::print() is now enabled for release builds as well so that
we can call it from $vm.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
- Added the $vm instance to global objects conditional on the JSC_enableDollarVM
option.
* runtime/Options.h:
- Added the JSC_enableDollarVM option.
* tools/JSDollarVM.cpp: Added.
* tools/JSDollarVM.h: Added.
(JSC::JSDollarVM::createStructure):
(JSC::JSDollarVM::create):
(JSC::JSDollarVM::JSDollarVM):
* tools/JSDollarVMPrototype.cpp: Added.
- This file contains 2 sets of functions:
a. a C++ implementation of debugging utility functions that are callable when
doing debugging from lldb. To the extent possible, these functions try to
be cautious and not cause unintended crashes should the user call them with
the wrong info. Hence, they are designed to be robust rather than speedy.
b. the native implementations of JS functions in the $vm object. Where there
is overlapping functionality, these are built on top of the C++ functions
above to do the work.
Note: it does not make sense for all of the $vm functions to have a C++
counterpart for lldb debugging. For example, the $vm.dfgTrue() function is
only useful for JS code, and works via the DFG intrinsics mechanism.
When doing debugging via lldb, the optimization level of the currently
executing JS function can be gotten by dumping the current CallFrame instead.
(JSC::currentThreadOwnsJSLock):
(JSC::ensureCurrentThreadOwnsJSLock):
(JSC::JSDollarVMPrototype::addFunction):
(JSC::functionCrash): - $vm.crash()
(JSC::functionDFGTrue): - $vm.dfgTrue()
(JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
(JSC::CallerFrameJITTypeFunctor::operator()):
(JSC::CallerFrameJITTypeFunctor::jitType):
(JSC::functionLLintTrue): - $vm.llintTrue()
(JSC::functionJITTrue): - $vm.jitTrue()
(JSC::gc):
(JSC::functionGC): - $vm.gc()
(JSC::edenGC):
(JSC::functionEdenGC): - $vm.edenGC()
(JSC::isValidCodeBlock):
(JSC::codeBlockForFrame):
(JSC::functionCodeBlockForFrame): - $vm.codeBlockForFrame(frameNumber)
(JSC::codeBlockFromArg):
(JSC::functionPrintSourceFor): - $vm.printSourceFor(codeBlock)
(JSC::functionPrintByteCodeFor): - $vm.printBytecodeFor(codeBlock)
(JSC::functionPrint): - $vm.print(str)
(JSC::PrintFrameFunctor::PrintFrameFunctor):
(JSC::PrintFrameFunctor::operator()):
(JSC::printCallFrame):
(JSC::printStack):
(JSC::functionPrintCallFrame): - $vm.printCallFrame()
(JSC::functionPrintStack): - $vm.printStack()
(JSC::printValue):
(JSC::functionPrintValue): - $vm.printValue()
(JSC::JSDollarVMPrototype::finishCreation):
* tools/JSDollarVMPrototype.h: Added.
(JSC::JSDollarVMPrototype::create):
(JSC::JSDollarVMPrototype::createStructure):
(JSC::JSDollarVMPrototype::JSDollarVMPrototype):
2015-04-16 Geoffrey Garen <ggaren@apple.com>
Speculative fix after r182915
https://bugs.webkit.org/show_bug.cgi?id=143404
Reviewed by Alexey Proskuryakov.
* runtime/SymbolConstructor.h:
2015-04-16 Mark Lam <mark.lam@apple.com>
Fixed some typos in a comment.
Not reviewed.
* dfg/DFGGenerationInfo.h:
2015-04-16 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement Symbol.for and Symbol.keyFor
https://bugs.webkit.org/show_bug.cgi?id=143404
Reviewed by Geoffrey Garen.
This patch implements Symbol.for and Symbol.keyFor.
SymbolRegistry maintains registered StringImpl* symbols.
And to make this mapping enabled over realms,
VM owns this mapping (not JSGlobalObject).
While there's Default AtomicStringTable per thread,
SymbolRegistry should not exist over VMs.
So everytime VM is created, SymbolRegistry is also created.
In SymbolRegistry implementation, we don't leverage WeakGCMap (or weak reference design).
Theres are several reasons.
1. StringImpl* which represents identity of Symbols is not GC-managed object.
So we cannot use WeakGCMap directly.
While Symbol* is GC-managed object, holding weak reference to Symbol* doesn't maintain JS symbols (exposed primitive values to users) liveness,
because distinct Symbol* can exist.
Distinct Symbol* means the Symbol* object that pointer value (Symbol*) is different from weakly referenced Symbol* but held StringImpl* is the same.
2. We don't use WTF::WeakPtr. If we add WeakPtrFactory into StringImpl's member, we can track StringImpl*'s liveness by WeakPtr.
However there's problem about when we prune staled entries in SymbolRegistry.
Since the memory allocated for the Symbol is typically occupied by allocated symbolized StringImpl*'s content,
and it is not in GC-heap.
While heavily registering Symbols and storing StringImpl* into SymbolRegistry, Heap's EdenSpace is not so occupied.
So GC typically attempt to perform EdenCollection, and it doesn't call WeakGCMap's pruleStaleEntries callback.
As a result, before pruning staled entries in SymbolRegistry, fast malloc-ed memory fills up the system memory.
So instead of using Weak reference, we take relatively easy design.
When we register symbolized StringImpl* into SymbolRegistry, symbolized StringImpl* is aware of that.
And when destructing it, it removes its reference from SymbolRegistry as if atomic StringImpl do so with AtomicStringTable.
* CMakeLists.txt:
* DerivedSources.make:
* runtime/SymbolConstructor.cpp:
(JSC::SymbolConstructor::getOwnPropertySlot):
(JSC::symbolConstructorFor):
(JSC::symbolConstructorKeyFor):
* runtime/SymbolConstructor.h:
* runtime/VM.cpp:
* runtime/VM.h:
(JSC::VM::symbolRegistry):
* tests/stress/symbol-registry.js: Added.
(test):
2015-04-16 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Use specific functions for @@iterator functions
https://bugs.webkit.org/show_bug.cgi?id=143838
Reviewed by Geoffrey Garen.
In ES6, some methods are defined with the different names.
For example,
Map.prototype[Symbol.iterator] === Map.prototype.entries
Set.prototype[Symbol.iterator] === Set.prototype.values
Array.prototype[Symbol.iterator] === Array.prototype.values
%Arguments%[Symbol.iterator] === Array.prototype.values
However, current implementation creates different function objects per name.
This patch fixes it by setting the object that is used for the other method to @@iterator.
e.g. Setting Array.prototype.values function object to Array.prototype[Symbol.iterator].
And we drop Arguments' iterator implementation and replace Argument[@@iterator] implementation
with Array.prototype.values to conform to the spec.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::subtype):
(Inspector::JSInjectedScriptHost::getInternalProperties):
(Inspector::JSInjectedScriptHost::iteratorEntries):
* runtime/ArgumentsIteratorConstructor.cpp: Removed.
* runtime/ArgumentsIteratorConstructor.h: Removed.
* runtime/ArgumentsIteratorPrototype.cpp: Removed.
* runtime/ArgumentsIteratorPrototype.h: Removed.
* runtime/ArrayPrototype.cpp:
(JSC::ArrayPrototype::finishCreation):
* runtime/ArrayPrototype.h:
* runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::getOwnPropertySlot):
(JSC::ClonedArguments::put):
(JSC::ClonedArguments::deleteProperty):
(JSC::ClonedArguments::defineOwnProperty):
(JSC::ClonedArguments::materializeSpecials):
* runtime/ClonedArguments.h:
* runtime/CommonIdentifiers.h:
* runtime/DirectArguments.cpp:
(JSC::DirectArguments::overrideThings):
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments<Type>::getOwnPropertySlot):
(JSC::GenericArguments<Type>::getOwnPropertyNames):
(JSC::GenericArguments<Type>::put):
(JSC::GenericArguments<Type>::deleteProperty):
(JSC::GenericArguments<Type>::defineOwnProperty):
* runtime/JSArgumentsIterator.cpp: Removed.
* runtime/JSArgumentsIterator.h: Removed.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::arrayProtoValuesFunction):
* runtime/MapPrototype.cpp:
(JSC::MapPrototype::finishCreation):
* runtime/ScopedArguments.cpp:
(JSC::ScopedArguments::overrideThings):
* runtime/SetPrototype.cpp:
(JSC::SetPrototype::finishCreation):
* tests/stress/arguments-iterator.js: Added.
(test):
(testArguments):
* tests/stress/iterator-functions.js: Added.
(test):
(argumentsTests):
2015-04-14 Mark Lam <mark.lam@apple.com>
Add JSC_functionOverrides=<overrides file> debugging tool.
https://bugs.webkit.org/show_bug.cgi?id=143717
Reviewed by Geoffrey Garen.
This tool allows us to do runtime replacement of function bodies with alternatives
for debugging purposes. For example, this is useful when we need to debug VM bugs
which manifest in scripts executing in webpages downloaded from remote servers
that we don't control. The tool allows us to augment those scripts with logging
or test code to help isolate the bugs.
This tool works by substituting the SourceCode at FunctionExecutable creation
time. It identifies which SourceCode to substitute by comparing the source
string against keys in a set of key value pairs.
The keys are function body strings defined by 'override' clauses in the overrides
file specified by in the JSC_functionOverrides option. The values are function
body strings defines by 'with' clauses in the overrides file.
See comment blob at top of FunctionOverrides.cpp on the formatting
of the overrides file.
At FunctionExecutable creation time, if the SourceCode string matches one of the
'override' keys from the overrides file, the tool will replace the SourceCode with
a new one based on the corresponding 'with' value string. The FunctionExecutable
will then be created with the new SourceCode instead.
Some design decisions:
1. We opted to require that the 'with' clause appear on a separate line than the
'override' clause because this makes it easier to read and write when the
'override' clause's function body is single lined and long.
2. The user can use any sequence of characters for the delimiter (except for '{',
'}' and white space characters) because this ensures that there can always be
some delimiter pattern that does not appear in the function body in the clause
e.g. in the body of strings in the JS code.
'{' and '}' are disallowed because they are used to mark the boundaries of the
function body string. White space characters are disallowed because they can
be error prone (the user may not be able to tell between spaces and tabs).
3. The start and end delimiter must be an identical sequence of characters.
I had considered allowing the use of complementary characters like <>, [], and
() for making delimiter pairs like:
[[[[ ... ]]]]
<[([( ... )])]>
But in the end, decided against it because:
a. These sequences of complementary characters can exists in JS code.
In contrast, a repeating delimiter like %%%% is unlikely to appear in JS
code.
b. It can be error prone for the user to have to type the exact complement
character for the end delimiter in reverse order.
In contrast, a repeating delimiter like %%%% is much easier to type and
less error prone. Even a sequence like @#$%^ is less error prone than
a complementary sequence because it can be copy-pasted, and need not be
typed in reverse order.
c. It is easier to parse for the same delimiter string for both start and end.
4. The tool does a lot of checks for syntax errors in the overrides file because
we don't want any overrides to fail silently. If a syntax error is detected,
the tool will print an error message and call exit(). This avoids the user
wasting time doing debugging only to be surprised later that their specified
overrides did not take effect because of some unnoticed typo.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedFunctionExecutable::link):
* runtime/Executable.h:
* runtime/Options.h:
* tools/FunctionOverrides.cpp: Added.
(JSC::FunctionOverrides::overrides):
(JSC::FunctionOverrides::FunctionOverrides):
(JSC::initializeOverrideInfo):
(JSC::FunctionOverrides::initializeOverrideFor):
(JSC::hasDisallowedCharacters):
(JSC::parseClause):
(JSC::FunctionOverrides::parseOverridesInFile):
* tools/FunctionOverrides.h: Added.
2015-04-16 Basile Clement <basile_clement@apple.com>
Extract the allocation profile from JSFunction into a rare object
https://bugs.webkit.org/show_bug.cgi?id=143807
Reviewed by Filip Pizlo.
The allocation profile is only needed for those functions that are used
to create objects with [new].
Extracting it into its own JSCell removes the need for JSFunction and
JSCallee to be JSDestructibleObjects, which should improve performances in most
cases at the cost of an extra pointer dereference when the allocation profile
is actually needed.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGOperations.cpp:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_create_this):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_create_this):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/FunctionRareData.cpp: Added.
(JSC::FunctionRareData::create):
(JSC::FunctionRareData::destroy):
(JSC::FunctionRareData::createStructure):
(JSC::FunctionRareData::visitChildren):
(JSC::FunctionRareData::FunctionRareData):
(JSC::FunctionRareData::~FunctionRareData):
(JSC::FunctionRareData::finishCreation):
* runtime/FunctionRareData.h: Added.
(JSC::FunctionRareData::offsetOfAllocationProfile):
(JSC::FunctionRareData::allocationProfile):
(JSC::FunctionRareData::allocationStructure):
(JSC::FunctionRareData::allocationProfileWatchpointSet):
* runtime/JSBoundFunction.cpp:
(JSC::JSBoundFunction::destroy): Deleted.
* runtime/JSBoundFunction.h:
* runtime/JSCallee.cpp:
(JSC::JSCallee::destroy): Deleted.
* runtime/JSCallee.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::JSFunction):
(JSC::JSFunction::createRareData):
(JSC::JSFunction::visitChildren):
(JSC::JSFunction::put):
(JSC::JSFunction::defineOwnProperty):
(JSC::JSFunction::destroy): Deleted.
(JSC::JSFunction::createAllocationProfile): Deleted.
* runtime/JSFunction.h:
(JSC::JSFunction::offsetOfRareData):
(JSC::JSFunction::rareData):
(JSC::JSFunction::allocationStructure):
(JSC::JSFunction::allocationProfileWatchpointSet):
(JSC::JSFunction::offsetOfAllocationProfile): Deleted.
(JSC::JSFunction::allocationProfile): Deleted.
* runtime/JSFunctionInlines.h:
(JSC::JSFunction::JSFunction):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2015-04-16 Csaba Osztrogonác <ossy@webkit.org>
Remove the unnecessary WTF_CHANGES define
https://bugs.webkit.org/show_bug.cgi?id=143825
Reviewed by Andreas Kling.
* config.h:
2015-04-15 Andreas Kling <akling@apple.com>
Make MarkedBlock and WeakBlock 4x smaller.
<https://webkit.org/b/143802>
Reviewed by Mark Hahnenberg.
To reduce GC heap fragmentation and generally use less memory, reduce the size of MarkedBlock
and its buddy WeakBlock by 4x, bringing them from 64kB+4kB to 16kB+1kB.
In a sampling of cool web sites, I'm seeing ~8% average reduction in overall GC heap size.
Some examples:
apple.com: 6.3MB -> 5.5MB (14.5% smaller)
reddit.com: 4.5MB -> 4.1MB ( 9.7% smaller)
twitter.com: 23.2MB -> 21.4MB ( 8.4% smaller)
cuteoverload.com: 24.5MB -> 23.6MB ( 3.8% smaller)
Benchmarks look mostly neutral.
Some small slowdowns on Octane, some slightly bigger speedups on Kraken and SunSpider.
* heap/MarkedBlock.h:
* heap/WeakBlock.h:
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LowLevelInterpreter.asm:
2015-04-15 Jordan Harband <ljharb@gmail.com>
String.prototype.startsWith/endsWith/includes have wrong length in r182673
https://bugs.webkit.org/show_bug.cgi?id=143659
Reviewed by Benjamin Poulain.
Fix lengths of String.prototype.{includes,startsWith,endsWith} per spec
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.includes
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.startswith
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.endswith
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
2015-04-15 Mark Lam <mark.lam@apple.com>
Remove obsolete VMInspector debugging tool.
https://bugs.webkit.org/show_bug.cgi?id=143798
Reviewed by Michael Saboff.
I added the VMInspector tool 3 years ago to aid in VM hacking work. Some of it
has bit rotted, and now the VM also has better ways to achieve its functionality.
Hence this code is now obsolete and should be removed.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* interpreter/CallFrame.h:
* interpreter/VMInspector.cpp: Removed.
* interpreter/VMInspector.h: Removed.
* llint/LowLevelInterpreter.cpp:
2015-04-15 Jordan Harband <ljharb@gmail.com>
Math.imul has wrong length in Safari 8.0.4
https://bugs.webkit.org/show_bug.cgi?id=143658
Reviewed by Benjamin Poulain.
Correcting function length from 1, to 2, to match spec
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-math.imul
* runtime/MathObject.cpp:
(JSC::MathObject::finishCreation):
2015-04-15 Jordan Harband <ljharb@gmail.com>
Number.parseInt in nightly r182673 has wrong length
https://bugs.webkit.org/show_bug.cgi?id=143657
Reviewed by Benjamin Poulain.
Correcting function length from 1, to 2, to match spec
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-number.parseint
* runtime/NumberConstructor.cpp:
(JSC::NumberConstructor::finishCreation):
2015-04-15 Filip Pizlo <fpizlo@apple.com>
Harden DFGForAllKills
https://bugs.webkit.org/show_bug.cgi?id=143792
Reviewed by Geoffrey Garen.
Unfortunately, we don't have a good way to test this yet - but it will be needed to prevent
bugs in https://bugs.webkit.org/show_bug.cgi?id=143734.
Previously ForAllKills used the bytecode kill analysis. That seemed like a good idea because
that analysis is cheaper than the full liveness analysis. Unfortunately, it's probably wrong:
- It looks for kill sites at forExit origin boundaries. But, something might have been killed
by an operation that was logically in between the forExit origins at the boundary, but was
removed from the DFG for whatever reason. The DFG is allowed to have bytecode instruction
gaps.
- It overlooked the fact that a MovHint that addresses a local that is always live kills that
local. For example, storing to an argument means that the prior value of the argument is
killed.
This fixes the analysis by making it handle MovHints directly, and making it define kills in
the most conservative way possible: it asks if you were live before but dead after. If we
have the compile time budget to afford this more direct approach, then it's definitel a good
idea since it's so fool-proof.
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGForAllKills.h:
(JSC::DFG::forAllKilledOperands):
(JSC::DFG::forAllKilledNodesAtNodeIndex):
(JSC::DFG::forAllDirectlyKilledOperands): Deleted.
2015-04-15 Joseph Pecoraro <pecoraro@apple.com>
Provide SPI to allow changing whether JSContexts are remote debuggable by default
https://bugs.webkit.org/show_bug.cgi?id=143681
Reviewed by Darin Adler.
* API/JSRemoteInspector.h:
* API/JSRemoteInspector.cpp:
(JSRemoteInspectorGetInspectionEnabledByDefault):
(JSRemoteInspectorSetInspectionEnabledByDefault):
Provide SPI to toggle the default enabled inspection state of debuggables.
* API/JSContextRef.cpp:
(JSGlobalContextCreateInGroup):
Respect the default setting.
2015-04-15 Joseph Pecoraro <pecoraro@apple.com>
JavaScriptCore: Use kCFAllocatorDefault where possible
https://bugs.webkit.org/show_bug.cgi?id=143747
Reviewed by Darin Adler.
* heap/HeapTimer.cpp:
(JSC::HeapTimer::HeapTimer):
* inspector/remote/RemoteInspectorDebuggableConnection.mm:
(Inspector::RemoteInspectorInitializeGlobalQueue):
(Inspector::RemoteInspectorDebuggableConnection::setupRunLoop):
For consistency and readability use the constant instead of
different representations of null.
2015-04-14 Michael Saboff <msaboff@apple.com>
Remove JavaScriptCoreUseJIT default from JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=143746
Reviewed by Mark Lam.
* runtime/VM.cpp:
(JSC::enableAssembler):
2015-04-14 Chris Dumez <cdumez@apple.com>
Regression(r180020): Web Inspector crashes on pages that have a stylesheet with an invalid MIME type
https://bugs.webkit.org/show_bug.cgi?id=143745
<rdar://problem/20243916>
Reviewed by Joseph Pecoraro.
Add assertion in ContentSearchUtilities::findMagicComment() to make
sure the content String is not null or we would crash in
JSC::Yarr::interpret() later.
* inspector/ContentSearchUtilities.cpp:
(Inspector::ContentSearchUtilities::findMagicComment):
2015-04-14 Michael Saboff <msaboff@apple.com>
DFG register fillSpeculate*() functions should validate incoming spill format is compatible with requested fill format
https://bugs.webkit.org/show_bug.cgi?id=143727
Reviewed by Geoffrey Garen.
Used the result of AbstractInterpreter<>::filter() to check that the current spill format is compatible
with the requested fill format. If filter() reports a contradiction, then we force an OSR exit.
Removed individual checks made redundant by the new check.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
(JSC::DFG::SpeculativeJIT::fillSpeculateCell):
(JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
(JSC::DFG::SpeculativeJIT::fillSpeculateInt52):
(JSC::DFG::SpeculativeJIT::fillSpeculateCell):
(JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
2015-04-14 Joseph Pecoraro <pecoraro@apple.com>
Replace JavaScriptCoreOutputConsoleMessagesToSystemConsole default with an SPI
https://bugs.webkit.org/show_bug.cgi?id=143691
Reviewed by Geoffrey Garen.
* API/JSRemoteInspector.h:
* API/JSRemoteInspector.cpp:
(JSRemoteInspectorSetLogToSystemConsole):
Add SPI to enable/disable logging to the system console.
This only affects JSContext `console` logs and warnings.
* inspector/JSGlobalObjectConsoleClient.h:
* inspector/JSGlobalObjectConsoleClient.cpp:
(Inspector::JSGlobalObjectConsoleClient::logToSystemConsole):
(Inspector::JSGlobalObjectConsoleClient::setLogToSystemConsole):
(Inspector::JSGlobalObjectConsoleClient::messageWithTypeAndLevel):
(Inspector::JSGlobalObjectConsoleClient::initializeLogToSystemConsole): Deleted.
Simplify access to the setting now that it doesn't need to
initialize its value from preferences.
2015-04-14 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Auto-attach fails after r179562, initialization too late after dispatch
https://bugs.webkit.org/show_bug.cgi?id=143682
Reviewed by Timothy Hatcher.
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::singleton):
If we are on the main thread, run the initialization immediately.
Otherwise dispatch to the main thread. This way if the first JSContext
was created on the main thread it can get auto-attached if applicable.
2015-04-14 Joseph Pecoraro <pecoraro@apple.com>
Unreviewed build fix for Mavericks.
Mavericks includes this file but does not enable ENABLE_REMOTE_INSPECTOR
so the Inspector namespace is not available when compiling this file.
* API/JSRemoteInspector.cpp:
2015-04-14 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Expose private APIs to interact with RemoteInspector instead of going through WebKit
https://bugs.webkit.org/show_bug.cgi?id=143729
Reviewed by Timothy Hatcher.
* API/JSRemoteInspector.h: Added.
* API/JSRemoteInspector.cpp: Added.
(JSRemoteInspectorDisableAutoStart):
(JSRemoteInspectorStart):
(JSRemoteInspectorSetParentProcessInformation):
Add the new SPIs for basic remote inspection behavior.
* JavaScriptCore.xcodeproj/project.pbxproj:
Add the new files to Mac only, since remote inspection is only
enabled there anyways.
2015-04-14 Mark Lam <mark.lam@apple.com>
Rename JSC_dfgFunctionWhitelistFile to JSC_dfgWhitelist.
https://bugs.webkit.org/show_bug.cgi?id=143722
Reviewed by Michael Saboff.
Renaming JSC_dfgFunctionWhitelistFile to JSC_dfgWhitelist so that it is
shorter, and easier to remember (without having to look it up) and to
type. JSC options now support descriptions, and one can always look up
the description if the option's purpose is not already obvious.
* dfg/DFGFunctionWhitelist.cpp:
(JSC::DFG::FunctionWhitelist::ensureGlobalWhitelist):
(JSC::DFG::FunctionWhitelist::contains):
* runtime/Options.h:
2015-04-13 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix Windows build. Windows doesn't take kindly to private classes that use FAST_ALLOCATED.
* runtime/InferredValue.h:
2015-04-13 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix build. I introduced a new cell type at the same time as kling changed how new cell types are written.
* runtime/InferredValue.h:
2015-04-08 Filip Pizlo <fpizlo@apple.com>
JSC should detect singleton functions
https://bugs.webkit.org/show_bug.cgi?id=143232
Reviewed by Geoffrey Garen.
This started out as an attempt to make constructors faster by detecting when a constructor is a
singleton. The idea is that each FunctionExecutable has a VariableWatchpointSet - a watchpoint
along with an inferred value - that detects if only one JSFunction has been allocated for that
executable, and if so, what that JSFunction is. Then, inside the code for the FunctionExecutable,
if the watchpoint set has an inferred value (i.e. it's been initialized and it is still valid),
we can constant-fold GetCallee.
Unfortunately, constructors don't use GetCallee anymore, so that didn't pan out. But in the
process I realized a bunch of things:
- This allows us to completely eliminate the GetCallee/GetScope sequence that we still sometimes
had even in code where our singleton-closure detection worked. That's because singleton-closure
inference worked at the op_resolve_scope, and that op_resolve_scope still needed to keep alive
the incoming scope in case we OSR exit. But by constant-folding GetCallee, that sequence
disappears. OSR exit can rematerialize the callee or the scope by just knowing their constant
values.
- Singleton detection should be a reusable thing. So, I got rid of VariableWatchpointSet and
created InferredValue. InferredValue is a cell, so it can handle its own GC magic.
FunctionExecutable uses an InferredValue to tell you about singleton JSFunctions.
- The old singleton-scope detection in op_resolve_scope is better abstracted as a SymbolTable
detecting a singleton JSSymbolTableObject. So, SymbolTable uses an InferredValue to tell you
about singleton JSSymbolTableObjects. It's curious that we want to have singleton detection in
SymbolTable if we already have it in FunctionExecutable. This comes into play in two ways.
First, it means that the DFG can realize sooner that a resolve_scope resolves to a constant
scope. Ths saves compile times and it allows prediction propagation to benefit from the
constant folding. Second, it means that we will detect a singleton scope even if it is
referenced from a non-singleton scope that is nearer to us in the scope chain. This refactoring
allows us to eliminate the function reentry watchpoint.
- This allows us to use a normal WatchpointSet, instead of a VariableWatchpointSet, for inferring
constant values in scopes. Previously when the DFG inferred that a closure variable was
constant, it wouldn't know which closure that variable was in and so it couldn't just load that
value. But now we are first inferring that the function is a singleton, which means that we
know exactly what scope it points to, and we can load the value from the scope. Using a
WatchpointSet instead of a VariableWatchpointSet saves some memory and simplifies a bunch of
code. This also means that now, the only user of VariableWatchpointSet is FunctionExecutable.
I've tweaked the code of VariableWatchpointSet to reduce its power to just be what
FunctionExecutable wants.
This also has the effect of simplifying the implementation of block scoping. Prior to this
change, block scoping would have needed to have some story for the function reentry watchpoint on
any nested symbol table. That's totally weird to think about; it's not really a function reentry
but a scope reentry. Now we don't have to think about this. Constant inference on nested scopes
will "just work": if we prove that we know the constant value of the scope then the machinery
kicks in, otherwise it doesn't.
This is a small Octane and AsmBench speed-up. AsmBench sees 1% while Octane sees sub-1%.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::finalizeUnconditionally):
(JSC::CodeBlock::valueProfileForBytecodeOffset):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::valueProfileForBytecodeOffset): Deleted.
* bytecode/CodeOrigin.cpp:
(JSC::InlineCallFrame::calleeConstant):
(JSC::InlineCallFrame::visitAggregate):
* bytecode/CodeOrigin.h:
(JSC::InlineCallFrame::calleeConstant): Deleted.
(JSC::InlineCallFrame::visitAggregate): Deleted.
* bytecode/Instruction.h:
* bytecode/VariableWatchpointSet.cpp: Removed.
* bytecode/VariableWatchpointSet.h: Removed.
* bytecode/VariableWatchpointSetInlines.h: Removed.
* bytecode/VariableWriteFireDetail.cpp: Added.
(JSC::VariableWriteFireDetail::dump):
(JSC::VariableWriteFireDetail::touch):
* bytecode/VariableWriteFireDetail.h: Added.
(JSC::VariableWriteFireDetail::VariableWriteFireDetail):
* bytecode/Watchpoint.h:
(JSC::WatchpointSet::stateOnJSThread):
(JSC::WatchpointSet::startWatching):
(JSC::WatchpointSet::fireAll):
(JSC::WatchpointSet::touch):
(JSC::WatchpointSet::invalidate):
(JSC::InlineWatchpointSet::stateOnJSThread):
(JSC::InlineWatchpointSet::state):
(JSC::InlineWatchpointSet::hasBeenInvalidated):
(JSC::InlineWatchpointSet::invalidate):
(JSC::InlineWatchpointSet::touch):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::get):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::getScope): Deleted.
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDesiredWatchpoints.cpp:
(JSC::DFG::InferredValueAdaptor::add):
(JSC::DFG::DesiredWatchpoints::addLazily):
(JSC::DFG::DesiredWatchpoints::reallyAdd):
(JSC::DFG::DesiredWatchpoints::areStillValid):
* dfg/DFGDesiredWatchpoints.h:
(JSC::DFG::InferredValueAdaptor::hasBeenInvalidated):
(JSC::DFG::DesiredWatchpoints::isWatched):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
(JSC::DFG::Graph::tryGetConstantClosureVar):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasWatchpointSet):
(JSC::DFG::Node::watchpointSet):
(JSC::DFG::Node::hasVariableWatchpointSet): Deleted.
(JSC::DFG::Node::variableWatchpointSet): Deleted.
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewFunction):
(JSC::DFG::SpeculativeJIT::compileCreateActivation):
(JSC::DFG::SpeculativeJIT::compileNotifyWrite):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGVarargsForwardingPhase.cpp:
* ftl/FTLIntrinsicRepository.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileCreateActivation):
(JSC::FTL::LowerDFGToLLVM::compileNewFunction):
(JSC::FTL::LowerDFGToLLVM::compileNotifyWrite):
* interpreter/Interpreter.cpp:
(JSC::StackFrame::friendlySourceURL):
(JSC::StackFrame::friendlyFunctionName):
* interpreter/Interpreter.h:
(JSC::StackFrame::friendlySourceURL): Deleted.
(JSC::StackFrame::friendlyFunctionName): Deleted.
* jit/JIT.cpp:
(JSC::JIT::emitNotifyWrite):
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_touch_entry): Deleted.
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitPutGlobalVar):
(JSC::JIT::emitPutClosureVar):
(JSC::JIT::emitNotifyWrite): Deleted.
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emitPutGlobalVar):
(JSC::JIT::emitPutClosureVar):
(JSC::JIT::emitNotifyWrite): Deleted.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL): Deleted.
* runtime/CommonSlowPaths.h:
* runtime/Executable.cpp:
(JSC::FunctionExecutable::finishCreation):
(JSC::FunctionExecutable::visitChildren):
* runtime/Executable.h:
(JSC::FunctionExecutable::singletonFunction):
* runtime/InferredValue.cpp: Added.
(JSC::InferredValue::create):
(JSC::InferredValue::destroy):
(JSC::InferredValue::createStructure):
(JSC::InferredValue::visitChildren):
(JSC::InferredValue::InferredValue):
(JSC::InferredValue::~InferredValue):
(JSC::InferredValue::notifyWriteSlow):
(JSC::InferredValue::ValueCleanup::ValueCleanup):
(JSC::InferredValue::ValueCleanup::~ValueCleanup):
(JSC::InferredValue::ValueCleanup::finalizeUnconditionally):
* runtime/InferredValue.h: Added.
(JSC::InferredValue::inferredValue):
(JSC::InferredValue::state):
(JSC::InferredValue::isStillValid):
(JSC::InferredValue::hasBeenInvalidated):
(JSC::InferredValue::add):
(JSC::InferredValue::notifyWrite):
(JSC::InferredValue::invalidate):
* runtime/JSEnvironmentRecord.cpp:
(JSC::JSEnvironmentRecord::visitChildren):
* runtime/JSEnvironmentRecord.h:
(JSC::JSEnvironmentRecord::isValid):
(JSC::JSEnvironmentRecord::finishCreation):
* runtime/JSFunction.cpp:
(JSC::JSFunction::create):
* runtime/JSFunction.h:
(JSC::JSFunction::createWithInvalidatedReallocationWatchpoint):
(JSC::JSFunction::createImpl):
(JSC::JSFunction::create): Deleted.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::addGlobalVar):
(JSC::JSGlobalObject::addFunction):
* runtime/JSGlobalObject.h:
* runtime/JSLexicalEnvironment.cpp:
(JSC::JSLexicalEnvironment::symbolTablePut):
* runtime/JSScope.h:
(JSC::ResolveOp::ResolveOp):
* runtime/JSSegmentedVariableObject.h:
(JSC::JSSegmentedVariableObject::finishCreation):
* runtime/JSSymbolTableObject.h:
(JSC::JSSymbolTableObject::JSSymbolTableObject):
(JSC::JSSymbolTableObject::setSymbolTable):
(JSC::symbolTablePut):
(JSC::symbolTablePutWithAttributes):
* runtime/PutPropertySlot.h:
* runtime/SymbolTable.cpp:
(JSC::SymbolTableEntry::prepareToWatch):
(JSC::SymbolTable::SymbolTable):
(JSC::SymbolTable::finishCreation):
(JSC::SymbolTable::visitChildren):
(JSC::SymbolTableEntry::inferredValue): Deleted.
(JSC::SymbolTableEntry::notifyWriteSlow): Deleted.
(JSC::SymbolTable::WatchpointCleanup::WatchpointCleanup): Deleted.
(JSC::SymbolTable::WatchpointCleanup::~WatchpointCleanup): Deleted.
(JSC::SymbolTable::WatchpointCleanup::finalizeUnconditionally): Deleted.
* runtime/SymbolTable.h:
(JSC::SymbolTableEntry::disableWatching):
(JSC::SymbolTableEntry::watchpointSet):
(JSC::SymbolTable::singletonScope):
(JSC::SymbolTableEntry::notifyWrite): Deleted.
* runtime/TypeProfiler.cpp:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
* tests/stress/infer-uninitialized-closure-var.js: Added.
(foo.f):
(foo):
* tests/stress/singleton-scope-then-overwrite.js: Added.
(foo.f):
(foo):
* tests/stress/singleton-scope-then-realloc-and-overwrite.js: Added.
(foo):
* tests/stress/singleton-scope-then-realloc.js: Added.
(foo):
2015-04-13 Andreas Kling <akling@apple.com>
Don't segregate heap objects based on Structure immortality.
<https://webkit.org/b/143638>
Reviewed by Darin Adler.
Put all objects that need a destructor call into the same MarkedBlock.
This reduces memory consumption in many situations, while improving locality,
since much more of the MarkedBlock space can be shared.
Instead of branching on the MarkedBlock type, we now check a bit in the
JSCell's inline type flags (StructureIsImmortal) to see whether it's safe
to access the cell's Structure during destruction or not.
Performance benchmarks look mostly neutral. Maybe a small regression on
SunSpider's date objects.
On the amazon.com landing page, this saves us 50 MarkedBlocks (3200kB) along
with a bunch of WeakBlocks that were hanging off of them. That's on the higher
end of savings we can get from this, but still a very real improvement.
Most of this patch is removing the "hasImmortalStructure" constant from JSCell
derived classes and passing that responsibility to the StructureIsImmortal flag.
StructureFlags is made public so that it's accessible from non-member functions.
I made sure to declare it everywhere and make classes final to try to make it
explicit what each class is doing to its inherited flags.
* API/JSCallbackConstructor.h:
* API/JSCallbackObject.h:
* bytecode/UnlinkedCodeBlock.h:
* debugger/DebuggerScope.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileMakeRope):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileMakeRope):
* heap/Heap.h:
(JSC::Heap::subspaceForObjectDestructor):
(JSC::Heap::allocatorForObjectWithDestructor):
(JSC::Heap::subspaceForObjectNormalDestructor): Deleted.
(JSC::Heap::subspaceForObjectsWithImmortalStructure): Deleted.
(JSC::Heap::allocatorForObjectWithNormalDestructor): Deleted.
(JSC::Heap::allocatorForObjectWithImmortalStructureDestructor): Deleted.
* heap/HeapInlines.h:
(JSC::Heap::allocateWithDestructor):
(JSC::Heap::allocateObjectOfType):
(JSC::Heap::subspaceForObjectOfType):
(JSC::Heap::allocatorForObjectOfType):
(JSC::Heap::allocateWithNormalDestructor): Deleted.
(JSC::Heap::allocateWithImmortalStructureDestructor): Deleted.
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::allocateBlock):
* heap/MarkedAllocator.h:
(JSC::MarkedAllocator::needsDestruction):
(JSC::MarkedAllocator::MarkedAllocator):
(JSC::MarkedAllocator::init):
(JSC::MarkedAllocator::destructorType): Deleted.
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::create):
(JSC::MarkedBlock::MarkedBlock):
(JSC::MarkedBlock::callDestructor):
(JSC::MarkedBlock::specializedSweep):
(JSC::MarkedBlock::sweep):
(JSC::MarkedBlock::sweepHelper):
* heap/MarkedBlock.h:
(JSC::MarkedBlock::needsDestruction):
(JSC::MarkedBlock::destructorType): Deleted.
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::MarkedSpace):
(JSC::MarkedSpace::resetAllocators):
(JSC::MarkedSpace::forEachAllocator):
(JSC::MarkedSpace::isPagedOut):
(JSC::MarkedSpace::clearNewlyAllocated):
* heap/MarkedSpace.h:
(JSC::MarkedSpace::subspaceForObjectsWithDestructor):
(JSC::MarkedSpace::destructorAllocatorFor):
(JSC::MarkedSpace::allocateWithDestructor):
(JSC::MarkedSpace::forEachBlock):
(JSC::MarkedSpace::subspaceForObjectsWithNormalDestructor): Deleted.
(JSC::MarkedSpace::subspaceForObjectsWithImmortalStructure): Deleted.
(JSC::MarkedSpace::immortalStructureDestructorAllocatorFor): Deleted.
(JSC::MarkedSpace::normalDestructorAllocatorFor): Deleted.
(JSC::MarkedSpace::allocateWithImmortalStructureDestructor): Deleted.
(JSC::MarkedSpace::allocateWithNormalDestructor): Deleted.
* inspector/JSInjectedScriptHost.h:
* inspector/JSInjectedScriptHostPrototype.h:
* inspector/JSJavaScriptCallFrame.h:
* inspector/JSJavaScriptCallFramePrototype.h:
* jsc.cpp:
* runtime/ArrayBufferNeuteringWatchpoint.h:
* runtime/ArrayConstructor.h:
* runtime/ArrayIteratorPrototype.h:
* runtime/BooleanPrototype.h:
* runtime/ClonedArguments.h:
* runtime/CustomGetterSetter.h:
* runtime/DateConstructor.h:
* runtime/DatePrototype.h:
* runtime/ErrorPrototype.h:
* runtime/ExceptionHelpers.h:
* runtime/Executable.h:
* runtime/GenericArguments.h:
* runtime/GetterSetter.h:
* runtime/InternalFunction.h:
* runtime/JSAPIValueWrapper.h:
* runtime/JSArgumentsIterator.h:
* runtime/JSArray.h:
* runtime/JSArrayBuffer.h:
* runtime/JSArrayBufferView.h:
* runtime/JSBoundFunction.h:
* runtime/JSCallee.h:
* runtime/JSCell.h:
* runtime/JSCellInlines.h:
(JSC::JSCell::classInfo):
* runtime/JSDataViewPrototype.h:
* runtime/JSEnvironmentRecord.h:
* runtime/JSFunction.h:
* runtime/JSGenericTypedArrayView.h:
* runtime/JSGlobalObject.h:
* runtime/JSLexicalEnvironment.h:
* runtime/JSNameScope.h:
* runtime/JSNotAnObject.h:
* runtime/JSONObject.h:
* runtime/JSObject.h:
(JSC::JSFinalObject::JSFinalObject):
* runtime/JSPromiseConstructor.h:
* runtime/JSPromiseDeferred.h:
* runtime/JSPromisePrototype.h:
* runtime/JSPromiseReaction.h:
* runtime/JSPropertyNameEnumerator.h:
* runtime/JSProxy.h:
* runtime/JSScope.h:
* runtime/JSString.h:
* runtime/JSSymbolTableObject.h:
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::structureIsImmortal):
* runtime/MathObject.h:
* runtime/NumberConstructor.h:
* runtime/NumberPrototype.h:
* runtime/ObjectConstructor.h:
* runtime/PropertyMapHashTable.h:
* runtime/RegExp.h:
* runtime/RegExpConstructor.h:
* runtime/RegExpObject.h:
* runtime/RegExpPrototype.h:
* runtime/ScopedArgumentsTable.h:
* runtime/SparseArrayValueMap.h:
* runtime/StrictEvalActivation.h:
* runtime/StringConstructor.h:
* runtime/StringIteratorPrototype.h:
* runtime/StringObject.h:
* runtime/StringPrototype.h:
* runtime/Structure.cpp:
(JSC::Structure::Structure):
* runtime/Structure.h:
* runtime/StructureChain.h:
* runtime/StructureRareData.h:
* runtime/Symbol.h:
* runtime/SymbolPrototype.h:
* runtime/SymbolTable.h:
* runtime/WeakMapData.h:
2015-04-13 Mark Lam <mark.lam@apple.com>
DFG inlining of op_call_varargs should keep the callee alive in case of OSR exit.
https://bugs.webkit.org/show_bug.cgi?id=143407
Reviewed by Filip Pizlo.
DFG inlining of a varargs call / construct needs to keep the local
containing the callee alive with a Phantom node because the LoadVarargs
node may OSR exit. After the OSR exit, the baseline JIT executes the
op_call_varargs with that callee in the local.
Previously, because that callee local was not explicitly kept alive,
the op_call_varargs case can OSR exit a DFG function and leave an
undefined value in that local. As a result, the baseline observes the
side effect of an op_call_varargs on an undefined value instead of the
function it expected.
Note: this issue does not manifest with op_construct_varargs because
the inlined constructor will have an op_create_this which operates on
the incoming callee value, thereby keeping it alive.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleInlining):
* tests/stress/call-varargs-with-different-arguments-length-after-warmup.js: Added.
(foo):
(Foo):
(doTest):
2015-04-12 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement Array.prototype.values
https://bugs.webkit.org/show_bug.cgi?id=143633
Reviewed by Darin Adler.
Symbol.unscopables is implemented, so we can implement Array.prototype.values
without largely breaking the web. The following script passes.
var array = [];
var values = 42;
with (array) {
assert(values, 42);
}
* runtime/ArrayPrototype.cpp:
* tests/stress/array-iterators-next.js:
* tests/stress/map-iterators-next.js:
* tests/stress/set-iterators-next.js:
* tests/stress/values-unscopables.js: Added.
(test):
2015-04-11 Yusuke Suzuki <utatane.tea@gmail.com>
Run flaky conservative GC related test first before polluting stack and registers
https://bugs.webkit.org/show_bug.cgi?id=143634
Reviewed by Ryosuke Niwa.
After r182653, JSC API tests fail. However, it's not related to the change.
After investigating the cause of this failure, I've found that the failed test is flaky
because JSC's GC is conservative. If previously allocated JSGlobalObject is accidentally alive
due to conservative roots in C stack and registers, this test fails.
Since GC marks C stack and registers as roots conservatively,
objects not referenced logically can be accidentally marked and alive.
To avoid this situation as possible as we can,
1. run this test first before stack is polluted,
2. extract this test as a function to suppress stack height.
* API/tests/testapi.mm:
(testWeakValue):
(testObjectiveCAPIMain):
(testObjectiveCAPI):
2015-04-11 Matt Baker <mattbaker@apple.com>
Web Inspector: create content view and details sidebar for Frames timeline
https://bugs.webkit.org/show_bug.cgi?id=143533
Reviewed by Timothy Hatcher.
Refactoring: RunLoop prefix changed to RenderingFrame.
* inspector/protocol/Timeline.json:
2015-04-11 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Enable Symbol in web pages
https://bugs.webkit.org/show_bug.cgi?id=143375
Reviewed by Ryosuke Niwa.
Expose Symbol to web pages.
Symbol was exposed, but it was hidden since it breaks Facebook comments.
This is because at that time Symbol is implemented,
but methods for Symbol.iterator and Object.getOwnPropertySymbols are not implemented yet
and it breaks React.js and immutable.js.
Now methods for Symbol.iterator and Object.getOwnPropertySymbols are implemented
and make sure that Facebook comment input functionality is not broken with exposed Symbol.
So this patch replaces runtime flags SymbolEnabled to SymbolDisabled
and makes enabling symbols by default.
* runtime/ArrayPrototype.cpp:
(JSC::ArrayPrototype::finishCreation):
* runtime/CommonIdentifiers.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructor::finishCreation):
* runtime/RuntimeFlags.h:
2015-04-10 Yusuke Suzuki <utatane.tea@gmail.com>
ES6: Iterator toString names should be consistent
https://bugs.webkit.org/show_bug.cgi?id=142424
Reviewed by Geoffrey Garen.
Iterator Object Names in the spec right now have spaces.
In our implementation some do and some don't.
This patch aligns JSC to the spec.
* runtime/JSArrayIterator.cpp:
* runtime/JSStringIterator.cpp:
* tests/stress/iterator-names.js: Added.
(test):
(iter):
(check):
2015-04-10 Michael Saboff <msaboff@apple.com>
REGRESSION (182567): regress/script-tests/sorting-benchmark.js fails on 32 bit dfg-eager tests
https://bugs.webkit.org/show_bug.cgi?id=143582
Reviewed by Mark Lam.
For 32 bit builds, we favor spilling unboxed values. The ASSERT at the root of this bug doesn't
fire for 64 bit builds, because we spill an "Other" value as a full JS value (DataFormatJS).
For 32 bit builds however, if we are able, we spill Other values as JSCell* (DataFormatCell).
The fix is to add a check in fillSpeculateInt32Internal() before the ASSERT that always OSR exits
if the spillFormat is DataFormatCell. Had we spilled in DataFormatJS and the value was a JSCell*,
we would still OSR exit after the speculation check.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode): Fixed an error in a comment while debugging.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
2015-04-10 Milan Crha <mcrha@redhat.com>
Disable Linux-specific code in a Windows build
https://bugs.webkit.org/show_bug.cgi?id=137973
Reviewed by Joseph Pecoraro.
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace):
2015-04-10 Csaba Osztrogonác <ossy@webkit.org>
[ARM] Fix calleeSaveRegisters() on non iOS platforms after r180516
https://bugs.webkit.org/show_bug.cgi?id=143368
Reviewed by Michael Saboff.
* jit/RegisterSet.cpp:
(JSC::RegisterSet::calleeSaveRegisters):
2015-04-08 Joseph Pecoraro <pecoraro@apple.com>
Use jsNontrivialString in more places if the string is guaranteed to be 2 or more characters
https://bugs.webkit.org/show_bug.cgi?id=143430
Reviewed by Darin Adler.
* runtime/ExceptionHelpers.cpp:
(JSC::errorDescriptionForValue):
* runtime/NumberPrototype.cpp:
(JSC::numberProtoFuncToExponential):
(JSC::numberProtoFuncToPrecision):
(JSC::numberProtoFuncToString):
* runtime/SymbolPrototype.cpp:
(JSC::symbolProtoFuncToString):
2015-04-08 Filip Pizlo <fpizlo@apple.com>
JSArray::sortNumeric should handle ArrayWithUndecided
https://bugs.webkit.org/show_bug.cgi?id=143535
Reviewed by Geoffrey Garen.
ArrayWithUndecided is what you get if you haven't stored anything into the array yet. We need to handle it.
* runtime/JSArray.cpp:
(JSC::JSArray::sortNumeric):
* tests/stress/sort-array-with-undecided.js: Added.
2015-04-08 Filip Pizlo <fpizlo@apple.com>
DFG::IntegerCheckCombiningPhase's wrap-around check shouldn't trigger C++ undef behavior on wrap-around
https://bugs.webkit.org/show_bug.cgi?id=143532
Reviewed by Gavin Barraclough.
Oh the irony! We were protecting an optimization that only worked if there was no wrap-around in JavaScript.
But the C++ code had wrap-around, which is undef in C++. So, if the compiler was smart enough, our compiler
would think that there never was wrap-around.
This fixes a failure in stress/tricky-array-boiunds-checks.js when JSC is compiled with bleeding-edge clang.
* dfg/DFGIntegerCheckCombiningPhase.cpp:
(JSC::DFG::IntegerCheckCombiningPhase::isValid):
2015-04-07 Michael Saboff <msaboff@apple.com>
Lazily initialize LogToSystemConsole flag to reduce memory usage
https://bugs.webkit.org/show_bug.cgi?id=143506
Reviewed by Mark Lam.
Only call into CF preferences code when we need to in order to reduce memory usage.
* inspector/JSGlobalObjectConsoleClient.cpp:
(Inspector::JSGlobalObjectConsoleClient::logToSystemConsole):
(Inspector::JSGlobalObjectConsoleClient::setLogToSystemConsole):
(Inspector::JSGlobalObjectConsoleClient::initializeLogToSystemConsole):
(Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
2015-04-07 Benjamin Poulain <benjamin@webkit.org>
Get the features.json files ready for open contributions
https://bugs.webkit.org/show_bug.cgi?id=143436
Reviewed by Darin Adler.
* features.json:
2015-04-07 Filip Pizlo <fpizlo@apple.com>
Constant folding of typed array properties should be handled by AI rather than strength reduction
https://bugs.webkit.org/show_bug.cgi?id=143496
Reviewed by Geoffrey Garen.
Handling constant folding in AI is better because it precludes us from having to fixpoint the CFA
phase and whatever other phase did the folding in order to find all constants.
This also removes the TypedArrayWatchpoint node type because we can just set the watchpoint
directly.
This also fixes a bug in FTL lowering of GetTypedArrayByteOffset. The bug was previously not
found because all of the tests for it involved the property getting constant folded. I found that
the codegen was bad because an earlier version of the patch broke that constant folding. This
adds a new test for that node type, which makes constant folding impossible by allocating a new
typed array every type. The lesson here is: if you write a test for something, run the test with
full IR dumps to make sure it's actually testing the thing you want it to test.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
(JSC::DFG::Graph::tryGetFoldableView):
(JSC::DFG::Graph::tryGetFoldableViewForChild1): Deleted.
* dfg/DFGGraph.h:
* dfg/DFGNode.h:
(JSC::DFG::Node::hasTypedArray): Deleted.
(JSC::DFG::Node::typedArray): Deleted.
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::jumpForTypedArrayOutOfBounds):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
(JSC::DFG::StrengthReductionPhase::foldTypedArrayPropertyToConstant): Deleted.
(JSC::DFG::StrengthReductionPhase::prepareToFoldTypedArray): Deleted.
* dfg/DFGWatchpointCollectionPhase.cpp:
(JSC::DFG::WatchpointCollectionPhase::handle):
(JSC::DFG::WatchpointCollectionPhase::addLazily):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileGetTypedArrayByteOffset):
(JSC::FTL::LowerDFGToLLVM::typedArrayLength):
* tests/stress/fold-typed-array-properties.js:
(foo):
* tests/stress/typed-array-byte-offset.js: Added.
(foo):
2015-04-07 Matthew Mirman <mmirman@apple.com>
Source and stack information should get appended only to native errors
and should be added directly after construction rather than when thrown.
This fixes frozen objects being unfrozen when thrown while conforming to
ecma script standard and other browser behavior.
rdar://problem/19927293
https://bugs.webkit.org/show_bug.cgi?id=141871
Reviewed by Geoffrey Garen.
Appending stack, source, line, and column information to an object whenever that object is thrown
is incorrect because it violates the ecma script standard for the behavior of throw. Suppose for example
that the object being thrown already has one of these properties or is frozen. Adding the properties
would then violate the frozen contract or overwrite those properties. Other browsers do not do this,
and doing this causes unnecessary performance hits in code with heavy use of the throw construct as
a control flow construct rather than just an error reporting mechanism.
Because WebCore adds "native" errors which do not inherit from any JSC native error,
appending the error properties as a seperate call after construction of the error is required
to avoid having to manually truncate the stack and gather local source information due to
the stack being extended by a nested call to construct one of the native jsc error.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
* interpreter/Interpreter.h:
* parser/ParserError.h:
(JSC::ParserError::toErrorObject):
* runtime/CommonIdentifiers.h:
* runtime/Error.cpp:
(JSC::createError):
(JSC::createEvalError):
(JSC::createRangeError):
(JSC::createReferenceError):
(JSC::createSyntaxError):
(JSC::createTypeError):
(JSC::createNotEnoughArgumentsError):
(JSC::createURIError):
(JSC::createOutOfMemoryError):
(JSC::FindFirstCallerFrameWithCodeblockFunctor::FindFirstCallerFrameWithCodeblockFunctor):
(JSC::FindFirstCallerFrameWithCodeblockFunctor::operator()):
(JSC::FindFirstCallerFrameWithCodeblockFunctor::foundCallFrame):
(JSC::FindFirstCallerFrameWithCodeblockFunctor::index):
(JSC::addErrorInfoAndGetBytecodeOffset): Added.
(JSC::addErrorInfo): Added special case for appending complete error info
to a newly constructed error object.
* runtime/Error.h:
* runtime/ErrorConstructor.cpp:
(JSC::Interpreter::constructWithErrorConstructor):
(JSC::Interpreter::callErrorConstructor):
* runtime/ErrorInstance.cpp:
(JSC::appendSourceToError): Moved from VM.cpp
(JSC::FindFirstCallerFrameWithCodeblockFunctor::FindFirstCallerFrameWithCodeblockFunctor):
(JSC::FindFirstCallerFrameWithCodeblockFunctor::operator()):
(JSC::FindFirstCallerFrameWithCodeblockFunctor::foundCallFrame):
(JSC::FindFirstCallerFrameWithCodeblockFunctor::index):
(JSC::addErrorInfoAndGetBytecodeOffset):
(JSC::ErrorInstance::finishCreation):
* runtime/ErrorInstance.h:
(JSC::ErrorInstance::create):
* runtime/ErrorPrototype.cpp:
(JSC::ErrorPrototype::finishCreation):
* runtime/ExceptionFuzz.cpp:
(JSC::doExceptionFuzzing):
* runtime/ExceptionHelpers.cpp:
(JSC::createError):
(JSC::createInvalidFunctionApplyParameterError):
(JSC::createInvalidInParameterError):
(JSC::createInvalidInstanceofParameterError):
(JSC::createNotAConstructorError):
(JSC::createNotAFunctionError):
(JSC::createNotAnObjectError):
(JSC::throwOutOfMemoryError):
(JSC::createStackOverflowError): Deleted.
(JSC::createOutOfMemoryError): Deleted.
* runtime/ExceptionHelpers.h:
* runtime/JSArrayBufferConstructor.cpp:
(JSC::constructArrayBuffer):
* runtime/JSArrayBufferPrototype.cpp:
(JSC::arrayBufferProtoFuncSlice):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::create):
(JSC::JSGenericTypedArrayView<Adaptor>::createUninitialized):
* runtime/NativeErrorConstructor.cpp:
(JSC::Interpreter::constructWithNativeErrorConstructor):
(JSC::Interpreter::callNativeErrorConstructor):
* runtime/VM.cpp:
(JSC::VM::throwException):
(JSC::appendSourceToError): Moved to Error.cpp
(JSC::FindFirstCallerFrameWithCodeblockFunctor::FindFirstCallerFrameWithCodeblockFunctor): Deleted.
(JSC::FindFirstCallerFrameWithCodeblockFunctor::operator()): Deleted.
(JSC::FindFirstCallerFrameWithCodeblockFunctor::foundCallFrame): Deleted.
(JSC::FindFirstCallerFrameWithCodeblockFunctor::index): Deleted.
* tests/stress/freeze_leek.js: Added.
2015-04-07 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: ES6: Show Symbol properties on Objects
https://bugs.webkit.org/show_bug.cgi?id=141279
Reviewed by Timothy Hatcher.
* inspector/protocol/Runtime.json:
Give PropertyDescriptor a reference to the Symbol RemoteObject
if the property is a symbol property.
* inspector/InjectedScriptSource.js:
Enumerate symbol properties on objects.
2015-04-07 Filip Pizlo <fpizlo@apple.com>
Make it possible to enable LLVM FastISel
https://bugs.webkit.org/show_bug.cgi?id=143489
Reviewed by Michael Saboff.
The decision to enable FastISel is made by Options.h|cpp, but the LLVM library can disable it if it finds that it is built
against a version of LLVM that doesn't support it. Thereafter, JSC::enableLLVMFastISel is the flag that tells the system
if we should enable it.
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* llvm/InitializeLLVM.cpp:
(JSC::initializeLLVMImpl):
* llvm/InitializeLLVM.h:
* llvm/InitializeLLVMLinux.cpp:
(JSC::getLLVMInitializerFunction):
(JSC::initializeLLVMImpl): Deleted.
* llvm/InitializeLLVMMac.cpp:
(JSC::getLLVMInitializerFunction):
(JSC::initializeLLVMImpl): Deleted.
* llvm/InitializeLLVMPOSIX.cpp:
(JSC::getLLVMInitializerFunctionPOSIX):
(JSC::initializeLLVMPOSIX): Deleted.
* llvm/InitializeLLVMPOSIX.h:
* llvm/InitializeLLVMWin.cpp:
(JSC::getLLVMInitializerFunction):
(JSC::initializeLLVMImpl): Deleted.
* llvm/LLVMAPI.cpp:
* llvm/LLVMAPI.h:
* llvm/library/LLVMExports.cpp:
(initCommandLine):
(initializeAndGetJSCLLVMAPI):
* runtime/Options.cpp:
(JSC::Options::initialize):
2015-04-06 Yusuke Suzuki <utatane.tea@gmail.com>
put_by_val_direct need to check the property is index or not for using putDirect / putDirectIndex
https://bugs.webkit.org/show_bug.cgi?id=140426
Reviewed by Darin Adler.
In the put_by_val_direct operation, we use JSObject::putDirect.
However, it only accepts non-index property. For index property, we need to use JSObject::putDirectIndex.
This patch checks toString-ed Identifier is index or not to choose putDirect / putDirectIndex.
* dfg/DFGOperations.cpp:
(JSC::DFG::putByVal):
(JSC::DFG::operationPutByValInternal):
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/Identifier.h:
(JSC::isIndex):
(JSC::parseIndex):
* tests/stress/dfg-put-by-val-direct-with-edge-numbers.js: Added.
(lookupWithKey):
(toStringThrowsError.toString):
2015-04-06 Alberto Garcia <berto@igalia.com>
[GTK] Fix HPPA build
https://bugs.webkit.org/show_bug.cgi?id=143453
Reviewed by Darin Adler.
Add HPPA to the list of supported CPUs.
* CMakeLists.txt:
2015-04-06 Mark Lam <mark.lam@apple.com>
In the 64-bit DFG and FTL, Array::Double case for HasIndexedProperty should set its result to true when all is well.
<https://webkit.org/b/143396>
Reviewed by Filip Pizlo.
The DFG was neglecting to set the result boolean. The FTL was setting it with
an inverted value. Both of these are now resolved.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileHasIndexedProperty):
* tests/stress/for-in-array-mode.js: Added.
(.):
(test):
2015-04-06 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] DFG and FTL should be aware of that StringConstructor behavior for symbols becomes different from ToString
https://bugs.webkit.org/show_bug.cgi?id=143424
Reviewed by Geoffrey Garen.
In ES6, StringConstructor behavior becomes different from ToString abstract operations in the spec. (and JSValue::toString).
ToString(symbol) throws a type error.
However, String(symbol) produces SymbolDescriptiveString(symbol).
So, in DFG and FTL phase, they should not inline StringConstructor to ToString.
Now, in the template literals patch, ToString DFG operation is planned to be used.
And current ToString behavior is aligned to the spec (and JSValue::toString) and it's better.
So intead of changing ToString behavior, this patch adds CallStringConstructor operation into DFG and FTL.
In CallStringConstructor, all behavior in DFG analysis is the same.
Only the difference from ToString is, when calling DFG operation functions, it calls
operationCallStringConstructorOnCell and operationCallStringConstructor instead of
operationToStringOnCell and operationToString.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor):
(JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
(JSC::DFG::FixupPhase::fixupToString): Deleted.
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
(JSC::DFG::SpeculativeJIT::compileToStringOnCell): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStructureRegistrationPhase.cpp:
(JSC::DFG::StructureRegistrationPhase::run):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileToStringOrCallStringConstructor):
(JSC::FTL::LowerDFGToLLVM::compileToString): Deleted.
* runtime/StringConstructor.cpp:
(JSC::stringConstructor):
(JSC::callStringConstructor):
* runtime/StringConstructor.h:
* tests/stress/symbol-and-string-constructor.js: Added.
(performString):
2015-04-06 Yusuke Suzuki <utatane.tea@gmail.com>
Return Optional<uint32_t> from PropertyName::asIndex
https://bugs.webkit.org/show_bug.cgi?id=143422
Reviewed by Darin Adler.
PropertyName::asIndex returns uint32_t and use UINT_MAX as NotAnIndex.
But it's not obvious to callers.
This patch changes
1. PropertyName::asIndex() to return Optional<uint32_t> and
2. function name `asIndex()` to `parseIndex()`.
It forces callers to check the value is index or not explicitly.
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFor):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFor):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitDirectPutById):
* jit/Repatch.cpp:
(JSC::emitPutTransitionStubAndGetOldStructure):
* jsc.cpp:
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncSort):
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments<Type>::getOwnPropertySlot):
(JSC::GenericArguments<Type>::put):
(JSC::GenericArguments<Type>::deleteProperty):
(JSC::GenericArguments<Type>::defineOwnProperty):
* runtime/Identifier.h:
(JSC::parseIndex):
(JSC::Identifier::isSymbol):
* runtime/JSArray.cpp:
(JSC::JSArray::defineOwnProperty):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
(JSC::JSGenericTypedArrayView<Adaptor>::put):
(JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
(JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
* runtime/JSObject.cpp:
(JSC::JSObject::put):
(JSC::JSObject::putDirectAccessor):
(JSC::JSObject::putDirectCustomAccessor):
(JSC::JSObject::deleteProperty):
(JSC::JSObject::putDirectMayBeIndex):
(JSC::JSObject::defineOwnProperty):
* runtime/JSObject.h:
(JSC::JSObject::getOwnPropertySlot):
(JSC::JSObject::getPropertySlot):
(JSC::JSObject::putDirectInternal):
* runtime/JSString.cpp:
(JSC::JSString::getStringPropertyDescriptor):
* runtime/JSString.h:
(JSC::JSString::getStringPropertySlot):
* runtime/LiteralParser.cpp:
(JSC::LiteralParser<CharType>::parse):
* runtime/PropertyName.h:
(JSC::parseIndex):
(JSC::toUInt32FromCharacters): Deleted.
(JSC::toUInt32FromStringImpl): Deleted.
(JSC::PropertyName::asIndex): Deleted.
* runtime/PropertyNameArray.cpp:
(JSC::PropertyNameArray::add):
* runtime/StringObject.cpp:
(JSC::StringObject::deleteProperty):
* runtime/Structure.cpp:
(JSC::Structure::prototypeChainMayInterceptStoreTo):
2015-04-05 Andreas Kling <akling@apple.com>
URI encoding/escaping should use efficient string building instead of calling snprintf().
<https://webkit.org/b/143426>
Reviewed by Gavin Barraclough.
I saw 0.5% of main thread time in snprintf() on <http://polymerlabs.github.io/benchmarks/>
which seemed pretty silly. This change gets that down to nothing in favor of using our
existing JSStringBuilder and HexNumber.h facilities.
These APIs are well-exercised by our existing test suite.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::encode):
(JSC::globalFuncEscape):
2015-04-05 Masataka Yakura <masataka.yakura@gmail.com>
documentation for ES Promises points to the wrong one
https://bugs.webkit.org/show_bug.cgi?id=143263
Reviewed by Darin Adler.
* features.json:
2015-04-05 Simon Fraser <simon.fraser@apple.com>
Remove "go ahead and" from comments
https://bugs.webkit.org/show_bug.cgi?id=143421
Reviewed by Darin Adler, Benjamin Poulain.
Remove the phrase "go ahead and" from comments where it doesn't add
anything (which is almost all of them).
* interpreter/JSStack.cpp:
(JSC::JSStack::growSlowCase):
2015-04-04 Andreas Kling <akling@apple.com>
Logically empty WeakBlocks should not pin down their MarkedBlocks indefinitely.
<https://webkit.org/b/143210>
Reviewed by Geoffrey Garen.
Since a MarkedBlock cannot be destroyed until all the WeakBlocks pointing into it are gone,
we had a little problem where WeakBlocks with only null pointers would still keep their
MarkedBlock alive.
This patch fixes that by detaching WeakBlocks from their MarkedBlock once a sweep discovers
that the WeakBlock contains no pointers to live objects. Ownership of the WeakBlock is passed
to the Heap, which will sweep the list of these detached WeakBlocks as part of a full GC,
destroying them once they're fully dead.
This allows the garbage collector to reclaim the 64kB MarkedBlocks much sooner, and resolves
a mysterious issue where doing two full garbage collections back-to-back would free additional
memory in the second collection.
Management of detached WeakBlocks is implemented as a Vector<WeakBlock*> in Heap, along with
an index of the next block in that vector that needs to be swept. The IncrementalSweeper then
calls into Heap::sweepNextLogicallyEmptyWeakBlock() to sweep one block at a time.
* heap/Heap.h:
* heap/Heap.cpp:
(JSC::Heap::collectAllGarbage): Add a final pass where we sweep the logically empty WeakBlocks
owned by Heap, after everything else has been swept.
(JSC::Heap::notifyIncrementalSweeper): Set up an incremental sweep of logically empty WeakBlocks
after a full garbage collection ends. Note that we don't do this after Eden collections, since
they are unlikely to cause entire WeakBlocks to go empty.
(JSC::Heap::addLogicallyEmptyWeakBlock): Added. Interface for passing ownership of a WeakBlock
to the Heap when it's detached from a WeakSet.
(JSC::Heap::sweepAllLogicallyEmptyWeakBlocks): Helper for collectAllGarbage() that sweeps all
of the logically empty WeakBlocks owned by Heap.
(JSC::Heap::sweepNextLogicallyEmptyWeakBlock): Sweeps one logically empty WeakBlock if needed
and updates the next-logically-empty-weak-block-to-sweep index.
(JSC::Heap::lastChanceToFinalize): call sweepAllLogicallyEmptyWeakBlocks() here, since there
won't be another chance after this.
* heap/IncrementalSweeper.h:
(JSC::IncrementalSweeper::hasWork): Deleted.
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::fullSweep):
(JSC::IncrementalSweeper::doSweep):
(JSC::IncrementalSweeper::sweepNextBlock): Restructured IncrementalSweeper a bit to simplify
adding a new sweeping stage for the Heap's logically empty WeakBlocks. sweepNextBlock() is
changed to return a bool (true if there's more work to be done.)
* heap/WeakBlock.cpp:
(JSC::WeakBlock::sweep): This now figures out if the WeakBlock is logically empty, i.e doesn't
contain any pointers to live objects. The answer is stored in a new SweepResult member.
* heap/WeakBlock.h:
(JSC::WeakBlock::isLogicallyEmptyButNotFree): Added. Can be queried after a sweep to determine
if the WeakBlock could be detached from the MarkedBlock.
(JSC::WeakBlock::SweepResult::SweepResult): Deleted in favor of initializing member variables
when declaring them.
2015-04-04 Yusuke Suzuki <utatane.tea@gmail.com>
Implement ES6 Object.getOwnPropertySymbols
https://bugs.webkit.org/show_bug.cgi?id=141106
Reviewed by Geoffrey Garen.
This patch implements `Object.getOwnPropertySymbols`.
One technical issue is that, since we use private symbols (such as `@Object`) in the
privileged JS code in `builtins/`, they should not be exposed.
To distinguish them from the usual symbols, check the target `StringImpl*` is a not private name
before adding it into PropertyNameArray.
To check the target `StringImpl*` is a private name, we leverage privateToPublic map in `BuiltinNames`
since all private symbols are held in this map.
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createExecutableInternal):
* builtins/BuiltinNames.h:
(JSC::BuiltinNames::isPrivateName):
* runtime/CommonIdentifiers.cpp:
(JSC::CommonIdentifiers::isPrivateName):
* runtime/CommonIdentifiers.h:
* runtime/EnumerationMode.h:
(JSC::EnumerationMode::EnumerationMode):
(JSC::EnumerationMode::includeSymbolProperties):
* runtime/ExceptionHelpers.cpp:
(JSC::createUndefinedVariableError):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSLexicalEnvironment.cpp:
(JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames):
* runtime/JSSymbolTableObject.cpp:
(JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructor::finishCreation):
(JSC::objectConstructorGetOwnPropertySymbols):
(JSC::defineProperties):
(JSC::objectConstructorSeal):
(JSC::objectConstructorFreeze):
(JSC::objectConstructorIsSealed):
(JSC::objectConstructorIsFrozen):
* runtime/ObjectConstructor.h:
(JSC::ObjectConstructor::create):
* runtime/Structure.cpp:
(JSC::Structure::getPropertyNamesFromStructure):
* tests/stress/object-get-own-property-symbols-perform-to-object.js: Added.
(compare):
* tests/stress/object-get-own-property-symbols.js: Added.
(forIn):
* tests/stress/symbol-define-property.js: Added.
(testSymbol):
* tests/stress/symbol-seal-and-freeze.js: Added.
* tests/stress/symbol-with-json.js: Added.
2015-04-03 Mark Lam <mark.lam@apple.com>
Add Options::jitPolicyScale() as a single knob to make all compilations happen sooner.
<https://webkit.org/b/143385>
Reviewed by Geoffrey Garen.
For debugging purposes, sometimes, we want to be able to make compilation happen
sooner to see if we can accelerate the manifestation of certain events / bugs.
Currently, in order to achieve this, we'll have to tweak multiple JIT thresholds
which make up the compilation policy. Let's add a single knob that can tune all
the thresholds up / down in one go proportionately so that we can easily tweak
how soon compilation occurs.
* runtime/Options.cpp:
(JSC::scaleJITPolicy):
(JSC::recomputeDependentOptions):
* runtime/Options.h:
2015-04-03 Geoffrey Garen <ggaren@apple.com>
is* API methods should be @properties
https://bugs.webkit.org/show_bug.cgi?id=143388
Reviewed by Mark Lam.
This appears to be the preferred idiom in WebKit, CA, AppKit, and
Foundation.
* API/JSValue.h: Be @properties.
* API/tests/testapi.mm:
(testObjectiveCAPI): Use the @properties.
2015-04-03 Mark Lam <mark.lam@apple.com>
Some JSC Options refactoring and enhancements.
<https://webkit.org/b/143384>
Rubber stamped by Benjamin Poulain.
Create a better encapsulated Option class to make working with options easier. This
is a building block towards a JIT policy scaling debugging option I will introduce later.
This work entails:
1. Convert Options::Option into a public class Option (who works closely with Options).
2. Convert Options::EntryType into an enum class Options::Type and make it public.
3. Renamed Options::OPT_<option name> to Options::<option name>ID because it reads better.
4. Add misc methods to class Option to make it more useable.
* runtime/Options.cpp:
(JSC::Options::dumpOption):
(JSC::Option::dump):
(JSC::Option::operator==):
(JSC::Options::Option::dump): Deleted.
(JSC::Options::Option::operator==): Deleted.
* runtime/Options.h:
(JSC::Option::Option):
(JSC::Option::operator!=):
(JSC::Option::name):
(JSC::Option::description):
(JSC::Option::type):
(JSC::Option::isOverridden):
(JSC::Option::defaultOption):
(JSC::Option::boolVal):
(JSC::Option::unsignedVal):
(JSC::Option::doubleVal):
(JSC::Option::int32Val):
(JSC::Option::optionRangeVal):
(JSC::Option::optionStringVal):
(JSC::Option::gcLogLevelVal):
(JSC::Options::Option::Option): Deleted.
(JSC::Options::Option::operator!=): Deleted.
2015-04-03 Geoffrey Garen <ggaren@apple.com>
JavaScriptCore API should support type checking for Array and Date
https://bugs.webkit.org/show_bug.cgi?id=143324
Follow-up to address a comment by Dan.
* API/WebKitAvailability.h: __MAC_OS_X_VERSION_MIN_REQUIRED <= 101100
is wrong, since this API is available when __MAC_OS_X_VERSION_MIN_REQUIRED
is equal to 101100.
2015-04-03 Geoffrey Garen <ggaren@apple.com>
JavaScriptCore API should support type checking for Array and Date
https://bugs.webkit.org/show_bug.cgi?id=143324
Follow-up to address a comment by Dan.
* API/WebKitAvailability.h: Do use 10.0 because it was right all along.
Added a comment explaining why.
2015-04-03 Csaba Osztrogonác <ossy@webkit.org>
FTL JIT tests should fail if LLVM library isn't available
https://bugs.webkit.org/show_bug.cgi?id=143374
Reviewed by Mark Lam.
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* runtime/Options.h:
2015-04-03 Zan Dobersek <zdobersek@igalia.com>
Fix the EFL and GTK build after r182243
https://bugs.webkit.org/show_bug.cgi?id=143361
Reviewed by Csaba Osztrogonác.
* CMakeLists.txt: InspectorBackendCommands.js is generated in the
DerivedSources/JavaScriptCore/inspector/ directory.
2015-04-03 Zan Dobersek <zdobersek@igalia.com>
Unreviewed, fixing Clang builds of the GTK port on Linux.
* runtime/Options.cpp:
Include the <math.h> header for isnan().
2015-04-02 Mark Lam <mark.lam@apple.com>
Enhance ability to dump JSC Options.
<https://webkit.org/b/143357>
Reviewed by Benjamin Poulain.
Some enhancements to how the JSC options work:
1. Add a JSC_showOptions option which take values: 0 = None, 1 = Overridden only,
2 = All, 3 = Verbose.
The default is 0 (None). This dumps nothing.
With the Overridden setting, at VM initialization time, we will dump all
option values that have been changed from their default.
With the All setting, at VM initialization time, we will dump all option values.
With the Verbose setting, at VM initialization time, we will dump all option
values along with their descriptions (if available).
2. We now store a copy of the default option values.
We later use this for comparison to tell if an option has been overridden, and
print the default value for reference. As a result, we no longer need the
didOverride flag since we can compute whether the option is overridden at any time.
3. Added description strings to some options to be printed when JSC_showOptions=3 (Verbose).
This will come in handy later when we want to rename some of the options to more sane
names that are easier to remember. For example, we can change
Options::dfgFunctionWhitelistFile() to Options::dfgWhiteList(), and
Options::slowPathAllocsBetweenGCs() to Options::forcedGcRate(). With the availability
of the description, we can afford to use shorter and less descriptive option names,
but they will be easier to remember and use for day to day debugging work.
In this patch, I did not change the names of any of the options yet. I only added
description strings for options that I know about, and where I think the option name
isn't already descriptive enough.
4. Also deleted some unused code.
* jsc.cpp:
(CommandLine::parseArguments):
* runtime/Options.cpp:
(JSC::Options::initialize):
(JSC::Options::setOption):
(JSC::Options::dumpAllOptions):
(JSC::Options::dumpOption):
(JSC::Options::Option::dump):
(JSC::Options::Option::operator==):
* runtime/Options.h:
(JSC::OptionRange::rangeString):
(JSC::Options::Option::Option):
(JSC::Options::Option::operator!=):
2015-04-02 Geoffrey Garen <ggaren@apple.com>
JavaScriptCore API should support type checking for Array and Date
https://bugs.webkit.org/show_bug.cgi?id=143324
Reviewed by Darin Adler, Sam Weinig, Dan Bernstein.
* API/JSValue.h:
* API/JSValue.mm:
(-[JSValue isArray]):
(-[JSValue isDate]): Added an ObjC API.
* API/JSValueRef.cpp:
(JSValueIsArray):
(JSValueIsDate):
* API/JSValueRef.h: Added a C API.
* API/WebKitAvailability.h: Brought our availability macros up to date
and fixed a harmless bug where "10_10" translated to "10.0".
* API/tests/testapi.c:
(main): Added a test and corrected a pre-existing leak.
* API/tests/testapi.mm:
(testObjectiveCAPI): Added a test.
2015-04-02 Mark Lam <mark.lam@apple.com>
Add Options::dumpSourceAtDFGTime().
<https://webkit.org/b/143349>
Reviewed by Oliver Hunt, and Michael Saboff.
Sometimes, we will want to see the JS source code that we're compiling, and it
would be nice to be able to do this without having to jump thru a lot of hoops.
So, let's add a Options::dumpSourceAtDFGTime() option just like we have a
Options::dumpBytecodeAtDFGTime() option.
Also added versions of CodeBlock::dumpSource() and CodeBlock::dumpBytecode()
that explicitly take no arguments (instead of relying on the version that takes
the default argument). These versions are friendlier to use when we want to call
them from an interactive debugging session.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpSource):
(JSC::CodeBlock::dumpBytecode):
* bytecode/CodeBlock.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseCodeBlock):
* runtime/Options.h:
2015-04-02 Yusuke Suzuki <utatane.tea@gmail.com>
Clean up EnumerationMode to easily extend
https://bugs.webkit.org/show_bug.cgi?id=143276
Reviewed by Geoffrey Garen.
To make the followings easily,
1. Adding new flag Include/ExcludeSymbols in the Object.getOwnPropertySymbols patch
2. Make ExcludeSymbols implicitly default for the existing flags
we encapsulate EnumerationMode flags into EnumerationMode class.
And this class manages 2 flags. Later it will be extended to 3.
1. DontEnumPropertiesMode (default is Exclude)
2. JSObjectPropertiesMode (default is Include)
3. SymbolPropertiesMode (default is Exclude)
SymbolPropertiesMode will be added in Object.getOwnPropertySymbols patch.
This patch replaces places using ExcludeDontEnumProperties
to EnumerationMode() value which represents default mode.
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::getOwnNonIndexPropertyNames):
* API/JSObjectRef.cpp:
(JSObjectCopyPropertyNames):
* bindings/ScriptValue.cpp:
(Deprecated::jsToInspectorValue):
* bytecode/ObjectAllocationProfile.h:
(JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncSort):
* runtime/EnumerationMode.h:
(JSC::EnumerationMode::EnumerationMode):
(JSC::EnumerationMode::includeDontEnumProperties):
(JSC::EnumerationMode::includeJSObjectProperties):
(JSC::shouldIncludeDontEnumProperties): Deleted.
(JSC::shouldExcludeDontEnumProperties): Deleted.
(JSC::shouldIncludeJSObjectPropertyNames): Deleted.
(JSC::modeThatSkipsJSObject): Deleted.
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments<Type>::getOwnPropertyNames):
* runtime/JSArray.cpp:
(JSC::JSArray::getOwnNonIndexPropertyNames):
* runtime/JSArrayBuffer.cpp:
(JSC::JSArrayBuffer::getOwnNonIndexPropertyNames):
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::getOwnNonIndexPropertyNames):
* runtime/JSFunction.cpp:
(JSC::JSFunction::getOwnNonIndexPropertyNames):
* runtime/JSFunction.h:
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::getOwnNonIndexPropertyNames):
* runtime/JSLexicalEnvironment.cpp:
(JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames):
* runtime/JSONObject.cpp:
(JSC::Stringifier::Holder::appendNextProperty):
(JSC::Walker::walk):
* runtime/JSObject.cpp:
(JSC::getClassPropertyNames):
(JSC::JSObject::getOwnPropertyNames):
(JSC::JSObject::getOwnNonIndexPropertyNames):
(JSC::JSObject::getGenericPropertyNames):
* runtime/JSPropertyNameEnumerator.h:
(JSC::propertyNameEnumerator):
* runtime/JSSymbolTableObject.cpp:
(JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorGetOwnPropertyNames):
(JSC::objectConstructorKeys):
(JSC::defineProperties):
(JSC::objectConstructorSeal):
(JSC::objectConstructorFreeze):
(JSC::objectConstructorIsSealed):
(JSC::objectConstructorIsFrozen):
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::getOwnNonIndexPropertyNames):
(JSC::RegExpObject::getPropertyNames):
(JSC::RegExpObject::getGenericPropertyNames):
* runtime/StringObject.cpp:
(JSC::StringObject::getOwnPropertyNames):
* runtime/Structure.cpp:
(JSC::Structure::getPropertyNamesFromStructure):
2015-04-01 Alex Christensen <achristensen@webkit.org>
Progress towards CMake on Windows and Mac.
https://bugs.webkit.org/show_bug.cgi?id=143293
Reviewed by Filip Pizlo.
* CMakeLists.txt:
Enabled using assembly on Windows.
Replaced unix commands with CMake commands.
* PlatformMac.cmake:
Tell open source builders where to find unicode headers.
2015-04-01 Yusuke Suzuki <utatane.tea@gmail.com>
IteratorClose should be called when jumping over the target for-of loop
https://bugs.webkit.org/show_bug.cgi?id=143140
Reviewed by Geoffrey Garen.
This patch fixes labeled break/continue behaviors with for-of and iterators.
1. Support IteratorClose beyond multiple loop contexts
Previously, IteratorClose is only executed in for-of's breakTarget().
However, this misses IteratorClose execution when statement roll-ups multiple control flow contexts.
For example,
outer: for (var e1 of outer) {
inner: for (var e2 of inner) {
break outer;
}
}
In this case, return method of inner should be called.
We leverage the existing system for `finally` to execute inner.return method correctly.
Leveraging `finally` system fixes `break`, `continue` and `return` cases.
`throw` case is already supported by emitting try-catch handlers in for-of.
2. Incorrect LabelScope creation is done in ForOfNode
ForOfNode creates duplicated LabelScope.
It causes infinite loop when executing the following program that contains
explicitly labeled for-of loop.
For example,
inner: for (var elm of array) {
continue inner;
}
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::pushFinallyContext):
(JSC::BytecodeGenerator::pushIteratorCloseContext):
(JSC::BytecodeGenerator::popFinallyContext):
(JSC::BytecodeGenerator::popIteratorCloseContext):
(JSC::BytecodeGenerator::emitComplexPopScopes):
(JSC::BytecodeGenerator::emitEnumeration):
(JSC::BytecodeGenerator::emitIteratorClose):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ForOfNode::emitBytecode):
* tests/stress/iterator-return-beyond-multiple-iteration-scopes.js: Added.
(createIterator.iterator.return):
(createIterator):
* tests/stress/raise-error-in-iterator-close.js: Added.
(createIterator.iterator.return):
(createIterator):
2015-04-01 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Implement Symbol.unscopables
https://bugs.webkit.org/show_bug.cgi?id=142829
Reviewed by Geoffrey Garen.
This patch introduces Symbol.unscopables functionality.
In ES6, some generic names (like keys, values) are introduced
as Array's method name. And this breaks the web since some web sites
use like the following code.
var values = ...;
with (array) {
values; // This values is trapped by array's method "values".
}
To fix this, Symbol.unscopables introduces blacklist
for with scope's trapping. When resolving scope,
if name is found in the target scope and the target scope is with scope,
we check Symbol.unscopables object to filter generic names.
This functionality is only active for with scopes.
Global scope does not have unscopables functionality.
And since
1) op_resolve_scope for with scope always return Dynamic resolve type,
2) in that case, JSScope::resolve is always used in JIT and LLInt,
3) the code which contains op_resolve_scope that returns Dynamic cannot be compiled with DFG and FTL,
to implement this functionality, we just change JSScope::resolve and no need to change JIT code.
So performance regression is only visible in Dynamic resolving case, and it is already much slow.
* runtime/ArrayPrototype.cpp:
(JSC::ArrayPrototype::finishCreation):
* runtime/CommonIdentifiers.h:
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::runtimeFlags):
* runtime/JSScope.cpp:
(JSC::isUnscopable):
(JSC::JSScope::resolve):
* runtime/JSScope.h:
(JSC::ScopeChainIterator::scope):
* tests/stress/global-environment-does-not-trap-unscopables.js: Added.
(test):
* tests/stress/unscopables.js: Added.
(test):
(.):
2015-03-31 Ryosuke Niwa <rniwa@webkit.org>
ES6 class syntax should allow static setters and getters
https://bugs.webkit.org/show_bug.cgi?id=143180
Reviewed by Filip Pizlo
Apparently I misread the spec when I initially implemented parseClass.
ES6 class syntax allows static getters and setters so just allow that.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
2015-03-31 Filip Pizlo <fpizlo@apple.com>
PutClosureVar CSE def() rule has a wrong base
https://bugs.webkit.org/show_bug.cgi?id=143280
Reviewed by Michael Saboff.
I think that this code was incorrect in a benign way, since the base of a
PutClosureVar is not a JS-visible object. But it was preventing some optimizations.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
2015-03-31 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r182200.
https://bugs.webkit.org/show_bug.cgi?id=143279
Probably causing assertion extravaganza on bots. (Requested by
kling on #webkit).
Reverted changeset:
"Logically empty WeakBlocks should not pin down their
MarkedBlocks indefinitely."
https://bugs.webkit.org/show_bug.cgi?id=143210
http://trac.webkit.org/changeset/182200
2015-03-31 Yusuke Suzuki <utatane.tea@gmail.com>
Clean up Identifier factories to clarify the meaning of StringImpl*
https://bugs.webkit.org/show_bug.cgi?id=143146
Reviewed by Filip Pizlo.
In the a lot of places, `Identifier(VM*/ExecState*, StringImpl*)` constructor is used.
However, it's ambiguous because `StringImpl*` has 2 different meanings.
1) normal string, it is replacable with `WTFString` and
2) `uid`, which holds `isSymbol` information to represent Symbols.
So we dropped Identifier constructors for strings and instead, introduced 2 factory functions.
+ `Identifier::fromString(VM*/ExecState*, const String&)`.
Just construct Identifier from strings. The symbol-ness of StringImpl* is not kept.
+ `Identifier::fromUid(VM*/ExecState*, StringImpl*)`.
This function is used for 2) `uid`. So symbol-ness of `StringImpl*` is kept.
And to clean up `StringImpl` which is used as uid,
we introduce `StringKind` into `StringImpl`. There's 3 kinds
1. StringNormal (non-atomic, non-symbol)
2. StringAtomic (atomic, non-symbol)
3. StringSymbol (non-atomic, symbol)
They are mutually exclusive. And (atomic, symbol) case should not exist.
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::getOwnNonIndexPropertyNames):
* API/JSObjectRef.cpp:
(JSObjectMakeFunction):
* API/OpaqueJSString.cpp:
(OpaqueJSString::identifier):
* bindings/ScriptFunctionCall.cpp:
(Deprecated::ScriptFunctionCall::call):
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createExecutableInternal):
* builtins/BuiltinNames.h:
(JSC::BuiltinNames::BuiltinNames):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitThrowReferenceError):
(JSC::BytecodeGenerator::emitThrowTypeError):
(JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
(JSC::BytecodeGenerator::emitEnumeration):
* dfg/DFGDesiredIdentifiers.cpp:
(JSC::DFG::DesiredIdentifiers::reallyAdd):
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::functionDetails):
(Inspector::constructInternalProperty):
(Inspector::JSInjectedScriptHost::weakMapEntries):
(Inspector::JSInjectedScriptHost::iteratorEntries):
* inspector/JSInjectedScriptHostPrototype.cpp:
(Inspector::JSInjectedScriptHostPrototype::finishCreation):
* inspector/JSJavaScriptCallFramePrototype.cpp:
* inspector/ScriptCallStackFactory.cpp:
(Inspector::extractSourceInformationFromException):
* jit/JITOperations.cpp:
* jsc.cpp:
(GlobalObject::finishCreation):
(GlobalObject::addFunction):
(GlobalObject::addConstructableFunction):
(functionRun):
(runWithScripts):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LowLevelInterpreter.asm:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::addVar):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::createBindingPattern):
* parser/ParserArena.h:
(JSC::IdentifierArena::makeIdentifier):
(JSC::IdentifierArena::makeIdentifierLCharFromUChar):
(JSC::IdentifierArena::makeNumericIdentifier):
* runtime/ArgumentsIteratorPrototype.cpp:
(JSC::ArgumentsIteratorPrototype::finishCreation):
* runtime/ArrayIteratorPrototype.cpp:
(JSC::ArrayIteratorPrototype::finishCreation):
* runtime/ArrayPrototype.cpp:
(JSC::ArrayPrototype::finishCreation):
(JSC::arrayProtoFuncPush):
* runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::getOwnPropertySlot):
* runtime/CommonIdentifiers.cpp:
(JSC::CommonIdentifiers::CommonIdentifiers):
* runtime/CommonIdentifiers.h:
* runtime/Error.cpp:
(JSC::addErrorInfo):
(JSC::hasErrorInfo):
* runtime/ExceptionHelpers.cpp:
(JSC::createUndefinedVariableError):
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments<Type>::getOwnPropertySlot):
* runtime/Identifier.h:
(JSC::Identifier::isSymbol):
(JSC::Identifier::Identifier):
(JSC::Identifier::from): Deleted.
* runtime/IdentifierInlines.h:
(JSC::Identifier::Identifier):
(JSC::Identifier::fromUid):
(JSC::Identifier::fromString):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::dumpInContextAssumingStructure):
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::toPropertyKey):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSLexicalEnvironment.cpp:
(JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames):
* runtime/JSObject.cpp:
(JSC::getClassPropertyNames):
(JSC::JSObject::reifyStaticFunctionsForDelete):
* runtime/JSObject.h:
(JSC::makeIdentifier):
* runtime/JSPromiseConstructor.cpp:
(JSC::JSPromiseConstructorFuncRace):
(JSC::JSPromiseConstructorFuncAll):
* runtime/JSString.h:
(JSC::JSString::toIdentifier):
* runtime/JSSymbolTableObject.cpp:
(JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
* runtime/LiteralParser.cpp:
(JSC::LiteralParser<CharType>::tryJSONPParse):
(JSC::LiteralParser<CharType>::makeIdentifier):
* runtime/Lookup.h:
(JSC::reifyStaticProperties):
* runtime/MapConstructor.cpp:
(JSC::constructMap):
* runtime/MapIteratorPrototype.cpp:
(JSC::MapIteratorPrototype::finishCreation):
* runtime/MapPrototype.cpp:
(JSC::MapPrototype::finishCreation):
* runtime/MathObject.cpp:
(JSC::MathObject::finishCreation):
* runtime/NumberConstructor.cpp:
(JSC::NumberConstructor::finishCreation):
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructor::finishCreation):
* runtime/PrivateName.h:
(JSC::PrivateName::PrivateName):
* runtime/PropertyMapHashTable.h:
(JSC::PropertyTable::find):
(JSC::PropertyTable::get):
* runtime/PropertyName.h:
(JSC::PropertyName::PropertyName):
(JSC::PropertyName::publicName):
(JSC::PropertyName::asIndex):
* runtime/PropertyNameArray.cpp:
(JSC::PropertyNameArray::add):
* runtime/PropertyNameArray.h:
(JSC::PropertyNameArray::addKnownUnique):
* runtime/RegExpConstructor.cpp:
(JSC::RegExpConstructor::finishCreation):
* runtime/SetConstructor.cpp:
(JSC::constructSet):
* runtime/SetIteratorPrototype.cpp:
(JSC::SetIteratorPrototype::finishCreation):
* runtime/SetPrototype.cpp:
(JSC::SetPrototype::finishCreation):
* runtime/StringIteratorPrototype.cpp:
(JSC::StringIteratorPrototype::finishCreation):
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
* runtime/Structure.cpp:
(JSC::Structure::getPropertyNamesFromStructure):
* runtime/SymbolConstructor.cpp:
* runtime/VM.cpp:
(JSC::VM::throwException):
* runtime/WeakMapConstructor.cpp:
(JSC::constructWeakMap):
2015-03-31 Andreas Kling <akling@apple.com>
Logically empty WeakBlocks should not pin down their MarkedBlocks indefinitely.
<https://webkit.org/b/143210>
Reviewed by Geoffrey Garen.
Since a MarkedBlock cannot be destroyed until all the WeakBlocks pointing into it are gone,
we had a little problem where WeakBlocks with only null pointers would still keep their
MarkedBlock alive.
This patch fixes that by detaching WeakBlocks from their MarkedBlock once a sweep discovers
that the WeakBlock contains no pointers to live objects. Ownership of the WeakBlock is passed
to the Heap, which will sweep the list of these detached WeakBlocks as part of a full GC,
destroying them once they're fully dead.
This allows the garbage collector to reclaim the 64kB MarkedBlocks much sooner, and resolves
a mysterious issue where doing two full garbage collections back-to-back would free additional
memory in the second collection.
Management of detached WeakBlocks is implemented as a Vector<WeakBlock*> in Heap, along with
an index of the next block in that vector that needs to be swept. The IncrementalSweeper then
calls into Heap::sweepNextLogicallyEmptyWeakBlock() to sweep one block at a time.
* heap/Heap.h:
* heap/Heap.cpp:
(JSC::Heap::collectAllGarbage): Add a final pass where we sweep the logically empty WeakBlocks
owned by Heap, after everything else has been swept.
(JSC::Heap::notifyIncrementalSweeper): Set up an incremental sweep of logically empty WeakBlocks
after a full garbage collection ends. Note that we don't do this after Eden collections, since
they are unlikely to cause entire WeakBlocks to go empty.
(JSC::Heap::addLogicallyEmptyWeakBlock): Added. Interface for passing ownership of a WeakBlock
to the Heap when it's detached from a WeakSet.
(JSC::Heap::sweepAllLogicallyEmptyWeakBlocks): Helper for collectAllGarbage() that sweeps all
of the logically empty WeakBlocks owned by Heap.
(JSC::Heap::sweepNextLogicallyEmptyWeakBlock): Sweeps one logically empty WeakBlock if needed
and updates the next-logically-empty-weak-block-to-sweep index.
(JSC::Heap::lastChanceToFinalize): call sweepAllLogicallyEmptyWeakBlocks() here, since there
won't be another chance after this.
* heap/IncrementalSweeper.h:
(JSC::IncrementalSweeper::hasWork): Deleted.
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::fullSweep):
(JSC::IncrementalSweeper::doSweep):
(JSC::IncrementalSweeper::sweepNextBlock): Restructured IncrementalSweeper a bit to simplify
adding a new sweeping stage for the Heap's logically empty WeakBlocks. sweepNextBlock() is
changed to return a bool (true if there's more work to be done.)
* heap/WeakBlock.cpp:
(JSC::WeakBlock::sweep): This now figures out if the WeakBlock is logically empty, i.e doesn't
contain any pointers to live objects. The answer is stored in a new SweepResult member.
* heap/WeakBlock.h:
(JSC::WeakBlock::isLogicallyEmptyButNotFree): Added. Can be queried after a sweep to determine
if the WeakBlock could be detached from the MarkedBlock.
(JSC::WeakBlock::SweepResult::SweepResult): Deleted in favor of initializing member variables
when declaring them.
2015-03-31 Ryosuke Niwa <rniwa@webkit.org>
eval("this.foo") causes a crash if this had not been initialized in a derived class's constructor
https://bugs.webkit.org/show_bug.cgi?id=142883
Reviewed by Filip Pizlo.
The crash was caused by eval inside the constructor of a derived class not checking TDZ.
Fixed the bug by adding a parser flag that forces the TDZ check to be always emitted when accessing "this"
in eval inside a derived class' constructor.
* bytecode/EvalCodeCache.h:
(JSC::EvalCodeCache::getSlow):
* bytecompiler/NodesCodegen.cpp:
(JSC::ThisNode::emitBytecode):
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::evaluate):
* interpreter/Interpreter.cpp:
(JSC::eval):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::thisExpr):
* parser/NodeConstructors.h:
(JSC::ThisNode::ThisNode):
* parser/Nodes.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::Parser):
(JSC::Parser<LexerType>::parsePrimaryExpression):
* parser/Parser.h:
(JSC::parse):
* parser/ParserModes.h:
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::thisExpr):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
* runtime/CodeCache.h:
(JSC::SourceCodeKey::SourceCodeKey):
* runtime/Executable.cpp:
(JSC::EvalExecutable::create):
* runtime/Executable.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createEvalCodeBlock):
* runtime/JSGlobalObject.h:
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncEval):
* tests/stress/class-syntax-no-tdz-in-eval.js: Added.
* tests/stress/class-syntax-tdz-in-eval.js: Added.
2015-03-31 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r182186.
https://bugs.webkit.org/show_bug.cgi?id=143270
it crashes all the WebGL tests on the Debug bots (Requested by
dino on #webkit).
Reverted changeset:
"Web Inspector: add 2D/WebGL canvas instrumentation
infrastructure"
https://bugs.webkit.org/show_bug.cgi?id=137278
http://trac.webkit.org/changeset/182186
2015-03-31 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Object type restrictions on a first parameter of several Object.* functions are relaxed
https://bugs.webkit.org/show_bug.cgi?id=142937
Reviewed by Darin Adler.
In ES6, Object type restrictions on a first parameter of several Object.* functions are relaxed.
In ES5 or prior, when a first parameter is not object type, these functions raise TypeError.
But now, several functions perform ToObject onto a non-object parameter.
And others behaves as if a parameter is a non-extensible ordinary object with no own properties.
It is described in ES6 Annex E.
Functions different from ES5 are following.
1. An attempt is make to coerce the argument using ToObject.
Object.getOwnPropertyDescriptor
Object.getOwnPropertyNames
Object.getPrototypeOf
Object.keys
2. Treated as if it was a non-extensible ordinary object with no own properties.
Object.freeze
Object.isExtensible
Object.isFrozen
Object.isSealed
Object.preventExtensions
Object.seal
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructorGetPrototypeOfFunctor::operator()):
(JSC::objectConstructorGetPrototypeOf):
(JSC::objectConstructorGetOwnPropertyDescriptor):
(JSC::objectConstructorGetOwnPropertyNames):
(JSC::objectConstructorKeys):
(JSC::objectConstructorSeal):
(JSC::objectConstructorFreeze):
(JSC::objectConstructorPreventExtensions):
(JSC::objectConstructorIsSealed):
(JSC::objectConstructorIsFrozen):
(JSC::objectConstructorIsExtensible):
* tests/stress/object-freeze-accept-non-object.js: Added.
* tests/stress/object-get-own-property-descriptor-perform-to-object.js: Added.
(canary):
* tests/stress/object-get-own-property-names-perform-to-object.js: Added.
(compare):
* tests/stress/object-get-prototype-of-perform-to-object.js: Added.
* tests/stress/object-is-extensible-accept-non-object.js: Added.
* tests/stress/object-is-frozen-accept-non-object.js: Added.
* tests/stress/object-is-sealed-accept-non-object.js: Added.
* tests/stress/object-keys-perform-to-object.js: Added.
(compare):
* tests/stress/object-prevent-extensions-accept-non-object.js: Added.
* tests/stress/object-seal-accept-non-object.js: Added.
2015-03-31 Matt Baker <mattbaker@apple.com>
Web Inspector: add 2D/WebGL canvas instrumentation infrastructure
https://bugs.webkit.org/show_bug.cgi?id=137278
Reviewed by Timothy Hatcher.
Added Canvas protocol which defines types used by InspectorCanvasAgent.
* CMakeLists.txt:
* DerivedSources.make:
* inspector/protocol/Canvas.json: Added.
* inspector/scripts/codegen/generator.py:
(Generator.stylized_name_for_enum_value):
Added special handling for 2D (always uppercase) and WebGL (rename mapping) enum strings.
2015-03-30 Ryosuke Niwa <rniwa@webkit.org>
Extending null should set __proto__ to null
https://bugs.webkit.org/show_bug.cgi?id=142882
Reviewed by Geoffrey Garen and Benjamin Poulain.
Set Derived.prototype.__proto__ to null when extending null.
* bytecompiler/NodesCodegen.cpp:
(JSC::ClassExprNode::emitBytecode):
2015-03-30 Mark Lam <mark.lam@apple.com>
REGRESSION (r181993): inspector-protocol/debugger/setBreakpoint-dfg-and-modify-local.html crashes.
<https://webkit.org/b/143105>
Reviewed by Filip Pizlo.
With r181993, the DFG and FTL may elide the storing of the scope register. As a result,
on OSR exits from DFG / FTL frames where this elision has take place, we may get baseline
JIT frames that may have its scope register not set. The Debugger's current implementation
which relies on the scope register is not happy about this. For example, this results in a
crash in the layout test inspector-protocol/debugger/setBreakpoint-dfg-and-modify-local.html.
The fix is to disable inlining when the debugger is in use. Also, we add Flush nodes to
ensure that the scope register value is flushed to the register in the stack frame.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::ByteCodeParser):
(JSC::DFG::ByteCodeParser::setLocal):
(JSC::DFG::ByteCodeParser::flush):
- Add code to flush the scope register.
(JSC::DFG::ByteCodeParser::inliningCost):
- Pretend that all codeBlocks are too expensive to inline if the debugger is in use, thereby
disabling inlining whenever the debugger is in use.
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::Graph):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::hasDebuggerEnabled):
* dfg/DFGStackLayoutPhase.cpp:
(JSC::DFG::StackLayoutPhase::run):
- Update the DFG codeBlock's scopeRegister since it can be moved during stack layout.
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
- Update the FTL codeBlock's scopeRegister since it can be moved during stack layout.
2015-03-30 Michael Saboff <msaboff@apple.com>
Fix flakey float32-repeat-out-of-bounds.js and int8-repeat-out-of-bounds.js tests for ARM64
https://bugs.webkit.org/show_bug.cgi?id=138391
Reviewed by Mark Lam.
Re-enabling these tests as I can't get them to fail on local iOS test devices.
There have been many changes since these tests were disabled.
I'll watch automated test results for failures. If there are failures running automated
testing, it might be due to the device's relative CPU performance.
* tests/stress/float32-repeat-out-of-bounds.js:
* tests/stress/int8-repeat-out-of-bounds.js:
2015-03-30 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Regression: Preview for [[null]] shouldn't be []
https://bugs.webkit.org/show_bug.cgi?id=143208
Reviewed by Mark Lam.
* inspector/InjectedScriptSource.js:
Handle null when generating simple object previews.
2015-03-30 Per Arne Vollan <peavo@outlook.com>
Avoid using hardcoded values for JSValue::Int32Tag, if possible.
https://bugs.webkit.org/show_bug.cgi?id=143134
Reviewed by Geoffrey Garen.
* jit/JSInterfaceJIT.h:
* jit/Repatch.cpp:
(JSC::tryCacheGetByID):
2015-03-30 Filip Pizlo <fpizlo@apple.com>
REGRESSION: js/regress/inline-arguments-local-escape.html is flaky
https://bugs.webkit.org/show_bug.cgi?id=143104
Reviewed by Geoffrey Garen.
Created a test that is a 100% repro of the flaky failure. This test is called
get-my-argument-by-val-for-inlined-escaped-arguments.js. It fails all of the time because it
always causes the compiler to emit a GetMyArgumentByVal of the arguments object returned by
the inlined function. Other than that, it's the same as inline-arguments-local-escape.
Also created three more tests for three similar, but not identical, failures.
Then fixed the bug: PreciseLocalClobberize was assuming that if we read(Stack) then we are
only reading those parts of the stack that are relevant to the current semantic code origin.
That's false after ArgumentsEliminationPhase - we might have operations on phantom arguments,
like GetMyArgumentByVal, ForwardVarargs, CallForwardVarargs, and ConstructForwardVarargs, that
read parts of the stack associated with the inline call frame for the phantom arguments. This
may not be subsumed by the current semantic origin's stack area in cases that the arguments
were allowed to "locally" escape.
The higher-order lesson here is that in DFG SSA IR, the current semantic origin's stack area
is not really a meaningful concept anymore. It is only meaningful for nodes that will read
the stack due to function.arguments, but there are a bunch of other ways that we could also
read the stack and those operations may read any stack slot. I believe that this change makes
PreciseLocalClobberize right: it will refine a read(Stack) from Clobberize correctly by casing
on node type. In future, if we add a read(Stack) to Clobberize, we'll have to make sure that
readTop() in PreciseLocalClobberize does the right thing.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGPreciseLocalClobberize.h:
(JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
* dfg/DFGPutStackSinkingPhase.cpp:
* tests/stress/call-forward-varargs-for-inlined-escaped-arguments.js: Added.
* tests/stress/construct-forward-varargs-for-inlined-escaped-arguments.js: Added.
* tests/stress/forward-varargs-for-inlined-escaped-arguments.js: Added.
* tests/stress/get-my-argument-by-val-for-inlined-escaped-arguments.js: Added.
* tests/stress/real-forward-varargs-for-inlined-escaped-arguments.js: Added.
2015-03-30 Benjamin Poulain <benjamin@webkit.org>
Start the features.json files
https://bugs.webkit.org/show_bug.cgi?id=143207
Reviewed by Darin Adler.
Start the features.json files to have something to experiment
with for the UI.
* features.json: Added.
2015-03-29 Myles C. Maxfield <mmaxfield@apple.com>
[Win] Addresing post-review comment after r182122
https://bugs.webkit.org/show_bug.cgi?id=143189
Unreviewed.
2015-03-29 Myles C. Maxfield <mmaxfield@apple.com>
[Win] Allow building JavaScriptCore without Cygwin
https://bugs.webkit.org/show_bug.cgi?id=143189
Reviewed by Brent Fulgham.
Paths like /usr/bin/ don't exist on Windows.
Hashbangs don't work on Windows. Instead we must explicitly call the executable.
Prefixing commands with environment variables doesn't work on Windows.
Windows doesn't have 'cmp'
Windows uses 'del' instead of 'rm'
Windows uses 'type NUL' intead of 'touch'
* DerivedSources.make:
* JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make:
* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.make:
* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.pl:
* JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.make:
* JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.pl:
* JavaScriptCore.vcxproj/build-generated-files.pl:
* UpdateContents.py: Copied from Source/JavaScriptCore/JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.pl.
2015-03-28 Joseph Pecoraro <pecoraro@apple.com>
Clean up JavaScriptCore/builtins
https://bugs.webkit.org/show_bug.cgi?id=143177
Reviewed by Ryosuke Niwa.
* builtins/ArrayConstructor.js:
(from):
- We can compare to undefined instead of using a typeof undefined check.
- Converge on double quoted strings everywhere.
* builtins/ArrayIterator.prototype.js:
(next):
* builtins/StringIterator.prototype.js:
(next):
- Use shorthand object construction to avoid duplication.
- Improve grammar in error messages.
* tests/stress/array-iterators-next-with-call.js:
* tests/stress/string-iterators.js:
- Update for new error message strings.
2015-03-28 Saam Barati <saambarati1@gmail.com>
Web Inspector: ES6: Better support for Symbol types in Type Profiler
https://bugs.webkit.org/show_bug.cgi?id=141257
Reviewed by Joseph Pecoraro.
ES6 introduces the new primitive type Symbol. This patch makes JSC's
type profiler support this new primitive type.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* inspector/protocol/Runtime.json:
* runtime/RuntimeType.cpp:
(JSC::runtimeTypeForValue):
* runtime/RuntimeType.h:
(JSC::runtimeTypeIsPrimitive):
* runtime/TypeSet.cpp:
(JSC::TypeSet::addTypeInformation):
(JSC::TypeSet::dumpTypes):
(JSC::TypeSet::doesTypeConformTo):
(JSC::TypeSet::displayName):
(JSC::TypeSet::inspectorTypeSet):
(JSC::TypeSet::toJSONString):
* runtime/TypeSet.h:
(JSC::TypeSet::seenTypes):
* tests/typeProfiler/driver/driver.js:
* tests/typeProfiler/symbol.js: Added.
(wrapper.foo):
(wrapper.bar):
(wrapper.bar.bar.baz):
(wrapper):
2015-03-27 Saam Barati <saambarati1@gmail.com>
Deconstruction parameters are bound too late
https://bugs.webkit.org/show_bug.cgi?id=143148
Reviewed by Filip Pizlo.
Currently, a deconstruction pattern named with the same
name as a function will shadow the function. This is
wrong. It should be the other way around.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
2015-03-27 Ryosuke Niwa <rniwa@webkit.org>
parse doesn't initialize the 16-bit version of the JSC parser with defaultConstructorKind
https://bugs.webkit.org/show_bug.cgi?id=143170
Reviewed by Benjamin Poulain.
Assert that we never use 16-bit version of the parser to parse a default constructor
since both base and derived default constructors should be using a 8-bit string.
* parser/Parser.h:
(JSC::parse):
2015-03-27 Ryosuke Niwa <rniwa@webkit.org>
ES6 Classes: Runtime error in JIT'd class calling super() with arguments and superclass has default constructor
https://bugs.webkit.org/show_bug.cgi?id=142862
Reviewed by Benjamin Poulain.
Add a test that used to fail in DFG now that the bug has been fixed by r181993.
* tests/stress/class-syntax-derived-default-constructor.js: Added.
2015-03-27 Michael Saboff <msaboff@apple.com>
load8Signed() and load16Signed() should be renamed to avoid confusion
https://bugs.webkit.org/show_bug.cgi?id=143168
Reviewed by Benjamin Poulain.
Renamed load8Signed() to load8SignedExtendTo32() and load16Signed() to load16SignedExtendTo32().
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::load8SignedExtendTo32):
(JSC::MacroAssemblerARM::load16SignedExtendTo32):
(JSC::MacroAssemblerARM::load8Signed): Deleted.
(JSC::MacroAssemblerARM::load16Signed): Deleted.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::load16SignedExtendTo32):
(JSC::MacroAssemblerARM64::load8SignedExtendTo32):
(JSC::MacroAssemblerARM64::load16Signed): Deleted.
(JSC::MacroAssemblerARM64::load8Signed): Deleted.
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::load16SignedExtendTo32):
(JSC::MacroAssemblerARMv7::load8SignedExtendTo32):
(JSC::MacroAssemblerARMv7::load16Signed): Deleted.
(JSC::MacroAssemblerARMv7::load8Signed): Deleted.
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::load8SignedExtendTo32):
(JSC::MacroAssemblerMIPS::load16SignedExtendTo32):
(JSC::MacroAssemblerMIPS::load8Signed): Deleted.
(JSC::MacroAssemblerMIPS::load16Signed): Deleted.
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::load8SignedExtendTo32):
(JSC::MacroAssemblerSH4::load8):
(JSC::MacroAssemblerSH4::load16SignedExtendTo32):
(JSC::MacroAssemblerSH4::load16):
(JSC::MacroAssemblerSH4::load8Signed): Deleted.
(JSC::MacroAssemblerSH4::load16Signed): Deleted.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::load8SignedExtendTo32):
(JSC::MacroAssemblerX86Common::load16SignedExtendTo32):
(JSC::MacroAssemblerX86Common::load8Signed): Deleted.
(JSC::MacroAssemblerX86Common::load16Signed): Deleted.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitIntTypedArrayGetByVal):
2015-03-27 Michael Saboff <msaboff@apple.com>
Fix flakey dfg-int8array.js and dfg-int16array.js tests for ARM64
https://bugs.webkit.org/show_bug.cgi?id=138390
Reviewed by Mark Lam.
Changed load8Signed() and load16Signed() to only sign extend the loaded value to 32 bits
instead of 64 bits. This is what X86-64 does.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::load16Signed):
(JSC::MacroAssemblerARM64::load8Signed):
2015-03-27 Saam Barati <saambarati1@gmail.com>
Add back previously broken assert from bug 141869
https://bugs.webkit.org/show_bug.cgi?id=143005
Reviewed by Michael Saboff.
* runtime/ExceptionHelpers.cpp:
(JSC::invalidParameterInSourceAppender):
2015-03-26 Geoffrey Garen <ggaren@apple.com>
Make some more objects use FastMalloc
https://bugs.webkit.org/show_bug.cgi?id=143122
Reviewed by Csaba Osztrogonác.
* API/JSCallbackObject.h:
* heap/IncrementalSweeper.h:
* jit/JITThunks.h:
* runtime/JSGlobalObjectDebuggable.h:
* runtime/RegExpCache.h:
2015-03-27 Michael Saboff <msaboff@apple.com>
Objects with numeric properties intermittently get a phantom 'length' property
https://bugs.webkit.org/show_bug.cgi?id=142792
Reviewed by Csaba Osztrogonác.
Fixed a > (greater than) that should be a >> (right shift) in the code that disassembles
test and branch instructions. This function is used for linking tbz/tbnz branches between
two seperately JIT'ed sections of code. Sometime we'd create a bogus tbz instruction in
the failure case checks in the GetById array length stub created for "obj.length" access.
If the failure case code address was at a negative offset from the stub, we'd look for bit 1
being set when we should have been looking for bit 0.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::disassembleTestAndBranchImmediate):
2015-03-27 Yusuke Suzuki <utatane.tea@gmail.com>
Insert exception check around toPropertyKey call
https://bugs.webkit.org/show_bug.cgi?id=142922
Reviewed by Geoffrey Garen.
In some places, exception check is missing after/before toPropertyKey.
However, since it calls toString, it's observable to users,
Missing exception checks in Object.prototype methods can be
observed since it would be overridden with toObject(null/undefined) errors.
We inserted exception checks after toPropertyKey.
Missing exception checks in GetById related code can be
observed since it would be overridden with toObject(null/undefined) errors.
In this case, we need to insert exception checks before/after toPropertyKey
since RequireObjectCoercible followed by toPropertyKey can cause exceptions.
JSValue::get checks null/undefined and raise an exception if |this| is null or undefined.
However, we need to check whether the baseValue is object coercible before executing JSValue::toPropertyKey.
According to the spec, we first perform RequireObjectCoercible and check the exception.
And second, we perform ToPropertyKey and check the exception.
Since JSValue::toPropertyKey can cause toString call, this is observable to users.
For example, if the target is not object coercible,
ToPropertyKey should not be executed, and toString should not be executed by ToPropertyKey.
So the order of observable actions (RequireObjectCoercible and ToPropertyKey) should be correct to the spec.
This patch introduces JSValue::requireObjectCoercible and use it because of the following 2 reasons.
1. Using toObject instead of requireObjectCoercible produces unnecessary wrapper object.
toObject converts primitive types into wrapper objects.
But it is not efficient since wrapper objects are not necessary
if we look up methods from primitive values's prototype. (using synthesizePrototype is better).
2. Using the result of toObject is not correct to the spec.
To align to the spec correctly, we cannot use JSObject::get
by using the wrapper object produced by the toObject suggested in (1).
If we use JSObject that is converted by toObject, getter will be called by using this JSObject as |this|.
It is not correct since getter should be called with the original |this| value that may be primitive types.
So in this patch, we use JSValue::requireObjectCoercible
to check the target is object coercible and raise an error if it's not.
* dfg/DFGOperations.cpp:
* jit/JITOperations.cpp:
(JSC::getByVal):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::getByVal):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::requireObjectCoercible):
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncHasOwnProperty):
(JSC::objectProtoFuncDefineGetter):
(JSC::objectProtoFuncDefineSetter):
(JSC::objectProtoFuncLookupGetter):
(JSC::objectProtoFuncLookupSetter):
(JSC::objectProtoFuncPropertyIsEnumerable):
* tests/stress/exception-in-to-property-key-should-be-handled-early-in-object-methods.js: Added.
(shouldThrow):
(if):
* tests/stress/exception-in-to-property-key-should-be-handled-early.js: Added.
(shouldThrow):
(.):
2015-03-26 Joseph Pecoraro <pecoraro@apple.com>
WebContent Crash when instantiating class with Type Profiling enabled
https://bugs.webkit.org/show_bug.cgi?id=143037
Reviewed by Ryosuke Niwa.
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitMoveEmptyValue):
We cannot profile the type of an uninitialized empty JSValue.
Nor do we expect this to be necessary, since it is effectively
an unseen undefined value. So add a way to put the empty value
without profiling.
(JSC::BytecodeGenerator::emitMove):
Add an assert to try to catch this issue early on, and force
callers to explicitly use emitMoveEmptyValue instead.
* tests/typeProfiler/classes.js: Added.
(wrapper.Base):
(wrapper.Derived):
(wrapper):
Add test coverage both for this case and classes in general.
2015-03-26 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: ES6: Provide a better view for Classes in the console
https://bugs.webkit.org/show_bug.cgi?id=142999
Reviewed by Timothy Hatcher.
* inspector/protocol/Runtime.json:
Provide a new `subtype` enum "class". This is a subtype of `type`
"function", all other subtypes are subtypes of `object` types.
For a class, the frontend will immediately want to get the prototype
to enumerate its methods, so include the `classPrototype`.
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::subtype):
Denote class construction functions as "class" subtypes.
* inspector/InjectedScriptSource.js:
Handling for the new "class" type.
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::isClassConstructorFunction):
* runtime/Executable.h:
(JSC::FunctionExecutable::isClassConstructorFunction):
* runtime/JSFunction.h:
* runtime/JSFunctionInlines.h:
(JSC::JSFunction::isClassConstructorFunction):
Check if this function is a class constructor function. That information
is on the UnlinkedFunctionExecutable, so plumb it through to JSFunction.
2015-03-26 Geoffrey Garen <ggaren@apple.com>
Function.prototype.toString should not decompile the AST
https://bugs.webkit.org/show_bug.cgi?id=142853
Reviewed by Darin Adler.
Following up on Darin's review comments.
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
2015-03-26 Geoffrey Garen <ggaren@apple.com>
"lineNo" does not match WebKit coding style guidelines
https://bugs.webkit.org/show_bug.cgi?id=143119
Reviewed by Michael Saboff.
We can afford to use whole words.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::lineNumberForBytecodeOffset):
(JSC::CodeBlock::expressionRangeForBytecodeOffset):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
* bytecode/UnlinkedCodeBlock.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::WhileNode::emitBytecode):
* debugger/Debugger.cpp:
(JSC::Debugger::toggleBreakpoint):
* interpreter/Interpreter.cpp:
(JSC::StackFrame::computeLineAndColumn):
(JSC::GetStackTraceFunctor::operator()):
(JSC::Interpreter::execute):
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::computeLineAndColumn):
* parser/Nodes.h:
(JSC::Node::firstLine):
(JSC::Node::lineNo): Deleted.
(JSC::StatementNode::firstLine): Deleted.
* parser/ParserError.h:
(JSC::ParserError::toErrorObject):
* profiler/LegacyProfiler.cpp:
(JSC::createCallIdentifierFromFunctionImp):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
* runtime/Executable.cpp:
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ScriptExecutable::firstLine):
(JSC::ScriptExecutable::setOverrideLineNumber):
(JSC::ScriptExecutable::hasOverrideLineNumber):
(JSC::ScriptExecutable::overrideLineNumber):
(JSC::ScriptExecutable::lineNo): Deleted.
(JSC::ScriptExecutable::setOverrideLineNo): Deleted.
(JSC::ScriptExecutable::hasOverrideLineNo): Deleted.
(JSC::ScriptExecutable::overrideLineNo): Deleted.
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionConstructor.h:
* tools/CodeProfile.cpp:
(JSC::CodeProfile::report):
* tools/CodeProfile.h:
(JSC::CodeProfile::CodeProfile):
2015-03-26 Geoffrey Garen <ggaren@apple.com>
Assertion firing in JavaScriptCore/parser/parser.h for statesman.com site
https://bugs.webkit.org/show_bug.cgi?id=142974
Reviewed by Joseph Pecoraro.
This patch does two things:
(1) Restore JavaScriptCore's sanitization of line and column numbers to
one-based values.
We need this because WebCore sometimes provides huge negative column
numbers.
(2) Solve the attribute event listener line numbering problem a different
way: Rather than offseting all line numbers by -1 in an attribute event
listener in order to arrange for a custom result, instead use an explicit
feature for saying "all errors in this code should map to this line number".
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
* bytecode/UnlinkedCodeBlock.h:
* interpreter/Interpreter.cpp:
(JSC::StackFrame::computeLineAndColumn):
(JSC::GetStackTraceFunctor::operator()):
* interpreter/Interpreter.h:
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::computeLineAndColumn):
* parser/ParserError.h:
(JSC::ParserError::toErrorObject): Plumb through an override line number.
When a function has an override line number, all syntax and runtime
errors in the function will map to it. This is useful for attribute event
listeners.
* parser/SourceCode.h:
(JSC::SourceCode::SourceCode): Restore the old sanitization of line and
column numbers to one-based integers. It was kind of a hack to remove this.
* runtime/Executable.cpp:
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ScriptExecutable::setOverrideLineNo):
(JSC::ScriptExecutable::hasOverrideLineNo):
(JSC::ScriptExecutable::overrideLineNo):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionConstructor.h: Plumb through an override line number.
2015-03-26 Filip Pizlo <fpizlo@apple.com>
If we're in code for accessing scoped arguments, we should probably check if the object is a scoped arguments rather than checking if it's a direct arguments.
Reviewed by Michael Saboff.
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitScopedArgumentsGetByVal):
* tests/stress/scoped-then-direct-arguments-get-by-val-in-baseline.js: Added.
2015-03-26 Filip Pizlo <fpizlo@apple.com>
FTL ScopedArguments GetArrayLength generates incorrect code and crashes in LLVM
https://bugs.webkit.org/show_bug.cgi?id=143098
Reviewed by Csaba Osztrogonác.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileGetArrayLength): Fix a typo.
* tests/stress/scoped-arguments-array-length.js: Added. This test previously always crashed in ftl-no-cjit mode.
2015-03-26 Csaba Osztrogonác <ossy@webkit.org>
Unreviewed gardening, skip failing tests on AArch64 Linux.
* tests/mozilla/mozilla-tests.yaml:
* tests/stress/cached-prototype-setter.js:
2015-03-26 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fixes to silly things. While landing fixes to r181993, I introduced crashes. This fixes them.
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants): I landed a fix for a VS warning. It broke this. Now I'm fixing it.
* ftl/FTLCompile.cpp:
(JSC::FTL::compile): Make sure we pass the module when dumping. This makes FTL debugging possible again.
* ftl/FTLState.cpp:
(JSC::FTL::State::dumpState): New overload that takes a module, so that we can call this after FTL::compile() clears State's module.
* ftl/FTLState.h:
2015-03-25 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix obvious goof that was causing 32-bit debug crashes. The 64-bit version did it
right, so this just makes 32-bit do the same.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
2015-03-25 Filip Pizlo <fpizlo@apple.com>
Fix a typo that ggaren found but that I didn't fix before.
* runtime/DirectArgumentsOffset.h:
2015-03-25 Filip Pizlo <fpizlo@apple.com>
Unreviewed, VC found a bug. This fixes the bug.
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
2015-03-25 Filip Pizlo <fpizlo@apple.com>
Unreviewed, try to fix Windows build.
* runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::createWithInlineFrame):
2015-03-25 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix debug build.
* bytecompiler/NodesCodegen.cpp:
(JSC::ConstDeclNode::emitCodeSingle):
2015-03-25 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix CLOOP build.
* dfg/DFGMinifiedID.h:
2015-03-25 Filip Pizlo <fpizlo@apple.com>
Heap variables shouldn't end up in the stack frame
https://bugs.webkit.org/show_bug.cgi?id=141174
Reviewed by Geoffrey Garen.
This is a major change to how JavaScriptCore handles declared variables (i.e. "var"). It removes
any ambiguity about whether a variable should be in the heap or on the stack. A variable will no
longer move between heap and stack during its lifetime. This enables a bunch of optimizations and
simplifications:
- Accesses to variables no longer need checks or indirections to determine where the variable is
at that moment in time. For example, loading a closure variable now takes just one load instead
of two. Loading an argument by index now takes a bounds check and a load in the fastest case
(when no arguments object allocation is required) while previously that same operation required
a "did I allocate arguments yet" check, a bounds check, and then the load.
- Reasoning about the allocation of an activation or arguments object now follows the same simple
logic as the allocation of any other kind of object. Previously, those objects were lazily
allocated - so an allocation instruction wasn't the actual allocation site, since it might not
allocate anything at all. This made the implementation of traditional escape analyses really
awkward, and ultimately it meant that we missed important cases. Now, we can reason about the
arguments object using the usual SSA tricks which allows for more comprehensive removal.
- The allocations of arguments objects, functions, and activations are now much faster. While
this patch generally expands our ability to eliminate arguments object allocations, an earlier
version of the patch - which lacked that functionality - was a progression on some arguments-
and closure-happy benchmarks because although no allocations were eliminated, all allocations
were faster.
- There is no tear-off. The runtime no loner needs to know about where on the stack a frame keeps
its arguments objects or activations. The runtime doesn't have to do things to the arguments
objects and activations that a frame allocated, when the frame is unwound. We always had horrid
bugs in that code, so it's good to see it go. This removes *a ton* of machinery from the DFG,
FTL, CodeBlock, and other places. All of the things having to do with "captured variables" is
now gone. This also enables implementing block-scoping. Without this change, block-scope
support would require telling CodeBlock and all of the rest of the runtime about all of the
variables that store currently-live scopes. That would have been so disastrously hard that it
might as well be impossible. With this change, it's fair game for the bytecode generator to
simply allocate whatever activations it wants, wherever it wants, and to keep them live for
however long it wants. This all works, because after bytecode generation, an activation is just
an object and variables that refer to it are just normal variables.
- SymbolTable can now tell you explicitly where a variable lives. The answer is in the form of a
VarOffset object, which has methods like isStack(), isScope(), etc. VirtualRegister is never
used for offsets of non-stack variables anymore. We now have shiny new objects for other kinds
of offsets - ScopeOffset for offsets into scopes, and DirectArgumentsOffset for offsets into
an arguments object.
- Functions that create activations can now tier-up into the FTL. Previously they couldn't. Also,
using activations used to prevent inlining; now functions that use activations can be inlined
just fine.
This is a >1% speed-up on Octane. This is a >2% speed-up on CompressionBench. This is a tiny
speed-up on AsmBench (~0.4% or something). This looks like it might be a speed-up on SunSpider.
It's only a slow-down on very short-running microbenchmarks we had previously written for our old
style of tear-off-based arguments optimization. Those benchmarks are not part of any major suite.
The easiest way of understanding this change is to start by looking at the changes in runtime/,
and then the changes in bytecompiler/, and then sort of work your way up the compiler tiers.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/AbortReason.h:
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::BaseIndex::withOffset):
* bytecode/ByValInfo.h:
(JSC::hasOptimizableIndexingForJSType):
(JSC::hasOptimizableIndexing):
(JSC::jitArrayModeForJSType):
(JSC::jitArrayModePermitsPut):
(JSC::jitArrayModeForStructure):
* bytecode/BytecodeKills.h: Added.
(JSC::BytecodeKills::BytecodeKills):
(JSC::BytecodeKills::operandIsKilled):
(JSC::BytecodeKills::forEachOperandKilledAt):
(JSC::BytecodeKills::KillSet::KillSet):
(JSC::BytecodeKills::KillSet::add):
(JSC::BytecodeKills::KillSet::forEachLocal):
(JSC::BytecodeKills::KillSet::contains):
* bytecode/BytecodeList.json:
* bytecode/BytecodeLivenessAnalysis.cpp:
(JSC::isValidRegisterForLiveness):
(JSC::stepOverInstruction):
(JSC::BytecodeLivenessAnalysis::runLivenessFixpoint):
(JSC::BytecodeLivenessAnalysis::getLivenessInfoAtBytecodeOffset):
(JSC::BytecodeLivenessAnalysis::operandIsLiveAtBytecodeOffset):
(JSC::BytecodeLivenessAnalysis::computeFullLiveness):
(JSC::BytecodeLivenessAnalysis::computeKills):
(JSC::indexForOperand): Deleted.
(JSC::BytecodeLivenessAnalysis::getLivenessInfoForNonCapturedVarsAtBytecodeOffset): Deleted.
(JSC::getLivenessInfo): Deleted.
* bytecode/BytecodeLivenessAnalysis.h:
* bytecode/BytecodeLivenessAnalysisInlines.h:
(JSC::operandIsAlwaysLive):
(JSC::operandThatIsNotAlwaysLiveIsLive):
(JSC::operandIsLive):
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::nameForRegister):
(JSC::CodeBlock::validate):
(JSC::CodeBlock::isCaptured): Deleted.
(JSC::CodeBlock::framePointerOffsetToGetActivationRegisters): Deleted.
(JSC::CodeBlock::machineSlowArguments): Deleted.
* bytecode/CodeBlock.h:
(JSC::unmodifiedArgumentsRegister): Deleted.
(JSC::CodeBlock::setArgumentsRegister): Deleted.
(JSC::CodeBlock::argumentsRegister): Deleted.
(JSC::CodeBlock::uncheckedArgumentsRegister): Deleted.
(JSC::CodeBlock::usesArguments): Deleted.
(JSC::CodeBlock::captureCount): Deleted.
(JSC::CodeBlock::captureStart): Deleted.
(JSC::CodeBlock::captureEnd): Deleted.
(JSC::CodeBlock::argumentIndexAfterCapture): Deleted.
(JSC::CodeBlock::hasSlowArguments): Deleted.
(JSC::ExecState::argumentAfterCapture): Deleted.
* bytecode/CodeOrigin.h:
* bytecode/DataFormat.h:
(JSC::dataFormatToString):
* bytecode/FullBytecodeLiveness.h:
(JSC::FullBytecodeLiveness::getLiveness):
(JSC::FullBytecodeLiveness::operandIsLive):
(JSC::FullBytecodeLiveness::FullBytecodeLiveness): Deleted.
(JSC::FullBytecodeLiveness::getOut): Deleted.
* bytecode/Instruction.h:
(JSC::Instruction::Instruction):
* bytecode/Operands.h:
(JSC::Operands::virtualRegisterForIndex):
* bytecode/SpeculatedType.cpp:
(JSC::dumpSpeculation):
(JSC::speculationToAbbreviatedString):
(JSC::speculationFromClassInfo):
* bytecode/SpeculatedType.h:
(JSC::isDirectArgumentsSpeculation):
(JSC::isScopedArgumentsSpeculation):
(JSC::isActionableMutableArraySpeculation):
(JSC::isActionableArraySpeculation):
(JSC::isArgumentsSpeculation): Deleted.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::setArgumentsRegister): Deleted.
(JSC::UnlinkedCodeBlock::usesArguments): Deleted.
(JSC::UnlinkedCodeBlock::argumentsRegister): Deleted.
* bytecode/ValueRecovery.cpp:
(JSC::ValueRecovery::dumpInContext):
* bytecode/ValueRecovery.h:
(JSC::ValueRecovery::directArgumentsThatWereNotCreated):
(JSC::ValueRecovery::outOfBandArgumentsThatWereNotCreated):
(JSC::ValueRecovery::nodeID):
(JSC::ValueRecovery::argumentsThatWereNotCreated): Deleted.
* bytecode/VirtualRegister.h:
(JSC::VirtualRegister::operator==):
(JSC::VirtualRegister::operator!=):
(JSC::VirtualRegister::operator<):
(JSC::VirtualRegister::operator>):
(JSC::VirtualRegister::operator<=):
(JSC::VirtualRegister::operator>=):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeNextParameter):
(JSC::BytecodeGenerator::visibleNameForParameter):
(JSC::BytecodeGenerator::emitMove):
(JSC::BytecodeGenerator::variable):
(JSC::BytecodeGenerator::createVariable):
(JSC::BytecodeGenerator::emitResolveScope):
(JSC::BytecodeGenerator::emitGetFromScope):
(JSC::BytecodeGenerator::emitPutToScope):
(JSC::BytecodeGenerator::initializeVariable):
(JSC::BytecodeGenerator::emitInstanceOf):
(JSC::BytecodeGenerator::emitNewFunction):
(JSC::BytecodeGenerator::emitNewFunctionInternal):
(JSC::BytecodeGenerator::emitCall):
(JSC::BytecodeGenerator::emitReturn):
(JSC::BytecodeGenerator::emitConstruct):
(JSC::BytecodeGenerator::isArgumentNumber):
(JSC::BytecodeGenerator::emitEnumeration):
(JSC::BytecodeGenerator::addVar): Deleted.
(JSC::BytecodeGenerator::emitInitLazyRegister): Deleted.
(JSC::BytecodeGenerator::initializeCapturedVariable): Deleted.
(JSC::BytecodeGenerator::resolveCallee): Deleted.
(JSC::BytecodeGenerator::addCallee): Deleted.
(JSC::BytecodeGenerator::addParameter): Deleted.
(JSC::BytecodeGenerator::willResolveToArgumentsRegister): Deleted.
(JSC::BytecodeGenerator::uncheckedLocalArgumentsRegister): Deleted.
(JSC::BytecodeGenerator::createLazyRegisterIfNecessary): Deleted.
(JSC::BytecodeGenerator::isCaptured): Deleted.
(JSC::BytecodeGenerator::local): Deleted.
(JSC::BytecodeGenerator::constLocal): Deleted.
(JSC::BytecodeGenerator::emitResolveConstantLocal): Deleted.
(JSC::BytecodeGenerator::emitGetArgumentsLength): Deleted.
(JSC::BytecodeGenerator::emitGetArgumentByVal): Deleted.
(JSC::BytecodeGenerator::emitLazyNewFunction): Deleted.
(JSC::BytecodeGenerator::createArgumentsIfNecessary): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::Variable::Variable):
(JSC::Variable::isResolved):
(JSC::Variable::ident):
(JSC::Variable::offset):
(JSC::Variable::isLocal):
(JSC::Variable::local):
(JSC::Variable::isSpecial):
(JSC::BytecodeGenerator::argumentsRegister):
(JSC::BytecodeGenerator::emitNode):
(JSC::BytecodeGenerator::registerFor):
(JSC::Local::Local): Deleted.
(JSC::Local::operator bool): Deleted.
(JSC::Local::get): Deleted.
(JSC::Local::isSpecial): Deleted.
(JSC::ResolveScopeInfo::ResolveScopeInfo): Deleted.
(JSC::ResolveScopeInfo::isLocal): Deleted.
(JSC::ResolveScopeInfo::localIndex): Deleted.
(JSC::BytecodeGenerator::hasSafeLocalArgumentsRegister): Deleted.
(JSC::BytecodeGenerator::captureMode): Deleted.
(JSC::BytecodeGenerator::shouldTearOffArgumentsEagerly): Deleted.
(JSC::BytecodeGenerator::shouldCreateArgumentsEagerly): Deleted.
(JSC::BytecodeGenerator::hasWatchableVariable): Deleted.
(JSC::BytecodeGenerator::watchableVariableIdentifier): Deleted.
* bytecompiler/NodesCodegen.cpp:
(JSC::ResolveNode::isPure):
(JSC::ResolveNode::emitBytecode):
(JSC::BracketAccessorNode::emitBytecode):
(JSC::DotAccessorNode::emitBytecode):
(JSC::EvalFunctionCallNode::emitBytecode):
(JSC::FunctionCallResolveNode::emitBytecode):
(JSC::CallFunctionCallDotNode::emitBytecode):
(JSC::ApplyFunctionCallDotNode::emitBytecode):
(JSC::PostfixNode::emitResolve):
(JSC::DeleteResolveNode::emitBytecode):
(JSC::TypeOfResolveNode::emitBytecode):
(JSC::PrefixNode::emitResolve):
(JSC::ReadModifyResolveNode::emitBytecode):
(JSC::AssignResolveNode::emitBytecode):
(JSC::ConstDeclNode::emitCodeSingle):
(JSC::EmptyVarExpression::emitBytecode):
(JSC::ForInNode::tryGetBoundLocal):
(JSC::ForInNode::emitLoopHeader):
(JSC::ForOfNode::emitBytecode):
(JSC::ArrayPatternNode::emitDirectBinding):
(JSC::BindingNode::bindValue):
(JSC::getArgumentByVal): Deleted.
* dfg/DFGAbstractHeap.h:
* dfg/DFGAbstractInterpreter.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
(JSC::DFG::AbstractInterpreter<AbstractStateType>::clobberWorld):
(JSC::DFG::AbstractInterpreter<AbstractStateType>::clobberCapturedVars): Deleted.
* dfg/DFGAbstractValue.h:
* dfg/DFGArgumentPosition.h:
(JSC::DFG::ArgumentPosition::addVariable):
* dfg/DFGArgumentsEliminationPhase.cpp: Added.
(JSC::DFG::performArgumentsElimination):
* dfg/DFGArgumentsEliminationPhase.h: Added.
* dfg/DFGArgumentsSimplificationPhase.cpp: Removed.
* dfg/DFGArgumentsSimplificationPhase.h: Removed.
* dfg/DFGArgumentsUtilities.cpp: Added.
(JSC::DFG::argumentsInvolveStackSlot):
(JSC::DFG::emitCodeToGetArgumentsArrayLength):
* dfg/DFGArgumentsUtilities.h: Added.
* dfg/DFGArrayMode.cpp:
(JSC::DFG::ArrayMode::refine):
(JSC::DFG::ArrayMode::alreadyChecked):
(JSC::DFG::arrayTypeToString):
* dfg/DFGArrayMode.h:
(JSC::DFG::ArrayMode::canCSEStorage):
(JSC::DFG::ArrayMode::modeForPut):
* dfg/DFGAvailabilityMap.cpp:
(JSC::DFG::AvailabilityMap::prune):
* dfg/DFGAvailabilityMap.h:
(JSC::DFG::AvailabilityMap::closeOverNodes):
(JSC::DFG::AvailabilityMap::closeStartingWithLocal):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::newVariableAccessData):
(JSC::DFG::ByteCodeParser::getLocal):
(JSC::DFG::ByteCodeParser::setLocal):
(JSC::DFG::ByteCodeParser::getArgument):
(JSC::DFG::ByteCodeParser::setArgument):
(JSC::DFG::ByteCodeParser::flushDirect):
(JSC::DFG::ByteCodeParser::flush):
(JSC::DFG::ByteCodeParser::noticeArgumentsUse):
(JSC::DFG::ByteCodeParser::handleVarargsCall):
(JSC::DFG::ByteCodeParser::attemptToInlineCall):
(JSC::DFG::ByteCodeParser::handleInlining):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
(JSC::DFG::ByteCodeParser::parseCodeBlock):
* dfg/DFGCPSRethreadingPhase.cpp:
(JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
(JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
* dfg/DFGCSEPhase.cpp:
* dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h: Added.
(JSC::DFG::CallCreateDirectArgumentsSlowPathGenerator::CallCreateDirectArgumentsSlowPathGenerator):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::isSupportedForInlining):
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGCommon.h:
* dfg/DFGCommonData.h:
(JSC::DFG::CommonData::CommonData):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDCEPhase.cpp:
(JSC::DFG::DCEPhase::cleanVariables):
* dfg/DFGDisassembler.h:
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGFlushFormat.cpp:
(WTF::printInternal):
* dfg/DFGFlushFormat.h:
(JSC::DFG::resultFor):
(JSC::DFG::useKindFor):
(JSC::DFG::dataFormatFor):
* dfg/DFGForAllKills.h: Added.
(JSC::DFG::forAllLiveNodesAtTail):
(JSC::DFG::forAllDirectlyKilledOperands):
(JSC::DFG::forAllKilledOperands):
(JSC::DFG::forAllKilledNodesAtNodeIndex):
(JSC::DFG::forAllKillsInBlock):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::Graph):
(JSC::DFG::Graph::dump):
(JSC::DFG::Graph::substituteGetLocal):
(JSC::DFG::Graph::livenessFor):
(JSC::DFG::Graph::killsFor):
(JSC::DFG::Graph::tryGetConstantClosureVar):
(JSC::DFG::Graph::tryGetRegisters): Deleted.
* dfg/DFGGraph.h:
(JSC::DFG::Graph::symbolTableFor):
(JSC::DFG::Graph::uses):
(JSC::DFG::Graph::bytecodeRegisterForArgument): Deleted.
(JSC::DFG::Graph::capturedVarsFor): Deleted.
(JSC::DFG::Graph::usesArguments): Deleted.
(JSC::DFG::Graph::argumentsRegisterFor): Deleted.
(JSC::DFG::Graph::machineArgumentsRegisterFor): Deleted.
(JSC::DFG::Graph::uncheckedArgumentsRegisterFor): Deleted.
* dfg/DFGHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGHeapLocation.h:
* dfg/DFGInPlaceAbstractState.cpp:
(JSC::DFG::InPlaceAbstractState::initialize):
(JSC::DFG::InPlaceAbstractState::mergeStateAtTail):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
* dfg/DFGMayExit.cpp:
(JSC::DFG::mayExit):
* dfg/DFGMinifiedID.h:
* dfg/DFGMinifiedNode.cpp:
(JSC::DFG::MinifiedNode::fromNode):
* dfg/DFGMinifiedNode.h:
(JSC::DFG::belongsInMinifiedGraph):
(JSC::DFG::MinifiedNode::hasInlineCallFrame):
(JSC::DFG::MinifiedNode::inlineCallFrame):
* dfg/DFGNode.cpp:
(JSC::DFG::Node::convertToIdentityOn):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasConstant):
(JSC::DFG::Node::constant):
(JSC::DFG::Node::hasScopeOffset):
(JSC::DFG::Node::scopeOffset):
(JSC::DFG::Node::hasDirectArgumentsOffset):
(JSC::DFG::Node::capturedArgumentsOffset):
(JSC::DFG::Node::variablePointer):
(JSC::DFG::Node::hasCallVarargsData):
(JSC::DFG::Node::hasLoadVarargsData):
(JSC::DFG::Node::hasHeapPrediction):
(JSC::DFG::Node::hasCellOperand):
(JSC::DFG::Node::objectMaterializationData):
(JSC::DFG::Node::isPhantomAllocation):
(JSC::DFG::Node::willHaveCodeGenOrOSR):
(JSC::DFG::Node::shouldSpeculateDirectArguments):
(JSC::DFG::Node::shouldSpeculateScopedArguments):
(JSC::DFG::Node::isPhantomArguments): Deleted.
(JSC::DFG::Node::hasVarNumber): Deleted.
(JSC::DFG::Node::varNumber): Deleted.
(JSC::DFG::Node::registerPointer): Deleted.
(JSC::DFG::Node::shouldSpeculateArguments): Deleted.
* dfg/DFGNodeType.h:
* dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
(JSC::DFG::OSRAvailabilityAnalysisPhase::run):
(JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
* dfg/DFGOSRExitCompiler.cpp:
(JSC::DFG::OSRExitCompiler::emitRestoreArguments):
* dfg/DFGOSRExitCompiler.h:
(JSC::DFG::OSRExitCompiler::badIndex): Deleted.
(JSC::DFG::OSRExitCompiler::initializePoisoned): Deleted.
(JSC::DFG::OSRExitCompiler::poisonIndex): Deleted.
* dfg/DFGOSRExitCompiler32_64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompiler64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
(JSC::DFG::ArgumentsRecoveryGenerator::ArgumentsRecoveryGenerator): Deleted.
(JSC::DFG::ArgumentsRecoveryGenerator::~ArgumentsRecoveryGenerator): Deleted.
(JSC::DFG::ArgumentsRecoveryGenerator::generateFor): Deleted.
* dfg/DFGOSRExitCompilerCommon.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGPreciseLocalClobberize.h:
(JSC::DFG::PreciseLocalClobberizeAdaptor::read):
(JSC::DFG::PreciseLocalClobberizeAdaptor::write):
(JSC::DFG::PreciseLocalClobberizeAdaptor::def):
(JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
(JSC::DFG::preciseLocalClobberize):
(JSC::DFG::PreciseLocalClobberizeAdaptor::writeTop): Deleted.
(JSC::DFG::forEachLocalReadByUnwind): Deleted.
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::run):
(JSC::DFG::PredictionPropagationPhase::propagate):
(JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting):
(JSC::DFG::PredictionPropagationPhase::propagateThroughArgumentPositions):
* dfg/DFGPromoteHeapAccess.h:
(JSC::DFG::promoteHeapAccess):
* dfg/DFGPromotedHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGPromotedHeapLocation.h:
* dfg/DFGSSAConversionPhase.cpp:
(JSC::DFG::SSAConversionPhase::run):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitAllocateJSArray):
(JSC::DFG::SpeculativeJIT::emitGetLength):
(JSC::DFG::SpeculativeJIT::emitGetCallee):
(JSC::DFG::SpeculativeJIT::emitGetArgumentStart):
(JSC::DFG::SpeculativeJIT::checkArray):
(JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments):
(JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
(JSC::DFG::SpeculativeJIT::compileGetArrayLength):
(JSC::DFG::SpeculativeJIT::compileNewFunction):
(JSC::DFG::SpeculativeJIT::compileForwardVarargs):
(JSC::DFG::SpeculativeJIT::compileCreateActivation):
(JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
(JSC::DFG::SpeculativeJIT::compileGetFromArguments):
(JSC::DFG::SpeculativeJIT::compilePutToArguments):
(JSC::DFG::SpeculativeJIT::compileCreateScopedArguments):
(JSC::DFG::SpeculativeJIT::compileCreateClonedArguments):
(JSC::DFG::SpeculativeJIT::emitAllocateArguments): Deleted.
(JSC::DFG::SpeculativeJIT::compileGetByValOnArguments): Deleted.
(JSC::DFG::SpeculativeJIT::compileGetArgumentsLength): Deleted.
(JSC::DFG::SpeculativeJIT::compileNewFunctionNoCheck): Deleted.
(JSC::DFG::SpeculativeJIT::compileNewFunctionExpression): Deleted.
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
(JSC::DFG::SpeculativeJIT::emitAllocateJSObjectWithKnownSize):
(JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
(JSC::DFG::SpeculativeJIT::framePointerOffsetToGetActivationRegisters): Deleted.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStackLayoutPhase.cpp:
(JSC::DFG::StackLayoutPhase::run):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* dfg/DFGStructureRegistrationPhase.cpp:
(JSC::DFG::StructureRegistrationPhase::run):
* dfg/DFGUnificationPhase.cpp:
(JSC::DFG::UnificationPhase::run):
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::validateCPS):
* dfg/DFGValueSource.cpp:
(JSC::DFG::ValueSource::dump):
* dfg/DFGValueSource.h:
(JSC::DFG::dataFormatToValueSourceKind):
(JSC::DFG::valueSourceKindToDataFormat):
(JSC::DFG::ValueSource::ValueSource):
(JSC::DFG::ValueSource::forFlushFormat):
(JSC::DFG::ValueSource::valueRecovery):
* dfg/DFGVarargsForwardingPhase.cpp: Added.
(JSC::DFG::performVarargsForwarding):
* dfg/DFGVarargsForwardingPhase.h: Added.
* dfg/DFGVariableAccessData.cpp:
(JSC::DFG::VariableAccessData::VariableAccessData):
(JSC::DFG::VariableAccessData::flushFormat):
(JSC::DFG::VariableAccessData::mergeIsCaptured): Deleted.
* dfg/DFGVariableAccessData.h:
(JSC::DFG::VariableAccessData::shouldNeverUnbox):
(JSC::DFG::VariableAccessData::shouldUseDoubleFormat):
(JSC::DFG::VariableAccessData::isCaptured): Deleted.
(JSC::DFG::VariableAccessData::mergeIsArgumentsAlias): Deleted.
(JSC::DFG::VariableAccessData::isArgumentsAlias): Deleted.
* dfg/DFGVariableAccessDataDump.cpp:
(JSC::DFG::VariableAccessDataDump::dump):
* dfg/DFGVariableAccessDataDump.h:
* dfg/DFGVariableEventStream.cpp:
(JSC::DFG::VariableEventStream::tryToSetConstantRecovery):
* dfg/DFGVariableEventStream.h:
* ftl/FTLAbstractHeap.cpp:
(JSC::FTL::AbstractHeap::dump):
(JSC::FTL::AbstractField::dump):
(JSC::FTL::IndexedAbstractHeap::dump):
(JSC::FTL::NumberedAbstractHeap::dump):
(JSC::FTL::AbsoluteAbstractHeap::dump):
* ftl/FTLAbstractHeap.h:
* ftl/FTLAbstractHeapRepository.cpp:
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLExitArgument.cpp:
(JSC::FTL::ExitArgument::dump):
* ftl/FTLExitPropertyValue.cpp:
(JSC::FTL::ExitPropertyValue::withLocalsOffset):
* ftl/FTLExitPropertyValue.h:
* ftl/FTLExitTimeObjectMaterialization.cpp:
(JSC::FTL::ExitTimeObjectMaterialization::ExitTimeObjectMaterialization):
(JSC::FTL::ExitTimeObjectMaterialization::accountForLocalsOffset):
* ftl/FTLExitTimeObjectMaterialization.h:
(JSC::FTL::ExitTimeObjectMaterialization::origin):
* ftl/FTLExitValue.cpp:
(JSC::FTL::ExitValue::withLocalsOffset):
(JSC::FTL::ExitValue::valueFormat):
(JSC::FTL::ExitValue::dumpInContext):
* ftl/FTLExitValue.h:
(JSC::FTL::ExitValue::isArgument):
(JSC::FTL::ExitValue::argumentsObjectThatWasNotCreated): Deleted.
(JSC::FTL::ExitValue::isArgumentsObjectThatWasNotCreated): Deleted.
(JSC::FTL::ExitValue::valueFormat): Deleted.
* ftl/FTLInlineCacheSize.cpp:
(JSC::FTL::sizeOfCallForwardVarargs):
(JSC::FTL::sizeOfConstructForwardVarargs):
(JSC::FTL::sizeOfICFor):
* ftl/FTLInlineCacheSize.h:
* ftl/FTLIntrinsicRepository.h:
* ftl/FTLJSCallVarargs.cpp:
(JSC::FTL::JSCallVarargs::JSCallVarargs):
(JSC::FTL::JSCallVarargs::emit):
* ftl/FTLJSCallVarargs.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::lower):
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compilePutStack):
(JSC::FTL::LowerDFGToLLVM::compileGetArrayLength):
(JSC::FTL::LowerDFGToLLVM::compileGetByVal):
(JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentByVal):
(JSC::FTL::LowerDFGToLLVM::compilePutByVal):
(JSC::FTL::LowerDFGToLLVM::compileArrayPush):
(JSC::FTL::LowerDFGToLLVM::compileArrayPop):
(JSC::FTL::LowerDFGToLLVM::compileCreateActivation):
(JSC::FTL::LowerDFGToLLVM::compileNewFunction):
(JSC::FTL::LowerDFGToLLVM::compileCreateDirectArguments):
(JSC::FTL::LowerDFGToLLVM::compileCreateScopedArguments):
(JSC::FTL::LowerDFGToLLVM::compileCreateClonedArguments):
(JSC::FTL::LowerDFGToLLVM::compileStringCharAt):
(JSC::FTL::LowerDFGToLLVM::compileStringCharCodeAt):
(JSC::FTL::LowerDFGToLLVM::compileGetGlobalVar):
(JSC::FTL::LowerDFGToLLVM::compilePutGlobalVar):
(JSC::FTL::LowerDFGToLLVM::compileGetArgumentCount):
(JSC::FTL::LowerDFGToLLVM::compileGetClosureVar):
(JSC::FTL::LowerDFGToLLVM::compilePutClosureVar):
(JSC::FTL::LowerDFGToLLVM::compileGetFromArguments):
(JSC::FTL::LowerDFGToLLVM::compilePutToArguments):
(JSC::FTL::LowerDFGToLLVM::compileCallOrConstructVarargs):
(JSC::FTL::LowerDFGToLLVM::compileForwardVarargs):
(JSC::FTL::LowerDFGToLLVM::compileGetEnumeratorPname):
(JSC::FTL::LowerDFGToLLVM::ArgumentsLength::ArgumentsLength):
(JSC::FTL::LowerDFGToLLVM::getArgumentsLength):
(JSC::FTL::LowerDFGToLLVM::getCurrentCallee):
(JSC::FTL::LowerDFGToLLVM::getArgumentsStart):
(JSC::FTL::LowerDFGToLLVM::baseIndex):
(JSC::FTL::LowerDFGToLLVM::allocateObject):
(JSC::FTL::LowerDFGToLLVM::allocateVariableSizedObject):
(JSC::FTL::LowerDFGToLLVM::isArrayType):
(JSC::FTL::LowerDFGToLLVM::emitStoreBarrier):
(JSC::FTL::LowerDFGToLLVM::buildExitArguments):
(JSC::FTL::LowerDFGToLLVM::exitValueForAvailability):
(JSC::FTL::LowerDFGToLLVM::exitValueForNode):
(JSC::FTL::LowerDFGToLLVM::loadStructure):
(JSC::FTL::LowerDFGToLLVM::compilePhantomArguments): Deleted.
(JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentsLength): Deleted.
(JSC::FTL::LowerDFGToLLVM::compileGetClosureRegisters): Deleted.
(JSC::FTL::LowerDFGToLLVM::compileCheckArgumentsNotCreated): Deleted.
(JSC::FTL::LowerDFGToLLVM::checkArgumentsNotCreated): Deleted.
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileRecovery):
(JSC::FTL::compileStub):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
* ftl/FTLOutput.h:
(JSC::FTL::Output::aShr):
(JSC::FTL::Output::lShr):
(JSC::FTL::Output::zeroExtPtr):
* heap/CopyToken.h:
* interpreter/CallFrame.h:
(JSC::ExecState::getArgumentUnsafe):
* interpreter/Interpreter.cpp:
(JSC::sizeOfVarargs):
(JSC::sizeFrameForVarargs):
(JSC::loadVarargs):
(JSC::unwindCallFrame):
* interpreter/Interpreter.h:
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::createArguments):
(JSC::StackVisitor::Frame::existingArguments): Deleted.
* interpreter/StackVisitor.h:
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::storeValue):
(JSC::AssemblyHelpers::loadValue):
(JSC::AssemblyHelpers::storeTrustedValue):
(JSC::AssemblyHelpers::branchIfNotCell):
(JSC::AssemblyHelpers::branchIsEmpty):
(JSC::AssemblyHelpers::argumentsStart):
(JSC::AssemblyHelpers::baselineArgumentsRegisterFor): Deleted.
(JSC::AssemblyHelpers::offsetOfLocals): Deleted.
(JSC::AssemblyHelpers::offsetOfArguments): Deleted.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgument):
* jit/GPRInfo.h:
(JSC::JSValueRegs::withTwoAvailableRegs):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JIT.h:
* jit/JITCall.cpp:
(JSC::JIT::compileSetupVarargsFrame):
* jit/JITCall32_64.cpp:
(JSC::JIT::compileSetupVarargsFrame):
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_create_lexical_environment):
(JSC::JIT::emit_op_new_func):
(JSC::JIT::emit_op_create_direct_arguments):
(JSC::JIT::emit_op_create_scoped_arguments):
(JSC::JIT::emit_op_create_out_of_band_arguments):
(JSC::JIT::emit_op_tear_off_arguments): Deleted.
(JSC::JIT::emit_op_create_arguments): Deleted.
(JSC::JIT::emit_op_init_lazy_reg): Deleted.
(JSC::JIT::emit_op_get_arguments_length): Deleted.
(JSC::JIT::emitSlow_op_get_arguments_length): Deleted.
(JSC::JIT::emit_op_get_argument_by_val): Deleted.
(JSC::JIT::emitSlow_op_get_argument_by_val): Deleted.
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_create_lexical_environment):
(JSC::JIT::emit_op_tear_off_arguments): Deleted.
(JSC::JIT::emit_op_create_arguments): Deleted.
(JSC::JIT::emit_op_init_lazy_reg): Deleted.
(JSC::JIT::emit_op_get_arguments_length): Deleted.
(JSC::JIT::emitSlow_op_get_arguments_length): Deleted.
(JSC::JIT::emit_op_get_argument_by_val): Deleted.
(JSC::JIT::emitSlow_op_get_argument_by_val): Deleted.
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitGetClosureVar):
(JSC::JIT::emitPutClosureVar):
(JSC::JIT::emit_op_get_from_arguments):
(JSC::JIT::emit_op_put_to_arguments):
(JSC::JIT::emit_op_init_global_const):
(JSC::JIT::privateCompileGetByVal):
(JSC::JIT::emitDirectArgumentsGetByVal):
(JSC::JIT::emitScopedArgumentsGetByVal):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emitGetClosureVar):
(JSC::JIT::emitPutClosureVar):
(JSC::JIT::emit_op_get_from_arguments):
(JSC::JIT::emit_op_put_to_arguments):
(JSC::JIT::emit_op_init_global_const):
* jit/SetupVarargsFrame.cpp:
(JSC::emitSetupVarargsFrameFastCase):
* llint/LLIntOffsetsExtractor.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* parser/Nodes.h:
(JSC::ScopeNode::captures):
* runtime/Arguments.cpp: Removed.
* runtime/Arguments.h: Removed.
* runtime/ArgumentsMode.h: Added.
* runtime/DirectArgumentsOffset.cpp: Added.
(JSC::DirectArgumentsOffset::dump):
* runtime/DirectArgumentsOffset.h: Added.
(JSC::DirectArgumentsOffset::DirectArgumentsOffset):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* runtime/ConstantMode.cpp: Added.
(WTF::printInternal):
* runtime/ConstantMode.h:
(JSC::modeForIsConstant):
* runtime/DirectArguments.cpp: Added.
(JSC::DirectArguments::DirectArguments):
(JSC::DirectArguments::createUninitialized):
(JSC::DirectArguments::create):
(JSC::DirectArguments::createByCopying):
(JSC::DirectArguments::visitChildren):
(JSC::DirectArguments::copyBackingStore):
(JSC::DirectArguments::createStructure):
(JSC::DirectArguments::overrideThings):
(JSC::DirectArguments::overrideThingsIfNecessary):
(JSC::DirectArguments::overrideArgument):
(JSC::DirectArguments::copyToArguments):
(JSC::DirectArguments::overridesSize):
* runtime/DirectArguments.h: Added.
(JSC::DirectArguments::internalLength):
(JSC::DirectArguments::length):
(JSC::DirectArguments::canAccessIndexQuickly):
(JSC::DirectArguments::getIndexQuickly):
(JSC::DirectArguments::setIndexQuickly):
(JSC::DirectArguments::callee):
(JSC::DirectArguments::argument):
(JSC::DirectArguments::overrodeThings):
(JSC::DirectArguments::offsetOfCallee):
(JSC::DirectArguments::offsetOfLength):
(JSC::DirectArguments::offsetOfMinCapacity):
(JSC::DirectArguments::offsetOfOverrides):
(JSC::DirectArguments::storageOffset):
(JSC::DirectArguments::offsetOfSlot):
(JSC::DirectArguments::allocationSize):
(JSC::DirectArguments::storage):
* runtime/FunctionPrototype.cpp:
* runtime/GenericArguments.h: Added.
(JSC::GenericArguments::GenericArguments):
* runtime/GenericArgumentsInlines.h: Added.
(JSC::GenericArguments<Type>::getOwnPropertySlot):
(JSC::GenericArguments<Type>::getOwnPropertySlotByIndex):
(JSC::GenericArguments<Type>::getOwnPropertyNames):
(JSC::GenericArguments<Type>::put):
(JSC::GenericArguments<Type>::putByIndex):
(JSC::GenericArguments<Type>::deleteProperty):
(JSC::GenericArguments<Type>::deletePropertyByIndex):
(JSC::GenericArguments<Type>::defineOwnProperty):
(JSC::GenericArguments<Type>::copyToArguments):
* runtime/GenericOffset.h: Added.
(JSC::GenericOffset::GenericOffset):
(JSC::GenericOffset::operator!):
(JSC::GenericOffset::offsetUnchecked):
(JSC::GenericOffset::offset):
(JSC::GenericOffset::operator==):
(JSC::GenericOffset::operator!=):
(JSC::GenericOffset::operator<):
(JSC::GenericOffset::operator>):
(JSC::GenericOffset::operator<=):
(JSC::GenericOffset::operator>=):
(JSC::GenericOffset::operator+):
(JSC::GenericOffset::operator-):
(JSC::GenericOffset::operator+=):
(JSC::GenericOffset::operator-=):
* runtime/JSArgumentsIterator.cpp:
(JSC::JSArgumentsIterator::finishCreation):
(JSC::argumentsFuncIterator):
* runtime/JSArgumentsIterator.h:
(JSC::JSArgumentsIterator::create):
(JSC::JSArgumentsIterator::next):
* runtime/JSEnvironmentRecord.cpp:
(JSC::JSEnvironmentRecord::visitChildren):
* runtime/JSEnvironmentRecord.h:
(JSC::JSEnvironmentRecord::variables):
(JSC::JSEnvironmentRecord::isValid):
(JSC::JSEnvironmentRecord::variableAt):
(JSC::JSEnvironmentRecord::offsetOfVariables):
(JSC::JSEnvironmentRecord::offsetOfVariable):
(JSC::JSEnvironmentRecord::allocationSizeForScopeSize):
(JSC::JSEnvironmentRecord::allocationSize):
(JSC::JSEnvironmentRecord::JSEnvironmentRecord):
(JSC::JSEnvironmentRecord::finishCreationUninitialized):
(JSC::JSEnvironmentRecord::finishCreation):
(JSC::JSEnvironmentRecord::registers): Deleted.
(JSC::JSEnvironmentRecord::registerAt): Deleted.
(JSC::JSEnvironmentRecord::addressOfRegisters): Deleted.
(JSC::JSEnvironmentRecord::offsetOfRegisters): Deleted.
* runtime/JSFunction.cpp:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::addGlobalVar):
(JSC::JSGlobalObject::addFunction):
(JSC::JSGlobalObject::visitChildren):
(JSC::JSGlobalObject::addStaticGlobals):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::directArgumentsStructure):
(JSC::JSGlobalObject::scopedArgumentsStructure):
(JSC::JSGlobalObject::outOfBandArgumentsStructure):
(JSC::JSGlobalObject::argumentsStructure): Deleted.
* runtime/JSLexicalEnvironment.cpp:
(JSC::JSLexicalEnvironment::symbolTableGet):
(JSC::JSLexicalEnvironment::symbolTablePut):
(JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames):
(JSC::JSLexicalEnvironment::symbolTablePutWithAttributes):
(JSC::JSLexicalEnvironment::visitChildren): Deleted.
* runtime/JSLexicalEnvironment.h:
(JSC::JSLexicalEnvironment::create):
(JSC::JSLexicalEnvironment::JSLexicalEnvironment):
(JSC::JSLexicalEnvironment::registersOffset): Deleted.
(JSC::JSLexicalEnvironment::storageOffset): Deleted.
(JSC::JSLexicalEnvironment::storage): Deleted.
(JSC::JSLexicalEnvironment::allocationSize): Deleted.
(JSC::JSLexicalEnvironment::isValidIndex): Deleted.
(JSC::JSLexicalEnvironment::isValid): Deleted.
(JSC::JSLexicalEnvironment::registerAt): Deleted.
* runtime/JSNameScope.cpp:
(JSC::JSNameScope::visitChildren): Deleted.
* runtime/JSNameScope.h:
(JSC::JSNameScope::create):
(JSC::JSNameScope::value):
(JSC::JSNameScope::finishCreation):
(JSC::JSNameScope::JSNameScope):
* runtime/JSScope.cpp:
(JSC::abstractAccess):
* runtime/JSSegmentedVariableObject.cpp:
(JSC::JSSegmentedVariableObject::findVariableIndex):
(JSC::JSSegmentedVariableObject::addVariables):
(JSC::JSSegmentedVariableObject::visitChildren):
(JSC::JSSegmentedVariableObject::findRegisterIndex): Deleted.
(JSC::JSSegmentedVariableObject::addRegisters): Deleted.
* runtime/JSSegmentedVariableObject.h:
(JSC::JSSegmentedVariableObject::variableAt):
(JSC::JSSegmentedVariableObject::assertVariableIsInThisObject):
(JSC::JSSegmentedVariableObject::registerAt): Deleted.
(JSC::JSSegmentedVariableObject::assertRegisterIsInThisObject): Deleted.
* runtime/JSSymbolTableObject.h:
(JSC::JSSymbolTableObject::offsetOfSymbolTable):
(JSC::symbolTableGet):
(JSC::symbolTablePut):
(JSC::symbolTablePutWithAttributes):
* runtime/JSType.h:
* runtime/Options.h:
* runtime/ClonedArguments.cpp: Added.
(JSC::ClonedArguments::ClonedArguments):
(JSC::ClonedArguments::createEmpty):
(JSC::ClonedArguments::createWithInlineFrame):
(JSC::ClonedArguments::createWithMachineFrame):
(JSC::ClonedArguments::createByCopyingFrom):
(JSC::ClonedArguments::createStructure):
(JSC::ClonedArguments::getOwnPropertySlot):
(JSC::ClonedArguments::getOwnPropertyNames):
(JSC::ClonedArguments::put):
(JSC::ClonedArguments::deleteProperty):
(JSC::ClonedArguments::defineOwnProperty):
(JSC::ClonedArguments::materializeSpecials):
(JSC::ClonedArguments::materializeSpecialsIfNecessary):
* runtime/ClonedArguments.h: Added.
(JSC::ClonedArguments::specialsMaterialized):
* runtime/ScopeOffset.cpp: Added.
(JSC::ScopeOffset::dump):
* runtime/ScopeOffset.h: Added.
(JSC::ScopeOffset::ScopeOffset):
* runtime/ScopedArguments.cpp: Added.
(JSC::ScopedArguments::ScopedArguments):
(JSC::ScopedArguments::finishCreation):
(JSC::ScopedArguments::createUninitialized):
(JSC::ScopedArguments::create):
(JSC::ScopedArguments::createByCopying):
(JSC::ScopedArguments::createByCopyingFrom):
(JSC::ScopedArguments::visitChildren):
(JSC::ScopedArguments::createStructure):
(JSC::ScopedArguments::overrideThings):
(JSC::ScopedArguments::overrideThingsIfNecessary):
(JSC::ScopedArguments::overrideArgument):
(JSC::ScopedArguments::copyToArguments):
* runtime/ScopedArguments.h: Added.
(JSC::ScopedArguments::internalLength):
(JSC::ScopedArguments::length):
(JSC::ScopedArguments::canAccessIndexQuickly):
(JSC::ScopedArguments::getIndexQuickly):
(JSC::ScopedArguments::setIndexQuickly):
(JSC::ScopedArguments::callee):
(JSC::ScopedArguments::overrodeThings):
(JSC::ScopedArguments::offsetOfOverrodeThings):
(JSC::ScopedArguments::offsetOfTotalLength):
(JSC::ScopedArguments::offsetOfTable):
(JSC::ScopedArguments::offsetOfScope):
(JSC::ScopedArguments::overflowStorageOffset):
(JSC::ScopedArguments::allocationSize):
(JSC::ScopedArguments::overflowStorage):
* runtime/ScopedArgumentsTable.cpp: Added.
(JSC::ScopedArgumentsTable::ScopedArgumentsTable):
(JSC::ScopedArgumentsTable::~ScopedArgumentsTable):
(JSC::ScopedArgumentsTable::destroy):
(JSC::ScopedArgumentsTable::create):
(JSC::ScopedArgumentsTable::clone):
(JSC::ScopedArgumentsTable::setLength):
(JSC::ScopedArgumentsTable::set):
(JSC::ScopedArgumentsTable::createStructure):
* runtime/ScopedArgumentsTable.h: Added.
(JSC::ScopedArgumentsTable::length):
(JSC::ScopedArgumentsTable::get):
(JSC::ScopedArgumentsTable::lock):
(JSC::ScopedArgumentsTable::offsetOfLength):
(JSC::ScopedArgumentsTable::offsetOfArguments):
(JSC::ScopedArgumentsTable::at):
* runtime/SymbolTable.cpp:
(JSC::SymbolTableEntry::prepareToWatch):
(JSC::SymbolTable::SymbolTable):
(JSC::SymbolTable::visitChildren):
(JSC::SymbolTable::localToEntry):
(JSC::SymbolTable::entryFor):
(JSC::SymbolTable::cloneScopePart):
(JSC::SymbolTable::prepareForTypeProfiling):
(JSC::SymbolTable::uniqueIDForOffset):
(JSC::SymbolTable::globalTypeSetForOffset):
(JSC::SymbolTable::cloneCapturedNames): Deleted.
(JSC::SymbolTable::uniqueIDForRegister): Deleted.
(JSC::SymbolTable::globalTypeSetForRegister): Deleted.
* runtime/SymbolTable.h:
(JSC::SymbolTableEntry::varOffsetFromBits):
(JSC::SymbolTableEntry::scopeOffsetFromBits):
(JSC::SymbolTableEntry::Fast::varOffset):
(JSC::SymbolTableEntry::Fast::scopeOffset):
(JSC::SymbolTableEntry::Fast::isDontEnum):
(JSC::SymbolTableEntry::Fast::getAttributes):
(JSC::SymbolTableEntry::SymbolTableEntry):
(JSC::SymbolTableEntry::varOffset):
(JSC::SymbolTableEntry::isWatchable):
(JSC::SymbolTableEntry::scopeOffset):
(JSC::SymbolTableEntry::setAttributes):
(JSC::SymbolTableEntry::constantMode):
(JSC::SymbolTableEntry::isDontEnum):
(JSC::SymbolTableEntry::disableWatching):
(JSC::SymbolTableEntry::pack):
(JSC::SymbolTableEntry::isValidVarOffset):
(JSC::SymbolTable::createNameScopeTable):
(JSC::SymbolTable::maxScopeOffset):
(JSC::SymbolTable::didUseScopeOffset):
(JSC::SymbolTable::didUseVarOffset):
(JSC::SymbolTable::scopeSize):
(JSC::SymbolTable::nextScopeOffset):
(JSC::SymbolTable::takeNextScopeOffset):
(JSC::SymbolTable::add):
(JSC::SymbolTable::set):
(JSC::SymbolTable::argumentsLength):
(JSC::SymbolTable::setArgumentsLength):
(JSC::SymbolTable::argumentOffset):
(JSC::SymbolTable::setArgumentOffset):
(JSC::SymbolTable::arguments):
(JSC::SlowArgument::SlowArgument): Deleted.
(JSC::SymbolTableEntry::Fast::getIndex): Deleted.
(JSC::SymbolTableEntry::getIndex): Deleted.
(JSC::SymbolTableEntry::isValidIndex): Deleted.
(JSC::SymbolTable::captureStart): Deleted.
(JSC::SymbolTable::setCaptureStart): Deleted.
(JSC::SymbolTable::captureEnd): Deleted.
(JSC::SymbolTable::setCaptureEnd): Deleted.
(JSC::SymbolTable::captureCount): Deleted.
(JSC::SymbolTable::isCaptured): Deleted.
(JSC::SymbolTable::parameterCount): Deleted.
(JSC::SymbolTable::parameterCountIncludingThis): Deleted.
(JSC::SymbolTable::setParameterCountIncludingThis): Deleted.
(JSC::SymbolTable::slowArguments): Deleted.
(JSC::SymbolTable::setSlowArguments): Deleted.
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
* runtime/VarOffset.cpp: Added.
(JSC::VarOffset::dump):
(WTF::printInternal):
* runtime/VarOffset.h: Added.
(JSC::VarOffset::VarOffset):
(JSC::VarOffset::assemble):
(JSC::VarOffset::isValid):
(JSC::VarOffset::operator!):
(JSC::VarOffset::kind):
(JSC::VarOffset::isStack):
(JSC::VarOffset::isScope):
(JSC::VarOffset::isDirectArgument):
(JSC::VarOffset::stackOffsetUnchecked):
(JSC::VarOffset::scopeOffsetUnchecked):
(JSC::VarOffset::capturedArgumentsOffsetUnchecked):
(JSC::VarOffset::stackOffset):
(JSC::VarOffset::scopeOffset):
(JSC::VarOffset::capturedArgumentsOffset):
(JSC::VarOffset::rawOffset):
(JSC::VarOffset::checkSanity):
(JSC::VarOffset::operator==):
(JSC::VarOffset::operator!=):
(JSC::VarOffset::hash):
(JSC::VarOffset::isHashTableDeletedValue):
(JSC::VarOffsetHash::hash):
(JSC::VarOffsetHash::equal):
* tests/stress/arguments-exit-strict-mode.js: Added.
* tests/stress/arguments-exit.js: Added.
* tests/stress/arguments-inlined-exit-strict-mode-fixed.js: Added.
* tests/stress/arguments-inlined-exit-strict-mode.js: Added.
* tests/stress/arguments-inlined-exit.js: Added.
* tests/stress/arguments-interference.js: Added.
* tests/stress/arguments-interference-cfg.js: Added.
* tests/stress/dead-get-closure-var.js: Added.
* tests/stress/get-declared-unpassed-argument-in-direct-arguments.js: Added.
* tests/stress/get-declared-unpassed-argument-in-scoped-arguments.js: Added.
* tests/stress/varargs-closure-inlined-exit-strict-mode.js: Added.
* tests/stress/varargs-closure-inlined-exit.js: Added.
* tests/stress/varargs-exit.js: Added.
* tests/stress/varargs-inlined-exit.js: Added.
* tests/stress/varargs-inlined-simple-exit-aliasing-weird-reversed-args.js: Added.
* tests/stress/varargs-inlined-simple-exit-aliasing-weird.js: Added.
* tests/stress/varargs-inlined-simple-exit-aliasing.js: Added.
* tests/stress/varargs-inlined-simple-exit.js: Added.
* tests/stress/varargs-too-few-arguments.js: Added.
* tests/stress/varargs-varargs-closure-inlined-exit.js: Added.
* tests/stress/varargs-varargs-inlined-exit-strict-mode.js: Added.
* tests/stress/varargs-varargs-inlined-exit.js: Added.
2015-03-25 Andy Estes <aestes@apple.com>
[Cocoa] RemoteInspectorXPCConnection::deserializeMessage() leaks a NSDictionary under Objective-C GC
https://bugs.webkit.org/show_bug.cgi?id=143068
Reviewed by Dan Bernstein.
* inspector/remote/RemoteInspectorXPCConnection.mm:
(Inspector::RemoteInspectorXPCConnection::deserializeMessage): Used RetainPtr::autorelease(), which does the right thing under GC.
2015-03-25 Filip Pizlo <fpizlo@apple.com>
Use JITCompilationCanFail in more places, and make the fail path of JITCompilationMustSucceed a crash instead of attempting GC
https://bugs.webkit.org/show_bug.cgi?id=142993
Reviewed by Geoffrey Garen and Mark Lam.
This changes the most commonly invoked paths that relied on JITCompilationMustSucceed
into using JITCompilationCanFail and having a legit fallback path. This mostly involves
having the FTL JIT do the same trick as the DFG JIT in case of any memory allocation
failure, but also involves adding the same kind of thing to the stub generators in
Repatch.
Because of that change, there are relatively few uses of JITCompilationMustSucceed. Most
of those uses cannot handle a GC, and so cannot do releaseExecutableMemory(). Only a few,
like host call stub generation, could handle a GC, but those get invoked very rarely. So,
this patch changes the releaseExecutableMemory() call into a crash with some diagnostic
printout.
Also add a way of inducing executable allocation failure, so that we can test this.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
(JSC::DFG::JITCompiler::link): Deleted.
(JSC::DFG::JITCompiler::linkFunction): Deleted.
* dfg/DFGJITCompiler.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateCodeSection):
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLState.h:
* jit/ArityCheckFailReturnThunks.cpp:
(JSC::ArityCheckFailReturnThunks::returnPCsFor):
* jit/ExecutableAllocationFuzz.cpp: Added.
(JSC::numberOfExecutableAllocationFuzzChecks):
(JSC::doExecutableAllocationFuzzing):
* jit/ExecutableAllocationFuzz.h: Added.
(JSC::doExecutableAllocationFuzzingIfEnabled):
* jit/ExecutableAllocatorFixedVMPool.cpp:
(JSC::ExecutableAllocator::allocate):
* jit/JIT.cpp:
(JSC::JIT::privateCompile):
* jit/JITCompilationEffort.h:
* jit/Repatch.cpp:
(JSC::generateByIdStub):
(JSC::tryCacheGetByID):
(JSC::tryBuildGetByIDList):
(JSC::emitPutReplaceStub):
(JSC::emitPutTransitionStubAndGetOldStructure):
(JSC::tryCachePutByID):
(JSC::tryBuildPutByIdList):
(JSC::tryRepatchIn):
(JSC::linkPolymorphicCall):
* jsc.cpp:
(jscmain):
* runtime/Options.h:
* runtime/TestRunnerUtils.h:
* runtime/VM.cpp:
* tests/executableAllocationFuzz: Added.
* tests/executableAllocationFuzz.yaml: Added.
* tests/executableAllocationFuzz/v8-raytrace.js: Added.
2015-03-25 Mark Lam <mark.lam@apple.com>
REGRESSION(169139): LLINT intermittently fails JSC testapi tests.
<https://webkit.org/b/135719>
Reviewed by Geoffrey Garen.
This is a regression introduced in http://trac.webkit.org/changeset/169139 which
changed VM::watchdog from an embedded field into a std::unique_ptr, but did not
update the LLINT to access it as such.
The issue has only manifested so far on the CLoop tests because those are LLINT
only. In the non-CLoop cases, the JIT kicks in and does the right thing, thereby
hiding the bug in the LLINT.
* API/JSContextRef.cpp:
(createWatchdogIfNeeded):
(JSContextGroupSetExecutionTimeLimit):
(JSContextGroupClearExecutionTimeLimit):
* llint/LowLevelInterpreter.asm:
2015-03-25 Filip Pizlo <fpizlo@apple.com>
Change Atomic methods from using the_wrong_naming_conventions to using theRightNamingConventions. Also make seq_cst the default.
Rubber stamped by Geoffrey Garen.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::visitAggregate):
2015-03-25 Joseph Pecoraro <pecoraro@apple.com>
Fix formatting in BuiltinExecutables
https://bugs.webkit.org/show_bug.cgi?id=143061
Reviewed by Ryosuke Niwa.
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createExecutableInternal):
2015-03-25 Joseph Pecoraro <pecoraro@apple.com>
ES6: Classes: Program level class statement throws exception in strict mode
https://bugs.webkit.org/show_bug.cgi?id=143038
Reviewed by Ryosuke Niwa.
Classes expose a name to the current lexical environment. This treats
"class X {}" like "var X = class X {}". Ideally it would be "let X = class X {}".
Also, improve error messages for class statements where the class is missing a name.
* parser/Parser.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
Fill name in info parameter if needed. Better error message if name is needed and missing.
(JSC::Parser<LexerType>::parseClassDeclaration):
Pass info parameter to get name, and expose the name as a variable name.
(JSC::Parser<LexerType>::parsePrimaryExpression):
Pass info parameter that is ignored.
* parser/ParserFunctionInfo.h:
Add a parser info for class, to extract the name.
2015-03-25 Yusuke Suzuki <utatane.tea@gmail.com>
New map and set modification tests in r181922 fails
https://bugs.webkit.org/show_bug.cgi?id=143031
Reviewed and tweaked by Geoffrey Garen.
When packing Map/Set backing store, we need to decrement Map/Set iterator's m_index
to adjust for the packed backing store.
Consider the following map data.
x: deleted, o: exists
0 1 2 3 4
x x x x o
And iterator with m_index 3.
When packing the map data, map data will become,
0
o
At that time, we perfom didRemoveEntry 4 times on iterators.
times => m_index/index/result
1 => 3/0/dec
2 => 2/1/dec
3 => 1/2/nothing
4 => 1/3/nothing
After iteration, iterator's m_index becomes 1. But we expected that becomes 0.
This is because if we use decremented m_index for comparison,
while provided deletedIndex is the index in old storage, m_index is the index in partially packed storage.
In this patch, we compare against the packed index instead.
times => m_index/packedIndex/result
1 => 3/0/dec
2 => 2/0/dec
3 => 1/0/dec
4 => 0/0/nothing
So m_index becomes 0 as expected.
And according to the spec, once the iterator is closed (becomes done: true),
its internal [[Map]]/[[Set]] is set to undefined.
So after the iterator is finished, we don't revive the iterator (e.g. by clearing m_index = 0).
In this patch, we change 2 things.
1.
Compare an iterator's index against the packed index when removing an entry.
2.
If the iterator is closed (isFinished()), we don't apply adjustment to the iterator.
* runtime/MapData.h:
(JSC::MapDataImpl::IteratorData::finish):
(JSC::MapDataImpl::IteratorData::isFinished):
(JSC::MapDataImpl::IteratorData::didRemoveEntry):
(JSC::MapDataImpl::IteratorData::didRemoveAllEntries):
(JSC::MapDataImpl::IteratorData::startPackBackingStore):
* runtime/MapDataInlines.h:
(JSC::JSIterator>::replaceAndPackBackingStore):
* tests/stress/modify-map-during-iteration.js:
* tests/stress/modify-set-during-iteration.js:
2015-03-24 Joseph Pecoraro <pecoraro@apple.com>
Setter should have a single formal parameter, Getter no parameters
https://bugs.webkit.org/show_bug.cgi?id=142903
Reviewed by Geoffrey Garen.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionInfo):
Enforce no parameters for getters and a single parameter
for setters, with informational error messages.
2015-03-24 Joseph Pecoraro <pecoraro@apple.com>
ES6: Classes: Early return in sub-class constructor results in returning undefined instead of instance
https://bugs.webkit.org/show_bug.cgi?id=143012
Reviewed by Ryosuke Niwa.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitReturn):
Fix handling of "undefined" when returned from a Derived class. It was
returning "undefined" when it should have returned "this".
2015-03-24 Yusuke Suzuki <utatane.tea@gmail.com>
REGRESSION (r181458): Heap use-after-free in JSSetIterator destructor
https://bugs.webkit.org/show_bug.cgi?id=142696
Reviewed and tweaked by Geoffrey Garen.
Before r142556, JSSetIterator::destroy was not defined.
So accidentally MapData::const_iterator in JSSet was never destroyed.
But it had non trivial destructor, decrementing MapData->m_iteratorCount.
After r142556, JSSetIterator::destroy works.
It correctly destruct MapData::const_iterator and m_iteratorCount partially works.
But JSSetIterator::~JSSetIterator requires owned JSSet since it mutates MapData->m_iteratorCount.
It is guaranteed that JSSet is live since JSSetIterator has a reference to JSSet
and marks it in visitChildren (WriteBarrier<Unknown>).
However, the order of destructions is not guaranteed in GC-ed system.
Consider the following case,
allocate JSSet and subsequently allocate JSSetIterator.
And they resides in the separated MarkedBlock, <1> and <2>.
JSSet<1> <- JSSetIterator<2>
And after that, when performing GC, Marker decides that the above 2 objects are not marked.
And Marker also decides MarkedBlocks <1> and <2> can be sweeped.
First Sweeper sweep <1>, destruct JSSet<1> and free MarkedBlock<1>.
Second Sweeper sweep <2>, attempt to destruct JSSetIterator<2>.
However, JSSetIterator<2>'s destructor,
JSSetIterator::~JSSetIterator requires live JSSet<1>, it causes use-after-free.
In this patch, we introduce WeakGCMap into JSMap/JSSet to track live iterators.
When packing the removed elements in JSSet/JSMap, we apply the change to all live
iterators tracked by WeakGCMap.
WeakGCMap can only track JSCell since they are managed by GC.
So we drop JSSet/JSMap C++ style iterators. Instead of C++ style iterator, this patch
introduces JS style iterator signatures into C++ class IteratorData.
If we need to iterate over JSMap/JSSet, use JSSetIterator/JSMapIterator instead of using
IteratorData directly.
* runtime/JSMap.cpp:
(JSC::JSMap::destroy):
* runtime/JSMap.h:
(JSC::JSMap::JSMap):
(JSC::JSMap::begin): Deleted.
(JSC::JSMap::end): Deleted.
* runtime/JSMapIterator.cpp:
(JSC::JSMapIterator::destroy):
* runtime/JSMapIterator.h:
(JSC::JSMapIterator::next):
(JSC::JSMapIterator::nextKeyValue):
(JSC::JSMapIterator::iteratorData):
(JSC::JSMapIterator::JSMapIterator):
* runtime/JSSet.cpp:
(JSC::JSSet::destroy):
* runtime/JSSet.h:
(JSC::JSSet::JSSet):
(JSC::JSSet::begin): Deleted.
(JSC::JSSet::end): Deleted.
* runtime/JSSetIterator.cpp:
(JSC::JSSetIterator::destroy):
* runtime/JSSetIterator.h:
(JSC::JSSetIterator::next):
(JSC::JSSetIterator::iteratorData):
(JSC::JSSetIterator::JSSetIterator):
* runtime/MapData.h:
(JSC::MapDataImpl::IteratorData::finish):
(JSC::MapDataImpl::IteratorData::isFinished):
(JSC::MapDataImpl::shouldPack):
(JSC::JSIterator>::MapDataImpl):
(JSC::JSIterator>::KeyType::KeyType):
(JSC::JSIterator>::IteratorData::IteratorData):
(JSC::JSIterator>::IteratorData::next):
(JSC::JSIterator>::IteratorData::ensureSlot):
(JSC::JSIterator>::IteratorData::applyMapDataPatch):
(JSC::JSIterator>::IteratorData::refreshCursor):
(JSC::MapDataImpl::const_iterator::key): Deleted.
(JSC::MapDataImpl::const_iterator::value): Deleted.
(JSC::MapDataImpl::const_iterator::operator++): Deleted.
(JSC::MapDataImpl::const_iterator::finish): Deleted.
(JSC::MapDataImpl::const_iterator::atEnd): Deleted.
(JSC::MapDataImpl::begin): Deleted.
(JSC::MapDataImpl::end): Deleted.
(JSC::MapDataImpl<Entry>::MapDataImpl): Deleted.
(JSC::MapDataImpl<Entry>::clear): Deleted.
(JSC::MapDataImpl<Entry>::KeyType::KeyType): Deleted.
(JSC::MapDataImpl<Entry>::const_iterator::internalIncrement): Deleted.
(JSC::MapDataImpl<Entry>::const_iterator::ensureSlot): Deleted.
(JSC::MapDataImpl<Entry>::const_iterator::const_iterator): Deleted.
(JSC::MapDataImpl<Entry>::const_iterator::~const_iterator): Deleted.
(JSC::MapDataImpl<Entry>::const_iterator::operator): Deleted.
(JSC::=): Deleted.
* runtime/MapDataInlines.h:
(JSC::JSIterator>::clear):
(JSC::JSIterator>::find):
(JSC::JSIterator>::contains):
(JSC::JSIterator>::add):
(JSC::JSIterator>::set):
(JSC::JSIterator>::get):
(JSC::JSIterator>::remove):
(JSC::JSIterator>::replaceAndPackBackingStore):
(JSC::JSIterator>::replaceBackingStore):
(JSC::JSIterator>::ensureSpaceForAppend):
(JSC::JSIterator>::visitChildren):
(JSC::JSIterator>::copyBackingStore):
(JSC::JSIterator>::applyMapDataPatch):
(JSC::MapDataImpl<Entry>::find): Deleted.
(JSC::MapDataImpl<Entry>::contains): Deleted.
(JSC::MapDataImpl<Entry>::add): Deleted.
(JSC::MapDataImpl<Entry>::set): Deleted.
(JSC::MapDataImpl<Entry>::get): Deleted.
(JSC::MapDataImpl<Entry>::remove): Deleted.
(JSC::MapDataImpl<Entry>::replaceAndPackBackingStore): Deleted.
(JSC::MapDataImpl<Entry>::replaceBackingStore): Deleted.
(JSC::MapDataImpl<Entry>::ensureSpaceForAppend): Deleted.
(JSC::MapDataImpl<Entry>::visitChildren): Deleted.
(JSC::MapDataImpl<Entry>::copyBackingStore): Deleted.
* runtime/MapPrototype.cpp:
(JSC::mapProtoFuncForEach):
* runtime/SetPrototype.cpp:
(JSC::setProtoFuncForEach):
* runtime/WeakGCMap.h:
(JSC::WeakGCMap::forEach):
* tests/stress/modify-map-during-iteration.js: Added.
(testValue):
(identityPairs):
(.set if):
(var):
(set map):
* tests/stress/modify-set-during-iteration.js: Added.
(testValue):
(set forEach):
(set delete):
2015-03-24 Mark Lam <mark.lam@apple.com>
The ExecutionTimeLimit test should use its own JSGlobalContextRef.
<https://webkit.org/b/143024>
Reviewed by Geoffrey Garen.
Currently, the ExecutionTimeLimit test is using a JSGlobalContextRef
passed in from testapi.c. It should create its own for better
encapsulation of the test.
* API/tests/ExecutionTimeLimitTest.cpp:
(currentCPUTimeAsJSFunctionCallback):
(testExecutionTimeLimit):
* API/tests/ExecutionTimeLimitTest.h:
* API/tests/testapi.c:
(main):
2015-03-24 Joseph Pecoraro <pecoraro@apple.com>
ES6: Object Literal Methods toString is missing method name
https://bugs.webkit.org/show_bug.cgi?id=142992
Reviewed by Geoffrey Garen.
Always stringify functions in the pattern:
"function " + <function name> + <text from opening parenthesis to closing brace>.
* runtime/FunctionPrototype.cpp:
(JSC::functionProtoFuncToString):
Update the path that was not stringifying in this pattern.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::parametersStartOffset):
* parser/Nodes.h:
* runtime/Executable.cpp:
(JSC::FunctionExecutable::FunctionExecutable):
* runtime/Executable.h:
(JSC::FunctionExecutable::parametersStartOffset):
Pass the already known function parameter opening parenthesis
start offset through to the FunctionExecutable.
* tests/mozilla/js1_5/Scope/regress-185485.js:
(with.g):
Add back original space in this test that was removed by r181810
now that we have the space again in stringification.
2015-03-24 Michael Saboff <msaboff@apple.com>
REGRESSION (172175-172177): Change in for...in processing causes properties added in loop to be enumerated
https://bugs.webkit.org/show_bug.cgi?id=142856
Reviewed by Filip Pizlo.
Refactored the way the for .. in enumeration over objects is done. We used to make three C++ calls to
get info for three loops to iterate over indexed properties, structure properties and other properties,
respectively. We still have the three loops, but now we make one C++ call to get all the info needed
for all loops before we exectue any enumeration.
The JSPropertyEnumerator has a count of the indexed properties and a list of named properties.
The named properties are one list, with structured properties in the range [0,m_endStructurePropertyIndex)
and the generic properties in the range [m_endStructurePropertyIndex, m_endGenericPropertyIndex);
Eliminated the bytecodes op_get_structure_property_enumerator, op_get_generic_property_enumerator and
op_next_enumerator_pname.
Added the bytecodes op_get_property_enumerator, op_enumerator_structure_pname and op_enumerator_generic_pname.
The bytecodes op_enumerator_structure_pname and op_enumerator_generic_pname are similar except for what
end value we stop iterating on.
Made corresponding node changes to the DFG and FTL for the bytecode changes.
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitGetPropertyEnumerator):
(JSC::BytecodeGenerator::emitEnumeratorStructurePropertyName):
(JSC::BytecodeGenerator::emitEnumeratorGenericPropertyName):
(JSC::BytecodeGenerator::emitGetStructurePropertyEnumerator): Deleted.
(JSC::BytecodeGenerator::emitGetGenericPropertyEnumerator): Deleted.
(JSC::BytecodeGenerator::emitNextEnumeratorPropertyName): Deleted.
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ForInNode::emitMultiLoopBytecode):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileGetEnumerableLength):
(JSC::FTL::LowerDFGToLLVM::compileGetPropertyEnumerator):
(JSC::FTL::LowerDFGToLLVM::compileGetEnumeratorStructurePname):
(JSC::FTL::LowerDFGToLLVM::compileGetEnumeratorGenericPname):
(JSC::FTL::LowerDFGToLLVM::compileGetStructurePropertyEnumerator): Deleted.
(JSC::FTL::LowerDFGToLLVM::compileGetGenericPropertyEnumerator): Deleted.
(JSC::FTL::LowerDFGToLLVM::compileGetEnumeratorPname): Deleted.
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_enumerator_structure_pname):
(JSC::JIT::emit_op_enumerator_generic_pname):
(JSC::JIT::emit_op_get_property_enumerator):
(JSC::JIT::emit_op_next_enumerator_pname): Deleted.
(JSC::JIT::emit_op_get_structure_property_enumerator): Deleted.
(JSC::JIT::emit_op_get_generic_property_enumerator): Deleted.
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_enumerator_structure_pname):
(JSC::JIT::emit_op_enumerator_generic_pname):
(JSC::JIT::emit_op_next_enumerator_pname): Deleted.
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* llint/LowLevelInterpreter.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* runtime/JSPropertyNameEnumerator.cpp:
(JSC::JSPropertyNameEnumerator::create):
(JSC::JSPropertyNameEnumerator::finishCreation):
* runtime/JSPropertyNameEnumerator.h:
(JSC::JSPropertyNameEnumerator::indexedLength):
(JSC::JSPropertyNameEnumerator::endStructurePropertyIndex):
(JSC::JSPropertyNameEnumerator::endGenericPropertyIndex):
(JSC::JSPropertyNameEnumerator::indexedLengthOffset):
(JSC::JSPropertyNameEnumerator::endStructurePropertyIndexOffset):
(JSC::JSPropertyNameEnumerator::endGenericPropertyIndexOffset):
(JSC::JSPropertyNameEnumerator::cachedInlineCapacityOffset):
(JSC::propertyNameEnumerator):
(JSC::JSPropertyNameEnumerator::cachedPropertyNamesLengthOffset): Deleted.
(JSC::structurePropertyNameEnumerator): Deleted.
(JSC::genericPropertyNameEnumerator): Deleted.
* runtime/Structure.cpp:
(JSC::Structure::setCachedPropertyNameEnumerator):
(JSC::Structure::cachedPropertyNameEnumerator):
(JSC::Structure::canCachePropertyNameEnumerator):
(JSC::Structure::setCachedStructurePropertyNameEnumerator): Deleted.
(JSC::Structure::cachedStructurePropertyNameEnumerator): Deleted.
(JSC::Structure::setCachedGenericPropertyNameEnumerator): Deleted.
(JSC::Structure::cachedGenericPropertyNameEnumerator): Deleted.
(JSC::Structure::canCacheStructurePropertyNameEnumerator): Deleted.
(JSC::Structure::canCacheGenericPropertyNameEnumerator): Deleted.
* runtime/Structure.h:
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::visitChildren):
(JSC::StructureRareData::cachedPropertyNameEnumerator):
(JSC::StructureRareData::setCachedPropertyNameEnumerator):
(JSC::StructureRareData::cachedStructurePropertyNameEnumerator): Deleted.
(JSC::StructureRareData::setCachedStructurePropertyNameEnumerator): Deleted.
(JSC::StructureRareData::cachedGenericPropertyNameEnumerator): Deleted.
(JSC::StructureRareData::setCachedGenericPropertyNameEnumerator): Deleted.
* runtime/StructureRareData.h:
* tests/stress/for-in-delete-during-iteration.js:
2015-03-24 Michael Saboff <msaboff@apple.com>
Unreviewed build fix for debug builds.
* runtime/ExceptionHelpers.cpp:
(JSC::invalidParameterInSourceAppender):
2015-03-24 Saam Barati <saambarati1@gmail.com>
Improve error messages in JSC
https://bugs.webkit.org/show_bug.cgi?id=141869
Reviewed by Geoffrey Garen.
JavaScriptCore has some unintuitive error messages associated
with certain common errors. This patch changes some specific
error messages to be more understandable and also creates a
mechanism that will allow for easy modification of error messages
in the future. The specific errors we change are not a function
errors and invalid parameter errors.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* interpreter/Interpreter.cpp:
(JSC::sizeOfVarargs):
* jit/JITOperations.cpp:
op_throw_static_error always has a JSString as its argument.
There is no need to dance around this, and we should assert
that this always holds. This JSString represents the error
message we want to display to the user, so there is no need
to pass it into errorDescriptionForValue which will now place
quotes around the string.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::opIn):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::ErrorInstance):
* runtime/ErrorInstance.h:
(JSC::ErrorInstance::hasSourceAppender):
(JSC::ErrorInstance::sourceAppender):
(JSC::ErrorInstance::setSourceAppender):
(JSC::ErrorInstance::clearSourceAppender):
(JSC::ErrorInstance::setRuntimeTypeForCause):
(JSC::ErrorInstance::runtimeTypeForCause):
(JSC::ErrorInstance::clearRuntimeTypeForCause):
(JSC::ErrorInstance::appendSourceToMessage): Deleted.
(JSC::ErrorInstance::setAppendSourceToMessage): Deleted.
(JSC::ErrorInstance::clearAppendSourceToMessage): Deleted.
* runtime/ExceptionHelpers.cpp:
(JSC::errorDescriptionForValue):
(JSC::defaultApproximateSourceError):
(JSC::defaultSourceAppender):
(JSC::functionCallBase):
(JSC::notAFunctionSourceAppender):
(JSC::invalidParameterInSourceAppender):
(JSC::invalidParameterInstanceofSourceAppender):
(JSC::createError):
(JSC::createInvalidFunctionApplyParameterError):
(JSC::createInvalidInParameterError):
(JSC::createInvalidInstanceofParameterError):
(JSC::createNotAConstructorError):
(JSC::createNotAFunctionError):
(JSC::createNotAnObjectError):
(JSC::createInvalidParameterError): Deleted.
* runtime/ExceptionHelpers.h:
* runtime/JSObject.cpp:
(JSC::JSObject::hasInstance):
* runtime/RuntimeType.cpp: Added.
(JSC::runtimeTypeForValue):
(JSC::runtimeTypeAsString):
* runtime/RuntimeType.h: Added.
* runtime/TypeProfilerLog.cpp:
(JSC::TypeProfilerLog::processLogEntries):
* runtime/TypeSet.cpp:
(JSC::TypeSet::getRuntimeTypeForValue): Deleted.
* runtime/TypeSet.h:
* runtime/VM.cpp:
(JSC::appendSourceToError):
(JSC::VM::throwException):
2015-03-23 Filip Pizlo <fpizlo@apple.com>
JSC should have a low-cost asynchronous disassembler
https://bugs.webkit.org/show_bug.cgi?id=142997
Reviewed by Mark Lam.
This adds a JSC_asyncDisassembly option that disassembles on a thread. Disassembly
doesn't block execution. Some code will live a little longer because of this, since the
work tasks hold a ref to the code, but other than that there is basically no overhead.
At present, this isn't really a replacement for JSC_showDisassembly, since it doesn't
provide contextual IR information for Baseline and DFG disassemblies, and it doesn't do
the separate IR dumps for FTL. Using JSC_showDisassembly and friends along with
JSC_asyncDisassembly has bizarre behavior - so just choose one.
A simple way of understanding how great this is, is to run a small benchmark like
V8Spider/earley-boyer.
Performance without any disassembly flags: 60ms
Performance with JSC_showDisassembly=true: 477ms
Performance with JSC_asyncDisassembly=true: 65ms
So, the overhead of disassembly goes from 8x to 8%.
Note that JSC_asyncDisassembly=true does make it incorrect to run "time" as a way of
measuring benchmark performance. This is because at VM exit, we wait for all async
disassembly requests to finish. For example, for earley-boyer, we spend an extra ~130ms
after the benchmark completely finishes to finish the disassemblies. This small weirdness
should be OK for the intended use-cases, since all you have to do to get around it is to
measure the execution time of the benchmark payload rather than the end-to-end time of
launching the VM.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::finalizeCodeWithDisassembly):
* assembler/LinkBuffer.h:
(JSC::LinkBuffer::wasAlreadyDisassembled):
(JSC::LinkBuffer::didAlreadyDisassemble):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::disassemble):
* dfg/DFGJITFinalizer.cpp:
(JSC::DFG::JITFinalizer::finalize):
(JSC::DFG::JITFinalizer::finalizeFunction):
* disassembler/Disassembler.cpp:
(JSC::disassembleAsynchronously):
(JSC::waitForAsynchronousDisassembly):
* disassembler/Disassembler.h:
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* jit/JIT.cpp:
(JSC::JIT::privateCompile):
* jsc.cpp:
* runtime/Options.h:
* runtime/VM.cpp:
(JSC::VM::~VM):
2015-03-23 Dean Jackson <dino@apple.com>
ES7: Implement Array.prototype.includes
https://bugs.webkit.org/show_bug.cgi?id=142707
Reviewed by Geoffrey Garen.
Add support for the ES7 includes method on Arrays.
https://github.com/tc39/Array.prototype.includes
* builtins/Array.prototype.js:
(includes): Implementation in JS.
* runtime/ArrayPrototype.cpp: Add 'includes' to the lookup table.
2015-03-23 Joseph Pecoraro <pecoraro@apple.com>
__defineGetter__/__defineSetter__ should throw exceptions
https://bugs.webkit.org/show_bug.cgi?id=142934
Reviewed by Geoffrey Garen.
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncDefineGetter):
(JSC::objectProtoFuncDefineSetter):
Throw exceptions when these functions are used directly.
2015-03-23 Joseph Pecoraro <pecoraro@apple.com>
Fix DO_PROPERTYMAP_CONSTENCY_CHECK enabled build
https://bugs.webkit.org/show_bug.cgi?id=142952
Reviewed by Geoffrey Garen.
* runtime/Structure.cpp:
(JSC::PropertyTable::checkConsistency):
The check offset method doesn't exist in PropertyTable, it exists in Structure.
(JSC::Structure::checkConsistency):
So move it here, and always put it at the start to match normal behavior.
2015-03-22 Filip Pizlo <fpizlo@apple.com>
Remove DFG::ValueRecoveryOverride; it's been dead since we removed forward speculations
https://bugs.webkit.org/show_bug.cgi?id=142956
Rubber stamped by Gyuyoung Kim.
Just removing dead code.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGOSRExit.h:
* dfg/DFGOSRExitCompiler.cpp:
* dfg/DFGValueRecoveryOverride.h: Removed.
2015-03-22 Filip Pizlo <fpizlo@apple.com>
DFG OSR exit shouldn't assume that the frame count for exit is greater than the frame count in DFG
https://bugs.webkit.org/show_bug.cgi?id=142948
Reviewed by Sam Weinig.
It's necessary to ensure that the stack pointer accounts for the extent of our stack usage
since a signal may clobber the area below the stack pointer. When the DFG is executing,
the stack pointer accounts for the DFG's worst-case stack usage. When we OSR exit back to
baseline, we will use a different amount of stack. This is because baseline is a different
compiler. It will make different decisions. So it will use a different amount of stack.
This gets tricky when we are in the process of doing an OSR exit, because we are sort of
incrementally transforming the stack from how it looked in the DFG to how it will look in
baseline. The most conservative approach would be to set the stack pointer to the max of
DFG and baseline.
When this code was written, a reckless assumption was made: that the stack usage in
baseline is always at least as large as the stack usage in DFG. Based on this incorrect
assumption, the code first adjusts the stack pointer to account for the baseline stack
usage. This sort of usually works, because usually baseline does happen to use more stack.
But that's not an invariant. Nobody guarantees this. We will never make any changes that
would make this be guaranteed, because that would be antithetical to how optimizing
compilers work. The DFG should be allowed to use however much stack it decides that it
should use in order to get good performance, and it shouldn't try to guarantee that it
always uses less stack than baseline.
As such, we must always assume that the frame size for DFG execution (i.e.
frameRegisterCount) and the frame size in baseline once we exit (i.e.
requiredRegisterCountForExit) are two independent quantities and they have no
relationship.
Fortunately, though, this code can be made correct by just moving the stack adjustment to
just before we do conversions. This is because we have since changed the OSR exit
algorithm to first lift up all state from the DFG state into a scratch buffer, and then to
drop it out of the scratch buffer and into the stack according to the baseline layout. The
point just before conversions is the point where we have finished reading the DFG frame
and will not read it anymore, and we haven't started writing the baseline frame. So, at
this point it is safe to set the stack pointer to account for the frame size at exit.
This is benign because baseline happens to create larger frames than DFG.
* dfg/DFGOSRExitCompiler32_64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompiler64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::adjustAndJumpToTarget):
2015-03-22 Filip Pizlo <fpizlo@apple.com>
Shorten the number of iterations to 10,000 since that's enough to test all tiers.
Rubber stamped by Sam Weinig.
* tests/stress/equals-masquerader.js:
2015-03-22 Filip Pizlo <fpizlo@apple.com>
tests/stress/*tdz* tests do 10x more iterations than necessary
https://bugs.webkit.org/show_bug.cgi?id=142946
Reviewed by Ryosuke Niwa.
The stress test harness runs all of these tests in various configurations. This includes
no-cjit, which has tier-up heuristics locked in such a way that 10,000 iterations is
enough to get to the highest tier. The only exceptions are very large functions or
functions that have some reoptimizations. That happens rarely, and when it does happen,
usually 20,000 iterations is enough.
Therefore, these tests use 10x too many iterations. This is bad, since these tests
allocate on each iteration, and so they run very slowly in debug mode.
* tests/stress/class-syntax-no-loop-tdz.js:
* tests/stress/class-syntax-no-tdz-in-catch.js:
* tests/stress/class-syntax-no-tdz-in-conditional.js:
* tests/stress/class-syntax-no-tdz-in-loop-no-inline-super.js:
* tests/stress/class-syntax-no-tdz-in-loop.js:
* tests/stress/class-syntax-no-tdz.js:
* tests/stress/class-syntax-tdz-in-catch.js:
* tests/stress/class-syntax-tdz-in-conditional.js:
* tests/stress/class-syntax-tdz-in-loop.js:
* tests/stress/class-syntax-tdz.js:
2015-03-21 Joseph Pecoraro <pecoraro@apple.com>
Fix a typo in Parser error message
https://bugs.webkit.org/show_bug.cgi?id=142942
Reviewed by Alexey Proskuryakov.
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitSlow_op_resolve_scope):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emitSlow_op_resolve_scope):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
Fix a common identifier typo.
2015-03-21 Joseph Pecoraro <pecoraro@apple.com>
Computed Property names should allow only AssignmentExpressions not any Expression
https://bugs.webkit.org/show_bug.cgi?id=142902
Reviewed by Ryosuke Niwa.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseProperty):
Limit computed expressions to just assignment expressions instead of
any expression (which allowed comma expressions).
2015-03-21 Andreas Kling <akling@apple.com>
Make UnlinkedFunctionExecutable fit in a 128-byte cell.
<https://webkit.org/b/142939>
Reviewed by Mark Hahnenberg.
Re-arrange the members of UnlinkedFunctionExecutable so it can fit inside
a 128-byte heap cell instead of requiring a 256-byte one.
Threw in a static_assert to catch anyone pushing it over the limit again.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::functionMode):
2015-03-20 Mark Hahnenberg <mhahnenb@gmail.com>
GCTimer should know keep track of nested GC phases
https://bugs.webkit.org/show_bug.cgi?id=142675
Reviewed by Darin Adler.
This improves the GC phase timing output in Heap.cpp by linking
phases nested inside other phases together, allowing tools
to compute how much time we're spending in various nested phases.
* heap/Heap.cpp:
2015-03-20 Geoffrey Garen <ggaren@apple.com>
FunctionBodyNode should known where its parameters started
https://bugs.webkit.org/show_bug.cgi?id=142926
Reviewed by Ryosuke Niwa.
This will allow us to re-parse parameters instead of keeping the
parameters piece of the AST around forever.
I also took the opportunity to initialize most FunctionBodyNode data
members at construction time, to help clarify that they are set right.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionExpr): No need to pass
functionKeywordStart here; we now provide it at FunctionBodyNode
creation time.
(JSC::ASTBuilder::createFunctionBody): Require everything we need at
construction time, including the start of our parameters.
(JSC::ASTBuilder::createGetterOrSetterProperty):
(JSC::ASTBuilder::createFuncDeclStatement): No need to pass
functionKeywordStart here; we now provide it at FunctionBodyNode
creation time.
(JSC::ASTBuilder::setFunctionNameStart): Deleted.
* parser/Nodes.cpp:
(JSC::FunctionBodyNode::FunctionBodyNode): Initialize everything at
construction time.
* parser/Nodes.h: Added a field for the location of our parameters.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionBody):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parsePropertyMethod):
(JSC::Parser<LexerType>::parseGetterSetter):
(JSC::Parser<LexerType>::parsePrimaryExpression):
* parser/Parser.h: Refactored to match above interface changes.
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionExpr):
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::createFuncDeclStatement):
(JSC::SyntaxChecker::createGetterOrSetterProperty): Refactored to match
above interface changes.
(JSC::SyntaxChecker::setFunctionNameStart): Deleted.
2015-03-20 Filip Pizlo <fpizlo@apple.com>
Observably effectful nodes in DFG IR should come last in their bytecode instruction (i.e. forExit section), except for Hint nodes
https://bugs.webkit.org/show_bug.cgi?id=142920
Reviewed by Oliver Hunt, Geoffrey Garen, and Mark Lam.
Observably effectful, n.: If we reexecute the bytecode instruction after this node has
executed, then something other than the bytecode instruction's specified outcome will
happen.
We almost never had observably effectful nodes except at the end of the bytecode
instruction. The exception is a lowered transitioning PutById:
PutStructure(@o, S1 -> S2)
PutByOffset(@o, @o, @v)
The PutStructure is observably effectful: if you try to reexecute the bytecode after
doing the PutStructure, then we'll most likely crash. The generic PutById handling means
first checking what the old structure of the object is; but if we reexecute, the old
structure will seem to be the new structure. But the property ensured by the new
structure hasn't been stored yet, so any attempt to load it or scan it will crash.
Intriguingly, however, none of the other operations involved in the PutById are
observably effectful. Consider this example:
PutByOffset(@o, @o, @v)
PutStructure(@o, S1 -> S2)
Note that the PutStructure node doesn't reallocate property storage; see further below
for an example that does that. Because no property storage is happening, we know that we
already had room for the new property. This means that the PutByOffset is no observable
until the PutStructure executes and "reveals" the property. Hence, PutByOffset is not
observably effectful.
Now consider this:
b: AllocatePropertyStorage(@o)
PutByOffset(@b, @o, @v)
PutStructure(@o, S1 -> S2)
Surprisingly, this is also safe, because the AllocatePropertyStorage is not observably
effectful. It *does* reallocate the property storage and the new property storage pointer
is stored into the object. But until the PutStructure occurs, the world will just think
that the reallocation didn't happen, in the sense that we'll think that the property
storage is using less memory than what we just allocated. That's harmless.
The AllocatePropertyStorage is safe in other ways, too. Even if we GC'd after the
AllocatePropertyStorage but before the PutByOffset (or before the PutStructure),
everything could be expected to be fine, so long as all of @o, @v and @b are on the
stack. If they are all on the stack, then the GC will leave the property storage alone
(so the extra memory we just allocated would be safe). The GC will not scan the part of
the property storage that contains @v, but that's fine, so long as @v is on the stack.
The better long-term solution is probably bug 142921.
But for now, this:
- Fixes an object materialization bug, exemplified by the two tests, that previously
crashed 100% of the time with FTL enabled and concurrent JIT disabled.
- Allows us to remove the workaround introduced in r174856.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handlePutById):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::insertCheck):
(JSC::DFG::FixupPhase::indexOfNode): Deleted.
(JSC::DFG::FixupPhase::indexOfFirstNodeOfExitOrigin): Deleted.
* dfg/DFGInsertionSet.h:
(JSC::DFG::InsertionSet::insertOutOfOrder): Deleted.
(JSC::DFG::InsertionSet::insertOutOfOrderNode): Deleted.
* tests/stress/materialize-past-butterfly-allocation.js: Added.
(bar):
(foo0):
(foo1):
(foo2):
(foo3):
(foo4):
* tests/stress/materialize-past-put-structure.js: Added.
(foo):
2015-03-20 Yusuke Suzuki <utatane.tea@gmail.com>
REGRESSION (r179429): Potential Use after free in JavaScriptCore`WTF::StringImpl::ref + 83
https://bugs.webkit.org/show_bug.cgi?id=142410
Reviewed by Geoffrey Garen.
Before this patch, added function JSValue::toPropertyKey returns PropertyName.
Since PropertyName doesn't have AtomicStringImpl ownership,
if Identifier is implicitly converted to PropertyName and Identifier is destructed,
PropertyName may refer freed AtomicStringImpl*.
This patch changes the result type of JSValue::toPropertyName from PropertyName to Identifier,
to keep AtomicStringImpl* ownership after the toPropertyName call is done.
And receive the result value as Identifier type to keep ownership in the caller side.
To catch the result of toPropertyKey as is, we catch the result of toPropertyName as auto.
However, now we don't need to have both Identifier and PropertyName.
So we'll merge PropertyName to Identifier in the subsequent patch.
* dfg/DFGOperations.cpp:
(JSC::DFG::operationPutByValInternal):
* jit/JITOperations.cpp:
(JSC::getByVal):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::getByVal):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::opIn):
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::toPropertyKey):
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorGetOwnPropertyDescriptor):
(JSC::objectConstructorDefineProperty):
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncPropertyIsEnumerable):
2015-03-18 Geoffrey Garen <ggaren@apple.com>
Function.prototype.toString should not decompile the AST
https://bugs.webkit.org/show_bug.cgi?id=142853
Reviewed by Sam Weinig.
To recover the function parameter string, Function.prototype.toString
decompiles the function parameters from the AST. This is bad for a few
reasons:
(1) It requires us to keep pieces of the AST live forever. This is an
awkward design and a waste of memory.
(2) It doesn't match Firefox or Chrome (because it changes whitespace
and ES6 destructuring expressions).
(3) It doesn't scale to ES6 default argument parameters, which require
arbitrarily complex decompilation.
(4) It can counterfeit all the line numbers in a function (because
whitespace can include newlines).
(5) It's expensive, and we've seen cases where websites invoke
Function.prototype.toString a lot by accident.
The fix is to do what we do for the rest of the function: Just quote the
original source text.
Since this change inevitably changes some function stringification, I
took the opportunity to make our stringification match Firefox's and
Chrome's.
* API/tests/testapi.c:
(assertEqualsAsUTF8String): Be more informative when this fails.
(main): Updated to match new stringification rules.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedFunctionExecutable::paramString): Deleted. Yay!
* bytecode/UnlinkedCodeBlock.h:
* parser/Nodes.h:
(JSC::StatementNode::isFuncDeclNode): New helper for constructing
anonymous functions.
* parser/SourceCode.h:
(JSC::SourceCode::SourceCode): Allow zero because WebCore wants it.
* runtime/CodeCache.cpp:
(JSC::CodeCache::getFunctionExecutableFromGlobalCode): Updated for use
of function declaration over function expression.
* runtime/Executable.cpp:
(JSC::FunctionExecutable::paramString): Deleted. Yay!
* runtime/Executable.h:
(JSC::FunctionExecutable::parameterCount):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck): Added a newline after
the opening brace to match Firefox and Chrome, and a space after the comma
to match Firefox and WebKit coding style. Added the function name to
the text of the function so it would look right when stringify-ing. Switched
from parentheses to braces to produce a function declaration instead of
a function expression because we are required to exclude the function's
name from its scope, and that's what a function declaration does.
* runtime/FunctionPrototype.cpp:
(JSC::functionProtoFuncToString): Removed an old workaround because the
library it worked around doesn't really exist anymore, and the behavior
doesn't match Firefox or Chrome. Use type profiling offsets instead of
function body offsets because we want to include the function name and
the parameter string, rather than stitching them in manually by
decompiling the AST.
(JSC::insertSemicolonIfNeeded): Deleted.
* tests/mozilla/js1_2/function/tostring-1.js:
* tests/mozilla/js1_5/Scope/regress-185485.js:
(with.g): Updated these test results for formatting changes.
2015-03-20 Joseph Pecoraro <pecoraro@apple.com>
SyntaxChecker assertion is trapped with computed property name and getter
https://bugs.webkit.org/show_bug.cgi?id=142863
Reviewed by Ryosuke Niwa.
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::getName):
Remove invalid assert. Computed properties will not have a name
and the calling code is checking for null expecting it. The
AST path (non-CheckingPath) already does this without the assert
so it is well tested.
2015-03-19 Mark Lam <mark.lam@apple.com>
JSCallbackObject<JSGlobalObject> should not destroy its JSCallbackObjectData before all its finalizers have been called.
<https://webkit.org/b/142846>
Reviewed by Geoffrey Garen.
Currently, JSCallbackObject<JSGlobalObject> registers weak finalizers via 2 mechanisms:
1. JSCallbackObject<Parent>::init() registers a weak finalizer for all JSClassRef
that a JSCallbackObject references.
2. JSCallbackObject<JSGlobalObject>::create() registers a finalizer via
vm.heap.addFinalizer() which destroys the JSCallbackObject.
The first finalizer is implemented as a virtual function of a JSCallbackObjectData
instance that will be destructed if the 2nd finalizer is called. Hence, if the
2nd finalizer if called first, the later invocation of the 1st finalizer will
result in a crash.
This patch fixes the issue by eliminating the finalizer registration in init().
Instead, we'll have the JSCallbackObject destructor call all the JSClassRef finalizers
if needed. This ensures that these finalizers are called before the JSCallbackObject
is destructor.
Also added assertions to a few Heap functions because JSCell::classInfo() expects
all objects that are allocated from MarkedBlock::Normal blocks to be derived from
JSDestructibleObject. These assertions will help us catch violations of this
expectation earlier.
* API/JSCallbackObject.cpp:
(JSC::JSCallbackObjectData::finalize): Deleted.
* API/JSCallbackObject.h:
(JSC::JSCallbackObjectData::~JSCallbackObjectData):
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::~JSCallbackObject):
(JSC::JSCallbackObject<Parent>::init):
* API/tests/GlobalContextWithFinalizerTest.cpp: Added.
(finalize):
(testGlobalContextWithFinalizer):
* API/tests/GlobalContextWithFinalizerTest.h: Added.
* API/tests/testapi.c:
(main):
* JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
* JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/HeapInlines.h:
(JSC::Heap::allocateObjectOfType):
(JSC::Heap::subspaceForObjectOfType):
(JSC::Heap::allocatorForObjectOfType):
2015-03-19 Andreas Kling <akling@apple.com>
JSCallee unnecessarily overrides a bunch of things in the method table.
<https://webkit.org/b/142855>
Reviewed by Geoffrey Garen.
Remove JSCallee method table overrides that simply call to base class.
This makes JSFunction property slot lookups slightly more efficient since
they can take the fast path when passing over JSCallee in the base class chain.
* runtime/JSCallee.cpp:
(JSC::JSCallee::getOwnPropertySlot): Deleted.
(JSC::JSCallee::getOwnNonIndexPropertyNames): Deleted.
(JSC::JSCallee::put): Deleted.
(JSC::JSCallee::deleteProperty): Deleted.
(JSC::JSCallee::defineOwnProperty): Deleted.
* runtime/JSCallee.h:
2015-03-19 Andreas Kling <akling@apple.com>
DFGAllocator should use bmalloc's aligned allocator.
<https://webkit.org/b/142871>
Reviewed by Geoffrey Garen.
Switch DFGAllocator to using bmalloc through fastAlignedMalloc().
* dfg/DFGAllocator.h:
(JSC::DFG::Allocator<T>::allocateSlow):
(JSC::DFG::Allocator<T>::freeRegionsStartingAt):
* heap/CopiedSpace.h:
* heap/MarkedBlock.h:
* heap/MarkedSpace.h:
2015-03-18 Joseph Pecoraro <pecoraro@apple.com>
ES6 Classes: Extends should accept an expression without parenthesis
https://bugs.webkit.org/show_bug.cgi?id=142840
Reviewed by Ryosuke Niwa.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
"extends" allows a LeftHandExpression (new expression / call expression,
which includes a member expression), not a primary expression. Our
parseMemberExpression does all of these.
2015-03-18 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Debugger Popovers and Probes should use FormattedValue/ObjectTreeView instead of Custom/ObjectPropertiesSection
https://bugs.webkit.org/show_bug.cgi?id=142830
Reviewed by Timothy Hatcher.
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::breakpointActionProbe):
Give Probe Samples object previews.
2015-03-17 Ryuan Choi <ryuan.choi@navercorp.com>
[EFL] Expose JavaScript binding interface through ewk_extension
https://bugs.webkit.org/show_bug.cgi?id=142033
Reviewed by Gyuyoung Kim.
* PlatformEfl.cmake: Install Javascript APIs.
2015-03-17 Geoffrey Garen <ggaren@apple.com>
Function bodies should always include braces
https://bugs.webkit.org/show_bug.cgi?id=142795
Reviewed by Michael Saboff.
Having a mode for excluding the opening and closing braces from a function
body was unnecessary and confusing.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock): Adopt the new one true linking function.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::codeBlockFor): No need to pass through
a boolean: there is only one kind of function now.
(JSC::UnlinkedFunctionExecutable::linkInsideExecutable): Deleted.
(JSC::UnlinkedFunctionExecutable::linkGlobalCode): Deleted. Let's only
have one way to do things. This removes the old mode that would pretend
that a function always started at column 1. That pretense was not true:
an attribute event listener does not necessarily start at column 1.
* bytecode/UnlinkedCodeBlock.h:
* generate-js-builtins: Adopt the new one true linking function.
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
(JSC::parse): needsReparsingAdjustment is always true now, so I removed it.
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces): Deleted. Removed unused stuff.
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck): Always provide a
leading space because that's what this function's comment says is required
for web compatibility. We used to fake this up after the fact when
stringifying, based on the bodyIncludesBraces flag, but that flag is gone now.
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString): No need to add braces and/or a space
after the fact -- we always have them now.
2015-03-17 Mark Lam <mark.lam@apple.com>
Refactor execution time limit tests out of testapi.c.
<https://webkit.org/b/142798>
Rubber stamped by Michael Saboff.
These tests were sometimes failing to time out on C loop builds. Let's
refactor them out of the big monolith that is testapi.c so that we can
reason more easily about them and make adjustments if needed.
* API/tests/ExecutionTimeLimitTest.cpp: Added.
(currentCPUTime):
(currentCPUTimeAsJSFunctionCallback):
(shouldTerminateCallback):
(cancelTerminateCallback):
(extendTerminateCallback):
(testExecutionTimeLimit):
* API/tests/ExecutionTimeLimitTest.h: Added.
* API/tests/testapi.c:
(main):
(currentCPUTime): Deleted.
(currentCPUTime_callAsFunction): Deleted.
(shouldTerminateCallback): Deleted.
(cancelTerminateCallback): Deleted.
(extendTerminateCallback): Deleted.
* JavaScriptCore.xcodeproj/project.pbxproj:
2015-03-17 Geoffrey Garen <ggaren@apple.com>
Built-in functions should know that they use strict mode
https://bugs.webkit.org/show_bug.cgi?id=142788
Reviewed by Mark Lam.
Even though all of our builtin functions use strict mode, the parser
thinks that they don't. This is because Executable::toStrictness treats
builtin-ness and strict-ness as mutually exclusive.
The fix is to disambiguate builtin-ness from strict-ness.
This bug is currently unobservable because of some other parser bugs. But
it causes lots of test failures once those other bugs are fixed.
* API/JSScriptRef.cpp:
(parseScript):
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createBuiltinExecutable): Adopt the new API
for a separate value to indicate builtin-ness vs strict-ness.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::codeBlockFor): Ditto.
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::toStrictness): Deleted. This function
was misleading since it pretended that no builtin function was ever
strict, which is the opposite of true.
* parser/Lexer.cpp:
(JSC::Lexer<T>::Lexer):
* parser/Lexer.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::Parser):
* parser/Parser.h:
(JSC::parse): Adopt the new API.
* parser/ParserModes.h: Added JSParserBuiltinMode, and tried to give
existing modes clearer names.
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode): Adopt the new API.
* runtime/CodeCache.h:
(JSC::SourceCodeKey::SourceCodeKey): Be sure to treat strict-ness and
bulitin-ness as separate pieces of the code cache key. We would not want
a user function to match a built-in function in the cache, even if they
agreed about strictness, since builtin functions have different lexing
rules.
* runtime/Completion.cpp:
(JSC::checkSyntax):
* runtime/Executable.cpp:
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::checkSyntax):
* runtime/Executable.h:
(JSC::FunctionExecutable::create):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock): Adopt the new API.
2015-03-16 Filip Pizlo <fpizlo@apple.com>
DFG IR shouldn't have a separate node for every kind of put hint that could be described using PromotedLocationDescriptor
https://bugs.webkit.org/show_bug.cgi?id=142769
Reviewed by Michael Saboff.
When we sink an object allocation, we need to have some way of tracking what stores would
have happened had the allocation not been sunk, so that we know how to rematerialize the
object on OSR exit. Prior to this change, trunk had two ways of describing such a "put
hint":
- The PutStrutureHint and PutByOffsetHint node types.
- The PromotedLocationDescriptor class, which has an enum with cases StructurePLoc and
NamedPropertyPLoc.
We also had ways of converting from a Node with those two node types to a
PromotedLocationDescriptor, and we had a way of converting a PromotedLocationDescriptor to
a Node.
This change removes the redundancy. We now have just one node type that corresponds to a
put hint, and it's called PutHint. It has a PromotedLocationDescriptor as metadata.
Converting between a PutHint node and a PromotedLocationDescriptor and vice-versa is now
trivial.
This means that if we add new kinds of sunken objects, we'll have less pro-forma to write
for the put hints to those objects. This is mainly to simplify the implementation of
arguments elimination in bug 141174.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
(JSC::DFG::Graph::mergeRelevantToOSR):
* dfg/DFGMayExit.cpp:
(JSC::DFG::mayExit):
* dfg/DFGNode.cpp:
(JSC::DFG::Node::convertToPutHint):
(JSC::DFG::Node::convertToPutStructureHint):
(JSC::DFG::Node::convertToPutByOffsetHint):
(JSC::DFG::Node::promotedLocationDescriptor):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasIdentifier):
(JSC::DFG::Node::hasPromotedLocationDescriptor):
(JSC::DFG::Node::convertToPutByOffsetHint): Deleted.
(JSC::DFG::Node::convertToPutStructureHint): Deleted.
* dfg/DFGNodeType.h:
* dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
(JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::ObjectAllocationSinkingPhase::run):
(JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
(JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGPromoteHeapAccess.h:
(JSC::DFG::promoteHeapAccess):
* dfg/DFGPromotedHeapLocation.cpp:
(JSC::DFG::PromotedHeapLocation::createHint):
* dfg/DFGPromotedHeapLocation.h:
(JSC::DFG::PromotedLocationDescriptor::imm1):
(JSC::DFG::PromotedLocationDescriptor::imm2):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::validateCPS):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
2015-03-17 Michael Saboff <msaboff@apple.com>
Windows X86-64 should use the fixed executable allocator
https://bugs.webkit.org/show_bug.cgi?id=142749
Reviewed by Filip Pizlo.
Added jit/ExecutableAllocatorFixedVMPool.cpp to Windows build.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* jit/ExecutableAllocatorFixedVMPool.cpp: Don't include unistd.h on Windows.
2015-03-17 Matt Baker <mattbaker@apple.com>
Web Inspector: Show rendering frames (and FPS) in Layout and Rendering timeline
https://bugs.webkit.org/show_bug.cgi?id=142029
Reviewed by Timothy Hatcher.
* inspector/protocol/Timeline.json:
Added new event type for runloop timeline records.
2015-03-16 Ryosuke Niwa <rniwa@webkit.org>
Enable ES6 classes by default
https://bugs.webkit.org/show_bug.cgi?id=142774
Reviewed by Gavin Barraclough.
Enabled the feature and unskipped tests.
* Configurations/FeatureDefines.xcconfig:
* tests/stress/class-syntax-no-loop-tdz.js:
* tests/stress/class-syntax-no-tdz-in-catch.js:
* tests/stress/class-syntax-no-tdz-in-conditional.js:
* tests/stress/class-syntax-no-tdz-in-loop-no-inline-super.js:
* tests/stress/class-syntax-no-tdz-in-loop.js:
* tests/stress/class-syntax-no-tdz.js:
* tests/stress/class-syntax-tdz-in-catch.js:
* tests/stress/class-syntax-tdz-in-conditional.js:
* tests/stress/class-syntax-tdz-in-loop.js:
* tests/stress/class-syntax-tdz.js:
2015-03-16 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Better Console Previews for Arrays / Small Objects
https://bugs.webkit.org/show_bug.cgi?id=142322
Reviewed by Timothy Hatcher.
* inspector/InjectedScriptSource.js:
Create deep valuePreviews for simple previewable objects,
such as arrays with 5 values, or basic objects with
3 properties.
2015-03-16 Ryosuke Niwa <rniwa@webkit.org>
Add support for default constructor
https://bugs.webkit.org/show_bug.cgi?id=142388
Reviewed by Filip Pizlo.
Added the support for default constructors. They're generated by ClassExprNode::emitBytecode
via BuiltinExecutables::createDefaultConstructor.
UnlinkedFunctionExecutable now has the ability to override SourceCode provided by the owner
executable. We can't make store SourceCode in UnlinkedFunctionExecutable since CodeCache can use
the same UnlinkedFunctionExecutable to generate code blocks for multiple functions.
Parser now has the ability to treat any function expression as a constructor of the kind specified
by m_defaultConstructorKind member variable.
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createDefaultConstructor): Added.
(JSC::BuiltinExecutables::createExecutableInternal): Generalized from createBuiltinExecutable.
Parse default constructors as normal non-builtin functions. Override SourceCode in the unlinked
function executable since the Miranda function's code is definitely not in the owner executable's
source code. That's the whole point.
* builtins/BuiltinExecutables.h:
(UnlinkedFunctionExecutable::createBuiltinExecutable): Added. Wraps createExecutableInternal.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::UnlinkedFunctionExecutable::linkInsideExecutable):
(JSC::UnlinkedFunctionExecutable::linkGlobalCode):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::symbolTable): Deleted.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitNewDefaultConstructor): Added.
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ClassExprNode::emitBytecode): Generate the default constructor if needed.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::Parser):
(JSC::Parser<LexerType>::parseFunctionInfo): Override ownerClassKind and assume the function as
a constructor if we're parsing a default constructor.
(JSC::Parser<LexerType>::parseClass): Allow omission of the class constructor.
* parser/Parser.h:
(JSC::parse):
2015-03-16 Alex Christensen <achristensen@webkit.org>
Progress towards CMake on Mac
https://bugs.webkit.org/show_bug.cgi?id=142747
Reviewed by Chris Dumez.
* CMakeLists.txt:
Include AugmentableInspectorController.h in CMake build.
2015-03-16 Csaba Osztrogonác <ossy@webkit.org>
[ARM] Enable generating idiv instructions if it is supported
https://bugs.webkit.org/show_bug.cgi?id=142725
Reviewed by Michael Saboff.
* assembler/ARMAssembler.h: Added sdiv and udiv implementation for ARM Traditional instruction set.
(JSC::ARMAssembler::sdiv):
(JSC::ARMAssembler::udiv):
* assembler/ARMv7Assembler.h: Use HAVE(ARM_IDIV_INSTRUCTIONS) instead of CPU(APPLE_ARMV7S).
* assembler/AbstractMacroAssembler.h:
(JSC::isARMv7IDIVSupported):
(JSC::optimizeForARMv7IDIVSupported):
(JSC::isARMv7s): Renamed to isARMv7IDIVSupported().
(JSC::optimizeForARMv7s): Renamed to optimizeForARMv7IDIVSupported().
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
2015-03-15 Filip Pizlo <fpizlo@apple.com>
DFG::PutStackSinkingPhase should eliminate GetStacks that have an obviously known source, and emit GetStacks when the stack's value is needed and none is deferred
https://bugs.webkit.org/show_bug.cgi?id=141624
Reviewed by Geoffrey Garen.
Not eliminating GetStacks was an obvious omission from the original PutStackSinkingPhase.
Previously, we would treat GetStacks conservatively and assume that the stack slot
escaped. That's pretty dumb, since a GetStack is a local load of the stack. This change
makes GetStack a no-op from the standpoint of this phase's deferral analysis. At the end
we either keep the GetStack (if there was no concrete deferral) or we replace it with an
identity over the value that would have been stored by the deferred PutStack. Note that
this might be a Phi that the phase creates, so this is strictly stronger than what GCSE
could do.
But this change revealed the fact that this phase never correctly handled side effects in
case that we had done a GetStack, then a side-effect, and then found ourselves wanting the
value on the stack due to (for example) a Phi on a deferred PutStack and that GetStack.
Basically, it's only correct to use the SSA converter's incoming value mapping if we have
a concrete deferral - since anything but a concrete deferral may imply that the value has
been clobbered.
This has no performance change. I believe that the bug was previously benign because we
have so few operations that clobber the stack anymore, and most of those get used in a
very idiomatic way. The GetStack elimination will be very useful for the varargs
simplification that is part of bug 141174.
This includes a test for the case that Speedometer hit, plus tests for the other cases I
thought of once I realized the deeper issue.
* dfg/DFGPutStackSinkingPhase.cpp:
* tests/stress/get-stack-identity-due-to-sinking.js: Added.
(foo):
(bar):
* tests/stress/get-stack-mapping-with-dead-get-stack.js: Added.
(bar):
(foo):
* tests/stress/get-stack-mapping.js: Added.
(bar):
(foo):
* tests/stress/weird-put-stack-varargs.js: Added.
(baz):
(foo):
(fuzz):
(bar):
2015-03-16 Joseph Pecoraro <pecoraro@apple.com>
Update Map/Set to treat -0 and 0 as the same value
https://bugs.webkit.org/show_bug.cgi?id=142709
Reviewed by Csaba Osztrogonác.
* runtime/MapData.h:
(JSC::MapDataImpl<Entry>::KeyType::KeyType):
No longer special case -0. It will be treated as the same as 0.
2015-03-15 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Better handle displaying -0
https://bugs.webkit.org/show_bug.cgi?id=142708
Reviewed by Timothy Hatcher.
Modeled after a blink change:
Patch by <aandrey@chromium.org>
DevTools: DevTools: Show -0 for negative zero in console
https://src.chromium.org/viewvc/blink?revision=162605&view=revision
* inspector/InjectedScriptSource.js:
When creating a description string, or preview value string
for -0, be sure the string is "-0" and not "0".
2015-03-14 Ryosuke Niwa <rniwa@webkit.org>
parseClass should popScope after pushScope
https://bugs.webkit.org/show_bug.cgi?id=142689
Reviewed by Benjamin Poulain.
Pop the parser scope as needed.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
2015-03-14 Dean Jackson <dino@apple.com>
Feature flag for Animations Level 2
https://bugs.webkit.org/show_bug.cgi?id=142699
<rdar://problem/20165097>
Reviewed by Brent Fulgham.
Add ENABLE_CSS_ANIMATIONS_LEVEL_2 and a runtime flag animationTriggersEnabled.
* Configurations/FeatureDefines.xcconfig:
2015-03-14 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r181487.
https://bugs.webkit.org/show_bug.cgi?id=142695
Caused Speedometer/Full.html to fail (Requested by smfr on
#webkit).
Reverted changeset:
"DFG::PutStackSinkingPhase should eliminate GetStacks that
have an obviously known source"
https://bugs.webkit.org/show_bug.cgi?id=141624
http://trac.webkit.org/changeset/181487
2015-03-14 Michael Saboff <msaboff@apple.com>
ES6: Add binary and octal literal support
https://bugs.webkit.org/show_bug.cgi?id=142681
Reviewed by Ryosuke Niwa.
Added a binary literal parser function, parseBinary(), to Lexer patterned after the octal parser.
Refactored the parseBinary, parseOctal and parseDecimal to use a constant size for the number of
characters to try and handle directly. Factored out the shifting past any prefix to be handled by
the caller. Added binary and octal parsing to toDouble() via helper functions.
* parser/Lexer.cpp:
(JSC::Lexer<T>::parseHex):
(JSC::Lexer<T>::parseBinary):
(JSC::Lexer<T>::parseOctal):
(JSC::Lexer<T>::parseDecimal):
(JSC::Lexer<T>::lex):
* parser/Lexer.h:
* parser/ParserTokens.h:
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::jsBinaryIntegerLiteral):
(JSC::jsOctalIntegerLiteral):
(JSC::toDouble):
2015-03-13 Alex Christensen <achristensen@webkit.org>
Progress towards CMake on Mac.
https://bugs.webkit.org/show_bug.cgi?id=142680
Reviewed by Gyuyoung Kim.
* PlatformMac.cmake:
Generate TracingDtrace.h based on project.pbxproj.
2015-03-13 Filip Pizlo <fpizlo@apple.com>
Object allocation sinking phase shouldn't re-decorate previously sunken allocations on each fixpoint operation
https://bugs.webkit.org/show_bug.cgi?id=142686
Reviewed by Oliver Hunt.
Just because promoteHeapAccess() notifies us of an effect to a heap location in a node doesn't
mean that we should handle it as if it was for one of our sinking candidates. Instead we should
prune based on m_sinkCandidates.
This fixes a benign bug where we would generate a lot of repeated IR for some pathological
tests.
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
2015-03-13 Eric Carlson <eric.carlson@apple.com>
[Mac] Enable WIRELESS_PLAYBACK_TARGET
https://bugs.webkit.org/show_bug.cgi?id=142635
Reviewed by Darin Adler.
* Configurations/FeatureDefines.xcconfig:
2015-03-13 Ryosuke Niwa <rniwa@webkit.org>
Class constructor should throw TypeError when "called"
https://bugs.webkit.org/show_bug.cgi?id=142566
Reviewed by Michael Saboff.
Added ConstructorKind::None to denote code that doesn't belong to an ES6 class.
This allows BytecodeGenerator to emit code to throw TypeError when generating code block
to call ES6 class constructors.
Most of changes are about increasing the number of bits to store ConstructorKind from one
bit to two bits.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::ExecutableInfo::ExecutableInfo):
(JSC::ExecutableInfo::needsActivation):
(JSC::ExecutableInfo::usesEval):
(JSC::ExecutableInfo::isStrictMode):
(JSC::ExecutableInfo::isConstructor):
(JSC::ExecutableInfo::isBuiltinFunction):
(JSC::ExecutableInfo::constructorKind):
(JSC::UnlinkedFunctionExecutable::constructorKind):
(JSC::UnlinkedCodeBlock::constructorKind):
(JSC::UnlinkedFunctionExecutable::constructorKindIsDerived): Deleted.
(JSC::UnlinkedCodeBlock::constructorKindIsDerived): Deleted.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate): Don't emit bytecode when we had already emitted code
to throw TypeError.
(JSC::BytecodeGenerator::BytecodeGenerator): Emit code to throw TypeError when generating
code to call.
(JSC::BytecodeGenerator::emitReturn):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::constructorKind):
(JSC::BytecodeGenerator::constructorKindIsDerived): Deleted.
* bytecompiler/NodesCodegen.cpp:
(JSC::ThisNode::emitBytecode):
(JSC::FunctionCallValueNode::emitBytecode):
* parser/Nodes.cpp:
(JSC::FunctionBodyNode::FunctionBodyNode):
* parser/Nodes.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionInfo): Renamed the incoming function argument to
ownerClassKind. Set constructorKind to Base or Derived only if we're parsing a constructor.
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseClass): Don't parse static methods using MethodMode since that
would result in BytecodeGenerator erroneously treating static method named "constructor" as
a class constructor.
(JSC::Parser<LexerType>::parsePropertyMethod):
(JSC::Parser<LexerType>::parsePrimaryExpression):
* parser/Parser.h:
* parser/ParserModes.h:
* runtime/Executable.h:
(JSC::EvalExecutable::executableInfo):
(JSC::ProgramExecutable::executableInfo):
2015-03-13 Filip Pizlo <fpizlo@apple.com>
DFG::PutStackSinkingPhase should eliminate GetStacks that have an obviously known source
https://bugs.webkit.org/show_bug.cgi?id=141624
Reviewed by Oliver Hunt.
This was an obvious omission from the original PutStackSinkingPhase. Previously, we would treat
GetStacks conservatively and assume that the stack slot escaped. That's pretty dumb, since a
GetStack is a local load of the stack. This change makes GetStack a no-op from the standpoint of
this phase's deferral analysis. At the end we either keep the GetStack (if there was no concrete
deferral) or we replace it with an identity over the value that would have been stored by the
deferred PutStack. Note that this might be a Phi that the phase creates, so this is strictly
stronger than what GCSE could do.
This is probably not a speed-up now, but it will be very useful for the varargs simplification
done in bug 141174.
* dfg/DFGPutStackSinkingPhase.cpp:
2015-03-12 Geoffrey Garen <ggaren@apple.com>
Prohibit GC while sweeping
https://bugs.webkit.org/show_bug.cgi?id=142638
Reviewed by Andreas Kling.
I noticed in https://bugs.webkit.org/show_bug.cgi?id=142636 that a GC
could trigger a sweep which could trigger another GC. Yo Dawg.
I tried to figure out whether this could cause problems or not and it
made me cross-eyed.
(Some clients like to report extra memory cost during deallocation as a
way to indicate that the GC now owns something exclusively. It's
arguably a bug to communicate with the GC in this way, but we shouldn't
do crazy when this happens.)
This patch makes explicit the fact that we don't allow GC while sweeping.
Usually, sweeping implicitly defers GC by virtue of happening during
allocation. But not always.
* heap/Heap.cpp:
(JSC::Heap::collectAllGarbage): Defer GC while sweeping due to an
explicit GC request.
(JSC::Heap::didFinishCollection): Make sure that zombifying sweep
defers GC by not returning to the non-GC state until we're all done.
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::sweepNextBlock): Defer GC while sweeping due
to a timer.
2015-03-13 Mark Lam <mark.lam@apple.com>
Replace TCSpinLock with a new WTF::SpinLock based on WTF::Atomic.
<https://webkit.org/b/142674>
Reviewed by Filip Pizlo.
* API/JSValue.mm:
(handerForStructTag):
* API/JSWrapperMap.mm:
* dfg/DFGCommon.cpp:
(JSC::DFG::startCrashing):
(JSC::DFG::isCrashing):
- Changed to use a StaticSpinLock since that's what this code was trying to do
anyway.
* heap/CopiedBlock.h:
(JSC::CopiedBlock::CopiedBlock):
* heap/CopiedSpace.cpp:
(JSC::CopiedSpace::CopiedSpace):
* heap/CopiedSpace.h:
* heap/GCThreadSharedData.cpp:
(JSC::GCThreadSharedData::GCThreadSharedData):
* heap/GCThreadSharedData.h:
* heap/ListableHandler.h:
(JSC::ListableHandler::List::List):
* parser/SourceProvider.cpp:
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::addDatabaseToAtExit):
(JSC::Profiler::Database::removeDatabaseFromAtExit):
(JSC::Profiler::Database::removeFirstAtExitDatabase):
2015-03-13 Ryosuke Niwa <rniwa@webkit.org>
BytecodeGenerator needs to be re-entrant to support miranda functions
https://bugs.webkit.org/show_bug.cgi?id=142627
Reviewed by Filip Pizlo.
Made CodeCache::getGlobalCodeBlock and CodeCache::getFunctionExecutableFromGlobalCode re-entrant
by not keeping AddResult while invoking BytecodeGenerator::generate.
This is needed to support Miranda functions since they need to be lazily initialized.
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
(JSC::CodeCacheMap::findCacheAndUpdateAge): Extracted from add.
(JSC::CodeCacheMap::addCache): Extracted from add.
(JSC::CodeCacheMap::add): Deleted.
2015-03-13 Mark Lam <mark.lam@apple.com>
Introduce WTF::Atomic to wrap std::atomic for a friendlier CAS.
<https://webkit.org/b/142661>
Reviewed by Filip Pizlo.
Changed CodeBlock, and the DFG's crashLock to use WTF::Atomic instead of
std::atomic.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::visitAggregate):
* bytecode/CodeBlock.h:
* dfg/DFGCommon.cpp:
(JSC::DFG::startCrashing):
2015-03-12 Mark Lam <mark.lam@apple.com>
Change the DFG crashLock to use std::atomic.
<https://webkit.org/b/142649>
Reviewed by Filip Pizlo.
* dfg/DFGCommon.cpp:
(JSC::DFG::startCrashing):
(JSC::DFG::isCrashing):
2015-03-12 Filip Pizlo <fpizlo@apple.com>
Bytecode liveness analysis should have more lambdas and fewer sets
https://bugs.webkit.org/show_bug.cgi?id=142647
Reviewed by Mark Lam.
In bug 141174 I'll need to identify all of the bytecode kill sites. This requires hooking into
the bytecode analysis' stepOverFunction method, except in such a way that we observe uses that
are not in outs. This refactors stepOverFunction so that you can pass it use/def functors that
can either be used to propagate outs (as we do right now) or to additionally detect kills or
whatever else.
In order to achieve this, the liveness analysis was moved off of maintaining uses/defs
bitvectors. This wasn't helping the abstraction and was probably inefficient. The new code
should be a bit faster since we don't have to clear uses/defs bitvectors on each instruction. On
the other hand, being able to intercept each use means that our code for exception handlers is
no longer a bitwise-merge; it requires finding set bits. Fortunately, this code only kicks in
for instructions inside a try, and its performance is O(live at catch), so that's probably not
bad.
* bytecode/BytecodeLivenessAnalysis.cpp:
(JSC::indexForOperand):
(JSC::stepOverInstruction):
(JSC::computeLocalLivenessForBytecodeOffset):
(JSC::BytecodeLivenessAnalysis::computeFullLiveness):
(JSC::setForOperand): Deleted.
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
2015-03-12 Ryosuke Niwa <rniwa@webkit.org>
"this" should be in TDZ until super is called in the constructor of a derived class
https://bugs.webkit.org/show_bug.cgi?id=142527
Reviewed by Mark Hahnenberg.
DFG and FTL implementations co-authored by Filip Pizlo.
In ES6 class syntax, "this" register must be in the "temporal dead zone" (TDZ) and throw ReferenceError until
super() is called inside the constructor of a derived class.
Added op_check_tdz, a new OP code, which throws a reference error when the first operand is an empty value
to all tiers of JIT and LLint. The op code throws in the slow path on the basis that a TDZ error should be
a programming error and not a part of the programs' normal control flow. In DFG, this op code is represented
by a no-op must-generate node CheckNotEmpty modeled after CheckCell.
Also made the constructor of a derived class assign the empty value to "this" register rather than undefined
so that ThisNode can emit the op_check_tdz to check the initialized-ness of "this" in such a constructor.
* bytecode/BytecodeList.json: Added op_check_tdz.
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset): Ditto.
(JSC::computeDefsForBytecodeOffset): Ditto.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode): Ditto.
* bytecode/ExitKind.cpp:
(JSC::exitKindToString): Added TDZFailure.
* bytecode/ExitKind.h: Ditto.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator): Assign the empty value to "this" register to indicate it's in TDZ.
(JSC::BytecodeGenerator::emitTDZCheck): Added.
(JSC::BytecodeGenerator::emitReturn): Emit the TDZ check since "this" can still be in TDZ if super() was never
called. e.g. class B extends A { constructor() { } }
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ThisNode::emitBytecode): Always emit the TDZ check if we're inside the constructor of a derived class.
We can't omit this check even if the result was ignored per spec.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Previously, empty value could never appear
in a local variable. This is no longer true so generalize this code. Also added the support for CheckNotEmpty.
Like CheckCell, we phantomize this DFG node in the constant folding phase if the type of the operand is already
found to be not empty. Otherwise filter out SpecEmpty.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock): Added op_check_tdz.
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel): op_check_tdz can be compiled and inlined.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize): CheckNotEmpty doesn't read or write values.
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants): Convert CheckNotEmpty to a phantom if non-emptiness had already
been proven for the operand prior to this node.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC): CheckNotEmpty does not trigger GC.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode): CheckNotEmpty is a no-op in the fixup phase.
* dfg/DFGNodeType.h: CheckNotEmpty cannot be removed even if the result was ignored. See ThisNode::emitBytecode.
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate): CheckNotEmpty doesn't return any value.
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute): CheckNotEmpty doesn't load from heap so it's safe.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile): Speculative the operand to be not empty. OSR exit if the speculation fails.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile): Ditto.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile): CheckNotEmpty can be compiled in FTL.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode): Calls compileCheckNotEmpty for CheckNotEmpty.
(JSC::FTL::LowerDFGToLLVM::compileCheckNotEmpty): OSR exit with "TDZFailure" if the operand is not empty.
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass): Added op_check_tdz.
(JSC::JIT::privateCompileSlowCases): Ditto.
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_check_tdz): Implements op_check_tdz in Baseline JIT.
(JSC::JIT::emitSlow_op_check_tdz): Ditto.
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_check_tdz): Ditto.
(JSC::JIT::emitSlow_op_check_tdz): Ditto.
* llint/LowLevelInterpreter32_64.asm: Implements op_check_tdz in LLint.
* llint/LowLevelInterpreter64.asm: Ditto.
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL): Throws a reference error for op_check_tdz. Shared by LLint and Baseline JIT.
* runtime/CommonSlowPaths.h:
* tests/stress/class-syntax-no-loop-tdz.js: Added.
* tests/stress/class-syntax-no-tdz-in-catch.js: Added.
* tests/stress/class-syntax-no-tdz-in-conditional.js: Added.
* tests/stress/class-syntax-no-tdz-in-loop-no-inline-super.js: Added.
* tests/stress/class-syntax-no-tdz-in-loop.js: Added.
* tests/stress/class-syntax-no-tdz.js: Added.
* tests/stress/class-syntax-tdz-in-catch.js: Added.
* tests/stress/class-syntax-tdz-in-conditional.js: Added.
* tests/stress/class-syntax-tdz-in-loop.js: Added.
* tests/stress/class-syntax-tdz.js: Added.
2015-03-12 Yusuke Suzuki <utatane.tea@gmail.com>
Integrate MapData into JSMap and JSSet
https://bugs.webkit.org/show_bug.cgi?id=142556
Reviewed by Filip Pizlo.
This patch integrates MapData into JSMap and JSSet.
This removes 2 object allocation per one JSMap / JSSet.
MapDataImpl is specialized into MapData and SetData.
In the case of SetData, it does not have the dummy values
previously stored in the MapDataImpl. So the storage size of SetData
becomes the half of the previous implementation.
And now MapData and SetData are completely integrated into JSMap and JSSet,
these structures are not exposed to the other code even in WebCore world.
And at the same time, this patch fixes missing destroy functions
in JSMapIterator and JSSetIterator.
They are needed because MapData::const_iterator is a non-trivial destructor.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/JSMap.cpp:
(JSC::JSMap::destroy):
(JSC::JSMap::visitChildren):
(JSC::JSMap::copyBackingStore):
(JSC::JSMap::has):
(JSC::JSMap::size):
(JSC::JSMap::get):
(JSC::JSMap::set):
(JSC::JSMap::clear):
(JSC::JSMap::remove):
(JSC::JSMap::finishCreation): Deleted.
* runtime/JSMap.h:
(JSC::JSMap::Entry::key):
(JSC::JSMap::Entry::value):
(JSC::JSMap::Entry::visitChildren):
(JSC::JSMap::Entry::setKey):
(JSC::JSMap::Entry::setKeyWithoutWriteBarrier):
(JSC::JSMap::Entry::setValue):
(JSC::JSMap::Entry::clear):
(JSC::JSMap::begin):
(JSC::JSMap::end):
(JSC::JSMap::JSMap):
(JSC::JSMap::mapData): Deleted.
* runtime/JSMapIterator.cpp:
(JSC::JSMapIterator::finishCreation):
(JSC::JSMapIterator::destroy):
(JSC::JSMapIterator::visitChildren):
* runtime/JSMapIterator.h:
(JSC::JSMapIterator::JSMapIterator):
* runtime/JSSet.cpp:
(JSC::JSSet::destroy):
(JSC::JSSet::visitChildren):
(JSC::JSSet::copyBackingStore):
(JSC::JSSet::has):
(JSC::JSSet::size):
(JSC::JSSet::add):
(JSC::JSSet::clear):
(JSC::JSSet::remove):
(JSC::JSSet::finishCreation): Deleted.
* runtime/JSSet.h:
(JSC::JSSet::Entry::key):
(JSC::JSSet::Entry::value):
(JSC::JSSet::Entry::visitChildren):
(JSC::JSSet::Entry::setKey):
(JSC::JSSet::Entry::setKeyWithoutWriteBarrier):
(JSC::JSSet::Entry::setValue):
(JSC::JSSet::Entry::clear):
(JSC::JSSet::begin):
(JSC::JSSet::end):
(JSC::JSSet::JSSet):
(JSC::JSSet::mapData): Deleted.
* runtime/JSSetIterator.cpp:
(JSC::JSSetIterator::finishCreation):
(JSC::JSSetIterator::visitChildren):
(JSC::JSSetIterator::destroy):
* runtime/JSSetIterator.h:
(JSC::JSSetIterator::JSSetIterator):
* runtime/MapConstructor.cpp:
(JSC::constructMap):
* runtime/MapData.h:
(JSC::MapDataImpl::const_iterator::key):
(JSC::MapDataImpl::const_iterator::value):
(JSC::MapDataImpl::size):
(JSC::MapDataImpl<Entry>::MapDataImpl):
(JSC::MapDataImpl<Entry>::clear):
(JSC::MapDataImpl<Entry>::KeyType::KeyType):
(JSC::MapDataImpl<Entry>::const_iterator::internalIncrement):
(JSC::MapDataImpl<Entry>::const_iterator::ensureSlot):
(JSC::MapDataImpl<Entry>::const_iterator::const_iterator):
(JSC::MapDataImpl<Entry>::const_iterator::~const_iterator):
(JSC::MapDataImpl<Entry>::const_iterator::operator):
(JSC::=):
(JSC::MapData::const_iterator::key): Deleted.
(JSC::MapData::const_iterator::value): Deleted.
(JSC::MapData::create): Deleted.
(JSC::MapData::createStructure): Deleted.
(JSC::MapData::size): Deleted.
(JSC::MapData::clear): Deleted.
(JSC::MapData::KeyType::KeyType): Deleted.
(JSC::MapData::const_iterator::internalIncrement): Deleted.
(JSC::MapData::const_iterator::ensureSlot): Deleted.
(JSC::MapData::const_iterator::const_iterator): Deleted.
(JSC::MapData::const_iterator::~const_iterator): Deleted.
(JSC::MapData::const_iterator::operator*): Deleted.
(JSC::MapData::const_iterator::end): Deleted.
(JSC::MapData::const_iterator::operator!=): Deleted.
(JSC::MapData::const_iterator::operator==): Deleted.
* runtime/MapDataInlines.h: Renamed from Source/JavaScriptCore/runtime/MapData.cpp.
(JSC::MapDataImpl<Entry>::find):
(JSC::MapDataImpl<Entry>::contains):
(JSC::MapDataImpl<Entry>::add):
(JSC::MapDataImpl<Entry>::set):
(JSC::MapDataImpl<Entry>::get):
(JSC::MapDataImpl<Entry>::remove):
(JSC::MapDataImpl<Entry>::replaceAndPackBackingStore):
(JSC::MapDataImpl<Entry>::replaceBackingStore):
(JSC::MapDataImpl<Entry>::ensureSpaceForAppend):
(JSC::MapDataImpl<Entry>::visitChildren):
(JSC::MapDataImpl<Entry>::copyBackingStore):
* runtime/MapPrototype.cpp:
(JSC::getMap):
(JSC::mapProtoFuncClear):
(JSC::mapProtoFuncDelete):
(JSC::mapProtoFuncForEach):
(JSC::mapProtoFuncGet):
(JSC::mapProtoFuncHas):
(JSC::mapProtoFuncSet):
(JSC::mapProtoFuncSize):
(JSC::getMapData): Deleted.
* runtime/SetPrototype.cpp:
(JSC::getSet):
(JSC::setProtoFuncAdd):
(JSC::setProtoFuncClear):
(JSC::setProtoFuncDelete):
(JSC::setProtoFuncForEach):
(JSC::setProtoFuncHas):
(JSC::setProtoFuncSize):
(JSC::getMapData): Deleted.
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2015-03-12 Mark Lam <mark.lam@apple.com>
Use std::atomic for CodeBlock::m_visitAggregateHasBeenCalled.
<https://webkit.org/b/142640>
Reviewed by Mark Hahnenberg.
We used to spin our own compare and swap on a uint8_t. Now that we can
use C++11, let's use std::atomic instead.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::visitAggregate):
- The CAS here needs std::memory_order_acquire ordering because it
requires lock acquisition semantics to visit the CodeBlock.
* bytecode/CodeBlock.h:
(JSC::CodeBlockSet::mark):
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::clearMarksForFullCollection):
(JSC::CodeBlockSet::clearMarksForEdenCollection):
- These can go with relaxed ordering because they are all done before
the GC starts parallel marking.
2015-03-12 Csaba Osztrogonác <ossy@webkit.org>
[cmake] Fix the incremental build issue revealed by r181419
https://bugs.webkit.org/show_bug.cgi?id=142613
Reviewed by Carlos Garcia Campos.
* CMakeLists.txt:
2015-03-11 Ryosuke Niwa <rniwa@webkit.org>
"static" should not be a reserved keyword in non-strict mode even when ES6 class is enabled
https://bugs.webkit.org/show_bug.cgi?id=142600
Reviewed by Mark Lam.
Make "static" RESERVED_IF_STRICT and manually detect it in parseClass.
No new tests. This is already checked by js/reserved-words.html and js/keywords-and-reserved_words.html
* parser/Keywords.table:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
* parser/ParserTokens.h:
2015-03-11 Geoffrey Garen <ggaren@apple.com>
Many users of Heap::reportExtraMemory* are wrong, causing lots of memory growth
https://bugs.webkit.org/show_bug.cgi?id=142593
Reviewed by Andreas Kling.
Adopt deprecatedReportExtraMemory as a short-term fix for runaway
memory growth in these cases where we have not adopted
reportExtraMemoryVisited.
Long-term, we should use reportExtraMemoryAllocated+reportExtraMemoryVisited.
That's tracked by https://bugs.webkit.org/show_bug.cgi?id=142595.
* API/JSBase.cpp:
(JSReportExtraMemoryCost):
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::add):
2015-03-11 Geoffrey Garen <ggaren@apple.com>
Refactored the JSC::Heap extra cost API for clarity and to make some known bugs more obvious
https://bugs.webkit.org/show_bug.cgi?id=142589
Reviewed by Andreas Kling.
* API/JSBase.cpp:
(JSReportExtraMemoryCost): Added a FIXME to annotate a known bug.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::visitAggregate):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::setJITCode): Updated for rename.
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::reportExtraMemoryAllocatedSlowCase):
(JSC::Heap::deprecatedReportExtraMemorySlowCase): Renamed our reporting
APIs to clarify their relationship to each other: One must report extra
memory at the time of allocation, and at the time the GC visits it.
(JSC::Heap::extraMemorySize):
(JSC::Heap::size):
(JSC::Heap::capacity):
(JSC::Heap::sizeAfterCollect):
(JSC::Heap::willStartCollection): Updated for renames. Added explicit
API for deprecated users who can't use our best API.
(JSC::Heap::reportExtraMemoryCostSlowCase): Deleted.
(JSC::Heap::extraSize): Deleted.
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::reportExtraMemoryAllocated):
(JSC::Heap::reportExtraMemoryVisited):
(JSC::Heap::deprecatedReportExtraMemory):
(JSC::Heap::reportExtraMemoryCost): Deleted. Ditto.
* heap/SlotVisitor.h:
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::reportExtraMemoryVisited):
(JSC::SlotVisitor::reportExtraMemoryUsage): Deleted. Moved this
functionality into the Heap since it's pretty detailed in its access
to the heap.
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::visitChildren): Updated for
renames.
* runtime/JSString.cpp:
(JSC::JSString::visitChildren):
(JSC::JSRopeString::resolveRopeToAtomicString):
(JSC::JSRopeString::resolveRope):
* runtime/JSString.h:
(JSC::JSString::finishCreation): Updated for renames.
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::add): Added FIXME.
* runtime/WeakMapData.cpp:
(JSC::WeakMapData::visitChildren): Updated for rename.
2015-03-11 Ryosuke Niwa <rniwa@webkit.org>
Calling super() in a base class results in a crash
https://bugs.webkit.org/show_bug.cgi?id=142563
Reviewed by Filip Pizlo.
The bug was caused by BytecodeGenerator trying to generate "super" expression inside the constructor of a base class.
Disallow that by keeping track of whether "super" has been used in the current scope or not (needsSuperBinding flag)
and then throwing a syntax error in parseFunctionInfo if it was used and the current scope wasn't the constructor of
a derived class.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionInfo): Don't allow super() or super.foo outside the constructor of a derived class.
(JSC::Parser<LexerType>::parseClass): Pass in the constructor kind to parseGetterSetter.
(JSC::Parser<LexerType>::parseGetterSetter): Ditto to parseFunctionInfo.
(JSC::Parser<LexerType>::parseMemberExpression): Set needsSuperBinding flag true on the containing scope.
* parser/Parser.h:
(JSC::Scope::Scope):
(JSC::Scope::needsSuperBinding): Added.
(JSC::Scope::setNeedsSuperBinding): Added.
2015-03-10 Darin Adler <darin@apple.com>
Some event handler fixes
https://bugs.webkit.org/show_bug.cgi?id=142474
Reviewed by Anders Carlsson.
* inspector/InjectedScriptManager.cpp:
(Inspector::InjectedScriptManager::createInjectedScript): Call clearException.
I spotted the fact it was missing by auditing all the calls to JSC::call.
2015-03-10 Matthew Mirman <mmirman@apple.com>
Functions should have initialization precedence over arguments.
https://bugs.webkit.org/show_bug.cgi?id=142550
rdar://problem/19702564
Reviewed by Geoffrey Garen.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeCapturedVariable):
* tests/stress/initialize_functions_after_arguments.js: Added.
2015-03-10 Andreas Kling <akling@apple.com>
Eden collections should trigger sweep of MarkedBlocks containing new objects.
<https://webkit.org/b/142538>
Reviewed by Geoffrey Garen.
Take a snapshot of all MarkedBlocks with new objects as part of Eden collections,
and append that to the IncrementalSweeper's working set.
This ensures that we run destructors for objects that were discovered to be garbage during
Eden collections, instead of delaying their teardown until the next full collection,
or the next allocation cycle for their block.
* heap/Heap.cpp:
(JSC::Heap::snapshotMarkedSpace): For Eden collections, snapshot the list of MarkedBlocks
that contain new objects, since those are the only ones we're interested in.
Also use Vector::resizeToFit() to allocate the snapshot for full collections, since we know
the final size we need up front.
(JSC::Heap::notifyIncrementalSweeper): For Eden collections, tell the IncrementalSweeper
to add the block snapshot (taken earlier) to its existing set of blocks instead of replacing
it entirely. This allows Eden collections and incremental sweeping to occur interleaved with
each other without missing destruction opportunities.
* heap/IncrementalSweeper.h:
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::doSweep):
(JSC::IncrementalSweeper::sweepNextBlock): Change the way we iterate over the sweeper's
work list: instead of keeping an index for the next block, just pop from the end of the list.
This allows us to add new blocks and deduplicate the list without disturbing iteration.
(JSC::IncrementalSweeper::startSweeping): Make this take a Vector<MarkedBlock>&& so we can
pass ownership of this Vector efficiently from Heap to IncrementalSweeper.
(JSC::IncrementalSweeper::addBlocksAndContinueSweeping): Added. This is used by Eden
collections to add a set of MarkedBlocks with new objects to the sweeper's existing
working set and kick the timer.
* heap/MarkedSpace.h:
(JSC::MarkedSpace::blocksWithNewObjects): Expose the list of MarkedBlocks with new objects.
2015-03-10 Alex Christensen <achristensen@webkit.org>
Use unsigned for HashSet size.
https://bugs.webkit.org/show_bug.cgi?id=142518
Reviewed by Benjamin Poulain.
* dfg/DFGAvailabilityMap.cpp:
(JSC::DFG::AvailabilityMap::prune):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* heap/MarkedBlockSet.h:
(JSC::MarkedBlockSet::remove):
* runtime/WeakMapData.h:
2015-03-10 Mark Lam <mark.lam@apple.com>
Use std::numeric_limits<unsigned>::max() instead of (unsigned)-1.
<https://webkit.org/b/142539>
Reviewed by Benjamin Poulain.
* jit/JIT.cpp:
(JSC::JIT::JIT):
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
(JSC::JIT::privateCompile):
(JSC::JIT::privateCompileExceptionHandlers):
* jit/JITInlines.h:
(JSC::JIT::emitNakedCall):
(JSC::JIT::addSlowCase):
(JSC::JIT::addJump):
(JSC::JIT::emitJumpSlowToHot):
(JSC::JIT::emitGetVirtualRegister):
* jit/SlowPathCall.h:
(JSC::JITSlowPathCall::call):
* yarr/Yarr.h:
2015-03-10 Mark Lam <mark.lam@apple.com>
[Win] JSC Build Warnings Need to be Resolved.
<https://webkit.org/b/142366>
Reviewed by Brent Fulgham.
Applied some benign changes to make the MSVC compiler happy.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::fillJSValue):
* runtime/BasicBlockLocation.cpp:
(JSC::BasicBlockLocation::getExecutedRanges):
* runtime/ControlFlowProfiler.cpp:
(JSC::ControlFlowProfiler::hasBasicBlockAtTextOffsetBeenExecuted):
2015-03-10 Yusuke Suzuki <utatane.tea@gmail.com>
Upgrade Map, Set and WeakMap constructor interface
https://bugs.webkit.org/show_bug.cgi?id=142348
Reviewed by Filip Pizlo.
In the latest ES6 spec, Map and Set constructors take initialization data sets
as iterable value. And iterate it and add the values into the constructed one.
This is breaking change because the old constructor interface is
already shipped in Safari 8.
* runtime/MapConstructor.cpp:
(JSC::callMap):
(JSC::constructMap):
(JSC::MapConstructor::getCallData):
* runtime/SetConstructor.cpp:
(JSC::callSet):
(JSC::constructSet):
* runtime/WeakMapConstructor.cpp:
(JSC::callWeakMap):
(JSC::constructWeakMap):
(JSC::WeakMapConstructor::getCallData):
* tests/stress/map-constructor-adder.js: Added.
* tests/stress/map-constructor.js: Added.
(testCallTypeError):
(testTypeError):
(for):
* tests/stress/set-constructor-adder.js: Added.
(Set.prototype.add):
* tests/stress/set-constructor.js: Added.
(for):
* tests/stress/weak-map-constructor-adder.js: Added.
* tests/stress/weak-map-constructor.js: Added.
(testCallTypeError):
(testTypeError):
(for):
2015-03-10 Michael Catanzaro <mcatanzaro@igalia.com>
GCC: CRASH() should be annotated with NORETURN
https://bugs.webkit.org/show_bug.cgi?id=142524
Reviewed by Anders Carlsson.
Don't return from a NORETURN function. This used to avoid a warning from GCC, but now it
causes one.
* jsc.cpp:
2015-03-10 Mark Lam <mark.lam@apple.com>
Gardening: fix bleeding debug test bots.
https://webkit.org/b/142513>
Not reviewed.
The test needs to initialize WTF threading explicitly before using it.
* API/tests/CompareAndSwapTest.cpp:
(testCompareAndSwap):
2015-03-10 Alex Christensen <achristensen@webkit.org>
[WinCairo] Unreviewed build fix.
* JavaScriptCore.vcxproj/testapi/testapiCommonCFLite.props:
Added directory containing config.h, like r181304.
2015-03-09 Mark Lam <mark.lam@apple.com>
Yet another build fix for Windows.
https://webkit.org/b/142513>
Reviewed by Alex Christensen.
Looks like MSVC requires the function be explicitly declared in a header file
in order for it to be linkable from another file in the same project. This is
strange, but it seems to make MSVC happy.
Also fixed a typo in testapi.vcxproj.filters.
* API/tests/CompareAndSwapTest.cpp:
* API/tests/CompareAndSwapTest.h: Added.
* API/tests/testapi.c:
* JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
* JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
2015-03-09 Chris Dumez <cdumez@apple.com>
[iOS] Sweep all collected objects on critical memory pressure
https://bugs.webkit.org/show_bug.cgi?id=142457
<rdar://problem/20044440>
Reviewed by Geoffrey Garen.
All fullSweep() API to IncrementalSweeper so that we can call it in the
memory pressure handler.
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::fullSweep):
* heap/IncrementalSweeper.h:
(JSC::IncrementalSweeper::hasWork):
2015-03-09 Mark Lam <mark.lam@apple.com>
Another build fix for Windows.
https://webkit.org/b/142513>
Not reviewed.
* API/tests/CompareAndSwapTest.cpp:
- Added JS_EXPORT_PRIVATE attribute.
2015-03-09 Mark Lam <mark.lam@apple.com>
Build fix for Windows after r181305.
https://webkit.org/b/142513>
Reviewed by Alex Christensen.
Windows doesn't like pthreads anymore. Changed test to use WTF threading.
* API/tests/CompareAndSwapTest.cpp:
(setBitThreadFunc):
(testCompareAndSwap):
2015-03-09 Mark Lam <mark.lam@apple.com>
8-bit version of weakCompareAndSwap() can cause an infinite loop.
https://webkit.org/b/142513>
Reviewed by Filip Pizlo.
Added a test that exercises the 8-bit CAS from multiple threads. The threads
will contend to set bits in a large array of bytes using the CAS function.
* API/tests/CompareAndSwapTest.cpp: Added.
(Bitmap::Bitmap):
(Bitmap::numBits):
(Bitmap::clearAll):
(Bitmap::concurrentTestAndSet):
(setBitThreadFunc):
(testCompareAndSwap):
* API/tests/testapi.c:
(main):
* JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
* JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
2015-03-09 Brent Fulgham <bfulgham@apple.com>
[Win] testapi project is unable to find the 'config.h' file.
Rubberstamped by Mark Lam.
* JavaScriptCore.vcxproj/testapi/testapiCommon.props: Add JavaScriptCore source directory
to the include path.
2015-03-09 Andreas Kling <akling@apple.com>
Stale entries in WeakGCMaps are keeping tons of WeakBlocks alive unnecessarily.
<https://webkit.org/b/142115>
<rdar://problem/19992268>
Reviewed by Geoffrey Garen.
Prune stale entries from WeakGCMaps as part of every full garbage collection.
This frees up tons of previously-stuck WeakBlocks that were only sitting around
with finalized handles waiting to die.
Note that WeakGCMaps register/unregister themselves with the GC heap in their
ctor/dtor, so creating one now requires passing the VM.
Average time spent in the PruningStaleEntriesFromWeakGCMaps GC phase appears
to be between 0.01ms and 0.3ms, though I've seen a few longer ones at ~1.2ms.
It seems somewhat excessive to do this on every Eden collection, so it's only
doing work in full collections for now.
Because the GC may now mutate WeakGCMap below object allocation, I've made it
so that the classic HashMap::add() optimization can't be used with WeakGCMap.
This caused intermittent test failures when originally landed due to having
an invalid iterator on the stack after add() inserted a new entry and we
proceeded to allocate the new object, triggering GC.
* API/JSWeakObjectMapRefInternal.h:
(OpaqueJSWeakObjectMap::create):
(OpaqueJSWeakObjectMap::OpaqueJSWeakObjectMap):
* API/JSWeakObjectMapRefPrivate.cpp:
* API/JSWrapperMap.mm:
(-[JSWrapperMap initWithContext:]):
(-[JSWrapperMap jsWrapperForObject:]): Pass VM to WeakGCMap constructor.
* JavaScriptCore.xcodeproj/project.pbxproj: Add WeakGCMapInlines.h and make
it project-private so WebCore clients can access it.
* heap/Heap.cpp:
(JSC::Heap::collect):
(JSC::Heap::pruneStaleEntriesFromWeakGCMaps): Added a new GC phase for pruning
stale entries from WeakGCMaps. This is only executed during full collections.
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::registerWeakGCMap):
(JSC::Heap::unregisterWeakGCMap): Added a mechanism for WeakGCMaps to register
themselves with the Heap and provide a pruning callback.
* runtime/PrototypeMap.h:
(JSC::PrototypeMap::PrototypeMap):
* runtime/Structure.cpp:
(JSC::StructureTransitionTable::add): Pass VM to WeakGCMap constructor.
* runtime/JSCInlines.h: Add "WeakGCMapInlines.h"
* runtime/JSGlobalObject.cpp: Include "WeakGCMapInlines.h" so this builds.
* runtime/JSString.cpp:
(JSC::jsStringWithCacheSlowCase):
* runtime/PrototypeMap.cpp:
(JSC::PrototypeMap::addPrototype):
(JSC::PrototypeMap::emptyObjectStructureForPrototype): Remove HashMap add()
optimization since it's not safe in the GC-managed WeakGCMap world.
* runtime/VM.cpp:
(JSC::VM::VM): Pass VM to WeakGCMap constructor.
* runtime/WeakGCMap.h:
(JSC::WeakGCMap::set):
(JSC::WeakGCMap::add):
(JSC::WeakGCMap::WeakGCMap): Deleted.
(JSC::WeakGCMap::gcMap): Deleted.
(JSC::WeakGCMap::gcMapIfNeeded): Deleted.
* runtime/WeakGCMapInlines.h: Added.
(JSC::WeakGCMap::WeakGCMap):
(JSC::WeakGCMap::~WeakGCMap):
(JSC::WeakGCMap::pruneStaleEntries): Moved ctor, dtor and pruning callback
to WeakGCMapInlines.h to fix interdependent header issues. Removed code that
prunes WeakGCMap at certain growth milestones and instead rely on the GC
callback for housekeeping.
2015-03-09 Ryosuke Niwa <rniwa@webkit.org>
Support extends and super keywords
https://bugs.webkit.org/show_bug.cgi?id=142200
Reviewed by Filip Pizlo.
Added the support for ES6 class syntax inheritance.
Added ConstructorKind as well as boolean flags indicating the constructor kind to
various classes in UnlinkedCodeBlock as well as AST nodes.
Each method stores the associated class as its homeObjectPrivateName. This value is used to
make super calls.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::ExecutableInfo::ExecutableInfo):
(JSC::UnlinkedFunctionExecutable::constructorKindIsDerived): Added.
(JSC::UnlinkedCodeBlock::constructorKindIsDerived): Added.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator): Don't emit op_create_this in a derived class
as the object is allocated by the highest base class's constructor. Also set "this" to null
and store the original value in m_newTargetRegister. "this" is supposed to be in TDZ but
that will be implemented in a separate patch.
(JSC::BytecodeGenerator::emitReturn): Allow "undefined" to be returned from a derived class.
In a derived class's constructor, not returning "undefined" or an object results in a type
error instead of "this" being returned.
(JSC::BytecodeGenerator::emitThrowTypeError): Added.
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::constructorKindIsDerived): Added.
(JSC::BytecodeGenerator::newTarget): Added.
* bytecompiler/NodesCodegen.cpp:
(JSC::SuperNode::emitBytecode): Added. Emits the code to obtain the callee's parent class.
(JSC::emitSuperBaseForCallee): Added. Emits the code to obtain the parent class's prototype.
(JSC::emitPutHomeObject): Added.
(JSC::PropertyListNode::emitBytecode): Stores the home object when adding methods.
(JSC::PropertyListNode::emitPutConstantProperty): Ditto.
(JSC::BracketAccessorNode::emitBytecode): Added the support for super['foo'].
(JSC::DotAccessorNode::emitBytecode): Added the support for super.foo.
(JSC::FunctionCallValueNode::emitBytecode): Added the support for super().
(JSC::FunctionCallBracketNode::emitBytecode): Added the support for super['foo']().
(JSC::FunctionCallDotNode::emitBytecode): Added the support for super.foo().
(JSC::DeleteBracketNode::emitBytecode): Forbid "delete super.foo".
(JSC::DeleteDotNode::emitBytecode): Forbid "delete super['foo']".
(JSC::ClassExprNode::emitBytecode): Added the support for "classHeritage". This is the main
logic for inheritance. When a class B inherits from a class A, set B.__proto__ to A and set
B.prototype.__proto__ to A.prototype. Throw exceptions when either A or A.__proto__ is not
an object.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::superExpr): Added.
* parser/NodeConstructors.h:
(JSC::SuperNode::SuperNode): Added.
* parser/Nodes.cpp:
(JSC::FunctionBodyNode::FunctionBodyNode):
* parser/Nodes.h:
(JSC::ExpressionNode::isSuperNode):
(JSC::PropertyNode::type):
(JSC::PropertyNode::needsSuperBinding):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionBody):
(JSC::Parser<LexerType>::parseFunctionInfo): Throw a parser error if super() is used outside
of class constructors.
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseClass): ConstructorKind is "derived" if and only if the parent
class is specified in the declaration / expression.
(JSC::Parser<LexerType>::parseGetterSetter):
(JSC::Parser<LexerType>::parsePrimaryExpression):
(JSC::Parser<LexerType>::parseMemberExpression): Added the support for "super()", "super.foo",
and "super['foo']". Throw a semantic error if "super" appears by itself.
* parser/Parser.h:
(JSC::Scope::Scope): Added m_hasDirectSuper. This variable keeps track of the use of "super()"
so that parseFunctionInfo can spit an error if it's used outside of class constructors.
(JSC::Scope::hasDirectSuper): Added.
(JSC::Scope::setHasDirectSuper): Added.
* parser/ParserModes.h:
(JSC::ConstructorKind): Added.
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::superExpr): Added.
* runtime/CommonIdentifiers.h: Added homeObjectPrivateName.
* runtime/Executable.h:
(JSC::EvalExecutable::executableInfo):
(JSC::ProgramExecutable::executableInfo):
2015-03-08 Andreas Kling <akling@apple.com>
JITThunks keeps finalized Weaks around, pinning WeakBlocks.
<https://webkit.org/b/142454>
Reviewed by Darin Adler.
Make JITThunks a WeakHandleOwner so it can keep its host function map free of stale entries.
This fixes an issue I was seeing where a bunch of WeakBlocks stuck around with nothing but
finalized Weak<NativeExecutable> entries.
* jit/JITThunks.h:
* jit/JITThunks.cpp:
(JSC::JITThunks::finalize): Make JITThunks inherit from WeakHandleOwner so it can receive
a callback when the NativeExecutables get garbage collected.
(JSC::JITThunks::hostFunctionStub): Pass 'this' as the handle owner when creating Weaks.
2015-03-08 Andreas Kling <akling@apple.com>
BuiltinExecutables keeps finalized Weaks around, pinning WeakBlocks.
<https://webkit.org/b/142460>
Reviewed by Geoffrey Garen.
Make BuiltinExecutables a WeakHandleOwner so it can clear out its respective Weak members
if and when their pointees get garbage collected.
This fixes an issue I've seen locally where a WeakBlock is pinned down by a single one of
these Weak<BuiltinExecutables>.
* builtins/BuiltinExecutables.h: Make BuiltinExecutables inherit from WeakHandleOwner.
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::finalize): Clear out the relevant member pointer when it's been
garbage collected. We use the WeakImpl's "context" field to pass the address of the member.
2015-03-07 Geoffrey Garen <ggaren@apple.com>
Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
https://bugs.webkit.org/show_bug.cgi?id=140900
Reviewed by Mark Hahnenberg.
Re-landing just the removal of BlockAllocator, which is now unused.
* API/JSBase.cpp:
* CMakeLists.txt:
* JavaScriptCore.order:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/BlockAllocator.cpp: Removed.
* heap/BlockAllocator.h: Removed.
* heap/GCThreadSharedData.h:
* heap/HandleBlockInlines.h:
* heap/Heap.cpp:
(JSC::Heap::Heap):
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::blockAllocator): Deleted.
* heap/HeapTimer.cpp:
* heap/MarkedBlock.h:
* heap/MarkedSpace.h:
* heap/Region.h: Removed.
* heap/SuperRegion.cpp: Removed.
* heap/SuperRegion.h: Removed.
2015-03-07 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r181010.
https://bugs.webkit.org/show_bug.cgi?id=142442
Broke media/video-src-invalid-poster.html (Requested by kling
on #webkit).
Reverted changeset:
"Stale entries in WeakGCMaps are keeping tons of WeakBlocks
alive unnecessarily."
https://bugs.webkit.org/show_bug.cgi?id=142115
http://trac.webkit.org/changeset/181010
2015-03-07 Ryosuke Niwa <rniwa@webkit.org>
The code to link FunctionExecutable is duplicated everywhere
https://bugs.webkit.org/show_bug.cgi?id=142436
Reviewed by Darin Adler.
Reduced code duplication by factoring out linkInsideExecutable and linkGlobalCode.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock): Calls linkInsideExecutable.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedFunctionExecutable::linkInsideExecutable): Renamed from link. Now takes care of startOffset.
This change was needed to use this function in CodeBlock::CodeBlock. Also, this function no longer takes
lineOffset since this information is already stored in the source code.
(JSC::UnlinkedFunctionExecutable::linkGlobalCode): Extracted from FunctionExecutable::fromGlobalCode.
* bytecode/UnlinkedCodeBlock.h:
* generate-js-builtins: Calls linkGlobalCode.
* runtime/Executable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties): Calls linkGlobalCode.
(JSC::FunctionExecutable::fromGlobalCode): Calls linkGlobalCode.
2015-03-06 Geoffrey Garen <ggaren@apple.com>
Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
https://bugs.webkit.org/show_bug.cgi?id=140900
Reviewed by Mark Hahnenberg.
Re-landing just the MarkedBlock piece of this patch.
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::allocateBlock):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::create):
(JSC::MarkedBlock::destroy):
(JSC::MarkedBlock::MarkedBlock):
* heap/MarkedBlock.h:
(JSC::MarkedBlock::capacity):
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::freeBlock):
2015-03-07 Ryosuke Niwa <rniwa@webkit.org>
fromGlobalCode has an unused Debugger* argument
https://bugs.webkit.org/show_bug.cgi?id=142430
Reviewed by Darin Adler.
Removed the debugger argument from UnlinkedFunctionExecutable::fromGlobalCode and
FunctionExecutable::fromGlobalCode since it's not used in either function.
Also use reference in other arguments.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
* bytecode/UnlinkedCodeBlock.h:
* runtime/Executable.cpp:
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
2015-03-06 Brent Fulgham <bfulgham@apple.com>
[Win] Turn off a warning on Windows.
Reduce build logging noise on Windows.
* JavaScriptCore.vcxproj/JavaScriptCoreCommon.props:
2015-03-06 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: ES6: Improved Support for Iterator Objects
https://bugs.webkit.org/show_bug.cgi?id=142420
Reviewed by Timothy Hatcher.
* inspector/protocol/Runtime.json:
Add new object subtype "iterator" for built-in iterator objects.
* inspector/InjectedScriptSource.js:
Return iterator values as Entry objects.
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::subtype):
Identify "iterator" typed objects.
(Inspector::JSInjectedScriptHost::getInternalProperties):
Provide internal properties for the different Iterator objects.
(Inspector::JSInjectedScriptHost::iteratorEntries):
Fetch the next few iterator entries of a built-in iterator object.
* inspector/JSInjectedScriptHost.h:
* inspector/JSInjectedScriptHostPrototype.cpp:
(Inspector::JSInjectedScriptHostPrototype::finishCreation):
(Inspector::jsInjectedScriptHostPrototypeFunctionIteratorEntries):
Call through to JSInjectedScriptHost.
* runtime/JSArgumentsIterator.cpp:
(JSC::JSArgumentsIterator::clone):
* runtime/JSArgumentsIterator.h:
(JSC::JSArgumentsIterator::iteratedValue):
* runtime/JSArrayIterator.cpp:
(JSC::JSArrayIterator::kind):
(JSC::JSArrayIterator::iteratedValue):
(JSC::JSArrayIterator::clone):
* runtime/JSArrayIterator.h:
* runtime/JSMapIterator.cpp:
(JSC::JSMapIterator::finishCreation):
(JSC::JSMapIterator::clone):
* runtime/JSMapIterator.h:
(JSC::JSMapIterator::kind):
(JSC::JSMapIterator::iteratedValue):
* runtime/JSSetIterator.cpp:
(JSC::JSSetIterator::finishCreation):
(JSC::JSSetIterator::clone):
* runtime/JSSetIterator.h:
(JSC::JSSetIterator::kind):
(JSC::JSSetIterator::iteratedValue):
* runtime/JSStringIterator.cpp:
(JSC::JSStringIterator::iteratedValue):
(JSC::JSStringIterator::clone):
* runtime/JSStringIterator.h:
Add accessors for internal properties and provide a way to clone the
iterator so we can be at the same index and peek at the next few
objects without modifying the original iterator object.
2015-03-06 Ryosuke Niwa <rniwa@webkit.org>
REGRESSION(r180595): construct varargs fails in FTL
https://bugs.webkit.org/show_bug.cgi?id=142030
Reviewed by Michael Saboff.
Increase sizeOfCallVarargs as done for sizeOfConstructVarargs in r180651.
* ftl/FTLInlineCacheSize.cpp:
(JSC::FTL::sizeOfCallVarargs):
2015-03-06 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Adopt Object Literal Shorthand Property Construction Syntax
https://bugs.webkit.org/show_bug.cgi?id=142374
Reviewed by Timothy Hatcher.
* inspector/InjectedScriptSource.js:
2015-03-06 Joseph Pecoraro <pecoraro@apple.com>
ES6: Object Literal Extensions - Methods
https://bugs.webkit.org/show_bug.cgi?id=142390
Reviewed by Geoffrey Garen.
Support method syntax in object literals.
* parser/Parser.h:
* parser/Parser.cpp:
(JSC::stringForFunctionMode):
(JSC::Parser<LexerType>::parseProperty):
Methods are allowed for identifier, string, and numeric names,
and computed property names.
(JSC::Parser<LexerType>::parsePropertyMethod):
Helper for parsing a property method.
2015-03-05 Joseph Pecoraro <pecoraro@apple.com>
__proto__ shorthand property should not modify prototype in Object Literal construction
https://bugs.webkit.org/show_bug.cgi?id=142382
Reviewed by Geoffrey Garen.
When parsing shorthand property syntax we know we will do a
put direct, even if the property name is __proto__. Pass that
information through to bytecode generation.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitDirectPutById):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::PropertyListNode::emitPutConstantProperty):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createGetterOrSetterProperty):
(JSC::ASTBuilder::createProperty):
* parser/NodeConstructors.h:
(JSC::PropertyNode::PropertyNode):
* parser/Nodes.h:
(JSC::PropertyNode::putType):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseProperty):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createProperty):
2015-03-06 Geoffrey Garen <ggaren@apple.com>
Fix crashes seen on the the 32-bit buildbots after my last patch.
Unreviewed.
* heap/CopiedBlock.h:
(JSC::CopiedBlock::payload):
* heap/CopiedSpace.cpp:
(JSC::CopiedSpace::tryAllocateOversize): Round up to the right alignment,
since the size of the CopiedBlock class is not guaranteed to be the
right alignment, and is in fact the wrong alignment on 32-bit.
2015-03-05 Geoffrey Garen <ggaren@apple.com>
Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
https://bugs.webkit.org/show_bug.cgi?id=140900
Reviewed by Mark Hahnenberg.
Re-landing just the CopiedBlock piece of this patch.
* heap/CopiedBlock.h:
(JSC::CopiedBlock::createNoZeroFill):
(JSC::CopiedBlock::destroy):
(JSC::CopiedBlock::create):
(JSC::CopiedBlock::CopiedBlock):
(JSC::CopiedBlock::isOversize):
(JSC::CopiedBlock::payloadEnd):
(JSC::CopiedBlock::capacity):
* heap/CopiedSpace.cpp:
(JSC::CopiedSpace::~CopiedSpace):
(JSC::CopiedSpace::tryAllocateOversize):
(JSC::CopiedSpace::tryReallocateOversize):
* heap/CopiedSpaceInlines.h:
(JSC::CopiedSpace::recycleEvacuatedBlock):
(JSC::CopiedSpace::recycleBorrowedBlock):
(JSC::CopiedSpace::allocateBlockForCopyingPhase):
(JSC::CopiedSpace::allocateBlock):
(JSC::CopiedSpace::startedCopying):
* heap/CopyWorkList.h:
2015-03-06 Myles C. Maxfield <mmaxfield@apple.com>
[iOS] SVG fonts are garbled
https://bugs.webkit.org/show_bug.cgi?id=142377
Reviewed by Simon Fraser.
* Configurations/FeatureDefines.xcconfig:
2015-03-05 Joseph Pecoraro <pecoraro@apple.com>
ES6: Object Literal Extensions - Shorthand Properties (Identifiers)
https://bugs.webkit.org/show_bug.cgi?id=142353
Reviewed by Geoffrey Garen.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseProperty):
Parsing an identifier property followed by a comma or end brace treat
as a shorthand property and create a property that has the same
property name as the identifier name and value of a variable with that
identifier. Otherwise, fall through to getter/setter parsing.
2015-03-05 Brent Fulgham <bfulgham@apple.com>
[Win] Unreviewed gardening.
Confirmed with JSC that warning 4611 (interaction between '_setjmp' and C++ object
destruction is non-portable) should be ignored in the JavaScriptCore project.
* JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: Silence warning 4611.
2015-03-05 Chris Dumez <cdumez@apple.com>
Regression(r173761): ASSERTION FAILED: !is8Bit() in StringImpl::characters16()
https://bugs.webkit.org/show_bug.cgi?id=142350
Reviewed by Michael Saboff and Benjamin Poulain.
Call WTFString::hasInfixStartingAt() / hasInfixEndingAt() now that these
methods have been renamed for clarity.
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncStartsWith):
(JSC::stringProtoFuncEndsWith):
2015-03-05 Yusuke Suzuki <utatane.tea@gmail.com>
Implement ES6 StringIterator
https://bugs.webkit.org/show_bug.cgi?id=142080
Reviewed by Filip Pizlo.
This patch introduces ES6 String Iterator.
It enumerates code points instead of elements in String.
So surrogate pairs should be handled correctly.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/StringIterator.prototype.js: Added.
(next):
* runtime/CommonIdentifiers.h:
* runtime/JSGlobalObject.cpp:
* runtime/JSGlobalObject.h:
* runtime/JSStringIterator.cpp: Added.
(JSC::JSStringIterator::finishCreation):
* runtime/JSStringIterator.h: Added.
(JSC::JSStringIterator::createStructure):
(JSC::JSStringIterator::create):
(JSC::JSStringIterator::JSStringIterator):
* runtime/StringIteratorConstructor.cpp: Added.
(JSC::StringIteratorConstructor::finishCreation):
* runtime/StringIteratorConstructor.h: Added.
(JSC::StringIteratorConstructor::create):
(JSC::StringIteratorConstructor::createStructure):
(JSC::StringIteratorConstructor::StringIteratorConstructor):
* runtime/StringIteratorPrototype.cpp: Added.
(JSC::StringIteratorPrototype::finishCreation):
(JSC::StringIteratorPrototype::getOwnPropertySlot):
(JSC::stringIteratorPrototypeIterator):
* runtime/StringIteratorPrototype.h: Added.
(JSC::StringIteratorPrototype::create):
(JSC::StringIteratorPrototype::createStructure):
(JSC::StringIteratorPrototype::StringIteratorPrototype):
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
(JSC::stringProtoFuncIterator):
* tests/stress/string-iterators.js: Added.
(testSurrogatePair):
(increment):
(for):
2015-03-05 Csaba Osztrogonác <ossy@webkit.org>
[ARM] Fix the FTL build on Aarch64 Linux after r177421
https://bugs.webkit.org/show_bug.cgi?id=142040
Reviewed by Mark Lam.
* llvm/library/LLVMExports.cpp:
(initializeAndGetJSCLLVMAPI):
2015-03-05 Yusuke Suzuki <utatane.tea@gmail.com>
Upgrade ES6 Iterator interfaces
https://bugs.webkit.org/show_bug.cgi?id=141351
Reviewed by Filip Pizlo.
This patch upgrades the exising ES6 iterator to align the latest spec.
In the latest spec,
1. `Iterator.next` returns object that implements IteratorResult interface { value: value, done, boolean }.
2. `Iterator.return` is introduced. When the iteration is terminated by the abrupt completion,
it is called to close iterator state.
3. Iterator.next of Array is moved from an iterator object to `%ArrayIteratorPrototype%`.
To upgrade it, we changes the bytecode that represents for-of loops.
And to embody the efficient iteration with an iterator object,
we implemented %ArrayIteratorPrototype%.next in JavaScript and
it is located in builtins/ArrayIterator.prototype.js.
Implementing it in JavaScript encourages inlining and
utilizes escape analysis for an iterator result object in DFG JIT.
And we dropped the intrinsic version of %ArrayIteratorPrototype%.next.
And we introduced IteratorOperations that is defined in the spec.
It aligns the iteration in the runtime to the latest spec.
Currently, Promise.all and Promise.race uses an iterable object.
However, Promise.all and Promise.race implementation is also based on the old spec.
Subsequent patches will upgrade it.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/ArrayIterator.prototype.js: Copied from Source/JavaScriptCore/runtime/ArrayIteratorPrototype.h.
(next):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitReturn):
(JSC::BytecodeGenerator::emitThrowTypeError):
(JSC::BytecodeGenerator::emitEnumeration):
(JSC::BytecodeGenerator::emitIsObject):
(JSC::BytecodeGenerator::emitIsUndefined):
* bytecompiler/BytecodeGenerator.h:
* jit/ThunkGenerators.cpp:
(JSC::arrayIteratorNextThunkGenerator): Deleted.
(JSC::arrayIteratorNextKeyThunkGenerator): Deleted.
(JSC::arrayIteratorNextValueThunkGenerator): Deleted.
* jit/ThunkGenerators.h:
* runtime/ArgumentsIteratorPrototype.cpp:
(JSC::ArgumentsIteratorPrototype::finishCreation):
(JSC::argumentsIteratorPrototypeFuncNext):
* runtime/ArrayIteratorPrototype.cpp:
(JSC::ArrayIteratorPrototype::finishCreation):
(JSC::ArrayIteratorPrototype::getOwnPropertySlot):
(JSC::arrayIteratorProtoFuncIterator):
(JSC::arrayIteratorPrototypeIterate): Deleted.
* runtime/ArrayIteratorPrototype.h:
* runtime/CommonIdentifiers.h:
* runtime/Intrinsic.h:
* runtime/IteratorOperations.cpp: Added.
(JSC::iteratorNext):
(JSC::iteratorValue):
(JSC::iteratorComplete):
(JSC::iteratorStep):
(JSC::iteratorClose):
(JSC::createIterResultObject):
* runtime/IteratorOperations.h: Copied from Source/JavaScriptCore/runtime/ArrayIteratorPrototype.cpp.
* runtime/JSArrayIterator.cpp:
(JSC::JSArrayIterator::finishCreation):
(JSC::JSArrayIterator::visitChildren): Deleted.
(JSC::createIteratorResult): Deleted.
(JSC::arrayIteratorNext): Deleted.
(JSC::arrayIteratorNextKey): Deleted.
(JSC::arrayIteratorNextValue): Deleted.
(JSC::arrayIteratorNextGeneric): Deleted.
* runtime/JSArrayIterator.h:
(JSC::JSArrayIterator::JSArrayIterator):
(JSC::JSArrayIterator::iterationKind): Deleted.
(JSC::JSArrayIterator::iteratedObject): Deleted.
(JSC::JSArrayIterator::nextIndex): Deleted.
(JSC::JSArrayIterator::setNextIndex): Deleted.
(JSC::JSArrayIterator::finish): Deleted.
(JSC::JSArrayIterator::offsetOfIterationKind): Deleted.
(JSC::JSArrayIterator::offsetOfIteratedObject): Deleted.
(JSC::JSArrayIterator::offsetOfNextIndex): Deleted.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSPromiseConstructor.cpp:
(JSC::performPromiseRaceLoop):
(JSC::JSPromiseConstructorFuncRace):
(JSC::performPromiseAll):
(JSC::JSPromiseConstructorFuncAll):
* runtime/MapIteratorPrototype.cpp:
(JSC::MapIteratorPrototype::finishCreation):
(JSC::MapIteratorPrototypeFuncNext):
* runtime/SetIteratorPrototype.cpp:
(JSC::SetIteratorPrototype::finishCreation):
(JSC::SetIteratorPrototypeFuncNext):
* runtime/VM.cpp:
(JSC::thunkGeneratorForIntrinsic):
* tests/stress/array-iterators-next-with-call.js: Added.
(increment):
(for):
* tests/stress/array-iterators-next.js: Added.
Revive the older Array iterator tests that manually call 'next' method.
* tests/stress/custom-iterators.js: Added.
(iter.next):
(iter.Symbol.iterator):
(iter.return):
(iter.get next):
(iter.get return):
(iteratorInterfaceErrorTest.iter.next):
(iteratorInterfaceErrorTest.iter.Symbol.iterator):
(iteratorInterfaceErrorTest.iter.return):
(iteratorInterfaceErrorTest):
(iteratorInterfaceErrorTestReturn.iter.next):
(iteratorInterfaceErrorTestReturn.iter.Symbol.iterator):
(iteratorInterfaceErrorTestReturn.iter.return):
(iteratorInterfaceErrorTestReturn):
(iteratorInterfaceBreakTestReturn.iter.next):
(iteratorInterfaceBreakTestReturn.iter.Symbol.iterator):
(iteratorInterfaceBreakTestReturn.iter.return):
(iteratorInterfaceBreakTestReturn):
This tests the behavior of custom iterators.
'next' and 'return' of iterator work with for-of.
* tests/stress/iterators-shape.js: Added.
(iteratorShape):
(sameNextMethods):
(set var):
This tests the shape of iterators; iterators of Array have 'next' method in %ArrayIteratorPrototype%.
* tests/stress/map-iterators-next.js: Added.
(set var):
(.get if):
(otherKey):
* tests/stress/set-iterators-next.js: Added.
(otherKey):
2015-03-04 Yusuke Suzuki <utatane.tea@gmail.com>
Hide Promise with runtime flags under Cocoa JSContext API
https://bugs.webkit.org/show_bug.cgi?id=141965
Reviewed by Filip Pizlo.
Since there's no run loop in JavaScriptCore APIs, Promises don't work currently.
So until they work, we hide Promise from a global object.
Introduce new JSC runtime flag, PromiseDisabled. When `isPromiseDisabled` is true,
Promise constructor is not attached to JSGlobalObject.
To make 0 as default runtime flags, we choose PromiseDisabled flag
instead of PromiseEnabled flag. So by default, Promise is enabled.
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::JSCallbackObject):
* API/JSContextRef.cpp:
(javaScriptRuntimeFlags):
(JSGlobalContextCreateInGroup):
* API/tests/testapi.c:
(main):
* API/tests/testapi.mm:
(testObjectiveCAPI):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::create):
* runtime/RuntimeFlags.h:
(JSC::RuntimeFlags::createAllEnabled):
2015-03-04 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Array/Collection Sizes should be visible and distinct
https://bugs.webkit.org/show_bug.cgi?id=142254
Reviewed by Timothy Hatcher.
* runtime/WeakMapData.h:
(JSC::WeakMapData::size):
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::weakMapSize):
* inspector/JSInjectedScriptHost.h:
* inspector/JSInjectedScriptHostPrototype.cpp:
(Inspector::JSInjectedScriptHostPrototype::finishCreation):
(Inspector::jsInjectedScriptHostPrototypeFunctionWeakMapSize):
Add a way to get a WeakMap's size.
* inspector/protocol/Runtime.json:
Include size in RemoteObject and ObjectPreview.
* inspector/InjectedScriptSource.js:
Set the size of RemoteObjects and previews if they
are array/collection types.
2015-03-04 Andreas Kling <akling@apple.com>
GC should compute stack bounds and dump registers at the earliest opportunity.
<https://webkit.org/b/142310>
<rdar://problem/20045624>
Reviewed by Geoffrey Garen.
Make Heap::collect() a wrapper function around a collectImpl() where the work is actually done.
The wrapper function that grabs a snapshot of the current stack boundaries and register values
on entry, and sanitizes the stack on exit.
This is a speculative fix for what appears to be overly conservative behavior in the garbage
collector following r178364 which caused a measurable regression in memory usage on Membuster.
The theory being that we were putting pointers to dead things on the stack before scanning it,
and by doing that ended up marking things that we'd otherwise discover to be garbage.
* heap/Heap.cpp:
(JSC::Heap::markRoots):
(JSC::Heap::gatherStackRoots):
(JSC::Heap::collect):
(JSC::Heap::collectImpl):
* heap/Heap.h:
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::gatherFromCurrentThread):
(JSC::MachineThreads::gatherConservativeRoots):
* heap/MachineStackMarker.h:
2015-03-04 Debarshi Ray <debarshir@gnome.org>
Silence GCC's -Wstrict-prototypes
https://bugs.webkit.org/show_bug.cgi?id=142278
Reviewed by Alexey Proskuryakov.
* API/JSContextRef.h:
2015-03-04 Benjamin Poulain <bpoulain@apple.com>
[JSC] Add a node for Math.log()
https://bugs.webkit.org/show_bug.cgi?id=142126
Reviewed by Geoffrey Garen.
This patch adds the DFG node ArithLog for LogIntrinsic.
Having a direct call to log has very little value by itself, the implementation
in DFG and FTL is a simple function call.
What is useful in ArithLog is that we know the operation is pure.
This allow us to hoist it out of loops when the argument is independent
is an invariant of the loop.
Perf wise, this patch gives:
-Kraken's imaging-darkroom: definitely 1.2372x faster.
-AsmBench's Towers.c: definitely 1.0261x faster.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsic):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
(JSC::DFG::PredictionPropagationPhase::doDoubleVoting):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithLog):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLIntrinsicRepository.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileArithLog):
* ftl/FTLOutput.h:
(JSC::FTL::Output::doubleLog):
* tests/stress/math-log-basics.js: Added.
* tests/stress/math-log-with-constants.js: Added.
2015-03-04 Filip Pizlo <fpizlo@apple.com>
Only Heap should be in charge of deciding how to select a subspace for a type
https://bugs.webkit.org/show_bug.cgi?id=142304
Reviewed by Mark Lam.
This slightly reduces the code duplication for selecting subspace based on type, and what
duplication is left is at least localized in HeapInlines.h. The immediate effect is that
the DFG and FTL don't have to duplicate this pattern.
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
(JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::allocateObject):
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::allocateObjectOfType):
(JSC::Heap::subspaceForObjectOfType):
(JSC::Heap::allocatorForObjectOfType):
* runtime/JSCellInlines.h:
(JSC::allocateCell):
2015-03-04 Andreas Kling <akling@apple.com>
Stale entries in WeakGCMaps are keeping tons of WeakBlocks alive unnecessarily.
<https://webkit.org/b/142115>
<rdar://problem/19992268>
Reviewed by Geoffrey Garen.
Prune stale entries from WeakGCMaps as part of every full garbage collection.
This frees up tons of previously-stuck WeakBlocks that were only sitting around
with finalized handles waiting to die.
Note that WeakGCMaps register/unregister themselves with the GC heap in their
ctor/dtor, so creating one now requires passing the VM.
Average time spent in the PruningStaleEntriesFromWeakGCMaps GC phase appears
to be between 0.01ms and 0.3ms, though I've seen a few longer ones at ~1.2ms.
It seems somewhat excessive to do this on every Eden collection, so it's only
doing work in full collections for now.
* API/JSWeakObjectMapRefInternal.h:
(OpaqueJSWeakObjectMap::create):
(OpaqueJSWeakObjectMap::OpaqueJSWeakObjectMap):
* API/JSWeakObjectMapRefPrivate.cpp:
* API/JSWrapperMap.mm:
(-[JSWrapperMap initWithContext:]):
(-[JSWrapperMap jsWrapperForObject:]): Pass VM to WeakGCMap constructor.
* JavaScriptCore.xcodeproj/project.pbxproj: Add WeakGCMapInlines.h and make
it project-private so WebCore clients can access it.
* heap/Heap.cpp:
(JSC::Heap::collect):
(JSC::Heap::pruneStaleEntriesFromWeakGCMaps): Added a new GC phase for pruning
stale entries from WeakGCMaps. This is only executed during full collections.
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::registerWeakGCMap):
(JSC::Heap::unregisterWeakGCMap): Added a mechanism for WeakGCMaps to register
themselves with the Heap and provide a pruning callback.
* runtime/PrototypeMap.h:
(JSC::PrototypeMap::PrototypeMap):
* runtime/Structure.cpp:
(JSC::StructureTransitionTable::add): Pass VM to WeakGCMap constructor.
* runtime/JSCInlines.h: Add "WeakGCMapInlines.h"
* runtime/JSGlobalObject.cpp: Include "WeakGCMapInlines.h" so this builds.
* runtime/VM.cpp:
(JSC::VM::VM): Pass VM to WeakGCMap constructor.
* runtime/WeakGCMap.h:
(JSC::WeakGCMap::set):
(JSC::WeakGCMap::add):
(JSC::WeakGCMap::WeakGCMap): Deleted.
(JSC::WeakGCMap::gcMap): Deleted.
(JSC::WeakGCMap::gcMapIfNeeded): Deleted.
* runtime/WeakGCMapInlines.h: Added.
(JSC::WeakGCMap::WeakGCMap):
(JSC::WeakGCMap::~WeakGCMap):
(JSC::WeakGCMap::pruneStaleEntries): Moved ctor, dtor and pruning callback
to WeakGCMapInlines.h to fix interdependent header issues. Removed code that
prunes WeakGCMap at certain growth milestones and instead rely on the GC
callback for housekeeping.
2015-03-03 Filip Pizlo <fpizlo@apple.com>
DFG IR should refer to FunctionExecutables directly and not via the CodeBlock
https://bugs.webkit.org/show_bug.cgi?id=142229
Reviewed by Mark Lam and Benjamin Poulain.
Anytime a DFG IR node refers to something in CodeBlock, it has three effects:
- Cumbersome API for accessing the thing that the node refers to.
- Not obvious how to create a new such node after bytecode parsing, especially if the
thing it refers to isn't already in the CodeBlock. We have done this in the past, but
it usually involves subtle changes to CodeBlock.
- Not obvious how to inline code that ends up using such nodes. Again, when we have done
this, it involved subtle changes to CodeBlock.
Prior to this change, the NewFunction* node types used an index into tables in CodeBlock.
For this reason, those operations were not inlineable. But the functin tables in CodeBlock
just point to FunctionExecutables, which are cells; this means that we can just abstract
these operands in DFG IR as cellOperands. cellOperands use DFG::FrozenValue, which means
that GC registration happens automagically. Even better, our dumping for cellOperand
already did FunctionExecutable dumping - so that functionality gets to be deduplicated.
Because this change increases the number of users of cellOperand, it also adds some
convenience methods for using it. For example, whereas before you'd say things like:
jsCast<Foo*>(node->cellOperand()->value())
you can now just say:
node->castOperand<Foo*>()
This change also changes existing cellOperand users to use the new conveniance API when
applicable.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::jettisonFunctionDeclsAndExprs):
* bytecode/CodeBlock.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGFrozenValue.h:
(JSC::DFG::FrozenValue::cell):
(JSC::DFG::FrozenValue::dynamicCast):
(JSC::DFG::FrozenValue::cast):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
(JSC::DFG::Graph::registerFrozenValues):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasCellOperand):
(JSC::DFG::Node::castOperand):
(JSC::DFG::Node::hasFunctionDeclIndex): Deleted.
(JSC::DFG::Node::functionDeclIndex): Deleted.
(JSC::DFG::Node::hasFunctionExprIndex): Deleted.
(JSC::DFG::Node::functionExprIndex): Deleted.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewFunctionNoCheck):
(JSC::DFG::SpeculativeJIT::compileNewFunctionExpression):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGWatchpointCollectionPhase.cpp:
(JSC::DFG::WatchpointCollectionPhase::handle):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileCheckCell):
(JSC::FTL::LowerDFGToLLVM::compileNativeCallOrConstruct):
2015-03-03 Michael Saboff <msaboff@apple.com>
DelayedReleaseScope drops locks during GC which can cause a thread switch and code reentry
https://bugs.webkit.org/show_bug.cgi?id=141275
Reviewed by Geoffrey Garen.
The original issue is that the CodeCache uses an unsafe method to add new UnlinkedCodeBlocks.
It basically adds a null UnlinkedCodeBlock if there isn't a cached entry and then later
updates the null entry to the result of the compilation. If during that compilation and
related processing we need to garbage collect, the DelayedReleaseScope would drop locks
possibly allowing another thread to try to get the same source out of the CodeCache.
This second thread would find the null entry and crash. The fix is to move the processing of
DelayedReleaseScope to when we drop locks and not drop locks during GC. That was done in
the original patch with the new function releaseDelayedReleasedObjects().
Updated releaseDelayedReleasedObjects() so that objects are released with all locks
dropped. Now its processing follows these steps
Increment recursion counter and do recursion check and exit if recursing
While there are objects to release
ASSERT that lock is held by current thread
Take all items from delayed release Vector and put into temporary Vector
Release API lock
Release and clear items from temporary vector
Reaquire API lock
This meets the requirement that we release while the API lock is released and it is
safer processing of the delayed release Vector.
Added new regression test to testapi.
Also added comment describing how recursion into releaseDelayedReleasedObjects() is
prevented.
* API/tests/Regress141275.h: Added.
* API/tests/Regress141275.mm: Added.
(+[JSTEvaluatorTask evaluatorTaskWithEvaluateBlock:completionHandler:]):
(-[JSTEvaluator init]):
(-[JSTEvaluator initWithScript:]):
(-[JSTEvaluator _accessPendingTasksWithBlock:]):
(-[JSTEvaluator insertSignPostWithCompletion:]):
(-[JSTEvaluator evaluateScript:completion:]):
(-[JSTEvaluator evaluateBlock:completion:]):
(-[JSTEvaluator waitForTasksDoneAndReportResults]):
(__JSTRunLoopSourceScheduleCallBack):
(__JSTRunLoopSourcePerformCallBack):
(__JSTRunLoopSourceCancelCallBack):
(-[JSTEvaluator _jsThreadMain]):
(-[JSTEvaluator _sourceScheduledOnRunLoop:]):
(-[JSTEvaluator _setupEvaluatorThreadContextIfNeeded]):
(-[JSTEvaluator _callCompletionHandler:ifNeededWithError:]):
(-[JSTEvaluator _sourcePerform]):
(-[JSTEvaluator _sourceCanceledOnRunLoop:]):
(runRegress141275):
* API/tests/testapi.mm:
(testObjectiveCAPI):
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/Heap.cpp:
(JSC::Heap::releaseDelayedReleasedObjects):
* runtime/JSLock.cpp:
(JSC::JSLock::unlock):
2015-03-03 Filip Pizlo <fpizlo@apple.com>
DFG should constant fold GetScope, and accesses to the scope register in the ByteCodeParser should not pretend that it's a constant as that breaks OSR exit liveness tracking
https://bugs.webkit.org/show_bug.cgi?id=106202
Rubber stamped by Benjamin Poulain.
This fixes a bug discovered by working on https://bugs.webkit.org/show_bug.cgi?id=142229,
which was in turn discovered by working on https://bugs.webkit.org/show_bug.cgi?id=141174.
Our way of dealing with scopes known to be constant is very sketchy, and only really works
when a function is inlined. When it is, we pretend that every load of the scopeRegister sees
a constant. But this breaks the DFG's tracking of the liveness of the scopeRegister. The way
this worked made us miss oppportunities for optimizing based on a constant scope, and it also
meant that in some cases - particularly like when we inline code that uses NewFuction and
friends, as I do in bug 142229 - it makes OSR exit think that the scope is dead even though
it's most definitely alive and it's a constant.
The problem here is that we were doing too many optimizations in the ByteCodeParser, and not
later. Later optimization phases know how to preserve OSR exit liveness. They're actually
really good at it. Also, later phases know how to infer that any variable is a constant no
matter how that constant arose - rather than the inlining-specific thing in ByteCodeParser.
This changes the ByteCodeParser to largely avoid doing constant folding on the scope, except
making the GetScope operation itself a constant. This is a compilation-time hack for small
functions, and it doesn't break the loads of local variables - so OSR exit liveness still
sees that the scopeRegister is in use. This then adds a vastly more powerful GetScope and
GetClosureVar constant folder in the AbstractInterpreter. This handles most general cases
including those that arise in complex control flow. This will catch cases where the scope
is constant for any number of reasons. Basically anytime that the callee is inferred constant
this will give us a constant scope. Also, we still have the parse-time constant folding of
ResolveScope based on the reentry watchpoint, which luckily did the right thing with respect
to OSR exit liveness (it splats a Phantom on its inputs, and it produces a constant result
which is then set() normally).
This appears to be a broad speed-up, albeit a small one. But mainly it unblocks bug 142229,
which then should unblock bug 141174.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::get):
(JSC::DFG::ByteCodeParser::getLocal):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::parse):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::tryGetConstantClosureVar):
(JSC::DFG::Graph::tryGetRegisters):
(JSC::DFG::Graph::tryGetActivation): Deleted.
* dfg/DFGGraph.h:
* dfg/DFGNode.h:
(JSC::DFG::Node::hasVariableWatchpointSet):
(JSC::DFG::Node::hasSymbolTable): Deleted.
(JSC::DFG::Node::symbolTable): Deleted.
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGWatchpointCollectionPhase.cpp:
(JSC::DFG::WatchpointCollectionPhase::handle):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileGetClosureVar):
* runtime/SymbolTable.cpp:
(JSC::SymbolTable::visitChildren):
(JSC::SymbolTable::localToEntry):
(JSC::SymbolTable::entryFor):
* runtime/SymbolTable.h:
(JSC::SymbolTable::add):
(JSC::SymbolTable::set):
* tests/stress/function-expression-exit.js: Added.
* tests/stress/function-reentry-infer-on-self.js: Added.
(thingy):
* tests/stress/goofy-function-reentry-incorrect-inference.js: Added.
2015-03-03 Anders Carlsson <andersca@apple.com>
Remove unused compression code
https://bugs.webkit.org/show_bug.cgi?id=142237
Reviewed by Geoffrey Garen.
* bytecode/UnlinkedCodeBlock.h:
2015-03-03 Filip Pizlo <fpizlo@apple.com>
JIT debugging features that selectively disable the JITs for code blocks need to stay out of the way of the critical path of JIT management
https://bugs.webkit.org/show_bug.cgi?id=142234
Reviewed by Mark Lam and Benjamin Poulain.
Long ago, we used to selectively disable compilation of CodeBlocks for debugging purposes by
adding hacks to DFGDriver.cpp. This was all well and good. It used the existing
CompilationFailed mode of the DFG driver to signal failure of CodeBlocks that we didn't want
to compile. That's great because CompilationFailed is a well-supported return value on the
critical path, usually used for when we run out of JIT memory.
Later, this was moved into DFGCapabilities. This was basically incorrect. It introduced a bug
where disabling compiling of a CodeBlock meant that we stopped inlining it as well. So if
you had a compiler bug that arose if foo was inlined into bar, and you bisected down to bar,
then foo would no longer get inlined and you wouldn't see the bug. That's busted.
So then we changed the code in DFGCapabilities to mark bar as CanCompile and foo as
CanInline. Now, foo wouldn't get compiled alone but it would get inlined.
But then we removed CanCompile because that capability mode only existed for the purpose of
our old varargs hacks. After that removal, "CanInline" became CannotCompile. This means
that if you bisect down on bar in the "foo inlined into bar" case, you'll crash in the DFG
because the baseline JIT wouldn't have known to insert profiling on foo.
We could fix this by bringing back CanInline.
But this is all a pile of nonsense. The debug support to selectively disable compilation of
some CodeBlocks shouldn't cross-cut our entire engine and should most certainly never involve
adding new capability modes. This support is a hack at best and is for use by JSC hackers
only. It should be as unintrusive as possible.
So, as in the ancient times, the only proper place to put this hack is in DFGDriver.cpp, and
return CompilationFailed. This is correct not just because it takes capability modes out of
the picture (and obviates the need to introduce new ones), but also because it means that
disabling compilation doesn't change the profiling mode of other CodeBlocks in the Baseline
JIT. Capability mode influences profiling mode which in turn influences code generation in
the Baseline JIT, sometimes in very significant ways - like, we sometimes do additional
double-to-int conversions in Baseline if we know that we might tier-up into the DFG, since
this buys us more precise profiling.
This change reduces the intrusiveness of debugging hacks by making them use the very simple
CompilationFailed mechanism rather than trying to influence capability modes. Capability
modes have very subtle effects on the whole engine, while CompilationFailed just makes the
engine pretend like the DFG compilation will happen at timelike infinity. That makes these
hacks much more likely to continue working as we make other changes to the system.
This brings back the ability to bisect down onto a function bar when bar inlines foo. Prior
to this change, we would crash in that case.
* dfg/DFGCapabilities.cpp:
(JSC::DFG::isSupported):
(JSC::DFG::mightCompileEval):
(JSC::DFG::mightCompileProgram):
(JSC::DFG::mightCompileFunctionForCall):
(JSC::DFG::mightCompileFunctionForConstruct):
* dfg/DFGCapabilities.h:
* dfg/DFGDriver.cpp:
(JSC::DFG::compileImpl):
2015-03-03 peavo@outlook.com <peavo@outlook.com>
[Win64] JSC compile error.
https://bugs.webkit.org/show_bug.cgi?id=142216
Reviewed by Mark Lam.
There is missing a version of setupArgumentsWithExecState when NUMBER_OF_ARGUMENT_REGISTERS == 4.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState):
2015-03-02 Filip Pizlo <fpizlo@apple.com>
DFG compile time measurements should really report milliseconds
https://bugs.webkit.org/show_bug.cgi?id=142209
Reviewed by Benjamin Poulain.
Fix this to record milliseconds instead of seconds.
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThread):
(JSC::DFG::Plan::compileInThreadImpl):
2015-03-02 Filip Pizlo <fpizlo@apple.com>
Remove op_get_callee, it's unused
https://bugs.webkit.org/show_bug.cgi?id=142206
Reviewed by Andreas Kling.
It's a bit of a shame that we stopped using this opcode since it gives us same-callee
profiling. But, if we were to add this functionality back in, we would almost certainly do
it by adding a JSFunction allocation watchpoint on FunctionExecutable.
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::finalizeUnconditionally):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_get_callee): Deleted.
(JSC::JIT::emitSlow_op_get_callee): Deleted.
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_get_callee): Deleted.
(JSC::JIT::emitSlow_op_get_callee): Deleted.
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL): Deleted.
2015-03-02 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Context Menu to Log a Particular Object
https://bugs.webkit.org/show_bug.cgi?id=142198
Reviewed by Timothy Hatcher.
Add a protocol method to assign a $n index to a value. For an object
use the injected script context for that object. For a value, use
the execution context to know where to save the value.
* inspector/InjectedScript.cpp:
(Inspector::InjectedScript::saveResult):
* inspector/InjectedScript.h:
* inspector/InjectedScriptSource.js:
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::saveResult):
* inspector/agents/InspectorRuntimeAgent.h:
* inspector/protocol/Debugger.json:
* inspector/protocol/Runtime.json:
2015-03-02 Filip Pizlo <fpizlo@apple.com>
SpeculativeJIT::emitAllocateArguments() should be a bit faster, and shouldn't do destructor initialization
https://bugs.webkit.org/show_bug.cgi?id=142197
Reviewed by Geoffrey Garen.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitAllocateArguments): Use shift instead of mul, since mul doesn't automatically strength-reduce to shift. Also pass the structure as a TrustedImmPtr.
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject): Rationalize this a bit. The other emitAllocate... methods take a templated structure so that it can be either a TrustedImmPtr or a register. Also don't do destructor initialization, since its one client doesn't need it, and it's actually probably wrong.
2015-03-02 Mark Lam <mark.lam@apple.com>
Exception stack unwinding in JSC hangs while the Timeline Profiler is enabled.
<https://webkit.org/b/142191>
Reviewed by Geoffrey Garen.
Imagine a scenario where the Inspector is paused / suspended at a breakpoint or
while the user is stepping through JS code. The user then tries to evaluate an
expression in the console, and that evaluation results in an exception being
thrown. Currently, if the Timeline Profiler is enabled while this exception is
being thrown, the WebProcess will hang while trying to handle that exception.
The issue is that the Timeline Profiler's ProfileGenerator::didExecute() will
return early and decline to process ProfileNodes if the Inspector is paused.
This is proper because it does not want to count work done for injected scripts
(e.g. from the console) towards the timeline profile of the webpage being run.
However, this is in conflict with ProfileGenerator::exceptionUnwind()'s
expectation that didExecute() will process ProfileNodes in order to do the stack
unwinding for the exception handling. As a result,
ProfileGenerator::exceptionUnwind() hangs.
ProfileGenerator::exceptionUnwind() is in error. While the Inspector is paused,
there will not be any ProfileNodes that it needs to "unwind". Hence, the fix is
simply to return early also in ProfileGenerator::exceptionUnwind() if the
Inspector is paused.
* profiler/ProfileGenerator.cpp:
(JSC::ProfileGenerator::exceptionUnwind):
2015-03-02 Filip Pizlo <fpizlo@apple.com>
FTL should correctly document where it puts the argument count for inlined varargs frames
https://bugs.webkit.org/show_bug.cgi?id=142187
Reviewed by Geoffrey Garn.
After LLVM tells us where the captured variables alloca landed in the frame, we need to
tell all of our meta-data about it. We were forgetting to do so for the argument count
register, which is used by inlined varargs calls.
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* tests/stress/inline-varargs-get-arguments.js: Added.
(foo):
(bar):
(baz):
2015-03-02 Filip Pizlo <fpizlo@apple.com>
Deduplicate slow path calling code in JITOpcodes.cpp/JITOpcodes32_64.cpp
https://bugs.webkit.org/show_bug.cgi?id=142184
Reviewed by Michael Saboff.
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_get_enumerable_length):
(JSC::JIT::emitSlow_op_has_structure_property):
(JSC::JIT::emit_op_has_generic_property):
(JSC::JIT::emit_op_get_structure_property_enumerator):
(JSC::JIT::emit_op_get_generic_property_enumerator):
(JSC::JIT::emit_op_to_index_string):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_get_enumerable_length): Deleted.
(JSC::JIT::emitSlow_op_has_structure_property): Deleted.
(JSC::JIT::emit_op_has_generic_property): Deleted.
(JSC::JIT::emit_op_get_structure_property_enumerator): Deleted.
(JSC::JIT::emit_op_get_generic_property_enumerator): Deleted.
(JSC::JIT::emit_op_to_index_string): Deleted.
(JSC::JIT::emit_op_profile_control_flow): Deleted.
2015-03-02 Antti Koivisto <antti@apple.com>
Add way to dump cache meta data to file
https://bugs.webkit.org/show_bug.cgi?id=142183
Reviewed by Andreas Kling.
Export appendQuotedJSONStringToBuilder.
* bytecompiler/NodesCodegen.cpp:
(JSC::ObjectPatternNode::toString):
* runtime/JSONObject.cpp:
(JSC::appendQuotedJSONStringToBuilder):
(JSC::Stringifier::appendQuotedString):
(JSC::escapeStringToBuilder): Deleted.
* runtime/JSONObject.h:
2015-03-02 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Add Context Menus to Object Tree properties
https://bugs.webkit.org/show_bug.cgi?id=142125
Reviewed by Timothy Hatcher.
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::functionDetails):
Update to include columnNumber.
2015-03-01 Filip Pizlo <fpizlo@apple.com>
BytecodeGenerator shouldn't emit op_resolve_scope as a roundabout way of returning the scopeRegister
https://bugs.webkit.org/show_bug.cgi?id=142153
Reviewed by Michael Saboff.
We don't need a op_resolve_scope if we know that it will simply return the scope register.
This changes the BytecodeGenerator to use the scope register directly in those cases where
we know statically that we would just have returned that from op_resolve_scope.
This doesn't appear to have a significant impact on performance.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitResolveScope):
(JSC::BytecodeGenerator::emitReturn):
(JSC::BytecodeGenerator::emitGetOwnScope): Deleted.
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ResolveNode::emitBytecode):
(JSC::EvalFunctionCallNode::emitBytecode):
(JSC::FunctionCallResolveNode::emitBytecode):
(JSC::PostfixNode::emitResolve):
(JSC::DeleteResolveNode::emitBytecode):
(JSC::TypeOfResolveNode::emitBytecode):
(JSC::PrefixNode::emitResolve):
(JSC::ReadModifyResolveNode::emitBytecode):
(JSC::AssignResolveNode::emitBytecode):
(JSC::ConstDeclNode::emitCodeSingle):
(JSC::EmptyVarExpression::emitBytecode):
(JSC::ForInNode::emitLoopHeader):
(JSC::ForOfNode::emitBytecode):
(JSC::BindingNode::bindValue):
2015-02-27 Benjamin Poulain <bpoulain@apple.com>
[JSC] Use the way number constants are written to help type speculation
https://bugs.webkit.org/show_bug.cgi?id=142072
Reviewed by Filip Pizlo.
This patch changes how we interpret numeric constant based on how they appear
in the source.
Constants that are integers but written with a decimal point now carry that information
to the optimizating tiers. From there, we use that to be more aggressive about typing
math operations toward double operations.
For example, in:
var a = x + 1.0;
var b = y + 1;
The Add for a would be biased toward doubles, the Add for b would speculate
integer as usual.
The gains are tiny but this is a prerequisite to make my next patch useful:
-SunSpider's access-fannkuch: definitely 1.0661x faster
-SunSpider's math-cordic: definitely 1.0266x slower
overal: might be 1.0066x slower.
-Kraken's imaging-darkroom: definitely 1.0333x faster.
* parser/Lexer.cpp:
(JSC::tokenTypeForIntegerLikeToken):
(JSC::Lexer<T>::lex):
The lexer now create two types of tokens for number: INTEGER and DOUBLE.
Those token types only carry information about how the values were
entered, an INTEGER does not have to be an integer, it is only written like one.
Large integer still end up represented as double in memory.
One trap I fell into was typing numbers like 12e3 as double. This kind of literal
is frequently used in integer-typed code, while 12.e3 would appear in double-typed
code.
Because of that, the only signals for double are: decimal point, negative zero,
and ridiculously large values.
* parser/NodeConstructors.h:
(JSC::DoubleNode::DoubleNode):
(JSC::IntegerNode::IntegerNode):
* parser/Nodes.h:
(JSC::NumberNode::value):
(JSC::NumberNode::setValue): Deleted.
Number get specialized in two new kind of nodes in the AST: IntegerNode and DoubleNode.
* bytecompiler/NodesCodegen.cpp:
(JSC::NumberNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createDoubleExpr):
(JSC::ASTBuilder::createIntegerExpr):
(JSC::ASTBuilder::createIntegerLikeNumber):
(JSC::ASTBuilder::createDoubleLikeNumber):
(JSC::ASTBuilder::createNumberFromBinaryOperation):
(JSC::ASTBuilder::createNumberFromUnaryOperation):
(JSC::ASTBuilder::makeNegateNode):
(JSC::ASTBuilder::makeBitwiseNotNode):
(JSC::ASTBuilder::makeMultNode):
(JSC::ASTBuilder::makeDivNode):
(JSC::ASTBuilder::makeModNode):
(JSC::ASTBuilder::makeAddNode):
(JSC::ASTBuilder::makeSubNode):
(JSC::ASTBuilder::makeLeftShiftNode):
(JSC::ASTBuilder::makeRightShiftNode):
(JSC::ASTBuilder::makeURightShiftNode):
(JSC::ASTBuilder::makeBitOrNode):
(JSC::ASTBuilder::makeBitAndNode):
(JSC::ASTBuilder::makeBitXOrNode):
(JSC::ASTBuilder::createNumberExpr): Deleted.
(JSC::ASTBuilder::createNumber): Deleted.
The AST has some optimization to resolve constants before emitting bytecode.
In the new code, the intger representation is kept if both operands where
also represented as integers.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseDeconstructionPattern):
(JSC::Parser<LexerType>::parseProperty):
(JSC::Parser<LexerType>::parseGetterSetter):
(JSC::Parser<LexerType>::parsePrimaryExpression):
(JSC::Parser<LexerType>::printUnexpectedTokenText):
* parser/ParserTokens.h:
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createDoubleExpr):
(JSC::SyntaxChecker::createIntegerExpr):
(JSC::SyntaxChecker::createNumberExpr): Deleted.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::registerName):
(JSC::CodeBlock::constantName):
Change constantName(r, getConstant(r)) -> constantName(r) to simplify
the dump code.
(JSC::CodeBlock::dumpBytecode):
Dump thre soure representation information we have with each constant.
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::shrinkToFit):
(JSC::constantName): Deleted.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::constantsSourceCodeRepresentation):
(JSC::CodeBlock::addConstant):
(JSC::CodeBlock::addConstantLazily):
(JSC::CodeBlock::constantSourceCodeRepresentation):
(JSC::CodeBlock::setConstantRegisters):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::addConstant):
(JSC::UnlinkedCodeBlock::constantsSourceCodeRepresentation):
(JSC::UnlinkedCodeBlock::shrinkToFit):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::addConstantValue):
(JSC::BytecodeGenerator::emitLoad):
* bytecompiler/BytecodeGenerator.h:
We have to differentiate between constants that have the same values but are
represented differently in the source. Values like 1.0 and 1 now end up
as different constants.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::get):
(JSC::DFG::ByteCodeParser::addConstantToGraph):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::registerFrozenValues):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::addSpeculationMode):
(JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
ArithAdd is very aggressive toward using Int52, which is quite useful
in many benchmarks.
Here we need to specialize to make sure we don't force our literals
to Int52 if there were represented as double.
There is one exception to that rule: when the other operand is guaranteed
to come from a NodeResultInt32. This is because there is some weird code
doing stuff like:
var b = a|0;
var c = b*2.0;
* dfg/DFGNode.h:
(JSC::DFG::Node::Node):
(JSC::DFG::Node::setOpAndDefaultFlags):
(JSC::DFG::Node::sourceCodeRepresentation):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* runtime/JSCJSValue.h:
(JSC::EncodedJSValueWithRepresentationHashTraits::emptyValue):
(JSC::EncodedJSValueWithRepresentationHashTraits::constructDeletedValue):
(JSC::EncodedJSValueWithRepresentationHashTraits::isDeletedValue):
(JSC::EncodedJSValueWithRepresentationHash::hash):
(JSC::EncodedJSValueWithRepresentationHash::equal):
* tests/stress/arith-add-with-constants.js: Added.
* tests/stress/arith-mul-with-constants.js: Added.
2015-02-26 Filip Pizlo <fpizlo@apple.com>
Unreviewed, roll out r180723. It broke a bunch of tests.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::constLocal):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ConstDeclNode::emitCodeSingle):
* tests/stress/const-arguments.js: Removed.
2015-02-26 Mark Lam <mark.lam@apple.com>
Assertion fix for r180711: The bool returning form of BytecodeGenerator::addVar() can be removed.
<https://webkit.org/b/142064>
Reviewed by Joseph Pecoraro.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::addVar):
2015-02-26 Mark Lam <mark.lam@apple.com>
MachineThreads::Thread clean up has a use after free race condition.
<https://webkit.org/b/141990>
Reviewed by Filip Pizlo.
MachineThreads::Thread clean up relies on the clean up mechanism
implemented in _pthread_tsd_cleanup_key(), which looks like this:
void _pthread_tsd_cleanup_key(pthread_t self, pthread_key_t key)
{
void (*destructor)(void *);
if (_pthread_key_get_destructor(key, &destructor)) {
void **ptr = &self->tsd[key];
void *value = *ptr;
// === Start of window for the bug to manifest =================
// At this point, this thread has cached "destructor" and "value"
// (which is a MachineThreads*). If the VM gets destructed (along
// with its MachineThreads registry) by another thread, then this
// thread will have no way of knowing that the MachineThreads* is
// now pointing to freed memory. Calling the destructor below will
// therefore result in a use after free scenario when it tries to
// access the MachineThreads' data members.
if (value) {
*ptr = NULL;
if (destructor) {
// === End of window for the bug to manifest ==================
destructor(value);
}
}
}
}
The fix is to add each active MachineThreads to an ActiveMachineThreadsManager,
and always check if the manager still contains that MachineThreads object
before we call removeCurrentThread() on it. When MachineThreads is destructed,
it will remove itself from the manager. The add, remove, and checking
operations are all synchronized on the manager's lock, thereby ensuring that
the MachineThreads object, if found in the manager, will remain alive for the
duration of time we call removeCurrentThread() on it.
There's also possible for the MachineThreads object to already be destructed
and another one happened to have been instantiated at the same address.
Hence, we should only remove the exiting thread if it is found in the
MachineThreads object.
There is no test for this issue because this bug requires a race condition
between 2 threads where:
1. Thread B, which had previously used the VM, exiting and
getting to the bug window shown in _pthread_tsd_cleanup_key() above.
2. Thread A destructing the VM (and its MachineThreads object)
within that window of time before Thread B calls the destructor.
It is not possible to get a reliable test case without invasively
instrumenting _pthread_tsd_cleanup_key() or MachineThreads::removeCurrentThread()
to significantly increase that window of opportunity.
* heap/MachineStackMarker.cpp:
(JSC::ActiveMachineThreadsManager::Locker::Locker):
(JSC::ActiveMachineThreadsManager::add):
(JSC::ActiveMachineThreadsManager::remove):
(JSC::ActiveMachineThreadsManager::contains):
(JSC::ActiveMachineThreadsManager::ActiveMachineThreadsManager):
(JSC::activeMachineThreadsManager):
(JSC::MachineThreads::MachineThreads):
(JSC::MachineThreads::~MachineThreads):
(JSC::MachineThreads::removeThread):
(JSC::MachineThreads::removeThreadIfFound):
(JSC::MachineThreads::removeCurrentThread): Deleted.
* heap/MachineStackMarker.h:
2015-02-26 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Save Console Evaluations into Command Line variables $1-$99 ($n)
https://bugs.webkit.org/show_bug.cgi?id=142061
Reviewed by Timothy Hatcher.
* inspector/protocol/Debugger.json:
* inspector/protocol/Runtime.json:
Input flag "saveResult" on whether we should try to save a result.
Output int "savedResultIndex" to tell the frontend the saved state.
* inspector/InjectedScriptSource.js:
Handle saving and clearing $1-$99 values.
Include in BasicCommandLineAPI for JSContext inspection.
* inspector/InjectedScriptBase.cpp:
(Inspector::InjectedScriptBase::makeEvalCall):
* inspector/InjectedScriptBase.h:
Allow an optional "savedResultIndex" out value on evals.
* inspector/InjectedScript.cpp:
(Inspector::InjectedScript::evaluate):
(Inspector::InjectedScript::evaluateOnCallFrame):
* inspector/InjectedScript.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::evaluateOnCallFrame):
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::evaluate):
* inspector/agents/InspectorRuntimeAgent.h:
Plumbing for new in and out parameters.
2015-02-26 Filip Pizlo <fpizlo@apple.com>
The bool returning form of BytecodeGenerator::addVar() can be removed
https://bugs.webkit.org/show_bug.cgi?id=142064
Reviewed by Mark Lam.
It's easier to implement addVar() when you don't have to return whether it's a new
variable or not.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::addVar):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::addVar): Deleted.
2015-02-26 Filip Pizlo <fpizlo@apple.com>
Various array access corner cases should take OSR exit feedback
https://bugs.webkit.org/show_bug.cgi?id=142056
Reviewed by Geoffrey Garen.
Two major changes here:
- Don't keep converting GetById into GetArrayLength if we exited due to any kind of array
type check.
- Use a generic form of GetByVal/PutByVal if we exited due to any kind of exotic checks,
like the Arguments safety checks. We use the "ExoticObjectMode" for out-of-bounds on
arguments for now, since it's a convenient way of forcing out-of-bounds to be handled by
the Generic array mode.
* bytecode/ExitKind.cpp:
(JSC::exitKindToString):
* bytecode/ExitKind.h:
* dfg/DFGArrayMode.cpp:
(JSC::DFG::ArrayMode::refine):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByValOnArguments):
(JSC::DFG::SpeculativeJIT::compileGetArgumentsLength):
* tests/stress/array-length-array-storage-plain-object.js: Added.
(foo):
* tests/stress/array-length-plain-object.js: Added.
(foo):
2015-02-25 Filip Pizlo <fpizlo@apple.com>
DFG SSA stack accesses shouldn't speak of VariableAccessDatas
https://bugs.webkit.org/show_bug.cgi?id=142036
Reviewed by Michael Saboff.
VariableAccessData is a useful thing in LoadStore and ThreadedCPS, but it's purely harmful in
SSA because you can't cook up new VariableAccessDatas. So, if you know that you want to load
or store to the stack, and you know what format to use as well as the location, then prior to
this patch you couldn't do it unless you found some existing VariableAccessData that matched
your requirements. That can be a hard task.
It's better if SSA doesn't speak of VariableAccessDatas but instead just has stack accesses
that speak of the things that a stack access needs: local, machineLocal, and format. This
patch changes the SSA way of accessing the stack to do just that.
Also add more IR validation.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGFlushFormat.h:
(JSC::DFG::isConcrete):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
* dfg/DFGGraph.h:
* dfg/DFGMayExit.cpp:
(JSC::DFG::mayExit):
* dfg/DFGNode.cpp:
(JSC::DFG::Node::hasVariableAccessData):
* dfg/DFGNode.h:
(JSC::DFG::StackAccessData::StackAccessData):
(JSC::DFG::StackAccessData::flushedAt):
(JSC::DFG::Node::convertToPutStack):
(JSC::DFG::Node::convertToGetStack):
(JSC::DFG::Node::hasUnlinkedLocal):
(JSC::DFG::Node::hasStackAccessData):
(JSC::DFG::Node::stackAccessData):
(JSC::DFG::Node::willHaveCodeGenOrOSR):
* dfg/DFGNodeType.h:
* dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
(JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGPutLocalSinkingPhase.cpp: Removed.
* dfg/DFGPutLocalSinkingPhase.h: Removed.
* dfg/DFGPutStackSinkingPhase.cpp: Copied from Source/JavaScriptCore/dfg/DFGPutLocalSinkingPhase.cpp.
(JSC::DFG::performPutStackSinking):
(JSC::DFG::performPutLocalSinking): Deleted.
* dfg/DFGPutStackSinkingPhase.h: Copied from Source/JavaScriptCore/dfg/DFGPutLocalSinkingPhase.h.
* dfg/DFGSSAConversionPhase.cpp:
(JSC::DFG::SSAConversionPhase::run):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStackLayoutPhase.cpp:
(JSC::DFG::StackLayoutPhase::run):
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::validate):
(JSC::DFG::Validate::validateCPS):
(JSC::DFG::Validate::validateSSA):
* dfg/DFGVirtualRegisterAllocationPhase.cpp:
(JSC::DFG::VirtualRegisterAllocationPhase::run):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::lower):
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileGetStack):
(JSC::FTL::LowerDFGToLLVM::compilePutStack):
(JSC::FTL::LowerDFGToLLVM::compileGetLocal): Deleted.
(JSC::FTL::LowerDFGToLLVM::compilePutLocal): Deleted.
* ftl/FTLOSRExit.h:
* tests/stress/many-sunken-locals.js: Added. This failure mode was caught by some miscellaneous test, so I figured I should write an explicit test for it.
(foo):
(bar):
(baz):
(fuzz):
(buzz):
2015-02-26 Mark Lam <mark.lam@apple.com>
Rolling out r180602, r180608, r180613, r180617, r180671.
<https://webkit.org/b/141990>
Not reviewed.
The r180602 solution does result in more work for GC when worker
threads are in use. Filip is uncomfortable with that.
The EFL and GTK ports also seem to be unhappy with this change.
Rolling out while we investigate.
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::gatherStackRoots):
(JSC::Heap::machineThreads): Deleted.
* heap/Heap.h:
(JSC::Heap::machineThreads):
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::MachineThreads):
(JSC::MachineThreads::~MachineThreads):
(JSC::MachineThreads::addCurrentThread):
* heap/MachineStackMarker.h:
* runtime/JSLock.cpp:
(JSC::JSLock::didAcquireLock):
2015-02-26 Myles C. Maxfield <mmaxfield@apple.com>
[Mac] [iOS] Parsing support for -apple-trailing-word
https://bugs.webkit.org/show_bug.cgi?id=141939
Reviewed by Andreas Kling.
* Configurations/FeatureDefines.xcconfig:
2015-02-26 Michael Saboff <msaboff@apple.com>
[Win] Debug-only JavaScriptCore failures
https://bugs.webkit.org/show_bug.cgi?id=142045
Rubber stamped by Filip Pizlo.
Reduced loop count to a more reasonable value of 10,000. This still gets us to tier up
to the FTL, but doesn't take too long to run.
* tests/stress/repeated-arity-check-fail.js:
2015-02-26 Brent Fulgham <bfulgham@apple.com>
[Win] Make build logs more legible by reducing noise
https://bugs.webkit.org/show_bug.cgi?id=142034
Reviewed by Alexey Proskuryakov.
Modify batch files, makefiles, and DOS commands to remove
uninteresting/unhelpful output.
* JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make:
* JavaScriptCore.vcxproj/JavaScriptCorePreBuild.cmd:
* JavaScriptCore.vcxproj/copy-files.cmd:
* JavaScriptCore.vcxproj/jsc/jscLauncherPreBuild.cmd:
* JavaScriptCore.vcxproj/jsc/jscPreBuild.cmd:
* JavaScriptCore.vcxproj/testRegExp/testRegExpLauncherPreBuild.cmd:
* JavaScriptCore.vcxproj/testRegExp/testRegExpPreBuild.cmd:
* JavaScriptCore.vcxproj/testapi/testapiLauncherPostBuild.cmd:
* JavaScriptCore.vcxproj/testapi/testapiLauncherPreBuild.cmd:
* JavaScriptCore.vcxproj/testapi/testapiPostBuild.cmd:
* JavaScriptCore.vcxproj/testapi/testapiPreBuild.cmd:
2015-02-26 Csaba Osztrogonác <ossy@webkit.org>
Add calleeSaveRegisters() implementation for ARM Traditional
https://bugs.webkit.org/show_bug.cgi?id=141903
Reviewed by Darin Adler.
* jit/RegisterSet.cpp:
(JSC::RegisterSet::calleeSaveRegisters):
2015-02-25 Michael Saboff <msaboff@apple.com>
Web Inspector: CRASH when debugger pauses inside a Promise handler
https://bugs.webkit.org/show_bug.cgi?id=141396
Reviewed by Mark Lam.
For frames that don't have a scope, typically native frames, use the lexicalGlobalObject to
create the DebuggerScope for that frame.
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::scope):
2015-02-25 Filip Pizlo <fpizlo@apple.com>
DFG abstract heaps should respect the difference between heap and stack
https://bugs.webkit.org/show_bug.cgi?id=142022
Reviewed by Geoffrey Garen.
We will soon (https://bugs.webkit.org/show_bug.cgi?id=141174) be in a world where a "world
clobbering" operation cannot write to our stack, but may be able to read from it. This
means that we need to change the DFG abstract heap hierarchy to have a notion of Heap that
subsumes all that World previously subsumed, and a new notion of Stack that is a subtype
of World and a sibling of Heap.
So, henceforth "clobbering the world" means reading World and writing Heap.
This makes a bunch of changes to make this work, including changing the implementation of
disjointness in AbstractHeap to make it support a more general hierarchy. I was expecting
a slow-down, but I measured the heck out of this and found no perf difference.
* dfg/DFGAbstractHeap.cpp:
(JSC::DFG::AbstractHeap::dump):
* dfg/DFGAbstractHeap.h:
(JSC::DFG::AbstractHeap::supertype):
(JSC::DFG::AbstractHeap::isStrictSubtypeOf):
(JSC::DFG::AbstractHeap::isSubtypeOf):
(JSC::DFG::AbstractHeap::overlaps):
(JSC::DFG::AbstractHeap::isDisjoint):
* dfg/DFGClobberize.cpp:
(JSC::DFG::clobbersHeap):
(JSC::DFG::clobbersWorld): Deleted.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
2015-02-25 Ryosuke Niwa <rniwa@webkit.org>
REGRESSION(r180595): construct varargs fails in FTL
https://bugs.webkit.org/show_bug.cgi?id=142030
Reviewed by Geoffrey Garen.
The bug was caused by IC size being too small for construct_varargs even though we've added a new argument.
Fixed the bug by increasing the IC size to match call_varargs.
* ftl/FTLInlineCacheSize.cpp:
(JSC::FTL::sizeOfConstructVarargs):
2015-02-25 Mark Lam <mark.lam@apple.com>
ASan does not like JSC::MachineThreads::tryCopyOtherThreadStack.
<https://webkit.org/b/141672>
Reviewed by Alexey Proskuryakov.
ASan does not like the fact that we memcpy the stack for GC scans. So,
we're working around this by using our own memcpy (asanUnsafeMemcpy)
implementation that we can tell ASan to ignore.
* heap/MachineStackMarker.cpp:
(JSC::asanUnsafeMemcpy):
2015-02-25 Benjamin Poulain <bpoulain@apple.com>
CodeBlock crashes when dumping op_push_name_scope
https://bugs.webkit.org/show_bug.cgi?id=141953
Reviewed by Filip Pizlo and Csaba Osztrogonác.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* tests/stress/op-push-name-scope-crashes-profiler.js: Added.
2015-02-25 Benjamin Poulain <benjamin@webkit.org>
Make ParserError immutable by design
https://bugs.webkit.org/show_bug.cgi?id=141955
Reviewed by Geoffrey Garen.
This patch enforce that no field of ParserError can
be modified after the constructor.
* parser/ParserError.h:
Move the attributes to pack the integer + 2 bytes together.
This is irrelevant for memory impact, it is to remve a load-store
when copying by value.
Also move the attributes to be private.
(JSC::ParserError::isValid):
To client of the interface cared about the type of the error,
the only information needed was: is there an error.
(JSC::ParserError::ParserError):
(JSC::ParserError::syntaxErrorType):
(JSC::ParserError::token):
(JSC::ParserError::message):
(JSC::ParserError::line):
(JSC::ParserError::toErrorObject):
* API/JSScriptRef.cpp:
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createBuiltinExecutable):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedFunctionExecutable::codeBlockFor):
* bytecode/UnlinkedCodeBlock.h:
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::parse):
* jsc.cpp:
(runInteractive):
* parser/Parser.h:
(JSC::parse):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Completion.h:
* runtime/Executable.cpp:
(JSC::ProgramExecutable::checkSyntax):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
2015-02-25 Filip Pizlo <fpizlo@apple.com>
Need to pass RTLD_DEEPBIND to dlopen() to ensure that our LLVMOverrides take effect on Linux
https://bugs.webkit.org/show_bug.cgi?id=142006
Reviewed by Csaba Osztrogonác.
This fixes hard-to-reproduce concurrency-related crashes when running stress tests with FTL and
concurrent JIT enabled.
* llvm/InitializeLLVMPOSIX.cpp:
(JSC::initializeLLVMPOSIX):
2015-02-24 Filip Pizlo <fpizlo@apple.com>
CMake build of libllvmForJSC.so should limit its export list like the Xcode build does
https://bugs.webkit.org/show_bug.cgi?id=141989
Reviewed by Gyuyoung Kim.
* CMakeLists.txt:
* llvm/library/libllvmForJSC.version: Added.
2015-02-24 Alexey Proskuryakov <ap@apple.com>
More iOS build fix after r180602.
* heap/Heap.h: Export Heap::machineThreads().
2015-02-24 Brent Fulgham <bfulgham@apple.com>
Unreviewed build fix after r180602.
* heap/MachineStackMarker.h: Add missing 'no return'
declaration for Windows.
2015-02-24 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r180599.
https://bugs.webkit.org/show_bug.cgi?id=141998
Lots of new test failures (Requested by smfr on #webkit).
Reverted changeset:
"Parsing support for -webkit-trailing-word"
https://bugs.webkit.org/show_bug.cgi?id=141939
http://trac.webkit.org/changeset/180599
2015-02-24 Mark Lam <mark.lam@apple.com>
MachineThreads::Thread clean up has a use after free race condition.
<https://webkit.org/b/141990>
Reviewed by Michael Saboff.
MachineThreads::Thread clean up relies on the clean up mechanism
implemented in _pthread_tsd_cleanup_key(), which looks like this:
void _pthread_tsd_cleanup_key(pthread_t self, pthread_key_t key)
{
void (*destructor)(void *);
if (_pthread_key_get_destructor(key, &destructor)) {
void **ptr = &self->tsd[key];
void *value = *ptr;
// At this point, this thread has cached "destructor" and "value"
// (which is a MachineThreads*). If the VM gets destructed (along
// with its MachineThreads registry) by another thread, then this
// thread will have no way of knowing that the MachineThreads* is
// now pointing to freed memory. Calling the destructor below will
// therefore result in a use after free scenario when it tries to
// access the MachineThreads' data members.
if (value) {
*ptr = NULL;
if (destructor) {
destructor(value);
}
}
}
}
The solution is simply to change MachineThreads from a per VM thread
registry to a process global singleton thread registry i.e. the
MachineThreads registry is now immortal and we cannot have a use after
free scenario since we never free it.
The cost of this change is that all VM instances will have to scan
stacks of all threads ever touched by a VM, and not just those that
touched a specific VM. However, stacks tend to be shallow. Hence,
those additional scans will tend to be cheap.
Secondly, it is not common for there to be multiple JSC VMs in use
concurrently on multiple threads. Hence, this cost should rarely
manifest in real world applications.
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::machineThreads):
(JSC::Heap::gatherStackRoots):
* heap/Heap.h:
(JSC::Heap::machineThreads): Deleted.
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::MachineThreads):
(JSC::MachineThreads::~MachineThreads):
(JSC::MachineThreads::addCurrentThread):
* heap/MachineStackMarker.h:
* runtime/JSLock.cpp:
(JSC::JSLock::didAcquireLock):
2015-02-24 Myles C. Maxfield <mmaxfield@apple.com>
[Mac] [iOS] Parsing support for -apple-trailing-word
https://bugs.webkit.org/show_bug.cgi?id=141939
Reviewed by Andreas Kling.
* Configurations/FeatureDefines.xcconfig:
2015-02-24 Ryosuke Niwa <rniwa@webkit.org>
Use "this" instead of "callee" to get the constructor
https://bugs.webkit.org/show_bug.cgi?id=141019
Reviewed by Filip Pizlo.
This patch uses "this" register to pass the constructor (newTarget) to op_create_this from
op_construct or op_construct_varargs. This will allow future patches that implement ES6 class
to pass in the most derived class' constructor through "this" argument.
BytecodeGenerator's emitConstruct and emitConstructVarargs now passes thisRegister like
regular calls and emitCreateThis passes in this register to op_create_this as constructor.
The rest of the code change removes the code for special casing "this" register not being used
in call to construct.
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitCreateThis):
(JSC::BytecodeGenerator::emitConstructVarargs):
(JSC::BytecodeGenerator::emitConstruct):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::NewExprNode::emitBytecode):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
(JSC::DFG::ByteCodeParser::handleVarargsCall):
(JSC::DFG::ByteCodeParser::emitArgumentPhantoms):
(JSC::DFG::ByteCodeParser::attemptToInlineCall):
(JSC::DFG::ByteCodeParser::handleInlining):
(JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGJITCode.cpp:
(JSC::DFG::JITCode::reconstruct):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* ftl/FTLJSCallVarargs.cpp:
(JSC::FTL::JSCallVarargs::emit):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNativeCallOrConstruct):
(JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct):
(JSC::FTL::LowerDFGToLLVM::compileCallOrConstructVarargs):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::executeConstruct):
* jit/JITOperations.cpp:
2015-02-24 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Make Getter/Setter RemoteObject property and ObjectPreview handling consistent
https://bugs.webkit.org/show_bug.cgi?id=141587
Reviewed by Timothy Hatcher.
Convert getProperties(ownAndGetterProperties) to getDisplayableProperties().
Mark PropertyDescriptors that are presumed to be native getters / bindings
separately so that the frontend may display them differently.
* inspector/InjectedScript.cpp:
(Inspector::InjectedScript::getProperties):
(Inspector::InjectedScript::getDisplayableProperties):
* inspector/InjectedScript.h:
* inspector/InjectedScriptSource.js:
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::getProperties):
(Inspector::InspectorRuntimeAgent::getDisplayableProperties):
* inspector/agents/InspectorRuntimeAgent.h:
* inspector/protocol/Runtime.json:
2015-02-24 Mark Lam <mark.lam@apple.com>
Rolling out r179753. The fix was invalid.
<https://webkit.org/b/141990>
Not reviewed.
* API/tests/testapi.mm:
(threadMain):
(useVMFromOtherThread): Deleted.
(useVMFromOtherThreadAndOutliveVM): Deleted.
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::~Heap):
(JSC::Heap::gatherStackRoots):
* heap/Heap.h:
(JSC::Heap::machineThreads):
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::Thread::Thread):
(JSC::MachineThreads::MachineThreads):
(JSC::MachineThreads::~MachineThreads):
(JSC::MachineThreads::addCurrentThread):
(JSC::MachineThreads::removeThread):
(JSC::MachineThreads::removeCurrentThread):
* heap/MachineStackMarker.h:
2015-02-24 Yusuke Suzuki <utatane.tea@gmail.com>
Constructor returning null should construct an object instead of null
https://bugs.webkit.org/show_bug.cgi?id=141640
Reviewed by Filip Pizlo.
When constructor code doesn't return object, constructor should return `this` object instead.
Since we used `op_is_object` for this check and `op_is_object` is intended to be used for `typeof`,
it allows `null` as an object.
This patch fixes it by introducing an new bytecode `op_is_object_or_null` for `typeof` use cases.
Instead, constructor uses simplified `is_object`.
As a result, `op_is_object` becomes fairly simple. So we introduce optimization for `op_is_object`.
1. LLInt and baseline JIT support `op_is_object` as a fast path.
2. DFG abstract interpreter support `op_is_object`. And recognize its speculated type and read-write effects.
3. DFG introduces inlined asm for `op_is_object` rather than calling a C++ function.
4. FTL lowers DFG's IsObject into LLVM IR.
And at the same time, this patch fixes isString / isObject predicate used for `op_is_object` and others
in LLInt, JIT, DFG and FTL.
Before introducing ES6 Symbol, JSCell is only used for object and string in user observable area.
So in many places, when the cell is not object, we recognize it as a string, and vice versa.
However, now ES6 Symbol is implemented as a JSCell, this assumption is broken.
So this patch stop using !isString as isObject.
To check whether a cell is an object, instead of seeing that structure ID of a cell is not stringStructure,
we examine typeInfo in JSCell.
* JavaScriptCore.order:
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFor):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitEqualityOp):
(JSC::BytecodeGenerator::emitReturn):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
IsObject operation only touches JSCell typeInfoType.
And this value would be changed through structure transition.
As a result, IsObject can report that it doesn't read any information.
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
Just like IsString, IsObject is also fixed up.
* dfg/DFGHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGHeapLocation.h:
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
(JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
(JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
(JSC::DFG::SpeculativeJIT::compileToStringOnCell):
(JSC::DFG::SpeculativeJIT::speculateObject):
(JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
(JSC::DFG::SpeculativeJIT::speculateString):
(JSC::DFG::SpeculativeJIT::speculateNotStringVar):
(JSC::DFG::SpeculativeJIT::emitSwitchChar):
(JSC::DFG::SpeculativeJIT::emitSwitchString):
(JSC::DFG::SpeculativeJIT::branchIsObject):
(JSC::DFG::SpeculativeJIT::branchNotObject):
(JSC::DFG::SpeculativeJIT::branchIsString):
(JSC::DFG::SpeculativeJIT::branchNotString):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compileObjectEquality):
(JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
(JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
(JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
(JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compileObjectEquality):
(JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
(JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
(JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
(JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileToString):
(JSC::FTL::LowerDFGToLLVM::compileIsObject):
(JSC::FTL::LowerDFGToLLVM::compileIsObjectOrNull):
(JSC::FTL::LowerDFGToLLVM::speculateTruthyObject):
(JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
(JSC::FTL::LowerDFGToLLVM::isObject):
(JSC::FTL::LowerDFGToLLVM::isNotObject):
(JSC::FTL::LowerDFGToLLVM::isNotString):
(JSC::FTL::LowerDFGToLLVM::speculateNonNullObject):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::emitJumpIfCellObject):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_is_object):
(JSC::JIT::emit_op_to_primitive):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_is_object):
(JSC::JIT::emit_op_to_primitive):
(JSC::JIT::compileOpStrictEq):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* runtime/Operations.cpp:
(JSC::jsIsObjectTypeOrNull):
(JSC::jsIsObjectType): Deleted.
* runtime/Operations.h:
* tests/stress/constructor-with-return.js: Added.
(Test):
When constructor doesn't return an object, `this` should be returned instead.
In this test, we check all primitives. And test object, array and wrappers.
* tests/stress/dfg-to-primitive-pass-symbol.js: Added.
(toPrimitiveTarget):
(doToPrimitive):
op_to_primitive operation passes Symbol in fast path.
2015-02-24 Yusuke Suzuki <utatane.tea@gmail.com>
REGRESSION(r179429): Can't type comments in Facebook
https://bugs.webkit.org/show_bug.cgi?id=141859
Reviewed by Brent Fulgham.
When window.Symbol is exposed to user-space pages,
Facebook's JavaScript use it (maybe, for immutable-js and React.js's unique key).
However, to work with Symbols completely, it also requires
1) Object.getOwnPropertySymbols (for mixin including Symbols)
2) the latest ES6 Iterator interface that uses Iterator.next and it returns { done: boolean, value: value }.
Since they are not landed yet, comments in Facebook don't work.
This patch introduces RuntimeFlags for JavaScriptCore.
Specifying SymbolEnabled flag under test runner and inspector to continue to work with Symbol.
And drop JavaScriptExperimentsEnabled flag
because it is no longer used and use case of this is duplicated to runtime flags.
* JavaScriptCore.order:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* jsc.cpp:
(GlobalObject::javaScriptRuntimeFlags):
(GlobalObject::javaScriptExperimentsEnabled): Deleted.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::JSGlobalObject):
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::finishCreation):
(JSC::JSGlobalObject::javaScriptRuntimeFlags):
(JSC::JSGlobalObject::javaScriptExperimentsEnabled): Deleted.
* runtime/RuntimeFlags.h: Added.
(JSC::RuntimeFlags::RuntimeFlags):
(JSC::RuntimeFlags::createAllEnabled):
2015-02-23 Filip Pizlo <fpizlo@apple.com>
Our bizarre behavior on Arguments::defineOwnProperty should be deliberate rather than a spaghetti incident
https://bugs.webkit.org/show_bug.cgi?id=141951
Reviewed by Benjamin Poulain.
This patch has no behavioral change, but it simplifies a bunch of wrong code. The code is
still wrong in exactly the same way, but at least it's obvious what's going on. The wrongness
is covered by this bug: https://bugs.webkit.org/show_bug.cgi?id=141952.
* runtime/Arguments.cpp:
(JSC::Arguments::copyBackingStore): We should only see the arguments token; assert otherwise. This works because if the GC sees the butterfly token it calls the JSObject::copyBackingStore method directly.
(JSC::Arguments::defineOwnProperty): Make our bizarre behavior deliberate rather than an accident of a decade of patches.
* tests/stress/arguments-bizarre-behavior.js: Added.
(foo):
* tests/stress/arguments-bizarre-behaviour-disable-enumerability.js: Added. My choice of spellings of the word "behavio[u]r" is almost as consistent as our implementation of arguments.
(foo):
* tests/stress/arguments-custom-properties-gc.js: Added. I added this test because at first I was unsure if we GCd arguments correctly.
(makeBaseArguments):
(makeArray):
(cons):
2015-02-23 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r180547 and r180550.
https://bugs.webkit.org/show_bug.cgi?id=141957
Broke 10 Windows tests. (Requested by bfulgham_ on #webkit).
Reverted changesets:
"REGRESSION(r179429): Can't type comments in Facebook"
https://bugs.webkit.org/show_bug.cgi?id=141859
http://trac.webkit.org/changeset/180547
"Constructor returning null should construct an object instead
of null"
https://bugs.webkit.org/show_bug.cgi?id=141640
http://trac.webkit.org/changeset/180550
2015-02-23 Yusuke Suzuki <utatane.tea@gmail.com>
Constructor returning null should construct an object instead of null
https://bugs.webkit.org/show_bug.cgi?id=141640
Reviewed by Geoffrey Garen.
When constructor code doesn't return object, constructor should return `this` object instead.
Since we used `op_is_object` for this check and `op_is_object` is intended to be used for `typeof`,
it allows `null` as an object.
This patch fixes it by introducing an new bytecode `op_is_object_or_null` for `typeof` use cases.
Instead, constructor uses simplified `is_object`.
As a result, `op_is_object` becomes fairly simple. So we introduce optimization for `op_is_object`.
1. LLInt and baseline JIT support `op_is_object` as a fast path.
2. DFG abstract interpreter support `op_is_object`. And recognize its speculated type and read-write effects.
3. DFG introduces inlined asm for `op_is_object` rather than calling a C++ function.
4. FTL lowers DFG's IsObject into LLVM IR.
And at the same time, this patch fixes isString / isObject predicate used for `op_is_object` and others
in LLInt, JIT, DFG and FTL.
Before introducing ES6 Symbol, JSCell is only used for object and string in user observable area.
So in many places, when the cell is not object, we recognize it as a string, and vice versa.
However, now ES6 Symbol is implemented as a JSCell, this assumption is broken.
So this patch stop using !isString as isObject.
To check whether a cell is an object, instead of seeing that structure ID of a cell is not stringStructure,
we examine typeInfo in JSCell.
* JavaScriptCore.order:
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFor):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitEqualityOp):
(JSC::BytecodeGenerator::emitReturn):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
IsObject operation only touches JSCell typeInfoType.
And this value would not be changed through structure transition.
As a result, IsObject can report that it doesn't read any information.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
Just like IsString, IsObject is also fixed up.
* dfg/DFGHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGHeapLocation.h:
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
(JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
(JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
(JSC::DFG::SpeculativeJIT::compileToStringOnCell):
(JSC::DFG::SpeculativeJIT::speculateObject):
(JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
(JSC::DFG::SpeculativeJIT::speculateString):
(JSC::DFG::SpeculativeJIT::speculateNotStringVar):
(JSC::DFG::SpeculativeJIT::emitSwitchChar):
(JSC::DFG::SpeculativeJIT::emitSwitchString):
(JSC::DFG::SpeculativeJIT::branchIsObject):
(JSC::DFG::SpeculativeJIT::branchNotObject):
(JSC::DFG::SpeculativeJIT::branchIsString):
(JSC::DFG::SpeculativeJIT::branchNotString):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compileObjectEquality):
(JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
(JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
(JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
(JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compileObjectEquality):
(JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
(JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
(JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
(JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileToString):
(JSC::FTL::LowerDFGToLLVM::compileIsObject):
(JSC::FTL::LowerDFGToLLVM::compileIsObjectOrNull):
(JSC::FTL::LowerDFGToLLVM::speculateTruthyObject):
(JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
(JSC::FTL::LowerDFGToLLVM::isObject):
(JSC::FTL::LowerDFGToLLVM::isNotObject):
(JSC::FTL::LowerDFGToLLVM::isNotString):
(JSC::FTL::LowerDFGToLLVM::speculateNonNullObject):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::emitJumpIfCellObject):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_is_object):
(JSC::JIT::emit_op_to_primitive):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_is_object):
(JSC::JIT::emit_op_to_primitive):
(JSC::JIT::compileOpStrictEq):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* runtime/Operations.cpp:
(JSC::jsIsObjectTypeOrNull):
(JSC::jsIsObjectType): Deleted.
* runtime/Operations.h:
2015-02-23 Ryosuke Niwa <rniwa@webkit.org>
Disable font loading events until our implementation gets updated to match the latest spec
https://bugs.webkit.org/show_bug.cgi?id=141938
Reviewed by Andreas Kling.
* Configurations/FeatureDefines.xcconfig:
2015-02-23 Yusuke Suzuki <utatane.tea@gmail.com>
REGRESSION(r179429): Can't type comments in Facebook
https://bugs.webkit.org/show_bug.cgi?id=141859
Reviewed by Geoffrey Garen.
When window.Symbol is exposed to user-space pages,
Facebook's JavaScript use it (maybe, for immutable-js and React.js's unique key).
However, to work with Symbols completely, it also requires
1) Object.getOwnPropertySymbols (for mixin including Symbols)
2) the latest ES6 Iterator interface that uses Iterator.next and it returns { done: boolean, value: value }.
Since they are not landed yet, comments in Facebook don't work.
This patch introduces RuntimeFlags for JavaScriptCore.
Specifying SymbolEnabled flag under test runner and inspector to continue to work with Symbol.
And drop JavaScriptExperimentsEnabled flag
because it is no longer used and use case of this is duplicated to runtime flags.
* JavaScriptCore.order:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* jsc.cpp:
(GlobalObject::javaScriptRuntimeFlags):
(GlobalObject::javaScriptExperimentsEnabled): Deleted.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::JSGlobalObject):
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::finishCreation):
(JSC::JSGlobalObject::javaScriptRuntimeFlags):
(JSC::JSGlobalObject::javaScriptExperimentsEnabled): Deleted.
* runtime/RuntimeFlags.h: Added.
(JSC::RuntimeFlags::RuntimeFlags):
(JSC::RuntimeFlags::createAllEnabled):
2015-02-23 Benjamin Poulain <bpoulain@apple.com>
Set the semantic origin of delayed SetLocal to the Bytecode that originated it
https://bugs.webkit.org/show_bug.cgi?id=141727
Reviewed by Filip Pizlo.
Previously, delayed SetLocals would have the NodeOrigin of the next
bytecode. This was because delayed SetLocal are...delayed... and
currentCodeOrigin() is the one where the node is emitted.
This made debugging a little awkward since the OSR exits on SetLocal
were reported for the next bytecode. This patch changes the semantic
origin to keep the original bytecode.
From benchmarks, this looks like it could be a tiny bit faster
but it likely just noise.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::setDirect):
(JSC::DFG::ByteCodeParser::setLocal):
(JSC::DFG::ByteCodeParser::setArgument):
(JSC::DFG::ByteCodeParser::currentNodeOrigin):
(JSC::DFG::ByteCodeParser::addToGraph):
(JSC::DFG::ByteCodeParser::DelayedSetLocal::DelayedSetLocal):
(JSC::DFG::ByteCodeParser::DelayedSetLocal::execute):
2015-02-23 Benjamin Poulain <bpoulain@apple.com>
Remove DFGNode::predictHeap()
https://bugs.webkit.org/show_bug.cgi?id=141864
Reviewed by Geoffrey Garen.
* dfg/DFGNode.h:
(JSC::DFG::Node::predictHeap): Deleted.
Unused code.
2015-02-23 Filip Pizlo <fpizlo@apple.com>
Get rid of JSLexicalEnvironment::argumentsGetter
https://bugs.webkit.org/show_bug.cgi?id=141930
Reviewed by Mark Lam.
This function is unused, and the way it's written is bizarre - it's a return statement that
dominates a bunch of dead code.
* runtime/JSLexicalEnvironment.cpp:
(JSC::JSLexicalEnvironment::argumentsGetter): Deleted.
* runtime/JSLexicalEnvironment.h:
2015-02-23 Filip Pizlo <fpizlo@apple.com>
Remove unused activationCount and allTheThingsCount variable declarations.
Rubber stamped by Mark Lam and Michael Saboff.
* runtime/JSLexicalEnvironment.h:
2015-02-23 Saam Barati <saambarati1@gmail.com>
Adjust the ranges of basic block statements in JSC's control flow profiler to be mutually exclusive
https://bugs.webkit.org/show_bug.cgi?id=141095
Reviewed by Mark Lam.
Suppose the control flow of a program forms basic block A with successor block
B. A's end offset will be the *same* as B's start offset in the current architecture
of the control flow profiler. This makes reasoning about the text offsets of
the control flow profiler unsound. To make reasoning about offsets sound, all
basic block ranges should be mutually exclusive. All calls to emitProfileControlFlow
now pass in the *start* of a basic block as the text offset argument. This simplifies
all calls to emitProfileControlFlow because the previous implementation had a
lot of edge cases for getting the desired basic block text boundaries.
This patch also ensures that the basic block boundary of a block statement
is the exactly the block's open and close brace offsets (inclusive). For example,
in if/for/while statements. This also has the consequence that for statements
like "if (cond) foo();", the whitespace preceding "foo()" is not part of
the "foo()" basic block, but instead is part of the "if (cond) " basic block.
This is okay because these text offsets aren't meant to be human readable.
Instead, they reflect the text offsets of JSC's AST nodes. The Web Inspector
is the only client of this API and user of these text offsets and it is
not negatively effected by this new behavior.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
When computing basic block boundaries in CodeBlock, we ensure that every
block's end offset is one less than its successor's start offset to
maintain that boundaries' ranges should be mutually exclusive.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
Because the control flow profiler needs to know which functions
have executed, we can't lazily create functions. This was a bug
from before that was hidden because the Type Profiler was always
enabled when the control flow profiler was enabled when profiling
was turned on from the Web Inspector. But, JSC allows for Control
Flow profiling to be turned on without Type Profiling, so we need
to ensure the Control Flow profiler has all the data it needs.
* bytecompiler/NodesCodegen.cpp:
(JSC::ConditionalNode::emitBytecode):
(JSC::IfElseNode::emitBytecode):
(JSC::WhileNode::emitBytecode):
(JSC::ForNode::emitBytecode):
(JSC::ForInNode::emitMultiLoopBytecode):
(JSC::ForOfNode::emitBytecode):
(JSC::TryNode::emitBytecode):
* jsc.cpp:
(functionHasBasicBlockExecuted):
We now assert that the substring argument is indeed a substring
of the function argument's text because subtle bugs could be
introduced otherwise.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::setStartOffset):
* parser/Nodes.h:
(JSC::Node::setStartOffset):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseBlockStatement):
(JSC::Parser<LexerType>::parseStatement):
(JSC::Parser<LexerType>::parseMemberExpression):
For the various function call AST nodes, their m_position member
variable is now the start of the entire function call expression
and not at the start of the open paren of the arguments list.
* runtime/BasicBlockLocation.cpp:
(JSC::BasicBlockLocation::getExecutedRanges):
* runtime/ControlFlowProfiler.cpp:
(JSC::ControlFlowProfiler::getBasicBlocksForSourceID):
Function ranges inserted as gaps should follow the same criteria
that the bytecode generator uses to ensure that basic blocks
start and end offsets are mutually exclusive.
* tests/controlFlowProfiler/brace-location.js: Added.
(foo):
(bar):
(baz):
(testIf):
(testForRegular):
(testForIn):
(testForOf):
(testWhile):
(testIfNoBraces):
(testForRegularNoBraces):
(testForInNoBraces):
(testForOfNoBraces):
(testWhileNoBraces):
* tests/controlFlowProfiler/conditional-expression.js: Added.
(foo):
(bar):
(baz):
(testConditionalBasic):
(testConditionalFunctionCall):
* tests/controlFlowProfiler/driver/driver.js:
(checkBasicBlock):
2015-02-23 Matthew Mirman <mmirman@apple.com>
r9 is volatile on ARMv7 for iOS 3 and up.
https://bugs.webkit.org/show_bug.cgi?id=141489
rdar://problem/19432916
Reviewed by Michael Saboff.
* jit/RegisterSet.cpp:
(JSC::RegisterSet::calleeSaveRegisters): removed r9 from the list of ARMv7 callee save registers.
* tests/stress/regress-141489.js: Added.
(foo):
2015-02-23 Csaba Osztrogonác <ossy@webkit.org>
[ARM] Add the necessary setupArgumentsWithExecState after bug141915
https://bugs.webkit.org/show_bug.cgi?id=141921
Reviewed by Michael Saboff.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState):
2015-02-23 Filip Pizlo <fpizlo@apple.com>
Scopes should always be created with a previously-created symbol table rather than creating one on the fly
https://bugs.webkit.org/show_bug.cgi?id=141915
Reviewed by Mark Lam.
The main effect of this change is that pushing name scopes no longer requires creating symbol
tables on the fly.
This also makes it so that JSEnvironmentRecords must always have an a priori symbol table.
JSSegmentedVariableObject still does a hack where it creates a blank symbol table on-demand.
This is needed because that's what JSGlobalObject and all of its many subclasses want. That's
harmless; I mainly needed a prior symbol tables for JSEnvironmentRecords anyway.
* bytecode/BytecodeList.json:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitPushFunctionNameScope):
(JSC::BytecodeGenerator::emitPushCatchScope):
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_push_name_scope):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_push_name_scope):
* jit/JITOperations.cpp:
(JSC::pushNameScope):
* jit/JITOperations.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter.asm:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
* runtime/JSCatchScope.h:
(JSC::JSCatchScope::JSCatchScope):
(JSC::JSCatchScope::create):
* runtime/JSEnvironmentRecord.h:
(JSC::JSEnvironmentRecord::JSEnvironmentRecord):
* runtime/JSFunctionNameScope.h:
(JSC::JSFunctionNameScope::JSFunctionNameScope):
(JSC::JSFunctionNameScope::create):
* runtime/JSNameScope.cpp:
(JSC::JSNameScope::create):
* runtime/JSNameScope.h:
(JSC::JSNameScope::create):
(JSC::JSNameScope::finishCreation):
(JSC::JSNameScope::JSNameScope):
* runtime/JSSegmentedVariableObject.h:
(JSC::JSSegmentedVariableObject::finishCreation):
* runtime/JSSymbolTableObject.h:
(JSC::JSSymbolTableObject::JSSymbolTableObject):
(JSC::JSSymbolTableObject::finishCreation): Deleted.
* runtime/SymbolTable.h:
(JSC::SymbolTable::createNameScopeTable):
2015-02-23 Filip Pizlo <fpizlo@apple.com>
Add a comment to clarify that the test was taken from the bug report, in response to
feedback from Michael Saboff and Benjamin Poulain.
* tests/stress/regress-141883.js:
2015-02-22 Filip Pizlo <fpizlo@apple.com>
Function name scope is only created on the function instance that triggered parsing rather than on every function instance that needs it
https://bugs.webkit.org/show_bug.cgi?id=141881
Reviewed by Michael Saboff.
Previously we only created the function name scope in a way that made it visible to the
function that triggered parsing/linking of the executable/codeBlock, and to the linker for
that code block. This was sort of the bare minimum for the feature to appear to work right to
synthetic tests.
There are two valid "times" to create the function name scope. Either it's created for each
JSFunction instance that needs a name scope, or it's created for each execution of such a
JSFunction. This change chooses the latter, because it happens to be the easiest to implement
with what we have right now. I opened a bug for optimizing this if we ever need to:
https://bugs.webkit.org/show_bug.cgi?id=141887.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
(JSC::Interpreter::prepareForRepeatCall):
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setUpCall):
* runtime/ArrayPrototype.cpp:
(JSC::isNumericCompareFunction):
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::ScriptExecutable::prepareForExecutionImpl):
(JSC::FunctionExecutable::FunctionExecutable):
* runtime/Executable.h:
(JSC::ScriptExecutable::prepareForExecution):
* runtime/JSFunction.cpp:
(JSC::JSFunction::addNameScopeIfNeeded): Deleted.
* runtime/JSFunction.h:
* tests/stress/function-name-scope.js: Added.
(check.verify):
(check):
2015-02-22 Filip Pizlo <fpizlo@apple.com>
Crash in DFGFrozenValue
https://bugs.webkit.org/show_bug.cgi?id=141883
Reviewed by Benjamin Poulain.
If a value might be a cell, then we have to have Graph freeze it rather than trying to
create the FrozenValue directly. Creating it directly is just an optimization for when you
know for sure that it cannot be a cell.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* tests/stress/regress-141883.js: Added. Hacked the original test to be faster while still crashing before this fix.
2015-02-21 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Generate Previews more often for RemoteObject interaction
https://bugs.webkit.org/show_bug.cgi?id=141875
Reviewed by Timothy Hatcher.
* inspector/protocol/Runtime.json:
Add generatePreview to getProperties.
* inspector/InjectedScript.cpp:
(Inspector::InjectedScript::getProperties):
(Inspector::InjectedScript::getInternalProperties):
* inspector/InjectedScript.h:
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::getProperties):
* inspector/agents/InspectorRuntimeAgent.h:
Plumb the generatePreview boolean through to the injected script.
* inspector/InjectedScriptSource.js:
Add generatePreview for getProperties.
Fix callFunctionOn to generatePreviews if asked.
2015-02-20 Mark Lam <mark.lam@apple.com>
Refactor JSWrapperMap.mm to defer creation of the ObjC JSValue until the latest possible moment.
<https://webkit.org/b/141856>
Reviewed by Geoffrey Garen.
1. Make JSObjCClassInfo's -constructor and -wrapperForObject return a
JSC::JSObject* just like -prototype.
2. Defer the creation of the ObjC JSValue from JSC::JSObject* until
the latest moment when it is needed. This allows us to not have to
keep converting back to a JSC::JSObject* in intermediate code.
* API/JSWrapperMap.mm:
(makeWrapper):
(objectWithCustomBrand):
(constructorWithCustomBrand):
(allocateConstructorForCustomClass):
(-[JSObjCClassInfo allocateConstructorAndPrototype]):
(-[JSObjCClassInfo wrapperForObject:]):
(-[JSObjCClassInfo constructor]):
(-[JSWrapperMap jsWrapperForObject:]):
2015-02-20 Filip Pizlo <fpizlo@apple.com>
Build fix for gcc.
* runtime/JSNameScope.cpp:
(JSC::JSNameScope::create):
2015-02-20 Filip Pizlo <fpizlo@apple.com>
Get rid of JSNameScope::m_type
https://bugs.webkit.org/show_bug.cgi?id=141851
Reviewed by Geoffrey Garen.
This is a big step towards getting rid of JSEnvironmentRecord::m_registers. To do it we need
to ensure that subclasses of JSEnvironmentRecord never have additional C++ fields, so that
JSEnvironmentRecord can always place "registers" right after the end of itself.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* debugger/DebuggerScope.cpp:
(JSC::DebuggerScope::isCatchScope):
(JSC::DebuggerScope::isFunctionNameScope):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/JSCatchScope.cpp: Added.
* runtime/JSCatchScope.h: Added.
(JSC::JSCatchScope::JSCatchScope):
(JSC::JSCatchScope::create):
(JSC::JSCatchScope::createStructure):
* runtime/JSFunction.cpp:
(JSC::JSFunction::addNameScopeIfNeeded):
* runtime/JSFunctionNameScope.cpp: Added.
* runtime/JSFunctionNameScope.h: Added.
(JSC::JSFunctionNameScope::JSFunctionNameScope):
(JSC::JSFunctionNameScope::create):
(JSC::JSFunctionNameScope::createStructure):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::catchScopeStructure):
(JSC::JSGlobalObject::functionNameScopeStructure):
(JSC::JSGlobalObject::nameScopeStructure): Deleted.
* runtime/JSNameScope.cpp:
(JSC::JSNameScope::create):
* runtime/JSNameScope.h:
(JSC::JSNameScope::create):
(JSC::JSNameScope::JSNameScope):
(JSC::JSNameScope::createStructure): Deleted.
(JSC::JSNameScope::isFunctionNameScope): Deleted.
(JSC::JSNameScope::isCatchScope): Deleted.
* runtime/JSObject.cpp:
(JSC::JSObject::isCatchScopeObject):
(JSC::JSObject::isFunctionNameScopeObject):
* runtime/JSObject.h:
2015-02-20 Mark Lam <mark.lam@apple.com>
[JSObjCClassInfo reallocateConstructorAndOrPrototype] should also reallocate super class prototype chain.
<https://webkit.org/b/141809>
Reviewed by Geoffrey Garen.
A ObjC class that implement the JSExport protocol will have a JS prototype
chain and constructor automatically synthesized for its JS wrapper object.
However, if there are no more instances of that ObjC class reachable by a
JS GC root scan, then its synthesized prototype chain and constructors may
be released by the GC. If a new instance of that ObjC class is subsequently
instantiated, then [JSObjCClassInfo reallocateConstructorAndOrPrototype]
should re-construct the prototype chain and constructor (if they were
previously released). However, the current implementation only
re-constructs the immediate prototype, but not every other prototype
object upstream in the prototype chain.
To fix this, we do the following:
1. We no longer allocate the JSObjCClassInfo's prototype and constructor
eagerly. Hence, -initWithContext:forClass: will no longer call
-allocateConstructorAndPrototypeWithSuperClassInfo:.
2. Instead, we'll always access the prototype and constructor thru
accessor methods. The accessor methods will call
-allocateConstructorAndPrototype: if needed.
3. -allocateConstructorAndPrototype: will fetch the needed superClassInfo
from the JSWrapperMap itself. This makes it so that we no longer
need to pass the superClassInfo all over.
4. -allocateConstructorAndPrototype: will get the super class prototype
by invoking -prototype: on the superClassInfo, thereby allowing the
super class to allocate its prototype and constructor if needed and
fixing the issue in this bug.
5. Also removed the GC warning comments, and ensured that needed JS
objects are kept alive by having a local var pointing to it from the
stack (which makes a GC root).
* API/JSWrapperMap.mm:
(-[JSObjCClassInfo initWithContext:forClass:]):
(-[JSObjCClassInfo allocateConstructorAndPrototype]):
(-[JSObjCClassInfo wrapperForObject:]):
(-[JSObjCClassInfo constructor]):
(-[JSObjCClassInfo prototype]):
(-[JSWrapperMap classInfoForClass:]):
(-[JSObjCClassInfo initWithContext:forClass:superClassInfo:]): Deleted.
(-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]): Deleted.
(-[JSObjCClassInfo reallocateConstructorAndOrPrototype]): Deleted.
* API/tests/Regress141809.h: Added.
* API/tests/Regress141809.mm: Added.
(-[TestClassB name]):
(-[TestClassC name]):
(runRegress141809):
* API/tests/testapi.mm:
* JavaScriptCore.xcodeproj/project.pbxproj:
2015-02-20 Alexey Proskuryakov <ap@apple.com>
Remove svn:keywords property.
As far as I can tell, the property had no effect on any of these files, but also,
when it has effect it's likely harmful.
* builtins/ArrayConstructor.js: Removed property svn:keywords.
2015-02-20 Michael Saboff <msaboff@apple.com>
DFG JIT needs to check for stack overflow at the start of Program and Eval execution
https://bugs.webkit.org/show_bug.cgi?id=141676
Reviewed by Filip Pizlo.
Added stack check to the beginning of the code the DFG copmiler emits for Program and Eval nodes.
To aid in testing the code, I replaced the EvalCodeCache::maxCacheableSourceLength const
a options in runtime/Options.h. The test script, run-jsc-stress-tests, sets that option
to a huge value when running with the "Eager" options. This allows the updated test to
reliably exercise the code in questions.
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compile):
Added stack check.
* bytecode/EvalCodeCache.h:
(JSC::EvalCodeCache::tryGet):
(JSC::EvalCodeCache::getSlow):
* runtime/Options.h:
Replaced EvalCodeCache::imaxCacheableSourceLength with Options::maximumEvalCacheableSourceLength
so that it can be configured when running the related test.
2015-02-20 Eric Carlson <eric.carlson@apple.com>
[iOS] cleanup AirPlay code
https://bugs.webkit.org/show_bug.cgi?id=141811
Reviewed by Jer Noble.
* Configurations/FeatureDefines.xcconfig: IOS_AIRPLAY -> WIRELESS_PLAYBACK_TARGET.
2015-02-19 Dean Jackson <dino@apple.com>
ES6: Implement Array.from()
https://bugs.webkit.org/show_bug.cgi?id=141054
<rdar://problem/19654521>
Reviewed by Filip Pizlo.
Implement the Array.from() ES6 method
as defined in Section 22.1.2.1 of the specification.
Given that we can't rely on the built-in
global functions or objects to be untainted,
I had to expose a few of them directly to
the function via private names. In particular:
- Math.floor -> @floor
- Math.abs -> @abs
- Number -> @Number
- Array -> @Array
- isFinite -> @isFinite
* builtins/ArrayConstructor.js: Added.
(from): Implementation of Array.from in JavaScript.
* runtime/ArrayConstructor.cpp: Add "from" to the lookup
table for the constructor object.
* runtime/CommonIdentifiers.h: Add the private versions
of the identifiers listed above.
* runtime/JSGlobalObject.cpp: Add the implementations of
those identifiers to the global object (using their
private names).
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalPrivateFuncAbs): Implementation of the abs function.
(JSC::globalPrivateFuncFloor): Implementation of the floor function.
* runtime/JSGlobalObjectFunctions.h:
2015-02-19 Benjamin Poulain <bpoulain@apple.com>
Refine the FTL part of ArithPow
https://bugs.webkit.org/show_bug.cgi?id=141792
Reviewed by Filip Pizlo.
This patch refines the FTL lowering of ArithPow. This was left out
of the original patch to keep it simpler.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileArithPow):
Two improvements here:
1) Do not generate the NaN check unless we know the exponent might be a NaN.
2) Use one BasicBlock per check with the appropriate weight. Now that we have
one branch per test, move the Infinity check before the check for 1 since
it is the less common case.
* tests/stress/math-pow-becomes-custom-function.js: Added.
Test for changing the Math.pow() function after it has been optimized.
* tests/stress/math-pow-nan-behaviors.js:
The previous tests were only going as far as the DFGAbstractInterpreter
were the operations were replaced by the equivalent constant.
I duplicated the test functions to also test the dynamic behavior of DFG
and FTL.
* tests/stress/math-pow-with-constants.js:
Add cases covering exponent constants. LLVM removes many value
checks for those.
* tests/stress/math-pow-with-never-NaN-exponent.js: Added.
Test for the new optimization removing the NaN check.
2015-02-19 Csaba Osztrogonác <ossy@webkit.org>
REGRESSION(r180279): It broke 20 tests on ARM Linux
https://bugs.webkit.org/show_bug.cgi?id=141771
Reviewed by Filip Pizlo.
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation): Align 64-bit values to respect ARM EABI.
2015-02-18 Benjamin Poulain <bpoulain@apple.com>
Remove BytecodeGenerator's numberMap, it is dead code
https://bugs.webkit.org/show_bug.cgi?id=141779
Reviewed by Filip Pizlo.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitLoad): Deleted.
* bytecompiler/BytecodeGenerator.h:
The JSValueMap seems better in every way.
The emitLoad() taking a double was the only way to use numberMap
and that code has no caller.
2015-02-18 Michael Saboff <msaboff@apple.com>
Rollout r180247 & r180249 from trunk
https://bugs.webkit.org/show_bug.cgi?id=141773
Reviewed by Filip Pizlo.
Theses changes makes sense to fix the crash reported in https://bugs.webkit.org/show_bug.cgi?id=141730
only for branches. The change to fail the FTL compile but continue running is not comprehensive
enough for general use on trunk.
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::lower):
(JSC::FTL::LowerDFGToLLVM::createPhiVariables):
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileUpsilon):
(JSC::FTL::LowerDFGToLLVM::compilePhi):
(JSC::FTL::LowerDFGToLLVM::compileDoubleRep):
(JSC::FTL::LowerDFGToLLVM::compileValueRep):
(JSC::FTL::LowerDFGToLLVM::compileValueToInt32):
(JSC::FTL::LowerDFGToLLVM::compilePutLocal):
(JSC::FTL::LowerDFGToLLVM::compileArithAddOrSub):
(JSC::FTL::LowerDFGToLLVM::compileArithMul):
(JSC::FTL::LowerDFGToLLVM::compileArithDiv):
(JSC::FTL::LowerDFGToLLVM::compileArithMod):
(JSC::FTL::LowerDFGToLLVM::compileArithMinOrMax):
(JSC::FTL::LowerDFGToLLVM::compileArithAbs):
(JSC::FTL::LowerDFGToLLVM::compileArithNegate):
(JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):
(JSC::FTL::LowerDFGToLLVM::compileGetById):
(JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentByVal):
(JSC::FTL::LowerDFGToLLVM::compileGetArrayLength):
(JSC::FTL::LowerDFGToLLVM::compileGetByVal):
(JSC::FTL::LowerDFGToLLVM::compilePutByVal):
(JSC::FTL::LowerDFGToLLVM::compileArrayPush):
(JSC::FTL::LowerDFGToLLVM::compileArrayPop):
(JSC::FTL::LowerDFGToLLVM::compileNewArray):
(JSC::FTL::LowerDFGToLLVM::compileToString):
(JSC::FTL::LowerDFGToLLVM::compileMakeRope):
(JSC::FTL::LowerDFGToLLVM::compileCompareEq):
(JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
(JSC::FTL::LowerDFGToLLVM::compileSwitch):
(JSC::FTL::LowerDFGToLLVM::compare):
(JSC::FTL::LowerDFGToLLVM::boolify):
(JSC::FTL::LowerDFGToLLVM::opposite):
(JSC::FTL::LowerDFGToLLVM::lowJSValue):
(JSC::FTL::LowerDFGToLLVM::speculate):
(JSC::FTL::LowerDFGToLLVM::isArrayType):
(JSC::FTL::LowerDFGToLLVM::exitValueForAvailability):
(JSC::FTL::LowerDFGToLLVM::exitValueForNode):
(JSC::FTL::LowerDFGToLLVM::setInt52):
(JSC::FTL::lowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::loweringFailed): Deleted.
* ftl/FTLLowerDFGToLLVM.h:
2015-02-18 Filip Pizlo <fpizlo@apple.com>
DFG should really support varargs
https://bugs.webkit.org/show_bug.cgi?id=141332
Reviewed by Oliver Hunt.
This adds comprehensive vararg call support to the DFG and FTL compilers. Previously, if a
function had a varargs call, then it could only be compiled if that varargs call was just
forwarding arguments and we were inlining the function rather than compiling it directly. Also,
only varargs calls were dealt with; varargs constructs were not.
This lifts all of those restrictions. Every varargs call or construct can now be compiled by both
the DFG and the FTL. Those calls can also be inlined, too - provided that profiling gives us a
sensible bound on arguments list length. When we inline a varargs call, the act of loading the
varargs is now made explicit in IR. I believe that we have enough IR machinery in place that we
would be able to do the arguments forwarding optimization as an IR transformation. This patch
doesn't implement that yet, and keeps the old bytecode-based varargs argument forwarding
optimization for now.
There are three major IR features introduced in this patch:
CallVarargs/ConstructVarargs: these are like Call/Construct except that they take an arguments
array rather than a list of arguments. Currently, they splat this arguments array onto the stack
using the same basic technique as the baseline JIT has always done. Except, these nodes indicate
that we are not interested in doing the non-escaping "arguments" optimization.
CallForwardVarargs: this is a form of CallVarargs that just does the non-escaping "arguments"
optimization, aka forwarding arguments. It's somewhat lazy that this doesn't include
ConstructForwardVarargs, but the reason is that once we eliminate the lazy tear-off for
arguments, this whole thing will have to be tweaked - and for now forwarding on construct is just
not important in benchmarks. ConstructVarargs will still do forwarding, just not inlined.
LoadVarargs: loads all elements out of an array onto the stack in a manner suitable for a varargs
call. This is used only when a varargs call (or construct) was inlined. The bytecode parser will
make room on the stack for the arguments, and will use LoadVarars to put those arguments into
place.
In the future, we can consider adding strength reductions like:
- If CallVarargs/ConstructVarargs see an array of known size with known elements, turn them into
Call/Construct.
- If CallVarargs/ConstructVarargs are passed an unmodified, unescaped Arguments object, then
turn them into CallForwardVarargs/ConstructForwardVarargs.
- If LoadVarargs sees an array of known size, then turn it into a sequence of GetByVals and
PutLocals.
- If LoadVarargs sees an unmodified, unescaped Arguments object, then turn it into something like
LoadForwardVarargs.
- If CallVarargs/ConstructVarargs/LoadVarargs see the result of a splice (or other Array
prototype function), then do the splice and varargs loading in one go (maybe via a new node
type).
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::rshiftPtr):
(JSC::MacroAssembler::urshiftPtr):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::urshift64):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::urshift64):
* assembler/X86Assembler.h:
(JSC::X86Assembler::shrq_i8r):
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::CallLinkInfo):
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFor):
(JSC::CallLinkStatus::setProvenConstantCallee):
(JSC::CallLinkStatus::dump):
* bytecode/CallLinkStatus.h:
(JSC::CallLinkStatus::maxNumArguments):
(JSC::CallLinkStatus::setIsProved): Deleted.
* bytecode/CodeOrigin.cpp:
(WTF::printInternal):
* bytecode/CodeOrigin.h:
(JSC::InlineCallFrame::varargsKindFor):
(JSC::InlineCallFrame::specializationKindFor):
(JSC::InlineCallFrame::isVarargs):
(JSC::InlineCallFrame::isNormalCall): Deleted.
* bytecode/ExitKind.cpp:
(JSC::exitKindToString):
* bytecode/ExitKind.h:
* bytecode/ValueRecovery.cpp:
(JSC::ValueRecovery::dumpInContext):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGArgumentsSimplificationPhase.cpp:
(JSC::DFG::ArgumentsSimplificationPhase::run):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::flush):
(JSC::DFG::ByteCodeParser::addCall):
(JSC::DFG::ByteCodeParser::handleCall):
(JSC::DFG::ByteCodeParser::handleVarargsCall):
(JSC::DFG::ByteCodeParser::emitFunctionChecks):
(JSC::DFG::ByteCodeParser::inliningCost):
(JSC::DFG::ByteCodeParser::inlineCall):
(JSC::DFG::ByteCodeParser::attemptToInlineCall):
(JSC::DFG::ByteCodeParser::handleInlining):
(JSC::DFG::ByteCodeParser::handleMinMax):
(JSC::DFG::ByteCodeParser::handleIntrinsic):
(JSC::DFG::ByteCodeParser::handleTypedArrayConstructor):
(JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::removeLastNodeFromGraph): Deleted.
(JSC::DFG::ByteCodeParser::undoFunctionChecks): Deleted.
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGCapabilities.h:
(JSC::DFG::functionCapabilityLevel):
(JSC::DFG::mightCompileFunctionFor):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGCommon.cpp:
(WTF::printInternal):
* dfg/DFGCommon.h:
(JSC::DFG::canInline):
(JSC::DFG::leastUpperBound):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
(JSC::DFG::Graph::dumpBlockHeader):
(JSC::DFG::Graph::isLiveInBytecode):
(JSC::DFG::Graph::valueProfileFor):
(JSC::DFG::Graph::methodOfGettingAValueProfileFor):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::valueProfileFor): Deleted.
(JSC::DFG::Graph::methodOfGettingAValueProfileFor): Deleted.
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compileExceptionHandlers):
(JSC::DFG::JITCompiler::link):
* dfg/DFGMayExit.cpp:
(JSC::DFG::mayExit):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasCallVarargsData):
(JSC::DFG::Node::callVarargsData):
(JSC::DFG::Node::hasLoadVarargsData):
(JSC::DFG::Node::loadVarargsData):
(JSC::DFG::Node::hasHeapPrediction):
* dfg/DFGNodeType.h:
* dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
(JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::dumpAndVerifyGraph):
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGPreciseLocalClobberize.h:
(JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
(JSC::DFG::PreciseLocalClobberizeAdaptor::writeTop):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSSAConversionPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::isFlushed):
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStackLayoutPhase.cpp:
(JSC::DFG::StackLayoutPhase::run):
(JSC::DFG::StackLayoutPhase::assign):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::run):
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::validateCPS):
* ftl/FTLAbbreviations.h:
(JSC::FTL::functionType):
(JSC::FTL::buildCall):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLInlineCacheSize.cpp:
(JSC::FTL::sizeOfCall):
(JSC::FTL::sizeOfCallVarargs):
(JSC::FTL::sizeOfCallForwardVarargs):
(JSC::FTL::sizeOfConstructVarargs):
(JSC::FTL::sizeOfIn):
(JSC::FTL::sizeOfICFor):
(JSC::FTL::sizeOfCheckIn): Deleted.
* ftl/FTLInlineCacheSize.h:
* ftl/FTLIntrinsicRepository.h:
* ftl/FTLJSCall.cpp:
(JSC::FTL::JSCall::JSCall):
* ftl/FTLJSCallBase.cpp:
* ftl/FTLJSCallBase.h:
* ftl/FTLJSCallVarargs.cpp: Added.
(JSC::FTL::JSCallVarargs::JSCallVarargs):
(JSC::FTL::JSCallVarargs::numSpillSlotsNeeded):
(JSC::FTL::JSCallVarargs::emit):
(JSC::FTL::JSCallVarargs::link):
* ftl/FTLJSCallVarargs.h: Added.
(JSC::FTL::JSCallVarargs::node):
(JSC::FTL::JSCallVarargs::stackmapID):
(JSC::FTL::JSCallVarargs::operator<):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::lower):
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentsLength):
(JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentByVal):
(JSC::FTL::LowerDFGToLLVM::compileCallOrConstructVarargs):
(JSC::FTL::LowerDFGToLLVM::compileLoadVarargs):
(JSC::FTL::LowerDFGToLLVM::compileIn):
(JSC::FTL::LowerDFGToLLVM::emitStoreBarrier):
(JSC::FTL::LowerDFGToLLVM::vmCall):
(JSC::FTL::LowerDFGToLLVM::vmCallNoExceptions):
(JSC::FTL::LowerDFGToLLVM::callCheck):
* ftl/FTLOutput.h:
(JSC::FTL::Output::call):
* ftl/FTLState.cpp:
(JSC::FTL::State::State):
* ftl/FTLState.h:
* interpreter/Interpreter.cpp:
(JSC::sizeOfVarargs):
(JSC::sizeFrameForVarargs):
* interpreter/Interpreter.h:
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::readInlinedFrame):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitExceptionCheck):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::addressFor):
(JSC::AssemblyHelpers::calleeFrameSlot):
(JSC::AssemblyHelpers::calleeArgumentSlot):
(JSC::AssemblyHelpers::calleeFrameTagSlot):
(JSC::AssemblyHelpers::calleeFramePayloadSlot):
(JSC::AssemblyHelpers::calleeArgumentTagSlot):
(JSC::AssemblyHelpers::calleeArgumentPayloadSlot):
(JSC::AssemblyHelpers::calleeFrameCallerFrame):
(JSC::AssemblyHelpers::selectScratchGPR):
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState):
* jit/GPRInfo.h:
* jit/JIT.cpp:
(JSC::JIT::privateCompile):
* jit/JIT.h:
* jit/JITCall.cpp:
(JSC::JIT::compileSetupVarargsFrame):
(JSC::JIT::compileOpCall):
* jit/JITCall32_64.cpp:
(JSC::JIT::compileSetupVarargsFrame):
(JSC::JIT::compileOpCall):
* jit/JITOperations.h:
* jit/SetupVarargsFrame.cpp:
(JSC::emitSetupVarargsFrameFastCase):
* jit/SetupVarargsFrame.h:
* runtime/Arguments.h:
(JSC::Arguments::create):
(JSC::Arguments::registerArraySizeInBytes):
(JSC::Arguments::finishCreation):
* runtime/Options.h:
* tests/stress/construct-varargs-inline-smaller-Foo.js: Added.
(Foo):
(bar):
(checkEqual):
(test):
* tests/stress/construct-varargs-inline.js: Added.
(Foo):
(bar):
(checkEqual):
(test):
* tests/stress/construct-varargs-no-inline.js: Added.
(Foo):
(bar):
(checkEqual):
(test):
* tests/stress/get-argument-by-val-in-inlined-varargs-call-out-of-bounds.js: Added.
(foo):
(bar):
* tests/stress/get-argument-by-val-safe-in-inlined-varargs-call-out-of-bounds.js: Added.
(foo):
(bar):
* tests/stress/get-my-argument-by-val-creates-arguments.js: Added.
(blah):
(foo):
(bar):
(checkEqual):
(test):
* tests/stress/load-varargs-then-inlined-call-exit-in-foo.js: Added.
(foo):
(bar):
(checkEqual):
* tests/stress/load-varargs-then-inlined-call-inlined.js: Added.
(foo):
(bar):
(baz):
(checkEqual):
(test):
* tests/stress/load-varargs-then-inlined-call.js: Added.
(foo):
(bar):
(checkEqual):
(test):
2015-02-17 Michael Saboff <msaboff@apple.com>
Unreviewed, Restoring the C LOOP insta-crash fix in r180184.
Fixed a typo that only affected the C Loop in the prologue() macro in LowLevelInterpreter.asm.
After the stackHeightOKGetCodeBlock label, codeBlockSetter(t1) should be codeBlockGetter(t1).
* llint/LowLevelInterpreter.asm: Fixed a typo.
2015-02-18 Csaba Osztrogonác <ossy@webkit.org>
URTBF after r180258 to fix Windows build.
* runtime/MathCommon.cpp:
(JSC::mathPowInternal):
2015-02-18 Joseph Pecoraro <pecoraro@apple.com>
REGRESSION(r180235): It broke the !ENABLE(PROMISES) build
https://bugs.webkit.org/show_bug.cgi?id=141746
Unreviewed build fix.
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::getInternalProperties):
Wrap JSPromise related code in ENABLE(PROMISES) guard.
2015-02-18 Benjamin Poulain <benjamin@webkit.org>
Fix the C-Loop LLInt build
https://bugs.webkit.org/show_bug.cgi?id=141618
Reviewed by Filip Pizlo.
I broke C-Loop when moving the common code of pow()
to JITOperations because that file is #ifdefed out
when the JITs are disabled.
It would be weird to move it back to MathObject since
the function needs to know about the calling conventions.
To avoid making a mess, I just gave the function its own file
that is used by both the runtime and the JIT.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAbstractInterpreterInlines.h:
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* runtime/MathCommon.cpp: Added.
(JSC::fdlibmScalbn):
(JSC::fdlibmPow):
(JSC::isDenormal):
(JSC::isEdgeCase):
(JSC::mathPowInternal):
(JSC::operationMathPow):
* runtime/MathCommon.h: Added.
* runtime/MathObject.cpp:
2015-02-17 Benjamin Poulain <bpoulain@apple.com>
Clean up OSRExit's considerAddingAsFrequentExitSite()
https://bugs.webkit.org/show_bug.cgi?id=141690
Reviewed by Anders Carlsson.
Looks like some code was removed from CodeBlock::tallyFrequentExitSites()
and the OSRExit were left untouched.
This patch cleans up the two loops and remove the boolean return
on considerAddingAsFrequentExitSite().
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::tallyFrequentExitSites):
* dfg/DFGOSRExit.h:
(JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
* dfg/DFGOSRExitBase.cpp:
(JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):
* dfg/DFGOSRExitBase.h:
(JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSite):
* ftl/FTLOSRExit.h:
(JSC::FTL::OSRExit::considerAddingAsFrequentExitSite):
2015-02-17 Alexey Proskuryakov <ap@apple.com>
Debug build fix after r180247.
* ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::loweringFailed):
2015-02-17 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r180184.
https://bugs.webkit.org/show_bug.cgi?id=141733
Caused infinite recursion on js/function-apply-aliased.html
(Requested by ap_ on #webkit).
Reverted changeset:
"REGRESSION(r180060): C Loop crashes"
https://bugs.webkit.org/show_bug.cgi?id=141671
http://trac.webkit.org/changeset/180184
2015-02-17 Michael Saboff <msaboff@apple.com>
CrashTracer: DFG_CRASH beneath JSC::FTL::LowerDFGToLLVM::compileNode
https://bugs.webkit.org/show_bug.cgi?id=141730
Reviewed by Geoffrey Garen.
Added a new failure handler, loweringFailed(), to LowerDFGToLLVM that reports failures
while processing DFG lowering. For debug builds, the failures are logged identical
to the way the DFG_CRASH() reports them. For release builds, the failures are reported
and that FTL compilation is terminated, but the process is allowed to continue.
Wrapped calls to loweringFailed() in a macro LOWERING_FAILED so the function and
line number are reported at the point of the inconsistancy.
Converted instances of DFG_CRASH to LOWERING_FAILED.
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl): Added lowerDFGToLLVM() failure check that
will fail the FTL compile.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
Added new member variable, m_loweringSucceeded, to stop compilation on the first
reported failure.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::lower):
* ftl/FTLLowerDFGToLLVM.h:
Added check for compilation failures and now report those failures via a boolean
return value.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::createPhiVariables):
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileUpsilon):
(JSC::FTL::LowerDFGToLLVM::compilePhi):
(JSC::FTL::LowerDFGToLLVM::compileDoubleRep):
(JSC::FTL::LowerDFGToLLVM::compileValueRep):
(JSC::FTL::LowerDFGToLLVM::compileValueToInt32):
(JSC::FTL::LowerDFGToLLVM::compilePutLocal):
(JSC::FTL::LowerDFGToLLVM::compileArithAddOrSub):
(JSC::FTL::LowerDFGToLLVM::compileArithMul):
(JSC::FTL::LowerDFGToLLVM::compileArithDiv):
(JSC::FTL::LowerDFGToLLVM::compileArithMod):
(JSC::FTL::LowerDFGToLLVM::compileArithMinOrMax):
(JSC::FTL::LowerDFGToLLVM::compileArithAbs):
(JSC::FTL::LowerDFGToLLVM::compileArithNegate):
(JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):
(JSC::FTL::LowerDFGToLLVM::compileGetById):
(JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentByVal):
(JSC::FTL::LowerDFGToLLVM::compileGetArrayLength):
(JSC::FTL::LowerDFGToLLVM::compileGetByVal):
(JSC::FTL::LowerDFGToLLVM::compilePutByVal):
(JSC::FTL::LowerDFGToLLVM::compileArrayPush):
(JSC::FTL::LowerDFGToLLVM::compileArrayPop):
(JSC::FTL::LowerDFGToLLVM::compileNewArray):
(JSC::FTL::LowerDFGToLLVM::compileToString):
(JSC::FTL::LowerDFGToLLVM::compileMakeRope):
(JSC::FTL::LowerDFGToLLVM::compileCompareEq):
(JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
(JSC::FTL::LowerDFGToLLVM::compileSwitch):
(JSC::FTL::LowerDFGToLLVM::compare):
(JSC::FTL::LowerDFGToLLVM::boolify):
(JSC::FTL::LowerDFGToLLVM::opposite):
(JSC::FTL::LowerDFGToLLVM::lowJSValue):
(JSC::FTL::LowerDFGToLLVM::speculate):
(JSC::FTL::LowerDFGToLLVM::isArrayType):
(JSC::FTL::LowerDFGToLLVM::exitValueForAvailability):
(JSC::FTL::LowerDFGToLLVM::exitValueForNode):
(JSC::FTL::LowerDFGToLLVM::setInt52):
Changed DFG_CRASH() to LOWERING_FAILED(). Updated related control flow as appropriate.
(JSC::FTL::LowerDFGToLLVM::loweringFailed): New error reporting member function.
2015-02-17 Filip Pizlo <fpizlo@apple.com>
StackLayoutPhase should use CodeBlock::usesArguments rather than FunctionExecutable::usesArguments
https://bugs.webkit.org/show_bug.cgi?id=141721
rdar://problem/17198633
Reviewed by Michael Saboff.
I've seen cases where the two are out of sync. We know we can trust the CodeBlock::usesArguments because
we use it everywhere else.
No test because I could never reproduce the crash.
* dfg/DFGGraph.h:
(JSC::DFG::Graph::usesArguments):
* dfg/DFGStackLayoutPhase.cpp:
(JSC::DFG::StackLayoutPhase::run):
2015-02-16 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Improved Console Support for Bound Functions
https://bugs.webkit.org/show_bug.cgi?id=141635
Reviewed by Timothy Hatcher.
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::getInternalProperties):
Expose internal properties of a JSBoundFunction.
2015-02-16 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: ES6: Improved Console Support for Promise Objects
https://bugs.webkit.org/show_bug.cgi?id=141634
Reviewed by Timothy Hatcher.
* inspector/InjectedScript.cpp:
(Inspector::InjectedScript::getInternalProperties):
* inspector/InjectedScriptSource.js:
Include internal properties in previews. Share code
with normal internal property handling.
* inspector/JSInjectedScriptHost.cpp:
(Inspector::constructInternalProperty):
(Inspector::JSInjectedScriptHost::getInternalProperties):
Provide internal state of Promises.
* inspector/protocol/Runtime.json:
Provide an optional field to distinguish if a PropertyPreview
is for an Internal property or not.
2015-02-17 Filip Pizlo <fpizlo@apple.com>
Throwing from an FTL call IC slow path may result in tag registers being clobbered on 64-bit CPUs
https://bugs.webkit.org/show_bug.cgi?id=141717
rdar://problem/19863382
Reviewed by Geoffrey Garen.
The best solution is to ensure that the engine catching an exception restores tag registers.
Each of these new test cases reliably crashed prior to this patch and they don't crash at all now.
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_catch):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter64.asm:
* tests/stress/throw-from-ftl-call-ic-slow-path-cells.js: Added.
* tests/stress/throw-from-ftl-call-ic-slow-path-undefined.js: Added.
* tests/stress/throw-from-ftl-call-ic-slow-path.js: Added.
2015-02-17 Csaba Osztrogonác <ossy@webkit.org>
[ARM] Add the necessary setupArgumentsWithExecState after bug141332
https://bugs.webkit.org/show_bug.cgi?id=141714
Reviewed by Michael Saboff.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState):
2015-02-15 Sam Weinig <sam@webkit.org>
Add experimental <attachment> element support
https://bugs.webkit.org/show_bug.cgi?id=141626
Reviewed by Tim Horton.
* Configurations/FeatureDefines.xcconfig:
2015-02-16 Michael Saboff <msaboff@apple.com>
REGRESSION(r180060): C Loop crashes
https://bugs.webkit.org/show_bug.cgi?id=141671
Reviewed by Geoffrey Garen.
Fixed a typo that only affected the C Loop in the prologue() macro in LowLevelInterpreter.asm.
After the stackHeightOKGetCodeBlock label, codeBlockSetter(t1) should be codeBlockGetter(t1).
Fixed the processing of an out of stack exception in llint_stack_check to not get the caller's
frame. This isn't needed, since this helper is only called to check the stack on entry. Any
exception will be handled by a call ancestor.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::llint_stack_check): Changed to use the current frame for processing an exception.
* llint/LowLevelInterpreter.asm: Fixed a typo.
2015-02-16 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Scope details sidebar should label objects with constructor names
https://bugs.webkit.org/show_bug.cgi?id=139449
Reviewed by Timothy Hatcher.
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::internalConstructorName):
* runtime/Structure.cpp:
(JSC::Structure::toStructureShape):
Share calculatedClassName.
* runtime/JSObject.h:
* runtime/JSObject.cpp:
(JSC::JSObject::calculatedClassName):
Elaborate on a way to get an Object's class name.
2015-02-16 Filip Pizlo <fpizlo@apple.com>
DFG SSA should use GetLocal for arguments, and the GetArgument node type should be removed
https://bugs.webkit.org/show_bug.cgi?id=141623
Reviewed by Oliver Hunt.
During development of https://bugs.webkit.org/show_bug.cgi?id=141332, I realized that I
needed to use GetArgument for loading something that has magically already appeared on the
stack, so currently trunk sort of allows this. But then I realized three things:
- A GetArgument with a non-JSValue flush format means speculating that the value on the
stack obeys that format, rather than just assuming that that it already has that format.
In bug 141332, I want it to assume rather than speculate. That also happens to be more
intuitive; I don't think I was wrong to expect that.
- The node I really want is GetLocal. I'm just getting the value of the local and I don't
want to do anything else.
- Maybe it would be easier if we just used GetLocal for all of the cases where we currently
use GetArgument.
This changes the FTL to do argument speculations in the prologue just like the DFG does.
This brings some consistency to our system, and allows us to get rid of the GetArgument
node. The speculations that the FTL must do are now made explicit in the m_argumentFormats
vector in DFG::Graph. This has natural DCE behavior: even if all uses of the argument are
dead we will still speculate. We already have safeguards to ensure we only speculate if
there are uses that benefit from speculation (which is a much more conservative criterion
than DCE).
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDCEPhase.cpp:
(JSC::DFG::DCEPhase::run):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGFlushFormat.h:
(JSC::DFG::typeFilterFor):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::valueProfileFor):
(JSC::DFG::Graph::methodOfGettingAValueProfileFor):
* dfg/DFGInPlaceAbstractState.cpp:
(JSC::DFG::InPlaceAbstractState::initialize):
* dfg/DFGNode.cpp:
(JSC::DFG::Node::hasVariableAccessData):
* dfg/DFGNodeType.h:
* dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
(JSC::DFG::OSRAvailabilityAnalysisPhase::run):
(JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGPutLocalSinkingPhase.cpp:
* dfg/DFGSSAConversionPhase.cpp:
(JSC::DFG::SSAConversionPhase::run):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::lower):
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileGetLocal):
(JSC::FTL::LowerDFGToLLVM::compileGetArgument): Deleted.
* tests/stress/dead-speculating-argument-use.js: Added.
(foo):
(o.valueOf):
2015-02-15 Filip Pizlo <fpizlo@apple.com>
Rare case profiling should actually work
https://bugs.webkit.org/show_bug.cgi?id=141632
Reviewed by Michael Saboff.
This simple adjustment appears to be a 2% speed-up on Octane. Over time, the slow case
heuristic has essentially stopped working because the typical execution count threshold for a
bytecode instruction is around 66 while the slow case threshold is 100: virtually
guaranteeing that the DFG will never think that a bytecode instruction has taken the slow
case even if it took it every single time. So, this changes the slow case threshold to 20.
I checked if we could lower this down further, like to 10. That is worse than 20, and about
as bad as 100.
* runtime/Options.h:
2015-02-15 Brian J. Burg <burg@cs.washington.edu>
Web Inspector: remove unused XHR replay code
https://bugs.webkit.org/show_bug.cgi?id=141622
Reviewed by Timothy Hatcher.
* inspector/protocol/Network.json: remove XHR replay methods.
2015-02-15 David Kilzer <ddkilzer@apple.com>
REGRESSION (r180082): WebCore Debug builds fail on Mavericks due to weak export symbols
<http://webkit.org/b/141607>
More work towards fixing the Mavericks Debug build.
* inspector/ScriptDebugServer.h:
(Inspector::ScriptDebugServer::Task):
* inspector/agents/InspectorDebuggerAgent.h:
(Inspector::InspectorDebuggerAgent::Listener):
- Remove subclass exports. They did not help.
* runtime/JSCJSValue.h:
(JSC::JSValue::toFloat): Do not mark inline method for export.
2015-02-09 Brian J. Burg <burg@cs.washington.edu>
Web Inspector: remove some unnecessary Inspector prefixes from class names in Inspector namespace
https://bugs.webkit.org/show_bug.cgi?id=141372
Reviewed by Joseph Pecoraro.
* inspector/ConsoleMessage.cpp:
(Inspector::ConsoleMessage::addToFrontend):
(Inspector::ConsoleMessage::updateRepeatCountInConsole):
* inspector/ConsoleMessage.h:
* inspector/InspectorAgentBase.h:
* inspector/InspectorAgentRegistry.cpp:
(Inspector::AgentRegistry::AgentRegistry):
(Inspector::AgentRegistry::append):
(Inspector::AgentRegistry::appendExtraAgent):
(Inspector::AgentRegistry::didCreateFrontendAndBackend):
(Inspector::AgentRegistry::willDestroyFrontendAndBackend):
(Inspector::AgentRegistry::discardAgents):
(Inspector::InspectorAgentRegistry::InspectorAgentRegistry): Deleted.
(Inspector::InspectorAgentRegistry::append): Deleted.
(Inspector::InspectorAgentRegistry::appendExtraAgent): Deleted.
(Inspector::InspectorAgentRegistry::didCreateFrontendAndBackend): Deleted.
(Inspector::InspectorAgentRegistry::willDestroyFrontendAndBackend): Deleted.
(Inspector::InspectorAgentRegistry::discardAgents): Deleted.
* inspector/InspectorAgentRegistry.h:
* inspector/InspectorBackendDispatcher.cpp:
(Inspector::BackendDispatcher::CallbackBase::CallbackBase):
(Inspector::BackendDispatcher::CallbackBase::isActive):
(Inspector::BackendDispatcher::CallbackBase::sendFailure):
(Inspector::BackendDispatcher::CallbackBase::sendIfActive):
(Inspector::BackendDispatcher::create):
(Inspector::BackendDispatcher::registerDispatcherForDomain):
(Inspector::BackendDispatcher::dispatch):
(Inspector::BackendDispatcher::sendResponse):
(Inspector::BackendDispatcher::reportProtocolError):
(Inspector::BackendDispatcher::getInteger):
(Inspector::BackendDispatcher::getDouble):
(Inspector::BackendDispatcher::getString):
(Inspector::BackendDispatcher::getBoolean):
(Inspector::BackendDispatcher::getObject):
(Inspector::BackendDispatcher::getArray):
(Inspector::BackendDispatcher::getValue):
(Inspector::InspectorBackendDispatcher::CallbackBase::CallbackBase): Deleted.
(Inspector::InspectorBackendDispatcher::CallbackBase::isActive): Deleted.
(Inspector::InspectorBackendDispatcher::CallbackBase::sendFailure): Deleted.
(Inspector::InspectorBackendDispatcher::CallbackBase::sendIfActive): Deleted.
(Inspector::InspectorBackendDispatcher::create): Deleted.
(Inspector::InspectorBackendDispatcher::registerDispatcherForDomain): Deleted.
(Inspector::InspectorBackendDispatcher::dispatch): Deleted.
(Inspector::InspectorBackendDispatcher::sendResponse): Deleted.
(Inspector::InspectorBackendDispatcher::reportProtocolError): Deleted.
(Inspector::InspectorBackendDispatcher::getInteger): Deleted.
(Inspector::InspectorBackendDispatcher::getDouble): Deleted.
(Inspector::InspectorBackendDispatcher::getString): Deleted.
(Inspector::InspectorBackendDispatcher::getBoolean): Deleted.
(Inspector::InspectorBackendDispatcher::getObject): Deleted.
(Inspector::InspectorBackendDispatcher::getArray): Deleted.
(Inspector::InspectorBackendDispatcher::getValue): Deleted.
* inspector/InspectorBackendDispatcher.h:
(Inspector::SupplementalBackendDispatcher::SupplementalBackendDispatcher):
(Inspector::SupplementalBackendDispatcher::~SupplementalBackendDispatcher):
(Inspector::InspectorSupplementalBackendDispatcher::InspectorSupplementalBackendDispatcher): Deleted.
(Inspector::InspectorSupplementalBackendDispatcher::~InspectorSupplementalBackendDispatcher): Deleted.
* inspector/InspectorFrontendChannel.h:
(Inspector::FrontendChannel::~FrontendChannel):
(Inspector::InspectorFrontendChannel::~InspectorFrontendChannel): Deleted.
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
(Inspector::JSGlobalObjectInspectorController::globalObjectDestroyed):
(Inspector::JSGlobalObjectInspectorController::connectFrontend):
(Inspector::JSGlobalObjectInspectorController::disconnectFrontend):
(Inspector::JSGlobalObjectInspectorController::dispatchMessageFromFrontend):
(Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
* inspector/JSGlobalObjectInspectorController.h:
* inspector/agents/InspectorAgent.cpp:
(Inspector::InspectorAgent::didCreateFrontendAndBackend):
(Inspector::InspectorAgent::willDestroyFrontendAndBackend):
* inspector/agents/InspectorAgent.h:
* inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::didCreateFrontendAndBackend):
(Inspector::InspectorConsoleAgent::willDestroyFrontendAndBackend):
* inspector/agents/InspectorConsoleAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::didCreateFrontendAndBackend):
(Inspector::InspectorDebuggerAgent::willDestroyFrontendAndBackend):
(Inspector::InspectorDebuggerAgent::handleConsoleAssert):
(Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement):
(Inspector::InspectorDebuggerAgent::pause):
(Inspector::InspectorDebuggerAgent::scriptExecutionBlockedByCSP):
(Inspector::InspectorDebuggerAgent::didPause):
(Inspector::InspectorDebuggerAgent::breakProgram):
(Inspector::InspectorDebuggerAgent::clearBreakDetails):
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::willDestroyFrontendAndBackend):
* inspector/agents/InspectorRuntimeAgent.h:
* inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
(Inspector::JSGlobalObjectRuntimeAgent::didCreateFrontendAndBackend):
(Inspector::JSGlobalObjectRuntimeAgent::willDestroyFrontendAndBackend):
* inspector/agents/JSGlobalObjectRuntimeAgent.h:
* inspector/augmentable/AlternateDispatchableAgent.h:
* inspector/augmentable/AugmentableInspectorController.h:
* inspector/remote/RemoteInspectorDebuggable.h:
* inspector/remote/RemoteInspectorDebuggableConnection.h:
* inspector/scripts/codegen/cpp_generator.py:
(CppGenerator.cpp_type_for_formal_out_parameter):
(CppGenerator.cpp_type_for_stack_out_parameter):
* inspector/scripts/codegen/cpp_generator_templates.py:
(AlternateBackendDispatcher):
(Alternate):
(void):
(AlternateInspectorBackendDispatcher): Deleted.
(AlternateInspector): Deleted.
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
(CppBackendDispatcherHeaderGenerator._generate_alternate_handler_forward_declarations_for_domains.Alternate):
(CppBackendDispatcherHeaderGenerator._generate_dispatcher_declaration_for_command):
(CppBackendDispatcherHeaderGenerator._generate_alternate_handler_forward_declarations_for_domains.AlternateInspector): Deleted.
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
(CppBackendDispatcherImplementationGenerator._generate_handler_class_destructor_for_domain):
(CppBackendDispatcherImplementationGenerator._generate_large_dispatcher_switch_implementation_for_domain):
(CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
(CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event):
* inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
(ObjCFrontendDispatcherImplementationGenerator._generate_event):
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
* runtime/JSGlobalObjectDebuggable.cpp:
(JSC::JSGlobalObjectDebuggable::connect):
(JSC::JSGlobalObjectDebuggable::disconnect):
* runtime/JSGlobalObjectDebuggable.h:
2015-02-14 David Kilzer <ddkilzer@apple.com>
REGRESSION (r180082): WebCore Debug builds fail on Mavericks due to weak export symbols
<http://webkit.org/b/141607>
Work towards fixing the Mavericks Debug build.
* inspector/ScriptDebugServer.h:
(Inspector::ScriptDebugServer::Task): Export class.
* inspector/agents/InspectorDebuggerAgent.h:
(Inspector::InspectorDebuggerAgent::Listener): Export class.
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::setConsoleClient): Do not mark inline
method for export.
2015-02-14 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Symbol RemoteObject should not send sub-type
https://bugs.webkit.org/show_bug.cgi?id=141604
Reviewed by Brian Burg.
* inspector/InjectedScriptSource.js:
2015-02-13 Benjamin Poulain <bpoulain@apple.com>
Attempt to fix 32bits build after r180098
* jit/JITOperations.cpp:
* jit/JITOperations.h:
I copied the attribute from the MathObject version of that function when I moved
it over. DFG has no version of a function call taking those attributes.
2015-02-13 Joseph Pecoraro <pecoraro@apple.com>
JSContext Inspector: Do not stash console messages for non-debuggable JSContext
https://bugs.webkit.org/show_bug.cgi?id=141589
Reviewed by Timothy Hatcher.
Consider developer extras disabled for JSContext inspection if the
RemoteInspector server is not enabled (typically a non-debuggable
process rejected by webinspectord) or if remote debugging on the
JSContext was explicitly disabled via SPI.
When developer extras are disabled, console message will not be stashed.
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::developerExtrasEnabled):
* inspector/JSGlobalObjectInspectorController.h:
2015-02-13 Benjamin Poulain <bpoulain@apple.com>
Add a DFG node for the Pow Intrinsics
https://bugs.webkit.org/show_bug.cgi?id=141540
Reviewed by Filip Pizlo.
Add a DFG Node for PowIntrinsic. This patch covers the basic cases
need to avoid massive regression. I will iterate over the node to cover
the missing types.
With this patch I get the following progressions on benchmarks:
-LongSpider's math-partial-sums: +5%.
-Kraken's imaging-darkroom: +17%
-AsmBench's cray.c: +6.6%
-CompressionBench: +2.2% globally.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
Cover a couple of trivial cases:
-If the exponent is zero, the result is always one, regardless of the base.
-If both arguments are constants, compute the result at compile time.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsic):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
We only support 2 basic cases at this time:
-Math.pow(double, int)
-Math.pow(double, double).
I'll cover Math.pow(int, int) in a follow up.
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToArithSqrt):
(JSC::DFG::Node::arithNodeFlags):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
(JSC::DFG::PredictionPropagationPhase::doDoubleVoting):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::compileArithPowIntegerFastPath):
(JSC::DFG::SpeculativeJIT::compileArithPow):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::validate):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLIntrinsicRepository.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileArithPow):
* ftl/FTLOutput.h:
(JSC::FTL::Output::doublePow):
(JSC::FTL::Output::doublePowi):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* runtime/MathObject.cpp:
(JSC::mathProtoFuncPow):
(JSC::isDenormal): Deleted.
(JSC::isEdgeCase): Deleted.
(JSC::mathPow): Deleted.
* tests/stress/math-pow-basics.js: Added.
* tests/stress/math-pow-integer-exponent-fastpath.js: Added.
* tests/stress/math-pow-nan-behaviors.js: Added.
* tests/stress/math-pow-with-constants.js: Added.
Start some basic testing of Math.pow().
Due to the various transform, the value change when the code tiers up,
I covered this by checking for approximate values.
2015-02-13 Benjamin Poulain <bpoulain@apple.com>
ArithSqrt should not be conditional on supportsFloatingPointSqrt
https://bugs.webkit.org/show_bug.cgi?id=141546
Reviewed by Geoffrey Garen and Filip Pizlo.
Just fallback to the function call in the DFG codegen.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsic):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithSqrt):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* tests/stress/math-sqrt-basics.js: Added.
Basic coverage.
* tests/stress/math-sqrt-basics-disable-architecture-specific-optimizations.js: Added.
Same tests but forcing the function call.
2015-02-13 Michael Saboff <msaboff@apple.com>
REGRESSION(r180060) New js/regress-141098 test crashes when LLInt is disabled.
https://bugs.webkit.org/show_bug.cgi?id=141577
Reviewed by Benjamin Poulain.
Changed the prologue of the baseline JIT to check for stack space for all
types of code blocks. Previously, it was only checking Function. Now
it checks Program and Eval as well.
* jit/JIT.cpp:
(JSC::JIT::privateCompile):
2015-02-13 Benjamin Poulain <bpoulain@apple.com>
Generate incq instead of addq when the immediate value is one
https://bugs.webkit.org/show_bug.cgi?id=141548
Reviewed by Gavin Barraclough.
JSC emits "addq #1 (rXX)" *a lot*.
This patch replace that by incq, which is one byte shorter
and is the adviced form.
Sunspider: +0.47%
Octane: +0.28%
Kraken: +0.44%
AsmBench, CompressionBench: neutral.
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::add64):
* assembler/X86Assembler.h:
(JSC::X86Assembler::incq_m):
2015-02-13 Benjamin Poulain <benjamin@webkit.org>
Little clean up of Bytecode Generator's Label
https://bugs.webkit.org/show_bug.cgi?id=141557
Reviewed by Michael Saboff.
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/BytecodeGenerator.cpp:
Label was a friend of BytecodeGenerator in order to access
m_instructions. There is no need for that, BytecodeGenerator
has a public getter.
* bytecompiler/Label.h:
(JSC::Label::Label):
(JSC::Label::setLocation):
(JSC::BytecodeGenerator::newLabel):
Make it explicit that the generator must exist.
2015-02-13 Michael Saboff <msaboff@apple.com>
Google doc spreadsheet reproducibly crashes when sorting
https://bugs.webkit.org/show_bug.cgi?id=141098
Reviewed by Oliver Hunt.
Moved the stack check to before the callee registers are allocated in the
prologue() by movving it from the functionInitialization() macro. This
way we can check the stack before moving the stack pointer, avoiding a
crash during a "call" instruction. Before this change, we weren't even
checking the stack for program and eval execution.
Made a couple of supporting changes.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::llint_stack_check): We can't just go up one frame as we
may be processing an exception to an entry frame.
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
(llint_throw_from_slow_path_trampoline): Changed method to get the vm
from the code block to not use the codeBlock, since we may need to
continue from an exception in a native function.
2015-02-12 Benjamin Poulain <benjamin@webkit.org>
Simplify the initialization of BytecodeGenerator a bit
https://bugs.webkit.org/show_bug.cgi?id=141505
Reviewed by Anders Carlsson.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
* bytecompiler/BytecodeGenerator.h:
Setup the default initialization at the declaration level
instead of the constructor.
Also made m_scopeNode and m_codeType const to make it explicit
that they are invariant after construction.
* parser/Nodes.cpp:
* runtime/Executable.cpp:
Remove 2 useless #includes.
2015-02-12 Benjamin Poulain <benjamin@webkit.org>
Move the generators for GetScope and SkipScope to the common core in DFGSpeculativeJIT
https://bugs.webkit.org/show_bug.cgi?id=141506
Reviewed by Michael Saboff.
The generators for the nodes GetScope and SkipScope were
completely identical between 32 and 64bits.
This patch moves the duplicated code to DFGSpeculativeJIT.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetScope):
(JSC::DFG::SpeculativeJIT::compileSkipScope):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
2015-02-11 Brent Fulgham <bfulgham@apple.com>
[Win] [64-bit] Work around MSVC2013 Runtime Bug
https://bugs.webkit.org/show_bug.cgi?id=141498
<rdar://problem/19803642>
Reviewed by Anders Carlsson.
Disable FMA3 instruction use in the MSVC math library to
work around a VS2013 runtime crash. We can remove this
workaround when we switch to VS2015.
* API/tests/testapi.c: Call _set_FMA3_enable(0) to disable
FMA3 support.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Add new files.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto.
* JavaScriptCore.vcxproj/JavaScriptCoreDLL.cpp: Added.
* JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp: Call _set_FMA3_enable(0)
to disable FMA3 support.
* jsc.cpp: Ditto.
* testRegExp.cpp: Ditto.
2015-02-11 Filip Pizlo <fpizlo@apple.com>
The callee frame helpers in DFG::SpeculativeJIT should be available to other JITs
https://bugs.webkit.org/show_bug.cgi?id=141493
Reviewed by Michael Saboff.
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::calleeFrameSlot): Deleted.
(JSC::DFG::SpeculativeJIT::calleeArgumentSlot): Deleted.
(JSC::DFG::SpeculativeJIT::calleeFrameTagSlot): Deleted.
(JSC::DFG::SpeculativeJIT::calleeFramePayloadSlot): Deleted.
(JSC::DFG::SpeculativeJIT::calleeArgumentTagSlot): Deleted.
(JSC::DFG::SpeculativeJIT::calleeArgumentPayloadSlot): Deleted.
(JSC::DFG::SpeculativeJIT::calleeFrameCallerFrame): Deleted.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::calleeFrameSlot):
(JSC::AssemblyHelpers::calleeArgumentSlot):
(JSC::AssemblyHelpers::calleeFrameTagSlot):
(JSC::AssemblyHelpers::calleeFramePayloadSlot):
(JSC::AssemblyHelpers::calleeArgumentTagSlot):
(JSC::AssemblyHelpers::calleeArgumentPayloadSlot):
(JSC::AssemblyHelpers::calleeFrameCallerFrame):
2015-02-11 Filip Pizlo <fpizlo@apple.com>
SetupVarargsFrame should not assume that an inline stack frame would have identical layout to a normal stack frame
https://bugs.webkit.org/show_bug.cgi?id=141485
Reviewed by Oliver Hunt.
The inlineStackOffset argument was meant to make it easy for the DFG to use this helper for
vararg calls from inlined code, but that doesn't work since the DFG inline call frame
doesn't actually put the argument count at the JSStack::ArgumentCount offset. In fact there
is really no such thing as an inlineStackOffset except when we OSR exit; while the code is
running the stack layout is compacted so that the stackOffset is not meaningful.
* jit/JITCall.cpp:
(JSC::JIT::compileSetupVarargsFrame):
* jit/JITCall32_64.cpp:
(JSC::JIT::compileSetupVarargsFrame):
* jit/SetupVarargsFrame.cpp:
(JSC::emitSetupVarargsFrameFastCase):
* jit/SetupVarargsFrame.h:
2015-02-10 Filip Pizlo <fpizlo@apple.com>
Split FTL::JSCall into the part that knows about call inline caching and the part that interacts with LLVM patchpoints
https://bugs.webkit.org/show_bug.cgi?id=141455
Reviewed by Mark Lam.
The newly introduced FTL::JSCallBase can be used to build other things, like the FTL portion
of https://bugs.webkit.org/show_bug.cgi?id=141332.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::specializationKindFor):
(JSC::CallLinkInfo::specializationKind):
* ftl/FTLJSCall.cpp:
(JSC::FTL::JSCall::JSCall):
(JSC::FTL::JSCall::emit): Deleted.
(JSC::FTL::JSCall::link): Deleted.
* ftl/FTLJSCall.h:
* ftl/FTLJSCallBase.cpp: Added.
(JSC::FTL::JSCallBase::JSCallBase):
(JSC::FTL::JSCallBase::emit):
(JSC::FTL::JSCallBase::link):
* ftl/FTLJSCallBase.h: Added.
2015-02-10 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix build.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState):
2015-02-10 Filip Pizlo <fpizlo@apple.com>
op_call_varargs should only load the length once
https://bugs.webkit.org/show_bug.cgi?id=141440
rdar://problem/19761683
Reviewed by Michael Saboff.
Refactors the pair of calls that set up the varargs frame so that the first call returns the
length, and the second call uses the length returned by the first one. It turns out that this
gave me an opportunity to shorten a lot of the code.
* interpreter/Interpreter.cpp:
(JSC::sizeFrameForVarargs):
(JSC::loadVarargs):
(JSC::setupVarargsFrame):
(JSC::setupVarargsFrameAndSetThis):
* interpreter/Interpreter.h:
(JSC::calleeFrameForVarargs):
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState):
* jit/JIT.h:
* jit/JITCall.cpp:
(JSC::JIT::compileSetupVarargsFrame):
* jit/JITCall32_64.cpp:
(JSC::JIT::compileSetupVarargsFrame):
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/SetupVarargsFrame.cpp:
(JSC::emitSetVarargsFrame):
(JSC::emitSetupVarargsFrameFastCase):
* jit/SetupVarargsFrame.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/Arguments.cpp:
(JSC::Arguments::copyToArguments):
* runtime/Arguments.h:
* runtime/JSArray.cpp:
(JSC::JSArray::copyToArguments):
* runtime/JSArray.h:
* runtime/VM.h:
* tests/stress/call-varargs-length-effects.js: Added.
(foo):
(bar):
2015-02-10 Michael Saboff <msaboff@apple.com>
Crash in JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq
https://bugs.webkit.org/show_bug.cgi?id=139398
Reviewed by Filip Pizlo.
Due to CFA analysis, the CompareStrictEq node was determined to be unreachable, but later
was determined to be reachable. When we go to lower to LLVM, the edges for the CompareStrictEq
node are UntypedUse which we can't compile. Fixed this by checking that the IR before
lowering can still be handled by the FTL.
Had to add GetArgument as a node that the FTL can compile as the SSA conversion phase converts
a SetArgument to a GetArgument. Before this change FTL::canCompile() would never see a GetArgument
node. With the check right before lowering, we see this node.
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl): Added a final FTL::canCompile() check before lowering
to verify that after all the transformations we still have valid IR for the FTL.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile): Added GetArgument as a node the FTL can compile.
2015-02-10 Filip Pizlo <fpizlo@apple.com>
Remove unused DFG::SpeculativeJIT::calleeFrameOffset().
Rubber stamped by Michael Saboff.
Not only was this not used, I believe that the math was wrong. The callee frame doesn't
actually land past m_nextMachineLocal; instead it lands just below wherever we put SP and
that decision is made elsewhere. Also, it makes no sense to subtract 1 from
m_nextMachineLocal when trying to deduce the number of in-use stack slots.
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::calleeFrameOffset): Deleted.
2015-02-10 Saam Barati <saambarati1@gmail.com>
Parser::parseVarDeclarationList gets the wrong JSToken for the last identifier
https://bugs.webkit.org/show_bug.cgi?id=141272
Reviewed by Oliver Hunt.
This patch fixes a bug where the wrong text location would be
assigned to a variable declaration inside a ForIn/ForOf loop.
It also fixes a bug in the type profiler where the type profiler
emits the wrong text offset for a ForIn loop's variable declarator
when it's not a pattern node.
* bytecompiler/NodesCodegen.cpp:
(JSC::ForInNode::emitLoopHeader):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseVarDeclarationList):
* tests/typeProfiler/loop.js:
(testForIn):
(testForOf):
2015-02-09 Saam Barati <saambarati1@gmail.com>
JSC's Type Profiler doesn't profile the type of the looping variable in ForOf/ForIn loops
https://bugs.webkit.org/show_bug.cgi?id=141241
Reviewed by Filip Pizlo.
Type information is now recorded for ForIn and ForOf statements.
It was an oversight to not have these statements profiled before.
* bytecompiler/NodesCodegen.cpp:
(JSC::ForInNode::emitLoopHeader):
(JSC::ForOfNode::emitBytecode):
* tests/typeProfiler/loop.js: Added.
(testForIn):
(testForOf):
2015-02-09 Filip Pizlo <fpizlo@apple.com>
DFG::StackLayoutPhase should always set the scopeRegister to VirtualRegister() because the DFG doesn't do anything to make its value valid
https://bugs.webkit.org/show_bug.cgi?id=141412
Reviewed by Michael Saboff.
StackLayoutPhase was attempting to ensure that the register that
CodeBlock::scopeRegister() points to is the right one for the DFG. But the DFG did nothing
else to maintain the validity of the scopeRegister(). It wasn't captured as far as I can
tell. StackLayoutPhase didn't explicitly mark it live. PreciseLocalClobberize didn't mark
it as being live. So, by the time we got here the register referred to by
CodeBlock::scopeRegister() would have been junk. Moreover, CodeBlock::scopeRegister() was
not used for DFG code blocks, and was hardly ever used outside of bytecode generation.
So, this patch just removes the code to manipulate this field and replaces it with an
unconditional setScopeRegister(VirtualRegister()). Setting it to the invalid register
ensures that any attempst to read the scopeRegister in a DFG or FTL frame immediately
punts.
* dfg/DFGStackLayoutPhase.cpp:
(JSC::DFG::StackLayoutPhase::run):
2015-02-09 Filip Pizlo <fpizlo@apple.com>
Varargs frame set-up should be factored out for use by other JITs
https://bugs.webkit.org/show_bug.cgi?id=141388
Reviewed by Michael Saboff.
Previously the code that dealt with varargs always assumed that we were setting up a varargs call
frame by literally following the execution semantics of op_call_varargs. This isn't how it'll
happen once the DFG and FTL do varargs calls, or when varargs calls get inlined. The DFG and FTL
don't literally execute bytecode; for example their stack frame layout has absolutely nothing in
common with what the bytecode says, and that will never change.
This patch makes two changes:
Setting up the varargs callee frame can be done in smaller steps: particularly in the case of a
varargs call that gets inlined, we aren't going to actually want to set up a callee frame in
full - we just want to put the arguments somewhere, and that place will not have much (if
anything) in common with the call frame format. This patch factors that out into something called
a loadVarargs. The thing we used to call loadVarargs is now called setupVarargsFrame. This patch
also separates loading varargs from setting this, since the fact that those two things are done
together is a detail made explicit in bytecode but it's not at all required in the higher-tier
engines. In the process of factoring this code out, I found a bunch of off-by-one errors in the
various calculations. I fixed them. The distance from the caller's frame pointer to the callee
frame pointer is always:
numUsedCallerSlots + argCount + 1 + CallFrameSize
where numUsedCallerSlots is toLocal(firstFreeRegister) - 1, which simplifies down to just
-firstFreeRegister. The code now speaks of numUsedCallerSlots rather than firstFreeRegister,
since the latter is a bytecode peculiarity that doesn't apply in the DFG or FTL. In the DFG, the
internally-computed frame size, minus the parameter slots, will be used for numUsedCallerSlots.
In the FTL, we will essentially compute numUsedCallerSlots dynamically by subtracting SP from FP.
Eventually, LLVM might give us some cleaner way of doing this, but it probably doesn't matter
very much.
The arguments forwarding optimization is factored out of the Baseline JIT: the DFG and FTL will
want to do this optimization as well, but it involves quite a bit of code. So, this code is now
factored out into SetupVarargsFrame.h|cpp, so that other JITs can use it. In the process of factoring
this code out I noticed that the 32-bit and 64-bit code is nearly identical, so I combined them.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.h:
(JSC::ExecState::r):
(JSC::ExecState::uncheckedR):
* bytecode/VirtualRegister.h:
(JSC::VirtualRegister::operator+):
(JSC::VirtualRegister::operator-):
(JSC::VirtualRegister::operator+=):
(JSC::VirtualRegister::operator-=):
* interpreter/CallFrame.h:
* interpreter/Interpreter.cpp:
(JSC::sizeFrameForVarargs):
(JSC::loadVarargs):
(JSC::setupVarargsFrame):
(JSC::setupVarargsFrameAndSetThis):
* interpreter/Interpreter.h:
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitGetFromCallFrameHeaderPtr):
(JSC::AssemblyHelpers::emitGetFromCallFrameHeader32):
(JSC::AssemblyHelpers::emitGetFromCallFrameHeader64):
* jit/JIT.h:
* jit/JITCall.cpp:
(JSC::JIT::compileSetupVarargsFrame):
* jit/JITCall32_64.cpp:
(JSC::JIT::compileSetupVarargsFrame):
* jit/JITInlines.h:
(JSC::JIT::callOperation):
(JSC::JIT::emitGetFromCallFrameHeaderPtr): Deleted.
(JSC::JIT::emitGetFromCallFrameHeader32): Deleted.
(JSC::JIT::emitGetFromCallFrameHeader64): Deleted.
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/SetupVarargsFrame.cpp: Added.
(JSC::emitSetupVarargsFrameFastCase):
* jit/SetupVarargsFrame.h: Added.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/Arguments.cpp:
(JSC::Arguments::copyToArguments):
* runtime/Arguments.h:
* runtime/JSArray.cpp:
(JSC::JSArray::copyToArguments):
* runtime/JSArray.h:
2015-02-09 Filip Pizlo <fpizlo@apple.com>
DFG call codegen should resolve the callee operand as late as possible
https://bugs.webkit.org/show_bug.cgi?id=141398
Reviewed by Mark Lam.
This is mostly a benign restructuring to help with the implementation of
https://bugs.webkit.org/show_bug.cgi?id=141332.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
2015-02-08 Filip Pizlo <fpizlo@apple.com>
DFG should only have two mechanisms for describing effectfulness of nodes; previously there were three
https://bugs.webkit.org/show_bug.cgi?id=141369
Reviewed by Michael Saboff.
We previously used the NodeMightClobber and NodeClobbersWorld NodeFlags to describe
effectfulness. Starting over a year ago, we introduced a more powerful mechanism - the
DFG::clobberize() function. Now we only have one remaining client of the old NodeFlags,
and everyone else uses DFG::clobberize(). We should get rid of those NodeFlags and
finally switch everyone over to DFG::clobberize().
Unfortunately there is still another place where effectfulness of nodes is described: the
AbstractInterpreter. This is because the AbstractInterpreter has special tuning both for
compile time performance and there are places where the AI is more precise than
clobberize() because of its flow-sensitivity.
This means that after this change there will be only two places, rather than three, where
the effectfulness of a node has to be described:
- DFG::clobberize()
- DFG::AbstractInterpreter
* dfg/DFGClobberize.cpp:
(JSC::DFG::clobbersWorld):
* dfg/DFGClobberize.h:
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::attemptToMakeGetTypedArrayByteLength):
(JSC::DFG::FixupPhase::convertToGetArrayLength):
(JSC::DFG::FixupPhase::attemptToMakeGetTypedArrayByteOffset):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::isPredictedNumerical): Deleted.
(JSC::DFG::Graph::byValIsPure): Deleted.
(JSC::DFG::Graph::clobbersWorld): Deleted.
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToConstant):
(JSC::DFG::Node::convertToGetLocalUnlinked):
(JSC::DFG::Node::convertToGetByOffset):
(JSC::DFG::Node::convertToMultiGetByOffset):
(JSC::DFG::Node::convertToPutByOffset):
(JSC::DFG::Node::convertToMultiPutByOffset):
* dfg/DFGNodeFlags.cpp:
(JSC::DFG::dumpNodeFlags):
* dfg/DFGNodeFlags.h:
* dfg/DFGNodeType.h:
2015-02-09 Csaba Osztrogonác <ossy@webkit.org>
Fix the !ENABLE(DFG_JIT) build
https://bugs.webkit.org/show_bug.cgi?id=141387
Reviewed by Darin Adler.
* jit/Repatch.cpp:
2015-02-08 Benjamin Poulain <benjamin@webkit.org>
Remove a few duplicate propagation steps from the DFG's PredictionPropagation phase
https://bugs.webkit.org/show_bug.cgi?id=141363
Reviewed by Darin Adler.
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
Some blocks were duplicated, they probably evolved separately
to the same state.
2015-02-08 Benjamin Poulain <benjamin@webkit.org>
Remove useless declarations and a stale comment from DFGByteCodeParser.h
https://bugs.webkit.org/show_bug.cgi?id=141361
Reviewed by Darin Adler.
The comment refers to the original form of the ByteCodeParser:
parse(Graph&, JSGlobalData*, CodeBlock*, unsigned startIndex);
That form is long dead, the comment is more misleading than anything.
* dfg/DFGByteCodeParser.cpp:
* dfg/DFGByteCodeParser.h:
2015-02-08 Benjamin Poulain <benjamin@webkit.org>
Encapsulate DFG::Plan's beforeFTL timestamp
https://bugs.webkit.org/show_bug.cgi?id=141360
Reviewed by Darin Adler.
Make the attribute private, it is an internal state.
Rename beforeFTL->timeBeforeFTL for readability.
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThread):
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGPlan.h:
2015-02-08 Benjamin Poulain <bpoulain@apple.com>
Remove DFGNode::hasArithNodeFlags()
https://bugs.webkit.org/show_bug.cgi?id=141319
Reviewed by Michael Saboff.
* dfg/DFGNode.h:
(JSC::DFG::Node::hasArithNodeFlags): Deleted.
Unused code is unused.
2015-02-07 Chris Dumez <cdumez@apple.com>
Add Vector::removeFirstMatching() / removeAllMatching() methods taking lambda functions
https://bugs.webkit.org/show_bug.cgi?id=141321
Reviewed by Darin Adler.
Use new Vector::removeFirstMatching() / removeAllMatching() methods.
2015-02-06 Filip Pizlo <fpizlo@apple.com>
DFG SSA shouldn't have SetArgument nodes
https://bugs.webkit.org/show_bug.cgi?id=141342
Reviewed by Mark Lam.
I was wondering why we kept the SetArgument around for captured
variables. It turns out we did so because we thought we had to, even
though we didn't have to. The node is meaningless in SSA.
* dfg/DFGSSAConversionPhase.cpp:
(JSC::DFG::SSAConversionPhase::run):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
2015-02-06 Filip Pizlo <fpizlo@apple.com>
It should be possible to use the DFG SetArgument node to indicate that someone set the value of a local out-of-band
https://bugs.webkit.org/show_bug.cgi?id=141337
Reviewed by Mark Lam.
This mainly involved ensuring that SetArgument behaves just like SetLocal from a CPS standpoint, but with a special case for those SetArguments that
are associated with the prologue.
* dfg/DFGCPSRethreadingPhase.cpp:
(JSC::DFG::CPSRethreadingPhase::run):
(JSC::DFG::CPSRethreadingPhase::canonicalizeSet):
(JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
(JSC::DFG::CPSRethreadingPhase::specialCaseArguments):
(JSC::DFG::CPSRethreadingPhase::canonicalizeSetLocal): Deleted.
(JSC::DFG::CPSRethreadingPhase::canonicalizeSetArgument): Deleted.
2015-02-06 Mark Lam <mark.lam@apple.com>
MachineThreads should be ref counted.
<https://webkit.org/b/141317>
Reviewed by Filip Pizlo.
The VM's MachineThreads registry object is being referenced from other
threads as a raw pointer. In a scenario where the VM is destructed on
the main thread, there is no guarantee that another thread isn't still
holding a reference to the registry and will eventually invoke
removeThread() on it on thread exit. Hence, there's a possible use
after free scenario here.
The fix is to make MachineThreads ThreadSafeRefCounted, and have all
threads that references keep a RefPtr to it to ensure that it stays
alive until the very last thread is done with it.
* API/tests/testapi.mm:
(useVMFromOtherThread): - Renamed to be more descriptive.
(useVMFromOtherThreadAndOutliveVM):
- Added a test that has another thread which uses the VM outlive the
VM to confirm that there is no crash.
However, I was not actually able to get the VM to crash without this
patch because I wasn't always able to the thread destructor to be
called. With this patch applied, I did verify with some logging that
the MachineThreads registry is only destructed after all threads
have removed themselves from it.
(threadMain): Deleted.
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::~Heap):
(JSC::Heap::gatherStackRoots):
* heap/Heap.h:
(JSC::Heap::machineThreads):
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::Thread::Thread):
(JSC::MachineThreads::addCurrentThread):
(JSC::MachineThreads::removeCurrentThread):
* heap/MachineStackMarker.h:
2015-02-06 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r179743.
https://bugs.webkit.org/show_bug.cgi?id=141335
caused missing symbols in non-WebKit clients of WTF::Vector
(Requested by kling on #webkit).
Reverted changeset:
"Remove WTF::fastMallocGoodSize()."
https://bugs.webkit.org/show_bug.cgi?id=141020
http://trac.webkit.org/changeset/179743
2015-02-04 Filip Pizlo <fpizlo@apple.com>
Remove BytecodeGenerator::preserveLastVar() and replace it with a more robust mechanism for preserving non-temporary registers
https://bugs.webkit.org/show_bug.cgi?id=141211
Reviewed by Mark Lam.
Previously, the way non-temporary registers were preserved (i.e. not reclaimed anytime
we did newTemporary()) by calling preserveLastVar() after all non-temps are created. It
would raise the refcount on the last (highest-numbered) variable created, and rely on
the fact that register reclamation started at higher-numbered registers and worked its
way down. So any retained register would block any lower-numbered registers from being
reclaimed.
Also, preserveLastVar() sets a thing called m_firstConstantIndex. It's unused.
This removes preserveLastVar() and makes addVar() retain each register it creates. This
is more explicit, since addVar() is the mechanism for creating non-temporary registers.
To make this work I had to remove an assertion that Register::setIndex() can only be
called when the refcount is zero. This method might be called after a var is created to
change its index. This previously worked because preserveLastVar() would be called after
we had already made all index changes, so the vars would still have refcount zero. Now
they have refcount 1. I think it's OK to lose this assertion; I can't remember this
assertion ever firing in a way that alerted me to a serious issue.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::preserveLastVar): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::addVar):
* bytecompiler/RegisterID.h:
(JSC::RegisterID::setIndex):
2015-02-06 Andreas Kling <akling@apple.com>
Remove WTF::fastMallocGoodSize().
<https://webkit.org/b/141020>
Reviewed by Anders Carlsson.
* assembler/AssemblerBuffer.h:
(JSC::AssemblerData::AssemblerData):
(JSC::AssemblerData::grow):
2015-02-05 Michael Saboff <msaboff@apple.com>
CodeCache is not thread safe when adding the same source from two different threads
https://bugs.webkit.org/show_bug.cgi?id=141275
Reviewed by Mark Lam.
The issue for this bug is that one thread, takes a cache miss in CodeCache::getGlobalCodeBlock,
but in the process creates a cache entry with a nullptr UnlinkedCodeBlockType* which it
will fill in later in the function. During the body of that function, it allocates
objects that may garbage collect. During that garbage collection, we drop the all locks.
While the locks are released by the first thread, another thread can enter the VM and might
have exactly the same source and enter CodeCache::getGlobalCodeBlock() itself. When it
looks up the code block, it sees it as a cache it and uses the nullptr UnlinkedCodeBlockType*
and crashes. This fixes the problem by not dropping the locks during garbage collection.
There are other likely scenarios where we have a data structure like this code cache in an
unsafe state for arbitrary reentrance.
Moved the functionality of DelayedReleaseScope directly into Heap. Changed it into
a simple list that is cleared with the new function Heap::releaseDelayedReleasedObjects.
Now we accumulate objects to be released and release them when all locks are dropped or
when destroying the Heap. This eliminated the dropping and reaquiring of locks associated
with the old scope form of this list.
Given that all functionality of DelayedReleaseScope is now used and referenced by Heap
and the lock management no longer needs to be done, just made the list a member of Heap.
We do need to guard against the case that releasing an object can create more objects
by calling into JS. That is why releaseDelayedReleasedObjects() is written to remove
an object to release so that we aren't recursively in Vector code. The other thing we
do in releaseDelayedReleasedObjects() is to guard against recursive calls to itself using
the m_delayedReleaseRecursionCount. We only release at the first entry into the function.
This case is already tested by testapi.mm.
* heap/DelayedReleaseScope.h: Removed file
* API/JSAPIWrapperObject.mm:
* API/ObjCCallbackFunction.mm:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::doSweep):
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::tryAllocateHelper):
(JSC::MarkedAllocator::tryAllocate):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::sweep):
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::MarkedSpace):
(JSC::MarkedSpace::lastChanceToFinalize):
(JSC::MarkedSpace::didFinishIterating):
* heap/MarkedSpace.h:
* heap/Heap.cpp:
(JSC::Heap::collectAllGarbage):
(JSC::Heap::zombifyDeadObjects):
Removed references to DelayedReleaseScope and DelayedReleaseScope.h.
* heap/Heap.cpp:
(JSC::Heap::Heap): Initialized m_delayedReleaseRecursionCount.
(JSC::Heap::lastChanceToFinalize): Call releaseDelayedObjectsNow() as the VM is going away.
(JSC::Heap::releaseDelayedReleasedObjects): New function that released the accumulated
delayed release objects.
* heap/Heap.h:
(JSC::Heap::m_delayedReleaseObjects): List of objects to be released later.
(JSC::Heap::m_delayedReleaseRecursionCount): Counter to indicate that
releaseDelayedReleasedObjects is being called recursively.
* heap/HeapInlines.h:
(JSC::Heap::releaseSoon): Changed location of list to add delayed release objects.
* runtime/JSLock.cpp:
(JSC::JSLock::willReleaseLock):
Call Heap::releaseDelayedObjectsNow() when releasing the lock.
2015-02-05 Youenn Fablet <youenn.fablet@crf.canon.fr> and Xabier Rodriguez Calvar <calvaris@igalia.com>
[Streams API] Implement a barebone ReadableStream interface
https://bugs.webkit.org/show_bug.cgi?id=141045
Reviewed by Benjamin Poulain.
* Configurations/FeatureDefines.xcconfig:
2015-02-05 Saam Barati <saambarati1@gmail.com>
Crash in uninitialized deconstructing variable.
https://bugs.webkit.org/show_bug.cgi?id=141070
Reviewed by Michael Saboff.
According to the ES6 spec, when a destructuring pattern occurs
as the left hand side of an assignment inside a var declaration
statement, the assignment must also have a right hand side value.
"var {x} = {};" is a legal syntactic statement, but,
"var {x};" is a syntactic error.
Section 13.2.2 of the latest draft ES6 spec specifies this requirement:
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-variable-statement
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseVarDeclaration):
(JSC::Parser<LexerType>::parseVarDeclarationList):
(JSC::Parser<LexerType>::parseForStatement):
* parser/Parser.h:
2015-02-04 Gyuyoung Kim <gyuyoung.kim@samsung.com>
Unreviewed, fix a build break on EFL port since r179648.
* heap/MachineStackMarker.cpp: EFL port doesn't use previousThread variable.
(JSC::MachineThreads::tryCopyOtherThreadStacks):
2015-02-04 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: ES6: Improved Console Support for Symbol Objects
https://bugs.webkit.org/show_bug.cgi?id=141173
Reviewed by Timothy Hatcher.
* inspector/protocol/Runtime.json:
New type, "symbol".
* inspector/InjectedScriptSource.js:
Handle Symbol objects in a few places. They don't have properties
and they cannot be implicitly converted to strings.
2015-02-04 Mark Lam <mark.lam@apple.com>
Undo gardening: Restoring the expected ERROR message since that is not the cause of the bot unhappiness.
Not reviewed.
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::tryCopyOtherThreadStacks):
2015-02-04 Mark Lam <mark.lam@apple.com>
Gardening: Changed expected ERROR message to WARNING to make test bots happy.
Rubber stamped by Simon Fraser.
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::tryCopyOtherThreadStacks):
2015-02-04 Mark Lam <mark.lam@apple.com>
r179576 introduce a deadlock potential during GC thread suspension.
<https://webkit.org/b/141268>
Reviewed by Michael Saboff.
http://trac.webkit.org/r179576 introduced a potential for deadlocking.
In the GC thread suspension loop, we currently delete
MachineThreads::Thread that we detect to be invalid. This is unsafe
because we may have already suspended some threads, and one of those
suspended threads may still be holding the C heap lock which we need
for deleting the invalid thread.
The fix is to put the invalid threads in a separate toBeDeleted list,
and delete them only after GC has resumed all threads.
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::removeCurrentThread):
- Undo refactoring removeThreadWithLockAlreadyAcquired() out of
removeCurrentThread() since it is no longer needed.
(JSC::MachineThreads::tryCopyOtherThreadStacks):
- Put invalid Threads on a threadsToBeDeleted list, and delete those
Threads only after all threads have been resumed.
(JSC::MachineThreads::removeThreadWithLockAlreadyAcquired): Deleted.
* heap/MachineStackMarker.h:
2015-02-04 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Clean up Object Property Descriptor Collection
https://bugs.webkit.org/show_bug.cgi?id=141222
Reviewed by Timothy Hatcher.
* inspector/InjectedScriptSource.js:
Use a list of options when determining which properties to collect
instead of a few booleans with overlapping responsibilities.
2015-02-04 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: console.table with columnName filter for non-existent property should still show column
https://bugs.webkit.org/show_bug.cgi?id=141066
Reviewed by Timothy Hatcher.
* inspector/ConsoleMessage.cpp:
(Inspector::ConsoleMessage::addToFrontend):
When a user provides a second argument, e.g. console.table(..., columnNames),
then pass that second argument to the frontend.
* inspector/InjectedScriptSource.js:
Add a FIXME about the old, unused path now.
2015-02-04 Saam Barati <saambarati1@gmail.com>
TypeSet can use 1 byte instead of 4 bytes for its m_seenTypes member variable
https://bugs.webkit.org/show_bug.cgi?id=141204
Reviewed by Darin Adler.
There is no need to use 32 bits to store a TypeSet::RuntimeType set
bit-vector when the largest value for a single TypeSet::RuntimeType
is 0x80. 8 bits is enough to represent the set of seen types.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* runtime/TypeSet.cpp:
(JSC::TypeSet::doesTypeConformTo):
* runtime/TypeSet.h:
(JSC::TypeSet::seenTypes):
2015-02-04 Mark Lam <mark.lam@apple.com>
Remove concept of makeUsableFromMultipleThreads().
<https://webkit.org/b/141221>
Reviewed by Mark Hahnenberg.
Currently, we rely on VM::makeUsableFromMultipleThreads() being called before we
start acquiring the JSLock and entering the VM from different threads.
Acquisition of the JSLock will register the acquiring thread with the VM's thread
registry if not already registered. However, it will only do this if the VM's
thread specific key has been initialized by makeUsableFromMultipleThreads().
This is fragile, and also does not read intuitively because one would expect to
acquire the JSLock before calling any methods on the VM. This is exactly what
JSGlobalContextCreateInGroup() did (i.e. acquire the lock before calling
makeUsableFromMultipleThreads()), but is wrong. The result is that the invoking
thread will not have been registered with the VM during that first entry into
the VM.
The fix is to make it so that we initialize the VM's thread specific key on
construction of the VM's MachineThreads registry instead of relying on
makeUsableFromMultipleThreads() being called. With this, we can eliminate
makeUsableFromMultipleThreads() altogether.
Performance results are neutral in aggregate.
* API/JSContextRef.cpp:
(JSGlobalContextCreateInGroup):
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::MachineThreads):
(JSC::MachineThreads::~MachineThreads):
(JSC::MachineThreads::addCurrentThread):
(JSC::MachineThreads::removeThread):
(JSC::MachineThreads::gatherConservativeRoots):
(JSC::MachineThreads::makeUsableFromMultipleThreads): Deleted.
* heap/MachineStackMarker.h:
* runtime/VM.cpp:
(JSC::VM::sharedInstance):
* runtime/VM.h:
(JSC::VM::makeUsableFromMultipleThreads): Deleted.
2015-02-04 Chris Dumez <cdumez@apple.com>
Add removeFirst(value) / removeAll(value) methods to WTF::Vector
https://bugs.webkit.org/show_bug.cgi?id=141192
Reviewed by Benjamin Poulain.
Use new Vector::removeFirst(value) / removeAll(value) API to simplify the
code a bit.
* inspector/InspectorValues.cpp:
(Inspector::InspectorObjectBase::remove):
2015-02-03 Mark Lam <mark.lam@apple.com>
Workaround a thread library bug where thread destructors may not get called.
<https://webkit.org/b/141209>
Reviewed by Michael Saboff.
There's a bug where thread destructors may not get called. As far as
we know, this only manifests on darwin ports. We will work around this
by checking at GC time if the platform thread is still valid. If not,
we'll purge it from the VM's registeredThreads list before proceeding
with thread scanning activity.
Note: it is important that we do this invalid thread detection during
suspension, because the validity (and liveness) of the other thread is
only guaranteed while it is suspended.
* API/tests/testapi.mm:
(threadMain):
- Added a test to enter the VM from another thread before we GC on
the main thread.
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::removeThreadWithLockAlreadyAcquired):
(JSC::MachineThreads::removeCurrentThread):
- refactored removeThreadWithLockAlreadyAcquired() out from
removeCurrentThread() so that we can also call it for purging invalid
threads.
(JSC::suspendThread):
- Added a return status to tell if the suspension succeeded or not.
(JSC::MachineThreads::tryCopyOtherThreadStacks):
- Check if the suspension failed, and purge the thread if we can't
suspend it. Failure to suspend implies that the thread has
terminated without calling its destructor.
* heap/MachineStackMarker.h:
2015-02-03 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: ASSERT mainThreadPthread launching remote debuggable JSContext app with Debug JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=141189
Reviewed by Michael Saboff.
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::singleton):
Ensure we call WTF::initializeMainThread() on the main thread so that
we can perform automatic String <-> NSString conversions.
2015-02-03 Brent Fulgham <bfulgham@apple.com>
[Win] Project file cleanups after r179429.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2015-02-02 Filip Pizlo <fpizlo@apple.com>
arguments[-1] should have well-defined behavior
https://bugs.webkit.org/show_bug.cgi?id=141183
Reviewed by Mark Lam.
According to JSC's internal argument numbering, 0 is "this" and 1 is the first argument.
In the "arguments[i]" expression, "this" is not accessible and i = 0 refers to the first
argument. Previously we handled the bounds check in "arguments[i]" - where "arguments" is
statically known to be the current function's arguments object - as follows:
add 1, i
branchAboveOrEqual i, callFrame.ArgumentCount, slowPath
The problem with this is that if i = -1, this passes the test, and we end up accessing
what would be the "this" argument slot. That's wrong, since we should really be bottoming
out in arguments["-1"], which is usually undefined but could be anything. It's even worse
if the function is inlined or if we're in a constructor - in that case the "this" slot
could be garbage.
It turns out that we had this bug in all of our engines.
This fixes the issue by changing the algorithm to:
load32 callFrame.ArgumentCount, tmp
sub 1, tmp
branchAboveOrEqual i, tmp, slowPath
In some engines, we would have used the modified "i" (the one that had 1 added to it) for
the subsequent argument load; since we don't do this anymore I also had to change some of
the offsets on the BaseIndex arguments load.
This also includes tests that are written in such a way as to get coverage on LLInt and
Baseline JIT (get-my-argument-by-val-wrap-around-no-warm-up), DFG and FTL
(get-my-argument-by-val-wrap-around), and DFG when we're being paranoid about the user
overwriting the "arguments" variable (get-my-argument-by-val-safe-wrap-around). This also
includes off-by-1 out-of-bounds tests for each of these cases, since in the process of
writing the patch I broke the arguments[arguments.length] case in the DFG and didn't see
any test failures.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentByVal):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::offsetOfArguments):
(JSC::AssemblyHelpers::offsetOfArgumentsIncludingThis): Deleted.
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_get_argument_by_val):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_get_argument_by_val):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* tests/stress/get-my-argument-by-val-out-of-bounds-no-warm-up.js: Added.
(foo):
* tests/stress/get-my-argument-by-val-out-of-bounds.js: Added.
(foo):
* tests/stress/get-my-argument-by-val-safe-out-of-bounds.js: Added.
(foo):
* tests/stress/get-my-argument-by-val-safe-wrap-around.js: Added.
(foo):
* tests/stress/get-my-argument-by-val-wrap-around-no-warm-up.js: Added.
(foo):
* tests/stress/get-my-argument-by-val-wrap-around.js: Added.
(foo):
2015-02-02 Filip Pizlo <fpizlo@apple.com>
MultiGetByOffset should be marked NodeMustGenerate
https://bugs.webkit.org/show_bug.cgi?id=140137
Reviewed by Michael Saboff.
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToGetByOffset): We were sloppy - we should also clear NodeMustGenerate once it's a GetByOffset.
(JSC::DFG::Node::convertToMultiGetByOffset): Assert that we converted from something that already had NodeMustGenerate.
* dfg/DFGNodeType.h: We shouldn't DCE a node that does checks and could be effectful in baseline. Making MultiGetByOffset as NodeMustGenerate prevents DCE. FTL could still DCE the actual loads, but the checks will stay.
* tests/stress/multi-get-by-offset-dce.js: Added. This previously failed because the getter wasn't called.
(foo):
2015-02-02 Filip Pizlo <fpizlo@apple.com>
[FTL] inlined GetMyArgumentByVal with no arguments passed causes instant crash
https://bugs.webkit.org/show_bug.cgi?id=141180
rdar://problem/19677552
Reviewed by Benjamin Poulain.
If we do a GetMyArgumentByVal on an inlined call frame that has no arguments, then the
bounds check already terminates execution. This means we can skip the part where we
previously did an out-of-bound array access on the inlined call frame arguments vector.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::safelyInvalidateAfterTermination):
(JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentByVal):
(JSC::FTL::LowerDFGToLLVM::terminate):
(JSC::FTL::LowerDFGToLLVM::didAlreadyTerminate):
(JSC::FTL::LowerDFGToLLVM::crash):
* tests/stress/get-my-argument-by-val-inlined-no-formal-parameters.js: Added.
(foo):
(bar):
2015-02-02 Filip Pizlo <fpizlo@apple.com>
REGRESSION(r179477): arguments simplification no longer works
https://bugs.webkit.org/show_bug.cgi?id=141169
Reviewed by Mark Lam.
The operations involved in callee/scope access don't exit and shouldn't get in the way
of strength-reducing a Flush to a PhantomLocal. Then the PhantomLocal shouldn't get in
the way of further such strength-reduction. We also need to canonicalize PhantomLocal
before running arguments simplification.
* dfg/DFGMayExit.cpp:
(JSC::DFG::mayExit):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
2015-02-02 Filip Pizlo <fpizlo@apple.com>
VirtualRegister should really know how to dump itself
https://bugs.webkit.org/show_bug.cgi?id=141171
Reviewed by Geoffrey Garen.
Gives VirtualRegister a dump() method that pretty-prints the virtual register. The rest of
the patch is all about using this new power.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::constantName):
(JSC::CodeBlock::registerName):
* bytecode/CodeBlock.h:
(JSC::missingThisObjectMarker): Deleted.
* bytecode/VirtualRegister.cpp: Added.
(JSC::VirtualRegister::dump):
* bytecode/VirtualRegister.h:
(WTF::printInternal): Deleted.
* dfg/DFGArgumentPosition.h:
(JSC::DFG::ArgumentPosition::dump):
* dfg/DFGFlushedAt.cpp:
(JSC::DFG::FlushedAt::dump):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
* dfg/DFGPutLocalSinkingPhase.cpp:
* dfg/DFGSSAConversionPhase.cpp:
(JSC::DFG::SSAConversionPhase::run):
* dfg/DFGValidate.cpp:
(JSC::DFG::Validate::reportValidationContext):
* dfg/DFGValueSource.cpp:
(JSC::DFG::ValueSource::dump):
* dfg/DFGVariableEvent.cpp:
(JSC::DFG::VariableEvent::dump):
(JSC::DFG::VariableEvent::dumpSpillInfo):
* ftl/FTLExitArgumentForOperand.cpp:
(JSC::FTL::ExitArgumentForOperand::dump):
* ftl/FTLExitValue.cpp:
(JSC::FTL::ExitValue::dumpInContext):
* profiler/ProfilerBytecodeSequence.cpp:
(JSC::Profiler::BytecodeSequence::BytecodeSequence):
2015-02-02 Geoffrey Garen <ggaren@apple.com>
Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
https://bugs.webkit.org/show_bug.cgi?id=140900
Reviewed by Mark Hahnenberg.
Re-landing just the HandleBlock piece of this patch.
* heap/HandleBlock.h:
* heap/HandleBlockInlines.h:
(JSC::HandleBlock::create):
(JSC::HandleBlock::destroy):
(JSC::HandleBlock::HandleBlock):
(JSC::HandleBlock::payloadEnd):
* heap/HandleSet.cpp:
(JSC::HandleSet::~HandleSet):
(JSC::HandleSet::grow):
2015-02-02 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Support console.table
https://bugs.webkit.org/show_bug.cgi?id=141058
Reviewed by Timothy Hatcher.
* inspector/InjectedScriptSource.js:
Include the firstLevelKeys filter when generating previews.
* runtime/ConsoleClient.cpp:
(JSC::appendMessagePrefix):
Differentiate console.table logs to system log.
2015-01-31 Filip Pizlo <fpizlo@apple.com>
BinarySwitch should be faster on average
https://bugs.webkit.org/show_bug.cgi?id=141046
Reviewed by Anders Carlsson.
This optimizes our binary switch using math. It's strictly better than what we had before
assuming we bottom out in some case (rather than fall through), assuming all cases get
hit with equal probability. The difference is particularly large for large switch
statements. For example, a switch statement with 1000 cases would previously require on
average 13.207 branches to get to some case, while now it just requires 10.464.
This is also a progression for the fall-through case, though we could shave off another
1/6 branch on average if we wanted to - though it would regress taking a case (not falling
through) by 1/6 branch. I believe it's better to bias the BinarySwitch for not falling
through.
This also adds some randomness to the algorithm to minimize the likelihood of us
generating a switch statement that is always particularly bad for some input. Note that
the randomness has no effect on average-case performance assuming all cases are equally
likely.
This ought to have no actual performance change because we don't rely on binary switches
that much. The main reason why this change is interesting is that I'm finding myself
increasingly relying on BinarySwitch, and I'd like to know that it's optimal.
* jit/BinarySwitch.cpp:
(JSC::BinarySwitch::BinarySwitch):
(JSC::BinarySwitch::~BinarySwitch):
(JSC::BinarySwitch::build):
* jit/BinarySwitch.h:
2015-02-02 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Extend CSS.getSupportedCSSProperties to provide values for properties for CSS Augmented JSContext
https://bugs.webkit.org/show_bug.cgi?id=141064
Reviewed by Timothy Hatcher.
* inspector/protocol/CSS.json:
2015-02-02 Daniel Bates <dabates@apple.com>
[iOS] ASSERTION FAILED: m_scriptExecutionContext->isContextThread() in ContextDestructionObserver::observeContext
https://bugs.webkit.org/show_bug.cgi?id=141057
<rdar://problem/19068790>
Reviewed by Alexey Proskuryakov.
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::receivedIndicateMessage): Modified to call WTF::callOnWebThreadOrDispatchAsyncOnMainThread().
(Inspector::dispatchAsyncOnQueueSafeForAnyDebuggable): Deleted; moved logic to common helper function,
WTF::callOnWebThreadOrDispatchAsyncOnMainThread() so that it can be called from both RemoteInspector::receivedIndicateMessage()
and CryptoKeyRSA::generatePair().
2015-02-02 Saam Barati <saambarati1@gmail.com>
Create tests for JSC's Control Flow Profiler
https://bugs.webkit.org/show_bug.cgi?id=141123
Reviewed by Filip Pizlo.
This patch creates a control flow profiler testing API in jsc.cpp
that accepts a function and a string as arguments. The string must
be a substring of the text of the function argument. The API returns
a boolean indicating whether or not the basic block that encloses the
substring has executed.
This patch uses this API to test that the control flow profiler
behaves as expected on basic block boundaries. These tests do not
provide full coverage for all JavaScript statements that can create
basic blocks boundaries. Full coverage will come in a later patch.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionHasBasicBlockExecuted):
* runtime/ControlFlowProfiler.cpp:
(JSC::ControlFlowProfiler::hasBasicBlockAtTextOffsetBeenExecuted):
* runtime/ControlFlowProfiler.h:
* tests/controlFlowProfiler: Added.
* tests/controlFlowProfiler.yaml: Added.
* tests/controlFlowProfiler/driver: Added.
* tests/controlFlowProfiler/driver/driver.js: Added.
(assert):
* tests/controlFlowProfiler/if-statement.js: Added.
(testIf):
(noMatches):
* tests/controlFlowProfiler/loop-statements.js: Added.
(forRegular):
(forIn):
(forOf):
(whileLoop):
* tests/controlFlowProfiler/switch-statements.js: Added.
(testSwitch):
* tests/controlFlowProfiler/test-jit.js: Added.
(tierUpToBaseline):
(tierUpToDFG):
(baselineTest):
(dfgTest):
2015-01-28 Filip Pizlo <fpizlo@apple.com>
Polymorphic call inlining should be based on polymorphic call inline caching rather than logging
https://bugs.webkit.org/show_bug.cgi?id=140660
Reviewed by Geoffrey Garen.
When we first implemented polymorphic call inlining, we did the profiling based on a call
edge log. The idea was to store each call edge (a tuple of call site and callee) into a
global log that was processed lazily. Processing the log would give precise counts of call
edges, and could be used to drive well-informed inlining decisions - polymorphic or not.
This was a speed-up on throughput tests but a slow-down for latency tests. It was a net win
nonetheless.
Experience with this code shows three things. First, the call edge profiler is buggy and
complex. It would take work to fix the bugs. Second, the call edge profiler incurs lots of
overhead for latency code that we care deeply about. Third, it's not at all clear that
having call edge counts for every possible callee is any better than just having call edge
counts for the limited number of callees that an inline cache would catch.
So, this patch removes the call edge profiler and replaces it with a polymorphic call inline
cache. If we miss the basic call inline cache, we inflate the cache to be a jump to an
out-of-line stub that cases on the previously known callees. If that misses again, then we
rewrite that stub to include the new callee. We do this up to some number of callees. If we
hit the limit then we switch to using a plain virtual call.
Substantial speed-up on V8Spider; undoes the slow-down that the original call edge profiler
caused. Might be a SunSpider speed-up (below 1%), depending on hardware.
Rolling this back in after fixing https://bugs.webkit.org/show_bug.cgi?id=141107.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CallEdge.h:
(JSC::CallEdge::count):
(JSC::CallEdge::CallEdge):
* bytecode/CallEdgeProfile.cpp: Removed.
* bytecode/CallEdgeProfile.h: Removed.
* bytecode/CallEdgeProfileInlines.h: Removed.
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::unlink):
(JSC::CallLinkInfo::visitWeak):
* bytecode/CallLinkInfo.h:
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::CallLinkStatus):
(JSC::CallLinkStatus::computeFor):
(JSC::CallLinkStatus::computeFromCallLinkInfo):
(JSC::CallLinkStatus::isClosureCall):
(JSC::CallLinkStatus::makeClosureCall):
(JSC::CallLinkStatus::dump):
(JSC::CallLinkStatus::computeFromCallEdgeProfile): Deleted.
* bytecode/CallLinkStatus.h:
(JSC::CallLinkStatus::CallLinkStatus):
(JSC::CallLinkStatus::isSet):
(JSC::CallLinkStatus::variants):
(JSC::CallLinkStatus::size):
(JSC::CallLinkStatus::at):
(JSC::CallLinkStatus::operator[]):
(JSC::CallLinkStatus::canOptimize):
(JSC::CallLinkStatus::edges): Deleted.
(JSC::CallLinkStatus::canTrustCounts): Deleted.
* bytecode/CallVariant.cpp:
(JSC::variantListWithVariant):
(JSC::despecifiedVariantList):
* bytecode/CallVariant.h:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::~CodeBlock):
(JSC::CodeBlock::linkIncomingPolymorphicCall):
(JSC::CodeBlock::unlinkIncomingCalls):
(JSC::CodeBlock::noticeIncomingCall):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::isIncomingCallAlreadyLinked): Deleted.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
(JSC::DFG::ByteCodeParser::handleCall):
(JSC::DFG::ByteCodeParser::handleInlining):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGDriver.cpp:
(JSC::DFG::compileImpl):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasHeapPrediction):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGTierUpCheckInjectionPhase.cpp:
(JSC::DFG::TierUpCheckInjectionPhase::run):
(JSC::DFG::TierUpCheckInjectionPhase::removeFTLProfiling): Deleted.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* heap/Heap.cpp:
(JSC::Heap::collect):
* jit/BinarySwitch.h:
* jit/ClosureCallStubRoutine.cpp: Removed.
* jit/ClosureCallStubRoutine.h: Removed.
* jit/JITCall.cpp:
(JSC::JIT::compileOpCall):
* jit/JITCall32_64.cpp:
(JSC::JIT::compileOpCall):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
(JSC::operationLinkPolymorphicCallFor):
(JSC::operationLinkClosureCallFor): Deleted.
* jit/JITStubRoutine.h:
* jit/JITWriteBarrier.h:
* jit/PolymorphicCallStubRoutine.cpp: Added.
(JSC::PolymorphicCallNode::~PolymorphicCallNode):
(JSC::PolymorphicCallNode::unlink):
(JSC::PolymorphicCallCase::dump):
(JSC::PolymorphicCallStubRoutine::PolymorphicCallStubRoutine):
(JSC::PolymorphicCallStubRoutine::~PolymorphicCallStubRoutine):
(JSC::PolymorphicCallStubRoutine::variants):
(JSC::PolymorphicCallStubRoutine::edges):
(JSC::PolymorphicCallStubRoutine::visitWeak):
(JSC::PolymorphicCallStubRoutine::markRequiredObjectsInternal):
* jit/PolymorphicCallStubRoutine.h: Added.
(JSC::PolymorphicCallNode::PolymorphicCallNode):
(JSC::PolymorphicCallCase::PolymorphicCallCase):
(JSC::PolymorphicCallCase::variant):
(JSC::PolymorphicCallCase::codeBlock):
* jit/Repatch.cpp:
(JSC::linkSlowFor):
(JSC::linkFor):
(JSC::revertCall):
(JSC::unlinkFor):
(JSC::linkVirtualFor):
(JSC::linkPolymorphicCall):
(JSC::linkClosureCall): Deleted.
* jit/Repatch.h:
* jit/ThunkGenerators.cpp:
(JSC::linkPolymorphicCallForThunkGenerator):
(JSC::linkPolymorphicCallThunkGenerator):
(JSC::linkPolymorphicCallThatPreservesRegsThunkGenerator):
(JSC::linkClosureCallForThunkGenerator): Deleted.
(JSC::linkClosureCallThunkGenerator): Deleted.
(JSC::linkClosureCallThatPreservesRegsThunkGenerator): Deleted.
* jit/ThunkGenerators.h:
(JSC::linkPolymorphicCallThunkGeneratorFor):
(JSC::linkClosureCallThunkGeneratorFor): Deleted.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::jitCompileAndSetHeuristics):
* runtime/Options.h:
* runtime/VM.cpp:
(JSC::VM::prepareToDiscardCode):
(JSC::VM::ensureCallEdgeLog): Deleted.
* runtime/VM.h:
2015-01-30 Filip Pizlo <fpizlo@apple.com>
Converting Flushes and PhantomLocals to Phantoms requires an OSR availability analysis rather than just using the SetLocal's child
https://bugs.webkit.org/show_bug.cgi?id=141107
Reviewed by Michael Saboff.
See the bugzilla for a discussion of the problem. This addresses the problem by ensuring
that Flushes are always strength-reduced to PhantomLocals, and CPS rethreading does a mini
OSR availability analysis to determine the right MovHint value to use for the Phantom.
* dfg/DFGCPSRethreadingPhase.cpp:
(JSC::DFG::CPSRethreadingPhase::CPSRethreadingPhase):
(JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
(JSC::DFG::CPSRethreadingPhase::clearVariables):
(JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
(JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
(JSC::DFG::CPSRethreadingPhase::clearVariablesAtHeadAndTail): Deleted.
* dfg/DFGNode.h:
(JSC::DFG::Node::convertPhantomToPhantomLocal):
(JSC::DFG::Node::convertFlushToPhantomLocal):
(JSC::DFG::Node::convertToPhantomLocal): Deleted.
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* tests/stress/inline-call-that-doesnt-use-all-args.js: Added.
(foo):
(bar):
(baz):
2015-01-31 Michael Saboff <msaboff@apple.com>
Crash (DFG assertion) beneath AbstractInterpreter::verifyEdge() @ http://experilous.com/1/planet-generator/2014-09-28/version-1
https://bugs.webkit.org/show_bug.cgi?id=141111
Reviewed by Filip Pizlo.
In LowerDFGToLLVM::compileNode(), if we determine while compiling a node that we would have
exited, we don't need to process the OSR availability or abstract interpreter.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::safelyInvalidateAfterTermination): Broke this out a a separate
method since we need to call it at the top and near the bottom of compileNode().
(JSC::FTL::LowerDFGToLLVM::compileNode):
2015-01-31 Sam Weinig <sam@webkit.org>
Remove even more Mountain Lion support
https://bugs.webkit.org/show_bug.cgi?id=141124
Reviewed by Alexey Proskuryakov.
* API/tests/DateTests.mm:
* Configurations/Base.xcconfig:
* Configurations/DebugRelease.xcconfig:
* Configurations/FeatureDefines.xcconfig:
* Configurations/Version.xcconfig:
* jit/ExecutableAllocatorFixedVMPool.cpp:
2015-01-31 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r179426.
https://bugs.webkit.org/show_bug.cgi?id=141119
"caused a memory use regression" (Requested by Guest45 on
#webkit).
Reverted changeset:
"Use FastMalloc (bmalloc) instead of BlockAllocator for GC
pages"
https://bugs.webkit.org/show_bug.cgi?id=140900
http://trac.webkit.org/changeset/179426
2015-01-30 Daniel Bates <dabates@apple.com>
Clean up: Remove unnecessary <dispatch/dispatch.h> header from RemoteInspectorDebuggableConnection.h
https://bugs.webkit.org/show_bug.cgi?id=141067
Reviewed by Timothy Hatcher.
Remove the header <dispatch/dispatch.h> from RemoteInspectorDebuggableConnection.h as we
do not make use of its functionality. Instead, include this header in RemoteInspectorDebuggableConnection.mm
and RemoteInspector.mm. The latter depended on <dispatch/dispatch.h> being included via
header RemoteInspectorDebuggableConnection.h.
* inspector/remote/RemoteInspector.mm: Include header <dispatch/dispatch.h>.
* inspector/remote/RemoteInspectorDebuggableConnection.h: Remove header <dispatch/dispatch.h>.
* inspector/remote/RemoteInspectorDebuggableConnection.mm: Include header <dispatch/dispatch.h>.
2015-01-30 Yusuke Suzuki <utatane.tea@gmail.com>
Implement ES6 Symbol
https://bugs.webkit.org/show_bug.cgi?id=140435
Reviewed by Geoffrey Garen.
This patch implements ES6 Symbol. In this patch, we don't support
Symbol.keyFor, Symbol.for, Object.getOwnPropertySymbols. They will be
supported in the subsequent patches.
Since ES6 Symbol is introduced as new primitive value, we implement
Symbol as a derived class from JSCell. And now JSValue accepts Symbol*
as a new primitive value.
Symbol has a *unique* flagged StringImpl* as an `uid`. Which pointer
value represents the Symbol's identity. So don't compare Symbol's
JSCell pointer value for comparison.
This enables re-producing Symbol primitive value from StringImpl* uid
by executing`Symbol::create(vm, uid)`. This is needed to produce
Symbol primitive values from stored StringImpl* in `Object.getOwnPropertySymbols`.
And Symbol.[[Description]] is folded into the string value of Symbol's uid.
By doing so, we can represent ES6 Symbol without extending current PropertyTable key; StringImpl*.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.order:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createBuiltinExecutable):
* builtins/BuiltinNames.h:
* dfg/DFGOperations.cpp:
(JSC::DFG::operationPutByValInternal):
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::subtype):
* interpreter/Interpreter.cpp:
* jit/JITOperations.cpp:
(JSC::getByVal):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::getByVal):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter.asm:
* runtime/CommonIdentifiers.h:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::opIn):
* runtime/ExceptionHelpers.cpp:
(JSC::createUndefinedVariableError):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::synthesizePrototype):
(JSC::JSValue::dumpInContextAssumingStructure):
(JSC::JSValue::toStringSlowCase):
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::isSymbol):
(JSC::JSValue::isPrimitive):
(JSC::JSValue::toPropertyKey):
It represents ToPropertyKey abstract operation in the ES6 spec.
It cleans up the old implementation's `isName` checks.
And to prevent performance regressions in
js/regress/fold-get-by-id-to-multi-get-by-offset-rare-int.html
js/regress/fold-get-by-id-to-multi-get-by-offset.html
we annnotate this function as ALWAYS_INLINE.
(JSC::JSValue::getPropertySlot):
(JSC::JSValue::get):
(JSC::JSValue::equalSlowCaseInline):
(JSC::JSValue::strictEqualSlowCaseInline):
* runtime/JSCell.cpp:
(JSC::JSCell::put):
(JSC::JSCell::putByIndex):
(JSC::JSCell::toPrimitive):
(JSC::JSCell::getPrimitiveNumber):
(JSC::JSCell::toNumber):
(JSC::JSCell::toObject):
* runtime/JSCell.h:
* runtime/JSCellInlines.h:
(JSC::JSCell::isSymbol):
(JSC::JSCell::toBoolean):
(JSC::JSCell::pureToBoolean):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::symbolPrototype):
(JSC::JSGlobalObject::symbolObjectStructure):
* runtime/JSONObject.cpp:
(JSC::Stringifier::Stringifier):
* runtime/JSSymbolTableObject.cpp:
(JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
* runtime/JSType.h:
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::isName): Deleted.
* runtime/MapData.cpp:
(JSC::MapData::find):
(JSC::MapData::add):
(JSC::MapData::remove):
(JSC::MapData::replaceAndPackBackingStore):
* runtime/MapData.h:
(JSC::MapData::clear):
* runtime/NameInstance.h: Removed.
* runtime/NamePrototype.cpp: Removed.
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorGetOwnPropertyDescriptor):
(JSC::objectConstructorDefineProperty):
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncHasOwnProperty):
(JSC::objectProtoFuncDefineGetter):
(JSC::objectProtoFuncDefineSetter):
(JSC::objectProtoFuncLookupGetter):
(JSC::objectProtoFuncLookupSetter):
(JSC::objectProtoFuncPropertyIsEnumerable):
* runtime/Operations.cpp:
(JSC::jsTypeStringForValue):
(JSC::jsIsObjectType):
* runtime/PrivateName.h:
(JSC::PrivateName::PrivateName):
(JSC::PrivateName::operator==):
(JSC::PrivateName::operator!=):
* runtime/PropertyMapHashTable.h:
(JSC::PropertyTable::find):
(JSC::PropertyTable::get):
* runtime/PropertyName.h:
(JSC::PropertyName::PropertyName):
(JSC::PropertyName::publicName):
* runtime/SmallStrings.h:
* runtime/StringConstructor.cpp:
(JSC::callStringConstructor):
In ES6, String constructor accepts Symbol to execute `String(symbol)`.
* runtime/Structure.cpp:
(JSC::Structure::getPropertyNamesFromStructure):
* runtime/StructureInlines.h:
(JSC::Structure::prototypeForLookup):
* runtime/Symbol.cpp: Added.
(JSC::Symbol::Symbol):
(JSC::SymbolObject::create):
(JSC::Symbol::toPrimitive):
(JSC::Symbol::toBoolean):
(JSC::Symbol::getPrimitiveNumber):
(JSC::Symbol::toObject):
(JSC::Symbol::toNumber):
(JSC::Symbol::destroy):
(JSC::Symbol::descriptiveString):
* runtime/Symbol.h: Added.
(JSC::Symbol::createStructure):
(JSC::Symbol::create):
(JSC::Symbol::privateName):
(JSC::Symbol::finishCreation):
(JSC::asSymbol):
* runtime/SymbolConstructor.cpp: Renamed from Source/JavaScriptCore/runtime/NameConstructor.cpp.
(JSC::SymbolConstructor::SymbolConstructor):
(JSC::SymbolConstructor::finishCreation):
(JSC::callSymbol):
(JSC::SymbolConstructor::getConstructData):
(JSC::SymbolConstructor::getCallData):
* runtime/SymbolConstructor.h: Renamed from Source/JavaScriptCore/runtime/NameConstructor.h.
(JSC::SymbolConstructor::create):
(JSC::SymbolConstructor::createStructure):
* runtime/SymbolObject.cpp: Renamed from Source/JavaScriptCore/runtime/NameInstance.cpp.
(JSC::SymbolObject::SymbolObject):
(JSC::SymbolObject::finishCreation):
(JSC::SymbolObject::defaultValue):
Now JSC doesn't support @@toPrimitive. So instead of it, we implement
Symbol.prototype[@@toPrimitive] as ES5 Symbol.[[DefaultValue]].
* runtime/SymbolObject.h: Added.
(JSC::SymbolObject::create):
(JSC::SymbolObject::internalValue):
(JSC::SymbolObject::createStructure):
* runtime/SymbolPrototype.cpp: Added.
(JSC::SymbolPrototype::SymbolPrototype):
(JSC::SymbolPrototype::finishCreation):
(JSC::SymbolPrototype::getOwnPropertySlot):
(JSC::symbolProtoFuncToString):
(JSC::symbolProtoFuncValueOf):
* runtime/SymbolPrototype.h: Renamed from Source/JavaScriptCore/runtime/NamePrototype.h.
(JSC::SymbolPrototype::create):
(JSC::SymbolPrototype::createStructure):
SymbolPrototype object is ordinary JS object. Not wrapper object of Symbol.
It is tested in js/symbol-prototype-is-ordinary-object.html.
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2015-01-30 Geoffrey Garen <ggaren@apple.com>
Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
https://bugs.webkit.org/show_bug.cgi?id=140900
Reviewed by Mark Hahnenberg.
Re-landing just the HandleBlock piece of this patch.
* heap/HandleBlock.h:
* heap/HandleBlockInlines.h:
(JSC::HandleBlock::create):
(JSC::HandleBlock::destroy):
(JSC::HandleBlock::HandleBlock):
(JSC::HandleBlock::payloadEnd):
* heap/HandleSet.cpp:
(JSC::HandleSet::~HandleSet):
(JSC::HandleSet::grow):
2015-01-30 Geoffrey Garen <ggaren@apple.com>
GC marking threads should clear malloc caches
https://bugs.webkit.org/show_bug.cgi?id=141097
Reviewed by Sam Weinig.
Follow-up based on Mark Hahnenberg's review: Release after the copy
phase, rather than after any phase, since we'd rather not release
between marking and copying.
* heap/GCThread.cpp:
(JSC::GCThread::waitForNextPhase):
(JSC::GCThread::gcThreadMain):
2015-01-30 Geoffrey Garen <ggaren@apple.com>
GC marking threads should clear malloc caches
https://bugs.webkit.org/show_bug.cgi?id=141097
Reviewed by Andreas Kling.
This is an attempt to ameliorate a potential memory use regression
caused by https://bugs.webkit.org/show_bug.cgi?id=140900
Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages.
FastMalloc may accumulate a per-thread cache on each of the 8-ish
GC marking threads, which can be expensive.
* heap/GCThread.cpp:
(JSC::GCThread::waitForNextPhase): Scavenge the current thread before
going to sleep. There's probably not too much value to keeping our
per-thread cache between GCs, and it has some memory footprint.
2015-01-30 Chris Dumez <cdumez@apple.com>
Rename shared() static member functions to singleton() for singleton classes.
https://bugs.webkit.org/show_bug.cgi?id=141088
Reviewed by Ryosuke Niwa and Benjamin Poulain.
Rename shared() static member functions to singleton() for singleton
classes as per the recent coding style change.
* inspector/remote/RemoteInspector.h:
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::singleton):
(Inspector::RemoteInspector::start):
(Inspector::RemoteInspector::shared): Deleted.
* inspector/remote/RemoteInspectorDebuggable.cpp:
(Inspector::RemoteInspectorDebuggable::~RemoteInspectorDebuggable):
(Inspector::RemoteInspectorDebuggable::init):
(Inspector::RemoteInspectorDebuggable::update):
(Inspector::RemoteInspectorDebuggable::setRemoteDebuggingAllowed):
(Inspector::RemoteInspectorDebuggable::pauseWaitingForAutomaticInspection):
(Inspector::RemoteInspectorDebuggable::unpauseForInitializedInspector):
* inspector/remote/RemoteInspectorDebuggableConnection.mm:
(Inspector::RemoteInspectorDebuggableConnection::setup):
(Inspector::RemoteInspectorDebuggableConnection::sendMessageToFrontend):
2015-01-30 Geoffrey Garen <ggaren@apple.com>
Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
https://bugs.webkit.org/show_bug.cgi?id=140900
Reviewed by Mark Hahnenberg.
Re-landing just the CopyWorkListSegment piece of this patch.
* heap/CopiedBlockInlines.h:
(JSC::CopiedBlock::reportLiveBytes):
* heap/CopyWorkList.h:
(JSC::CopyWorkListSegment::create):
(JSC::CopyWorkListSegment::destroy):
(JSC::CopyWorkListSegment::CopyWorkListSegment):
(JSC::CopyWorkList::CopyWorkList):
(JSC::CopyWorkList::~CopyWorkList):
(JSC::CopyWorkList::append):
2015-01-29 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r179357 and r179358.
https://bugs.webkit.org/show_bug.cgi?id=141062
Suspect this caused WebGL tests to start flaking (Requested by
kling on #webkit).
Reverted changesets:
"Polymorphic call inlining should be based on polymorphic call
inline caching rather than logging"
https://bugs.webkit.org/show_bug.cgi?id=140660
http://trac.webkit.org/changeset/179357
"Unreviewed, fix no-JIT build."
http://trac.webkit.org/changeset/179358
2015-01-29 Geoffrey Garen <ggaren@apple.com>
Removed op_ret_object_or_this
https://bugs.webkit.org/show_bug.cgi?id=141048
Reviewed by Michael Saboff.
op_ret_object_or_this was one opcode that would keep us out of the
optimizing compilers.
We don't need a special-purpose opcode; we can just use a branch.
* bytecode/BytecodeBasicBlock.cpp:
(JSC::isTerminal): Removed.
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset): Removed.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode): Removed.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitReturn): Use an explicit branch to determine
if we need to substitute 'this' for the return value. Our engine no longer
benefits from fused opcodes that dispatch less in the interpreter.
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITCall32_64.cpp:
(JSC::JIT::emit_op_ret_object_or_this): Deleted.
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_ret_object_or_this): Deleted.
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm: Removed.
2015-01-29 Ryosuke Niwa <rniwa@webkit.org>
Implement ES6 class syntax without inheritance support
https://bugs.webkit.org/show_bug.cgi?id=140918
Reviewed by Geoffrey Garen.
Added the most basic support for ES6 class syntax. After this patch, we support basic class definition like:
class A {
constructor() { }
someMethod() { }
}
We'll add the support for "extends" keyword and automatically generating a constructor in follow up patches.
We also don't support block scoping of a class declaration.
We support both class declaration and class expression. A class expression is implemented by the newly added
ClassExprNode AST node. A class declaration is implemented by ClassDeclNode, which is a thin wrapper around
AssignResolveNode.
Tests: js/class-syntax-declaration.html
js/class-syntax-expression.html
* bytecompiler/NodesCodegen.cpp:
(JSC::ObjectLiteralNode::emitBytecode): Create a new object instead of delegating the work to PropertyListNode.
Also fixed the 5-space indentation.
(JSC::PropertyListNode::emitBytecode): Don't create a new object now that ObjectLiteralNode does this.
(JSC::ClassDeclNode::emitBytecode): Added. Just let the AssignResolveNode node emit the byte code.
(JSC::ClassExprNode::emitBytecode): Create the class constructor and add static methods to the constructor by
emitting the byte code for PropertyListNode. Add instance methods to the class's prototype object the same way.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createClassExpr): Added. Creates a ClassExprNode.
(JSC::ASTBuilder::createClassDeclStatement): Added. Creates a AssignResolveNode and wraps it by a ClassDeclNode.
* parser/NodeConstructors.h:
(JSC::ClassDeclNode::ClassDeclNode): Added.
(JSC::ClassExprNode::ClassExprNode): Added.
* parser/Nodes.h:
(JSC::ClassExprNode): Added.
(JSC::ClassDeclNode): Added.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseStatement): Added the support for class declaration.
(JSC::stringForFunctionMode): Return "method" for MethodMode.
(JSC::Parser<LexerType>::parseClassDeclaration): Added. Uses parseClass to create a class expression and wraps
it with ClassDeclNode as described above.
(JSC::Parser<LexerType>::parseClass): Parses a class expression.
(JSC::Parser<LexerType>::parseProperty):
(JSC::Parser<LexerType>::parseGetterSetter): Extracted from parseProperty to share the code between parseProperty
and parseClass.
(JSC::Parser<LexerType>::parsePrimaryExpression): Added the support for class expression.
* parser/Parser.h:
(FunctionParseMode): Added MethodMode.
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createClassExpr): Added.
(JSC::SyntaxChecker::createClassDeclStatement): Added.
2015-01-29 Geoffrey Garen <ggaren@apple.com>
Try to fix the Windows build.
Not reviewed.
* heap/WeakBlock.h: Use the fully qualified name when declaring our friend.
2015-01-29 Geoffrey Garen <ggaren@apple.com>
Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
https://bugs.webkit.org/show_bug.cgi?id=140900
Reviewed by Mark Hahnenberg.
Re-landing just the WeakBlock piece of this patch.
* heap/WeakBlock.cpp:
(JSC::WeakBlock::create):
(JSC::WeakBlock::destroy):
(JSC::WeakBlock::WeakBlock):
* heap/WeakBlock.h:
* heap/WeakSet.cpp:
(JSC::WeakSet::~WeakSet):
(JSC::WeakSet::addAllocator):
(JSC::WeakSet::removeAllocator):
2015-01-29 Geoffrey Garen <ggaren@apple.com>
Use Vector instead of GCSegmentedArray in CodeBlockSet
https://bugs.webkit.org/show_bug.cgi?id=141044
Reviewed by Ryosuke Niwa.
This is allowed now that we've gotten rid of fastMallocForbid.
4kB was a bit overkill for just storing a few pointers.
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::CodeBlockSet):
* heap/CodeBlockSet.h:
* heap/Heap.cpp:
(JSC::Heap::Heap):
2015-01-29 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix no-JIT build.
* jit/PolymorphicCallStubRoutine.cpp:
2015-01-28 Filip Pizlo <fpizlo@apple.com>
Polymorphic call inlining should be based on polymorphic call inline caching rather than logging
https://bugs.webkit.org/show_bug.cgi?id=140660
Reviewed by Geoffrey Garen.
When we first implemented polymorphic call inlining, we did the profiling based on a call
edge log. The idea was to store each call edge (a tuple of call site and callee) into a
global log that was processed lazily. Processing the log would give precise counts of call
edges, and could be used to drive well-informed inlining decisions - polymorphic or not.
This was a speed-up on throughput tests but a slow-down for latency tests. It was a net win
nonetheless.
Experience with this code shows three things. First, the call edge profiler is buggy and
complex. It would take work to fix the bugs. Second, the call edge profiler incurs lots of
overhead for latency code that we care deeply about. Third, it's not at all clear that
having call edge counts for every possible callee is any better than just having call edge
counts for the limited number of callees that an inline cache would catch.
So, this patch removes the call edge profiler and replaces it with a polymorphic call inline
cache. If we miss the basic call inline cache, we inflate the cache to be a jump to an
out-of-line stub that cases on the previously known callees. If that misses again, then we
rewrite that stub to include the new callee. We do this up to some number of callees. If we
hit the limit then we switch to using a plain virtual call.
Substantial speed-up on V8Spider; undoes the slow-down that the original call edge profiler
caused. Might be a SunSpider speed-up (below 1%), depending on hardware.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CallEdge.h:
(JSC::CallEdge::count):
(JSC::CallEdge::CallEdge):
* bytecode/CallEdgeProfile.cpp: Removed.
* bytecode/CallEdgeProfile.h: Removed.
* bytecode/CallEdgeProfileInlines.h: Removed.
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::unlink):
(JSC::CallLinkInfo::visitWeak):
* bytecode/CallLinkInfo.h:
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::CallLinkStatus):
(JSC::CallLinkStatus::computeFor):
(JSC::CallLinkStatus::computeFromCallLinkInfo):
(JSC::CallLinkStatus::isClosureCall):
(JSC::CallLinkStatus::makeClosureCall):
(JSC::CallLinkStatus::dump):
(JSC::CallLinkStatus::computeFromCallEdgeProfile): Deleted.
* bytecode/CallLinkStatus.h:
(JSC::CallLinkStatus::CallLinkStatus):
(JSC::CallLinkStatus::isSet):
(JSC::CallLinkStatus::variants):
(JSC::CallLinkStatus::size):
(JSC::CallLinkStatus::at):
(JSC::CallLinkStatus::operator[]):
(JSC::CallLinkStatus::canOptimize):
(JSC::CallLinkStatus::edges): Deleted.
(JSC::CallLinkStatus::canTrustCounts): Deleted.
* bytecode/CallVariant.cpp:
(JSC::variantListWithVariant):
(JSC::despecifiedVariantList):
* bytecode/CallVariant.h:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::~CodeBlock):
(JSC::CodeBlock::linkIncomingPolymorphicCall):
(JSC::CodeBlock::unlinkIncomingCalls):
(JSC::CodeBlock::noticeIncomingCall):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::isIncomingCallAlreadyLinked): Deleted.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
(JSC::DFG::ByteCodeParser::handleCall):
(JSC::DFG::ByteCodeParser::handleInlining):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGDriver.cpp:
(JSC::DFG::compileImpl):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasHeapPrediction):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGTierUpCheckInjectionPhase.cpp:
(JSC::DFG::TierUpCheckInjectionPhase::run):
(JSC::DFG::TierUpCheckInjectionPhase::removeFTLProfiling): Deleted.
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* heap/Heap.cpp:
(JSC::Heap::collect):
* jit/BinarySwitch.h:
* jit/ClosureCallStubRoutine.cpp: Removed.
* jit/ClosureCallStubRoutine.h: Removed.
* jit/JITCall.cpp:
(JSC::JIT::compileOpCall):
* jit/JITCall32_64.cpp:
(JSC::JIT::compileOpCall):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
(JSC::operationLinkPolymorphicCallFor):
(JSC::operationLinkClosureCallFor): Deleted.
* jit/JITStubRoutine.h:
* jit/JITWriteBarrier.h:
* jit/PolymorphicCallStubRoutine.cpp: Added.
(JSC::PolymorphicCallNode::~PolymorphicCallNode):
(JSC::PolymorphicCallNode::unlink):
(JSC::PolymorphicCallCase::dump):
(JSC::PolymorphicCallStubRoutine::PolymorphicCallStubRoutine):
(JSC::PolymorphicCallStubRoutine::~PolymorphicCallStubRoutine):
(JSC::PolymorphicCallStubRoutine::variants):
(JSC::PolymorphicCallStubRoutine::edges):
(JSC::PolymorphicCallStubRoutine::visitWeak):
(JSC::PolymorphicCallStubRoutine::markRequiredObjectsInternal):
* jit/PolymorphicCallStubRoutine.h: Added.
(JSC::PolymorphicCallNode::PolymorphicCallNode):
(JSC::PolymorphicCallCase::PolymorphicCallCase):
(JSC::PolymorphicCallCase::variant):
(JSC::PolymorphicCallCase::codeBlock):
* jit/Repatch.cpp:
(JSC::linkSlowFor):
(JSC::linkFor):
(JSC::revertCall):
(JSC::unlinkFor):
(JSC::linkVirtualFor):
(JSC::linkPolymorphicCall):
(JSC::linkClosureCall): Deleted.
* jit/Repatch.h:
* jit/ThunkGenerators.cpp:
(JSC::linkPolymorphicCallForThunkGenerator):
(JSC::linkPolymorphicCallThunkGenerator):
(JSC::linkPolymorphicCallThatPreservesRegsThunkGenerator):
(JSC::linkClosureCallForThunkGenerator): Deleted.
(JSC::linkClosureCallThunkGenerator): Deleted.
(JSC::linkClosureCallThatPreservesRegsThunkGenerator): Deleted.
* jit/ThunkGenerators.h:
(JSC::linkPolymorphicCallThunkGeneratorFor):
(JSC::linkClosureCallThunkGeneratorFor): Deleted.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::jitCompileAndSetHeuristics):
* runtime/Options.h:
* runtime/VM.cpp:
(JSC::VM::prepareToDiscardCode):
(JSC::VM::ensureCallEdgeLog): Deleted.
* runtime/VM.h:
2015-01-29 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: ES6: Improved Console Format for Set and Map Objects (like Arrays)
https://bugs.webkit.org/show_bug.cgi?id=122867
Reviewed by Timothy Hatcher.
Add new Runtime.RemoteObject object subtypes for "map", "set", and "weakmap".
Upgrade Runtime.ObjectPreview to include type/subtype information. Now,
an ObjectPreview can be used for any value, in place of a RemoteObject,
and not capture / hold a reference to the value. The value will be in
the string description.
Adding this information to ObjectPreview can duplicate some information
in the protocol messages if a preview is provided, but simplifies
previews, so that all the information you need for any RemoteObject
preview is available. To slim messages further, make "overflow" and
"properties" only available on previews that may contain properties.
So, not primitives or null.
Finally, for "Map/Set/WeakMap" add an "entries" list to the preview
that will return previews with "key" and "value" properties depending
on the collection type. To get live, non-preview objects from a
collection, use Runtime.getCollectionEntries.
In order to keep the WeakMap's values Weak the frontend may provide
a unique object group name when getting collection entries. It may
then release that object group, e.g. when not showing the WeakMap's
values to the user, and thus remove the strong reference to the keys
so they may be garbage collected.
* runtime/WeakMapData.h:
(JSC::WeakMapData::begin):
(JSC::WeakMapData::end):
Expose iterators so the Inspector may access WeakMap keys/values.
* inspector/JSInjectedScriptHostPrototype.cpp:
(Inspector::JSInjectedScriptHostPrototype::finishCreation):
(Inspector::jsInjectedScriptHostPrototypeFunctionWeakMapEntries):
* inspector/JSInjectedScriptHost.h:
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::subtype):
Discern "map", "set", and "weakmap" object subtypes.
(Inspector::JSInjectedScriptHost::weakMapEntries):
Return a list of WeakMap entries. These are strong references
that the Inspector code is responsible for releasing.
* inspector/protocol/Runtime.json:
Update types and expose the new getCollectionEntries command.
* inspector/agents/InspectorRuntimeAgent.h:
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::getCollectionEntries):
* inspector/InjectedScript.h:
* inspector/InjectedScript.cpp:
(Inspector::InjectedScript::getInternalProperties):
(Inspector::InjectedScript::getCollectionEntries):
Pass through to the InjectedScript and call getCollectionEntries.
* inspector/scripts/codegen/generator.py:
Add another type with runtime casting.
* inspector/InjectedScriptSource.js:
- Implement getCollectionEntries to get a range of values from a
collection. The non-Weak collections have an order to their keys (in
order of added) so range'd gets are okay. WeakMap does not have an
order, so only allow fetching a number of values.
- Update preview generation to address the Runtime.ObjectPreview
type changes.
2015-01-28 Geoffrey Garen <ggaren@apple.com>
Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
https://bugs.webkit.org/show_bug.cgi?id=140900
Reviewed by Mark Hahnenberg.
Re-landing just the GCArraySegment piece of this patch.
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::CodeBlockSet):
* heap/CodeBlockSet.h:
* heap/GCSegmentedArray.h:
(JSC::GCArraySegment::GCArraySegment):
* heap/GCSegmentedArrayInlines.h:
(JSC::GCSegmentedArray<T>::GCSegmentedArray):
(JSC::GCSegmentedArray<T>::~GCSegmentedArray):
(JSC::GCSegmentedArray<T>::clear):
(JSC::GCSegmentedArray<T>::expand):
(JSC::GCSegmentedArray<T>::refill):
(JSC::GCArraySegment<T>::create):
(JSC::GCArraySegment<T>::destroy):
* heap/GCThreadSharedData.cpp:
(JSC::GCThreadSharedData::GCThreadSharedData):
* heap/Heap.cpp:
(JSC::Heap::Heap):
* heap/MarkStack.cpp:
(JSC::MarkStackArray::MarkStackArray):
* heap/MarkStack.h:
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::SlotVisitor):
2015-01-29 Csaba Osztrogonác <ossy@webkit.org>
Move HAVE_DTRACE definition back to Platform.h
https://bugs.webkit.org/show_bug.cgi?id=141033
Reviewed by Dan Bernstein.
* Configurations/Base.xcconfig:
* JavaScriptCore.xcodeproj/project.pbxproj:
2015-01-28 Geoffrey Garen <ggaren@apple.com>
Removed fastMallocForbid / fastMallocAllow
https://bugs.webkit.org/show_bug.cgi?id=141012
Reviewed by Mark Hahnenberg.
Copy non-current thread stacks before scanning them instead of scanning
them in-place.
This operation is uncommon (i.e., never in the web content process),
and even in a stress test with 4 threads it only copies about 27kB,
so I think the performance cost is OK.
Scanning in-place requires a complex dance where we constrain our GC
data structures not to use malloc, free, or any other interesting functions
that might acquire locks. We've gotten this wrong many times in the past,
and I just got it wrong again yesterday. Since this code path is rarely
tested, I want it to just make sense, and not depend on or constrain the
details of the rest of the GC heap's design.
* heap/MachineStackMarker.cpp:
(JSC::otherThreadStack): Factored out a helper function for dealing with
unaligned and/or backwards pointers.
(JSC::MachineThreads::tryCopyOtherThreadStack): This is now the only
constrained function, and it only calls memcpy and low-level thread APIs.
(JSC::MachineThreads::tryCopyOtherThreadStacks): The design here is that
you do one pass over all the threads to compute their combined size,
and then a second pass to do all the copying. In theory, the threads may
grow in between passes, in which case you'll continue until the threads
stop growing. In practice, you never continue.
(JSC::growBuffer): Helper function for growing.
(JSC::MachineThreads::gatherConservativeRoots):
(JSC::MachineThreads::gatherFromOtherThread): Deleted.
* heap/MachineStackMarker.h: Updated for interface changes.
2015-01-28 Brian J. Burg <burg@cs.washington.edu>
Web Inspector: remove CSS.setPropertyText, CSS.toggleProperty and related dead code
https://bugs.webkit.org/show_bug.cgi?id=140961
Reviewed by Timothy Hatcher.
* inspector/protocol/CSS.json: Remove unused protocol methods.
2015-01-28 Dana Burkart <dburkart@apple.com>
Move ASan flag settings from DebugRelease.xcconfig to Base.xcconfig
https://bugs.webkit.org/show_bug.cgi?id=136765
Reviewed by Alexey Proskuryakov.
* Configurations/Base.xcconfig:
* Configurations/DebugRelease.xcconfig:
2015-01-27 Filip Pizlo <fpizlo@apple.com>
ExitSiteData saying m_takesSlowPath shouldn't mean early returning takesSlowPath() since for the non-LLInt case we later set m_couldTakeSlowPath, which is more precise
https://bugs.webkit.org/show_bug.cgi?id=140980
Reviewed by Oliver Hunt.
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFor):
2015-01-27 Filip Pizlo <fpizlo@apple.com>
Move DFGBinarySwitch out of the DFG so that all of the JITs can use it
https://bugs.webkit.org/show_bug.cgi?id=140959
Rubber stamped by Geoffrey Garen.
I want to use this for polymorphic stubs for https://bugs.webkit.org/show_bug.cgi?id=140660.
This code no longer has DFG dependencies so this is a very clean move.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGBinarySwitch.cpp: Removed.
* dfg/DFGBinarySwitch.h: Removed.
* dfg/DFGSpeculativeJIT.cpp:
* jit/BinarySwitch.cpp: Copied from Source/JavaScriptCore/dfg/DFGBinarySwitch.cpp.
* jit/BinarySwitch.h: Copied from Source/JavaScriptCore/dfg/DFGBinarySwitch.h.
2015-01-27 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r179192.
https://bugs.webkit.org/show_bug.cgi?id=140953
Caused numerous layout test failures (Requested by mattbaker_
on #webkit).
Reverted changeset:
"Use FastMalloc (bmalloc) instead of BlockAllocator for GC
pages"
https://bugs.webkit.org/show_bug.cgi?id=140900
http://trac.webkit.org/changeset/179192
2015-01-27 Michael Saboff <msaboff@apple.com>
REGRESSION(r178591): 20% regression in Octane box2d
https://bugs.webkit.org/show_bug.cgi?id=140948
Reviewed by Geoffrey Garen.
Added check that we have a lexical environment to the arguments is captured check.
It doesn't make sense to resolve "arguments" when it really isn't captured.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::willResolveToArgumentsRegister):
2015-01-26 Geoffrey Garen <ggaren@apple.com>
Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
https://bugs.webkit.org/show_bug.cgi?id=140900
Reviewed by Mark Hahnenberg.
Removes some more custom allocation code.
Looks like a speedup. (See results attached to bugzilla.)
Will hopefully reduce memory use by improving sharing between the GC and
malloc heaps.
* API/JSBase.cpp:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj: Feed the compiler.
* heap/BlockAllocator.cpp: Removed.
* heap/BlockAllocator.h: Removed. No need for a custom allocator anymore.
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::CodeBlockSet):
* heap/CodeBlockSet.h: Feed the compiler.
* heap/CopiedBlock.h:
(JSC::CopiedBlock::createNoZeroFill):
(JSC::CopiedBlock::create):
(JSC::CopiedBlock::CopiedBlock):
(JSC::CopiedBlock::isOversize):
(JSC::CopiedBlock::payloadEnd):
(JSC::CopiedBlock::capacity):
* heap/CopiedBlockInlines.h:
(JSC::CopiedBlock::reportLiveBytes): Each copied block now tracks its
own size, since we can't rely on Region to tell us our size anymore.
* heap/CopiedSpace.cpp:
(JSC::CopiedSpace::~CopiedSpace):
(JSC::CopiedSpace::tryAllocateOversize):
(JSC::CopiedSpace::tryReallocateOversize):
* heap/CopiedSpaceInlines.h:
(JSC::CopiedSpace::recycleEvacuatedBlock):
(JSC::CopiedSpace::recycleBorrowedBlock):
(JSC::CopiedSpace::allocateBlockForCopyingPhase):
(JSC::CopiedSpace::allocateBlock):
(JSC::CopiedSpace::startedCopying): Deallocate blocks directly, rather
than pushing them onto the block allocator's free list; the block
allocator doesn't exist anymore.
* heap/CopyWorkList.h:
(JSC::CopyWorkListSegment::create):
(JSC::CopyWorkListSegment::CopyWorkListSegment):
(JSC::CopyWorkList::~CopyWorkList):
(JSC::CopyWorkList::append):
(JSC::CopyWorkList::CopyWorkList): Deleted.
* heap/GCSegmentedArray.h:
(JSC::GCArraySegment::GCArraySegment):
* heap/GCSegmentedArrayInlines.h:
(JSC::GCSegmentedArray<T>::GCSegmentedArray):
(JSC::GCSegmentedArray<T>::~GCSegmentedArray):
(JSC::GCSegmentedArray<T>::clear):
(JSC::GCSegmentedArray<T>::expand):
(JSC::GCSegmentedArray<T>::refill):
(JSC::GCArraySegment<T>::create):
* heap/GCThreadSharedData.cpp:
(JSC::GCThreadSharedData::GCThreadSharedData):
* heap/GCThreadSharedData.h: Feed the compiler.
* heap/HandleBlock.h:
* heap/HandleBlockInlines.h:
(JSC::HandleBlock::create):
(JSC::HandleBlock::HandleBlock):
(JSC::HandleBlock::payloadEnd):
* heap/HandleSet.cpp:
(JSC::HandleSet::~HandleSet):
(JSC::HandleSet::grow): Same as above.
* heap/Heap.cpp:
(JSC::Heap::Heap):
* heap/Heap.h: Removed the block allocator since it is unused now.
* heap/HeapBlock.h:
(JSC::HeapBlock::destroy):
(JSC::HeapBlock::HeapBlock):
(JSC::HeapBlock::region): Deleted. Removed the Region pointer from each
HeapBlock since a HeapBlock is just a normal allocation now.
* heap/HeapInlines.h:
(JSC::Heap::blockAllocator): Deleted.
* heap/HeapTimer.cpp:
* heap/MarkStack.cpp:
(JSC::MarkStackArray::MarkStackArray):
* heap/MarkStack.h: Feed the compiler.
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::allocateBlock): No need to use a custom code path
based on size, since we use a general purpose allocator now.
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::create):
(JSC::MarkedBlock::destroy):
(JSC::MarkedBlock::MarkedBlock):
* heap/MarkedBlock.h:
(JSC::MarkedBlock::capacity): Track block size explicitly, like CopiedBlock.
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::freeBlock):
* heap/MarkedSpace.h:
* heap/Region.h: Removed.
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::SlotVisitor): Removed reference to block allocator.
* heap/SuperRegion.cpp: Removed.
* heap/SuperRegion.h: Removed.
* heap/WeakBlock.cpp:
(JSC::WeakBlock::create):
(JSC::WeakBlock::WeakBlock):
* heap/WeakBlock.h:
* heap/WeakSet.cpp:
(JSC::WeakSet::~WeakSet):
(JSC::WeakSet::addAllocator):
(JSC::WeakSet::removeAllocator): Removed reference to block allocator.
2015-01-27 Csaba Osztrogonác <ossy@webkit.org>
[ARM] Typo fix after r176083
https://bugs.webkit.org/show_bug.cgi?id=140937
Reviewed by Anders Carlsson.
* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::ldrh):
2015-01-27 Csaba Osztrogonác <ossy@webkit.org>
[Win] Unreviewed gardening, skip failing tests.
* tests/exceptionFuzz.yaml: Skip exception fuzz tests due to bug140928.
* tests/mozilla/mozilla-tests.yaml: Skip ecma/Date/15.9.5.28-1.js due to bug140927.
2015-01-26 Csaba Osztrogonác <ossy@webkit.org>
[Win] Enable JSC stress tests by default
https://bugs.webkit.org/show_bug.cgi?id=128307
Unreviewed typo fix after r179165.
* tests/mozilla/mozilla-tests.yaml:
2015-01-26 Csaba Osztrogonác <ossy@webkit.org>
[Win] Enable JSC stress tests by default
https://bugs.webkit.org/show_bug.cgi?id=128307
Reviewed by Brent Fulgham.
* tests/mozilla/mozilla-tests.yaml: Skipped on Windows.
* tests/stress/ftl-arithcos.js: Skipped on Windows.
2015-01-26 Ryosuke Niwa <rniwa@webkit.org>
Parse a function expression as a primary expression
https://bugs.webkit.org/show_bug.cgi?id=140908
Reviewed by Mark Lam.
Moved the code to generate an AST node for a function expression from parseMemberExpression
to parsePrimaryExpression to match the ES6 specification terminology:
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-primary-expression
There should be no behavior change from this change since parsePrimaryExpression is only
called in parseMemberExpression other than the fact failIfStackOverflow() is called.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parsePrimaryExpression):
(JSC::Parser<LexerType>::parseMemberExpression):
2015-01-26 Myles C. Maxfield <mmaxfield@apple.com>
[iOS] [SVG -> OTF Converter] Flip the switch off on iOS
https://bugs.webkit.org/show_bug.cgi?id=140860
Reviewed by Darin Adler.
The fonts it makes are grotesque. (See what I did there? Typographic
humor is the best humor.)
* Configurations/FeatureDefines.xcconfig:
2015-01-23 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Rename InjectedScriptHost::type to subtype
https://bugs.webkit.org/show_bug.cgi?id=140841
Reviewed by Timothy Hatcher.
We were using this to set the subtype of an "object" type RemoteObject
so we should clean up the name and call it subtype.
* inspector/InjectedScriptHost.h:
* inspector/InjectedScriptSource.js:
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::subtype):
(Inspector::JSInjectedScriptHost::type): Deleted.
* inspector/JSInjectedScriptHost.h:
* inspector/JSInjectedScriptHostPrototype.cpp:
(Inspector::JSInjectedScriptHostPrototype::finishCreation):
(Inspector::jsInjectedScriptHostPrototypeFunctionSubtype):
(Inspector::jsInjectedScriptHostPrototypeFunctionType): Deleted.
2015-01-23 Michael Saboff <msaboff@apple.com>
LayoutTests/js/script-tests/reentrant-caching.js crashing on 32 bit builds
https://bugs.webkit.org/show_bug.cgi?id=140843
Reviewed by Oliver Hunt.
When we are in vmEntryToJavaScript, we keep the stack pointer at an
alignment sutiable for pointing to a call frame header, which is the
alignment post making a call. We adjust the sp when calling to JS code,
but don't adjust it before calling the out of stack handler.
* llint/LowLevelInterpreter32_64.asm:
Moved stack point down 8 bytes to get it aligned.
2015-01-23 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Object Previews in the Console
https://bugs.webkit.org/show_bug.cgi?id=129204
Reviewed by Timothy Hatcher.
Update the very old, unused object preview code. Part of this comes from
the earlier WebKit legacy implementation, and the Blink implementation.
A RemoteObject may include a preview, if it is asked for, and if the
RemoteObject is an object. Previews are a shallow (single level) list
of a limited number of properties on the object. The previewed
properties are always stringified (even if primatives). Previews are
limited to just 5 properties or 100 indices. Previews are marked
as lossless if they are a complete snapshot of the object.
There is a path to make previews two levels deep, that is currently
unused but should soon be used for tables (e.g. IndexedDB).
* inspector/InjectedScriptSource.js:
- Move some code off of InjectedScript to be generic functions
usable by RemoteObject as well.
- Update preview generation to use
* inspector/protocol/Runtime.json:
- Add a new type, "accessor" for preview objects. This represents
a getter / setter. We currently don't get the value.
2015-01-23 Michael Saboff <msaboff@apple.com>
Immediate crash when setting JS breakpoint
https://bugs.webkit.org/show_bug.cgi?id=140811
Reviewed by Mark Lam.
When the DFG stack layout phase doesn't allocate a register for the scope register,
it incorrectly sets the scope register in the code block to a bad value, one with
an offset of 0. Changed it so that we set the code block's scope register to the
invalid VirtualRegister instead.
No tests needed as adding the ASSERT in setScopeRegister() was used to find the bug.
We crash with that ASSERT in testapi and likely many other tests as well.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::setScopeRegister):
(JSC::CodeBlock::scopeRegister):
Added ASSERTs to catch any future improper setting of the code block's scope register.
* dfg/DFGStackLayoutPhase.cpp:
(JSC::DFG::StackLayoutPhase::run):
2015-01-22 Mark Hahnenberg <mhahnenb@gmail.com>
EdenCollections unnecessarily visit SmallStrings
https://bugs.webkit.org/show_bug.cgi?id=140762
Reviewed by Geoffrey Garen.
* heap/Heap.cpp:
(JSC::Heap::copyBackingStores): Also added a GCPhase for copying
backing stores, which is a significant portion of garbage collection.
(JSC::Heap::visitSmallStrings): Check to see if we need to visit
SmallStrings based on the collection type.
* runtime/SmallStrings.cpp:
(JSC::SmallStrings::SmallStrings):
(JSC::SmallStrings::visitStrongReferences): Set the fact that we have
visited the SmallStrings since the last modification.
* runtime/SmallStrings.h:
(JSC::SmallStrings::needsToBeVisited): If we're doing a
FullCollection, we need to visit. Otherwise, it depends on whether
we've been visited since the last modification/allocation.
2015-01-22 Ryosuke Niwa <rniwa@webkit.org>
Add a build flag for ES6 class syntax
https://bugs.webkit.org/show_bug.cgi?id=140760
Reviewed by Michael Saboff.
Added ES6_CLASS_SYNTAX build flag and used it in tokenizer to recognize
"class", "extends", "static" and "super" keywords.
* Configurations/FeatureDefines.xcconfig:
* parser/Keywords.table:
* parser/ParserTokens.h:
2015-01-22 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r178894.
https://bugs.webkit.org/show_bug.cgi?id=140775
Broke JSC and bindings tests (Requested by ap_ on #webkit).
Reverted changeset:
"put_by_val_direct need to check the property is index or not
for using putDirect / putDirectIndex"
https://bugs.webkit.org/show_bug.cgi?id=140426
http://trac.webkit.org/changeset/178894
2015-01-22 Mark Lam <mark.lam@apple.com>
BytecodeGenerator::initializeCapturedVariable() sets a misleading value for the 5th operand of op_put_to_scope.
<https://webkit.org/b/140743>
Reviewed by Oliver Hunt.
BytecodeGenerator::initializeCapturedVariable() was setting the 5th operand to
op_put_to_scope to an inappropriate value (i.e. 0). As a result, the execution
of put_to_scope could store a wrong inferred value into the VariableWatchpointSet
for which ever captured variable is at local index 0. In practice, this turns
out to be the local for the Arguments object. In this reproduction case in the
bug, the wrong inferred value written there is the boolean true.
Subsequently, DFG compilation occurs and CreateArguments is emitted to first do
a check of the local for the Arguments object. But because that local has a
wrong inferred value, the check always discovers a non-null value and we never
actually create the Arguments object. Immediately after this, an OSR exit
occurs leaving the Arguments object local uninitialized. Later on at arguments
tear off, we run into a boolean true where we had expected to find an Arguments
object, which in turn, leads to the crash.
The fix is to:
1. In the case where the resolveModeType is LocalClosureVar, change the
5th operand of op_put_to_scope to be a boolean. True means that the
local var is watchable. False means it is not watchable. We no longer
pass the local index (instead of true) and UINT_MAX (instead of false).
This allows us to express more clearer in the code what that value means,
as well as remove the redundant way of getting the local's identifier.
The identifier is always the one passed in the 2nd operand.
2. Previously, though intuitively, we know that the watchable variable
identifier should be the same as the one that is passed in operand 2, this
relationship was not clear in the code. By code analysis, I confirmed that
the callers of BytecodeGenerator::emitPutToScope() always use the same
identifier for operand 2 and for filling out the ResolveScopeInfo from
which we get the watchable variable identifier later. I've changed the
code to make this clear now by always using the identifier passed in
operand 2.
3. In the case where the resolveModeType is LocalClosureVar,
initializeCapturedVariable() and emitPutToScope() will now query
hasWatchableVariable() to determine if the local is watchable or not.
Accordingly, we pass the boolean result of hasWatchableVariable() as
operand 5 of op_put_to_scope.
Also added some assertions.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::initializeCapturedVariable):
(JSC::BytecodeGenerator::hasConstant):
(JSC::BytecodeGenerator::emitPutToScope):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::hasWatchableVariable):
(JSC::BytecodeGenerator::watchableVariableIdentifier):
(JSC::BytecodeGenerator::watchableVariable): Deleted.
2015-01-22 Ryosuke Niwa <rniwa@webkit.org>
PropertyListNode::emitNode duplicates the code to put a constant property
https://bugs.webkit.org/show_bug.cgi?id=140761
Reviewed by Geoffrey Garen.
Extracted PropertyListNode::emitPutConstantProperty to share the code.
Also made PropertyListNode::emitBytecode private since nobody is calling this function directly.
* bytecompiler/NodesCodegen.cpp:
(JSC::PropertyListNode::emitBytecode):
(JSC::PropertyListNode::emitPutConstantProperty): Added.
* parser/Nodes.h:
2015-01-22 Yusuke Suzuki <utatane.tea@gmail.com>
put_by_val_direct need to check the property is index or not for using putDirect / putDirectIndex
https://bugs.webkit.org/show_bug.cgi?id=140426
Reviewed by Geoffrey Garen.
In the put_by_val_direct operation, we use JSObject::putDirect.
However, it only accepts non-index property. For index property, we need to use JSObject::putDirectIndex.
This patch changes Identifier::asIndex() to return Optional<uint32_t>.
It forces callers to check the value is index or not explicitly.
Additionally, it checks toString-ed Identifier is index or not to choose putDirect / putDirectIndex.
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFor):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFor):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitDirectPutById):
* dfg/DFGOperations.cpp:
(JSC::DFG::operationPutByValInternal):
* jit/JITOperations.cpp:
* jit/Repatch.cpp:
(JSC::emitPutTransitionStubAndGetOldStructure):
* jsc.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/Arguments.cpp:
(JSC::Arguments::getOwnPropertySlot):
(JSC::Arguments::put):
(JSC::Arguments::deleteProperty):
(JSC::Arguments::defineOwnProperty):
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncSort):
* runtime/JSArray.cpp:
(JSC::JSArray::defineOwnProperty):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
(JSC::JSGenericTypedArrayView<Adaptor>::put):
(JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
(JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
* runtime/JSObject.cpp:
(JSC::JSObject::put):
(JSC::JSObject::putDirectAccessor):
(JSC::JSObject::putDirectCustomAccessor):
(JSC::JSObject::deleteProperty):
(JSC::JSObject::putDirectMayBeIndex):
(JSC::JSObject::defineOwnProperty):
* runtime/JSObject.h:
(JSC::JSObject::getOwnPropertySlot):
(JSC::JSObject::getPropertySlot):
(JSC::JSObject::putDirectInternal):
* runtime/JSString.cpp:
(JSC::JSString::getStringPropertyDescriptor):
* runtime/JSString.h:
(JSC::JSString::getStringPropertySlot):
* runtime/LiteralParser.cpp:
(JSC::LiteralParser<CharType>::parse):
* runtime/PropertyName.h:
(JSC::toUInt32FromCharacters):
(JSC::toUInt32FromStringImpl):
(JSC::PropertyName::asIndex):
* runtime/PropertyNameArray.cpp:
(JSC::PropertyNameArray::add):
* runtime/StringObject.cpp:
(JSC::StringObject::deleteProperty):
* runtime/Structure.cpp:
(JSC::Structure::prototypeChainMayInterceptStoreTo):
2015-01-21 Ryosuke Niwa <rniwa@webkit.org>
Consolidate out arguments of parseFunctionInfo into a struct
https://bugs.webkit.org/show_bug.cgi?id=140754
Reviewed by Oliver Hunt.
Introduced ParserFunctionInfo for storing out arguments of parseFunctionInfo.
* JavaScriptCore.xcodeproj/project.pbxproj:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionExpr):
(JSC::ASTBuilder::createGetterOrSetterProperty): This one takes a property name in addition to
ParserFunctionInfo since the property name and the function name could differ.
(JSC::ASTBuilder::createFuncDeclStatement):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseProperty):
(JSC::Parser<LexerType>::parseMemberExpression):
* parser/Parser.h:
* parser/ParserFunctionInfo.h: Added.
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionExpr):
(JSC::SyntaxChecker::createFuncDeclStatement):
(JSC::SyntaxChecker::createClassDeclStatement):
(JSC::SyntaxChecker::createGetterOrSetterProperty):
2015-01-21 Mark Hahnenberg <mhahnenb@gmail.com>
Change Heap::m_compiledCode to use a Vector
https://bugs.webkit.org/show_bug.cgi?id=140717
Reviewed by Andreas Kling.
Right now it's a DoublyLinkedList, which is iterated during each
collection. This contributes to some of the longish Eden pause times.
A Vector would be more appropriate and would also allow ExecutableBase
to be 2 pointers smaller.
* heap/Heap.cpp:
(JSC::Heap::deleteAllCompiledCode):
(JSC::Heap::deleteAllUnlinkedFunctionCode):
(JSC::Heap::clearUnmarkedExecutables):
* heap/Heap.h:
* runtime/Executable.h: No longer need to inherit from DoublyLinkedListNode.
2015-01-21 Ryosuke Niwa <rniwa@webkit.org>
BytecodeGenerator shouldn't expose all of its member variables
https://bugs.webkit.org/show_bug.cgi?id=140752
Reviewed by Mark Lam.
Added "private:" and removed unused data members as detected by clang.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::lastOpcodeID): Added. Used in BinaryOpNode::emitBytecode.
* bytecompiler/NodesCodegen.cpp:
(JSC::BinaryOpNode::emitBytecode):
2015-01-21 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: ASSERT expanding objects in console PrimitiveBindingTraits<T>::assertValueHasExpectedType
https://bugs.webkit.org/show_bug.cgi?id=140746
Reviewed by Timothy Hatcher.
* inspector/InjectedScriptSource.js:
Do not add impure properties to the descriptor object that will
eventually be sent to the frontend.
2015-01-21 Matthew Mirman <mmirman@apple.com>
Updated split such that it does not include the empty end of input string match.
https://bugs.webkit.org/show_bug.cgi?id=138129
<rdar://problem/18807403>
Reviewed by Filip Pizlo.
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncSplit):
* tests/stress/empty_eos_regex_split.js: Added.
2015-01-21 Michael Saboff <msaboff@apple.com>
Eliminate Scope slot from JavaScript CallFrame
https://bugs.webkit.org/show_bug.cgi?id=136724
Reviewed by Geoffrey Garen.
This finishes the removal of the scope chain slot from the call frame header.
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
* dfg/DFGPreciseLocalClobberize.h:
(JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* ftl/FTLJSCall.cpp:
(JSC::FTL::JSCall::emit):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNativeCallOrConstruct):
(JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct):
* interpreter/JSStack.h:
* interpreter/VMInspector.cpp:
(JSC::VMInspector::dumpFrame):
* jit/JITCall.cpp:
(JSC::JIT::compileOpCall):
* jit/JITCall32_64.cpp:
(JSC::JIT::compileOpCall):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::privateCompileCTINativeCall):
* jit/Repatch.cpp:
(JSC::generateByIdStub):
(JSC::linkClosureCall):
* jit/ThunkGenerators.cpp:
(JSC::virtualForThunkGenerator):
(JSC::nativeForGenerator):
Deleted ScopeChain slot from JSStack. Removed all code where ScopeChain was being
read or set. In most cases this was where we make JS calls.
* interpreter/CallFrameClosure.h:
(JSC::CallFrameClosure::setArgument):
(JSC::CallFrameClosure::resetCallFrame): Deleted.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
(JSC::Interpreter::prepareForRepeatCall):
* interpreter/ProtoCallFrame.cpp:
(JSC::ProtoCallFrame::init):
* interpreter/ProtoCallFrame.h:
(JSC::ProtoCallFrame::scope): Deleted.
(JSC::ProtoCallFrame::setScope): Deleted.
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter64.asm:
Removed the related scopeChainValue member from ProtoCallFrame. Reduced the number of
registers that needed to be copied from the ProtoCallFrame to a callee's frame
from 5 to 4.
* llint/LowLevelInterpreter32_64.asm:
In addition to the prior changes, also deleted the unused macro getDeBruijnScope.
2015-01-21 Michael Saboff <msaboff@apple.com>
Eliminate construct methods from NullGetterFunction and NullSetterFunction classes
https://bugs.webkit.org/show_bug.cgi?id=140708
Reviewed by Mark Lam.
Eliminated construct methods and change getConstructData() for both classes to return
ConstructTypeNone as they can never be called.
* runtime/NullGetterFunction.cpp:
(JSC::NullGetterFunction::getConstructData):
(JSC::constructReturnUndefined): Deleted.
* runtime/NullSetterFunction.cpp:
(JSC::NullSetterFunction::getConstructData):
(JSC::constructReturnUndefined): Deleted.
2015-01-21 Csaba Osztrogonác <ossy@webkit.org>
Remove ENABLE(INSPECTOR) ifdef guards
https://bugs.webkit.org/show_bug.cgi?id=140668
Reviewed by Darin Adler.
* Configurations/FeatureDefines.xcconfig:
* bindings/ScriptValue.cpp:
(Deprecated::ScriptValue::toInspectorValue):
* bindings/ScriptValue.h:
* inspector/ConsoleMessage.cpp:
* inspector/ConsoleMessage.h:
* inspector/ContentSearchUtilities.cpp:
* inspector/ContentSearchUtilities.h:
* inspector/IdentifiersFactory.cpp:
* inspector/IdentifiersFactory.h:
* inspector/InjectedScript.cpp:
* inspector/InjectedScript.h:
* inspector/InjectedScriptBase.cpp:
* inspector/InjectedScriptBase.h:
* inspector/InjectedScriptHost.cpp:
* inspector/InjectedScriptHost.h:
* inspector/InjectedScriptManager.cpp:
* inspector/InjectedScriptManager.h:
* inspector/InjectedScriptModule.cpp:
* inspector/InjectedScriptModule.h:
* inspector/InspectorAgentRegistry.cpp:
* inspector/InspectorBackendDispatcher.cpp:
* inspector/InspectorBackendDispatcher.h:
* inspector/InspectorProtocolTypes.h:
* inspector/JSGlobalObjectConsoleClient.cpp:
* inspector/JSGlobalObjectInspectorController.cpp:
* inspector/JSGlobalObjectInspectorController.h:
* inspector/JSGlobalObjectScriptDebugServer.cpp:
* inspector/JSGlobalObjectScriptDebugServer.h:
* inspector/JSInjectedScriptHost.cpp:
* inspector/JSInjectedScriptHost.h:
* inspector/JSInjectedScriptHostPrototype.cpp:
* inspector/JSInjectedScriptHostPrototype.h:
* inspector/JSJavaScriptCallFrame.cpp:
* inspector/JSJavaScriptCallFrame.h:
* inspector/JSJavaScriptCallFramePrototype.cpp:
* inspector/JSJavaScriptCallFramePrototype.h:
* inspector/JavaScriptCallFrame.cpp:
* inspector/JavaScriptCallFrame.h:
* inspector/ScriptCallFrame.cpp:
(Inspector::ScriptCallFrame::buildInspectorObject):
* inspector/ScriptCallFrame.h:
* inspector/ScriptCallStack.cpp:
(Inspector::ScriptCallStack::buildInspectorArray):
* inspector/ScriptCallStack.h:
* inspector/ScriptDebugServer.cpp:
* inspector/agents/InspectorAgent.cpp:
* inspector/agents/InspectorAgent.h:
* inspector/agents/InspectorConsoleAgent.cpp:
* inspector/agents/InspectorConsoleAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorRuntimeAgent.cpp:
* inspector/agents/InspectorRuntimeAgent.h:
* inspector/agents/JSGlobalObjectConsoleAgent.cpp:
* inspector/agents/JSGlobalObjectConsoleAgent.h:
* inspector/agents/JSGlobalObjectDebuggerAgent.cpp:
* inspector/agents/JSGlobalObjectDebuggerAgent.h:
* inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
* inspector/agents/JSGlobalObjectRuntimeAgent.h:
* inspector/scripts/codegen/cpp_generator_templates.py:
(CppGeneratorTemplates):
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
* runtime/TypeSet.cpp:
(JSC::TypeSet::inspectorTypeSet):
(JSC::StructureShape::inspectorRepresentation):
2015-01-20 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Clean up InjectedScriptSource.js
https://bugs.webkit.org/show_bug.cgi?id=140709
Reviewed by Timothy Hatcher.
This patch includes some relevant Blink patches and small changes.
Patch by <aandrey@chromium.org>
DevTools: Remove console last result $_ on console clear.
https://src.chromium.org/viewvc/blink?revision=179179&view=revision
Patch by <eustas@chromium.org>
[Inspect DOM properties] incorrect CSS Selector Syntax
https://src.chromium.org/viewvc/blink?revision=156903&view=revision
* inspector/InjectedScriptSource.js:
2015-01-20 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Cleanup RuntimeAgent a bit
https://bugs.webkit.org/show_bug.cgi?id=140706
Reviewed by Timothy Hatcher.
* inspector/InjectedScript.h:
* inspector/InspectorBackendDispatcher.h:
* inspector/ScriptCallFrame.cpp:
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::evaluate):
(Inspector::InspectorRuntimeAgent::getProperties):
(Inspector::InspectorRuntimeAgent::run):
(Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
(Inspector::recompileAllJSFunctionsForTypeProfiling):
(Inspector::InspectorRuntimeAgent::setTypeProfilerEnabledState):
2015-01-20 Matthew Mirman <mmirman@apple.com>
Made Identity in the DFG allocate a new temp register and move
the old data to it.
https://bugs.webkit.org/show_bug.cgi?id=140700
<rdar://problem/19339106>
Reviewed by Filip Pizlo.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
Added scratch registers for Identity.
* tests/mozilla/mozilla-tests.yaml: enabled previously failing test
2015-01-20 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Expanding event objects in console shows undefined for most values, it should have real values
https://bugs.webkit.org/show_bug.cgi?id=137306
Reviewed by Timothy Hatcher.
Provide another optional parameter to getProperties, to gather a list
of all own and getter properties.
* inspector/InjectedScript.cpp:
(Inspector::InjectedScript::getProperties):
* inspector/InjectedScript.h:
* inspector/InjectedScriptSource.js:
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::getProperties):
* inspector/agents/InspectorRuntimeAgent.h:
* inspector/protocol/Runtime.json:
2015-01-20 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Should show dynamic specificity values
https://bugs.webkit.org/show_bug.cgi?id=140647
Reviewed by Benjamin Poulain.
* inspector/protocol/CSS.json:
Clarify CSSSelector optional values and add "dynamic" property indicating
if the selector can be dynamic based on the element it is matched against.
2015-01-20 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r178751.
https://bugs.webkit.org/show_bug.cgi?id=140694
Caused 32-bit JSC test failures (Requested by JoePeck on
#webkit).
Reverted changeset:
"put_by_val_direct need to check the property is index or not
for using putDirect / putDirectIndex"
https://bugs.webkit.org/show_bug.cgi?id=140426
http://trac.webkit.org/changeset/178751
2015-01-20 Yusuke Suzuki <utatane.tea@gmail.com>
put_by_val_direct need to check the property is index or not for using putDirect / putDirectIndex
https://bugs.webkit.org/show_bug.cgi?id=140426
Reviewed by Geoffrey Garen.
In the put_by_val_direct operation, we use JSObject::putDirect.
However, it only accepts non-index property. For index property, we need to use JSObject::putDirectIndex.
This patch changes Identifier::asIndex() to return Optional<uint32_t>.
It forces callers to check the value is index or not explicitly.
Additionally, it checks toString-ed Identifier is index or not to choose putDirect / putDirectIndex.
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFor):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFor):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitDirectPutById):
* dfg/DFGOperations.cpp:
(JSC::DFG::operationPutByValInternal):
* jit/JITOperations.cpp:
* jit/Repatch.cpp:
(JSC::emitPutTransitionStubAndGetOldStructure):
* jsc.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/Arguments.cpp:
(JSC::Arguments::getOwnPropertySlot):
(JSC::Arguments::put):
(JSC::Arguments::deleteProperty):
(JSC::Arguments::defineOwnProperty):
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncSort):
* runtime/JSArray.cpp:
(JSC::JSArray::defineOwnProperty):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
(JSC::JSGenericTypedArrayView<Adaptor>::put):
(JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
(JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
* runtime/JSObject.cpp:
(JSC::JSObject::put):
(JSC::JSObject::putDirectAccessor):
(JSC::JSObject::putDirectCustomAccessor):
(JSC::JSObject::deleteProperty):
(JSC::JSObject::putDirectMayBeIndex):
(JSC::JSObject::defineOwnProperty):
* runtime/JSObject.h:
(JSC::JSObject::getOwnPropertySlot):
(JSC::JSObject::getPropertySlot):
(JSC::JSObject::putDirectInternal):
* runtime/JSString.cpp:
(JSC::JSString::getStringPropertyDescriptor):
* runtime/JSString.h:
(JSC::JSString::getStringPropertySlot):
* runtime/LiteralParser.cpp:
(JSC::LiteralParser<CharType>::parse):
* runtime/PropertyName.h:
(JSC::toUInt32FromCharacters):
(JSC::toUInt32FromStringImpl):
(JSC::PropertyName::asIndex):
* runtime/PropertyNameArray.cpp:
(JSC::PropertyNameArray::add):
* runtime/StringObject.cpp:
(JSC::StringObject::deleteProperty):
* runtime/Structure.cpp:
(JSC::Structure::prototypeChainMayInterceptStoreTo):
2015-01-20 Michael Saboff <msaboff@apple.com>
REGRESSION(178696): Sporadic crashes while garbage collecting
https://bugs.webkit.org/show_bug.cgi?id=140688
Reviewed by Geoffrey Garen.
Added missing visitor.append(&thisObject->m_nullSetterFunction).
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::visitChildren):
2015-01-19 Brian J. Burg <burg@cs.washington.edu>
Web Replay: code generator should take supplemental specifications and allow cross-framework references
https://bugs.webkit.org/show_bug.cgi?id=136312
Reviewed by Joseph Pecoraro.
Some types are shared between replay inputs from different frameworks.
Previously, these type declarations were duplicated in every input
specification file in which they were used. This caused some type encoding
traits to be emitted twice if used from WebCore inputs and WebKit2 inputs.
This patch teaches the replay inputs code generator to accept multiple
input specification files. Inputs can freely reference types from other
frameworks without duplicating declarations.
On the code generation side, the model could contain types and inputs from
frameworks that are not the target framework. Only generate code for the
target framework.
To properly generate cross-framework type encoding traits, use
Type.encoding_type_argument in more places, and add the export macro for WebCore
and the Test framework.
Adjust some tests so that enum coverage is preserved by moving the enum types
into "Test" (the target framework for tests).
* JavaScriptCore.vcxproj/copy-files.cmd:
For Windows, copy over JSInputs.json as if it were a private header.
* JavaScriptCore.xcodeproj/project.pbxproj: Make JSInputs.json a private header.
* replay/JSInputs.json:
Put all primitive types and WTF types in this specification file.
* replay/scripts/CodeGeneratorReplayInputs.py:
(Input.__init__):
(InputsModel.__init__): Keep track of the input's framework.
(InputsModel.parse_specification): Parse the framework here. Adjust to new format,
and allow either types or inputs to be missing from a single file.
(InputsModel.parse_type_with_framework):
(InputsModel.parse_input_with_framework):
(Generator.should_generate_item): Added helper method.
(Generator.generate_header): Filter inputs to generate.
(Generator.generate_implementation): Filter inputs to generate.
(Generator.generate_enum_trait_declaration): Filter enums to generate.
Add WEBCORE_EXPORT macro to enum encoding traits.
(Generator.generate_for_each_macro): Filter inputs to generate.
(Generator.generate_enum_trait_implementation): Filter enums to generate.
(generate_from_specifications): Added.
(generate_from_specifications.parse_json_from_file):
(InputsModel.parse_toplevel): Deleted.
(InputsModel.parse_type_with_framework_name): Deleted.
(InputsModel.parse_input): Deleted.
(generate_from_specification): Deleted.
* replay/scripts/CodeGeneratorReplayInputsTemplates.py:
* replay/scripts/tests/expected/fail-on-no-inputs.json-error: Removed.
* replay/scripts/tests/expected/fail-on-no-types.json-error: Removed.
* replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.cpp:
* replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.cpp:
* replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.cpp:
* replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.cpp:
* replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-input-with-guard.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-input-with-vector-members.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-inputs-with-flags.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-memoized-type-modes.json-TestReplayInputs.h:
* replay/scripts/tests/fail-on-c-style-enum-no-storage.json:
* replay/scripts/tests/fail-on-duplicate-enum-type.json:
* replay/scripts/tests/fail-on-duplicate-input-names.json:
* replay/scripts/tests/fail-on-duplicate-type-names.json:
* replay/scripts/tests/fail-on-enum-type-missing-values.json:
* replay/scripts/tests/fail-on-missing-input-member-name.json:
* replay/scripts/tests/fail-on-missing-input-name.json:
* replay/scripts/tests/fail-on-missing-input-queue.json:
* replay/scripts/tests/fail-on-missing-type-mode.json:
* replay/scripts/tests/fail-on-missing-type-name.json:
* replay/scripts/tests/fail-on-no-inputs.json:
Removed, no longer required to be in a single file.
* replay/scripts/tests/fail-on-no-types.json:
Removed, no longer required to be in a single file.
* replay/scripts/tests/fail-on-unknown-input-queue.json:
* replay/scripts/tests/fail-on-unknown-member-type.json:
* replay/scripts/tests/fail-on-unknown-type-mode.json:
* replay/scripts/tests/generate-enum-encoding-helpers-with-guarded-values.json:
* replay/scripts/tests/generate-enum-encoding-helpers.json:
* replay/scripts/tests/generate-enum-with-guard.json:
Include enums that are and are not generated.
* replay/scripts/tests/generate-enums-with-same-base-name.json:
* replay/scripts/tests/generate-event-loop-shape-types.json:
* replay/scripts/tests/generate-input-with-guard.json:
* replay/scripts/tests/generate-input-with-vector-members.json:
* replay/scripts/tests/generate-inputs-with-flags.json:
* replay/scripts/tests/generate-memoized-type-modes.json:
2015-01-20 Tomas Popela <tpopela@redhat.com>
[GTK] Cannot compile 2.7.3 on PowerPC machines
https://bugs.webkit.org/show_bug.cgi?id=140616
Include climits for INT_MAX and wtf/DataLog.h for dataLogF
Reviewed by Csaba Osztrogonác.
* runtime/BasicBlockLocation.cpp:
2015-01-19 Michael Saboff <msaboff@apple.com>
A "cached" null setter should throw a TypeException when called in strict mode and doesn't
https://bugs.webkit.org/show_bug.cgi?id=139418
Reviewed by Filip Pizlo.
Made a new NullSetterFunction class similar to NullGetterFunction. The difference is that
NullSetterFunction will throw a TypeError per the ECMA262 spec for a strict mode caller.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
Added new files NullSetterFunction.cpp and NullSetterFunction.h.
* runtime/GetterSetter.h:
(JSC::GetterSetter::GetterSetter):
(JSC::GetterSetter::isSetterNull):
(JSC::GetterSetter::setSetter):
Change setter instances from using NullGetterFunction to using NullSetterFunction.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::nullSetterFunction):
Added m_nullSetterFunction and accessor.
* runtime/NullSetterFunction.cpp: Added.
(JSC::GetCallerStrictnessFunctor::GetCallerStrictnessFunctor):
(JSC::GetCallerStrictnessFunctor::operator()):
(JSC::GetCallerStrictnessFunctor::callerIsStrict):
(JSC::callerIsStrict):
Method to determine if the caller is in strict mode.
(JSC::callReturnUndefined):
(JSC::constructReturnUndefined):
(JSC::NullSetterFunction::getCallData):
(JSC::NullSetterFunction::getConstructData):
* runtime/NullSetterFunction.h: Added.
(JSC::NullSetterFunction::create):
(JSC::NullSetterFunction::createStructure):
(JSC::NullSetterFunction::NullSetterFunction):
Class with handlers for a null setter.
2015-01-19 Saam Barati <saambarati1@gmail.com>
Web Inspector: Provide a front end for JSC's Control Flow Profiler
https://bugs.webkit.org/show_bug.cgi?id=138454
Reviewed by Timothy Hatcher.
This patch puts the final touches on what JSC needs to provide
for the Web Inspector to show a UI for the control flow profiler.
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::recompileAllJSFunctionsForTypeProfiling):
* runtime/ControlFlowProfiler.cpp:
(JSC::ControlFlowProfiler::getBasicBlocksForSourceID):
* runtime/FunctionHasExecutedCache.cpp:
(JSC::FunctionHasExecutedCache::getFunctionRanges):
(JSC::FunctionHasExecutedCache::getUnexecutedFunctionRanges): Deleted.
* runtime/FunctionHasExecutedCache.h:
2015-01-19 David Kilzer <ddkilzer@apple.com>
[iOS] Only use LLVM static library arguments on 64-bit builds of libllvmForJSC.dylib
<http://webkit.org/b/140658>
Reviewed by Filip Pizlo.
* Configurations/LLVMForJSC.xcconfig: Set OTHER_LDFLAGS_LLVM
only when building for 64-bit architectures.
2015-01-19 Filip Pizlo <fpizlo@apple.com>
ClosureCallStubRoutine no longer needs codeOrigin
https://bugs.webkit.org/show_bug.cgi?id=140659
Reviewed by Michael Saboff.
Once upon a time, we would look for the CodeOrigin associated with a return PC. This search
would start with the CodeBlock according to the caller frame's call frame header. But if the
call was a closure call, the return PC would be inside some closure call stub. So if the
CodeBlock search failed, we would search *all* closure call stub routines to see which one
encompasses the return PC. Then, we would use the CodeOrigin stored in the stub routine
object. This was all a bunch of madness, and we actually got rid of it - we now determine
the CodeOrigin for a call frame using the encoded code origin bits inside the tag of the
argument count.
This patch removes the final vestiges of the madness:
- Remove the totally unused method declaration for the thing that did the closure call stub
search.
- Remove the CodeOrigin field from the ClosureCallStubRoutine. Except for that crazy search
that we no longer do, everyone else who finds a ClosureCallStubRoutine will find it via
the CallLinkInfo. The CallLinkInfo also has the CodeOrigin, so we don't need this field
anymore.
* bytecode/CodeBlock.h:
* jit/ClosureCallStubRoutine.cpp:
(JSC::ClosureCallStubRoutine::ClosureCallStubRoutine):
* jit/ClosureCallStubRoutine.h:
(JSC::ClosureCallStubRoutine::executable):
(JSC::ClosureCallStubRoutine::codeOrigin): Deleted.
* jit/Repatch.cpp:
(JSC::linkClosureCall):
2015-01-19 Saam Barati <saambarati1@gmail.com>
Basic block start offsets should never be larger than end offsets in the control flow profiler
https://bugs.webkit.org/show_bug.cgi?id=140377
Reviewed by Filip Pizlo.
The bytecode generator will emit code more than once for some AST nodes. For instance,
the finally block of TryNode will emit two code paths for its finally block: one for
the normal path, and another for the path where an exception is thrown in the catch block.
This repeated code emission of the same AST node previously broke how the control
flow profiler computed text ranges of basic blocks because when the same AST node
is emitted multiple times, there is a good chance that there are ranges that span
from the end offset of one of these duplicated nodes back to the start offset of
the same duplicated node. This caused a basic block range to report a larger start
offset than end offset. This was incorrect. Now, when this situation is encountered
while linking a CodeBlock, the faulty range in question is ignored.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
* bytecode/CodeBlock.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ForInNode::emitMultiLoopBytecode):
(JSC::ForOfNode::emitBytecode):
(JSC::TryNode::emitBytecode):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseConditionalExpression):
* runtime/ControlFlowProfiler.cpp:
(JSC::ControlFlowProfiler::ControlFlowProfiler):
* runtime/ControlFlowProfiler.h:
(JSC::ControlFlowProfiler::dummyBasicBlock):
2015-01-19 Myles C. Maxfield <mmaxfield@apple.com>
[SVG -> OTF Converter] Flip the switch on
https://bugs.webkit.org/show_bug.cgi?id=140592
Reviewed by Antti Koivisto.
* Configurations/FeatureDefines.xcconfig:
2015-01-19 Brian J. Burg <burg@cs.washington.edu>
Web Replay: convert to is<T> and downcast<T> for decoding replay inputs
https://bugs.webkit.org/show_bug.cgi?id=140512
Reviewed by Chris Dumez.
Generate a SPECIALIZE_TYPE_TRAITS_* chunk of code for each input. This cannot
be done using REPLAY_INPUT_NAMES_FOR_EACH macro since that doesn't fully qualify
input types, and the type traits macro is defined in namespace WTF.
* replay/NondeterministicInput.h: Make overridden methods public.
* replay/scripts/CodeGeneratorReplayInputs.py:
(Generator.generate_header):
(Generator.qualified_input_name): Allow forcing qualification. WTF is never a target framework.
(Generator.generate_input_type_trait_declaration): Added.
* replay/scripts/CodeGeneratorReplayInputsTemplates.py: Add a template.
* replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-input-with-guard.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-input-with-vector-members.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-inputs-with-flags.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-memoized-type-modes.json-TestReplayInputs.h:
2015-01-19 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r178653.
https://bugs.webkit.org/show_bug.cgi?id=140634
Broke multiple SVG tests on Mountain Lion (Requested by ap on
#webkit).
Reverted changeset:
"[SVG -> OTF Converter] Flip the switch on"
https://bugs.webkit.org/show_bug.cgi?id=140592
http://trac.webkit.org/changeset/178653
2015-01-18 Dean Jackson <dino@apple.com>
ES6: Support Array.of construction
https://bugs.webkit.org/show_bug.cgi?id=140605
<rdar://problem/19513655>
Reviewed by Geoffrey Garen.
Add and implementation of Array.of, described in 22.1.2.3 of the ES6
specification (15 Jan 2015). The Array.of() method creates a new Array
instance with a variable number of arguments, regardless of number or type
of the arguments.
* runtime/ArrayConstructor.cpp:
(JSC::arrayConstructorOf): Create a new empty Array, then iterate
over the arguments, setting them to the appropriate index.
2015-01-19 Myles C. Maxfield <mmaxfield@apple.com>
[SVG -> OTF Converter] Flip the switch on
https://bugs.webkit.org/show_bug.cgi?id=140592
Reviewed by Antti Koivisto.
* Configurations/FeatureDefines.xcconfig:
2015-01-17 Brian J. Burg <burg@cs.washington.edu>
Web Inspector: highlight data for overlay should use protocol type builders
https://bugs.webkit.org/show_bug.cgi?id=129441
Reviewed by Timothy Hatcher.
Add a new domain for overlay types.
* CMakeLists.txt:
* DerivedSources.make:
* inspector/protocol/OverlayTypes.json: Added.
2015-01-17 Michael Saboff <msaboff@apple.com>
Crash in JSScope::resolve() on tools.ups.com
https://bugs.webkit.org/show_bug.cgi?id=140579
Reviewed by Geoffrey Garen.
For op_resolve_scope of a global property or variable that needs to check for the var
injection check watchpoint, we need to keep the scope around with a Phantom. The
baseline JIT slowpath for op_resolve_scope needs the scope value if the watchpoint
fired.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
2015-01-16 Brian J. Burg <burg@cs.washington.edu>
Web Inspector: code generator should introduce typedefs for protocol types that are arrays
https://bugs.webkit.org/show_bug.cgi?id=140557
Reviewed by Joseph Pecoraro.
Currently, there is no generated type name for "array" type declarations such as Console.CallStack.
This makes it longwinded and confusing to use the type in C++ code.
This patch adds a typedef for array type declarations, so types such as Console::CallStack
can be referred to directly, rather than using Inspector::Protocol::Array<Console::CallFrame>.
Some tests were updated to cover array type declarations used as parameters and type members.
* inspector/ScriptCallStack.cpp: Use the new typedef.
(Inspector::ScriptCallStack::buildInspectorArray):
* inspector/ScriptCallStack.h:
* inspector/scripts/codegen/cpp_generator.py:
(CppGenerator.cpp_protocol_type_for_type): If an ArrayType is nominal, use the typedef'd name instead.
* inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
(_generate_typedefs_for_domain): Also generate typedefs for array type declarations.
(_generate_typedefs_for_domain.Inspector):
* inspector/scripts/codegen/models.py: Save the name of an ArrayType when it is a type declaration.
(ArrayType.__init__):
(Protocol.resolve_types):
(Protocol.lookup_type_reference):
* inspector/scripts/tests/commands-with-async-attribute.json:
* inspector/scripts/tests/commands-with-optional-call-return-parameters.json:
* inspector/scripts/tests/events-with-optional-parameters.json:
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
* inspector/scripts/tests/type-declaration-object-type.json:
2015-01-16 Brian J. Burg <burg@cs.washington.edu>
Web Replay: purge remaining PassRefPtr uses and minor cleanup
https://bugs.webkit.org/show_bug.cgi?id=140456
Reviewed by Andreas Kling.
Get rid of PassRefPtr. Introduce default initializers where it makes sense.
Remove mistaken uses of AtomicString that were not removed as part of r174113.
* replay/EmptyInputCursor.h:
* replay/InputCursor.h:
(JSC::InputCursor::InputCursor):
2015-01-16 Brian J. Burg <burg@cs.washington.edu>
Web Inspector: code generator should fail on duplicate parameter and member names
https://bugs.webkit.org/show_bug.cgi?id=140555
Reviewed by Timothy Hatcher.
* inspector/scripts/codegen/models.py:
(find_duplicates): Add a helper function to find duplicates in a list.
(Protocol.parse_type_declaration):
(Protocol.parse_command):
(Protocol.parse_event):
* inspector/scripts/tests/expected/fail-on-duplicate-command-call-parameter-names.json-error: Added.
* inspector/scripts/tests/expected/fail-on-duplicate-command-return-parameter-names.json-error: Added.
* inspector/scripts/tests/expected/fail-on-duplicate-event-parameter-names.json-error: Added.
* inspector/scripts/tests/expected/fail-on-duplicate-type-member-names.json-error: Added.
* inspector/scripts/tests/fail-on-duplicate-command-call-parameter-names.json: Added.
* inspector/scripts/tests/fail-on-duplicate-command-return-parameter-names.json: Added.
* inspector/scripts/tests/fail-on-duplicate-event-parameter-names.json: Added.
* inspector/scripts/tests/fail-on-duplicate-type-member-names.json: Added.
2015-01-16 Michael Saboff <msaboff@apple.com>
REGRESSION (r174226): Header on huffingtonpost.com is too large
https://bugs.webkit.org/show_bug.cgi?id=140306
Reviewed by Filip Pizlo.
BytecodeGenerator::willResolveToArguments() is used to check to see if we can use the
arguments register or whether we need to resolve "arguments". If the arguments have
been captured, then they are stored in the lexical environment and the arguments
register is not used.
Changed BytecodeGenerator::willResolveToArguments() to also check to see if the arguments
register is captured. Renamed the function to willResolveToArgumentsRegister() to
better indicate what we are checking.
Aligned 32 and 64 bit paths in ArgumentsRecoveryGenerator::generateFor() for creating
an arguments object that was optimized out of an inlined callFrame. The 32 bit path
incorrectly calculated the location of the reified callee frame. This alignment resulted
in the removal of operationCreateInlinedArgumentsDuringOSRExit()
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::willResolveToArgumentsRegister):
(JSC::BytecodeGenerator::uncheckedLocalArgumentsRegister):
(JSC::BytecodeGenerator::emitCall):
(JSC::BytecodeGenerator::emitConstruct):
(JSC::BytecodeGenerator::emitEnumeration):
(JSC::BytecodeGenerator::willResolveToArguments): Deleted.
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::BracketAccessorNode::emitBytecode):
(JSC::DotAccessorNode::emitBytecode):
(JSC::getArgumentByVal):
(JSC::ApplyFunctionCallDotNode::emitBytecode):
(JSC::ArrayPatternNode::emitDirectBinding):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::ArgumentsRecoveryGenerator::generateFor):
* dfg/DFGOperations.cpp:
(JSC::operationCreateInlinedArgumentsDuringOSRExit): Deleted.
* dfg/DFGOperations.h:
(JSC::operationCreateInlinedArgumentsDuringOSRExit): Deleted.
2015-01-15 Csaba Osztrogonác <ossy@webkit.org>
Remove ENABLE(SQL_DATABASE) guards
https://bugs.webkit.org/show_bug.cgi?id=140434
Reviewed by Darin Adler.
* CMakeLists.txt:
* Configurations/FeatureDefines.xcconfig:
* DerivedSources.make:
* inspector/protocol/Database.json:
2015-01-14 Alexey Proskuryakov <ap@apple.com>
Web Inspector and regular console use different source code locations for messages
https://bugs.webkit.org/show_bug.cgi?id=140478
Reviewed by Brian Burg.
* inspector/ConsoleMessage.h: Expose computed source location.
* inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::addMessageToConsole):
(Inspector::InspectorConsoleAgent::stopTiming):
(Inspector::InspectorConsoleAgent::count):
* inspector/agents/InspectorConsoleAgent.h:
addMessageToConsole() now takes a pre-made ConsoleMessage object.
* inspector/JSGlobalObjectConsoleClient.cpp:
(Inspector::JSGlobalObjectConsoleClient::messageWithTypeAndLevel):
(Inspector::JSGlobalObjectConsoleClient::warnUnimplemented):
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::reportAPIException):
* inspector/agents/JSGlobalObjectDebuggerAgent.cpp:
(Inspector::JSGlobalObjectDebuggerAgent::breakpointActionLog):
Updated for the above changes.
2015-01-15 Mark Lam <mark.lam@apple.com>
[Part 2] Argument object created by "Function dot arguments" should use a clone of argument values.
<https://webkit.org/b/140093>
Reviewed by Geoffrey Garen.
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::createArguments):
- We should not fetching the lexicalEnvironment here. The reason we've
introduced the ClonedArgumentsCreationMode is because the lexicalEnvironment
may not be available to us at this point. Instead, we'll just pass a nullptr.
* runtime/Arguments.cpp:
(JSC::Arguments::tearOffForCloning):
* runtime/Arguments.h:
(JSC::Arguments::finishCreation):
- Use the new tearOffForCloning() to tear off arguments right out of the values
passed on the stack. tearOff() is not appropriate for this purpose because
it takes slowArgumentsData into account.
2015-01-14 Matthew Mirman <mmirman@apple.com>
Removed accidental commit of "invalid_array.js"
http://trac.webkit.org/changeset/178439
* tests/stress/invalid_array.js: Removed.
2015-01-14 Matthew Mirman <mmirman@apple.com>
Fixes operationPutByIdOptimizes such that they check that the put didn't
change the structure of the object who's property access is being
cached. Also removes uses of the new base value from the cache generation code.
https://bugs.webkit.org/show_bug.cgi?id=139500
Reviewed by Filip Pizlo.
* jit/JITOperations.cpp:
(JSC::operationPutByIdStrictOptimize): saved the structure before the put.
(JSC::operationPutByIdNonStrictOptimize): ditto.
(JSC::operationPutByIdDirectStrictOptimize): ditto.
(JSC::operationPutByIdDirectNonStrictOptimize): ditto.
* jit/Repatch.cpp:
(JSC::generateByIdStub):
(JSC::tryCacheGetByID):
(JSC::tryBuildGetByIDList):
(JSC::emitPutReplaceStub):
(JSC::emitPutTransitionStubAndGetOldStructure): Added.
(JSC::tryCachePutByID):
(JSC::repatchPutByID):
(JSC::tryBuildPutByIdList):
(JSC::tryRepatchIn):
(JSC::emitPutTransitionStub): Deleted.
* jit/Repatch.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/JSPropertyNameEnumerator.h:
(JSC::genericPropertyNameEnumerator):
* runtime/Operations.h:
(JSC::normalizePrototypeChainForChainAccess): restructured to not use the base value.
(JSC::normalizePrototypeChain): restructured to not use the base value.
* tests/mozilla/mozilla-tests.yaml:
* tests/stress/proto-setter.js: Added.
* tests/stress/put-by-id-build-list-order-recurse.js: Added.
Added test that fails without this patch.
2015-01-13 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Remove unused ResizeImage and DecodeImageData timeline events
https://bugs.webkit.org/show_bug.cgi?id=140404
Reviewed by Timothy Hatcher.
* inspector/protocol/Timeline.json:
2015-01-13 Yusuke Suzuki <utatane.tea@gmail.com>
DFG can call PutByValDirect for generic arrays
https://bugs.webkit.org/show_bug.cgi?id=140389
Reviewed by Geoffrey Garen.
Computed properties in object initializers (ES6) use the put_by_val_direct operation.
However, current DFG asserts that put_by_val_direct is not used for the generic array,
the assertion failure is raised.
This patch allow DFG to use put_by_val_direct to generic arrays.
And fix the DFG put_by_val_direct implementation for string properties.
At first, put_by_val_direct is inteded to be used for spread elements.
So the property keys were limited to numbers (indexes).
But now, it's also used for computed properties in object initializers.
* dfg/DFGOperations.cpp:
(JSC::DFG::operationPutByValInternal):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
2015-01-13 Geoffrey Garen <ggaren@apple.com>
Out of bounds access in BytecodeGenerator::emitGetById under DotAccessorNode::emitBytecode
https://bugs.webkit.org/show_bug.cgi?id=140397
Reviewed by Geoffrey Garen.
Patch by Alexey Proskuryakov.
Reviewed, performance tested, and ChangeLogged by Geoffrey Garen.
No performance change.
No test, since this is a small past-the-end read, which is very
difficult to turn into a reproducible failing test -- and existing tests
crash reliably using ASan.
* bytecompiler/NodesCodegen.cpp:
(JSC::BracketAccessorNode::emitBytecode):
(JSC::DotAccessorNode::emitBytecode):
(JSC::FunctionCallBracketNode::emitBytecode):
(JSC::PostfixNode::emitResolve):
(JSC::DeleteBracketNode::emitBytecode):
(JSC::DeleteDotNode::emitBytecode):
(JSC::PrefixNode::emitResolve):
(JSC::UnaryOpNode::emitBytecode):
(JSC::BitwiseNotNode::emitBytecode):
(JSC::BinaryOpNode::emitBytecode):
(JSC::EqualNode::emitBytecode):
(JSC::StrictEqualNode::emitBytecode):
(JSC::ThrowableBinaryOpNode::emitBytecode):
(JSC::AssignDotNode::emitBytecode):
(JSC::AssignBracketNode::emitBytecode): Use RefPtr in more places. Any
register used across a call to a function that might allocate a new
temporary register must be held in a RefPtr.
2015-01-12 Michael Saboff <msaboff@apple.com>
Local JSArray* "keys" in objectConstructorKeys() is not marked during garbage collection
https://bugs.webkit.org/show_bug.cgi?id=140348
Reviewed by Mark Lam.
We used to read registers in MachineThreads::gatherFromCurrentThread(), but that is too late
because those registers may have been spilled on the stack and replaced with other values by
the time we call down to gatherFromCurrentThread().
Now we get the register contents at the same place that we demarcate the current top of
stack using the address of a local variable, in Heap::markRoots(). The register contents
buffer is passed along with the demarcation pointer. These need to be done at this level
in the call tree and no lower, as markRoots() calls various functions that visit object
pointers that may be latter proven dead. Any of those pointers that are left on the
stack or in registers could be incorrectly marked as live if we scan the stack contents
from a called function or one of its callees. The stack demarcation pointer and register
saving need to be done in the same function so that we have a consistent stack, active
and spilled registers.
Because we don't want to make unnecessary calls to get the register contents, we use
a macro to allocated, and possibly align, the register structure and get the actual
register contents.
* heap/Heap.cpp:
(JSC::Heap::markRoots):
(JSC::Heap::gatherStackRoots):
* heap/Heap.h:
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::gatherFromCurrentThread):
(JSC::MachineThreads::gatherConservativeRoots):
* heap/MachineStackMarker.h:
2015-01-12 Benjamin Poulain <benjamin@webkit.org>
Add basic pattern matching support to the url filters
https://bugs.webkit.org/show_bug.cgi?id=140283
Reviewed by Andreas Kling.
* JavaScriptCore.xcodeproj/project.pbxproj:
Make YarrParser.h private in order to use it from WebCore.
2015-01-12 Geoffrey Garen <ggaren@apple.com>
Out of bounds read in IdentifierArena::makeIdentifier
https://bugs.webkit.org/show_bug.cgi?id=140376
Patch by Alexey Proskuryakov.
Reviewed and ChangeLogged by Geoffrey Garen.
No test, since this is a small past-the-end read, which is very
difficult to turn into a reproducible failing test -- and existing tests
crash reliably using ASan.
* parser/ParserArena.h:
(JSC::IdentifierArena::makeIdentifier):
(JSC::IdentifierArena::makeIdentifierLCharFromUChar): Check for a
zero-length string input, like we do in the literal parser, since it is
not valid to dereference characters in a zero-length string.
A zero-length string is allowed in JavaScript -- for example, "".
2015-01-11 Sam Weinig <sam@webkit.org>
Remove support for SharedWorkers
https://bugs.webkit.org/show_bug.cgi?id=140344
Reviewed by Anders Carlsson.
* Configurations/FeatureDefines.xcconfig:
2015-01-12 Myles C. Maxfield <mmaxfield@apple.com>
Allow targetting the SVG->OTF font converter with ENABLE(SVG_OTF_CONVERTER)
https://bugs.webkit.org/show_bug.cgi?id=136769
Reviewed by Antti Koivisto.
* Configurations/FeatureDefines.xcconfig:
2015-01-12 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r178266.
https://bugs.webkit.org/show_bug.cgi?id=140363
Broke a JSC test (Requested by ap on #webkit).
Reverted changeset:
"Local JSArray* "keys" in objectConstructorKeys() is not
marked during garbage collection"
https://bugs.webkit.org/show_bug.cgi?id=140348
http://trac.webkit.org/changeset/178266
2015-01-12 Michael Saboff <msaboff@apple.com>
Local JSArray* "keys" in objectConstructorKeys() is not marked during garbage collection
https://bugs.webkit.org/show_bug.cgi?id=140348
Reviewed by Mark Lam.
Move the address of the local variable that is used to demarcate the top of the stack for
conservative roots down to MachineThreads::gatherFromCurrentThread() since it also gets
the register values using setjmp(). That way we don't lose any callee save register
contents between Heap::markRoots(), where it was set, and gatherFromCurrentThread().
If we lose any JSObject* that are only in callee save registers, they will be GC'ed
erroneously.
* heap/Heap.cpp:
(JSC::Heap::markRoots):
(JSC::Heap::gatherStackRoots):
* heap/Heap.h:
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::gatherFromCurrentThread):
(JSC::MachineThreads::gatherConservativeRoots):
* heap/MachineStackMarker.h:
2015-01-11 Eric Carlson <eric.carlson@apple.com>
Fix typo in testate.c error messages
https://bugs.webkit.org/show_bug.cgi?id=140305
Reviewed by Geoffrey Garen.
* API/tests/testapi.c:
(main): "... script did not timed out ..." -> "... script did not time out ..."
2015-01-09 Michael Saboff <msaboff@apple.com>
Breakpoint doesn't fire in this HTML5 game
https://bugs.webkit.org/show_bug.cgi?id=140269
Reviewed by Mark Lam.
When parsing a single line cached function, use the lineStartOffset of the
location where we found the cached function instead of the cached lineStartOffset.
The cache location's lineStartOffset has not been adjusted for any possible
containing functions.
This change is not needed for multi-line cached functions. Consider the
single line source:
function outer(){function inner1(){doStuff();}; (function inner2() {doMoreStuff()})()}
The first parser pass, we parse and cache inner1() and inner2() with a lineStartOffset
of 0. Later when we parse outer() and find inner1() in the cache, SourceCode start
character is at outer()'s outermost open brace. That is what we should use for
lineStartOffset for inner1(). When done parsing inner1() we set the parsing token
to the saved location for inner1(), including the lineStartOffset of 0. We need
to use the value of lineStartOffset before we started parsing inner1(). That is
what the fix does. When we parse inner2() the lineStartOffset will be correct.
For a multi-line function, the close brace is guaranteed to be on a different line
than the open brace. Hence, its lineStartOffset will not change with the change of
the SourceCode start character
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionInfo):
2015-01-09 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Uncaught Exception in ProbeManager deleting breakpoint
https://bugs.webkit.org/show_bug.cgi?id=140279
rdar://problem/19422299
Reviewed by Oliver Hunt.
* runtime/MapData.cpp:
(JSC::MapData::replaceAndPackBackingStore):
The cell table also needs to have its values fixed.
2015-01-09 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Remove or use TimelineAgent Resource related event types
https://bugs.webkit.org/show_bug.cgi?id=140155
Reviewed by Timothy Hatcher.
Remove unused / stale Timeline event types.
* inspector/protocol/Timeline.json:
2015-01-09 Csaba Osztrogonác <ossy@webkit.org>
REGRESSION(r177925): It broke the !ENABLE(INSPECTOR) build
https://bugs.webkit.org/show_bug.cgi?id=140098
Reviewed by Brian Burg.
* inspector/InspectorBackendDispatcher.h: Missing ENABLE(INSPECTOR) guard added.
2015-01-08 Mark Lam <mark.lam@apple.com>
Argument object created by "Function dot arguments" should use a clone of the argument values.
<https://webkit.org/b/140093>
Reviewed by Geoffrey Garen.
After the change in <https://webkit.org/b/139827>, the dfg-tear-off-arguments-not-activation.js
test will crash. The relevant code which manifests the issue is as follows:
function bar() {
return foo.arguments;
}
function foo(p) {
var x = 42;
if (p)
return (function() { return x; });
else
return bar();
}
In this case, foo() has no knowledge of bar() needing its LexicalEnvironment and
has dead code eliminated the SetLocal that stores it into its designated local.
In bar(), the factory for the Arguments object (for creating foo.arguments) tries
to read foo's LexicalEnvironment from its designated lexicalEnvironment local,
but instead, finds it to be uninitialized. This results in a null pointer access
which causes a crash.
This can be resolved by having bar() instantiate a clone of the Arguments object
instead, and populate its elements with values fetched directly from foo's frame.
There's no need to reference foo's LexicalEnvironment (whether present or not).
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::createArguments):
* runtime/Arguments.h:
(JSC::Arguments::finishCreation):
2015-01-08 Mark Lam <mark.lam@apple.com>
Make the LLINT and Baseline JIT's op_create_arguments and op_get_argument_by_val use their lexicalEnvironment operand.
<https://webkit.org/b/140236>
Reviewed by Geoffrey Garen.
Will change the DFG to use the operand on a subsequent pass. For now,
the DFG uses a temporary thunk (operationCreateArgumentsForDFG()) to
retain the old behavior of getting the lexicalEnviroment from the
ExecState.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitGetArgumentByVal):
(JSC::BytecodeGenerator::createArgumentsIfNecessary):
- When the lexicalEnvironment is not available, pass the invalid VirtualRegister
instead of an empty JSValue as the lexicalEnvironment operand.
* dfg/DFGOperations.cpp:
- Use the lexicalEnvironment from the ExecState for now.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
- Use the operationCreateArgumentsForDFG() thunk for now.
* interpreter/CallFrame.cpp:
(JSC::CallFrame::lexicalEnvironmentOrNullptr):
* interpreter/CallFrame.h:
- Added this convenience function to return either the
lexicalEnvironment or a nullptr so that we don't need to do a
conditional check on codeBlock->needsActivation() at multiple sites.
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::createArguments):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_create_arguments):
(JSC::JIT::emitSlow_op_get_argument_by_val):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_create_arguments):
(JSC::JIT::emitSlow_op_get_argument_by_val):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/Arguments.h:
(JSC::Arguments::create):
(JSC::Arguments::finishCreation):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSLexicalEnvironment.cpp:
(JSC::JSLexicalEnvironment::argumentsGetter):
2015-01-08 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Pause Reason Improvements (Breakpoint, Debugger Statement, Pause on Next Statement)
https://bugs.webkit.org/show_bug.cgi?id=138991
Reviewed by Timothy Hatcher.
* debugger/Debugger.cpp:
(JSC::Debugger::Debugger):
(JSC::Debugger::pauseIfNeeded):
(JSC::Debugger::didReachBreakpoint):
When actually pausing, if we hit a breakpoint ensure the reason
is PausedForBreakpoint, otherwise use the current reason.
* debugger/Debugger.h:
Make pause reason and pausing breakpoint ID public.
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::buildAssertPauseReason):
(Inspector::buildCSPViolationPauseReason):
(Inspector::InspectorDebuggerAgent::buildBreakpointPauseReason):
(Inspector::InspectorDebuggerAgent::buildExceptionPauseReason):
(Inspector::InspectorDebuggerAgent::handleConsoleAssert):
(Inspector::buildObjectForBreakpointCookie):
(Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
(Inspector::InspectorDebuggerAgent::removeBreakpoint):
(Inspector::InspectorDebuggerAgent::resolveBreakpoint):
(Inspector::InspectorDebuggerAgent::pause):
(Inspector::InspectorDebuggerAgent::scriptExecutionBlockedByCSP):
(Inspector::InspectorDebuggerAgent::currentCallFrames):
(Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
Clean up creation of pause reason objects and other cleanup
of PassRefPtr use and InjectedScript use.
(Inspector::InspectorDebuggerAgent::didPause):
Clean up so that we first check for an Exception, and then fall
back to including a Pause Reason derived from the Debugger.
* inspector/protocol/Debugger.json:
Add new DebuggerStatement, Breakpoint, and PauseOnNextStatement reasons.
2015-01-08 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Type check NSArray's in ObjC Interfaces have the right object types
https://bugs.webkit.org/show_bug.cgi?id=140209
Reviewed by Timothy Hatcher.
Check the types of objects in NSArrays for all interfaces (commands, events, types)
when the user can set an array of objects. Previously we were only type checking
they were RWIJSONObjects, now we add an explicit check for the exact object type.
* inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
(ObjCConfigurationImplementationGenerator._generate_success_block_for_command):
* inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
(ObjCFrontendDispatcherImplementationGenerator._generate_event):
* inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
(ObjCProtocolTypesImplementationGenerator._generate_init_method_for_required_members):
(ObjCProtocolTypesImplementationGenerator._generate_setter_for_member):
* inspector/scripts/codegen/objc_generator.py:
(ObjCGenerator.objc_class_for_array_type):
(ObjCGenerator):
2015-01-07 Mark Lam <mark.lam@apple.com>
Add the lexicalEnvironment as an operand to op_get_argument_by_val.
<https://webkit.org/b/140233>
Reviewed by Filip Pizlo.
This patch only adds the operand to the bytecode. It is not in use yet.
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitGetArgumentByVal):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2015-01-07 Yusuke Suzuki <utatane.tea@gmail.com>
Investigate the character type of repeated string instead of checking is8Bit flag
https://bugs.webkit.org/show_bug.cgi?id=140139
Reviewed by Darin Adler.
Instead of checking is8Bit flag of the repeated string, investigate
the actual value of the repeated character since i8Bit flag give a false negative case.
* runtime/StringPrototype.cpp:
(JSC::repeatCharacter):
(JSC::stringProtoFuncRepeat):
(JSC::repeatSmallString): Deleted.
2015-01-07 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: ObjC Generate types from the GenericTypes domain
https://bugs.webkit.org/show_bug.cgi?id=140229
Reviewed by Timothy Hatcher.
Generate types from the GenericTypes domain, as they are expected
by other domains (like Page domain). Also, don't include the @protocol
forward declaration for a domain if it doesn't have any commands.
* inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
(ObjCBackendDispatcherHeaderGenerator._generate_objc_forward_declarations):
(ObjCBackendDispatcherHeaderGenerator): Deleted.
(ObjCBackendDispatcherHeaderGenerator._generate_objc_forward_declarations_for_domains): Deleted.
* inspector/scripts/codegen/objc_generator.py:
(ObjCGenerator):
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2015-01-07 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Remove unnecessary copyRef for paramsObject in generated dispatchers
https://bugs.webkit.org/show_bug.cgi?id=140228
Reviewed by Timothy Hatcher.
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
(CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event):
* inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
(ObjCFrontendDispatcherImplementationGenerator._generate_event_out_parameters):
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
2015-01-07 Saam Barati <saambarati1@gmail.com>
interpret op_profile_type in the LLInt instead of unconditionally calling into the slow path
https://bugs.webkit.org/show_bug.cgi?id=140165
Reviewed by Michael Saboff.
Inlining the functionality of TypeProfilerLog::recordTypeInformationForLocation
into the LLInt speeds up type profiling.
* llint/LLIntOffsetsExtractor.cpp:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* runtime/TypeProfilerLog.h:
(JSC::TypeProfilerLog::recordTypeInformationForLocation): Deleted.
2015-01-07 Brian J. Burg <burg@cs.washington.edu>
Web Inspector: purge PassRefPtr from Inspector code and use Ref for typed and untyped protocol objects
https://bugs.webkit.org/show_bug.cgi?id=140053
Reviewed by Andreas Kling.
This patch replaces uses of PassRefPtr with uses of RefPtr&& and WTF::move() in code
related to Web Inspector. It also converts many uses of RefPtr to Ref where
references are always non-null. These two refactorings have been combined since
they tend to require similar changes to the code.
Creation methods for subclasses of InspectorValue now return a Ref, and callsites
have been updated to take a Ref instead of RefPtr.
Builders for typed protocol objects now return a Ref. Since there is no implicit
call to operator&, callsites now must explicitly call .release() to convert a
builder object into the corresponding protocol object once required fields are set.
Update callsites and use auto to eliminate repetition of longwinded protocol types.
Tests for inspector protocol and replay inputs have been rebaselined.
* bindings/ScriptValue.cpp:
(Deprecated::jsToInspectorValue):
(Deprecated::ScriptValue::toInspectorValue):
* bindings/ScriptValue.h:
* inspector/ConsoleMessage.cpp:
(Inspector::ConsoleMessage::addToFrontend):
* inspector/ContentSearchUtilities.cpp:
(Inspector::ContentSearchUtilities::buildObjectForSearchMatch):
(Inspector::ContentSearchUtilities::searchInTextByLines):
* inspector/ContentSearchUtilities.h:
* inspector/InjectedScript.cpp:
(Inspector::InjectedScript::getFunctionDetails):
(Inspector::InjectedScript::getProperties):
(Inspector::InjectedScript::getInternalProperties):
(Inspector::InjectedScript::wrapCallFrames):
(Inspector::InjectedScript::wrapObject):
(Inspector::InjectedScript::wrapTable):
* inspector/InjectedScript.h:
* inspector/InjectedScriptBase.cpp:
(Inspector::InjectedScriptBase::makeEvalCall): Split the early exits.
* inspector/InspectorBackendDispatcher.cpp:
(Inspector::InspectorBackendDispatcher::CallbackBase::CallbackBase):
(Inspector::InspectorBackendDispatcher::CallbackBase::sendIfActive):
(Inspector::InspectorBackendDispatcher::create):
(Inspector::InspectorBackendDispatcher::dispatch):
(Inspector::InspectorBackendDispatcher::sendResponse):
(Inspector::InspectorBackendDispatcher::reportProtocolError):
(Inspector::getPropertyValue): Add a comment to clarify what this clever code does.
(Inspector::InspectorBackendDispatcher::getInteger):
(Inspector::InspectorBackendDispatcher::getDouble):
(Inspector::InspectorBackendDispatcher::getString):
(Inspector::InspectorBackendDispatcher::getBoolean):
(Inspector::InspectorBackendDispatcher::getObject):
(Inspector::InspectorBackendDispatcher::getArray):
(Inspector::InspectorBackendDispatcher::getValue):
* inspector/InspectorBackendDispatcher.h: Use a typed protocol object to collect
protocol error strings.
(Inspector::InspectorSupplementalBackendDispatcher::InspectorSupplementalBackendDispatcher):
Convert the supplemental dispatcher's reference to Ref since it is never null.
* inspector/InspectorEnvironment.h:
* inspector/InspectorProtocolTypes.h: Get rid of ArrayItemHelper and
StructItemTraits. Add more versions of addItem to handle pushing various types.
(Inspector::Protocol::Array::openAccessors):
(Inspector::Protocol::Array::addItem):
(Inspector::Protocol::Array::create):
(Inspector::Protocol::StructItemTraits::push):
(Inspector::Protocol::BindingTraits<Protocol::Array<T>>::runtimeCast): Assert argument.
(Inspector::Protocol::StructItemTraits::pushRefPtr): Deleted.
(Inspector::Protocol::ArrayItemHelper<String>::Traits::pushRaw): Deleted.
(Inspector::Protocol::ArrayItemHelper<int>::Traits::pushRaw): Deleted.
(Inspector::Protocol::ArrayItemHelper<double>::Traits::pushRaw): Deleted.
(Inspector::Protocol::ArrayItemHelper<bool>::Traits::pushRaw): Deleted.
(Inspector::Protocol::ArrayItemHelper<InspectorValue>::Traits::pushRefPtr): Deleted.
(Inspector::Protocol::ArrayItemHelper<InspectorObject>::Traits::pushRefPtr): Deleted.
(Inspector::Protocol::ArrayItemHelper<InspectorArray>::Traits::pushRefPtr): Deleted.
(Inspector::Protocol::ArrayItemHelper<Protocol::Array<T>>::Traits::pushRefPtr): Deleted.
* inspector/InspectorValues.cpp: Straighten out getArray and getObject to have
the same call signature as other getters. Use Ref where possible.
(Inspector::InspectorObjectBase::getBoolean):
(Inspector::InspectorObjectBase::getString):
(Inspector::InspectorObjectBase::getObject):
(Inspector::InspectorObjectBase::getArray):
(Inspector::InspectorObjectBase::getValue):
(Inspector::InspectorObjectBase::writeJSON):
(Inspector::InspectorArrayBase::get):
(Inspector::InspectorObject::create):
(Inspector::InspectorArray::create):
(Inspector::InspectorValue::null):
(Inspector::InspectorString::create):
(Inspector::InspectorBasicValue::create):
(Inspector::InspectorObjectBase::get): Deleted.
* inspector/InspectorValues.h:
(Inspector::InspectorObjectBase::setValue):
(Inspector::InspectorObjectBase::setObject):
(Inspector::InspectorObjectBase::setArray):
(Inspector::InspectorArrayBase::pushValue):
(Inspector::InspectorArrayBase::pushObject):
(Inspector::InspectorArrayBase::pushArray):
* inspector/JSGlobalObjectConsoleClient.cpp:
(Inspector::JSGlobalObjectConsoleClient::messageWithTypeAndLevel):
(Inspector::JSGlobalObjectConsoleClient::count):
(Inspector::JSGlobalObjectConsoleClient::timeEnd):
(Inspector::JSGlobalObjectConsoleClient::timeStamp):
* inspector/JSGlobalObjectConsoleClient.h:
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::executionStopwatch):
* inspector/JSGlobalObjectInspectorController.h:
* inspector/ScriptCallFrame.cpp:
(Inspector::ScriptCallFrame::buildInspectorObject):
* inspector/ScriptCallFrame.h:
* inspector/ScriptCallStack.cpp:
(Inspector::ScriptCallStack::create):
(Inspector::ScriptCallStack::buildInspectorArray):
* inspector/ScriptCallStack.h:
* inspector/agents/InspectorAgent.cpp:
(Inspector::InspectorAgent::enable):
(Inspector::InspectorAgent::inspect):
(Inspector::InspectorAgent::activateExtraDomain):
* inspector/agents/InspectorAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::handleConsoleAssert):
(Inspector::buildObjectForBreakpointCookie):
(Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
(Inspector::InspectorDebuggerAgent::setBreakpoint):
(Inspector::InspectorDebuggerAgent::continueToLocation):
(Inspector::InspectorDebuggerAgent::resolveBreakpoint):
(Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement):
(Inspector::InspectorDebuggerAgent::scriptExecutionBlockedByCSP):
(Inspector::InspectorDebuggerAgent::currentCallFrames):
(Inspector::InspectorDebuggerAgent::didParseSource):
(Inspector::InspectorDebuggerAgent::breakpointActionProbe):
(Inspector::InspectorDebuggerAgent::breakProgram):
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::buildErrorRangeObject):
(Inspector::InspectorRuntimeAgent::callFunctionOn):
(Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
(Inspector::InspectorRuntimeAgent::getBasicBlocks):
* inspector/agents/InspectorRuntimeAgent.h:
* inspector/scripts/codegen/cpp_generator.py:
(CppGenerator.cpp_type_for_unchecked_formal_in_parameter):
(CppGenerator.cpp_type_for_type_with_name):
(CppGenerator.cpp_type_for_formal_async_parameter):
(CppGenerator.should_use_references_for_type):
(CppGenerator):
* inspector/scripts/codegen/cpp_generator_templates.py:
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
(CppBackendDispatcherHeaderGenerator.generate_output):
(CppBackendDispatcherHeaderGenerator._generate_async_handler_declaration_for_command):
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
(CppBackendDispatcherImplementationGenerator._generate_small_dispatcher_switch_implementation_for_domain):
(CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
(CppFrontendDispatcherHeaderGenerator.generate_output):
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
(CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event):
* inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
(CppProtocolTypesHeaderGenerator.generate_output):
(_generate_class_for_object_declaration):
(_generate_unchecked_setter_for_member):
(_generate_forward_declarations_for_binding_traits):
* inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
(ObjCConfigurationImplementationGenerator._generate_success_block_for_command):
* inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
(ObjCFrontendDispatcherImplementationGenerator._generate_event):
(ObjCFrontendDispatcherImplementationGenerator._generate_event_out_parameters):
* inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
(ObjCProtocolTypesImplementationGenerator.generate_output):
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
* replay/EncodedValue.cpp:
(JSC::EncodedValue::asObject):
(JSC::EncodedValue::asArray):
(JSC::EncodedValue::put<EncodedValue>):
(JSC::EncodedValue::append<EncodedValue>):
(JSC::EncodedValue::get<EncodedValue>):
* replay/EncodedValue.h:
* replay/scripts/CodeGeneratorReplayInputs.py:
(Type.borrow_type):
(Type.argument_type):
(Generator.generate_member_move_expression):
* runtime/ConsoleClient.cpp:
(JSC::ConsoleClient::printConsoleMessageWithArguments):
(JSC::ConsoleClient::internalMessageWithTypeAndLevel):
(JSC::ConsoleClient::logWithLevel):
(JSC::ConsoleClient::clear):
(JSC::ConsoleClient::dir):
(JSC::ConsoleClient::dirXML):
(JSC::ConsoleClient::table):
(JSC::ConsoleClient::trace):
(JSC::ConsoleClient::assertCondition):
(JSC::ConsoleClient::group):
(JSC::ConsoleClient::groupCollapsed):
(JSC::ConsoleClient::groupEnd):
* runtime/ConsoleClient.h:
* runtime/TypeSet.cpp:
(JSC::TypeSet::allStructureRepresentations):
(JSC::TypeSet::inspectorTypeSet):
(JSC::StructureShape::inspectorRepresentation):
* runtime/TypeSet.h:
2015-01-07 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r178039.
https://bugs.webkit.org/show_bug.cgi?id=140187
Breaks ObjC Inspector Protocol (Requested by JoePeck on
#webkit).
Reverted changeset:
"Web Inspector: purge PassRefPtr from Inspector code and use
Ref for typed and untyped protocol objects"
https://bugs.webkit.org/show_bug.cgi?id=140053
http://trac.webkit.org/changeset/178039
2015-01-06 Brian J. Burg <burg@cs.washington.edu>
Web Inspector: purge PassRefPtr from Inspector code and use Ref for typed and untyped protocol objects
https://bugs.webkit.org/show_bug.cgi?id=140053
Reviewed by Andreas Kling.
This patch replaces uses of PassRefPtr with uses of RefPtr&& and WTF::move() in code
related to Web Inspector. It also converts many uses of RefPtr to Ref where
references are always non-null. These two refactorings have been combined since
they tend to require similar changes to the code.
Creation methods for subclasses of InspectorValue now return a Ref, and callsites
have been updated to take a Ref instead of RefPtr.
Builders for typed protocol objects now return a Ref. Since there is no implicit
call to operator&, callsites now must explicitly call .release() to convert a
builder object into the corresponding protocol object once required fields are set.
Update callsites and use auto to eliminate repetition of longwinded protocol types.
Tests for inspector protocol and replay inputs have been rebaselined.
* bindings/ScriptValue.cpp:
(Deprecated::jsToInspectorValue):
(Deprecated::ScriptValue::toInspectorValue):
* bindings/ScriptValue.h:
* inspector/ConsoleMessage.cpp:
(Inspector::ConsoleMessage::addToFrontend):
* inspector/ContentSearchUtilities.cpp:
(Inspector::ContentSearchUtilities::buildObjectForSearchMatch):
(Inspector::ContentSearchUtilities::searchInTextByLines):
* inspector/ContentSearchUtilities.h:
* inspector/InjectedScript.cpp:
(Inspector::InjectedScript::getFunctionDetails):
(Inspector::InjectedScript::getProperties):
(Inspector::InjectedScript::getInternalProperties):
(Inspector::InjectedScript::wrapCallFrames):
(Inspector::InjectedScript::wrapObject):
(Inspector::InjectedScript::wrapTable):
* inspector/InjectedScript.h:
* inspector/InjectedScriptBase.cpp:
(Inspector::InjectedScriptBase::makeEvalCall): Split the early exits.
* inspector/InspectorBackendDispatcher.cpp:
(Inspector::InspectorBackendDispatcher::CallbackBase::CallbackBase):
(Inspector::InspectorBackendDispatcher::CallbackBase::sendIfActive):
(Inspector::InspectorBackendDispatcher::create):
(Inspector::InspectorBackendDispatcher::dispatch):
(Inspector::InspectorBackendDispatcher::sendResponse):
(Inspector::InspectorBackendDispatcher::reportProtocolError):
(Inspector::getPropertyValue): Add a comment to clarify what this clever code does.
(Inspector::InspectorBackendDispatcher::getInteger):
(Inspector::InspectorBackendDispatcher::getDouble):
(Inspector::InspectorBackendDispatcher::getString):
(Inspector::InspectorBackendDispatcher::getBoolean):
(Inspector::InspectorBackendDispatcher::getObject):
(Inspector::InspectorBackendDispatcher::getArray):
(Inspector::InspectorBackendDispatcher::getValue):
* inspector/InspectorBackendDispatcher.h: Use a typed protocol object to collect
protocol error strings.
(Inspector::InspectorSupplementalBackendDispatcher::InspectorSupplementalBackendDispatcher):
Convert the supplemental dispatcher's reference to Ref since it is never null.
* inspector/InspectorEnvironment.h:
* inspector/InspectorProtocolTypes.h: Get rid of ArrayItemHelper and
StructItemTraits. Add more versions of addItem to handle pushing various types.
(Inspector::Protocol::Array::openAccessors):
(Inspector::Protocol::Array::addItem):
(Inspector::Protocol::Array::create):
(Inspector::Protocol::StructItemTraits::push):
(Inspector::Protocol::BindingTraits<Protocol::Array<T>>::runtimeCast): Assert argument.
(Inspector::Protocol::StructItemTraits::pushRefPtr): Deleted.
(Inspector::Protocol::ArrayItemHelper<String>::Traits::pushRaw): Deleted.
(Inspector::Protocol::ArrayItemHelper<int>::Traits::pushRaw): Deleted.
(Inspector::Protocol::ArrayItemHelper<double>::Traits::pushRaw): Deleted.
(Inspector::Protocol::ArrayItemHelper<bool>::Traits::pushRaw): Deleted.
(Inspector::Protocol::ArrayItemHelper<InspectorValue>::Traits::pushRefPtr): Deleted.
(Inspector::Protocol::ArrayItemHelper<InspectorObject>::Traits::pushRefPtr): Deleted.
(Inspector::Protocol::ArrayItemHelper<InspectorArray>::Traits::pushRefPtr): Deleted.
(Inspector::Protocol::ArrayItemHelper<Protocol::Array<T>>::Traits::pushRefPtr): Deleted.
* inspector/InspectorValues.cpp: Straighten out getArray and getObject to have
the same call signature as other getters. Use Ref where possible.
(Inspector::InspectorObjectBase::getBoolean):
(Inspector::InspectorObjectBase::getString):
(Inspector::InspectorObjectBase::getObject):
(Inspector::InspectorObjectBase::getArray):
(Inspector::InspectorObjectBase::getValue):
(Inspector::InspectorObjectBase::writeJSON):
(Inspector::InspectorArrayBase::get):
(Inspector::InspectorObject::create):
(Inspector::InspectorArray::create):
(Inspector::InspectorValue::null):
(Inspector::InspectorString::create):
(Inspector::InspectorBasicValue::create):
(Inspector::InspectorObjectBase::get): Deleted.
* inspector/InspectorValues.h:
(Inspector::InspectorObjectBase::setValue):
(Inspector::InspectorObjectBase::setObject):
(Inspector::InspectorObjectBase::setArray):
(Inspector::InspectorArrayBase::pushValue):
(Inspector::InspectorArrayBase::pushObject):
(Inspector::InspectorArrayBase::pushArray):
* inspector/JSGlobalObjectConsoleClient.cpp:
(Inspector::JSGlobalObjectConsoleClient::messageWithTypeAndLevel):
(Inspector::JSGlobalObjectConsoleClient::count):
(Inspector::JSGlobalObjectConsoleClient::timeEnd):
(Inspector::JSGlobalObjectConsoleClient::timeStamp):
* inspector/JSGlobalObjectConsoleClient.h:
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::executionStopwatch):
* inspector/JSGlobalObjectInspectorController.h:
* inspector/ScriptCallFrame.cpp:
(Inspector::ScriptCallFrame::buildInspectorObject):
* inspector/ScriptCallFrame.h:
* inspector/ScriptCallStack.cpp:
(Inspector::ScriptCallStack::create):
(Inspector::ScriptCallStack::buildInspectorArray):
* inspector/ScriptCallStack.h:
* inspector/agents/InspectorAgent.cpp:
(Inspector::InspectorAgent::enable):
(Inspector::InspectorAgent::inspect):
(Inspector::InspectorAgent::activateExtraDomain):
* inspector/agents/InspectorAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::handleConsoleAssert):
(Inspector::buildObjectForBreakpointCookie):
(Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
(Inspector::InspectorDebuggerAgent::setBreakpoint):
(Inspector::InspectorDebuggerAgent::continueToLocation):
(Inspector::InspectorDebuggerAgent::resolveBreakpoint):
(Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement):
(Inspector::InspectorDebuggerAgent::scriptExecutionBlockedByCSP):
(Inspector::InspectorDebuggerAgent::currentCallFrames):
(Inspector::InspectorDebuggerAgent::didParseSource):
(Inspector::InspectorDebuggerAgent::breakpointActionProbe):
(Inspector::InspectorDebuggerAgent::breakProgram):
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::buildErrorRangeObject):
(Inspector::InspectorRuntimeAgent::callFunctionOn):
(Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
(Inspector::InspectorRuntimeAgent::getBasicBlocks):
* inspector/agents/InspectorRuntimeAgent.h:
* inspector/scripts/codegen/cpp_generator.py:
(CppGenerator.cpp_type_for_unchecked_formal_in_parameter):
(CppGenerator.cpp_type_for_type_with_name):
(CppGenerator.cpp_type_for_formal_async_parameter):
(CppGenerator.should_use_references_for_type):
(CppGenerator):
* inspector/scripts/codegen/cpp_generator_templates.py:
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
(CppBackendDispatcherHeaderGenerator.generate_output):
(CppBackendDispatcherHeaderGenerator._generate_async_handler_declaration_for_command):
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
(CppBackendDispatcherImplementationGenerator._generate_small_dispatcher_switch_implementation_for_domain):
(CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
(CppFrontendDispatcherHeaderGenerator.generate_output):
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
(CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event):
* inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
(CppProtocolTypesHeaderGenerator.generate_output):
(_generate_class_for_object_declaration):
(_generate_unchecked_setter_for_member):
(_generate_forward_declarations_for_binding_traits):
* inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
(ObjCConfigurationImplementationGenerator._generate_success_block_for_command):
* inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
(ObjCFrontendDispatcherImplementationGenerator._generate_event):
(ObjCFrontendDispatcherImplementationGenerator._generate_event_out_parameters):
* inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
(ObjCProtocolTypesImplementationGenerator.generate_output):
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
* replay/EncodedValue.cpp:
(JSC::EncodedValue::asObject):
(JSC::EncodedValue::asArray):
(JSC::EncodedValue::put<EncodedValue>):
(JSC::EncodedValue::append<EncodedValue>):
(JSC::EncodedValue::get<EncodedValue>):
* replay/EncodedValue.h:
* replay/scripts/CodeGeneratorReplayInputs.py:
(Type.borrow_type):
(Type.argument_type):
(Generator.generate_member_move_expression):
* runtime/ConsoleClient.cpp:
(JSC::ConsoleClient::printConsoleMessageWithArguments):
(JSC::ConsoleClient::internalMessageWithTypeAndLevel):
(JSC::ConsoleClient::logWithLevel):
(JSC::ConsoleClient::clear):
(JSC::ConsoleClient::dir):
(JSC::ConsoleClient::dirXML):
(JSC::ConsoleClient::table):
(JSC::ConsoleClient::trace):
(JSC::ConsoleClient::assertCondition):
(JSC::ConsoleClient::group):
(JSC::ConsoleClient::groupCollapsed):
(JSC::ConsoleClient::groupEnd):
* runtime/ConsoleClient.h:
* runtime/TypeSet.cpp:
(JSC::TypeSet::allStructureRepresentations):
(JSC::TypeSet::inspectorTypeSet):
(JSC::StructureShape::inspectorRepresentation):
* runtime/TypeSet.h:
2015-01-06 Chris Dumez <cdumez@apple.com>
Drop ResourceResponseBase::connectionID and connectionReused members
https://bugs.webkit.org/show_bug.cgi?id=140158
Reviewed by Sam Weinig.
Drop ResourceResponseBase::connectionID and connectionReused members.
Those were needed by the Chromium port but are no longer used.
* inspector/protocol/Network.json:
2015-01-06 Mark Lam <mark.lam@apple.com>
Add the lexicalEnvironment as an operand to op_create_arguments.
<https://webkit.org/b/140148>
Reviewed by Geoffrey Garen.
This patch only adds the operand to the bytecode. It is not in use yet.
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::createArgumentsIfNecessary):
- Adds the lexicalEnvironment register (if present) as an operand to
op_create_arguments. Else, adds a constant empty JSValue.
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2015-01-06 Alexey Proskuryakov <ap@apple.com>
ADDRESS_SANITIZER macro is overloaded
https://bugs.webkit.org/show_bug.cgi?id=140130
Reviewed by Anders Carlsson.
* interpreter/JSStack.cpp: (JSC::JSStack::sanitizeStack): Use the new macro.
This code is nearly unused (only compiled in when JIT is disabled at build time),
however I've been told that it's best to keep it.
2015-01-06 Mark Lam <mark.lam@apple.com>
Fix Use details for op_create_arguments.
<https://webkit.org/b/140110>
Rubber stamped by Filip Pizlo.
The previous patch was wrong about op_create_arguments not using its 1st operand.
It does read from it (hence, used) to check if the Arguments object has already
been created or not. This patch reverts the change for op_create_arguments.
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
2015-01-06 Mark Lam <mark.lam@apple.com>
Fix Use details for op_create_lexical_environment and op_create_arguments.
<https://webkit.org/b/140110>
Reviewed by Filip Pizlo.
The current "Use" details for op_create_lexical_environment and
op_create_arguments are wrong. op_create_argument uses nothing instead of the
1st operand (the output local). op_create_lexical_environment uses its 2nd
operand (the scope chain) instead of the 1st (the output local).
This patch fixes them to specify the proper uses.
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
2015-01-06 Yusuke Suzuki <utatane.tea@gmail.com>
Implement ES6 String.prototype.repeat(count)
https://bugs.webkit.org/show_bug.cgi?id=140047
Reviewed by Darin Adler.
Introducing ES6 String.prototype.repeat(count) function.
* runtime/JSString.h:
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
(JSC::repeatSmallString):
(JSC::stringProtoFuncRepeat):
2015-01-03 Michael Saboff <msaboff@apple.com>
Crash in operationNewFunction when scrolling on Google+
https://bugs.webkit.org/show_bug.cgi?id=140033
Reviewed by Oliver Hunt.
In DFG code, the scope register can be eliminated because all uses have been
dead code eliminated. In the case where one of the uses was creating a function
that is never used, the baseline code will still create the function. If we OSR
exit to a path where that function gets created, check the scope register value
and set the new, but dead, function to undefined instead of creating a new function.
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_new_func_exp):
2015-01-01 Yusuke Suzuki <utatane.tea@gmail.com>
String includes methods perform toString on searchString before toInt32 on a offset
https://bugs.webkit.org/show_bug.cgi?id=140031
Reviewed by Darin Adler.
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncStartsWith):
(JSC::stringProtoFuncEndsWith):
(JSC::stringProtoFuncIncludes):
2015-01-01 Gyuyoung Kim <gyuyoung.kim@samsung.com>
Change to return std::unique_ptr<> in fooCreate()
https://bugs.webkit.org/show_bug.cgi?id=139983
Reviewed by Darin Adler.
To avoid unnecessary std::unique_ptr<> casting, fooCreate() returns std::unique_ptr<> directly.
* create_regex_tables:
* yarr/YarrPattern.h:
(JSC::Yarr::YarrPattern::reset):
(JSC::Yarr::YarrPattern::newlineCharacterClass):
(JSC::Yarr::YarrPattern::digitsCharacterClass):
(JSC::Yarr::YarrPattern::spacesCharacterClass):
(JSC::Yarr::YarrPattern::wordcharCharacterClass):
(JSC::Yarr::YarrPattern::nondigitsCharacterClass):
(JSC::Yarr::YarrPattern::nonspacesCharacterClass):
(JSC::Yarr::YarrPattern::nonwordcharCharacterClass):
2015-01-01 Jeff Miller <jeffm@apple.com>
Update user-visible copyright strings to include 2015
https://bugs.webkit.org/show_bug.cgi?id=139880
Reviewed by Darin Adler.
* Info.plist:
2015-01-01 Darin Adler <darin@apple.com>
We often misspell identifier as "identifer"
https://bugs.webkit.org/show_bug.cgi?id=140025
Reviewed by Michael Saboff.
* runtime/ArrayConventions.h: Fix it.
2014-12-29 Gyuyoung Kim <gyuyoung.kim@samsung.com>
Move JavaScriptCore/yarr to std::unique_ptr
https://bugs.webkit.org/show_bug.cgi?id=139621
Reviewed by Anders Carlsson.
Final clean up OwnPtr|PassOwnPtr in JavaScriptCore/yarr.
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::ByteCompiler::atomParenthesesSubpatternEnd):
* yarr/YarrInterpreter.h:
(JSC::Yarr::BytecodePattern::BytecodePattern):
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::opCompileParenthesesSubpattern):
(JSC::Yarr::YarrGenerator::opCompileParentheticalAssertion):
(JSC::Yarr::YarrGenerator::opCompileBody):
* yarr/YarrPattern.cpp:
(JSC::Yarr::CharacterClassConstructor::charClass):
(JSC::Yarr::YarrPatternConstructor::YarrPatternConstructor):
(JSC::Yarr::YarrPatternConstructor::reset):
(JSC::Yarr::YarrPatternConstructor::atomPatternCharacter):
(JSC::Yarr::YarrPatternConstructor::atomCharacterClassEnd):
(JSC::Yarr::YarrPatternConstructor::atomParenthesesSubpatternBegin):
(JSC::Yarr::YarrPatternConstructor::atomParentheticalAssertionBegin):
(JSC::Yarr::YarrPatternConstructor::copyDisjunction):
(JSC::Yarr::YarrPatternConstructor::checkForTerminalParentheses):
(JSC::Yarr::YarrPatternConstructor::optimizeDotStarWrappedExpressions):
* yarr/YarrPattern.h:
(JSC::Yarr::PatternDisjunction::addNewAlternative):
(JSC::Yarr::YarrPattern::newlineCharacterClass):
(JSC::Yarr::YarrPattern::digitsCharacterClass):
(JSC::Yarr::YarrPattern::spacesCharacterClass):
(JSC::Yarr::YarrPattern::wordcharCharacterClass):
(JSC::Yarr::YarrPattern::nondigitsCharacterClass):
(JSC::Yarr::YarrPattern::nonspacesCharacterClass):
(JSC::Yarr::YarrPattern::nonwordcharCharacterClass):
2014-12-26 Dan Bernstein <mitz@apple.com>
<rdar://problem/19348208> REGRESSION (r177027): iOS builds use the wrong toolchain
https://bugs.webkit.org/show_bug.cgi?id=139950
Reviewed by David Kilzer.
* Configurations/Base.xcconfig: Only define TOOLCHAINS when building for OS X, doing so
in a manner that works with Xcode 5.1.1.
2014-12-22 Mark Lam <mark.lam@apple.com>
Use ctiPatchCallByReturnAddress() in JITOperations.cpp.
<https://webkit.org/b/139892>
Reviewed by Michael Saboff.
The code in JITOperations.cpp sometimes calls RepatchBuffer::relinkCallerToFunction()
directly, and sometimes uses a helper function, ctiPatchCallByReturnAddress().
This patch changes it to use the helper function consistently.
* jit/JITOperations.cpp:
2014-12-22 Mark Lam <mark.lam@apple.com>
Fix some typos in a comment.
<https://webkit.org/b/139882>
Reviewed by Michael Saboff.
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_get_by_val):
2014-12-22 Mark Lam <mark.lam@apple.com>
Assert that Array elements not copied when changing shape to ArrayStorage type are indeed holes.
<https://webkit.org/b/138118>
Reviewed by Michael Saboff.
* runtime/JSObject.cpp:
(JSC::JSObject::convertInt32ToArrayStorage):
(JSC::JSObject::convertDoubleToArrayStorage):
(JSC::JSObject::convertContiguousToArrayStorage):
2014-12-20 Eric Carlson <eric.carlson@apple.com>
[iOS] add optimized fullscreen API
https://bugs.webkit.org/show_bug.cgi?id=139833
<rdar://problem/18844486>
Reviewed by Simon Fraser.
* Configurations/FeatureDefines.xcconfig: Add ENABLE_VIDEO_PRESENTATION_MODE.
2014-12-20 David Kilzer <ddkilzer@apple.com>
Switch from using PLATFORM_NAME to SDK selectors in WebCore, WebInspectorUI, WebKit, WebKit2
<http://webkit.org/b/139463>
Reviewed by Mark Rowe.
* Configurations/JavaScriptCore.xcconfig:
- Simplify SECTORDER_FLAGS.
2014-12-19 Andreas Kling <akling@apple.com>
Plug leak below LLVMCopyStringRepOfTargetData().
<https://webkit.org/b/139832>
Reviewed by Michael Saboff.
LLVMCopyStringRepOfTargetData() returns a strdup()'ed string, so make sure
to free() it after we're done using it.
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
2014-12-19 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: CRASH inspector-protocol/debugger/breakpoint-action-detach.html
https://bugs.webkit.org/show_bug.cgi?id=139797
Reviewed by Mark Lam.
* debugger/Debugger.h:
* debugger/Debugger.cpp:
(JSC::Debugger::isAttached):
Check if we are the debugger for a particular global object.
(JSC::Debugger::pauseIfNeeded):
Pass the global object on when hitting a brekapoint.
* inspector/ScriptDebugServer.h:
* inspector/ScriptDebugServer.cpp:
(Inspector::ScriptDebugServer::handleBreakpointHit):
Stop evaluting breakpoint actions if a previous action caused the
debugger to detach from this global object.
(Inspector::ScriptDebugServer::handlePause):
Standardize on passing JSGlobalObject parameter first.
2014-12-19 Mark Lam <mark.lam@apple.com>
[Win] Endless compiler warnings created by DFGEdge.h.
<https://webkit.org/b/139801>
Reviewed by Brent Fulgham.
Add a cast to fix the type just the way the 64-bit version does.
* dfg/DFGEdge.h:
(JSC::DFG::Edge::makeWord):
2014-12-19 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r177574.
https://bugs.webkit.org/show_bug.cgi?id=139821
"Broke Production builds by installing
libWebCoreTestSupport.dylib in the wrong directory" (Requested
by ddkilzer on #webkit).
Reverted changeset:
"Switch from using PLATFORM_NAME to SDK selectors in WebCore,
WebInspectorUI, WebKit, WebKit2"
https://bugs.webkit.org/show_bug.cgi?id=139463
http://trac.webkit.org/changeset/177574
2014-12-19 Michael Saboff <msaboff@apple.com>
REGRESSION(174226): Captured arguments in a using function compiled by the DFG have the initial value when the closure was invoked
https://bugs.webkit.org/show_bug.cgi?id=139808
Reviewed by Oliver Hunt.
There are three changes here.
1) Create a VariableWatchpointSet for captured arguments variables.
2) Properly use the VariableWatchpointSet* found in op_put_to_scope in the 64 bit LLInt code.
3) Add the same putLocalClosureVar path to the 32 bit LLInt code that exists in the 64 bit version.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2014-12-19 David Kilzer <ddkilzer@apple.com>
Switch from using PLATFORM_NAME to SDK selectors in WebCore, WebInspectorUI, WebKit, WebKit2
<http://webkit.org/b/139463>
Reviewed by Mark Rowe.
* Configurations/JavaScriptCore.xcconfig:
- Simplify SECTORDER_FLAGS.
2014-12-18 Brent Fulgham <bfulgham@apple.com>
Unreviewed build fix.
* jsc.cpp: Remove typo.
2014-12-17 Michael Saboff <msaboff@apple.com>
Tests with infinite recursion frequently crash
https://bugs.webkit.org/show_bug.cgi?id=139548
Reviewed by Geoffrey Garen.
While unwinding, if the call frame doesn't have a codeblock, then we
are in native code, handle appropriately.
* interpreter/Interpreter.cpp:
(JSC::unwindCallFrame):
(JSC::UnwindFunctor::operator()):
Added checks for null CodeBlock.
(JSC::Interpreter::unwind): Removed wrong ASSERT.
2014-12-17 Chris Dumez <cdumez@apple.com>
[iOS] Make it possible to toggle FeatureCounter support at runtime
https://bugs.webkit.org/show_bug.cgi?id=139688
<rdar://problem/19266254>
Reviewed by Andreas Kling.
Stop linking against AppSupport framework as the functionality is no
longer in WTF (it was moved to WebCore).
* Configurations/JavaScriptCore.xcconfig:
2014-12-17 Brent Fulgham <bfulgham@apple.com>
[Win] Correct DebugSuffix builds under MSBuild
https://bugs.webkit.org/show_bug.cgi?id=139733
<rdar://problem/19276880>
Reviewed by Simon Fraser.
* JavaScriptCore.vcxproj/JavaScriptCore.proj: Make sure to use the
'_debug' suffix when building the DebugSuffix target.
2014-12-16 Enrica Casucci <enrica@apple.com>
Fix iOS builders for 8.0
https://bugs.webkit.org/show_bug.cgi?id=139495
Reviewed by Michael Saboff.
* Configurations/LLVMForJSC.xcconfig:
* llvm/library/LLVMExports.cpp:
(initializeAndGetJSCLLVMAPI):
2014-12-16 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r177380.
https://bugs.webkit.org/show_bug.cgi?id=139707
"Breaks js/regres/elidable-new-object-* tests" (Requested by
msaboff_ on #webkit).
Reverted changeset:
"Fixes operationPutByIdOptimizes such that they check that the
put didn't"
https://bugs.webkit.org/show_bug.cgi?id=139500
http://trac.webkit.org/changeset/177380
2014-12-16 Matthew Mirman <mmirman@apple.com>
Fixes operationPutByIdOptimizes such that they check that the put didn't
change the structure of the object who's property access is being
cached.
https://bugs.webkit.org/show_bug.cgi?id=139500
Reviewed by Geoffrey Garen.
* jit/JITOperations.cpp:
(JSC::operationPutByIdStrictOptimize): saved the structure before the put.
(JSC::operationPutByIdNonStrictOptimize): ditto.
(JSC::operationPutByIdDirectStrictOptimize): ditto.
(JSC::operationPutByIdDirectNonStrictOptimize): ditto.
* jit/Repatch.cpp:
(JSC::tryCachePutByID): Added argument for the old structure
(JSC::repatchPutByID): Added argument for the old structure
* jit/Repatch.h:
* tests/stress/put-by-id-build-list-order-recurse.js:
Added test that fails without this patch.
2014-12-15 Chris Dumez <cdumez@apple.com>
[iOS] Add feature counting support
https://bugs.webkit.org/show_bug.cgi?id=139652
<rdar://problem/19255690>
Reviewed by Gavin Barraclough.
Link against AppSupport framework on iOS as we need it to implement
the new FeatureCounter API in WTF.
* Configurations/JavaScriptCore.xcconfig:
2014-12-15 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r177284.
https://bugs.webkit.org/show_bug.cgi?id=139658
"Breaks API tests and LayoutTests on Yosemite Debug"
(Requested by msaboff on #webkit).
Reverted changeset:
"Make sure range based iteration of Vector<> still receives
bounds checking"
https://bugs.webkit.org/show_bug.cgi?id=138821
http://trac.webkit.org/changeset/177284
2014-12-15 Dániel Bátyai <dbatyai.u-szeged@partner.samsung.com>
[EFL] FTL JIT not working on ARM64
https://bugs.webkit.org/show_bug.cgi?id=139295
Reviewed by Michael Saboff.
Added the missing code for stack unwinding and some additional small fixes
to get FTL working correctly.
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLUnwindInfo.cpp:
(JSC::FTL::UnwindInfo::parse):
2014-12-15 Oliver Hunt <oliver@apple.com>
Make sure range based iteration of Vector<> still receives bounds checking
https://bugs.webkit.org/show_bug.cgi?id=138821
Reviewed by Mark Lam.
Update code to deal with slightly changed iterator semantics.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::visitChildren):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitComplexPopScopes):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
* ftl/FTLAbbreviations.h:
(JSC::FTL::mdNode):
(JSC::FTL::buildCall):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* parser/Parser.h:
(JSC::Scope::Scope):
* runtime/JSArray.cpp:
(JSC::JSArray::setLengthWithArrayStorage):
(JSC::JSArray::sortCompactedVector):
* tools/ProfileTreeNode.h:
(JSC::ProfileTreeNode::dumpInternal):
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::matchCharacterClass):
2014-12-14 Filip Pizlo <fpizlo@apple.com>
PutLocalSinkingPhase has an invalid assertion about incoming values, because both liveness and deferral analyses are conservative
https://bugs.webkit.org/show_bug.cgi?id=139630
Reviewed by Oliver Hunt.
Replaces a faulty assertion with code to handle an awesome special case. Also adds a lot of
comments that reconstruct my reasoning about this code. I had to work hard to remember how
deferral worked so I wrote my discoveries down.
* dfg/DFGInsertionSet.h:
(JSC::DFG::InsertionSet::insertBottomConstantForUse):
* dfg/DFGPutLocalSinkingPhase.cpp:
* tests/stress/put-local-conservative.js: Added.
(foo):
(.result):
(bar):
2014-12-14 Andreas Kling <akling@apple.com>
Replace PassRef with Ref/Ref&& across the board.
<https://webkit.org/b/139587>
Reviewed by Darin Adler.
* runtime/Identifier.cpp:
(JSC::Identifier::add):
(JSC::Identifier::add8):
* runtime/Identifier.h:
(JSC::Identifier::add):
* runtime/IdentifierInlines.h:
(JSC::Identifier::add):
2014-12-12 Matthew Mirman <mmirman@apple.com>
shiftCountWithArrayStorage should exit to slow path if the object has a sparse map.
https://bugs.webkit.org/show_bug.cgi?id=139598
<rdar://problem/18779367>
Reviewed by Filip Pizlo.
* runtime/JSArray.cpp:
(JSC::JSArray::shiftCountWithArrayStorage): Added check for object having a sparse map.
* tests/stress/sparse_splice.js: Added.
2014-12-12 Gyuyoung Kim <gyuyoung.kim@samsung.com>
Final clean up OwnPtr in JSC - runtime, ftl, and tool directories
https://bugs.webkit.org/show_bug.cgi?id=139532
Reviewed by Mark Lam.
Final remove OwnPtr, PassOwnPtr in runtime, ftl, and tools directories of JSC.
* builtins/BuiltinExecutables.h:
* bytecode/CodeBlock.h:
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
* ftl/FTLAbstractHeap.cpp:
(JSC::FTL::IndexedAbstractHeap::atSlow):
* ftl/FTLAbstractHeap.h:
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLJITFinalizer.h:
* jsc.cpp:
(jscmain):
* parser/Lexer.h:
* runtime/PropertyMapHashTable.h:
(JSC::PropertyTable::clearDeletedOffsets):
(JSC::PropertyTable::addDeletedOffset):
* runtime/PropertyTable.cpp:
(JSC::PropertyTable::PropertyTable):
* runtime/RegExpObject.cpp:
* runtime/SmallStrings.cpp:
* runtime/Structure.cpp:
* runtime/StructureIDTable.cpp:
(JSC::StructureIDTable::StructureIDTable):
(JSC::StructureIDTable::resize):
* runtime/StructureIDTable.h:
* runtime/StructureTransitionTable.h:
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::~VM):
* runtime/VM.h:
* tools/CodeProfile.h:
(JSC::CodeProfile::CodeProfile):
(JSC::CodeProfile::addChild):
2014-12-11 Dan Bernstein <mitz@apple.com>
iOS Simulator production build fix.
* Configurations/JavaScriptCore.xcconfig: Don’t use an order file when building for the iOS
Simulator, as we did prior to 177027.
2014-12-11 Joseph Pecoraro <pecoraro@apple.com>
Explicitly export somre more RWIProtocol classes.
rdar://problem/19220408
Unreviewed build fix.
* inspector/scripts/codegen/generate_objc_configuration_header.py:
(ObjCConfigurationHeaderGenerator._generate_configuration_interface_for_domains):
* inspector/scripts/codegen/generate_objc_header.py:
(ObjCHeaderGenerator._generate_event_interfaces):
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2014-12-11 Alexey Proskuryakov <ap@apple.com>
Explicitly export some RWIProtocol classes
rdar://problem/19220408
* inspector/scripts/codegen/generate_objc_header.py:
(ObjCHeaderGenerator._generate_type_interface):
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2014-12-11 Mark Lam <mark.lam@apple.com>
Fix broken build after r177146.
https://bugs.webkit.org/show_bug.cgi?id=139533
Not reviewed.
* interpreter/CallFrame.h:
(JSC::ExecState::init):
- Restored CallFrame::init() minus the unused JSScope* arg.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
- Remove JSScope* arg when calling CallFrame::init().
2014-12-11 Michael Saboff <msaboff@apple.com>
REGRESSION: Use of undefined CallFrame::ScopeChain value
https://bugs.webkit.org/show_bug.cgi?id=139533
Reviewed by Mark Lam.
Removed CallFrame::scope() and CallFrame::setScope() and eliminated or changed
all usages of these funcitons. In some cases the scope is passed in or determined
another way. In some cases the scope is used to calculate other values. Lastly
were places where these functions where used that are no longer needed. For
example when making a call, the caller's ScopeChain was copied to the callee's
ScopeChain. This change no longer uses the ScopeChain call frame header slot.
That slot will be removed in a future patch.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* runtime/JSLexicalEnvironment.h:
(JSC::JSLexicalEnvironment::create):
(JSC::JSLexicalEnvironment::JSLexicalEnvironment):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_create_lexical_environment):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_create_lexical_environment):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::handleHostCall):
(JSC::LLInt::setUpCall):
(JSC::LLInt::llint_throw_stack_overflow_error):
Pass the current scope value to the helper operationCreateActivation() and
the call to JSLexicalEnvironment::create() instead of using the stack frame
scope chain value.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
CreateActivation now has a second child, the scope.
* interpreter/CallFrame.h:
(JSC::ExecState::init): Deleted. This is dead code.
(JSC::ExecState::scope): Deleted.
(JSC::ExecState::setScope): Deleted.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::dumpRegisters): Changed so we didn't access the scope
chain slot.
(JSC::Interpreter::execute):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
Changed process to find JSScope values on the stack or by some other means.
* runtime/JSWithScope.h:
(JSC::JSWithScope::JSWithScope): Deleted.
Eliminated unused constructor.
* runtime/StrictEvalActivation.cpp:
(JSC::StrictEvalActivation::StrictEvalActivation):
* runtime/StrictEvalActivation.h:
(JSC::StrictEvalActivation::create):
Changed to pass in the current scope.
2014-12-10 Gyuyoung Kim <gyuyoung.kim@samsung.com>
Use std::unique_ptr instead of OwnPtr in JSC - heap, jit, runtime, and parser directories
https://bugs.webkit.org/show_bug.cgi?id=139351
Reviewed by Filip Pizlo.
As a step to use std::unique_ptr<>, this cleans up OwnPtr and PassOwnPtr.
* bytecode/SamplingTool.h:
(JSC::SamplingTool::SamplingTool):
* heap/CopiedBlock.h:
(JSC::CopiedBlock::didSurviveGC):
(JSC::CopiedBlock::pin):
* heap/CopiedBlockInlines.h:
(JSC::CopiedBlock::reportLiveBytes):
* heap/GCActivityCallback.h:
* heap/GCThread.cpp:
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::markListSet):
* jit/ExecutableAllocator.cpp:
* jit/JIT.cpp:
(JSC::JIT::privateCompile):
* jit/JIT.h:
* jit/JITThunks.cpp:
(JSC::JITThunks::JITThunks):
(JSC::JITThunks::clearHostFunctionStubs):
* jit/JITThunks.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::Parser):
* parser/Parser.h:
(JSC::Scope::Scope):
(JSC::Scope::pushLabel):
* parser/ParserArena.cpp:
* parser/ParserArena.h:
(JSC::ParserArena::identifierArena):
* parser/SourceProviderCache.h:
* runtime/CodeCache.h:
* runtime/Executable.h:
* runtime/JSArray.cpp:
(JSC::JSArray::sortVector):
* runtime/JSGlobalObject.h:
2014-12-10 Geoffrey Garen <ggaren@apple.com>
Please disable the webkitFirstVersionWithInitConstructorSupport check on Apple TV
https://bugs.webkit.org/show_bug.cgi?id=139501
Reviewed by Gavin Barraclough.
NSVersionOfLinkTimeLibrary only works if you link directly against
JavaScriptCore, which is a bit awkward for our Apple TV client to do.
It's easy enough just to disable this check on Apple TV, since it has no
backwards compatibility requirement.
* API/JSWrapperMap.mm:
(supportsInitMethodConstructors):
2014-12-10 Matthew Mirman <mmirman@apple.com>
Fixes operationPutByIds such that they check that the put didn't
change the structure of the object who's property access is being
cached.
https://bugs.webkit.org/show_bug.cgi?id=139196
Reviewed by Filip Pizlo.
* jit/JITOperations.cpp:
(JSC::operationGetByIdOptimize): changed get to getPropertySlot
(JSC::operationPutByIdStrictBuildList): saved the structure before the put.
(JSC::operationPutByIdNonStrictBuildList): ditto.
(JSC::operationPutByIdDirectStrictBuildList): ditto.
(JSC::operationPutByIdDirectNonStrictBuildList): ditto.
* jit/Repatch.cpp:
(JSC::tryCachePutByID): fixed structure() to use the existant vm.
(JSC::tryBuildPutByIdList): Added a check that the old structure's id
is the same as the new.
(JSC::buildPutByIdList): Added an argument
* jit/Repatch.h:
(JSC::buildPutByIdList): Added an argument
* tests/stress/put-by-id-strict-build-list-order.js: Added.
2014-12-10 Csaba Osztrogonác <ossy@webkit.org>
URTBF after r177030.
Fix linking failure occured on ARM buildbots:
lib/libjavascriptcore_efl.so.1.11.0: undefined reference to `JSC::Structure::get(JSC::VM&, JSC::PropertyName, unsigned int&)'
* runtime/NullGetterFunction.cpp:
2014-12-09 Michael Saboff <msaboff@apple.com>
DFG Tries using an inner object's getter/setter when one hasn't been defined
https://bugs.webkit.org/show_bug.cgi?id=139229
Reviewed by Filip Pizlo.
Added a new NullGetterFunction singleton class to use for getters and setters that
haven't been set to a user defined value. The NullGetterFunction callReturnUndefined()
and createReturnUndefined() methods return undefined. Changed all null checks of the
getter and setter pointers to the newly added isGetterNull() and isSetterNull()
helper methods.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
Added NullGetterFunction.cpp & .h to build files.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncLookupGetter):
(JSC::objectProtoFuncLookupSetter):
* runtime/PropertyDescriptor.cpp:
(JSC::PropertyDescriptor::setDescriptor):
(JSC::PropertyDescriptor::setAccessorDescriptor):
Changed checking getter and setter to null to use new isGetterNull() and isSetterNull()
helpers.
* inspector/JSInjectedScriptHostPrototype.cpp:
(Inspector::JSInjectedScriptHostPrototype::finishCreation):
* inspector/JSJavaScriptCallFramePrototype.cpp:
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/JSObject.cpp:
(JSC::JSObject::putIndexedDescriptor):
(JSC::putDescriptor):
(JSC::JSObject::defineOwnNonIndexProperty):
* runtime/MapPrototype.cpp:
(JSC::MapPrototype::finishCreation):
* runtime/SetPrototype.cpp:
(JSC::SetPrototype::finishCreation):
Updated calls to GetterSetter::create(), setGetter(), setSetter(), withGetter()
and withSetter() to provide a global object.
* runtime/GetterSetter.cpp:
(JSC::GetterSetter::withGetter):
(JSC::GetterSetter::withSetter):
(JSC::callGetter):
(JSC::callSetter):
* runtime/GetterSetter.h:
(JSC::GetterSetter::GetterSetter):
(JSC::GetterSetter::create):
(JSC::GetterSetter::isGetterNull):
(JSC::GetterSetter::isSetterNull):
(JSC::GetterSetter::setGetter):
(JSC::GetterSetter::setSetter):
Changed to use NullGetterFunction for unspecified getters / setters.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::createThrowTypeError):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::nullGetterFunction):
(JSC::JSGlobalObject::evalFunction):
Added m_nullGetterFunction singleton. Updated calls to GetterSetter::create(),
setGetter() and setSetter() to provide a global object.
* runtime/NullGetterFunction.cpp: Added.
(JSC::callReturnUndefined):
(JSC::constructReturnUndefined):
(JSC::NullGetterFunction::getCallData):
(JSC::NullGetterFunction::getConstructData):
* runtime/NullGetterFunction.h: Added.
(JSC::NullGetterFunction::create):
(JSC::NullGetterFunction::createStructure):
(JSC::NullGetterFunction::NullGetterFunction):
New singleton class that returns undefined when called.
2014-12-09 Geoffrey Garen <ggaren@apple.com>
Re-enable function.arguments
https://bugs.webkit.org/show_bug.cgi?id=139452
<rdar://problem/18848149>
Reviewed by Sam Weinig.
Disabling function.arguments broke a few websites, and we don't have
time right now to work through the details.
I'm re-enabling function.arguments but leaving in the infrastructure
to re-disable it, so we can try this experiment again in the future.
* runtime/Options.h:
2014-12-09 David Kilzer <ddkilzer@apple.com>
Switch from using PLATFORM_NAME to SDK selectors in ANGLE, bmalloc, gtest, JavaScriptCore, WTF
<http://webkit.org/b/139212>
Reviewed by Joseph Pecoraro.
* Configurations/Base.xcconfig:
- Only set GCC_ENABLE_OBJC_GC, GCC_MODEL_TUNING and TOOLCHAINS
on OS X.
- Only set LLVM_LOCAL_HEADER_PATH and LLVM_SYSTEM_HEADER_PATH on
OS X.
- Set JAVASCRIPTCORE_CONTENTS_DIR and
JAVASCRIPTCORE_FRAMEWORKS_DIR separately for iOS and OS X.
* Configurations/DebugRelease.xcconfig:
- Only set MACOSX_DEPLOYMENT_TARGET and SDKROOT on OS X.
* Configurations/JSC.xcconfig:
- Only set CODE_SIGN_ENTITLEMENTS for iOS hardware builds.
* Configurations/JavaScriptCore.xcconfig:
- Set OTHER_LDFLAGS separately for iOS and OS X.
- Set SECTORDER_FLAGS separately for iOS and OS X, but only for
Production builds.
- Only set EXCLUDED_SOURCE_FILE_NAMES for iOS.
* Configurations/LLVMForJSC.xcconfig:
- Rename LLVM_LIBS_iphoneos to LLVM_LIBS_ios.
- Set LLVM_LIBRARY_PATHS and OTHER_LDFLAGS_LLVM_ENABLE_FTL_JIT
separately for iOS hardware and OS X.
- Fix curly braces in LIBRARY_SEARCH_PATHS.
- Merge OTHER_LDFLAGS_BASE into OTHER_LDFLAGS. (Could have been
done before this patch.)
* Configurations/ToolExecutable.xcconfig:
- Only set CODE_SIGN_ENTITLEMENTS for iOS, per target.
- Only set CLANG_ENABLE_OBJC_ARC for i386 on the iOS Simulator.
- Add missing newline.
* Configurations/Version.xcconfig:
- Set SYSTEM_VERSION_PREFIX separately for iOS and OS X.
2014-12-08 Gyuyoung Kim <gyuyoung.kim@samsung.com>
Fix EFL build fix since r177001
https://bugs.webkit.org/show_bug.cgi?id=139428
Unreviewed, EFL build fix.
Do not inherit duplicated class. ExpressionNode is already
child of ParserArenaFreeable class.
* parser/Nodes.h:
2014-12-08 Shivakumar JM <shiva.jm@samsung.com>
Fix Build Warning in JavaScriptCore ControlFlowProfiler::dumpData() api.
https://bugs.webkit.org/show_bug.cgi?id=139384
Reviewed by Mark Lam.
Fix Build Warning by using dataLog() function instead of dataLogF() function.
* runtime/ControlFlowProfiler.cpp:
(JSC::ControlFlowProfiler::dumpData):
2014-12-08 Saam Barati <saambarati1@gmail.com>
Web Inspector: Enable runtime API for JSC's control flow profiler
https://bugs.webkit.org/show_bug.cgi?id=139346
Reviewed by Joseph Pecoraro.
This patch creates an API that the Web Inspector can use
to get information about which basic blocks have exectued
from JSC's control flow profiler.
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::getBasicBlocks):
* inspector/agents/InspectorRuntimeAgent.h:
* inspector/protocol/Runtime.json:
2014-12-08 Geoffrey Garen <ggaren@apple.com>
Removed some allocation and cruft from the parser
https://bugs.webkit.org/show_bug.cgi?id=139416
Reviewed by Mark Lam.
Now, the only AST nodes that require a destructor are the ones that
relate to pickling a function's arguments -- which will required some
deeper thinking to resolve.
This is a < 1% parser speedup.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj: Removed NodeInfo because it
was unused.
* bytecompiler/NodesCodegen.cpp:
(JSC::CommaNode::emitBytecode):
(JSC::SourceElements::lastStatement):
(JSC::SourceElements::emitBytecode): Updated for interface change to linked list.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::ASTBuilder):
(JSC::ASTBuilder::varDeclarations):
(JSC::ASTBuilder::funcDeclarations):
(JSC::ASTBuilder::createFuncDeclStatement):
(JSC::ASTBuilder::addVar): Removed the ParserArenaData abstraction because
it wasn't buying us anything. We can just use Vector directly.
(JSC::ASTBuilder::createCommaExpr):
(JSC::ASTBuilder::appendToCommaExpr): Changed to use a linked list instead
of a vector, to avoid allocating a vector with inline capacity in the
common case in which an expression is not followed by a vector.
(JSC::ASTBuilder::Scope::Scope): Use Vector directly to avoid new'ing
up a Vector*.
(JSC::ASTBuilder::appendToComma): Deleted.
(JSC::ASTBuilder::combineCommaNodes): Deleted.
* parser/Lexer.cpp:
* parser/NodeConstructors.h:
(JSC::StatementNode::StatementNode):
(JSC::CommaNode::CommaNode):
(JSC::SourceElements::SourceElements): Updated for interface change to linked list.
* parser/NodeInfo.h: Removed.
* parser/Nodes.cpp:
(JSC::SourceElements::append):
(JSC::SourceElements::singleStatement): Use a linked list instead of a
vector to track the statements in a list. This removes some allocation
and it means that we don't need a destructor anymore.
(JSC::ScopeNode::ScopeNode):
(JSC::ProgramNode::ProgramNode):
(JSC::EvalNode::EvalNode):
(JSC::FunctionNode::FunctionNode): Updated for interface change to reference,
since these values are never null.
* parser/Nodes.h:
(JSC::StatementNode::next):
(JSC::StatementNode::setNext):
(JSC::CommaNode::append): Deleted. Updated for interface change to linked list.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::didFinishParsing): Updated for interface change to reference.
(JSC::Parser<LexerType>::parseVarDeclarationList):
(JSC::Parser<LexerType>::parseExpression): Track comma expressions as
an explicit list of CommaNodes, removing a use of vector and a destructor.
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createCommaExpr):
(JSC::SyntaxChecker::appendToCommaExpr):
(JSC::SyntaxChecker::appendToComma): Deleted. Updated for interface changes.
2014-12-08 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r176979.
https://bugs.webkit.org/show_bug.cgi?id=139424
"New JSC test in this patch is failing" (Requested by mlam on
#webkit).
Reverted changeset:
"Fixes operationPutByIds such that they check that the put
didn't"
https://bugs.webkit.org/show_bug.cgi?id=139196
http://trac.webkit.org/changeset/176979
2014-12-08 Matthew Mirman <mmirman@apple.com>
Fixes operationPutByIds such that they check that the put didn't
change the structure of the object who's property access is being
cached.
https://bugs.webkit.org/show_bug.cgi?id=139196
Reviewed by Filip Pizlo.
* jit/JITOperations.cpp:
(JSC::operationGetByIdOptimize): changed get to getPropertySlot
(JSC::operationPutByIdStrictBuildList): saved the structure before the put.
(JSC::operationPutByIdNonStrictBuildList): ditto.
(JSC::operationPutByIdDirectStrictBuildList): ditto.
(JSC::operationPutByIdDirectNonStrictBuildList): ditto.
* jit/Repatch.cpp:
(JSC::tryCachePutByID): fixed structure() to use the existant vm.
(JSC::tryBuildPutByIdList): Added a check that the old structure's id
is the same as the new.
(JSC::buildPutByIdList): Added an argument
* jit/Repatch.h:
(JSC::buildPutByIdList): Added an argument
* tests/stress/put-by-id-build-list-order-recurse.js: Test that failed before the change
* tests/stress/put-by-id-strict-build-list-order.js: Added.
2014-12-08 Anders Carlsson <andersca@apple.com>
Change WTF::currentCPUTime to return std::chrono::microseconds and get rid of currentCPUTimeMS
https://bugs.webkit.org/show_bug.cgi?id=139410
Reviewed by Andreas Kling.
* API/JSContextRef.cpp:
(JSContextGroupSetExecutionTimeLimit):
(JSContextGroupClearExecutionTimeLimit):
* runtime/Watchdog.cpp:
(JSC::Watchdog::setTimeLimit):
(JSC::Watchdog::didFire):
(JSC::Watchdog::startCountdownIfNeeded):
(JSC::Watchdog::startCountdown):
* runtime/Watchdog.h:
* runtime/WatchdogMac.cpp:
(JSC::Watchdog::startTimer):
2014-12-08 Mark Lam <mark.lam@apple.com>
CFA wrongly assumes that a speculation for SlowPutArrayStorageShape disallows ArrayStorageShape arrays.
<https://webkit.org/b/139327>
Reviewed by Michael Saboff.
The code generator and runtime slow paths expects otherwise. This patch fixes
CFA to match the code generator's expectation.
* dfg/DFGArrayMode.h:
(JSC::DFG::ArrayMode::arrayModesThatPassFiltering):
(JSC::DFG::ArrayMode::arrayModesWithIndexingShapes):
2014-12-08 Chris Dumez <cdumez@apple.com>
Revert r176293 & r176275
Unreviewed, revert r176293 & r176275 changing the Vector API to use unsigned type
instead of size_t. There is some disagreement regarding the long-term direction
of the API and we shouldn’t leave the API partly transitioned to unsigned type
while making a decision.
* bytecode/PreciseJumpTargets.cpp:
* replay/EncodedValue.h:
2014-12-07 Csaba Osztrogonác <ossy@webkit.org>
Remove the unused WTF_USE_GCC_COMPUTED_GOTO_WORKAROUND after r129453.
https://bugs.webkit.org/show_bug.cgi?id=139373
Reviewed by Sam Weinig.
* interpreter/Interpreter.cpp:
2014-12-06 Anders Carlsson <andersca@apple.com>
Fix build with newer versions of clang.
rdar://problem/18978716
* ftl/FTLJITCode.h:
Add missing overrides.
2014-12-05 Roger Fong <roger_fong@apple.com>
[Win] proj files copying over too many resources..
https://bugs.webkit.org/show_bug.cgi?id=139315.
<rdar://problem/19148278>
Reviewed by Brent Fulgham.
* JavaScriptCore.vcxproj/JavaScriptCore.proj: Only copy resource folders and JavaScriptCore.dll.
2014-12-05 Juergen Ributzka <juergen@apple.com>
[JSC][FTL] Add the data layout to the module and fix the pass order.
https://bugs.webkit.org/show_bug.cgi?id=138748
Reviewed by Oliver Hunt.
This adds the data layout to the module, so it can be used by all
optimization passes in the LLVM optimizer pipeline. This also allows
FastISel to select more instructions, because less non-legal types are
generated.
Also fix the order of the alias analysis passes in the optimization
pipeline.
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
2014-12-05 Geoffrey Garen <ggaren@apple.com>
Removed an unused function.
Reviewed by Michael Saboff.
Broken out from https://bugs.webkit.org/show_bug.cgi?id=139305.
* parser/ParserArena.h:
2014-12-05 David Kilzer <ddkilzer@apple.com>
FeatureDefines.xcconfig: Workaround bug in Xcode 5.1.1 when defining ENABLE_WEB_REPLAY
<http://webkit.org/b/139286>
Reviewed by Daniel Bates.
* Configurations/FeatureDefines.xcconfig: Switch back to using
PLATFORM_NAME to workaround a bug in Xcode 5.1.1 on 10.8.
2014-12-04 Mark Rowe <mrowe@apple.com>
Build fix after r176836.
Reviewed by Mark Lam.
* runtime/VM.h:
(JSC::VM::controlFlowProfiler): Don't try to export an inline function.
Doing so results in a weak external symbol being generated.
2014-12-04 Saam Barati <saambarati1@gmail.com>
JavaScript Control Flow Profiler
https://bugs.webkit.org/show_bug.cgi?id=137785
Reviewed by Filip Pizlo.
This patch introduces a mechanism for JavaScriptCore to profile
which basic blocks have executed. This mechanism will then be
used by the Web Inspector to indicate which basic blocks
have and have not executed.
The profiling works by compiling in an op_profile_control_flow
at the start of every basic block. Then, whenever this op code
executes, we know that a particular basic block has executed.
When we tier up a CodeBlock that contains an op_profile_control_flow
that corresponds to an already executed basic block, we don't
have to emit code for that particular op_profile_control_flow
because the internal data structures used to keep track of
basic block locations has already recorded that the corresponding
op_profile_control_flow has executed.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::CodeBlock):
* bytecode/Instruction.h:
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::addOpProfileControlFlowBytecodeOffset):
(JSC::UnlinkedCodeBlock::opProfileControlFlowBytecodeOffsets):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitProfileControlFlow):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ConditionalNode::emitBytecode):
(JSC::IfElseNode::emitBytecode):
(JSC::WhileNode::emitBytecode):
(JSC::ForNode::emitBytecode):
(JSC::ContinueNode::emitBytecode):
(JSC::BreakNode::emitBytecode):
(JSC::ReturnNode::emitBytecode):
(JSC::CaseClauseNode::emitBytecode):
(JSC::SwitchNode::emitBytecode):
(JSC::ThrowNode::emitBytecode):
(JSC::TryNode::emitBytecode):
(JSC::ProgramNode::emitBytecode):
(JSC::FunctionNode::emitBytecode):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::basicBlockLocation):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_profile_control_flow):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_profile_control_flow):
* jsc.cpp:
(GlobalObject::finishCreation):
(functionFindTypeForExpression):
(functionReturnTypeFor):
(functionDumpBasicBlockExecutionRanges):
* llint/LowLevelInterpreter.asm:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionExpr):
(JSC::ASTBuilder::createGetterOrSetterProperty):
(JSC::ASTBuilder::createFuncDeclStatement):
(JSC::ASTBuilder::endOffset):
(JSC::ASTBuilder::setStartOffset):
* parser/NodeConstructors.h:
(JSC::Node::Node):
* parser/Nodes.h:
(JSC::CaseClauseNode::setStartOffset):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseSwitchClauses):
(JSC::Parser<LexerType>::parseSwitchDefaultClause):
(JSC::Parser<LexerType>::parseBlockStatement):
(JSC::Parser<LexerType>::parseStatement):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseIfStatement):
(JSC::Parser<LexerType>::parseExpression):
(JSC::Parser<LexerType>::parseConditionalExpression):
(JSC::Parser<LexerType>::parseProperty):
(JSC::Parser<LexerType>::parseMemberExpression):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionExpr):
(JSC::SyntaxChecker::createFuncDeclStatement):
(JSC::SyntaxChecker::createGetterOrSetterProperty):
(JSC::SyntaxChecker::operatorStackPop):
* runtime/BasicBlockLocation.cpp: Added.
(JSC::BasicBlockLocation::BasicBlockLocation):
(JSC::BasicBlockLocation::insertGap):
(JSC::BasicBlockLocation::getExecutedRanges):
(JSC::BasicBlockLocation::dumpData):
(JSC::BasicBlockLocation::emitExecuteCode):
* runtime/BasicBlockLocation.h: Added.
(JSC::BasicBlockLocation::startOffset):
(JSC::BasicBlockLocation::endOffset):
(JSC::BasicBlockLocation::setStartOffset):
(JSC::BasicBlockLocation::setEndOffset):
(JSC::BasicBlockLocation::hasExecuted):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
* runtime/ControlFlowProfiler.cpp: Added.
(JSC::ControlFlowProfiler::~ControlFlowProfiler):
(JSC::ControlFlowProfiler::getBasicBlockLocation):
(JSC::ControlFlowProfiler::dumpData):
(JSC::ControlFlowProfiler::getBasicBlocksForSourceID):
* runtime/ControlFlowProfiler.h: Added. This class is in
charge of generating BasicBlockLocations and also
providing an interface that the Web Inspector can use to ping
which basic blocks have executed based on the source id of a script.
(JSC::BasicBlockKey::BasicBlockKey):
(JSC::BasicBlockKey::isHashTableDeletedValue):
(JSC::BasicBlockKey::operator==):
(JSC::BasicBlockKey::hash):
(JSC::BasicBlockKeyHash::hash):
(JSC::BasicBlockKeyHash::equal):
* runtime/Executable.cpp:
(JSC::ProgramExecutable::ProgramExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
* runtime/FunctionHasExecutedCache.cpp:
(JSC::FunctionHasExecutedCache::getUnexecutedFunctionRanges):
* runtime/FunctionHasExecutedCache.h:
* runtime/Options.h:
* runtime/TypeProfiler.cpp:
(JSC::TypeProfiler::logTypesForTypeLocation):
(JSC::TypeProfiler::typeInformationForExpressionAtOffset):
(JSC::TypeProfiler::findLocation):
(JSC::TypeProfiler::dumpTypeProfilerData):
* runtime/TypeProfiler.h:
(JSC::TypeProfiler::functionHasExecutedCache): Deleted.
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::enableProfilerWithRespectToCount):
(JSC::disableProfilerWithRespectToCount):
(JSC::VM::enableTypeProfiler):
(JSC::VM::disableTypeProfiler):
(JSC::VM::enableControlFlowProfiler):
(JSC::VM::disableControlFlowProfiler):
(JSC::VM::dumpTypeProfilerData):
* runtime/VM.h:
(JSC::VM::functionHasExecutedCache):
(JSC::VM::controlFlowProfiler):
2014-12-04 Filip Pizlo <fpizlo@apple.com>
printInternal(PrintStream& out, JSC::JITCode::JITType type) ends up dumping a literal %s
https://bugs.webkit.org/show_bug.cgi?id=139274
Reviewed by Geoffrey Garen.
* jit/JITCode.cpp:
(WTF::printInternal):
2014-12-04 Geoffrey Garen <ggaren@apple.com>
Removed the concept of ParserArenaRefCounted
https://bugs.webkit.org/show_bug.cgi?id=139277
Reviewed by Oliver Hunt.
This is a step toward a parser speedup.
Now that we have a clear root node type for each parse tree, there's no
need to have a concept for "I might be refcounted or arena allocated".
Instead, we can just use unique_ptr to manage the tree as a whole.
* API/JSScriptRef.cpp:
(parseScript):
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createBuiltinExecutable): Updated for type change.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock): Use unique_ptr. No need to call
destroyData() explicitly: the unique_ptr destructor will do everything
we need, as Bjarne intended.
* parser/NodeConstructors.h:
(JSC::ParserArenaRoot::ParserArenaRoot):
(JSC::ParserArenaRefCounted::ParserArenaRefCounted): Deleted.
* parser/Nodes.cpp:
(JSC::ScopeNode::ScopeNode):
(JSC::ProgramNode::ProgramNode):
(JSC::EvalNode::EvalNode):
(JSC::FunctionNode::FunctionNode):
(JSC::ProgramNode::create): Deleted.
(JSC::EvalNode::create): Deleted.
(JSC::FunctionNode::create): Deleted. All special create semantics can
just go away now that we play by C++ constructor / destructor rules.
* parser/Nodes.h:
(JSC::ParserArenaRoot::parserArena):
(JSC::ParserArenaRoot::~ParserArenaRoot): Just a normal class now, which
holds onto the whole parse tree by virtue of owning the arena in which
all the parsed nodes (except for itself) were allocated.
(JSC::ProgramNode::closedVariables):
(JSC::ParserArenaRefCounted::~ParserArenaRefCounted): Deleted.
(JSC::ScopeNode::destroyData): Deleted. No need to destroy anything
explicitly anymore -- we can just rely on destructors.
(JSC::ScopeNode::parserArena): Deleted.
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
(JSC::parse): unique_ptr all the things.
* parser/ParserArena.cpp:
(JSC::ParserArena::reset):
(JSC::ParserArena::isEmpty):
(JSC::ParserArena::contains): Deleted.
(JSC::ParserArena::last): Deleted.
(JSC::ParserArena::removeLast): Deleted.
(JSC::ParserArena::derefWithArena): Deleted.
* parser/ParserArena.h:
(JSC::ParserArena::swap): Much delete. Such wow.
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/Completion.cpp:
(JSC::checkSyntax):
* runtime/Executable.cpp:
(JSC::ProgramExecutable::checkSyntax): unique_ptr all the things.
2014-12-04 Andreas Kling <akling@apple.com>
REGRESSION(r173188): Text inserted when trying to delete a word from the Twitter message box.
<https://webkit.org/b/139076>
Reviewed by Geoffrey Garen.
The StringImpl* -> Weak<JSString> cache used by the DOM bindings
had a bug where the key could become a stale pointer if the cached
JSString had its internal StringImpl atomicized.
If a new StringImpl was then later constructed at the exact same
address as the stale key, before the Weak<JSString> got booted out
of the string cache, we'd now have a situation where asking the
string cache for that key would return the old JSString.
Solve this by not allowing JSString::toExistingAtomicString() to
change the JSString's internal StringImpl unless it's resolving a
rope string. (The StringImpl nullity determines rope state.)
This means that calling toExistingAtomicString() may now have to
query the AtomicString table on each call rather than just once.
All clients of this API would be forced to do this regardless,
since they return value will be used to key into containers with
AtomicStringImpl* keys.
No test because this relies on malloc putting two StringImpls
at the same address at different points in time and we have no
mechanism to reliably test that.
* runtime/JSString.h:
(JSC::JSString::toExistingAtomicString):
2014-12-04 Geoffrey Garen <ggaren@apple.com>
Marked some final things final.
Reviewed by Andreas Kling.
* parser/Nodes.h:
2014-12-04 Geoffrey Garen <ggaren@apple.com>
Split out FunctionNode from FunctionBodyNode
https://bugs.webkit.org/show_bug.cgi?id=139273
Reviewed by Andreas Kling.
This is step toward a parser speedup.
We used to use FunctionBodyNode for two different purposes:
(1) "I am the root function you are currently parsing";
(2) "I am a lazy record of a nested function, which you will parse later".
This made for awkward lifetime semantics and interfaces.
Now, case (1) is handled by FunctionBodyNode, and case (2) is handled by
a new node named FunctionNode.
Since case (1) no longer needs to handle being the root of the parse
tree, FunctionBodyNode can be a normal arena-allocated node.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock): Use FunctionNode instead of
FunctionBodyNode, since we are producing the root of the function parse
tree.
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable): Removed
some unused data, and default-initialized other data, which isn't filled
in meaningfully until recordParse() is called. (The previous values were
incorrect / meaningless, since the FunctionBodyNode didn't have
meaningful values in this case.)
* bytecode/UnlinkedCodeBlock.h: Ditto.
(JSC::UnlinkedFunctionExecutable::forceUsesArguments): Deleted.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator): Use FunctionNode instead of
FunctionBodyNode, since we are generating code starting at the root of
the parse tree.
(JSC::BytecodeGenerator::resolveCallee):
(JSC::BytecodeGenerator::addCallee):
* bytecompiler/BytecodeGenerator.h: Ditto.
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
(JSC::FunctionNode::emitBytecode): Moved the emitBytecode implementation
to FunctionNode, since we never generate code for FunctionBodyNode,
since it's just a placeholder in the AST.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setUsesArguments): Deleted. Updated for interface
changes.
* parser/Nodes.cpp:
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::finishParsing):
(JSC::FunctionBodyNode::setEndPosition):
(JSC::FunctionNode::FunctionNode):
(JSC::FunctionNode::create):
(JSC::FunctionNode::finishParsing):
(JSC::FunctionBodyNode::create): Deleted.
* parser/Nodes.h:
(JSC::FunctionBodyNode::parameters):
(JSC::FunctionBodyNode::source):
(JSC::FunctionBodyNode::startStartOffset):
(JSC::FunctionBodyNode::isInStrictContext):
(JSC::FunctionNode::parameters):
(JSC::FunctionNode::ident):
(JSC::FunctionNode::functionMode):
(JSC::FunctionNode::startColumn):
(JSC::FunctionNode::endColumn):
(JSC::ScopeNode::setSource): Deleted.
(JSC::FunctionBodyNode::parameterCount): Deleted. Split out the differences
between FunctionNode and FunctionBodyNode.
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createClauseList):
(JSC::SyntaxChecker::setUsesArguments): Deleted. Removed setUsesArguments
since it wasn't used.
* runtime/Executable.cpp:
(JSC::ProgramExecutable::checkSyntax): Removed a branch that was always
false.
2014-12-02 Brian J. Burg <burg@cs.washington.edu>
Web Inspector: timeline probe records have inaccurate per-probe hit counts
https://bugs.webkit.org/show_bug.cgi?id=138976
Reviewed by Joseph Pecoraro.
Previously, the DebuggerAgent was responsible for assigning unique ids to samples.
However, this makes it impossible for the frontend's Timeline manager to associate
a Probe Sample timeline record with the corresponding probe sample data. The record
only included the probe batchId (misnamed as hitCount in ScriptDebugServer).
This patch moves both the batchId and sampleId counters into ScriptDebugServer, so
any client of ScriptDebugListener will get the correct sampleId for each sample.
* inspector/ScriptDebugListener.h:
* inspector/ScriptDebugServer.cpp:
(Inspector::ScriptDebugServer::ScriptDebugServer):
(Inspector::ScriptDebugServer::dispatchBreakpointActionProbe):
(Inspector::ScriptDebugServer::handleBreakpointHit):
* inspector/ScriptDebugServer.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::InspectorDebuggerAgent):
(Inspector::InspectorDebuggerAgent::breakpointActionProbe):
* inspector/agents/InspectorDebuggerAgent.h:
2014-12-04 Oliver Hunt <oliver@apple.com>
Serialization of MapData object provides unsafe access to internal types
https://bugs.webkit.org/show_bug.cgi?id=138653
Reviewed by Geoffrey Garen.
Converting these ASSERTs into RELEASE_ASSERTs, as it is now obvious
that despite trying hard to be safe in all cases it's simply to easy
to use an iterator in an unsafe state.
* runtime/MapData.h:
(JSC::MapData::const_iterator::key):
(JSC::MapData::const_iterator::value):
2014-12-03 Gyuyoung Kim <gyuyoung.kim@samsung.com>
Move JavaScriptCore/dfg to std::unique_ptr
https://bugs.webkit.org/show_bug.cgi?id=139169
Reviewed by Filip Pizlo.
Use std::unique_ptr<>|std::make_unique<> in JavaScriptCore/dfg directory.
* dfg/DFGBasicBlock.h:
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::JITCompiler):
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::compileFunction):
(JSC::DFG::JITCompiler::linkFunction):
* dfg/DFGJITCompiler.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
(JSC::DFG::Plan::cancel):
* dfg/DFGPlan.h:
* dfg/DFGSlowPathGenerator.h:
* dfg/DFGWorklist.h:
* ftl/FTLFail.cpp:
(JSC::FTL::fail):
* ftl/FTLState.cpp:
(JSC::FTL::State::State):
2014-12-03 Michael Saboff <msaboff@apple.com>
REGRESSION (r176479): DFG ASSERTION beneath emitOSRExitCall running Kraken/imaging-gaussian-blur.js.ftl-no-cjit-osr-validation and other tests
https://bugs.webkit.org/show_bug.cgi?id=139246
Reviewed by Geoffrey Garen.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::buildExitArguments):
The DFG_ASSERT that checks liveness at exit time doesn't properly
handle the case where the local is not available at OSR exit time,
but the local is live in the bytecode. This now happens with the
allocated scope register when we are compiling for FTLForOSREntryMode
due to DCE done when the control flow was changed and a new entrypoint
was added in the OSR entrypoint creation phase. Therefore we silence
the assert when compiling for FTLForOSREntryMode.
2014-12-03 Geoffrey Garen <ggaren@apple.com>
Removed the global parser arena
https://bugs.webkit.org/show_bug.cgi?id=139236
Reviewed by Sam Weinig.
Simplifies parser lifetime logic.
There's no need to keep a global arena. We can create a new arena
each time we parse.
* bytecompiler/BytecodeGenerator.h: Global replace to pass around a
ParserArena instead of VM*, since the VM no longer owns the arena.
(JSC::BytecodeGenerator::parserArena):
* bytecompiler/NodesCodegen.cpp: Ditto.
(JSC::ArrayNode::toArgumentList):
(JSC::ApplyFunctionCallDotNode::emitBytecode):
* parser/ASTBuilder.h: Ditto.
(JSC::ASTBuilder::ASTBuilder):
(JSC::ASTBuilder::createSourceElements):
(JSC::ASTBuilder::createCommaExpr):
(JSC::ASTBuilder::createLogicalNot):
(JSC::ASTBuilder::createUnaryPlus):
(JSC::ASTBuilder::createVoid):
(JSC::ASTBuilder::thisExpr):
(JSC::ASTBuilder::createResolve):
(JSC::ASTBuilder::createObjectLiteral):
(JSC::ASTBuilder::createArray):
(JSC::ASTBuilder::createNumberExpr):
(JSC::ASTBuilder::createString):
(JSC::ASTBuilder::createBoolean):
(JSC::ASTBuilder::createNull):
(JSC::ASTBuilder::createBracketAccess):
(JSC::ASTBuilder::createDotAccess):
(JSC::ASTBuilder::createSpreadExpression):
(JSC::ASTBuilder::createRegExp):
(JSC::ASTBuilder::createNewExpr):
(JSC::ASTBuilder::createConditionalExpr):
(JSC::ASTBuilder::createAssignResolve):
(JSC::ASTBuilder::createFunctionExpr):
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::createGetterOrSetterProperty):
(JSC::ASTBuilder::createArguments):
(JSC::ASTBuilder::createArgumentsList):
(JSC::ASTBuilder::createProperty):
(JSC::ASTBuilder::createPropertyList):
(JSC::ASTBuilder::createElementList):
(JSC::ASTBuilder::createFormalParameterList):
(JSC::ASTBuilder::createClause):
(JSC::ASTBuilder::createClauseList):
(JSC::ASTBuilder::createFuncDeclStatement):
(JSC::ASTBuilder::createBlockStatement):
(JSC::ASTBuilder::createExprStatement):
(JSC::ASTBuilder::createIfStatement):
(JSC::ASTBuilder::createForLoop):
(JSC::ASTBuilder::createForInLoop):
(JSC::ASTBuilder::createForOfLoop):
(JSC::ASTBuilder::createEmptyStatement):
(JSC::ASTBuilder::createVarStatement):
(JSC::ASTBuilder::createEmptyVarExpression):
(JSC::ASTBuilder::createReturnStatement):
(JSC::ASTBuilder::createBreakStatement):
(JSC::ASTBuilder::createContinueStatement):
(JSC::ASTBuilder::createTryStatement):
(JSC::ASTBuilder::createSwitchStatement):
(JSC::ASTBuilder::createWhileStatement):
(JSC::ASTBuilder::createDoWhileStatement):
(JSC::ASTBuilder::createLabelStatement):
(JSC::ASTBuilder::createWithStatement):
(JSC::ASTBuilder::createThrowStatement):
(JSC::ASTBuilder::createDebugger):
(JSC::ASTBuilder::createConstStatement):
(JSC::ASTBuilder::appendConstDecl):
(JSC::ASTBuilder::combineCommaNodes):
(JSC::ASTBuilder::createDeconstructingAssignment):
(JSC::ASTBuilder::Scope::Scope):
(JSC::ASTBuilder::createNumber):
(JSC::ASTBuilder::makeTypeOfNode):
(JSC::ASTBuilder::makeDeleteNode):
(JSC::ASTBuilder::makeNegateNode):
(JSC::ASTBuilder::makeBitwiseNotNode):
(JSC::ASTBuilder::makeMultNode):
(JSC::ASTBuilder::makeDivNode):
(JSC::ASTBuilder::makeModNode):
(JSC::ASTBuilder::makeAddNode):
(JSC::ASTBuilder::makeSubNode):
(JSC::ASTBuilder::makeLeftShiftNode):
(JSC::ASTBuilder::makeRightShiftNode):
(JSC::ASTBuilder::makeURightShiftNode):
(JSC::ASTBuilder::makeBitOrNode):
(JSC::ASTBuilder::makeBitAndNode):
(JSC::ASTBuilder::makeBitXOrNode):
(JSC::ASTBuilder::makeFunctionCallNode):
(JSC::ASTBuilder::makeBinaryNode):
(JSC::ASTBuilder::makeAssignNode):
(JSC::ASTBuilder::makePrefixNode):
(JSC::ASTBuilder::makePostfixNode):
* parser/NodeConstructors.h: Ditto.
(JSC::ParserArenaFreeable::operator new):
(JSC::ParserArenaDeletable::operator new):
(JSC::ParserArenaRefCounted::ParserArenaRefCounted):
* parser/Nodes.cpp: Ditto.
(JSC::ScopeNode::ScopeNode):
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
* parser/Nodes.h: Ditto.
(JSC::ScopeNode::parserArena):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::Parser):
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseProperty): The parser now owns its own
arena, and transfers ownership of its contents when invoking the ScopeNode
constructor.
* parser/Parser.h:
(JSC::Parser<LexerType>::parse): No need to explicitly reset the arena,
since its lifetime is tied to the parser's lifetime now.
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createProperty):
(JSC::SyntaxChecker::createGetterOrSetterProperty):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h: The point of the patch: no more global.
2014-12-03 Geoffrey Garen <ggaren@apple.com>
The parser should allocate all pieces of the AST
https://bugs.webkit.org/show_bug.cgi?id=139230
Reviewed by Oliver Hunt.
This is a step toward a 14% parsing speedup.
Previously, allocation was split between the parser and certain node
constructor functions. This made for some duplicated code and circular
dependencies.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createGetterOrSetterProperty): No need to pass through
the VM, since our callee no longer needs to allocate anything.
(JSC::ASTBuilder::createProperty): Allocate the identifier for our
callee, since that is simpler than requiring our callee to notice that
we didn't do so, and do it for us.
(JSC::ASTBuilder::createForInLoop): Allocate the DeconstructingAssignmentNode
for our callee, since that is simpler than requiring our callee to notice
that we didn't do so, and do it for us.
Also, reuse some code instead of duplicating it.
(JSC::ASTBuilder::createForOfLoop): Ditto.
(JSC::ASTBuilder::createArrayPattern):
(JSC::ASTBuilder::createObjectPattern):
(JSC::ASTBuilder::createBindingLocation): No need to pass through a VM
pointer, since our callee no longer needs to allocate anything.
(JSC::ASTBuilder::createBreakStatement): Deleted.
(JSC::ASTBuilder::createContinueStatement): Deleted.
* parser/NodeConstructors.h:
(JSC::PropertyNode::PropertyNode):
(JSC::DeconstructionPatternNode::DeconstructionPatternNode):
(JSC::ArrayPatternNode::ArrayPatternNode):
(JSC::ArrayPatternNode::create):
(JSC::ObjectPatternNode::ObjectPatternNode):
(JSC::ObjectPatternNode::create):
(JSC::BindingNode::create):
(JSC::BindingNode::BindingNode):
(JSC::ContinueNode::ContinueNode): Deleted.
(JSC::BreakNode::BreakNode): Deleted.
(JSC::EnumerationNode::EnumerationNode): Deleted.
(JSC::ForInNode::ForInNode): Deleted.
(JSC::ForOfNode::ForOfNode): Deleted. Deleted a bunch of special cases
that don't exist anymore, now that the parser allocates all pieces of
the AST unconditionally.
* parser/Nodes.h: Ditto.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseBreakStatement):
(JSC::Parser<LexerType>::parseContinueStatement): Allocate the null
identifier for our callee, since that is simpler than requiring our
callee to notice that we didn't do so, and do it for us.
(JSC::Parser<LexerType>::parseProperty):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createProperty): No need to pass through a VM
pointer, since our callee no longer needs to allocate anything.
2014-12-03 Zsolt Borbely <zsborbely.u-szeged@partner.samsung.com>
Remove unused JSC runtime options
https://bugs.webkit.org/show_bug.cgi?id=133070
Reviewed by Csaba Osztrogonác.
* runtime/Options.h:
2014-12-02 Mark Lam <mark.lam@apple.com>
Rolling out r176592, r176603, r176616, and r176705 until build and perf issues are resolved.
https://bugs.webkit.org/show_bug.cgi?id=138821
Not reviewed.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::visitChildren):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitComplexPopScopes):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
* ftl/FTLAbbreviations.h:
(JSC::FTL::mdNode):
(JSC::FTL::buildCall):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* parser/Parser.h:
(JSC::Scope::Scope):
* runtime/JSArray.cpp:
(JSC::JSArray::setLengthWithArrayStorage):
(JSC::JSArray::sortCompactedVector):
* tools/ProfileTreeNode.h:
(JSC::ProfileTreeNode::dumpInternal):
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::matchCharacterClass):
2014-12-02 Michael Saboff <msaboff@apple.com>
Change CallFrame::globalThisValue() to not use CallFrame::scope()
https://bugs.webkit.org/show_bug.cgi?id=139202
Reviewed by Mark Lam.
Changed to use the globalThis() on the globalObject associated with the
callee. Moved the inline definition to JSGlobalObject.h instead of
including JSGlobalObject.h in JSScope.h. Also moved it as JSScope
objects are no longer involved in getting the value.
* runtime/JSGlobalObject.h:
(JSC::ExecState::globalThisValue):
* runtime/JSScope.h:
(JSC::ExecState::globalThisValue): Deleted.
2014-12-02 Matthew Mirman <mmirman@apple.com>
Fixes inline cache fast path accessing nonexistant getters.
<rdar://problem/18416918>
https://bugs.webkit.org/show_bug.cgi?id=136961
Reviewed by Filip Pizlo.
Fixes a bug in inline caching where getters would have been able to
modify the property they are getting during
building the inline cache and then accessing that
property through the inline cache site causing a recursive
inline cache building and allowing the fast path of the cache to
try to load a getter for the property that no longer exists.
* jit/JITOperations.cpp: Switched use of get to getPropertySlot.
* runtime/JSCJSValue.h:
added getPropertySlot for when you don't want to perform the get quite yet but want
to fill out the slot.
* runtime/JSCJSValueInlines.h: Added implementation for getPropertySlot
(JSC::JSValue::get): changed to simply call getPropertySlot
(JSC::JSValue::getPropertySlot): added.
* tests/stress/recursive_property_redefine_during_inline_caching.js: Added test case for bug.
(test):
2014-12-01 Michael Saboff <msaboff@apple.com>
Remove GetMyScope node from DFG
https://bugs.webkit.org/show_bug.cgi?id=139166
Reviewed by Oliver Hunt.
Eliminated GetMyScope DFG node type.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::isLiveInBytecode):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileGetMyScope): Deleted.
2014-12-01 Michael Saboff <msaboff@apple.com>
Crash (integer overflow) beneath ByteCodeParser::handleGetById typing in search field on weather.com
https://bugs.webkit.org/show_bug.cgi?id=139165
Reviewed by Oliver Hunt.
If we don't have any getById or putById variants, emit non-cached versions of these operations.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::handlePutById):
2014-12-01 Andreas Kling <akling@apple.com>
Optimize constructing JSC::Identifier from AtomicString.
<https://webkit.org/b/139157>
Reviewed by Michael Saboff.
Add constructors for Identifier taking AtomicString and AtomicStringImpl.
This avoids branching on the string's isAtomic flag, which is obviously
always true for AtomicString & AtomicStringImpl.
Had to add a Identifier(const char*) constructor to resolve implicit
ambiguity between String / AtomicString.
Also made PrivateName::uid() return AtomicStringImpl* to take advantage
of the new constructor in a few places.
* runtime/Identifier.h:
(JSC::Identifier::Identifier):
* runtime/IdentifierInlines.h:
(JSC::Identifier::Identifier):
* runtime/PrivateName.h:
(JSC::PrivateName::uid):
2014-12-01 Alexey Proskuryakov <ap@apple.com>
Several JavaScriptCore date tests are flaky, because they expect time to be frozen during execution
https://bugs.webkit.org/show_bug.cgi?id=139138
Reviewed by Mark Lam.
Merged a fix by Bob Clary.
* tests/mozilla/ecma/Date/15.9.1.1-1.js:
* tests/mozilla/ecma/Date/15.9.1.1-2.js:
* tests/mozilla/ecma/Date/15.9.2.1.js:
* tests/mozilla/ecma/Date/15.9.2.2-1.js:
* tests/mozilla/ecma/Date/15.9.2.2-2.js:
* tests/mozilla/ecma/Date/15.9.2.2-3.js:
* tests/mozilla/ecma/Date/15.9.2.2-4.js:
* tests/mozilla/ecma/Date/15.9.2.2-5.js:
* tests/mozilla/ecma/Date/15.9.2.2-6.js:
2014-11-17 Oliver Hunt <oliver@apple.com>
Make sure range based iteration of Vector<> still receives bounds checking
https://bugs.webkit.org/show_bug.cgi?id=138821
Reviewed by Mark Lam.
There are a few uses of begin()/end() that explicitly require pointers,
so we use getPtr() to extract the underlying pointer generically.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::visitChildren):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitComplexPopScopes):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
* ftl/FTLAbbreviations.h:
(JSC::FTL::mdNode):
(JSC::FTL::buildCall):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* parser/Parser.h:
(JSC::Scope::Scope):
* profiler/ProfileNode.cpp:
(JSC::ProfileNode::debugPrintRecursively):
* runtime/JSArray.cpp:
(JSC::JSArray::setLengthWithArrayStorage):
(JSC::JSArray::sortCompactedVector):
* tools/ProfileTreeNode.h:
(JSC::ProfileTreeNode::dumpInternal):
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::matchCharacterClass):
2014-11-29 Andreas Kling <akling@apple.com>
PropertyTable keys should be AtomicStringImpl.
<https://webkit.org/b/139096>
Reviewed by Sam Weinig.
Since PropertyTable keys are really always Identifiers, switch the key
type from StringImpl* to AtomicStringImpl*.
We have code in the GetByVal opcode implementations that assumes things
about this, so this change adds confidence to those algorithms.
* bytecode/ComplexGetStatus.cpp:
(JSC::ComplexGetStatus::computeFor):
* bytecode/ComplexGetStatus.h:
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFromLLInt):
(JSC::GetByIdStatus::computeFor):
(JSC::GetByIdStatus::computeForStubInfo):
* bytecode/GetByIdStatus.h:
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
(JSC::PutByIdStatus::computeFor):
(JSC::PutByIdStatus::computeForStubInfo):
* bytecode/PutByIdStatus.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGDesiredIdentifiers.cpp:
(JSC::DFG::DesiredIdentifiers::addLazily):
(JSC::DFG::DesiredIdentifiers::at):
* dfg/DFGDesiredIdentifiers.h:
(JSC::DFG::DesiredIdentifiers::operator[]):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::isStringPrototypeMethodSane):
* runtime/Identifier.h:
(JSC::Identifier::impl):
* runtime/IntendedStructureChain.cpp:
(JSC::IntendedStructureChain::mayInterceptStoreTo):
* runtime/IntendedStructureChain.h:
* runtime/PropertyMapHashTable.h:
* runtime/Structure.cpp:
(JSC::StructureTransitionTable::contains):
(JSC::StructureTransitionTable::get):
(JSC::Structure::addPropertyTransitionToExistingStructureImpl):
(JSC::Structure::addPropertyTransitionToExistingStructureConcurrently):
(JSC::Structure::getConcurrently):
(JSC::Structure::add):
(JSC::Structure::remove):
* runtime/Structure.h:
(JSC::PropertyMapEntry::PropertyMapEntry):
* runtime/StructureInlines.h:
(JSC::Structure::getConcurrently):
* runtime/StructureTransitionTable.h:
(JSC::StructureTransitionTable::Hash::hash):
2014-11-28 Gyuyoung Kim <gyuyoung.kim@samsung.com>
Use std::unique_ptr<>|make_unique<> in ftl, bytecode of JSC
https://bugs.webkit.org/show_bug.cgi?id=139063
Reviewed by Andreas Kling.
Clean up OwnPtr and PassOwnPtr in JSC.
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::push):
* bytecode/StructureStubClearingWatchpoint.h:
(JSC::StructureStubClearingWatchpoint::StructureStubClearingWatchpoint):
* ftl/FTLCompile.cpp:
(JSC::FTL::mmAllocateDataSection):
* ftl/FTLJITFinalizer.h:
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* parser/SourceProviderCacheItem.h:
2014-11-27 Gyuyoung Kim <gyuyoung.kim@samsung.com>
Use std::unique_ptr instead of OwnPtr in JSC classes
https://bugs.webkit.org/show_bug.cgi?id=139009
Reviewed by Filip Pizlo.
As a step of using std::unique_ptr<>, this patch replaces OwnPtr with
std::unique_ptr<>|std::make_unique<>.
* bytecode/DFGExitProfile.cpp:
(JSC::DFG::ExitProfile::add):
* bytecode/DFGExitProfile.h:
* bytecode/LazyOperandValueProfile.cpp:
(JSC::CompressedLazyOperandValueProfileHolder::add):
* bytecode/LazyOperandValueProfile.h:
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::specializedSweep):
(JSC::MarkedBlock::stopAllocating):
* heap/MarkedBlock.h:
(JSC::MarkedBlock::clearNewlyAllocated):
* inspector/ContentSearchUtilities.cpp:
(Inspector::ContentSearchUtilities::findMagicComment):
* runtime/RegExp.cpp:
(JSC::RegExp::invalidateCode):
* runtime/RegExp.h:
* yarr/RegularExpression.cpp:
(JSC::Yarr::RegularExpression::Private::compile):
(JSC::Yarr::RegularExpression::isValid):
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::ByteCompiler::compile):
(JSC::Yarr::ByteCompiler::regexBegin):
(JSC::Yarr::byteCompile):
* yarr/YarrInterpreter.h:
(JSC::Yarr::BytecodePattern::BytecodePattern):
2014-11-24 Gyuyoung Kim <gyuyoung.kim@samsung.com>
Clean up OwnPtr and PassOwnPtr in JSC - bytecode, jit, inspector, and interpreter
https://bugs.webkit.org/show_bug.cgi?id=139022
Reviewed by Filip Pizlo.
As a step of using std::unique_ptr<>, this patch replaces OwnPtr with
std::unique_ptr<>|std::make_unique<>.
* bytecode/DFGExitProfile.cpp:
(JSC::DFG::ExitProfile::add):
* bytecode/DFGExitProfile.h:
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::linkFunction):
* dfg/DFGJITFinalizer.cpp:
(JSC::DFG::JITFinalizer::JITFinalizer):
* dfg/DFGJITFinalizer.h:
* heap/IncrementalSweeper.h:
* inspector/ContentSearchUtilities.cpp:
(Inspector::ContentSearchUtilities::findMagicComment):
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/JSGlobalObjectRuntimeAgent.h:
* interpreter/Interpreter.cpp:
(JSC::Interpreter::enableSampler):
* interpreter/Interpreter.h:
* jit/ExecutableAllocator.cpp:
(JSC::ExecutableAllocator::ExecutableAllocator):
* jit/ExecutableAllocator.h:
2014-11-22 Gyuyoung Kim <gyuyoung.kim@samsung.com>
Clean up OwnPtr and PassOwnPtr in some of JS classes
https://bugs.webkit.org/show_bug.cgi?id=138724
Reviewed by Filip Pizlo.
As a step to use std::unique_ptr<> and std::make_unique<>, this patch replaces
OwnPtr with std::unique_ptr<>. Besides create() factory function is removed as well.
* builtins/BuiltinExecutables.h:
(JSC::BuiltinExecutables::create): Deleted.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::createRareDataIfNecessary):
* bytecode/StructureStubInfo.h:
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::hasRareData):
(JSC::UnlinkedCodeBlock::createRareDataIfNecessary):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
* runtime/CodeCache.h:
(JSC::CodeCache::create): Deleted.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::clearRareData):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::createRareDataIfNeeded):
* runtime/RegExpConstructor.h:
* runtime/SmallStrings.cpp:
(JSC::SmallStrings::createSingleCharacterString):
(JSC::SmallStrings::singleCharacterStringRep):
* runtime/SmallStrings.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2014-11-21 Michael Saboff <msaboff@apple.com>
r176455: ASSERT(!m_vector.isEmpty()) in IntendedStructureChain.cpp(143)
https://bugs.webkit.org/show_bug.cgi?id=139000
Reviewed by Darin Adler.
Check that the chainCount is non-zero before using a StructureChain.
* bytecode/ComplexGetStatus.cpp:
(JSC::ComplexGetStatus::computeFor):
2014-11-21 Michael Saboff <msaboff@apple.com>
Allocate local ScopeChain register
https://bugs.webkit.org/show_bug.cgi?id=138793
Reviewed by Geoffrey Garen.
Now we allocate the scope register as a local. The allocated register is stored in the
CodeBlock for use by other components. Update the DFG to work with a local scope register.
Changed usage of JSStack::ScopeChain access to the CallFrame header to use the allocated
local register.
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
Updated to properly represent the operand inputs and bytecode result.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::setScopeRegister):
(JSC::CodeBlock::scopeRegister):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::setScopeRegister):
(JSC::UnlinkedCodeBlock::scopeRegister):
Added scope register member and accessors.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::allocateAndEmitScope):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::scopeRegister):
Change m_scopeRegister to an allocated register. Added allocateAndEmitScope helper to
allocate the scope register, set the CodeBlock with its value and emit op_get_scope.
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::scope): Changed to access the scope using the new convention.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::get):
(JSC::DFG::ByteCodeParser::flush):
(JSC::DFG::ByteCodeParser::inlineCall):
(JSC::DFG::ByteCodeParser::parseBlock):
Changed op_create_lexical_environment to set the scope VirtualRegister operand.
Filled out op_get_scope processing to emit a GetScope node putting the result in
the scope VirtualRegister result operand.
Added Phantoms where appropriate to keep the Scope register alive in places where
it use is optimized away, but where the baseline JIT would need to use its value.
Eliminated uses of JSStack::ScopeChain.
* dfg/DFGStackLayoutPhase.cpp:
(JSC::DFG::StackLayoutPhase::run):
Make sure that the scope register stack location is allocated using the same place
that the codeBlock expects.
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
Allow strength reduction of Flush to skip of GetScope nodes looking for a prior
corresponding SetLocal.
* interpreter/CallFrame.h:
(JSC::ExecState::scope):
(JSC::ExecState::setScope):
Added new scope() and setScope() helpers that take a VirtualRegister offset.
* interpreter/Interpreter.cpp:
(JSC::eval):
Changed eval() to get the scope from the caller's scope register instead of from the
temporary frame created for eval.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::unwind):
Changed unwind() to manipulate the scope n the allocated register instead of from the
call frame slot.
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::readNonInlinedFrame):
(JSC::StackVisitor::readInlinedFrame):
* interpreter/StackVisitor.h:
(JSC::StackVisitor::Frame::callee):
(JSC::StackVisitor::Frame::scope): Deleted.
Eliminated the scope member as it needed to change and no StackVisitor users use it.
* jit/JITOperations.cpp:
(JSC::operationPushNameScope):
(JSC::operationPushWithScope):
* runtime/JSNameScope.h:
(JSC::JSNameScope::create):
* runtime/JSWithScope.h:
(JSC::JSWithScope::create): Deleted.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
Deleted JSNameScope::create() and JSWithScope::create() flavors tht used the ScopeChain slot
in the CallFrame header. Changed the only user of these function, op_push_name_scope and
op_push_with_scope helpers, to use the remaining create variants that require explicit scope.
Those operations get the scope from the register pointed to by their scope operands.
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
Changed resolveScope to use the allocated register.
2014-11-21 Csaba Osztrogonác <ossy@webkit.org>
[JSC] Disable verifyHeap
https://bugs.webkit.org/show_bug.cgi?id=138962
Reviewed by Mark Lam.
* runtime/Options.h:
2014-11-20 Mark Lam <mark.lam@apple.com>
Add some comments to describe the DFG UseKind representations.
<https://webkit.org/b/138934>
Reviewed by Filip Pizlo.
* dfg/DFGUseKind.h:
- Also regrouped the UseKind enums by representation to be more readable.
2014-11-20 Mark Lam <mark.lam@apple.com>
Add Heap verification infrastructure.
<https://webkit.org/b/138851>
Reviewed by Geoffrey Garen.
The verification infrastructure code is always built in but disabled by
default. When disabled, the cost is minimal:
1. Heap has a m_verifier field.
2. GC does a few "if (m_verifier)" checks that should fail.
3. HeapVerifier takes up code space though not used.
When enabled:
1. The HeapVerifier will keep N number of GC cycle data.
Each GC cycle will contain a "before marking" and "after marking" live
object list.
The GC cycles is a circular buffer. Only data for the last N GC cycles
will be retained.
2. During GC, the current GC cycle's live objects lists will be populated
before and after marking.
3. The current GC cycle's live object lists will be validated before GC,
after marking, and after GC.
Currently, the only validation being done is to verify that object
butterflies are allocated from valid blocks in the Storage (aka Copied)
space.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::collect):
* heap/Heap.h:
* heap/HeapVerifier.cpp: Added.
(JSC::LiveObjectList::findObject):
(JSC::HeapVerifier::HeapVerifier):
(JSC::HeapVerifier::collectionTypeName):
(JSC::HeapVerifier::phaseName):
(JSC::getButterflyDetails):
(JSC::HeapVerifier::initializeGCCycle):
(JSC::GatherLiveObjFunctor::GatherLiveObjFunctor):
(JSC::GatherLiveObjFunctor::operator()):
(JSC::HeapVerifier::gatherLiveObjects):
(JSC::HeapVerifier::liveObjectListForGathering):
(JSC::trimDeadObjectsFromList):
(JSC::HeapVerifier::trimDeadObjects):
(JSC::HeapVerifier::verifyButterflyIsInStorageSpace):
(JSC::HeapVerifier::verify):
(JSC::HeapVerifier::reportObject):
(JSC::HeapVerifier::checkIfRecorded):
* heap/HeapVerifier.h: Added.
(JSC::LiveObjectData::LiveObjectData):
(JSC::LiveObjectList::LiveObjectList):
(JSC::LiveObjectList::reset):
(JSC::HeapVerifier::GCCycle::GCCycle):
(JSC::HeapVerifier::GCCycle::collectionTypeName):
(JSC::HeapVerifier::incrementCycle):
(JSC::HeapVerifier::currentCycle):
(JSC::HeapVerifier::cycleForIndex):
* runtime/Options.h:
2014-11-20 Yusuke Suzuki <utatane.tea@gmail.com>
Rename String.prototype.contains to String.prototype.includes
https://bugs.webkit.org/show_bug.cgi?id=138923
As per the latest TC39 meeting[1, 2], String.prototype.contains is
renamed to String.prototype.includes. This is because the name
`contains` breaks the web since it conflicts with existing `contains`
implementations in major libraries.
[1]: https://github.com/mathiasbynens/String.prototype.includes
[2]: https://github.com/tc39/test262/pull/119
Reviewed by Geoffrey Garen.
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
(JSC::stringProtoFuncIncludes):
(JSC::stringProtoFuncContains): Deleted.
2014-11-19 Mark Lam <mark.lam@apple.com>
WTFCrashWithSecurityImplication under SpeculativeJIT::compile() when loading a page from theblaze.com.
<https://webkit.org/b/137642>
Reviewed by Filip Pizlo.
In the DFG, we have a ConstantFolding phase that occurs after all LocalCSE
phases have already transpired. Hence, Identity nodes introduced in the
ConstantFolding phase will be left in the node graph. Subsequently, the
DFG code generator asserts that CSE phases have consumed all Identity nodes.
This turns out to not be true. Hence, the crash. We fix this by teaching
the DFG code generator to emit code for Identity nodes.
Unlike the DFG, the FTL does not have this issue. That is because the FTL
plan has GlobalCSE phases that come after ConstantFolding and any other
phases that can generate Identity nodes. Hence, for the FTL, it is true that
CSE will consume all Identity nodes, and the code generator should not see any
Identity nodes.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
2014-11-19 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: JSContext inspection Resource search does not work
https://bugs.webkit.org/show_bug.cgi?id=131252
Reviewed by Timothy Hatcher.
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::searchInContent):
* inspector/protocol/Debugger.json:
Do some cleanup of the description and implementation of content searching.
2014-11-19 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Provide $exception in the console for the thrown exception value
https://bugs.webkit.org/show_bug.cgi?id=138726
Reviewed by Timothy Hatcher.
* debugger/DebuggerScope.cpp:
(JSC::DebuggerScope::caughtValue):
* debugger/DebuggerScope.h:
Access the caught value if this scope is a catch scope.
* runtime/JSNameScope.h:
(JSC::JSNameScope::isFunctionNameScope):
(JSC::JSNameScope::isCatchScope):
(JSC::JSNameScope::value):
Provide an accessor for the single value in the JSNameScope (with / catch block).
* inspector/InjectedScriptSource.js:
Save the exception value and expose it via $exception. Since the command line api
is recreated on each evaluation, $exception is essentially readonly.
* inspector/ScriptDebugServer.h:
* inspector/ScriptDebugServer.cpp:
(Inspector::ScriptDebugServer::dispatchDidPause):
(Inspector::ScriptDebugServer::exceptionOrCaughtValue):
When pausing, get the exception or caught value. The exception will be provided
if we are breaking on an explicit exception. When inside of a catch block, we
can get the caught value by walking up the scope chain.
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::InspectorDebuggerAgent):
(Inspector::InspectorDebuggerAgent::resume):
(Inspector::InspectorDebuggerAgent::stepOver):
(Inspector::InspectorDebuggerAgent::stepInto):
(Inspector::InspectorDebuggerAgent::stepOut):
Clearing state can be done in didContinue.
(Inspector::InspectorDebuggerAgent::didPause):
Set the exception value explicitly in the injected script when we have it.
(Inspector::InspectorDebuggerAgent::didContinue):
Clear state saved when we had paused, including clearly an exception value if needed.
(Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
(Inspector::InspectorDebuggerAgent::clearExceptionValue):
Call into the injected script only when needed.
* inspector/InjectedScript.cpp:
(Inspector::InjectedScript::setExceptionValue):
(Inspector::InjectedScript::clearExceptionValue):
* inspector/InjectedScript.h:
* inspector/InjectedScriptManager.cpp:
(Inspector::InjectedScriptManager::clearExceptionValue):
* inspector/InjectedScriptManager.h:
Clear on all injected scripts.
2014-11-19 Joseph Pecoraro <pecoraro@apple.com>
Unreviewed build fixes after r176329.
- export all of the codegen python files as they are included by the main generator
- update the imports of the main generator to match __init__.py
- remove bundling the python scripts as framework resources, just have them PrivateHeaders
* JavaScriptCore.xcodeproj/project.pbxproj:
* inspector/scripts/generate-inspector-protocol-bindings.py:
2014-11-18 Brian J. Burg <burg@cs.washington.edu>
Web Inspector: standardize language-specific protocol generator file, class, and method prefixes
https://bugs.webkit.org/show_bug.cgi?id=138237
Reviewed by Joseph Pecoraro.
Settle on cpp/objc/js file prefixes and Cpp/ObjC/JS class prefixes for generators.
Move C++-specific static methods into CppGenerator and add cpp_ prefixes where relevant.
Split the templates file into language-specific template files.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* inspector/scripts/codegen/__init__.py:
* inspector/scripts/codegen/cpp_generator.py: Copied from Source/JavaScriptCore/inspector/scripts/codegen/generator.py.
* inspector/scripts/codegen/cpp_generator_templates.py: Copied from Source/JavaScriptCore/inspector/scripts/codegen/generator_templates.py.
(CppGeneratorTemplates):
* inspector/scripts/codegen/generate_cpp_alternate_backend_dispatcher_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_alternate_backend_dispatcher_header.py.
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_backend_dispatcher_header.py.
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_backend_dispatcher_implementation.py.
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_frontend_dispatcher_header.py.
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_frontend_dispatcher_implementation.py.
* inspector/scripts/codegen/generate_cpp_protocol_types_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_protocol_types_header.py.
* inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_protocol_types_implementation.py.
* inspector/scripts/codegen/generate_js_backend_commands.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_backend_commands.py.
* inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_backend_dispatcher_header.py.
* inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_backend_dispatcher_implementation.py.
* inspector/scripts/codegen/generate_objc_configuration_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_configuration_header.py.
* inspector/scripts/codegen/generate_objc_configuration_implementation.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_configuration_implementation.py.
* inspector/scripts/codegen/generate_objc_conversion_helpers.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_conversion_helpers.py.
* inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_frontend_dispatcher_implementation.py.
* inspector/scripts/codegen/generate_objc_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_header.py.
* inspector/scripts/codegen/generate_objc_internal_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_internal_header.py.
* inspector/scripts/codegen/generate_objc_protocol_types_implementation.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_types_implementation.py.
* inspector/scripts/codegen/generator.py:
* inspector/scripts/codegen/generator_templates.py:
* inspector/scripts/codegen/objc_generator.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c.py.
* inspector/scripts/codegen/objc_generator_templates.py: Added.
* inspector/scripts/generate-inspector-protocol-bindings.py:
2014-11-19 Juergen Ributzka <juergen@apple.com>
Update WebKit to build with LLVM TOT
https://bugs.webkit.org/show_bug.cgi?id=138519
Reviewed by Alexey Proskuryakov.
* Configurations/LLVMForJSC.xcconfig:
* llvm/LLVMAPIFunctions.h:
* llvm/library/LLVMExports.cpp:
(initializeAndGetJSCLLVMAPI):
2014-11-18 David Kilzer <ddkilzer@apple.com>
FeatureDefines.xcconfig: Switch from using PLATFORM_NAME to SDK selectors
<http://webkit.org/b/138813>
Reviewed by Mark Rowe.
* Configurations/FeatureDefines.xcconfig: Switch to using SDK
selectors.
2014-11-18 Chris Dumez <cdumez@apple.com>
Update the Vector API to deal with unsigned types instead of size_t
https://bugs.webkit.org/show_bug.cgi?id=138824
Reviewed by Andreas Kling.
Update code base to fix build errors related to the typing changes
in the Vector API (size_t -> unsigned).
* bytecode/PreciseJumpTargets.cpp:
* replay/EncodedValue.h:
2014-11-18 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r176207.
https://bugs.webkit.org/show_bug.cgi?id=138836
Not ready yet (Requested by ap on #webkit).
Reverted changeset:
"Update WebKit to build with LLVM TOT"
https://bugs.webkit.org/show_bug.cgi?id=138519
http://trac.webkit.org/changeset/176207
2014-11-17 Mark Lam <mark.lam@apple.com>
Add printing functionality in JITted code for debugging purposes.
<https://webkit.org/b/138660>
Reviewed by Geoffrey Garen.
Sometimes, for debugging, it'd be nice to be able to just print the
values of constants or registers used in JITted code, or even just
a string to log that certain pieces of JITted code have been executed.
Using the JIT probe mechanism, we can make this happen.
* assembler/ARMv7Assembler.h:
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::CPUState::registerName):
(JSC::AbstractMacroAssembler::CPUState::registerValue):
(JSC::AbstractMacroAssembler::print):
(JSC::AbstractMacroAssembler::PrintArg::PrintArg):
(JSC::AbstractMacroAssembler::appendPrintArg):
(JSC::AbstractMacroAssembler::printInternal):
(JSC::AbstractMacroAssembler::printCallback):
* assembler/MacroAssemblerARM.cpp:
(JSC::MacroAssemblerARM::printCPURegisters):
(JSC::MacroAssemblerARM::printRegister):
* assembler/MacroAssemblerARM.h:
* assembler/MacroAssemblerARMv7.cpp:
(JSC::MacroAssemblerARMv7::printCPURegisters):
(JSC::MacroAssemblerARMv7::printRegister):
* assembler/MacroAssemblerARMv7.h:
* assembler/MacroAssemblerX86Common.cpp:
(JSC::MacroAssemblerX86Common::printRegister):
* assembler/MacroAssemblerX86Common.h:
2014-11-17 Anders Carlsson <andersca@apple.com>
Fix JavaScriptCore build with newer versions of clang.
<rdar://problem/18978716>
* heap/Heap.cpp:
(JSC::Heap::visitTempSortVectors):
(JSC::Heap::deleteAllCompiledCode): Deleted.
* inspector/agents/InspectorConsoleAgent.h:
2014-11-17 Juergen Ributzka <juergen@apple.com>
Update WebKit to build with LLVM TOT
https://bugs.webkit.org/show_bug.cgi?id=138519
Reviewed by Alexey Proskuryakov.
* Configurations/LLVMForJSC.xcconfig:
* llvm/LLVMAPIFunctions.h:
* llvm/library/LLVMExports.cpp:
(initializeAndGetJSCLLVMAPI):
2014-11-14 Benjamin Poulain <bpoulain@apple.com>
STRH can store values with the wrong offset
https://bugs.webkit.org/show_bug.cgi?id=138723
Reviewed by Michael Saboff.
This is the counterpart of r176083 for the str instruction.
I believe this code is currently unreachable because there is only one client of strh()
in the MacroAssembler and it always setup the scale explicitely.
* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::strh):
2014-11-13 Mark Lam <mark.lam@apple.com>
Reduce amount of cut-and-paste needed for probe mechanism implementations.
<https://webkit.org/b/138671>
Reviewed by Geoffrey Garen.
The existing code requires that each MacroAssembler implementation provide
their own copy of all of the probe implementations even when most of it is
identical. This patch hoists the common parts into AbstractMacroAssembler
(with some minor renaming). Each target specific MacroAssembler now only
need to implement a few target specific methods that are expected by and
documented in AbstractMacroAssembler.h in the ENABLE(MASM_PROBE) section.
In this patch, I also simplified the X86 and X86_64 ports to use the same
port implementation. The ARMv7 probe implementation should not conditionally
exclude the higher FP registers (since the JIT doesn't). Fixed the ARMv7
probe code to include the higher FP registers always.
This is all done in preparation to add printing functionality in JITted code
for debugging.
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::Label::Label):
(JSC::AbstractMacroAssembler::ConvertibleLoadLabel::ConvertibleLoadLabel):
(JSC::AbstractMacroAssembler::DataLabelPtr::DataLabelPtr):
(JSC::AbstractMacroAssembler::DataLabel32::DataLabel32):
(JSC::AbstractMacroAssembler::DataLabelCompact::DataLabelCompact):
(JSC::AbstractMacroAssembler::Jump::link):
(JSC::AbstractMacroAssembler::Jump::linkTo):
(JSC::AbstractMacroAssembler::JumpList::link):
(JSC::AbstractMacroAssembler::JumpList::linkTo):
(JSC::AbstractMacroAssembler::ProbeContext::print):
(JSC::AbstractMacroAssembler::printIndent):
(JSC::AbstractMacroAssembler::printCPU):
(JSC::AbstractMacroAssembler::CachedTempRegister::CachedTempRegister):
- Except for the 3 printing methods (which are for the probe), the rest
are touched simply because we need to add the MacroAssemblerType to the
template args.
The MacroAssemblerType is used by the abstract probe code to call the
few probe methods that need to have CPU specific implementations.
* assembler/MacroAssemblerARM.cpp:
(JSC::MacroAssemblerARM::printCPURegisters):
- This was refactored from ProbeContext::dumpCPURegisters() which no
longer exists.
(JSC::MacroAssemblerARM::ProbeContext::dumpCPURegisters): Deleted.
(JSC::MacroAssemblerARM::ProbeContext::dump): Deleted.
* assembler/MacroAssemblerARM.h:
* assembler/MacroAssemblerARM64.h:
* assembler/MacroAssemblerARMv7.cpp:
(JSC::MacroAssemblerARMv7::printCPURegisters):
- This was refactored from ProbeContext::dumpCPURegisters() which no
longer exists.
(JSC::MacroAssemblerARMv7::ProbeContext::dumpCPURegisters): Deleted.
(JSC::MacroAssemblerARMv7::ProbeContext::dump): Deleted.
* assembler/MacroAssemblerARMv7.h:
* assembler/MacroAssemblerMIPS.h:
* assembler/MacroAssemblerSH4.h:
* assembler/MacroAssemblerX86.h:
(JSC::MacroAssemblerX86::trustedImm32FromPtr): Deleted.
(JSC::MacroAssemblerX86::probe): Deleted.
* assembler/MacroAssemblerX86Common.cpp:
(JSC::MacroAssemblerX86Common::printCPURegisters):
- This was refactored from ProbeContext::dumpCPURegisters() which no
longer exists.
(JSC::MacroAssemblerX86Common::probe):
- This implementation of probe() is based on the one originally in
MacroAssemblerX86_64.h. It is generic and should work for both
32-bit and 64-bit.
(JSC::MacroAssemblerX86Common::ProbeContext::dumpCPURegisters): Deleted.
(JSC::MacroAssemblerX86Common::ProbeContext::dump): Deleted.
* assembler/MacroAssemblerX86Common.h:
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::trustedImm64FromPtr): Deleted.
(JSC::MacroAssemblerX86_64::probe): Deleted.
* jit/JITStubsARMv7.h:
2014-11-13 Michael Saboff <msaboff@apple.com>
Add scope operand to op_new_func* byte codes
https://bugs.webkit.org/show_bug.cgi?id=138707
Reviewed by Mark Lam.
Added scope operand to op_new_func and op_new_func_expr to replace the implicit use
of exec->scope().
* bytecode/BytecodeList.json: Increased size of op_new_func & op_new_func_expr bytecodes.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode): Added scope operand to dump output.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitNewFunctionInternal):
(JSC::BytecodeGenerator::emitNewFunctionExpression):
Emit scope operand.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
Added new scope source nodes to NewFunction, NewFunctionExpression & NewFunctionNoCheck.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewFunctionNoCheck):
(JSC::DFG::SpeculativeJIT::compileNewFunctionExpression):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
Use scope children when making new function JIT_Operation calls. Use JSScope* value instead of
exec->scope().
* dfg/DFGOperations.h:
* dfg/DFGOperations.cpp:
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_new_func):
(JSC::JIT::emit_op_new_func_exp):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
Added new Jsc JIT_Operation parameter type for JSScope* values. Created declarations and
definitions for new JIT_Operations with Jsc parameters. Use the JSScope* parameters in lieu
of exec->scope() in operationNewFunction().
Removed comment for unused Jsa (JSLexicalEnvironment*) JIT_Operation parameter type.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
Use the scope operand instead of exec->scope().
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
Changed the operand indecies for added scope operand.
2014-11-13 Mark Lam <mark.lam@apple.com>
Change X86/64 JIT probes to save/restore xmm regs as double instead of __m128. [Follow up]
<https://webkit.org/b/138708>
Reviewed by Michael Saboff.
Removed a stale comment and a now unnecessary #include.
* assembler/X86Assembler.h:
2014-11-13 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r176087.
https://bugs.webkit.org/show_bug.cgi?id=138714
Broke the build (Requested by ap on #webkit).
Reverted changeset:
"Update WebKit to build with LLVM TOT"
https://bugs.webkit.org/show_bug.cgi?id=138519
http://trac.webkit.org/changeset/176087
2014-11-13 Mark Lam <mark.lam@apple.com>
Change X86/64 JIT probes to save/restore xmm regs as double instead of __m128.
<https://webkit.org/b/138708>
Reviewed by Michael Saboff.
The JIT code only uses the xmm regs as double registers. This patch changes
the storage types of the FP registers in X86Assembler.h to double instead of
__m128, and updates the X86 and X86_64 JIT probe implementations accordingly.
Also made some minor cosmetic changes in the output of the probe dump functions.
* assembler/MacroAssemblerX86Common.cpp:
(JSC::MacroAssemblerX86Common::ProbeContext::dumpCPURegisters):
* assembler/X86Assembler.h:
* jit/JITStubsX86.h:
* jit/JITStubsX86Common.h:
* jit/JITStubsX86_64.h:
2014-11-13 Juergen Ributzka <juergen@apple.com>
Update WebKit to build with LLVM TOT
https://bugs.webkit.org/show_bug.cgi?id=138519
Reviewed by Geoffrey Garen.
* Configurations/LLVMForJSC.xcconfig:
* llvm/LLVMAPIFunctions.h:
* llvm/library/LLVMExports.cpp:
(initializeAndGetJSCLLVMAPI):
2014-11-13 Benjamin Poulain <benjamin@webkit.org>
ARMv7(s) Assembler: LDRH with immediate offset is loading from the wrong offset
https://bugs.webkit.org/show_bug.cgi?id=136914
Reviewed by Michael Saboff.
TLDR: the immediate offset of half-word load was divided by 2.
Story time: So I started getting those weird reports of :nth-child() behaving bizarrely
on ARMv7 and ARMv7s. To make things worse, the behavior changes depending on style updates.
I started looking the disassembly on the tests cases...
The first thing I noticed was that the computation of An+B looked wrong. For example,
in the case of n+6, the instruction should have been:
subs r1, r1, #6
but was
subs r1, r1, #2
After spending a lot of time trying to find the error in the assembler, I discovered
the problem was not real, but just a bug in the disassembler.
This is the first fix: ARMv7DOpcodeAddSubtractImmediate3's immediate3() was truncating
the value to 2 bits instead of 3 bits.
The disassembler being fixed, I still have no lead on the weird bug. Some disassembly later,
I realize the LDRH instruction is not decoded at all. The reason is that both LDRH and STRH
were under the umbrella ARMv7DOpcodeLoadStoreRegisterImmediateHalfWord but the pattern
only matched SRTH.
I fix that next, ARMv7DOpcodeLoadStoreRegisterImmediateHalfWord is split into
ARMv7DOpcodeStoreRegisterImmediateHalfWord and ARMv7DOpcodeLoadRegisterImmediateHalfWord,
each with their own pattern and their instruction group.
Now that I can see the LDRHs correctly, there is something fishy about them, their offset
is way too small for the data I load.
This time, looking at the binary, the generated code is indeed incorrect. It turns out that
the ARMv7 assembler shifted the offset of half-word load as if they were byte load: divided by 4.
As a result, all the load of half-words with more than zero offset were loading
values with a smaller offset than what they should have.
That being fixed, I dump the assembly: still wrong. I am ready to throw my keyboard through
my screen at that point.
Looking at the disassembler, there is yet again a bug. The computation of the scale() adjustment
of the offset was incorrect for anything but word loads.
I replaced it by a switch-case to make it explicit.
STRH is likely incorrect too. I'll fix that in a follow up, I want to survey all the 16 bits cases
that are not directly used by the CSS JIT.
* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::ldrh):
Fix the immediate scaling. Add an assertion to make sure the alignment of the input is correct.
* disassembler/ARMv7/ARMv7DOpcode.cpp:
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::scale):
Fix the scaling code. Just hardcode instruction-to-scale table.
* disassembler/ARMv7/ARMv7DOpcode.h:
(JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate3::immediate3):
The mask for a 3 bits immediate is not 3 :)
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::scale): Deleted.
2014-11-13 Andreas Kling <akling@apple.com>
Generate put_by_id for bracket assignment with constant string subscript.
<https://webkit.org/b/138702>
Reviewed by Geoffrey Garen.
Transform o["f"]=x to o.f=x when generating bytecode. This allows our JIT
to inline-cache those accesses instead of always dropping out to C++.
Just like the get_by_id transformations, this gets a bunch of use on
real-web content (and Speedometer) but little/none on raw JS benchmarks.
* bytecompiler/NodesCodegen.cpp:
(JSC::AssignBracketNode::emitBytecode):
2014-11-12 Mark Lam <mark.lam@apple.com>
Create canonical lists of registers used by both the Assemblers and the JIT probes.
<https://webkit.org/b/138681>
Reviewed by Filip Pizlo.
* assembler/ARMAssembler.h:
* assembler/ARMv7Assembler.h:
* assembler/X86Assembler.h:
- The FP register storage type is still defined as __m128 because the JIT
probe code still expects that amount of storage to be available. Will
change this to double when the JIT probe code is updated accordingly in a
later patch.
2014-11-12 Andreas Kling <akling@apple.com>
Generate get_by_id for bracket access with constant string subscript.
<https://webkit.org/b/138663>
Reviewed by Michael Saboff.
Transform o["f"] into o.f when generating bytecode. This allows our JIT
to inline-cache those accesses instead of always dropping out to C++.
This is surprisingly common in real-web content, less so in benchmarks.
Interestingly, Speedometer does hit the optimization quite a bit.
* bytecompiler/NodesCodegen.cpp:
(JSC::BracketAccessorNode::emitBytecode):
2014-11-12 Mark Lam <mark.lam@apple.com>
Rename USE(MASM_PROBE) to ENABLE(MASM_PROBE).
<https://webkit.org/b/138661>
Reviewed by Michael Saboff.
Also move the switch for enabling the use of MASM_PROBE from JavaScriptCore's
config.h to WTF's Platform.h. This ensures that the setting is consistently
applied even when building WebCore parts as well.
* assembler/ARMAssembler.h:
* assembler/ARMv7Assembler.h:
* assembler/MacroAssemblerARM.cpp:
* assembler/MacroAssemblerARM.h:
* assembler/MacroAssemblerARMv7.cpp:
* assembler/MacroAssemblerARMv7.h:
* assembler/MacroAssemblerX86.h:
* assembler/MacroAssemblerX86Common.cpp:
* assembler/MacroAssemblerX86Common.h:
* assembler/MacroAssemblerX86_64.h:
* assembler/X86Assembler.h:
* config.h:
* jit/JITStubs.h:
* jit/JITStubsARM.h:
* jit/JITStubsARMv7.h:
* jit/JITStubsX86.h:
* jit/JITStubsX86Common.h:
* jit/JITStubsX86_64.h:
2014-11-12 peavo@outlook.com <peavo@outlook.com>
[WinCairo] Incorrect names for test executables in debug mode.
https://bugs.webkit.org/show_bug.cgi?id=138659
Reviewed by Alex Christensen.
In debug mode, jsc.exe, and testapi.exe are not created, causing JSC test failures.
* JavaScriptCore.vcxproj/jsc/jscLauncher.vcxproj:
* JavaScriptCore.vcxproj/testapi/testapiLauncher.vcxproj:
2014-11-11 Michael Saboff <msaboff@apple.com>
Change DFG to use scope operand for op_resolve_scope
https://bugs.webkit.org/show_bug.cgi?id=138651
Reviewed by Geoffrey Garen.
Changed to use the provided scope VirtualRegister.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::getScope): Changed to use an argument scope register.
(JSC::DFG::ByteCodeParser::parseBlock): Created VirtualRegister from scope operand.
2014-11-11 Gyuyoung Kim <gyuyoung.kim@samsung.com>
Remove IncrementalSweeper::create()
https://bugs.webkit.org/show_bug.cgi?id=138243
Reviewed by Filip Pizlo.
As a step to use std::unique_ptr<> and std::make_unique<>, this patch removes
IncrementalSweeper::create(), then set constructor of IncrementalSweeper to public.
Now we begins to use std::make_unique<> to create IncrementalSweeper instance.
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::setIncrementalSweeper):
* heap/Heap.h:
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::create): Deleted.
* heap/IncrementalSweeper.h:
2014-11-11 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Handle activating extra agents properly after inspector has connected
https://bugs.webkit.org/show_bug.cgi?id=138639
Reviewed by Timothy Hatcher.
Instead of having the protocol configuration directly add the extra agent
to the inspector registry, isntead go through the augmentable controller.
The controller will initialize as required if we are already connected or not,
and will add to the registry.
The functional change here is that the frontend can be notified to activate
extra agents multiple times as agents eventually become available.
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
* inspector/JSGlobalObjectInspectorController.h:
* inspector/agents/InspectorAgent.cpp:
(Inspector::InspectorAgent::activateExtraDomain):
* inspector/agents/InspectorAgent.h:
* inspector/augmentable/AugmentableInspectorController.h:
* inspector/scripts/codegen/generator_templates.py:
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
Rebased results.
2014-11-11 Michael Saboff <msaboff@apple.com>
Use scope register when processing op_resolve_scope in LLInt and Baseline JIT
https://bugs.webkit.org/show_bug.cgi?id=138637
Reviewed by Mark Lam.
Filled out op_resolve_scope processing to use the scope operand to access the current
scope chain.
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
Added scope virtual register parameter to emitResolveClosure(). Added new callOperation() to
support the additional argument.
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitResolveClosure):
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emitSlow_op_resolve_scope):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emitResolveClosure):
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emitSlow_op_resolve_scope):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
Added "scope" parameter to emitResolveClosure(). Passed scope register index to slow path.
Used scope virtual register instead of JSStack::ScopeChain.
2014-11-11 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Don't require a debugger be attached for inspector auto attach
https://bugs.webkit.org/show_bug.cgi?id=138638
Reviewed by Timothy Hatcher.
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::updateDebuggableAutomaticInspectCandidate):
2014-11-11 Akos Kiss <akiss@inf.u-szeged.hu>
Handle cases in StackVisitor::Frame::existingArguments() when lexicalEnvironment and/or unmodifiedArgumentsRegister is not set up yet
https://bugs.webkit.org/show_bug.cgi?id=138543
Reviewed by Geoffrey Garen.
Exception fuzzing may may raise exceptions in places where they would be
otherwise impossible. Therefore, a callFrame may lack activation even if
the codeBlock signals need of activation. Also, even if codeBlock
signals the use of arguments, the unmodifiedArgumentsRegister may not be
initialized yet (neither locally nor in lexicalEnvironment).
If codeBlock()->needsActivation() is false, unmodifiedArgumentsRegister
is already checked for Undefined. This patch applies the same check when
the condition is true (and also checks whether
callFrame()->hasActivation()).
* interpreter/CallFrame.h:
(JSC::ExecState::hasActivation):
Moved to interpreter/CallFrameInlines.h.
* interpreter/CallFrameInlines.h:
(JSC::CallFrame::hasActivation):
Fixed to verify that the JSValue returned by uncheckedActivation() is a
cell.
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::existingArguments):
2014-11-11 Andreas Kling <akling@apple.com>
Another assertion fix for debug builds after r175846.
generateByIdStub() can now be called with an empty prototype chain
if kind == GetUndefined, so tweak the assertion to cover that.
* jit/Repatch.cpp:
(JSC::generateByIdStub):
2014-11-10 Andreas Kling <akling@apple.com>
Assertion fix for debug builds after r175846.
PropertySlot::slotBase() will assert if the slot is unset, so reorder
the tests to check for isCacheableValue() first.
* jit/Repatch.cpp:
(JSC::tryCacheGetByID):
2014-11-10 Andreas Kling <akling@apple.com>
The JIT should cache property lookup misses.
<https://webkit.org/b/135578>
Add support for inline caching of missed property lookups.
Previously this would banish us to C++ slow path.
It's implemented as a simple GetById cache that returns jsUndefined()
as long as the Structure chain check passes. There's no DFG exploitation
of this knowledge in this patch.
Test: js/regress/undefined-property-access.js (~5.5x speedup)
Reviewed by Filip Pizlo.
* bytecode/PolymorphicGetByIdList.h:
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeForStubInfo):
Add GetByIdAccess::SimpleMiss so we can communicate to the DFG that
the access has been cached.
* jit/Repatch.cpp:
(JSC::toString):
(JSC::kindFor):
(JSC::generateByIdStub):
(JSC::tryCacheGetByID):
(JSC::tryBuildGetByIDList):
Added a GetUndefined stub kind, just a simple "store jsUndefined()" snippet.
Use this to cache missed lookups, piggybacking mostly on the GetValue kind.
* runtime/PropertySlot.h:
(JSC::PropertySlot::isUnset):
Exposed the unset state so PropertySlot can communicate that lookup failed.
2014-11-10 Michael Saboff <msaboff@apple.com>
Add scope operand to op_create_lexical_environment
https://bugs.webkit.org/show_bug.cgi?id=138588
Reviewed by Geoffrey Garen.
Added a second operand to op_create_lexical_environment that contains the scope register
to update. Note that the DFG relies on operationCreateActivation() to update the
scope register since we can't issue a set() with a non-local, non-argument register.
This is temporary until the scope register is allocated as a local.
* bytecode/BytecodeList.json:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
Added the scope register operand.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
Filled in the scope register operand.
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_create_lexical_environment):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_create_lexical_environment):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
Set the scope register with the result of the appropriate create activation slow call.
2014-11-09 Akos Kiss <akiss@inf.u-szeged.hu>
Fix 'noreturn' function does return warning in LLVMOverrides.cpp
https://bugs.webkit.org/show_bug.cgi?id=138306
Reviewed by Filip Pizlo.
Adding NO_RETURN where needed.
* llvm/library/LLVMExports.cpp:
(initializeAndGetJSCLLVMAPI):
* llvm/library/LLVMOverrides.cpp:
* llvm/library/LLVMTrapCallback.h:
2014-11-07 Dániel Bátyai <dbatyai.u-szeged@partner.samsung.com>
Fix an alignment issue with operationPushCatchScope on ARMv7
https://bugs.webkit.org/show_bug.cgi?id=138510
Reviewed by Csaba Osztrogonác.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState):
* jit/JITInlines.h:
(JSC::JIT::callOperation):
2014-11-07 Michael Saboff <msaboff@apple.com>
Update scope related slow path code to use scope register added to opcodes
https://bugs.webkit.org/show_bug.cgi?id=138254
Reviewed by Mark Lam.
Updated slow paths for op_pop_scope, op_push_name_scope and op_push_with_scope.
Added scope register index parameter to the front of the relevant argument lists of the
slow functions. In the case of op_push_name_scope for x86 (32 bit), there aren't enough
registers to accomodate all the parameters. Therefore, added two new JSVALUE32_64 slow
paths called operationPushCatchScope() and operationPushFunctionNameScope() to eliminate
the last "type" argument.
* assembler/MacroAssemblerCodeRef.h:
(JSC::FunctionPtr::FunctionPtr): Added a new template to take 6 arguments.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::callOperation):
New variants of setupArgumentsWithExecState() and callOperation() to handle the new
combinations of argument types and counts.
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_push_with_scope):
(JSC::JIT::emit_op_pop_scope):
(JSC::JIT::emit_op_push_name_scope):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_push_with_scope):
(JSC::JIT::emit_op_pop_scope):
(JSC::JIT::emit_op_push_name_scope):
Use the new slow paths.
* jit/JITOperations.cpp:
* jit/JITOperations.h:
Updates to set the scope result using the scope register index. Added operationPushCatchScope()
and operationPushFunctionNameScope().
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
Updated the scope slow paths to use the scope register index in the instruction to read and
write the register instead of using CallFrame::scope() and CallFrame::setScope().
2014-11-07 Gyuyoung Kim <gyuyoung.kim@samsung.com>
Apply std::unique_ptr to slowPathCall()
https://bugs.webkit.org/show_bug.cgi?id=138489
Reviewed by Mark Lam.
As a step to use std::unique_ptr<>, this patch makes slowPathCall() use std::unique_ptr<>,
std::make_unique<>, and WTF::move().
* dfg/DFGSlowPathGenerator.h:
(JSC::DFG::slowPathCall):
(JSC::DFG::slowPathMove):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitAllocateJSArray):
(JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
(JSC::DFG::SpeculativeJIT::arrayify):
(JSC::DFG::SpeculativeJIT::compileIn):
(JSC::DFG::SpeculativeJIT::compileGetByValOnString):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetById):
(JSC::DFG::SpeculativeJIT::cachedPutById):
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetById):
(JSC::DFG::SpeculativeJIT::cachedPutById):
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
(JSC::DFG::SpeculativeJIT::compile):
2014-11-06 Mark Lam <mark.lam@apple.com>
slow_path_get_direct_pname() needs to be hardened against a constant baseValue.
<https://webkit.org/b/138476>
Reviewed by Michael Saboff.
slow_path_get_direct_pname() currently assumes that the baseValue is always a
non-constant virtual register. However, this is not always the case like in the
following:
function foo() {
var o = { a:1 };
for (var n in o)
0[n];
}
foo();
This patch fixes it to also check for constant virtual register indexes.
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
2014-11-06 Michael Saboff <msaboff@apple.com>
REGRESSION (r174985-174986): Site display disappears
https://bugs.webkit.org/show_bug.cgi?id=138082
Reviewed by Geoffrey Garen.
In support of the change in WebCore, this adds a new functor class to unwind to our
caller's frame possibly skipping of intermediate C++ frames.
* interpreter/StackVisitor.h:
(JSC::CallerFunctor::CallerFunctor):
(JSC::CallerFunctor::callerFrame):
(JSC::CallerFunctor::operator()):
2014-11-06 Gyuyoung Kim <gyuyoung.kim@samsung.com>
Use std::unique_ptr in CodeBlock class
https://bugs.webkit.org/show_bug.cgi?id=138395
Reviewed by Darin Adler.
* bytecode/CodeBlock.h: Use std::unique_ptr.
(JSC::CodeBlock::setJITCodeMap):
* jit/CompactJITCodeMap.h: Use std::unique_ptr instead of OwnPtr|PassOwnPtr.
(JSC::CompactJITCodeMap::CompactJITCodeMap):
(JSC::CompactJITCodeMap::Encoder::finish): Use std::unique_ptr instead of PassOwnPtr.
2014-11-05 Mark Lam <mark.lam@apple.com>
PutById inline caches should have a store barrier when it triggers a structure transition.
<https://webkit.org/b/138441>
Reviewed by Geoffrey Garen.
After r174025, we no longer insert DFG store barriers when the payload of a
PutById operation is not a cell. However, this can lead to a crash when we have
PutById inline cache code transitioning the structure and re-allocating the
butterfly of an old gen object. The lack of a store barrier in that inline
cache results in the old gen object not being noticed during an eden GC scan.
As a result, its newly allocated butterfly will not be kept alive, which leads
to a stale butterfly pointer and, eventually, a crash.
It is also possible that the new structure can be collected by the eden GC if
(at GC time):
1. It is in the eden gen.
2. The inline cache that installed it has been evicted.
3. There are no live eden gen objects referring to it.
The chances of this should be more rare than the butterfly re-allocation, but
it is still possible. Hence, the fix is to always add a store barrier if the
inline caches performs a structure transition.
* jit/Repatch.cpp:
(JSC::emitPutTransitionStub):
- Added store barrier code based on SpeculativeJIT::storeToWriteBarrierBuffer()'s
implementation.
2014-11-05 Gyuyoung Kim <gyuyoung.kim@samsung.com>
Use std::unique_ptr in JSClassRef and JSCallbackObject
https://bugs.webkit.org/show_bug.cgi?id=138402
Reviewed by Geoffrey Garen.
* API/JSCallbackObject.h: Use std::unique_ptr instead of OwnPtr|PassOwnPtr.
(JSC::JSCallbackObjectData::setPrivateProperty): ditto.
* API/JSClassRef.cpp: ditto.
* API/JSClassRef.h: ditto.
2014-11-05 Michael Saboff <msaboff@apple.com>
Disable flakey float32-repeat-out-of-bounds.js and int8-repeat-out-of-bounds.js tests for ARM64
https://bugs.webkit.org/show_bug.cgi?id=138381
Reviewed by Mark Lam.
Disabled these test for ARM64. Will address the failures and then re-enable.
* tests/stress/float32-repeat-out-of-bounds.js:
* tests/stress/int8-repeat-out-of-bounds.js:
2014-11-05 Alexey Proskuryakov <ap@apple.com>
Incorrect sandbox_check in RemoteInspector.mm
https://bugs.webkit.org/show_bug.cgi?id=138408
Reviewed by Joseph Pecoraro.
* inspector/remote/RemoteInspector.mm:
(Inspector::canAccessWebInspectorMachPort):
2014-11-03 Dean Jackson <dino@apple.com>
Add ENABLE_FILTERS_LEVEL_2 feature guard.
https://bugs.webkit.org/show_bug.cgi?id=138362
Reviewed by Tim Horton.
Add a new feature define for Level 2 of CSS Filters.
http://dev.w3.org/fxtf/filters-2/
* Configurations/FeatureDefines.xcconfig:
2014-11-04 Mark Lam <mark.lam@apple.com>
Rename checkMarkByte() to jumpIfIsRememberedOrInEden().
<https://webkit.org/b/138369>
Reviewed by Geoffrey Garen.
Write barriers are needed for GC Eden collections so that we can scan pointers
pointing from old generation objects to eden generation objects. The barrier
currently checks the mark byte in a cell to see if we should skip adding the
cell to the GC remembered set. The addition should be skipped if:
1. The cell is in the young generation. It has no old to eden pointers by
definition.
2. The cell is already in the remembered set. While it is ok to add the cell
to the GC remembered set more than once, it would be redundant. Hence,
we skip this as an optimization to avoid doing unnecessary work.
The barrier currently names this check as checkMarkByte(). We should rename it
to jumpIfIsRememberedOrInEden() to be clearer about its intent.
Similarly, Jump results of this check are currently named
ownerNotMarkedOrAlreadyRemembered. This can be misinterpreted as the owner is
not marked or not already remembered. We should rename it to
ownerIsRememberedOrInEden which is clearer about the intent of the
check. What we are really checking for is that the cell is in the eden gen,
which is implied by it being "not marked".
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::osrWriteBarrier):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::writeBarrier):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::writeBarrier):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::writeBarrier):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::jumpIfIsRememberedOrInEden):
(JSC::AssemblyHelpers::checkMarkByte): Deleted.
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitWriteBarrier):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/JSCell.h:
2014-11-04 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Pause on exceptions should show the actual exception
https://bugs.webkit.org/show_bug.cgi?id=63096
Reviewed by Timothy Hatcher.
* debugger/Debugger.h:
Expose accessor for the pause reason to subclasses.
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::type):
New "error" subtype for error objects.
* inspector/InjectedScriptSource.js:
When an object is an error object, use toString to provide a richer description.
* inspector/protocol/Runtime.json:
Expose a new "error" subtype for Error types (TypeError, ReferenceError, EvalError, etc).
* inspector/protocol/Debugger.json:
Provide type checked objects for different Debugger.pause pause reasons.
An exception provides the thrown object, but assert / CSP pauses provide
a richer typed object as the auxiliary data.
* inspector/ScriptDebugServer.cpp:
(Inspector::ScriptDebugServer::dispatchDidPause):
When paused because of an exception, pass the exception on.
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::handleConsoleAssert):
(Inspector::InspectorDebuggerAgent::scriptExecutionBlockedByCSP):
Provide richer data in pause events.
* inspector/scripts/codegen/generate_backend_commands.py:
(BackendCommandsGenerator.generate_domain.is_anonymous_enum_param):
(BackendCommandsGenerator.generate_domain):
* inspector/scripts/tests/expected/enum-values.json-result:
Generate frontend enums for anonymous enum event parameters.
2014-11-04 Michael Saboff <msaboff@apple.com>
Disable flakey float32-repeat-out-of-bounds.js and int8-repeat-out-of-bounds.js tests for ARM64
https://bugs.webkit.org/show_bug.cgi?id=138381
Reviewed by Mark Lam.
Disabled these test for ARM64. Will address the failures and then re-enable.
* tests/stress/float32-repeat-out-of-bounds.js:
* tests/stress/int8-repeat-out-of-bounds.js:
2014-11-04 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Enum value collisions between different generators
https://bugs.webkit.org/show_bug.cgi?id=138343
Reviewed by Brian Burg.
Each generator was using its own filtered list of domains_to_generate
to build the shared unique list of enum value encodings. This list
was slightly different across different generators. Instead always
use the list of all non-supplemental domains to generate the shared
list of enum values.
* inspector/scripts/codegen/generator.py:
(Generator.non_supplemental_domains):
(Generator.domains_to_generate):
(Generator._traverse_and_assign_enum_values):
* inspector/scripts/tests/enum-values.json: Added.
* inspector/scripts/tests/expected/enum-values.json-result: Added.
2014-11-03 Akos Kiss <akiss@inf.u-szeged.hu>
Workaround for Cortex-A53 erratum 835769
https://bugs.webkit.org/show_bug.cgi?id=138315
Reviewed by Filip Pizlo.
This patch introduces CMake variable and preprocessor macro
WTF_CPU_ARM64_CORTEXA53 with the aim of enabling Cortex-A53-specific
code paths, if set true. The patch also implements one case where such
code paths are needed: the workaround for Cortex-A53 erratum 835769. If
WTF_CPU_ARM64_CORTEXA53 is set then:
- CMake checks whether the compiler already has support for a workaround
and adds -mfix-cortex-a53-835769 to the compiler flags if so,
- the ARM64 backend of offlineasm inserts a nop between memory and
multiply-accumulate instructions, and
- the ARM64 assembler also inserts a nop between memory and (64-bit)
multiply-accumulate instructions.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::madd):
Call nopCortexA53Fix835769() to insert a nop if CPU(ARM64_CORTEXA53) and
if necessary.
(JSC::ARM64Assembler::msub): Likewise.
(JSC::ARM64Assembler::smaddl): Likewise.
(JSC::ARM64Assembler::smsubl): Likewise.
(JSC::ARM64Assembler::umaddl): Likewise.
(JSC::ARM64Assembler::umsubl): Likewise.
(JSC::ARM64Assembler::nopCortexA53Fix835769):
Added. Insert a nop if the previously emitted instruction was a load, a
store, or a prefetch, and if the current instruction is 64-bit.
* offlineasm/arm64.rb:
Add the arm64CortexA53Fix835769 phase and call it from
getModifiedListARM64 to insert nopCortexA53Fix835769 between appropriate
macro instructions. Also, lower nopCortexA53Fix835769 to nop if
CPU(ARM64_CORTEXA53), to nothing otherwise.
* offlineasm/instructions.rb:
Define macro instruction nopFixCortexA53Err835769.
2014-11-03 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r175509.
https://bugs.webkit.org/show_bug.cgi?id=138349
broke some builds (Requested by msaboff on #webkit).
Reverted changeset:
"Update scope related slow path code to use scope register
added to opcodes"
https://bugs.webkit.org/show_bug.cgi?id=138254
http://trac.webkit.org/changeset/175509
2014-11-03 Michael Saboff <msaboff@apple.com>
Update scope related slow path code to use scope register added to opcodes
https://bugs.webkit.org/show_bug.cgi?id=138254
Reviewed by Mark Lam.
Updated slow paths for op_pop_scope, op_push_name_scope and op_push_with_scope.
Added scope register index parameter to the front of the relevant argument lists of the
slow functions. In the case of op_push_name_scope for x86 (32 bit), there aren't enough
registers to accomodate all the parameters. Therefore, added two new JSVALUE32_64 slow
paths called operationPushCatchScope() and operationPushFunctionNameScope() to eliminate
the last "type" argument.
* assembler/MacroAssemblerCodeRef.h:
(JSC::FunctionPtr::FunctionPtr): Added a new template to take 6 arguments.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::callOperation):
New variants of setupArgumentsWithExecState() and callOperation() to handle the new
combinations of argument types and counts.
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_push_with_scope):
(JSC::JIT::emit_op_pop_scope):
(JSC::JIT::emit_op_push_name_scope):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_push_with_scope):
(JSC::JIT::emit_op_pop_scope):
(JSC::JIT::emit_op_push_name_scope):
Use the new slow paths.
* jit/JITOperations.cpp:
* jit/JITOperations.h:
Updates to set the scope result using the scope register index. Added operationPushCatchScope()
and operationPushFunctionNameScope().
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
Updated the scope slow paths to use the scope register index in the instruction to read and
write the register instead of using CallFrame::scope() and CallFrame::setScope().
2014-11-03 Michael Saboff <msaboff@apple.com>
Add "get scope" byte code
https://bugs.webkit.org/show_bug.cgi?id=138326
Reviewed by Mark Lam.
Added op_get_scope. Added implementations for the LLInt and baseline JIT.
Provided nop implementation for DFG and FTL. The new byte code is emitted
after op_enter for any function, program or eval. It is expected that the
DFG will be implemented such that unneeded op_get_scope would be eliminated
during DFG compilation.
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
Added new op_get_scope bytecode.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitGetScope):
* bytecompiler/BytecodeGenerator.h:
Emit new op_get_scope bytecode.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
Added framework for new op_get_scope bytecode.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_get_scope):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_get_scope):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
Implementation of op_get_scope bytecode.
2014-11-03 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Fix RWIProtocol 64-to-32 bit conversion warnings
https://bugs.webkit.org/show_bug.cgi?id=138325
Reviewed by Timothy Hatcher.
* inspector/InspectorValues.h:
Vector's length really is an unsigned, so a static_cast here is fine.
* inspector/scripts/codegen/generate_objective_c.py:
(ObjCGenerator.objc_type_for_raw_name):
Use int instead of NSInteger for APIs that eventually map to
InspectorObject's setInteger, which takes an int.
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
Rebaselined results with the type change.
2014-11-03 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Show Selector's Specificity
https://bugs.webkit.org/show_bug.cgi?id=138189
Reviewed by Timothy Hatcher.
* inspector/protocol/CSS.json:
Create a new named type CSSSelector to include a selector's text and specificity.
The specificity tuple is optional as it may soon be made dynamic in some cases.
2014-11-03 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: ObjC Protocol Interfaces should throw exceptions for nil arguments
https://bugs.webkit.org/show_bug.cgi?id=138221
Reviewed by Timothy Hatcher.
The RWIProtocol APIs will now raise exceptions when:
- any properties are set on a type with a nil value or key (handled by RWIProtocolJSONObject)
- required parameters in type constructors have nil value
- required or optional command return parameters have nil values
- required or optional event parameters have nil values
The exceptions include the name of the field when possible.
* inspector/scripts/codegen/generate_objective_c.py:
(ObjCGenerator.is_type_objc_pointer_type):
Provide a quick check to see if type would be a pointer or not
in the ObjC API. Enums for example are not pointers in the API
because we manage converting them to/from strings.
* inspector/scripts/codegen/generate_objective_c_backend_dispatcher_implementation.py:
(ObjectiveCConfigurationImplementationGenerator._generate_success_block_for_command):
* inspector/scripts/codegen/generate_objective_c_frontend_dispatcher_implementation.py:
(ObjectiveCFrontendDispatcherImplementationGenerator._generate_event):
* inspector/scripts/codegen/generate_objective_c_types_implementation.py:
(ObjectiveCTypesImplementationGenerator._generate_init_method_for_required_members):
(ObjectiveCTypesImplementationGenerator._generate_setter_for_member):
Throw exceptions when nil values are disallowed.
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
Rebaseline tests which include the exception raise calls.
2014-11-03 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: ALTERNATE_DISPATCHERS Let the frontend know about extra agents
https://bugs.webkit.org/show_bug.cgi?id=138236
Reviewed by Brian Burg.
Inform the frontend about any extra domains the backend may have
above and beyond the default list of domains for the debuggable type.
This approach means there is almost no cost to normal debugging.
When a JSContext is debugged with extra agents, a message is sent
to the frontend letting it know which domains to then activate,
and perform any initialization work that may be required.
* inspector/InspectorAgentBase.h:
(Inspector::InspectorAgentBase::domainName):
* inspector/InspectorAgentRegistry.cpp:
(Inspector::InspectorAgentRegistry::appendExtraAgent):
* inspector/InspectorAgentRegistry.h:
* inspector/scripts/codegen/generator_templates.py:
Provide a way to get a list of just the extra domains.
To aggregate this list provide a different "append"
specifically for extra agents.
* inspector/JSGlobalObjectInspectorController.h:
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
(Inspector::JSGlobalObjectInspectorController::connectFrontend):
When a frontend connects, inform it of the extra domains.
* inspector/protocol/Inspector.json:
* inspector/agents/InspectorAgent.h:
* inspector/agents/InspectorAgent.cpp:
(Inspector::InspectorAgent::enable):
(Inspector::InspectorAgent::activateExtraDomains):
Send an event with the extra domains to activate.
2014-11-01 Michael Saboff <msaboff@apple.com>
Add scope operand to op_resolve_scope
https://bugs.webkit.org/show_bug.cgi?id=138253
Reviewed by Mark Lam.
Added scope operand to op_resolve_scope. Although the scope register is filled in with
the ScopeChain register, this operand is not used in the processing of the bytecode.
That will be addressed in a future patch.
* bytecode/BytecodeList.json: Lengthened the three bytecodes.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode): Added code to dump the scope operand.
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::finalizeUnconditionally):
Updated the operand indecies for the processing of op_resolve_scope.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitResolveScope):
(JSC::BytecodeGenerator::emitGetOwnScope):
(JSC::BytecodeGenerator::emitReturn):
Added scope register to these emit functions and the bytecodes they emit.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emitSlow_op_resolve_scope):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emitSlow_op_resolve_scope):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
Updated the operand indecies for the processing of op_resolve_scope.
2014-11-01 Carlos Garcia Campos <cgarcia@igalia.com>
REGRESSION(CMake): Make it possible to build without introspection
https://bugs.webkit.org/show_bug.cgi?id=138006
Reviewed by Philippe Normand.
Do not install introspection files when introspection is disabled.
* PlatformGTK.cmake:
2014-10-31 Gyuyoung Kim <gyuyoung.kim@samsung.com>
Use std::unique_ptr for TypeCountSet
https://bugs.webkit.org/show_bug.cgi?id=138242
Reviewed by Andreas Kling.
* heap/Heap.cpp:
(JSC::Heap::protectedObjectTypeCounts):
Use std::unique_ptr<> instead of PassOwnPtr|OwnPtr.
(JSC::Heap::objectTypeCounts): ditto.
* heap/Heap.h:
2014-10-31 Michael Saboff <msaboff@apple.com>
Add scope operand to op_push_with_scope, op_push_name_scope and op_pop_scope
https://bugs.webkit.org/show_bug.cgi?id=138252
Reviewed by Geoffrey Garen.
Added scope operand to op_push_with_scope, op_push_name_scope and op_pop_scope.
Although the scope register is filled in with the ScopeChain register for all
three bytecodes, this operand is not used in the processing of the bytecodes.
That will be addressed in a future patch.
* bytecode/BytecodeList.json: Lengthened the three bytecodes.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode): Added code to dump the scope operand.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitPushWithScope):
(JSC::BytecodeGenerator::emitPopScope):
(JSC::BytecodeGenerator::emitComplexPopScopes):
(JSC::BytecodeGenerator::emitPopScopes):
(JSC::BytecodeGenerator::emitPushFunctionNameScope):
(JSC::BytecodeGenerator::emitPushCatchScope):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::scopeRegister):
Added scope register to these emit functions and the bytecodes they emit.
New m_scopeRegister and accessor.
* bytecompiler/NodesCodegen.cpp:
(JSC::ContinueNode::emitBytecode):
(JSC::BreakNode::emitBytecode):
(JSC::ReturnNode::emitBytecode):
(JSC::WithNode::emitBytecode):
(JSC::TryNode::emitBytecode):
Created a RegisterID for the ScopeChain register and used it to emit the updated
bytecodes.
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_push_with_scope):
(JSC::JIT::emit_op_push_name_scope):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_push_with_scope):
(JSC::JIT::emit_op_push_name_scope):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter.asm:
Updated the operand indecies for the processing of the updated bytecodes.
2014-10-31 Andreas Kling <akling@apple.com>
Make writes to RegExpObject.lastIndex cacheable.
<https://webkit.org/b/138255>
Reviewed by Geoffrey Garen.
We were neglecting to IC the puts to RegExpObject.lastIndex on Octane/regexp,
and ended up spending 4.5% of a time profile in operationPutByIdNonStrict.
~3% progression on Octane/regexp.
* runtime/RegExpObject.cpp:
(JSC::regExpObjectSetLastIndexStrict):
(JSC::regExpObjectSetLastIndexNonStrict):
(JSC::RegExpObject::put):
2014-10-31 Chris Dumez <cdumez@apple.com>
Fix a couple of warnings in JSC reported by clang static analyzer
https://bugs.webkit.org/show_bug.cgi?id=138240
Reviewed by Geoffrey Garen.
Fix a couple of warnings in JSC reported by clang static analyzer about
value stored in variables never being read. This is addressed by
reducing the scope of the variable or removing the variable entirely.
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::emitGetByOffset):
* runtime/VM.cpp:
(JSC::VM::throwException):
2014-10-30 Dana Burkart <dburkart@apple.com>
<rdar://problem/18821260> Prepare for the mysterious future
Reviewed by Lucas Forschler.
* Configurations/Base.xcconfig:
* Configurations/DebugRelease.xcconfig:
* Configurations/FeatureDefines.xcconfig:
* Configurations/Version.xcconfig:
2014-10-30 Saam Barati <saambarati1@gmail.com>
AST Nodes should keep track of their end offset
https://bugs.webkit.org/show_bug.cgi?id=138143
Reviewed by Filip Pizlo.
AST nodes nodes now have an int property for their end text
offsets. This change lays some foundational work that will be
needed in profiling which basic blocks have executed.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::setEndOffset):
* parser/Nodes.h:
(JSC::Node::endOffset):
(JSC::Node::setEndOffset):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseStatement):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseExpression):
(JSC::Parser<LexerType>::parseProperty):
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::operatorStackPop):
2014-10-30 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Generate ObjC inspector protocol types and alternate dispatcher interfaces
https://bugs.webkit.org/show_bug.cgi?id=138048
Reviewed by Brian Burg.
Generate Objective-C interfaces for inspector protocol types, command, and event dispatchers.
This is very much like the InspectorProtocolTypes, BackendDispatchers, and FrontendDispatchers,
but with an ObjC spin on things.
The private API that clients would use is all encapsulated in RWIProtocol.h. It includes the
types interfaces, command handler protocol, and event dispatcher interface. Where possible the
API uses real enums, which hides the raw protocol enum strings from clients.
Inspector protocol types are, like InspectorProtocolObjects, built on top of an InspectorObject.
This offers the flexibilty of adding arbitrary key/values using the RWIProtocolJSONObject
interface, which may be required for certain protocol objects like "Network.Headers" which
have no fields, but expect arbitrary properties to be added.
Command handler protocols always have two callbacks. An error callback and a success callback.
The signature is very much like BackendDispatchers. In parameters are passed directly to
the selectors, and out parameters are defined by the success callback. It will be the client's
responsibility to call either of these callbacks to complete handling of a request.
Event dispatcher interfaces are straight forward, just packaging up the arguments and sending
the message to the frontend.
ObjC <-> Protocol conversion happens in each of the generated files. In type getters / setters,
in commands parameters and event parameters. For this to work we generate conversion helpers
for all enums, ObjC enum <-> protocol strings. For NSArray <-> InspectorArray there are some
static helpers to do the conversions. We do lose some type safety in these conversions.
* JavaScriptCore.xcodeproj/project.pbxproj:
* inspector/scripts/codegen/__init__.py:
* inspector/scripts/codegen/generate_alternate_backend_dispatcher_header.py:
(AlternateBackendDispatcherHeaderGenerator._generate_handler_declarations_for_domain):
* inspector/scripts/codegen/generate_backend_dispatcher_header.py:
(BackendDispatcherHeaderGenerator._generate_alternate_handler_forward_declarations_for_domains.AlternateInspector):
(BackendDispatcherHeaderGenerator._generate_handler_declarations_for_domain):
(BackendDispatcherHeaderGenerator._generate_dispatcher_declarations_for_domain):
* inspector/scripts/codegen/generate_backend_dispatcher_implementation.py:
(BackendDispatcherImplementationGenerator._generate_handler_class_destructor_for_domain):
(BackendDispatcherImplementationGenerator._generate_dispatcher_implementations_for_domain):
* inspector/scripts/codegen/generate_frontend_dispatcher_header.py:
(FrontendDispatcherHeaderGenerator._generate_dispatcher_declarations_for_domain):
* inspector/scripts/codegen/generate_frontend_dispatcher_implementation.py:
(FrontendDispatcherImplementationGenerator._generate_dispatcher_implementations_for_domain):
* inspector/scripts/codegen/generate_objective_c.py: Added.
(join_type_and_name):
(strip_comment_markers):
(remove_duplicate_from_str):
(ObjCTypeCategory):
(ObjCTypeCategory.category_of_type):
(ObjCGenerator):
(ObjCGenerator.identifier_to_objc_identifier):
(ObjCGenerator.objc_identifier_to_identifier):
(ObjCGenerator.should_generate_domain_types_filter):
(ObjCGenerator.should_generate_domain_types_filter.should_generate_domain_types):
(ObjCGenerator.should_generate_domain_command_handler_filter):
(ObjCGenerator.should_generate_domain_command_handler_filter.should_generate_domain_command_handler):
(ObjCGenerator.should_generate_domain_event_dispatcher_filter):
(ObjCGenerator.should_generate_domain_event_dispatcher_filter.should_generate_domain_event_dispatcher):
(ObjCGenerator.objc_name_for_type):
(ObjCGenerator.objc_enum_name_for_anonymous_enum_declaration):
(ObjCGenerator.objc_enum_name_for_anonymous_enum_member):
(ObjCGenerator.objc_enum_name_for_anonymous_enum_parameter):
(ObjCGenerator.objc_enum_name_for_non_anonymous_enum):
(ObjCGenerator.variable_name_prefix_for_domain):
(ObjCGenerator.objc_accessor_type_for_raw_name):
(ObjCGenerator.objc_type_for_raw_name):
(ObjCGenerator.objc_class_for_raw_name):
(ObjCGenerator.protocol_type_for_raw_name):
(ObjCGenerator.protocol_type_for_type):
(ObjCGenerator.objc_class_for_type):
(ObjCGenerator.objc_accessor_type_for_member):
(ObjCGenerator.objc_accessor_type_for_member_internal):
(ObjCGenerator.objc_type_for_member):
(ObjCGenerator.objc_type_for_member_internal):
(ObjCGenerator.objc_type_for_param):
(ObjCGenerator.objc_type_for_param_internal):
(ObjCGenerator.objc_protocol_export_expression_for_variable):
(ObjCGenerator.objc_protocol_import_expression_for_member):
(ObjCGenerator.objc_protocol_import_expression_for_parameter):
(ObjCGenerator.objc_protocol_import_expression_for_variable):
(ObjCGenerator.objc_to_protocol_expression_for_member):
(ObjCGenerator.protocol_to_objc_expression_for_member):
(ObjCGenerator.objc_setter_method_for_member):
(ObjCGenerator.objc_setter_method_for_member_internal):
(ObjCGenerator.objc_getter_method_for_member):
(ObjCGenerator.objc_getter_method_for_member_internal):
* inspector/scripts/codegen/generate_objective_c_backend_dispatcher_header.py: Copied from Source/JavaScriptCore/inspector/scripts/codegen/generate_alternate_backend_dispatcher_header.py.
(ObjectiveCBackendDispatcherHeaderGenerator):
(ObjectiveCBackendDispatcherHeaderGenerator.output_filename):
(ObjectiveCBackendDispatcherHeaderGenerator.domains_to_generate):
(ObjectiveCBackendDispatcherHeaderGenerator.generate_output):
(ObjectiveCBackendDispatcherHeaderGenerator._generate_objc_forward_declarations):
(ObjectiveCBackendDispatcherHeaderGenerator._generate_objc_forward_declarations_for_domains):
(ObjectiveCBackendDispatcherHeaderGenerator._generate_objc_handler_declarations_for_domain):
(ObjectiveCBackendDispatcherHeaderGenerator._generate_objc_handler_declaration_for_command):
* inspector/scripts/codegen/generate_objective_c_backend_dispatcher_implementation.py: Added.
(ObjectiveCConfigurationImplementationGenerator):
(ObjectiveCConfigurationImplementationGenerator.__init__):
(ObjectiveCConfigurationImplementationGenerator.output_filename):
(ObjectiveCConfigurationImplementationGenerator.domains_to_generate):
(ObjectiveCConfigurationImplementationGenerator.generate_output):
(ObjectiveCConfigurationImplementationGenerator._generate_handler_implementation_for_domain):
(ObjectiveCConfigurationImplementationGenerator._generate_handler_implementation_for_command):
(ObjectiveCConfigurationImplementationGenerator._generate_success_block_for_command):
(ObjectiveCConfigurationImplementationGenerator._generate_conversions_for_command):
(ObjectiveCConfigurationImplementationGenerator._generate_invocation_for_command):
* inspector/scripts/codegen/generate_objective_c_configuration_header.py: Copied from Source/JavaScriptCore/inspector/scripts/codegen/generate_alternate_backend_dispatcher_header.py.
(ObjectiveCConfigurationHeaderGenerator):
(ObjectiveCConfigurationHeaderGenerator.output_filename):
(ObjectiveCConfigurationHeaderGenerator.generate_output):
(ObjectiveCConfigurationHeaderGenerator._generate_configuration_interface_for_domains):
(ObjectiveCConfigurationHeaderGenerator._generate_properties_for_domain):
* inspector/scripts/codegen/generate_objective_c_configuration_implementation.py: Added.
(ObjectiveCBackendDispatcherImplementationGenerator):
(ObjectiveCBackendDispatcherImplementationGenerator.__init__):
(ObjectiveCBackendDispatcherImplementationGenerator.output_filename):
(ObjectiveCBackendDispatcherImplementationGenerator.generate_output):
(ObjectiveCBackendDispatcherImplementationGenerator._generate_configuration_implementation_for_domains):
(ObjectiveCBackendDispatcherImplementationGenerator._generate_ivars):
(ObjectiveCBackendDispatcherImplementationGenerator._generate_dealloc):
(ObjectiveCBackendDispatcherImplementationGenerator._generate_handler_setter_for_domain):
(ObjectiveCBackendDispatcherImplementationGenerator._generate_event_dispatcher_getter_for_domain):
* inspector/scripts/codegen/generate_objective_c_conversion_helpers.py: Added.
(add_whitespace_separator):
(ObjectiveCConversionHelpersGenerator):
(ObjectiveCConversionHelpersGenerator.__init__):
(ObjectiveCConversionHelpersGenerator.output_filename):
(ObjectiveCConversionHelpersGenerator.domains_to_generate):
(ObjectiveCConversionHelpersGenerator.generate_output):
(ObjectiveCConversionHelpersGenerator._generate_enum_conversion_functions):
(ObjectiveCConversionHelpersGenerator._generate_anonymous_enum_conversion_for_declaration):
(ObjectiveCConversionHelpersGenerator._generate_anonymous_enum_conversion_for_member):
(ObjectiveCConversionHelpersGenerator._generate_anonymous_enum_conversion_for_parameter):
(ObjectiveCConversionHelpersGenerator._generate_enum_objc_to_protocol_string):
(ObjectiveCConversionHelpersGenerator._generate_enum_from_protocol_string):
* inspector/scripts/codegen/generate_objective_c_frontend_dispatcher_implementation.py: Added.
(ObjectiveCFrontendDispatcherImplementationGenerator):
(ObjectiveCFrontendDispatcherImplementationGenerator.__init__):
(ObjectiveCFrontendDispatcherImplementationGenerator.output_filename):
(ObjectiveCFrontendDispatcherImplementationGenerator.domains_to_generate):
(ObjectiveCFrontendDispatcherImplementationGenerator.generate_output):
(ObjectiveCFrontendDispatcherImplementationGenerator._generate_event_dispatcher_implementations):
(ObjectiveCFrontendDispatcherImplementationGenerator._generate_event):
(ObjectiveCFrontendDispatcherImplementationGenerator._generate_event_signature):
(ObjectiveCFrontendDispatcherImplementationGenerator._generate_event_out_parameters):
* inspector/scripts/codegen/generate_objective_c_header.py: Added.
(add_whitespace_separator):
(ObjectiveCHeaderGenerator):
(ObjectiveCHeaderGenerator.__init__):
(ObjectiveCHeaderGenerator.output_filename):
(ObjectiveCHeaderGenerator.generate_output):
(ObjectiveCHeaderGenerator._generate_forward_declarations):
(ObjectiveCHeaderGenerator._generate_enums):
(ObjectiveCHeaderGenerator._generate_types):
(ObjectiveCHeaderGenerator._generate_anonymous_enum_for_declaration):
(ObjectiveCHeaderGenerator._generate_anonymous_enum_for_member):
(ObjectiveCHeaderGenerator._generate_anonymous_enum_for_parameter):
(ObjectiveCHeaderGenerator._generate_enum):
(ObjectiveCHeaderGenerator._generate_enum.NS_ENUM):
(ObjectiveCHeaderGenerator._generate_type_interface):
(ObjectiveCHeaderGenerator._generate_init_method_for_required_members):
(ObjectiveCHeaderGenerator._generate_member_property):
(ObjectiveCHeaderGenerator._generate_command_protocols):
(ObjectiveCHeaderGenerator._generate_single_command_protocol):
(ObjectiveCHeaderGenerator._callback_block_for_command):
(ObjectiveCHeaderGenerator._generate_event_interfaces):
(ObjectiveCHeaderGenerator._generate_single_event_interface):
* inspector/scripts/codegen/generate_objective_c_internal_header.py: Copied from Source/JavaScriptCore/inspector/scripts/codegen/generate_alternate_backend_dispatcher_header.py.
(ObjectiveCTypesInternalHeaderGenerator):
(ObjectiveCTypesInternalHeaderGenerator.output_filename):
(ObjectiveCTypesInternalHeaderGenerator.generate_output):
(ObjectiveCTypesInternalHeaderGenerator._generate_event_dispatcher_private_interfaces):
* inspector/scripts/codegen/generate_objective_c_types_implementation.py: Added.
(add_whitespace_separator):
(ObjectiveCTypesImplementationGenerator):
(ObjectiveCTypesImplementationGenerator.__init__):
(ObjectiveCTypesImplementationGenerator.output_filename):
(ObjectiveCTypesImplementationGenerator.domains_to_generate):
(ObjectiveCTypesImplementationGenerator.generate_output):
(ObjectiveCTypesImplementationGenerator.generate_type_implementations):
(ObjectiveCTypesImplementationGenerator.generate_type_implementation):
(ObjectiveCTypesImplementationGenerator._generate_init_method_for_required_members):
(ObjectiveCTypesImplementationGenerator._generate_setter_for_member):
(ObjectiveCTypesImplementationGenerator._generate_getter_for_member):
* inspector/scripts/codegen/generate_protocol_types_header.py:
(ProtocolTypesHeaderGenerator._generate_forward_declarations):
(_generate_typedefs_for_domain):
(_generate_builders_for_domain):
* inspector/scripts/codegen/generator.py:
(Generator.wrap_with_guard_for_domain):
(Generator):
(Generator.wrap_with_guard):
* inspector/scripts/codegen/generator_templates.py:
(AlternateInspector):
(ObjCInspector):
* inspector/scripts/codegen/models.py:
(Framework.fromString):
(Frameworks):
* inspector/scripts/generate-inspector-protocol-bindings.py:
(generate_from_specification):
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2014-10-30 Andreas Kling <akling@apple.com>
Unreviewed assertion fix.
RegExpCachedResult::m_reified is now the dedicated member that knows whether
the result was reified into an array or not. Check that instead of m_result
which is now single-purpose.
* runtime/RegExpCachedResult.cpp:
(JSC::RegExpCachedResult::setInput):
2014-10-29 Andreas Kling <akling@apple.com>
Use plain JSArray for RegExp matches instead of a lazily populated custom object.
<https://webkit.org/b/138191>
Reviewed by Geoffrey Garen.
We're already offering two RegExp matching APIs, one that collects subpattern
matches (exec), and one that simply tests for a match (test).
Given that, it was pretty overkill to lazily populate the resulting array of
matches, since the user could simply use test() if they didn't need them.
This allows the JIT to generate better code for RegExp match arrays, and also
enables some fast paths in the JSC runtime that check if an object isJSArray().
Looks like ~1.5% improvement on Octane/regexp according to run-jsc-benchmarks.
* jit/Repatch.cpp:
(JSC::tryCacheGetByID):
* runtime/JSArray.h:
(JSC::createArrayButterflyWithExactLength): Deleted.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/RegExpCachedResult.cpp:
(JSC::RegExpCachedResult::visitChildren):
(JSC::RegExpCachedResult::lastResult):
(JSC::RegExpCachedResult::leftContext):
(JSC::RegExpCachedResult::rightContext):
* runtime/RegExpCachedResult.h:
(JSC::RegExpCachedResult::RegExpCachedResult):
(JSC::RegExpCachedResult::record):
(JSC::RegExpCachedResult::input):
* runtime/RegExpConstructor.cpp:
(JSC::RegExpConstructor::getBackref):
(JSC::RegExpConstructor::getLastParen):
(JSC::RegExpConstructor::getLeftContext):
(JSC::RegExpConstructor::getRightContext):
* runtime/RegExpMatchesArray.cpp:
(JSC::createRegExpMatchesArray):
(JSC::RegExpMatchesArray::RegExpMatchesArray): Deleted.
(JSC::RegExpMatchesArray::create): Deleted.
(JSC::RegExpMatchesArray::finishCreation): Deleted.
(JSC::RegExpMatchesArray::visitChildren): Deleted.
(JSC::RegExpMatchesArray::reifyAllProperties): Deleted.
(JSC::RegExpMatchesArray::reifyMatchProperty): Deleted.
(JSC::RegExpMatchesArray::leftContext): Deleted.
(JSC::RegExpMatchesArray::rightContext): Deleted.
* runtime/RegExpMatchesArray.h:
(JSC::RegExpMatchesArray::createStructure): Deleted.
(JSC::RegExpMatchesArray::reifyAllPropertiesIfNecessary): Deleted.
(JSC::RegExpMatchesArray::reifyMatchPropertyIfNecessary): Deleted.
(JSC::RegExpMatchesArray::getOwnPropertySlot): Deleted.
(JSC::RegExpMatchesArray::getOwnPropertySlotByIndex): Deleted.
(JSC::RegExpMatchesArray::put): Deleted.
(JSC::RegExpMatchesArray::putByIndex): Deleted.
(JSC::RegExpMatchesArray::deleteProperty): Deleted.
(JSC::RegExpMatchesArray::deletePropertyByIndex): Deleted.
(JSC::RegExpMatchesArray::getOwnPropertyNames): Deleted.
(JSC::RegExpMatchesArray::defineOwnProperty): Deleted.
(JSC::isRegExpMatchesArray): Deleted.
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::exec):
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncMatch):
2014-10-29 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Fix Type Dependency Issues
https://bugs.webkit.org/show_bug.cgi?id=125664
Reviewed by Brian Burg.
Now that all JSON protocol files are processed together again
in r174892, we can remove the duplicated types which were only
needed when the domains were split.
* inspector/protocol/Console.json:
* inspector/protocol/Runtime.json:
2014-10-28 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r175249.
https://bugs.webkit.org/show_bug.cgi?id=138138
Appears to be failing some JS tests (Requested by mlam_ on
#webkit).
Reverted changeset:
"Holes are not copied properly when Arrays change shape to
ArrayStorage type."
https://bugs.webkit.org/show_bug.cgi?id=138118
http://trac.webkit.org/changeset/175249
2014-10-27 Mark Lam <mark.lam@apple.com>
Holes are not copied properly when Arrays change shape to ArrayStorage type.
<https://webkit.org/b/138118>
Reviewed by Mark Hahnenberg.
When we convert non-ArrayStorage typed arrays into ArrayStorage typed arrays,
we skipped the holes. As a result, the slots in the ArrayStorage vector that
corresponds to those holes are uninitialize. This is now fixed.
* runtime/JSObject.cpp:
(JSC::JSObject::convertUndecidedToArrayStorage):
(JSC::JSObject::convertInt32ToArrayStorage):
(JSC::JSObject::convertDoubleToArrayStorage):
(JSC::JSObject::convertContiguousToArrayStorage):
2014-10-27 Mark Lam <mark.lam@apple.com>
Crash when attempting to perform array iteration on a non-array with numeric keys not initialized.
<https://webkit.org/b/137814>
Reviewed by Geoffrey Garen.
The arrayIteratorNextThunkGenerator() thunk was not checking for the case where
the butterfly may be NULL. This was the source of the crash, and is now fixed.
In addition, it is also not checking for the case where a property named "length"
may have been set on the iterated object. The thunk only checks the butterfly's
publicLength for its iteration operation. Array objects will work fine with this
because it always updates its butterfly's publicLength when its length changes.
In the case of iterable non-Array objects, the "length" property will require a
look up outside of the scope of this thunk. The fix is simply to limit the fast
case checks in this thunk to Array objects.
* jit/ThunkGenerators.cpp:
(JSC::arrayIteratorNextThunkGenerator):
2014-10-27 Mark Lam <mark.lam@apple.com>
Simplified some JSObject methods for converting arrays to ArrayStorage shape.
<https://webkit.org/b/138119>
Reviewed by Filip Pizlo.
Currently, for each Undecided, Int32, Double, and Contiguous array shapes,
there are 3 JSObject methods to convert them to ArrayStorage shape:
ArrayStorage* convert<shape>ToArrayStorage(VM&, NonPropertyTransition, unsigned neededLength);
ArrayStorage* convert<shape>ToArrayStorage(VM&, NonPropertyTransition);
ArrayStorage* convert<shape>ToArrayStorage(VM&);
However, the neededLength that is passed is always m_butterfly->vectorLength().
Hence, the method that takes a neededLength is really not needed. This patch
removes this unneeded verbosity.
* runtime/JSObject.cpp:
(JSC::JSObject::convertUndecidedToArrayStorage):
(JSC::JSObject::convertInt32ToArrayStorage):
- Also reordered the placement of the DeferGC statement so this Int32 function
will look more similar to the others.
(JSC::JSObject::convertDoubleToArrayStorage):
(JSC::JSObject::convertContiguousToArrayStorage):
* runtime/JSObject.h:
2014-10-25 Brian J. Burg <burg@cs.washington.edu>
Web Inspector: timelines should not count time elapsed while paused in the debugger
https://bugs.webkit.org/show_bug.cgi?id=136351
Unreviewed, follow-up fix after r175203. The debugger agent should not assume
that the inspector environment's stopwatch has already been started.
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::didPause): Check if the stopwatch isActive() before stopping.
2014-10-18 Brian J. Burg <burg@cs.washington.edu>
Web Inspector: timelines should not count time elapsed while paused in the debugger
https://bugs.webkit.org/show_bug.cgi?id=136351
Reviewed by Timothy Hatcher.
Now that we have a stopwatch to provide pause-aware timing data, we can remove the
profiler's handling of debugger pause/continue callbacks. The debugger agent accounts
for suspended execution by pausing and resuming the stopwatch.
* API/JSProfilerPrivate.cpp:
(JSStartProfiling): Use a fresh stopwatch when profiling from the JSC API.
* inspector/InspectorEnvironment.h:
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
(Inspector::JSGlobalObjectInspectorController::executionStopwatch):
* inspector/JSGlobalObjectInspectorController.h:
* inspector/ScriptDebugServer.cpp:
(Inspector::ScriptDebugServer::handlePause):
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::didPause):
(Inspector::InspectorDebuggerAgent::breakpointActionProbe):
(Inspector::InspectorDebuggerAgent::didContinue):
* inspector/agents/InspectorDebuggerAgent.h:
* profiler/LegacyProfiler.cpp:
(JSC::LegacyProfiler::profiler): Use nullptr.
(JSC::LegacyProfiler::startProfiling): Hand off a stopwatch to the profile generator.
(JSC::LegacyProfiler::stopProfiling): Use nullptr.
(JSC::LegacyProfiler::didPause): Deleted.
(JSC::LegacyProfiler::didContinue): Deleted.
* profiler/LegacyProfiler.h:
* profiler/Profile.cpp: The root node should always have a start time of 0.0.
(JSC::Profile::Profile):
* profiler/ProfileGenerator.cpp: Remove debugger pause/continue callbacks and the
timestamp member that was used to track time elapsed by the debugger. Just use the
stopwatch's elapsed times to generate start/elapsed times for function calls.
(JSC::ProfileGenerator::create):
(JSC::ProfileGenerator::ProfileGenerator):
(JSC::AddParentForConsoleStartFunctor::operator()): The parent node of |console.profile|
should have a start time of 0.0, since it represents the starting node of profiling.
(JSC::ProfileGenerator::beginCallEntry):
(JSC::ProfileGenerator::endCallEntry):
(JSC::ProfileGenerator::didPause): Deleted.
(JSC::ProfileGenerator::didContinue): Deleted.
* profiler/ProfileGenerator.h:
2014-10-24 Mark Lam <mark.lam@apple.com>
Simplified IndexingType's hasAnyArrayStorage().
<https://webkit.org/b/138051>
Reviewed by Michael Saboff.
IndexingType's hasAnyArrayStorage() currently does subtraction of ArrayStorageShape
with the purpose of making non-ArrayStorage types underflow (with that subtraction)
and have a result that exceeds SlowPutArrayStorageShape. What it is doing is
basically checking for a shape value that is greater equal to ArrayStorageShape.
We can just simplify the code as such.
Also added a comment to describe the structure of the bits in IndexingType.
* runtime/IndexingType.h:
(JSC::hasAnyArrayStorage):
2014-10-23 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Provide a way to have alternate inspector agents
https://bugs.webkit.org/show_bug.cgi?id=137901
Reviewed by Brian Burg.
Provide a way to use alternate inspector agents debugging a JSContext.
Expose a very slim private API that a client could use to know when
an inspector has connected/disconnected, and a way to register its
augmentative agents.
* Configurations/FeatureDefines.xcconfig:
* JavaScriptCore.xcodeproj/project.pbxproj:
New feature guard. New files.
* API/JSContextRef.cpp:
(JSGlobalContextGetAugmentableInspectorController):
* API/JSContextRefInspectorSupport.h: Added.
Access to the private interface from a JSContext.
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
(Inspector::JSGlobalObjectInspectorController::connectFrontend):
(Inspector::JSGlobalObjectInspectorController::disconnectFrontend):
* inspector/JSGlobalObjectInspectorController.h:
* inspector/augmentable/AugmentableInspectorController.h: Added.
(Inspector::AugmentableInspectorController::~AugmentableInspectorController):
(Inspector::AugmentableInspectorController::connected):
* inspector/augmentable/AugmentableInspectorControllerClient.h: Added.
(Inspector::AugmentableInspectorControllerClient::~AugmentableInspectorControllerClient):
* inspector/augmentable/AlternateDispatchableAgent.h: Added.
(Inspector::AlternateDispatchableAgent::AlternateDispatchableAgent):
Provide the private APIs a client could use to add alternate agents using alternate backend dispatchers.
* inspector/scripts/codegen/__init__.py:
* inspector/scripts/generate-inspector-protocol-bindings.py:
(generate_from_specification):
New includes, and use the new generator.
* inspector/scripts/codegen/generate_alternate_backend_dispatcher_header.py: Added.
(AlternateBackendDispatcherHeaderGenerator):
(AlternateBackendDispatcherHeaderGenerator.__init__):
(AlternateBackendDispatcherHeaderGenerator.output_filename):
(AlternateBackendDispatcherHeaderGenerator.generate_output):
(AlternateBackendDispatcherHeaderGenerator._generate_handler_declarations_for_domain):
(AlternateBackendDispatcherHeaderGenerator._generate_handler_declaration_for_command):
Generate the abstract AlternateInspectorBackendDispatcher interfaces.
* inspector/scripts/codegen/generate_backend_dispatcher_header.py:
(BackendDispatcherHeaderGenerator.generate_output):
(BackendDispatcherHeaderGenerator._generate_alternate_handler_forward_declarations_for_domains):
(BackendDispatcherHeaderGenerator._generate_alternate_handler_forward_declarations_for_domains.AlternateInspector):
Forward declare alternate dispatchers, and allow setting an alternate dispatcher on a domain dispatcher.
* inspector/scripts/codegen/generate_backend_dispatcher_implementation.py:
(BackendDispatcherImplementationGenerator.generate_output):
(BackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
Check for and dispatch on an AlternateInspectorBackendDispatcher if there is one for this domain.
* inspector/scripts/codegen/generator_templates.py:
(AlternateInspectorBackendDispatcher):
(AlternateInspector):
Template boilerplate for prelude and postlude.
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
Rebaseline tests.
2014-10-23 Michael Saboff <msaboff@apple.com>
offsets.rb:183:in `buildOffsetsMap': unhandled exception - is offlineasm dependency tracking broken? (132668)
https://bugs.webkit.org/show_bug.cgi?id=138017
Reviewed by Mark Lam.
Removed from the nput file $(SRCROOT)/llint/LowLevelAssembler.asm and output file
$(BUILT_PRODUCTS_DIR)/LLIntOffsets/LLIntDesiredOffsets.h from the Generate Derived Sources
build phase in the LLInt Offset target. There is no need for Xcode to do any dependency
checking with these files as the ruby script offlineasm/generate_offset_extractor.rb will
do that for us.
* JavaScriptCore.xcodeproj/project.pbxproj:
2014-10-23 Michael Saboff <msaboff@apple.com>
Change CallFrame::lexicalGlobalObject() to use Callee instead of JSScope
https://bugs.webkit.org/show_bug.cgi?id=136901
Reviewed by Mark Lam.
Implement ExecState::lexicalGlobalObject() using Callee.
* runtime/JSScope.h:
(JSC::ExecState::lexicalGlobalObject):
2014-10-22 Milan Crha <mcrha@redhat.com>
Prefix isnan() with std::.
<https://webkit.org/b/137966>.
Reviewed by Carlos Garcia Campos.
* profiler/ProfileNode.h:
(JSC::ProfileNode::Call::setStartTime):
(JSC::ProfileNode::Call::setElapsedTime):
2014-10-22 Mark Lam <mark.lam@apple.com>
Refactoring to simplify some code in DatePrototype.cpp.
<https://webkit.org/b/137997>
Reviewed by Filip Pizlo.
A bunch of functions in DatePrototype.cpp have the pattern of loading a
constant into a local variable only to pass it to a callee function
immediately after. There is no other use for that variable. This adds
additional verbosity with no added benefit.
This patch refactors those functions to just pass the constant arg directly.
* runtime/DatePrototype.cpp:
(JSC::dateProtoFuncSetMilliSeconds):
(JSC::dateProtoFuncSetUTCMilliseconds):
(JSC::dateProtoFuncSetSeconds):
(JSC::dateProtoFuncSetUTCSeconds):
(JSC::dateProtoFuncSetMinutes):
(JSC::dateProtoFuncSetUTCMinutes):
(JSC::dateProtoFuncSetHours):
(JSC::dateProtoFuncSetUTCHours):
(JSC::dateProtoFuncSetDate):
(JSC::dateProtoFuncSetUTCDate):
(JSC::dateProtoFuncSetMonth):
(JSC::dateProtoFuncSetUTCMonth):
(JSC::dateProtoFuncSetFullYear):
(JSC::dateProtoFuncSetUTCFullYear):
2014-10-22 Byungseon Shin <sun.shin@lge.com>
String(new Date(Mar 30 2014 01:00:00)) is wrong in CET
https://bugs.webkit.org/show_bug.cgi?id=130967
Reviewed by Mark Lam.
By definition of calculateLocalTimeOffset, input time should be UTC time.
But there are many cases when input time is based on local time.
So, it gives erroneous results while calculating offset of DST boundary time.
By adding a argument to distinguish UTC and local time, we can get the correct offset.
* JavaScriptCore.order:
* runtime/DateConstructor.cpp:
(JSC::constructDate):
(JSC::callDate):
(JSC::dateUTC):
* runtime/DateInstance.cpp:
(JSC::DateInstance::calculateGregorianDateTime):
(JSC::DateInstance::calculateGregorianDateTimeUTC):
* runtime/DatePrototype.cpp:
(JSC::setNewValueFromTimeArgs):
(JSC::setNewValueFromDateArgs):
(JSC::dateProtoFuncSetMilliSeconds):
(JSC::dateProtoFuncSetUTCMilliseconds):
(JSC::dateProtoFuncSetSeconds):
(JSC::dateProtoFuncSetUTCSeconds):
(JSC::dateProtoFuncSetMinutes):
(JSC::dateProtoFuncSetUTCMinutes):
(JSC::dateProtoFuncSetHours):
(JSC::dateProtoFuncSetUTCHours):
(JSC::dateProtoFuncSetDate):
(JSC::dateProtoFuncSetUTCDate):
(JSC::dateProtoFuncSetMonth):
(JSC::dateProtoFuncSetUTCMonth):
(JSC::dateProtoFuncSetFullYear):
(JSC::dateProtoFuncSetUTCFullYear):
(JSC::dateProtoFuncSetYear):
* runtime/JSDateMath.cpp:
(JSC::localTimeOffset):
(JSC::gregorianDateTimeToMS):
(JSC::msToGregorianDateTime):
(JSC::parseDateFromNullTerminatedCharacters):
* runtime/JSDateMath.h:
* runtime/VM.h:
(JSC::LocalTimeOffsetCache::LocalTimeOffsetCache):
(JSC::LocalTimeOffsetCache::reset):
Passing TimeType argument to distingush UTC time and local time.
2014-10-22 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Fix generator importing of protocol type "any", treat as value
https://bugs.webkit.org/show_bug.cgi?id=137931
Reviewed by Timothy Hatcher.
Treat incoming "any" objects as InspectorValues, which can be any type.
Add the necessary boilerplate to import.
* inspector/InspectorBackendDispatcher.cpp:
(Inspector::AsMethodBridges::asValue):
(Inspector::InspectorBackendDispatcher::getValue):
* inspector/InspectorBackendDispatcher.h:
* inspector/scripts/codegen/generator.py:
(Generator.keyed_get_method_for_type):
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
2014-10-22 Michael Saboff <msaboff@apple.com>
REGRESSION(r174996): Broke C_LOOP
https://bugs.webkit.org/show_bug.cgi?id=137971
Reviewed by Mark Lam.
Removed incorrect move to cfr (CallFrameRegister) before we make the call to a native function.
After r174996, the source register for the move contained garbage causing the crash. The move
to cfr before making the call to the native function is wrong and should have been removed
some time ago. This brings the ARM64 / C_LOOP code path inline with the other CPU paths.
Tested on ARM64 as well as a C_LOOP build.
* llint/LowLevelInterpreter64.asm:
2014-10-21 Mark Lam <mark.lam@apple.com>
Remove erroneous canUseJIT() in the intrinsics version of JITThunks::hostFunctionStub().
<https://webkit.org/b/137937>
Reviewed by Michael Saboff.
This version of JITThunks::hostFunctionStub() can only be called from the intrinsics
version of VM::getHostFunction() which asserts canUseJIT(). Hence, we can eliminate
the canUseJIT() check in JITThunks::hostFunctionStub(). We don't handle the
!canUseJIT() case properly there anyway.
* jit/JITThunks.cpp:
(JSC::JITThunks::hostFunctionStub):
2014-10-21 Michael Saboff <msaboff@apple.com>
Add operator==(PropertyName, const char*)
https://bugs.webkit.org/show_bug.cgi?id=137925
Reviewed by Mark Lam.
* runtime/PropertyName.h:
(JSC::operator==): Added to simplify comparison with string literals.
2014-10-21 Michael Saboff <msaboff@apple.com>
Change native call frames to use the scope from their Callee instead of their caller's scope
https://bugs.webkit.org/show_bug.cgi?id=137907
Reviewed by Mark Lam.
Changed setting of scope for native CallFrames to use the scope associated with the
Callee instead of the caller's scope.
* jit/ThunkGenerators.cpp:
(JSC::nativeForGenerator):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2014-10-21 Tibor Meszaros <tmeszaros.u-szeged@partner.samsung.com>
Add missing ENABLE(FTL_NATIVE_CALL_INLINING) guard to BundlePath.cpp after r174940
https://bugs.webkit.org/show_bug.cgi?id=137924
Reviewed by Csaba Osztrogonác.
* runtime/BundlePath.cpp:
2014-10-21 Dániel Bátyai <dbatyai.u-szeged@partner.samsung.com>
Fix FTL Native Inlining for EFL
https://bugs.webkit.org/show_bug.cgi?id=137774
Reviewed by Michael Saboff.
Added required functionality for Native Inlining to EFL, and fixed a bug/typo in the original code,
which caused incorrect memory allocation.
* CMakeLists.txt:
* create-llvm-ir-from-source-file.py: Added.
* create-symbol-table-index.py: Added.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::lower):
(JSC::FTL::LowerDFGToLLVM::getModuleByPathForSymbol):
(JSC::FTL::LowerDFGToLLVM::exitValueForAvailability):
(JSC::FTL::LowerDFGToLLVM::exitValueForNode):
* runtime/BundlePath.cpp: Added.
(JSC::bundlePath):
* runtime/JSDataViewPrototype.cpp:
(JSC::getData):
(JSC::setData):
* runtime/MathObject.cpp:
2014-10-21 Milan Crha <mcrha@redhat.com>
Move JSC::MacroAssemblerX86Common::s_sse2CheckState definition to MacroAssemblerX86Common.cpp.
<https://webkit.org/b/137807>
Reviewed by Csaba Osztrogonác.
* assembler/MacroAssemblerX86Common.cpp:
* jit/JIT.cpp:
2014-10-20 Joseph Pecoraro <pecoraro@apple.com>
Unreviewed add back copyright line that was accidentally removed.
* inspector/scripts/codegen/generator_templates.py:
(GeneratorTemplates):
2014-10-20 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: InspectorBackendCommands should include when to activate particular domains
https://bugs.webkit.org/show_bug.cgi?id=137753
Reviewed by Timothy Hatcher.
Add an availability property to domains that only activate for
particular debuggable types. If missing, the domain is always
activated. Otherwise it must be a debuggable type string.
When a frontend is opened for that debuggable type, the domain
will be activated.
* inspector/scripts/codegen/models.py:
(Protocol.parse_domain):
(Domain.__init__):
(Domains):
Parse and validate the Domain's "availability" property.
* inspector/scripts/codegen/generate_backend_commands.py:
(BackendCommandsGenerator.generate_domain):
Emit InspectorBackend.activateDomain with debuggable type filter.
* inspector/protocol/ApplicationCache.json:
* inspector/protocol/CSS.json:
* inspector/protocol/DOM.json:
* inspector/protocol/DOMDebugger.json:
* inspector/protocol/DOMStorage.json:
* inspector/protocol/Database.json:
* inspector/protocol/IndexedDB.json:
* inspector/protocol/LayerTree.json:
* inspector/protocol/Network.json:
* inspector/protocol/Page.json:
* inspector/protocol/Replay.json:
* inspector/protocol/Timeline.json:
* inspector/protocol/Worker.json:
These domains only activate for Web debuggables.
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
Update existing tests that now have activate output.
* inspector/scripts/tests/expected/fail-on-domain-availability.json-error: Added.
* inspector/scripts/tests/fail-on-domain-availability.json: Added.
Add a test for "availability" validation.
2014-10-20 Joseph Pecoraro <pecoraro@apple.com>
[Win] Build fix for generated inspector files.
Rubberstamped by Brent Fulgham.
* inspector/scripts/codegen/generate_backend_dispatcher_header.py:
(BackendDispatcherHeaderGenerator._generate_async_handler_declaration_for_command):
* inspector/scripts/codegen/generator_templates.py:
(GeneratorTemplates):
2014-10-20 Brent Fulgham <bfulgham@apple.com>
[Win] Unreviewed build fix.
We need to (1) pass the 'windows' argument to our script for checking feature definitions,
and (2) we must use Cwd::realpath on our path input arguments to avoid Cygwin and Windows
getting confused about path separators versus escape characters.
* JavaScriptCore.vcxproj/build-generated-files.pl:
2014-10-20 Mark Lam <mark.lam@apple.com>
[Follow up] Web Process crash when starting the web inspector after r174025.
<https://webkit.org/b/137340>
Reviewed by Geoffrey Garen.
Applied Geoff's feedback to clean up some code for better clarity after
r174856.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::insertCheck):
* dfg/DFGInsertionSet.h:
(JSC::DFG::InsertionSet::insertOutOfOrder):
2014-10-20 Mark Lam <mark.lam@apple.com>
Factor out JITCode::typeName() for debugging use.
<https://webkit.org/b/137888>
Reviewed by Geoffrey Garen.
JITCode's printInternal() currently decodes the JITType into a string and
prints it. This change factors out the part that decodes the JITType into
JITCode::typeName() so that we can call it from lldb while debugging to
quickly decode a JITType value.
* jit/JITCode.cpp:
(JSC::JITCode::typeName):
(WTF::printInternal):
* jit/JITCode.h:
2014-10-20 Joseph Pecoraro <pecoraro@apple.com>
Unreviewed Windows Build Fix #2 after r174892.
* JavaScriptCore.vcxproj/build-generated-files.pl:
Define FEATURE_DEFINES for JavaScriptCore's DerivedSources.make.
This uses the same technique as WebCore.
2014-10-20 Mark Lam <mark.lam@apple.com>
Fix placement of a few items in vcxproj ItemGroups.
<https://webkit.org/b/137886>
Reviewed by Geoffrey Garen.
https://webkit.org/b/137873 is likely a cut-and-paste error that manifested
because we had ClCompile and ClInclude entries mixed up in the wrong ItemGroups.
We should fix these so that ClCompile entries are in the ClCompile ItemGroup,
and ClInclude entries in the ClInclude ItemGroup. This will help reduce the
chance of future cut-and-paste errors of this nature.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2014-10-20 Joseph Pecoraro <pecoraro@apple.com>
Unreviewed Windows Build Fix after r174892.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
Update file name to the new generated file name.
2014-10-20 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Rename generated Inspector.json to CombinedDomains.json to prevent name collisions
https://bugs.webkit.org/show_bug.cgi?id=137825
Reviewed by Timothy Hatcher.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.vcxproj/copy-files.cmd:
* JavaScriptCore.xcodeproj/project.pbxproj:
* inspector/protocol/Inspector.json: Renamed from Source/JavaScriptCore/inspector/protocol/InspectorDomain.json.
2014-10-20 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Generate all Inspector domains together in JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=137748
Reviewed by Brian Burg.
* inspector/protocol/ApplicationCache.json: Renamed from Source/WebCore/inspector/protocol/ApplicationCache.json.
* inspector/protocol/CSS.json: Renamed from Source/WebCore/inspector/protocol/CSS.json.
* inspector/protocol/DOM.json: Renamed from Source/WebCore/inspector/protocol/DOM.json.
* inspector/protocol/DOMDebugger.json: Renamed from Source/WebCore/inspector/protocol/DOMDebugger.json.
* inspector/protocol/DOMStorage.json: Renamed from Source/WebCore/inspector/protocol/DOMStorage.json.
* inspector/protocol/Database.json: Renamed from Source/WebCore/inspector/protocol/Database.json.
* inspector/protocol/IndexedDB.json: Renamed from Source/WebCore/inspector/protocol/IndexedDB.json.
* inspector/protocol/LayerTree.json: Renamed from Source/WebCore/inspector/protocol/LayerTree.json.
* inspector/protocol/Network.json: Renamed from Source/WebCore/inspector/protocol/Network.json.
* inspector/protocol/Page.json: Renamed from Source/WebCore/inspector/protocol/Page.json.
* inspector/protocol/Replay.json: Renamed from Source/WebCore/inspector/protocol/Replay.json.
* inspector/protocol/Timeline.json: Renamed from Source/WebCore/inspector/protocol/Timeline.json.
* inspector/protocol/Worker.json: Renamed from Source/WebCore/inspector/protocol/Worker.json.
Move all protocol files into this directory.
* inspector/InspectorProtocolTypesBase.h: Renamed from Source/JavaScriptCore/inspector/InspectorProtocolTypes.h.
Renamed the base types file to not clash with the generated types file.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.vcxproj/copy-files.cmd:
* JavaScriptCore.xcodeproj/project.pbxproj:
Update build phases for new JSON files and new filenames.
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
Updated names of things now that prefixes are no longer needed.
* inspector/ConsoleMessage.h:
* inspector/ContentSearchUtilities.cpp:
* inspector/ContentSearchUtilities.h:
* inspector/InjectedScript.h:
* inspector/InjectedScriptBase.h:
* inspector/ScriptCallFrame.h:
* inspector/ScriptCallStack.h:
* inspector/agents/InspectorAgent.h:
* inspector/agents/InspectorConsoleAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::breakpointActionTypeForString):
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorRuntimeAgent.h:
* runtime/TypeProfiler.cpp:
* runtime/TypeSet.cpp:
Update includes and update a few function names that are generated.
* inspector/scripts/codegen/generate_protocol_types_header.py:
(ProtocolTypesHeaderGenerator.output_filename):
(ProtocolTypesHeaderGenerator.generate_output):
Include an export macro for type string constants defined in the implementation file.
* inspector/scripts/codegen/generate_backend_commands.py:
(BackendCommandsGenerator.output_filename):
* inspector/scripts/codegen/generate_backend_dispatcher_header.py:
(BackendDispatcherHeaderGenerator.output_filename):
(BackendDispatcherHeaderGenerator.generate_output):
* inspector/scripts/codegen/generate_backend_dispatcher_implementation.py:
(BackendDispatcherImplementationGenerator.output_filename):
(BackendDispatcherImplementationGenerator.generate_output):
(BackendDispatcherImplementationGenerator._generate_async_dispatcher_class_for_domain):
(BackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
* inspector/scripts/codegen/generate_frontend_dispatcher_header.py:
(FrontendDispatcherHeaderGenerator.output_filename):
(FrontendDispatcherHeaderGenerator.generate_output):
* inspector/scripts/codegen/generate_frontend_dispatcher_implementation.py:
(FrontendDispatcherImplementationGenerator.output_filename):
(FrontendDispatcherImplementationGenerator.generate_output):
(FrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event):
(_generate_class_for_object_declaration):
(_generate_builder_setter_for_member):
(_generate_unchecked_setter_for_member):
* inspector/scripts/codegen/generate_protocol_types_implementation.py:
(ProtocolTypesImplementationGenerator.output_filename):
(ProtocolTypesImplementationGenerator.generate_output):
(ProtocolTypesImplementationGenerator._generate_enum_mapping):
* inspector/scripts/codegen/models.py:
(Framework.fromString):
(Frameworks):
* inspector/scripts/generate-inspector-protocol-bindings.py:
Simplify generator now that prefixes are no longer needed. This updates
filenames, includes, and the list of supported directories.
2014-10-20 Csaba Osztrogonác <ossy@webkit.org>
Remove obsolete comments after r99798
https://bugs.webkit.org/show_bug.cgi?id=137871
Reviewed by Darin Adler.
r99798 removed the comment in MacroAssemblerARMv7::supportsFloatingPointTruncate(),
so we should remove the stale references to this removed comment.
* assembler/MacroAssemblerX86.h:
* assembler/MacroAssemblerX86_64.h:
2014-10-20 Csaba Osztrogonác <ossy@webkit.org>
MacroAssemblerX86Common.cpp should be built on Windows too
https://bugs.webkit.org/show_bug.cgi?id=137873
Reviewed by Brent Fulgham.
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2014-10-20 Csaba Osztrogonác <ossy@webkit.org>
[cmake] Remove duplicated source files
https://bugs.webkit.org/show_bug.cgi?id=137875
Reviewed by Gyuyoung Kim.
* CMakeLists.txt:
2014-10-18 Brian J. Burg <burg@cs.washington.edu>
Web Replay: code generator shouldn't complain about enums without a storage type if they are in an enclosing scope
https://bugs.webkit.org/show_bug.cgi?id=137084
Reviewed by Joseph Pecoraro.
In order to generate encode/decode method declarations without pulling in lots of headers,
the generator must forward declare enums (for enum classes or enums with explicit sizes).
Change the generator to not require an explicit size if an enum is declared inside a struct
or class definition. In that case, it must pull in headers since scoped enums can't be
forward declared.
This patch also fixes some chained if-statements that should be if-else statements.
Test: updated replay/scripts/tests/generate-enum-encoding-helpers.json to cover the new case.
* replay/scripts/CodeGeneratorReplayInputs.py:
(InputsModel.parse_type_with_framework_name.is):
(InputsModel.parse_type_with_framework_name.is.must):
(Generator.generate_enum_trait_implementation):
(InputsModel.parse_type_with_framework_name): Deleted.
* replay/scripts/CodeGeneratorReplayInputsTemplates.py:
* replay/scripts/tests/expected/fail-on-c-style-enum-no-storage.json-error:
* replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.cpp:
(JSC::EncodingTraits<WebCore::MouseButton>::decodeValue):
* replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.cpp:
(JSC::EncodingTraits<WebCore::MouseButton>::decodeValue):
(JSC::EncodingTraits<WebCore::PlatformEvent::Type>::encodeValue):
(JSC::EncodingTraits<WebCore::PlatformEvent::Type>::decodeValue):
* replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.cpp:
(JSC::EncodingTraits<WebCore::FormData1::Type>::decodeValue):
(JSC::EncodingTraits<PlatformEvent1::Type>::decodeValue):
* replay/scripts/tests/generate-enum-encoding-helpers.json: Added a new input to cover this case.
2014-10-17 Mark Lam <mark.lam@apple.com>
Web Process crash when starting the web inspector after r174025.
<https://webkit.org/b/137340>
Reviewed by Filip Pizlo.
After r174025, we can generate a bad graph in the DFG fixup phase like so:
102:<!0:-> StoreBarrier(Check:KnownCell:@19, ..., bc#44)
60:<!0:-> PutStructure(Check:KnownCell:@19, ..., bc#44)
103:<!0:-> Check(Check:NotCell:@54, ..., bc#44)
// ^-- PutByOffset's StoreBarrier has been elided and replaced
// with a speculation check which can OSR exit.
61:<!0:-> PutByOffset(Check:KnownCell:@19, ..., bc#44)
As a result, the structure change will get executed even if we end up OSR
exiting before the PutByOffset. In the baseline JIT code, the structure now
erroneously tells the put operation that there is a value in that property
slot when it is actually uninitialized (hence, the crash).
The fix is to insert the Check at the earliest point possible:
1. If the checked node is in the same bytecode as the PutByOffset, then
the earliest point where we can insert the Check is right after the
checked node.
2. If the checked node is from a preceding bytecode (before the PutByOffset),
then the earliest point where we can insert the Check is at the start
of the current bytecode.
Also reverted the workaround from r174749: https://webkit.org/b/137758.
Benchmark results appear to be a wash on aggregate.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::indexOfNode):
(JSC::DFG::FixupPhase::indexOfFirstNodeOfExitOrigin):
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::insertCheck):
* dfg/DFGInsertionSet.h:
(JSC::DFG::InsertionSet::insertOutOfOrder):
(JSC::DFG::InsertionSet::insertOutOfOrderNode):
2014-10-10 Oliver Hunt <oliver@apple.com>
Various arguments optimisations in codegen fail to account for arguments being in lexical record
https://bugs.webkit.org/show_bug.cgi?id=137617
Reviewed by Michael Saboff.
Rework the way we track |arguments| references so that we don't try
to use the |arguments| reference on the stack if it's not safe.
To do this without nuking performance it was necessary to update
the parser to track modification of the |arguments| reference
itself.
* bytecode/CodeBlock.cpp:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::willResolveToArguments):
(JSC::BytecodeGenerator::uncheckedLocalArgumentsRegister):
(JSC::BytecodeGenerator::emitCall):
(JSC::BytecodeGenerator::emitConstruct):
(JSC::BytecodeGenerator::emitEnumeration):
(JSC::BytecodeGenerator::uncheckedRegisterForArguments): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::hasSafeLocalArgumentsRegister):
* bytecompiler/NodesCodegen.cpp:
(JSC::BracketAccessorNode::emitBytecode):
(JSC::DotAccessorNode::emitBytecode):
(JSC::getArgumentByVal):
(JSC::CallFunctionCallDotNode::emitBytecode):
(JSC::ApplyFunctionCallDotNode::emitBytecode):
(JSC::ArrayPatternNode::emitDirectBinding):
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::existingArguments):
* parser/Nodes.h:
(JSC::ScopeNode::modifiesArguments):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
* parser/Parser.h:
(JSC::Scope::getCapturedVariables):
* parser/ParserModes.h:
2014-10-17 Gyuyoung Kim <gyuyoung.kim@samsung.com>
Use WTF::move() instead of std::move() to help ensure move semantics in JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=137809
Reviewed by Csaba Osztrogonác.
Substitution of WTF::move() for std::move(). Clean up std::move() in JavaScriptCore.
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeForStubInfo):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeForStubInfo):
* bytecode/PutByIdVariant.cpp:
(JSC::PutByIdVariant::setter):
2014-10-15 Oliver Hunt <oliver@apple.com>
Use a single allocation for the Arguments object
https://bugs.webkit.org/show_bug.cgi?id=137751
Reviewed by Filip Pizlo.
This patch removes the secondary allocation for parameters in the Arguments
object. This is faily simple, but we needed to make it possible for the JIT
to allocate a variable GC object. To do this i've added a new
emitAllocateVariableSizedJSObject function to the JIT that does the work to
find the correct heap for a variable sized allocation and then bump that
allocator.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitAllocateArguments):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject):
* heap/CopyToken.h:
* heap/Heap.h:
(JSC::Heap::subspaceForObjectWithoutDestructor):
(JSC::Heap::subspaceForObjectNormalDestructor):
(JSC::Heap::subspaceForObjectsWithImmortalStructure):
* heap/MarkedSpace.h:
(JSC::MarkedSpace::subspaceForObjectsWithNormalDestructor):
(JSC::MarkedSpace::subspaceForObjectsWithImmortalStructure):
(JSC::MarkedSpace::subspaceForObjectsWithoutDestructor):
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::createArguments):
* runtime/Arguments.cpp:
(JSC::Arguments::visitChildren):
(JSC::Arguments::copyBackingStore):
(JSC::Arguments::tearOff):
(JSC::Arguments::allocateRegisterArray): Deleted.
* runtime/Arguments.h:
(JSC::Arguments::create):
(JSC::Arguments::isTornOff):
(JSC::Arguments::offsetOfRegisterArray):
(JSC::Arguments::registerArraySizeInBytes):
(JSC::Arguments::registerArray):
(JSC::Arguments::allocationSize): Deleted.
2014-10-15 Filip Pizlo <fpizlo@apple.com>
Apparently we've had a hole in arguments capture all along
https://bugs.webkit.org/show_bug.cgi?id=137767
Reviewed by Oliver Hunt.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::getArgument):
* tests/stress/arguments-captured.js: Added.
(foo):
(bar):
2014-10-16 Saam Barati <saambarati1@gmail.com>
Have the ProfileType node in the DFG convert to a structure check where it can
https://bugs.webkit.org/show_bug.cgi?id=137596
Reviewed by Filip Pizlo.
TypeSet now keeps track of the live set of Structures it has seen.
It no longer nukes everything during GC. It now only removes unmarked
structures during GC. This modification allows the ProfileType node
to convert into a CheckStructure node safely in the DFG.
This change brings up the conversion rate from ProfileType to Check
or CheckStructrue from ~45% to ~65%. This change also speeds the
type profiler up significantly: consistently between 2x-20x faster.
This patch also does some slight refactoring: a few type profiler
related fields are moved from VM to TypeProfiler.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToCheckStructure):
* heap/Heap.cpp:
(JSC::Heap::collect):
* runtime/SymbolTable.cpp:
(JSC::SymbolTable::uniqueIDForVariable):
* runtime/SymbolTable.h:
* runtime/TypeLocationCache.cpp:
(JSC::TypeLocationCache::getTypeLocation):
* runtime/TypeProfiler.cpp:
(JSC::TypeProfiler::TypeProfiler):
(JSC::TypeProfiler::nextTypeLocation):
(JSC::TypeProfiler::invalidateTypeSetCache):
(JSC::TypeProfiler::dumpTypeProfilerData):
* runtime/TypeProfiler.h:
(JSC::TypeProfiler::getNextUniqueVariableID):
* runtime/TypeProfilerLog.cpp:
(JSC::TypeProfilerLog::processLogEntries):
* runtime/TypeSet.cpp:
(JSC::TypeSet::addTypeInformation):
(JSC::TypeSet::invalidateCache):
* runtime/TypeSet.h:
(JSC::TypeSet::structureSet):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::enableTypeProfiler):
(JSC::VM::disableTypeProfiler):
(JSC::VM::dumpTypeProfilerData):
(JSC::VM::nextTypeLocation): Deleted.
(JSC::VM::invalidateTypeSetCache): Deleted.
* runtime/VM.h:
(JSC::VM::typeProfiler):
(JSC::VM::getNextUniqueVariableID): Deleted.
* tests/typeProfiler/dfg-jit-optimizations.js:
2014-10-16 Adrien Destugues <pulkomandy@gmail.com>
Use isnan from std namespace in ProfileGenerator.cpp
https://bugs.webkit.org/show_bug.cgi?id=137653
Reviewed by Darin Adler.
The C++ isnan() function is in the std namespace. The unprefixed isnan
may be available because of C99 headers leakage in C++, but should not
be used.
No new tests: no functional change, build fix on platforms which don't
export C99 functions in C++.
* profiler/ProfileGenerator.cpp:
(JSC::ProfileGenerator::beginCallEntry):
(JSC::ProfileGenerator::endCallEntry):
(JSC::ProfileGenerator::didPause):
(JSC::ProfileGenerator::didContinue):
2014-10-15 Michael Saboff <msaboff@apple.com>
REGRESSION(r174025): remote inspector crashes frequently when executing inspector frontend's JavaScript
https://bugs.webkit.org/show_bug.cgi?id=137758
Rubber stamped by Filip Pizlo.
Reverted r174025 for just PutByOffset Nodes.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
2014-10-14 Gyuyoung Kim <gyuyoung.kim@samsung.com>
Clean up unnecessary PassOwnPtr.h inclusion
https://bugs.webkit.org/show_bug.cgi?id=137726
Reviewed by Chris Dumez.
* API/JSCallbackObject.h: Remove PassOwnPtr.h inclusion.
* bytecode/DFGExitProfile.cpp: ditto.
2014-10-14 Brent Fulgham <bfulgham@apple.com>
[Win] Unreviewed gardening. Ignore Visual Studio *.sdf files.
* JavaScriptCore.vcxproj: Modified properties svn:ignore and svn:ignore.
* JavaScriptCore.vcxproj/jsc: Modified property svn:ignore.
2014-10-14 Matthew Mirman <mmirman@apple.com>
Removes references to LLVMJIT which is no longer part of LLVM
https://bugs.webkit.org/show_bug.cgi?id=137708
Reviewed by Filip Pizlo.
* Configurations/LLVMForJSC.xcconfig: removed -lLLVMJIT
* llvm/LLVMAPIFunctions.h: removed LinkInJIT
2014-10-14 peavo@outlook.com <peavo@outlook.com>
[Win32] Thunk is not implemented.
https://bugs.webkit.org/show_bug.cgi?id=137691
Reviewed by Mark Lam.
Thunks for functions with double operands (floor, etc.) are not implemented on Win32.
* jit/ThunkGenerators.cpp:
2014-10-12 Alexey Proskuryakov <ap@apple.com>
Adding svn:ignore so that .pyc files don't show up as new.
* inspector/scripts/codegen: Added property svn:ignore.
2014-10-10 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r174606.
https://bugs.webkit.org/show_bug.cgi?id=137621
broke a JSC test (Requested by estes on #webkit).
Reverted changeset:
"Various arguments optimisations in codegen fail to account
for arguments being in lexical record"
https://bugs.webkit.org/show_bug.cgi?id=137617
http://trac.webkit.org/changeset/174606
2014-10-10 Oliver Hunt <oliver@apple.com>
Various arguments optimisations in codegen fail to account for arguments being in lexical record
https://bugs.webkit.org/show_bug.cgi?id=137617
Reviewed by Michael Saboff.
Rework the way we track |arguments| references so that we don't try
to use the |arguments| reference on the stack if it's not safe.
To do this without nuking performance it was necessary to update
the parser to track modification of the |arguments| reference
itself.
* bytecode/CodeBlock.cpp:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::willResolveToArguments):
(JSC::BytecodeGenerator::uncheckedLocalArgumentsRegister):
(JSC::BytecodeGenerator::emitCall):
(JSC::BytecodeGenerator::emitConstruct):
(JSC::BytecodeGenerator::emitEnumeration):
(JSC::BytecodeGenerator::uncheckedRegisterForArguments): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::hasSafeLocalArgumentsRegister):
* bytecompiler/NodesCodegen.cpp:
(JSC::BracketAccessorNode::emitBytecode):
(JSC::DotAccessorNode::emitBytecode):
(JSC::getArgumentByVal):
(JSC::CallFunctionCallDotNode::emitBytecode):
(JSC::ApplyFunctionCallDotNode::emitBytecode):
(JSC::ArrayPatternNode::emitDirectBinding):
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::existingArguments):
* parser/Nodes.h:
(JSC::ScopeNode::modifiesArguments):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
* parser/Parser.h:
(JSC::Scope::getCapturedVariables):
* parser/ParserModes.h:
2014-10-09 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Remove unused generator code
https://bugs.webkit.org/show_bug.cgi?id=137564
Reviewed by Brian Burg.
* inspector/scripts/codegen/generate_backend_dispatcher_header.py:
(BackendDispatcherHeaderGenerator.generate_output): Deleted.
* inspector/scripts/codegen/generate_backend_dispatcher_implementation.py:
(BackendDispatcherImplementationGenerator.generate_output):
* inspector/scripts/codegen/generate_frontend_dispatcher_header.py:
(FrontendDispatcherHeaderGenerator.generate_output):
* inspector/scripts/codegen/generate_frontend_dispatcher_implementation.py:
(FrontendDispatcherImplementationGenerator.generate_output):
* inspector/scripts/codegen/generate_protocol_types_header.py:
(ProtocolTypesHeaderGenerator.generate_output):
* inspector/scripts/codegen/generate_protocol_types_implementation.py:
(ProtocolTypesImplementationGenerator.generate_output):
inputFilename is now handled by the generic generator base class.
* inspector/scripts/codegen/models.py:
(Framework.fromString):
(Frameworks):
* inspector/scripts/generate-inspector-protocol-bindings.py:
The WTF framework is unused. Remove unexpected frameworks.
2014-10-09 Dean Jackson <dino@apple.com>
Remove ENABLE_CSS3_CONDITIONAL_RULES
https://bugs.webkit.org/show_bug.cgi?id=137571
Reviewed by Simon Fraser.
* Configurations/FeatureDefines.xcconfig:
2014-10-09 Adrien Destugues <pulkomandy@gmail.com>
Fix compiler warning on noreturn function
https://bugs.webkit.org/show_bug.cgi?id=137558
Reviewed by Darin Adler.
The function is marked "noreturn", but the stub implementation does
return. No new tests: function is never called. Only fixes a warning.
* heap/HeapStatistics.cpp:
(JSC::HeapStatistics::exitWithFailure):
2014-10-09 Akos Kiss <akiss@inf.u-szeged.hu>
Ensure that inline assembly Thunk functions don't conflict with the section designations of the compiler
https://bugs.webkit.org/show_bug.cgi?id=137434
Reviewed by Michael Saboff.
The ARM64 version of the defineUnaryDoubleOpWrapper macro in
ThunkGenerators.cpp contains inline assembly with .text assembler
directive followed by a static variable declaration. This macro gets
expanded several times afterwards, however, only during the compilation
of the first expansion does gcc insert a .data assembler directive
before the assembled version of the static variable. Thus, only the
first variable gets allocated in the .data section, all the others
remain in .text. If JavaScriptCore is built as a shared library then
this causes a segmentation fault during dynamic linking.
This patch puts a .previous directive at the end of the inline assembly
to ensure that the assumptions of the compiler about the sections are
not broken and the following variable goes to the right place.
* jit/ThunkGenerators.cpp:
2014-10-08 Oliver Hunt <oliver@apple.com>
Make sure arguments tearoff is performed through the environment record if necessary
https://bugs.webkit.org/show_bug.cgi?id=137538
Reviewed by Michael Saboff.
Fairly simple change. If we have a lexical record we need to pull the unmodified
arguments object from the record and then use the standard op_tear_off_arguments
instruction on the temporary.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitGetOwnScope):
(JSC::BytecodeGenerator::emitReturn):
* bytecompiler/BytecodeGenerator.h:
2014-10-08 peavo@outlook.com <peavo@outlook.com>
[WinCairo] Enable JIT on 32-bit.
https://bugs.webkit.org/show_bug.cgi?id=137521
Reviewed by Mark Lam.
Enable JIT on Windows 32-bit, but disable it at runtime if SSE2 is not present.
* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.pl:
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
2014-10-08 Brent Fulgham <bfulgham@apple.com>
[Win] Resolve some static analysis warnings in JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=137508
Reviewed by Geoffrey Garen.
* API/tests/testapi.c:
(assertEqualsAsCharactersPtr): MSVC insists on using %Iu as its format specifier
for size_t. Make the format string conditional on Windows.
* bytecode/Watchpoint.h:
(JSC::InlineWatchpointSet::encodeState): Silence warning about left-shifting 'state'
as a 32-bit value before OR-ing it with a 64-bit value.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode): Silence warning about operator prescedence
causing the || operation to take place before the >= test.
* dfg/DFGInPlaceAbstractState.cpp:
(JSC::DFG::InPlaceAbstractState::endBasicBlock): Ditto (|| before !=)
* testRegExp.cpp:
(testOneRegExp): Ditto %Iu format specifier.
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::Interpreter::allocParenthesesDisjunctionContext): Silence warning about
using a 32-bit value as part of a 64-bit calculation.
2014-10-07 Simon Fraser <simon.fraser@apple.com>
Roll-over Changelogs.
* ChangeLog-2014-10-07: Copied from Source/JavaScriptCore/ChangeLog.
== Rolled over to ChangeLog-2014-10-07 ==