Google Git
Sign in
webkit / WebKit / 5fa861cdb2dd355b08d554b74c0fd27ec1c95b52 / . / Source / JavaScriptCore / ChangeLog
blob: 705fbebe217072887b64ce208972351c5c0fb843 [file] [log] [blame]
2019-03-08 Robin Morisset <rmorisset@apple.com>
IntegerCheckCombiningPhase::Range can be shrunk by 8 bytes
https://bugs.webkit.org/show_bug.cgi?id=195487
Reviewed by Saam Barati.
* dfg/DFGIntegerCheckCombiningPhase.cpp:
2019-03-08 Robin Morisset <rmorisset@apple.com>
TypeLocation can be shrunk by 8 bytes
https://bugs.webkit.org/show_bug.cgi?id=195483
Reviewed by Mark Lam.
* bytecode/TypeLocation.h:
(JSC::TypeLocation::TypeLocation):
2019-03-08 Robin Morisset <rmorisset@apple.com>
GetByIdStatus can be shrunk by 16 bytes
https://bugs.webkit.org/show_bug.cgi?id=195480
Reviewed by Saam Barati.
8 bytes from reordering fields
8 more bytes by making the enum State only use 1 byte.
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::GetByIdStatus):
* bytecode/GetByIdStatus.h:
2019-03-08 Robin Morisset <rmorisset@apple.com>
PutByIdVariant can be shrunk by 8 bytes
https://bugs.webkit.org/show_bug.cgi?id=195482
Reviewed by Mark Lam.
* bytecode/PutByIdVariant.h:
(JSC::PutByIdVariant::PutByIdVariant):
2019-03-08 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, follow-up after r242568
Robin pointed that calculation of `numberOfChildren` and `nonEmptyIndex` is unnecessary.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2019-03-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] We should have more WithoutTransition functions which are usable for JSGlobalObject initialization
https://bugs.webkit.org/show_bug.cgi?id=195447
Reviewed by Filip Pizlo.
This patch reduces # of unnecessary structure transitions in JSGlobalObject initialization to avoid unnecessary allocations
caused by Structure transition. One example is WeakBlock allocation for StructureTransitionTable.
To achieve this, we (1) add putDirectNonIndexAccessorWithoutTransition and putDirectNativeIntrinsicGetterWithoutTransition
to add accessor properties without transition, and (2) add NameAdditionMode::WithoutStructureTransition mode to InternalFunction::finishCreation
to use `putDirectWithoutTransition` instead of `putDirect`.
* inspector/JSInjectedScriptHostPrototype.cpp:
(Inspector::JSInjectedScriptHostPrototype::finishCreation):
* inspector/JSJavaScriptCallFramePrototype.cpp:
(Inspector::JSJavaScriptCallFramePrototype::finishCreation):
* runtime/ArrayConstructor.cpp:
(JSC::ArrayConstructor::finishCreation):
* runtime/AsyncFunctionConstructor.cpp:
(JSC::AsyncFunctionConstructor::finishCreation):
* runtime/AsyncGeneratorFunctionConstructor.cpp:
(JSC::AsyncGeneratorFunctionConstructor::finishCreation):
* runtime/BigIntConstructor.cpp:
(JSC::BigIntConstructor::finishCreation):
* runtime/BooleanConstructor.cpp:
(JSC::BooleanConstructor::finishCreation):
* runtime/DateConstructor.cpp:
(JSC::DateConstructor::finishCreation):
* runtime/ErrorConstructor.cpp:
(JSC::ErrorConstructor::finishCreation):
* runtime/FunctionConstructor.cpp:
(JSC::FunctionConstructor::finishCreation):
* runtime/FunctionPrototype.cpp:
(JSC::FunctionPrototype::finishCreation):
(JSC::FunctionPrototype::addFunctionProperties):
(JSC::FunctionPrototype::initRestrictedProperties):
* runtime/FunctionPrototype.h:
* runtime/GeneratorFunctionConstructor.cpp:
(JSC::GeneratorFunctionConstructor::finishCreation):
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::finishCreation):
* runtime/InternalFunction.h:
* runtime/IntlCollatorConstructor.cpp:
(JSC::IntlCollatorConstructor::finishCreation):
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::IntlDateTimeFormatConstructor::finishCreation):
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::IntlNumberFormatConstructor::finishCreation):
* runtime/IntlPluralRulesConstructor.cpp:
(JSC::IntlPluralRulesConstructor::finishCreation):
* runtime/JSArrayBufferConstructor.cpp:
(JSC::JSGenericArrayBufferConstructor<sharingMode>::finishCreation):
* runtime/JSArrayBufferPrototype.cpp:
(JSC::JSArrayBufferPrototype::finishCreation):
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSObject.cpp:
(JSC::JSObject::putDirectNonIndexAccessorWithoutTransition):
(JSC::JSObject::putDirectNativeIntrinsicGetterWithoutTransition):
* runtime/JSObject.h:
* runtime/JSPromiseConstructor.cpp:
(JSC::JSPromiseConstructor::finishCreation):
* runtime/JSTypedArrayViewConstructor.cpp:
(JSC::JSTypedArrayViewConstructor::finishCreation):
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::JSTypedArrayViewPrototype::finishCreation):
* runtime/MapConstructor.cpp:
(JSC::MapConstructor::finishCreation):
* runtime/MapPrototype.cpp:
(JSC::MapPrototype::finishCreation):
* runtime/NativeErrorConstructor.cpp:
(JSC::NativeErrorConstructorBase::finishCreation):
* runtime/NullGetterFunction.h:
* runtime/NullSetterFunction.h:
* runtime/NumberConstructor.cpp:
(JSC::NumberConstructor::finishCreation):
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructor::finishCreation):
* runtime/ProxyConstructor.cpp:
(JSC::ProxyConstructor::finishCreation):
* runtime/RegExpConstructor.cpp:
(JSC::RegExpConstructor::finishCreation):
* runtime/RegExpPrototype.cpp:
(JSC::RegExpPrototype::finishCreation):
* runtime/SetConstructor.cpp:
(JSC::SetConstructor::finishCreation):
* runtime/SetPrototype.cpp:
(JSC::SetPrototype::finishCreation):
* runtime/StringConstructor.cpp:
(JSC::StringConstructor::finishCreation):
* runtime/SymbolConstructor.cpp:
(JSC::SymbolConstructor::finishCreation):
* runtime/WeakMapConstructor.cpp:
(JSC::WeakMapConstructor::finishCreation):
* runtime/WeakSetConstructor.cpp:
(JSC::WeakSetConstructor::finishCreation):
* wasm/js/WebAssemblyCompileErrorConstructor.cpp:
(JSC::WebAssemblyCompileErrorConstructor::finishCreation):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::WebAssemblyInstanceConstructor::finishCreation):
* wasm/js/WebAssemblyLinkErrorConstructor.cpp:
(JSC::WebAssemblyLinkErrorConstructor::finishCreation):
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::WebAssemblyMemoryConstructor::finishCreation):
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::WebAssemblyModuleConstructor::finishCreation):
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
(JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):
* wasm/js/WebAssemblyTableConstructor.cpp:
(JSC::WebAssemblyTableConstructor::finishCreation):
2019-03-08 Tadeu Zagallo <tzagallo@apple.com>
op_check_tdz does not def its argument
https://bugs.webkit.org/show_bug.cgi?id=192880
<rdar://problem/46221598>
Reviewed by Saam Barati.
This prevented the for-in loop optimization in the bytecode generator, since
the analysis sees a redefinition of the loop variable.
* bytecode/BytecodeUseDef.h:
(JSC::computeDefsForBytecodeOffset):
2019-03-07 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Make more fields lazy in JSGlobalObject
https://bugs.webkit.org/show_bug.cgi?id=195449
Reviewed by Mark Lam.
This patch makes more fields lazy-allocated in JSGlobalObject to save memory.
1. Some minor structures like moduleRecordStructure.
2. Some functions like parseInt / parseFloat. While they are eagerly created in JIT mode anyway to materialize NumberConstructor, we can lazily allocate them in non JIT mode.
3. ArrayBuffer constructor. While it is eagerly allocated in WebCore, we can make lazily allocated in JSC.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
* runtime/JSArrayBufferPrototype.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::parseIntFunction const):
(JSC::JSGlobalObject::parseFloatFunction const):
(JSC::JSGlobalObject::evalFunction const):
(JSC::JSGlobalObject::strictEvalActivationStructure const):
(JSC::JSGlobalObject::moduleRecordStructure const):
(JSC::JSGlobalObject::moduleNamespaceObjectStructure const):
(JSC::JSGlobalObject::proxyObjectStructure const):
(JSC::JSGlobalObject::callableProxyObjectStructure const):
(JSC::JSGlobalObject::proxyRevokeStructure const):
(JSC::JSGlobalObject::arrayBufferConstructor const):
(JSC::JSGlobalObject::arrayBufferPrototype const):
(JSC::JSGlobalObject::arrayBufferStructure const):
* runtime/ProxyObject.h:
* runtime/StrictEvalActivation.cpp:
(JSC::StrictEvalActivation::StrictEvalActivation):
* runtime/StrictEvalActivation.h:
* wasm/js/JSWebAssemblyMemory.cpp:
(JSC::JSWebAssemblyMemory::buffer):
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::webAssemblyModuleCustomSections):
2019-03-07 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Remove merging must handle values into proven types in CFA
https://bugs.webkit.org/show_bug.cgi?id=195444
Reviewed by Saam Barati.
Previously, we are merging must handle values as a proven constant in CFA. This is OK as long as this proven AbstractValue is blurred by merging the other legit AbstractValues
from the successors. But let's consider the following code, this is actually generated DFG graph from the attached test in r242626.
Block #2 (loop header) succ #3, #4
...
1: ForceOSRExit
...
2: JSConstant(0)
3: SetLocal(@2, loc6)
...
4: Branch(#3, #4)
Block #3 (This is OSR entry target) pred #2, #3, must handle value for loc6 => JSConstant(Int32, 31)
...
5: GetLocal(loc6)
6: StringFromCharCode(@5)
...
Block #3 is OSR entry target. So we have must handle value for loc6 and it is Int32 constant 31. Then we merge this constant as a proven value in #3's loc6 AbstractValue.
If the value from #2 blurs the value, it is OK. However, #2 has ForceOSRExit. So must handle value suddenly becomes the only source of loc6 in #3. Then we use this constant
as a proven value. But this is not expected behavior since must handle value is just a snapshot of the locals when we kick off the concurrent compilation. In the above example,
we assume that loop index is an constant 31, but it is wrong, and OSR entry fails. Because there is no strong assumption that the must handle value is the proven type or value,
we should not merge it in CFA.
Since (1) this is just an optimization, (2) type information is already propagated in prediction injection phase, and (3) the must handle value does not show the performance
progression in r211461 and we no longer see type misprediction in marsaglia-osr-entry.js, this patch simply removes must handle value type widening in CFA.
* dfg/DFGCFAPhase.cpp:
(JSC::DFG::CFAPhase::run):
(JSC::DFG::CFAPhase::performBlockCFA):
(JSC::DFG::CFAPhase::injectOSR): Deleted.
2019-03-07 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] StringFromCharCode fast path should accept 0xff in DFG and FTL
https://bugs.webkit.org/show_bug.cgi?id=195429
Reviewed by Saam Barati.
We can create single characters without allocation up to 0xff character code. But currently, DFGSpeculativeJIT and FTLLowerDFGToB3 go to the slow path
for 0xff case. On the other hand, DFG DoesGC phase says GC won't happen if the child is int32 constant and it is <= 0xff. So, if you have `String.fromCharCode(0xff)`,
this breaks the assumption in DFG DoesGC. The correct fix is changing the check in DFGSpeculativeJIT and FTLLowerDFGToB3 from AboveOrEqual to Above.
Note that ThunkGenerators's StringFromCharCode thunk was correct.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileFromCharCode):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):
2019-03-07 Mark Lam <mark.lam@apple.com>
Follow up refactoring in try-finally code after r242591.
https://bugs.webkit.org/show_bug.cgi?id=195428
Reviewed by Saam Barati.
1. Added some comments in emitFinallyCompletion() to describe each completion case.
2. Converted CatchEntry into a struct.
3. Renamed variable hasBreaksOrContinuesNotCoveredByJumps to hasBreaksOrContinuesThatEscapeCurrentFinally
to be more clear about its purpose.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::emitOutOfLineExceptionHandler):
(JSC::BytecodeGenerator::emitFinallyCompletion):
* bytecompiler/BytecodeGenerator.h:
2019-03-07 Saam Barati <sbarati@apple.com>
CompactVariableMap::Handle's copy operator= leaks the previous data
https://bugs.webkit.org/show_bug.cgi?id=195398
Reviewed by Yusuke Suzuki.
The copy constructor was just assigning |this| to the new value,
forgetting to decrement the ref count of the thing pointed to by
the |this| handle. Based on Yusuke's suggestion, this patch refactors
the move constructor, move operator=, and copy operator= to use the
swap() primitive and the copy constructor primitive.
* parser/VariableEnvironment.cpp:
(JSC::CompactVariableMap::Handle::Handle):
(JSC::CompactVariableMap::Handle::swap):
(JSC::CompactVariableMap::Handle::operator=): Deleted.
* parser/VariableEnvironment.h:
(JSC::CompactVariableMap::Handle::Handle):
(JSC::CompactVariableMap::Handle::operator=):
2019-03-07 Tadeu Zagallo <tzagallo@apple.com>
Lazily decode cached bytecode
https://bugs.webkit.org/show_bug.cgi?id=194810
Reviewed by Saam Barati.
Like lazy parsing, we should pause at code block boundaries. Instead
of always eagerly decoding UnlinkedFunctionExecutable's UnlinkedCodeBlocks,
we store their offsets in the executable and lazily decode them on the next
call to `unlinkedCodeBlockFor`.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::UnlinkedFunctionExecutable::~UnlinkedFunctionExecutable):
(JSC::UnlinkedFunctionExecutable::visitChildren):
(JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
(JSC::UnlinkedFunctionExecutable::decodeCachedCodeBlocks):
* bytecode/UnlinkedFunctionExecutable.h:
* runtime/CachedTypes.cpp:
(JSC::Decoder::Decoder):
(JSC::Decoder::~Decoder):
(JSC::Decoder::create):
(JSC::Decoder::offsetOf):
(JSC::Decoder::cacheOffset):
(JSC::Decoder::ptrForOffsetFromBase):
(JSC::Decoder::handleForEnvironment const):
(JSC::Decoder::setHandleForEnvironment):
(JSC::Decoder::addFinalizer):
(JSC::VariableLengthObject::isEmpty const):
(JSC::CachedWriteBarrier::isEmpty const):
(JSC::CachedFunctionExecutable::unlinkedCodeBlockForCall const):
(JSC::CachedFunctionExecutable::unlinkedCodeBlockForConstruct const):
(JSC::CachedFunctionExecutable::decode const):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::decodeCodeBlockImpl):
(JSC::isCachedBytecodeStillValid):
(JSC::decodeFunctionCodeBlock):
* runtime/CachedTypes.h:
(JSC::Decoder::vm):
2019-03-06 Mark Lam <mark.lam@apple.com>
Exception is a JSCell, not a JSObject.
https://bugs.webkit.org/show_bug.cgi?id=195392
Reviewed by Saam Barati.
Exception is a VM implementation construct to carry a stack trace for the point
where it is thrown from. As a reminder, an Exception is needed because:
1. JS code can throw primitives as well that are non-cells.
2. Error objects capture the stack trace at the point where they are constructed,
which is not always the same as the point where they are thrown (if they are
thrown).
Hence, Exception should not be visible to JS code, and therefore should not be a
JSObject. Hence, it should not inherit from JSDestructibleObject.
This patch changes the following:
1. Exception now inherits directly from JSCell instead.
2. Places where we return an Exception masquerading as a JSObject* are now
updated to return a nullptr when we encounter an exception.
3. We still return Exception* as JSValue or EncodedJSValue when we encounter an
exception in functions that return JSValue or EncodedJSValue. This is because
the number that implements the following pattern is too numerous:
return throw<Some Error>(...)
We'll leave these as is for now.
* bytecode/CodeBlock.h:
(JSC::ScriptExecutable::prepareForExecution):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::executeProgram):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
(JSC::Interpreter::prepareForRepeatCall):
(JSC::Interpreter::execute):
(JSC::Interpreter::executeModuleProgram):
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setUpCall):
* runtime/ConstructData.cpp:
(JSC::construct):
* runtime/Error.cpp:
(JSC::throwConstructorCannotBeCalledAsFunctionTypeError):
(JSC::throwTypeError):
(JSC::throwSyntaxError):
* runtime/Error.h:
(JSC::throwRangeError):
* runtime/Exception.cpp:
(JSC::Exception::createStructure):
* runtime/Exception.h:
* runtime/ExceptionHelpers.cpp:
(JSC::throwOutOfMemoryError):
(JSC::throwStackOverflowError):
(JSC::throwTerminatedExecutionException):
* runtime/ExceptionHelpers.h:
* runtime/FunctionConstructor.cpp:
(JSC::constructFunction):
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/IntlPluralRules.cpp:
(JSC::IntlPluralRules::resolvedOptions):
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayViewWithArguments):
* runtime/JSObject.h:
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorSeal):
(JSC::objectConstructorFreeze):
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties):
* runtime/RegExpConstructor.cpp:
(JSC::regExpCreate):
(JSC::constructRegExp):
* runtime/ScriptExecutable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::ScriptExecutable::prepareForExecutionImpl):
* runtime/ScriptExecutable.h:
* runtime/ThrowScope.cpp:
(JSC::ThrowScope::throwException):
* runtime/ThrowScope.h:
(JSC::ThrowScope::throwException):
(JSC::throwException):
* runtime/VM.cpp:
(JSC::VM::throwException):
* runtime/VM.h:
2019-03-06 Ross Kirsling <ross.kirsling@sony.com>
[Win] Remove -DUCHAR_TYPE=wchar_t stopgap and learn to live with char16_t.
https://bugs.webkit.org/show_bug.cgi?id=195346
Reviewed by Fujii Hironori.
* jsc.cpp:
(currentWorkingDirectory):
(fetchModuleFromLocalFileSystem):
* runtime/DateConversion.cpp:
(JSC::formatDateTime):
Use wchar helpers as needed.
2019-03-06 Mark Lam <mark.lam@apple.com>
Fix incorrect handling of try-finally completion values.
https://bugs.webkit.org/show_bug.cgi?id=195131
<rdar://problem/46222079>
Reviewed by Saam Barati and Yusuke Suzuki.
Consider the following:
function foo() { // line 1
try {
return 42; // line 3
} finally {
for (var j = 0; j < 1; j++) { // line 5
try {
throw ''; // line 7
} finally {
continue; // line 9
}
}
} // line 11
}
var result = foo();
With the current (before fix) code base, result will be the exception object thrown
at line 7. The expected result should be 42, returned at line 3.
The bug is that we were previously only using one set of completion type and
value registers for the entire function. This is inadequate because the outer
try-finally needs to preserve its own completion type and value ({ Return, 42 }
in this case) in order to be able to complete correctly.
One might be deceived into thinking that the above example should complete with
the exception thrown at line 7. However, according to Section 13.15.8 of the
ECMAScript spec, the 'continue' in the finally at line 9 counts as an abrupt
completion. As a result, it overrides the throw from line 7. After the continue,
execution resumes at the top of the loop at line 5, followed by a normal completion
at line 11.
Also according to Section 13.15.8, given that the completion type of the outer
finally is normal, the resultant completion of the outer try-finally should be
the completion of the outer try block i.e. { Return, 42 }.
This patch makes the following changes:
1. Fix handling of finally completion to use a unique set of completion
type and value registers for each FinallyContext.
2. Move the setting of Throw completion type to the out of line exception handler.
This makes the mainline code slightly less branchy.
3. Introduce emitOutOfLineCatchHandler(), emitOutOfLineFinallyHandler(), and
emitOutOfLineExceptionHandler() to make it clearer that these are not emitting
bytecode inline. Also, these make it clearer when we're emitting a handler
for a catch vs a finally.
4. Allocate the FinallyContext on the stack instead of as a member of the
heap allocated ControlFlowScope. This simplifies its life-cycle management
and reduces the amount of needed copying.
5. Update emitFinallyCompletion() to propagate the completion type and value to
the outer FinallyContext when needed.
6. Fix emitJumpIf() to use the right order of operands. Previously, we were
only using it to do op_stricteq and op_nstricteq comparisons. So, the order
wasn't important. We now use it to also do op_beloweq comparisons. Hence,
the order needs to be corrected.
7. Remove the unused CompletionType::Break and Continue. These are encoded with
the jumpIDs of the jump targets instead.
Relevant specifications:
Section 13.15.8: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-try-statement-runtime-semantics-evaluation
Section 6.3.2.4: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-updateempty
* bytecompiler/BytecodeGenerator.cpp:
(JSC::FinallyContext::FinallyContext):
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::pushFinallyControlFlowScope):
(JSC::BytecodeGenerator::popFinallyControlFlowScope):
(JSC::BytecodeGenerator::emitOutOfLineCatchHandler):
(JSC::BytecodeGenerator::emitOutOfLineFinallyHandler):
(JSC::BytecodeGenerator::emitOutOfLineExceptionHandler):
(JSC::BytecodeGenerator::emitEnumeration):
(JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
(JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
(JSC::BytecodeGenerator::emitFinallyCompletion):
(JSC::BytecodeGenerator::emitJumpIf):
(JSC::BytecodeGenerator::emitCatch): Deleted.
(JSC::BytecodeGenerator::allocateCompletionRecordRegisters): Deleted.
(JSC::BytecodeGenerator::releaseCompletionRecordRegisters): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::FinallyContext::completionTypeRegister const):
(JSC::FinallyContext::completionValueRegister const):
(JSC::ControlFlowScope::ControlFlowScope):
(JSC::BytecodeGenerator::emitLoad):
(JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope): Deleted.
(JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope): Deleted.
(JSC::BytecodeGenerator::completionTypeRegister const): Deleted.
(JSC::BytecodeGenerator::completionValueRegister const): Deleted.
(JSC::BytecodeGenerator::emitSetCompletionType): Deleted.
(JSC::BytecodeGenerator::emitSetCompletionValue): Deleted.
* bytecompiler/NodesCodegen.cpp:
(JSC::TryNode::emitBytecode):
2019-03-06 Saam Barati <sbarati@apple.com>
JSScript should keep the cache file locked for the duration of its existence and should truncate the cache when it is out of date
https://bugs.webkit.org/show_bug.cgi?id=195186
Reviewed by Keith Miller.
This patch makes it so that JSScript will keep its bytecode cache file
locked as long as the JSScript is alive. This makes it obvious that it's
safe to update that file, as it will only be used in a single VM, across
all processes, at a single time. We may be able to extend this in the future
if we can atomically update it across VMs/processes. However, we're choosing
more restricted semantics now as it's always easier to extend these semantics
in the future opposed to having to support the more flexible behavior
up front.
This patch also:
- Adds error messages if writing the cache fails. We don't expect this to
fail, but previously we would say we cached it even if write() fails.
- Removes the unused m_moduleKey field.
- Makes calling cacheBytecodeWithError with an already non-empty cache file fail.
In the future, we should extend this to just fill in the parts of the cache
that are not present. But we don't have the ability to do that yet, so we
just result in an error for now.
* API/JSScript.mm:
(-[JSScript dealloc]):
(-[JSScript readCache]):
(-[JSScript init]):
(-[JSScript writeCache:]):
* API/JSScriptInternal.h:
* API/tests/testapi.mm:
(testCacheFileIsExclusive):
(testCacheFileFailsWhenItsAlreadyCached):
(testObjectiveCAPI):
2019-03-06 Christopher Reid <chris.reid@sony.com>
Followups to (r242306): Use LockHolder instead of std::lock_guard on Remote Inspector Locks
https://bugs.webkit.org/show_bug.cgi?id=195381
Reviewed by Mark Lam.
Replacing std::lock_guard uses in Remote Inspector with WTF::LockHolder.
Also using `= { }` for struct initialization instead of memeset.
* inspector/remote/RemoteConnectionToTarget.cpp:
* inspector/remote/RemoteInspector.cpp:
* inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
* inspector/remote/cocoa/RemoteInspectorCocoa.mm:
* inspector/remote/cocoa/RemoteInspectorXPCConnection.mm:
* inspector/remote/glib/RemoteInspectorGlib.cpp:
* inspector/remote/playstation/RemoteInspectorPlayStation.cpp:
* inspector/remote/playstation/RemoteInspectorSocketClientPlayStation.cpp:
* inspector/remote/playstation/RemoteInspectorSocketPlayStation.cpp:
* inspector/remote/playstation/RemoteInspectorSocketServerPlayStation.cpp:
2019-03-06 Saam Barati <sbarati@apple.com>
Air::reportUsedRegisters must padInterference
https://bugs.webkit.org/show_bug.cgi?id=195303
<rdar://problem/48270343>
Reviewed by Keith Miller.
reportUsedRegisters uses reg liveness to eliminate loads/moves into dead
registers. However, liveness can report incorrect results in certain
scenarios when considering liveness at instruction boundaries. For example,
it can go wrong when an Inst has a LateUse of a register and the following
Inst has an EarlyDef of that same register. Such a scenario could lead us
to incorrectly say the register is not live-in to the first Inst. Pad
interference inserts Nops between such instruction boundaries that cause
this issue.
The test with this patch fixes the issue in reportUsedRegisters. This patch
also conservatively makes it so that lowerAfterRegAlloc calls padInterference
since it also reasons about liveness.
* b3/air/AirLowerAfterRegAlloc.cpp:
(JSC::B3::Air::lowerAfterRegAlloc):
* b3/air/AirPadInterference.h:
* b3/air/AirReportUsedRegisters.cpp:
(JSC::B3::Air::reportUsedRegisters):
* b3/testb3.cpp:
(JSC::B3::testReportUsedRegistersLateUseNotDead):
(JSC::B3::run):
2019-03-06 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] AI should not propagate AbstractValue relying on constant folding phase
https://bugs.webkit.org/show_bug.cgi?id=195375
Reviewed by Saam Barati.
MakeRope rule in AI attempts to propagate the node, which will be produced after constant folding phase runs.
This is wrong since we do not guarantee that constant folding phase runs after AI runs (e.g. DFGSpeculativeJIT
and FTLLowerDFGToB3 run AI). This results in the bug that the value produced at runtime is different from the
proven constant value in AI. In the attached test, AI says the value is SpecStringIdent while the resulted value
at runtime is SpecStringVar, resulting in wrong MakeRope code. This patch removes the path propagating the node
relying on constant folding phase.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2019-03-05 Saam barati <sbarati@apple.com>
op_switch_char broken for rope strings after JSRopeString layout rewrite
https://bugs.webkit.org/show_bug.cgi?id=195339
<rdar://problem/48592545>
Reviewed by Yusuke Suzuki.
When we did the JSString rewrite, we accidentally broke LLInt's switch_char
for rope strings. That change made it so that we always go to the slow path
for ropes. That's wrong. The slow path should only be taken when the rope
is of length 1. For lengths other than 1, we need to fall through to the
default case. This patch fixes this.
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/JSString.h:
2019-03-05 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Should check exception for JSString::toExistingAtomicString
https://bugs.webkit.org/show_bug.cgi?id=195337
Reviewed by Keith Miller, Saam Barati, and Mark Lam.
We missed the exception check for JSString::toExistingAtomicString while it can resolve
a rope and throw an OOM exception. This patch adds necessary exception checks. This patch
fixes test failures in debug build, reported in https://bugs.webkit.org/show_bug.cgi?id=194375#c93.
* dfg/DFGOperations.cpp:
* jit/JITOperations.cpp:
(JSC::getByVal):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::getByVal):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
2019-03-04 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, build fix for debug builds after r242397
* runtime/JSString.h:
2019-03-04 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Store bits for JSRopeString in 3 stores
https://bugs.webkit.org/show_bug.cgi?id=195234
Reviewed by Saam Barati.
This patch cleans up the initialization of JSRopeString fields in DFG and FTL.
Previously, we store some part of data separately. Instead, this patch calculates
the data first by bit operations and store calculated data with fewer stores.
This patch also cleans up is8Bit and isSubstring flags. We put them in lower bits
of the first fiber instead of the upper 16 bits. Since we only have 3 bit flags, (isRope, is8Bit, isSubstring),
we can put them into the lower 3 bits, they are always empty due to alignment.
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateImpl): A bit clean up of StringLength IC to give a chance of unnecessary mov removal.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::canBeRope):
(JSC::DFG::SpeculativeJIT::compileGetArrayLength):
(JSC::DFG::SpeculativeJIT::compileMakeRope):
* dfg/DFGSpeculativeJIT.h:
* ftl/FTLAbstractHeapRepository.cpp:
(JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
(JSC::FTL::DFG::LowerDFGToB3::isRopeString):
(JSC::FTL::DFG::LowerDFGToB3::isNotRopeString):
* runtime/JSString.cpp:
(JSC::JSString::visitChildren):
* runtime/JSString.h:
(JSC::JSString::is8Bit const):
(JSC::JSString::isSubstring const):
* tools/JSDollarVM.cpp:
(JSC::functionCreateNullRopeString):
(JSC::JSDollarVM::finishCreation):
2019-03-04 Joseph Pecoraro <pecoraro@apple.com>
ITMLKit Inspector: Data Bindings / Associated Data for nodes
https://bugs.webkit.org/show_bug.cgi?id=195290
<rdar://problem/48304019>
Reviewed by Devin Rousso.
* inspector/protocol/DOM.json:
2019-03-04 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Make Reflect lazily-allocated by dropping @Reflect references from builtin JS
https://bugs.webkit.org/show_bug.cgi?id=195250
Reviewed by Saam Barati.
By removing @Reflect from builtin JS, we can make Reflect object allocation lazy.
We move @ownKeys function from @Reflect to @Object to remove @Reflect reference.
We also remove m_intlObject field from JSGlobalObject since we no longer use it.
* builtins/BuiltinNames.h:
* builtins/GlobalOperations.js:
(globalPrivate.copyDataProperties):
(globalPrivate.copyDataPropertiesNoExclusions):
* runtime/JSGlobalObject.cpp:
(JSC::createReflectProperty):
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructor::finishCreation):
(JSC::objectConstructorOwnKeys):
* runtime/ReflectObject.cpp:
(JSC::ReflectObject::finishCreation):
2019-03-04 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Offer @makeTypeError instead of exposing @TypeError
https://bugs.webkit.org/show_bug.cgi?id=193858
Reviewed by Mark Lam.
Instead of exposing @TypeError, we expose @makeTypeError function.
And we make TypeError and Error lazily-allocated objects in non JIT environment.
In JIT environment, only TypeError becomes lazily-allocated since WebAssembly errors
touch Error prototype anyway. But we can make them lazy in a subsequent patch.
* builtins/AsyncFromSyncIteratorPrototype.js:
* builtins/AsyncGeneratorPrototype.js:
(globalPrivate.asyncGeneratorEnqueue):
* builtins/BuiltinNames.h:
* builtins/PromiseOperations.js:
(globalPrivate.createResolvingFunctions.resolve):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::initializeErrorConstructor):
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::errorPrototype const):
(JSC::JSGlobalObject::errorStructure const):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncMakeTypeError):
* runtime/JSGlobalObjectFunctions.h:
2019-03-04 Carlos Garcia Campos <cgarcia@igalia.com>
[GLib] Returning G_TYPE_OBJECT from a constructor does not work
https://bugs.webkit.org/show_bug.cgi?id=195206
Reviewed by Žan Doberšek.
We are freeing the newly created object before returning from the constructor.
* API/glib/JSCCallbackFunction.cpp:
(JSC::JSCCallbackFunction::construct):
2019-03-02 Darin Adler <darin@apple.com>
Retire legacy dtoa function and DecimalNumber class
https://bugs.webkit.org/show_bug.cgi?id=195253
Reviewed by Daniel Bates.
* runtime/NumberPrototype.cpp:
(JSC::numberProtoFuncToExponential): Removed dependency on NumberToStringBufferLength,
using NumberToStringBuffer instead. Also tweaked style of implementation a bit.
2019-03-01 Darin Adler <darin@apple.com>
Finish removing String::format
https://bugs.webkit.org/show_bug.cgi?id=194893
Reviewed by Daniel Bates.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::nameForRegister): Use makeString instead of String::format,
using the new "pad" function.
2019-03-01 Christopher Reid <chris.reid@sony.com>
[PlayStation] Upstream playstation's remote inspector server
https://bugs.webkit.org/show_bug.cgi?id=193806
Reviewed by Joseph Pecoraro.
Upstreaming PlayStation's Remote Inspector implementation.
It is using a JSON RPC protocol over TCP sockets.
This inspector implementation is planned to also support running on a WinCairo Client and Server.
* PlatformPlayStation.cmake:
* SourcesGTK.txt:
* SourcesWPE.txt:
* inspector/remote/RemoteConnectionToTarget.cpp: Renamed from Source/JavaScriptCore/inspector/remote/glib/RemoteConnectionToTargetGlib.cpp.
* inspector/remote/RemoteInspector.h:
* inspector/remote/playstation/RemoteInspectorConnectionClient.h: Added.
* inspector/remote/playstation/RemoteInspectorConnectionClientPlayStation.cpp: Added.
* inspector/remote/playstation/RemoteInspectorMessageParser.h: Added.
* inspector/remote/playstation/RemoteInspectorMessageParserPlayStation.cpp: Added.
* inspector/remote/playstation/RemoteInspectorPlayStation.cpp: Added.
* inspector/remote/playstation/RemoteInspectorServer.h: Added.
* inspector/remote/playstation/RemoteInspectorServerPlayStation.cpp: Added.
* inspector/remote/playstation/RemoteInspectorSocket.h: Added.
* inspector/remote/playstation/RemoteInspectorSocketClient.h: Added.
* inspector/remote/playstation/RemoteInspectorSocketClientPlayStation.cpp: Added.
* inspector/remote/playstation/RemoteInspectorSocketPlayStation.cpp: Added.
* inspector/remote/playstation/RemoteInspectorSocketServer.h: Added.
* inspector/remote/playstation/RemoteInspectorSocketServerPlayStation.cpp: Added.
2019-03-01 Saam Barati <sbarati@apple.com>
Create SPI to crash if a JSC VM is created
https://bugs.webkit.org/show_bug.cgi?id=195231
<rdar://problem/47717990>
Reviewed by Mark Lam.
* API/JSVirtualMachine.mm:
(+[JSVirtualMachine setCrashOnVMCreation:]):
* API/JSVirtualMachinePrivate.h:
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::setCrashOnVMCreation):
* runtime/VM.h:
2019-03-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Fix FTL build on ARM32_64 by adding stubs for JSRopeString::offsetOfXXX
https://bugs.webkit.org/show_bug.cgi?id=195235
Reviewed by Saam Barati.
This is a workaround until https://bugs.webkit.org/show_bug.cgi?id=195234 is done.
* runtime/JSString.h:
2019-03-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use runtime calls for DFG MakeRope if !CPU(ADDRESS64)
https://bugs.webkit.org/show_bug.cgi?id=195221
Reviewed by Mark Lam.
ARM32_64 builds DFG 64bit, but the size of address is 32bit. Make DFG MakeRope a runtime call not only for DFG 32_64,
but also DFG 64 with !CPU(ADDRESS64). This patch unifies compileMakeRope again, and use a runtime call for !CPU(ADDRESS64).
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileMakeRope):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compileMakeRope): Deleted.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compileMakeRope): Deleted.
2019-03-01 Justin Fan <justin_fan@apple.com>
[Web GPU] 32-bit builds broken by attempt to disable WebGPU on 32-bit
https://bugs.webkit.org/show_bug.cgi?id=195191
Rubber-stamped by Dean Jackson.
Dropping support for 32-bit entirely, so I'm intentionally leaving 32-bit broken.
* Configurations/FeatureDefines.xcconfig:
2019-03-01 Dominik Infuehr <dinfuehr@igalia.com>
Fix debug builds with GCC
https://bugs.webkit.org/show_bug.cgi?id=195205
Unreviewed. Fix debug builds in GCC by removing
the constexpr-keyword for this function.
* runtime/CachedTypes.cpp:
(JSC::tagFromSourceCodeType):
2019-03-01 Dominik Infuehr <dinfuehr@igalia.com>
[ARM] Fix assembler warnings in ctiMasmProbeTrampoline
https://bugs.webkit.org/show_bug.cgi?id=195164
Reviewed by Mark Lam.
Short branches in IT blocks are deprecated in AArch32. In addition the
the conditional branch was the only instruction in the IT block. Short
branches are able to encode the condition code themselves, the additional
IT instruction is not needed.
The assembler was also warning that writing into APSR without a bitmask
was deprecated. Therefore use APSR_nzcvq instead, this generates the same
instruction encoding.
* assembler/MacroAssemblerARMv7.cpp:
2019-02-28 Tadeu Zagallo <tzagallo@apple.com>
Remove CachedPtr::m_isEmpty and CachedOptional::m_isEmpty fields
https://bugs.webkit.org/show_bug.cgi?id=194999
Reviewed by Saam Barati.
These fields are unnecessary, since we can just check that m_offset
has not been initialized (I added VariableLengthObject::isEmpty for
that). They also add 7-byte padding to these classes, which is pretty
bad given how frequently CachedPtr is used.
* runtime/CachedTypes.cpp:
(JSC::CachedObject::operator new[]):
(JSC::VariableLengthObject::allocate):
(JSC::VariableLengthObject::isEmpty const):
(JSC::CachedPtr::encode):
(JSC::CachedPtr::decode const):
(JSC::CachedPtr::get const):
(JSC::CachedOptional::encode):
(JSC::CachedOptional::decode const):
(JSC::CachedOptional::decodeAsPtr const):
2019-02-28 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] sizeof(JSString) should be 16
https://bugs.webkit.org/show_bug.cgi?id=194375
Reviewed by Saam Barati.
This patch reduces sizeof(JSString) from 24 to 16 to fit it into GC heap cell atom. And it also reduces sizeof(JSRopeString) from 48 to 32.
Both classes cut 16 bytes per instance in GC allocation. This new layout is used in 64bit architectures which has little endianess.
JSString no longer has length and flags directly. JSString has String, and we query information to this String instead of holding duplicate
information in JSString. We embed isRope bit into this String's pointer so that we can convert JSRopeString to JSString in an atomic manner.
We emit store-store fence before we put String pointer. This should exist even before this patch, so this patch also fixes one concurrency issue.
The old JSRopeString separately had JSString* fibers along with String. In this patch, we merge the first JSString* fiber and String pointer
storage into one to reduce the size of JSRopeString. JSRopeString has three pointer width storage. We pick 48bit effective address of JSString*
fibers to compress three fibers + length + flags into three pointer width storage.
In 64bit architecture, JSString and JSRopeString have the following memory layout to make sizeof(JSString) == 16 and sizeof(JSRopeString) == 32.
JSString has only one pointer. We use it for String. length() and is8Bit() queries go to StringImpl. In JSRopeString, we reuse the above pointer
place for the 1st fiber. JSRopeString has three fibers so its size is 48. To keep length and is8Bit flag information in JSRopeString, JSRopeString
encodes these information into the fiber pointers. is8Bit flag is encoded in the 1st fiber pointer. length is embedded directly, and two fibers
are compressed into 12bytes. isRope information is encoded in the first fiber's LSB.
Since length of JSRopeString should be frequently accessed compared to each fiber, we put length in contiguous 32byte field, and compress 2nd
and 3rd fibers into the following 80byte fields. One problem is that now 2nd and 3rd fibers are split. Storing and loading 2nd and 3rd fibers
are not one pointer load operation. To make concurrent collector work correctly, we must initialize 2nd and 3rd fibers at JSRopeString creation
and we must not modify these part later.
0 8 10 16 32 48
JSString [ ID ][ header ][ String pointer 0]
JSRopeString [ ID ][ header ][ flags ][ 1st fiber 1][ length ][2nd lower32][2nd upper16][3rd lower16][3rd upper32]
^
isRope bit
Since fibers in JSRopeString are not initialized in atomic pointer store manner, we must initialize all the fiber fields at JSRopeString creation.
To achieve this, we modify our JSRopeString::RopeBuilder implementation not to create half-baked JSRopeString.
This patch also makes an empty JSString singleton per VM. This makes evaluation of JSString in boolean context one pointer comparison. This is
critical in this change since this patch enlarges the code necessary to get length from JSString in JIT. Without this guarantee, our code of boolean
context evaluation is bloated. This patch hides all the JSString::create and JSRopeString::create in the private permission. JSString and JSRopeString
creation is only allowed from jsString and related helper functions and they return a singleton empty JSString if the length is zero. We also change
JSRopeString::RopeBuilder not to construct an empty JSRopeString.
This patch is performance neutral in Speedometer2 and JetStream2. And it improves RAMification by 2.7%.
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::storeZero16):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::storeZero16):
(JSC::MacroAssemblerX86Common::store16):
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateImpl):
* bytecode/InlineAccess.cpp:
(JSC::InlineAccess::dumpCacheSizesAndCrash):
(JSC::linkCodeInline):
(JSC::InlineAccess::isCacheableStringLength):
(JSC::InlineAccess::generateStringLength):
* bytecode/InlineAccess.h:
(JSC::InlineAccess::sizeForPropertyAccess):
(JSC::InlineAccess::sizeForPropertyReplace):
(JSC::InlineAccess::sizeForLengthAccess):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileStringSlice):
(JSC::DFG::SpeculativeJIT::compileToLowerCase):
(JSC::DFG::SpeculativeJIT::compileGetCharCodeAt):
(JSC::DFG::SpeculativeJIT::compileGetByValOnString):
(JSC::DFG::SpeculativeJIT::compileStringEquality):
(JSC::DFG::SpeculativeJIT::compileStringZeroLength):
(JSC::DFG::SpeculativeJIT::compileLogicalNotStringOrOther):
(JSC::DFG::SpeculativeJIT::emitStringBranch):
(JSC::DFG::SpeculativeJIT::emitStringOrOtherBranch):
(JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
(JSC::DFG::SpeculativeJIT::compileGetArrayLength):
(JSC::DFG::SpeculativeJIT::emitPopulateSliceIndex):
(JSC::DFG::SpeculativeJIT::compileArraySlice):
(JSC::DFG::SpeculativeJIT::compileArrayIndexOf):
(JSC::DFG::SpeculativeJIT::speculateStringIdentAndLoadStorage):
(JSC::DFG::SpeculativeJIT::emitSwitchCharStringJump):
(JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):
(JSC::DFG::SpeculativeJIT::compileMakeRope): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::compileMakeRope):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::compileMakeRope):
* ftl/FTLAbstractHeapRepository.cpp:
(JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
(JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
(JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt):
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
(JSC::FTL::DFG::LowerDFGToB3::compileStringToUntypedStrictEquality):
(JSC::FTL::DFG::LowerDFGToB3::compileSwitch):
(JSC::FTL::DFG::LowerDFGToB3::mapHashString):
(JSC::FTL::DFG::LowerDFGToB3::compileMapHash):
(JSC::FTL::DFG::LowerDFGToB3::compileHasOwnProperty):
(JSC::FTL::DFG::LowerDFGToB3::compileStringSlice):
(JSC::FTL::DFG::LowerDFGToB3::compileToLowerCase):
(JSC::FTL::DFG::LowerDFGToB3::stringsEqual):
(JSC::FTL::DFG::LowerDFGToB3::boolify):
(JSC::FTL::DFG::LowerDFGToB3::switchString):
(JSC::FTL::DFG::LowerDFGToB3::isRopeString):
(JSC::FTL::DFG::LowerDFGToB3::isNotRopeString):
(JSC::FTL::DFG::LowerDFGToB3::speculateStringIdent):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitConvertValueToBoolean):
(JSC::AssemblyHelpers::branchIfValue):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::branchIfRopeStringImpl):
(JSC::AssemblyHelpers::branchIfNotRopeStringImpl):
* jit/JITInlines.h:
(JSC::JIT::emitLoadCharacterString):
* jit/Repatch.cpp:
(JSC::tryCacheGetByID):
* jit/ThunkGenerators.cpp:
(JSC::stringGetByValGenerator):
(JSC::stringCharLoad):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/JSString.cpp:
(JSC::JSString::createEmptyString):
(JSC::JSRopeString::RopeBuilder<RecordOverflow>::expand):
(JSC::JSString::dumpToStream):
(JSC::JSString::estimatedSize):
(JSC::JSString::visitChildren):
(JSC::JSRopeString::resolveRopeInternal8 const):
(JSC::JSRopeString::resolveRopeInternal8NoSubstring const):
(JSC::JSRopeString::resolveRopeInternal16 const):
(JSC::JSRopeString::resolveRopeInternal16NoSubstring const):
(JSC::JSRopeString::resolveRopeToAtomicString const):
(JSC::JSRopeString::convertToNonRope const):
(JSC::JSRopeString::resolveRopeToExistingAtomicString const):
(JSC::JSRopeString::resolveRopeWithFunction const):
(JSC::JSRopeString::resolveRope const):
(JSC::JSRopeString::resolveRopeSlowCase8 const):
(JSC::JSRopeString::resolveRopeSlowCase const):
(JSC::JSRopeString::outOfMemory const):
(JSC::JSRopeString::visitFibers): Deleted.
(JSC::JSRopeString::clearFibers const): Deleted.
* runtime/JSString.h:
(JSC::JSString::uninitializedValueInternal const):
(JSC::JSString::valueInternal const):
(JSC::JSString::JSString):
(JSC::JSString::finishCreation):
(JSC::JSString::create):
(JSC::JSString::offsetOfValue):
(JSC::JSString::isRope const):
(JSC::JSString::is8Bit const):
(JSC::JSString::length const):
(JSC::JSString::tryGetValueImpl const):
(JSC::JSString::toAtomicString const):
(JSC::JSString::toExistingAtomicString const):
(JSC::JSString::value const):
(JSC::JSString::tryGetValue const):
(JSC::JSRopeString::unsafeView const):
(JSC::JSRopeString::viewWithUnderlyingString const):
(JSC::JSString::unsafeView const):
(JSC::JSString::viewWithUnderlyingString const):
(JSC::JSString::offsetOfLength): Deleted.
(JSC::JSString::offsetOfFlags): Deleted.
(JSC::JSString::setIs8Bit const): Deleted.
(JSC::JSString::setLength): Deleted.
(JSC::JSString::string): Deleted.
(JSC::jsStringBuilder): Deleted.
* runtime/JSStringInlines.h:
(JSC::JSString::~JSString):
(JSC::JSString::equal const):
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncToString):
* runtime/RegExpMatchesArray.h:
(JSC::createRegExpMatchesArray):
* runtime/RegExpObjectInlines.h:
(JSC::collectMatches):
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoFuncSplitFast):
* runtime/SmallStrings.cpp:
(JSC::SmallStrings::initializeCommonStrings):
(JSC::SmallStrings::createEmptyString): Deleted.
* runtime/SmallStrings.h:
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncSlice):
* runtime/StringPrototypeInlines.h: Added.
(JSC::stringSlice):
2019-02-28 Saam barati <sbarati@apple.com>
Unreviewed. Attempt windows build fix after r242239.
* runtime/CachedTypes.cpp:
(JSC::tagFromSourceCodeType):
2019-02-28 Mark Lam <mark.lam@apple.com>
In cloop.rb, rename :int and :uint to :intptr and :uintptr.
https://bugs.webkit.org/show_bug.cgi?id=195183
Reviewed by Yusuke Suzuki.
Also changed intMemRef and uintMemRef to intptrMemRef and uintptrMemRef respectively.
* offlineasm/cloop.rb:
2019-02-28 Saam barati <sbarati@apple.com>
Make JSScript:cacheBytecodeWithError update the cache when the script changes
https://bugs.webkit.org/show_bug.cgi?id=194912
Reviewed by Mark Lam.
Prior to this patch, the JSScript SPI would never check if its cached
bytecode were still valid. This would lead the cacheBytecodeWithError
succeeding even if the underlying cache were stale. This patch fixes
that by making JSScript check if the cache is still valid. If it's not,
we will cache bytecode when cacheBytecodeWithError is invoked.
* API/JSScript.mm:
(-[JSScript readCache]):
(-[JSScript writeCache:]):
* API/tests/testapi.mm:
(testBytecodeCacheWithSameCacheFileAndDifferentScript):
(testObjectiveCAPI):
* runtime/CachedTypes.cpp:
(JSC::Decoder::Decoder):
(JSC::VariableLengthObject::buffer const):
(JSC::CachedPtr::decode const):
(JSC::tagFromSourceCodeType):
(JSC::GenericCacheEntry::isUpToDate const):
(JSC::CacheEntry::isStillValid const):
(JSC::GenericCacheEntry::decode const):
(JSC::GenericCacheEntry::isStillValid const):
(JSC::encodeCodeBlock):
(JSC::decodeCodeBlockImpl):
(JSC::isCachedBytecodeStillValid):
* runtime/CachedTypes.h:
* runtime/CodeCache.cpp:
(JSC::sourceCodeKeyForSerializedBytecode):
(JSC::sourceCodeKeyForSerializedProgram):
(JSC::sourceCodeKeyForSerializedModule):
(JSC::serializeBytecode):
* runtime/CodeCache.h:
(JSC::CodeCacheMap::fetchFromDiskImpl):
* runtime/Completion.cpp:
(JSC::generateProgramBytecode):
(JSC::generateBytecode): Deleted.
* runtime/Completion.h:
2019-02-28 Mark Lam <mark.lam@apple.com>
cloop.rb shift mask should depend on the word size being shifted.
https://bugs.webkit.org/show_bug.cgi?id=195181
<rdar://problem/48484164>
Reviewed by Yusuke Suzuki.
Previously, we're always masking the shift amount with 0x1f. This is only correct
for 32-bit words. For 64-bit words, the mask should be 0x3f. For pointer sized
shifts, the mask depends on sizeof(uintptr_t).
* offlineasm/cloop.rb:
2019-02-28 Justin Fan <justin_fan@apple.com>
[Web GPU] Enable Web GPU only on 64-bit
https://bugs.webkit.org/show_bug.cgi?id=195139
Because Metal is only supported on 64 bit apps.
Unreviewed build fix.
* Configurations/FeatureDefines.xcconfig:
2019-02-27 Mark Lam <mark.lam@apple.com>
The parser is failing to record the token location of new in new.target.
https://bugs.webkit.org/show_bug.cgi?id=195127
<rdar://problem/39645578>
Reviewed by Yusuke Suzuki.
Also adjust the token location for the following to be as shown:
new.target
^
super
^
import.meta
^
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseMemberExpression):
2019-02-27 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] mustHandleValues for dead bytecode locals should be ignored in DFG phases
https://bugs.webkit.org/show_bug.cgi?id=195144
<rdar://problem/47595961>
Reviewed by Mark Lam.
DFGMaximalFlushInsertionPhase inserts Flush for all the locals at the end of basic blocks. This enlarges the live ranges of
locals in DFG, and it sometimes makes DFG value live while it is dead in bytecode. The issue happens when we use mustHandleValues
to widen AbstractValue in CFAPhase. At that time, DFG tells "this value is live in DFG", but it may be dead in the bytecode level.
At that time, we attempt to merge AbstractValue with dead mustHandleValue, which is cleared as jsUndefined() in
DFG::Plan::cleanMustHandleValuesIfNecessary before start compilation, and crash because jsUndefined() may be irrelevant to the FlushFormat
in VariableAccessData.
This patch makes the type of mustHandleValues Operands<Optional<JSValue>>. We clear dead JSValues in DFG::Plan::cleanMustHandleValuesIfNecessary.
And we skip handling dead mustHandleValue in DFG phases.
* bytecode/Operands.h:
(JSC::Operands::isLocal const):
(JSC::Operands::isVariable const): Deleted.
* dfg/DFGCFAPhase.cpp:
(JSC::DFG::CFAPhase::injectOSR):
* dfg/DFGDriver.cpp:
(JSC::DFG::compileImpl):
(JSC::DFG::compile):
* dfg/DFGDriver.h:
* dfg/DFGJITCode.cpp:
(JSC::DFG::JITCode::reconstruct):
* dfg/DFGJITCode.h:
* dfg/DFGOperations.cpp:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::Plan):
(JSC::DFG::Plan::checkLivenessAndVisitChildren):
(JSC::DFG::Plan::cleanMustHandleValuesIfNecessary):
* dfg/DFGPlan.h:
(JSC::DFG::Plan::mustHandleValues const):
* dfg/DFGPredictionInjectionPhase.cpp:
(JSC::DFG::PredictionInjectionPhase::run):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::disableHoistingAcrossOSREntries):
* ftl/FTLOSREntry.cpp:
(JSC::FTL::prepareOSREntry):
* jit/JITOperations.cpp:
2019-02-27 Simon Fraser <simon.fraser@apple.com>
Roll out r242014; it caused crashes in compositing logging (webkit.org/b/195141)
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::nameForRegister):
2019-02-27 Robin Morisset <rmorisset@apple.com>
DFG: Loop-invariant code motion (LICM) should not hoist dead code
https://bugs.webkit.org/show_bug.cgi?id=194945
<rdar://problem/48311657>
Reviewed by Saam Barati.
* dfg/DFGLICMPhase.cpp:
(JSC::DFG::LICMPhase::run):
2019-02-27 Antoine Quint <graouts@apple.com>
Support Pointer Events on macOS
https://bugs.webkit.org/show_bug.cgi?id=195008
<rdar://problem/47454419>
Reviewed by Dean Jackson.
* Configurations/FeatureDefines.xcconfig:
2019-02-26 Mark Lam <mark.lam@apple.com>
Remove poisons in JSCPoison and uses of them.
https://bugs.webkit.org/show_bug.cgi?id=195082
Reviewed by Yusuke Suzuki.
Also removed unused poisoning code in WriteBarrier, AssemblyHelpers,
DFG::SpeculativeJIT, FTLLowerDFGToB3, and FTL::Output.
* API/JSAPIWrapperObject.h:
(JSC::JSAPIWrapperObject::wrappedObject):
* API/JSCallbackFunction.h:
* API/JSCallbackObject.h:
* API/glib/JSAPIWrapperGlobalObject.h:
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateWithGuard):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
(JSC::DFG::SpeculativeJIT::compileGetArrayLength):
(JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
(JSC::DFG::SpeculativeJIT::compileGetExecutable):
(JSC::DFG::SpeculativeJIT::compileCreateThis):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::TrustedImmPtr::weakPoisonedPointer): Deleted.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetExecutable):
(JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
(JSC::FTL::DFG::LowerDFGToB3::weakPointer):
(JSC::FTL::DFG::LowerDFGToB3::dynamicPoison): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::dynamicPoisonOnLoadedType): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::dynamicPoisonOnType): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::weakPoisonedPointer): Deleted.
* ftl/FTLOutput.h:
(JSC::FTL::Output::weakPoisonedPointer): Deleted.
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitDynamicPoison): Deleted.
(JSC::AssemblyHelpers::emitDynamicPoisonOnLoadedType): Deleted.
(JSC::AssemblyHelpers::emitDynamicPoisonOnType): Deleted.
* jit/AssemblyHelpers.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_create_this):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitScopedArgumentsGetByVal):
* jit/Repatch.cpp:
(JSC::linkPolymorphicCall):
* jit/ThunkGenerators.cpp:
(JSC::virtualThunkFor):
(JSC::nativeForGenerator):
(JSC::boundThisNoArgsFunctionCallGenerator):
* parser/UnlinkedSourceCode.h:
* runtime/ArrayPrototype.h:
* runtime/CustomGetterSetter.h:
(JSC::CustomGetterSetter::getter const):
(JSC::CustomGetterSetter::setter const):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::getCallData):
(JSC::InternalFunction::getConstructData):
* runtime/InternalFunction.h:
(JSC::InternalFunction::nativeFunctionFor):
* runtime/JSArrayBuffer.h:
* runtime/JSBoundFunction.h:
* runtime/JSCPoison.cpp: Removed.
* runtime/JSCPoison.h: Removed.
* runtime/JSFunction.h:
* runtime/JSGlobalObject.h:
* runtime/JSScriptFetchParameters.h:
* runtime/JSScriptFetcher.h:
* runtime/JSString.h:
* runtime/NativeExecutable.cpp:
(JSC::NativeExecutable::hashFor const):
* runtime/NativeExecutable.h:
* runtime/Options.h:
* runtime/ScopedArguments.h:
* runtime/Structure.cpp:
(JSC::StructureTransitionTable::setSingleTransition):
* runtime/StructureTransitionTable.h:
(JSC::StructureTransitionTable::map const):
(JSC::StructureTransitionTable::weakImpl const):
(JSC::StructureTransitionTable::setMap):
* runtime/WriteBarrier.h:
* wasm/WasmB3IRGenerator.cpp:
* wasm/WasmInstance.h:
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::createJSToWasmWrapper):
* wasm/js/JSWebAssemblyCodeBlock.h:
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
(JSC::JSWebAssemblyInstance::visitChildren):
* wasm/js/JSWebAssemblyInstance.h:
* wasm/js/JSWebAssemblyMemory.h:
* wasm/js/JSWebAssemblyModule.h:
* wasm/js/JSWebAssemblyTable.cpp:
(JSC::JSWebAssemblyTable::JSWebAssemblyTable):
(JSC::JSWebAssemblyTable::grow):
(JSC::JSWebAssemblyTable::clearFunction):
* wasm/js/JSWebAssemblyTable.h:
* wasm/js/WasmToJS.cpp:
(JSC::Wasm::materializeImportJSCell):
(JSC::Wasm::handleBadI64Use):
(JSC::Wasm::wasmToJS):
* wasm/js/WebAssemblyFunctionBase.h:
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
(JSC::WebAssemblyModuleRecord::evaluate):
* wasm/js/WebAssemblyModuleRecord.h:
* wasm/js/WebAssemblyToJSCallee.h:
* wasm/js/WebAssemblyWrapperFunction.h:
2019-02-26 Mark Lam <mark.lam@apple.com>
wasmToJS() should purify incoming NaNs.
https://bugs.webkit.org/show_bug.cgi?id=194807
<rdar://problem/48189132>
Reviewed by Saam Barati.
* runtime/JSCJSValue.h:
(JSC::jsNumber):
* runtime/TypedArrayAdaptors.h:
(JSC::IntegralTypedArrayAdaptor::toJSValue):
* wasm/js/WasmToJS.cpp:
(JSC::Wasm::wasmToJS):
2019-02-26 Dominik Infuehr <dinfuehr@igalia.com>
Fix warnings on ARM and MIPS
https://bugs.webkit.org/show_bug.cgi?id=195049
Reviewed by Mark Lam.
Fix all warnings on ARM and MIPS.
* assembler/MacroAssemblerPrinter.cpp:
(JSC::Printer::printMemory):
* assembler/testmasm.cpp:
(JSC::testProbeModifiesStackValues):
* bytecode/InByIdStatus.cpp:
(JSC::InByIdStatus::computeFor):
* runtime/CachedTypes.cpp:
(JSC::VariableLengthObject::buffer const):
* runtime/JSBigInt.h:
* tools/JSDollarVM.cpp:
(JSC::codeBlockFromArg):
2019-02-26 Mark Lam <mark.lam@apple.com>
Misc cleanup in StructureIDTable after r242096.
https://bugs.webkit.org/show_bug.cgi?id=195063
Reviewed by Saam Barati.
* runtime/StructureIDTable.cpp:
(JSC::StructureIDTable::allocateID):
- RELEASE_ASSERT that the StructureID allocation will succeed.
* runtime/StructureIDTable.h:
(JSC::StructureIDTable::decode):
(JSC::StructureIDTable::encode):
- Add back a comment that Yusuke requested but was lost when the patch was rolled
out and relanded.
- Applied bitwise_casts that Saam requested.
2019-02-26 Mark Lam <mark.lam@apple.com>
Gardening: 32-bit build fix after r242096.
https://bugs.webkit.org/show_bug.cgi?id=194989
Not reviewed.
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitLoadStructure):
2019-02-26 Mark Lam <mark.lam@apple.com>
Unpoison MacroAssemblerCodePtr, ClassInfo pointers, and a few other things.
https://bugs.webkit.org/show_bug.cgi?id=195039
Reviewed by Saam Barati.
1. Unpoison MacroAssemblerCodePtrs, ReturnAddressPtr.
2. Replace PoisonedClassInfoPtr with ClassInfo*.
3. Replace PoisonedMasmPtr with const void*.
4. Remove all references to CodeBlockPoison, JITCodePoison, and GlobalDataPoison.
* API/JSCallbackObject.h:
* API/JSObjectRef.cpp:
(classInfoPrivate):
* assembler/MacroAssemblerCodeRef.h:
(JSC::FunctionPtr::FunctionPtr):
(JSC::FunctionPtr::executableAddress const):
(JSC::FunctionPtr::retaggedExecutableAddress const):
(JSC::ReturnAddressPtr::ReturnAddressPtr):
(JSC::ReturnAddressPtr::value const):
(JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr):
(JSC::MacroAssemblerCodePtr::createFromExecutableAddress):
(JSC::MacroAssemblerCodePtr:: const):
(JSC::MacroAssemblerCodePtr::operator! const):
(JSC::MacroAssemblerCodePtr::operator== const):
(JSC::MacroAssemblerCodePtr::hash const):
(JSC::MacroAssemblerCodePtr::emptyValue):
(JSC::MacroAssemblerCodePtr::deletedValue):
(JSC::FunctionPtr<tag>::FunctionPtr):
(JSC::MacroAssemblerCodePtr::poisonedPtr const): Deleted.
* b3/B3LowerMacros.cpp:
* b3/testb3.cpp:
(JSC::B3::testInterpreter):
* dfg/DFGOSRExitCompilerCommon.h:
(JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCheckSubClass):
(JSC::DFG::SpeculativeJIT::compileNewStringObject):
(JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
(JSC::DFG::SpeculativeJIT::emitSwitchImm):
(JSC::DFG::SpeculativeJIT::emitSwitchCharStringJump):
(JSC::DFG::SpeculativeJIT::emitSwitchChar):
* dfg/DFGSpeculativeJIT.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNewStringObject):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitAllocateDestructibleObject):
* jit/ThunkGenerators.cpp:
(JSC::virtualThunkFor):
(JSC::boundThisNoArgsFunctionCallGenerator):
* runtime/JSCPoison.h:
* runtime/JSDestructibleObject.h:
(JSC::JSDestructibleObject::classInfo const):
* runtime/JSSegmentedVariableObject.h:
(JSC::JSSegmentedVariableObject::classInfo const):
* runtime/Structure.h:
* runtime/VM.h:
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addCall):
(JSC::Wasm::B3IRGenerator::addCallIndirect):
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToWasm):
2019-02-26 Mark Lam <mark.lam@apple.com>
[Re-landing] Add some randomness into the StructureID.
https://bugs.webkit.org/show_bug.cgi?id=194989
<rdar://problem/47975563>
Reviewed by Yusuke Suzuki.
1. On 64-bit, the StructureID will now be encoded as:
----------------------------------------------------------------
| 1 Nuke Bit | 24 StructureIDTable index bits | 7 entropy bits |
----------------------------------------------------------------
The entropy bits are chosen at random and assigned when a StructureID is
allocated.
2. Instead of Structure pointers, the StructureIDTable will now contain
encodedStructureBits, which is encoded as such:
----------------------------------------------------------------
| 7 entropy bits | 57 structure pointer bits |
----------------------------------------------------------------
The entropy bits here are the same 7 bits used in the encoding of the
StructureID for this structure entry in the StructureIDTable.
3. Retrieval of the structure pointer given a StructureID is now computed as
follows:
index = structureID >> 7; // with arithmetic shift.
encodedStructureBits = structureIDTable[index];
structure = encodedStructureBits ^ (structureID << 57);
We use an arithmetic shift for the right shift because that will preserve
the nuke bit in the high bit of the index if the StructureID was not
decontaminated before use as expected.
4. Remove unused function loadArgumentWithSpecificClass() in SpecializedThunkJIT.
5. Define StructureIDTable::m_size to be the number of allocated StructureIDs
instead of always being the same as m_capacity.
6. Change StructureIDTable::s_unusedID's value to 0.
Its previous value of unusedPointer i.e. 0xd1e7beef, does not make sense for
StructureID on 64-bit. Also, there was never any code that initializes unused
IDs to the s_unusedID. The only meaningful value for s_unusedID is 0, which
is the ID we'll get when the freelist is empty, prompting a resize of the
structureIDTable.
This patch appears to be perf neutral on JetStream 2 run via the cli on a
11" MacBook Air, 13" MacBook Pro, iPhone 6S, and iPhone XR.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::loadStructure):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::appendJSCellOrAuxiliary):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitLoadStructure):
* jit/AssemblyHelpers.h:
* jit/SpecializedThunkJIT.h:
(JSC::SpecializedThunkJIT::loadArgumentWithSpecificClass): Deleted.
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/StructureIDTable.cpp:
(JSC::StructureIDTable::StructureIDTable):
(JSC::StructureIDTable::makeFreeListFromRange):
(JSC::StructureIDTable::resize):
(JSC::StructureIDTable::allocateID):
(JSC::StructureIDTable::deallocateID):
* runtime/StructureIDTable.h:
(JSC::StructureIDTable::decode):
(JSC::StructureIDTable::encode):
(JSC::StructureIDTable::get):
(JSC::StructureIDTable::isValid):
2019-02-26 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r242071.
Breaks internal builds.
Reverted changeset:
"Add some randomness into the StructureID."
https://bugs.webkit.org/show_bug.cgi?id=194989
https://trac.webkit.org/changeset/242071
2019-02-26 Guillaume Emont <guijemont@igalia.com>
[JSC] Fix compilation on 32-bit platforms after r242071
https://bugs.webkit.org/show_bug.cgi?id=195042
Reviewed by Carlos Garcia Campos.
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitLoadStructure):
2019-02-26 Guillaume Emont <guijemont@igalia.com>
[JSC] Repeat string created from Array.prototype.join() take too much memory
https://bugs.webkit.org/show_bug.cgi?id=193912
Reviewed by Saam Barati.
Added a fast case in Array.prototype.join when the array is
uninitialized.
* runtime/ArrayPrototype.cpp:
(JSC::canUseFastJoin):
(JSC::fastJoin):
* runtime/JSStringInlines.h:
(JSC::repeatCharacter): moved from StringPrototype.cpp
* runtime/StringPrototype.cpp:
2019-02-25 Mark Lam <mark.lam@apple.com>
Add some randomness into the StructureID.
https://bugs.webkit.org/show_bug.cgi?id=194989
<rdar://problem/47975563>
Reviewed by Yusuke Suzuki.
1. On 64-bit, the StructureID will now be encoded as:
----------------------------------------------------------------
| 1 Nuke Bit | 24 StructureIDTable index bits | 7 entropy bits |
----------------------------------------------------------------
The entropy bits are chosen at random and assigned when a StructureID is
allocated.
2. Instead of Structure pointers, the StructureIDTable will now contain
encodedStructureBits, which is encoded as such:
----------------------------------------------------------------
| 7 entropy bits | 57 structure pointer bits |
----------------------------------------------------------------
The entropy bits here are the same 7 bits used in the encoding of the
StructureID for this structure entry in the StructureIDTable.
3. Retrieval of the structure pointer given a StructureID is now computed as
follows:
index = structureID >> 7; // with arithmetic shift.
encodedStructureBits = structureIDTable[index];
structure = encodedStructureBits ^ (structureID << 57);
We use an arithmetic shift for the right shift because that will preserve
the nuke bit in the high bit of the index if the StructureID was not
decontaminated before use as expected.
4. Remove unused function loadArgumentWithSpecificClass() in SpecializedThunkJIT.
5. Define StructureIDTable::m_size to be the number of allocated StructureIDs
instead of always being the same as m_capacity.
6. Change StructureIDTable::s_unusedID's value to 0.
Its previous value of unusedPointer i.e. 0xd1e7beef, does not make sense for
StructureID on 64-bit. Also, there was never any code that initializes unused
IDs to the s_unusedID. The only meaningful value for s_unusedID is 0, which
is the ID we'll get when the freelist is empty, prompting a resize of the
structureIDTable.
This patch appears to be perf neutral on JetStream 2 run via the cli on a
11" MacBook Air, 13" MacBook Pro, iPhone 6S, and iPhone XR.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::loadStructure):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::appendJSCellOrAuxiliary):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitLoadStructure):
* jit/AssemblyHelpers.h:
* jit/SpecializedThunkJIT.h:
(JSC::SpecializedThunkJIT::loadArgumentWithSpecificClass): Deleted.
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/StructureIDTable.cpp:
(JSC::StructureIDTable::StructureIDTable):
(JSC::StructureIDTable::makeFreeListFromRange):
(JSC::StructureIDTable::resize):
(JSC::StructureIDTable::allocateID):
(JSC::StructureIDTable::deallocateID):
* runtime/StructureIDTable.h:
(JSC::StructureIDTable::decode):
(JSC::StructureIDTable::encode):
(JSC::StructureIDTable::get):
(JSC::StructureIDTable::isValid):
2019-02-25 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Revert r226885 to make SlotVisitor creation lazy
https://bugs.webkit.org/show_bug.cgi?id=195013
Reviewed by Saam Barati.
We once changed SlotVisitor creation apriori to drop the lock. Also, it turns out that SlotVisitor is memory-consuming.
We should defer SlotVisitor creation until it is actually required. This patch reverts r226885. Even with this patch,
we still hold many SlotVisitors after we execute many parallel markers at least once. But recovering the feature of
dynamically allocating SlotVisitors helps further memory optimizations in this area.
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::runBeginPhase):
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::forEachSlotVisitor):
(JSC::Heap::numberOfSlotVisitors):
* heap/MarkingConstraintSolver.cpp:
(JSC::MarkingConstraintSolver::didVisitSomething const):
* heap/SlotVisitor.h:
2019-02-25 Saam Barati <sbarati@apple.com>
testb3 and testair should test O0/O1/O2
https://bugs.webkit.org/show_bug.cgi?id=194637
Reviewed by Mark Lam.
This patch makes it so that we run all tests in testair and testb3
in O0, O1, and O2. However, some tests are invalid for O0 and O1.
This patch makes it so we only run those tests in O2. These are
often tests that assert certain optimizations have occurred. There
are also a class of tests that rely on using patchpoints to stress
the register allocator into only a single valid allocation. The
O0, and sometimes O1, register allocators are not always good enough
to allocate such programs. To make these valid allocators to use, we rely
on the FTL and Wasm to not emit such patchpoints.
* b3/air/testair.cpp:
(main):
* b3/testb3.cpp:
(JSC::B3::compileProc):
(JSC::B3::testAddLoadTwice):
(JSC::B3::testMulLoadTwice):
(JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs):
(JSC::B3::testSimplePatchpointWithOuputClobbersFPArgs):
(JSC::B3::testPatchpointWithEarlyClobber):
(JSC::B3::testSimpleCheck):
(JSC::B3::testCheckFalse):
(JSC::B3::testCheckTrue):
(JSC::B3::testCheckLessThan):
(JSC::B3::testCheckMegaCombo):
(JSC::B3::testCheckTrickyMegaCombo):
(JSC::B3::testCheckTwoMegaCombos):
(JSC::B3::testCheckTwoNonRedundantMegaCombos):
(JSC::B3::testCheckAddImm):
(JSC::B3::testCheckAddImmCommute):
(JSC::B3::testCheckAddImmSomeRegister):
(JSC::B3::testCheckAdd):
(JSC::B3::testCheckAdd64):
(JSC::B3::testCheckAddFold):
(JSC::B3::testCheckAddFoldFail):
(JSC::B3::testCheckAddSelfOverflow64):
(JSC::B3::testCheckAddSelfOverflow32):
(JSC::B3::testCheckSubImm):
(JSC::B3::testCheckSubBadImm):
(JSC::B3::testCheckSub):
(JSC::B3::testCheckSub64):
(JSC::B3::testCheckSubFold):
(JSC::B3::testCheckSubFoldFail):
(JSC::B3::testCheckNeg):
(JSC::B3::testCheckNeg64):
(JSC::B3::testCheckMul):
(JSC::B3::testCheckMulMemory):
(JSC::B3::testCheckMul2):
(JSC::B3::testCheckMul64):
(JSC::B3::testCheckMulFold):
(JSC::B3::testCheckMulFoldFail):
(JSC::B3::testCheckMul64SShr):
(JSC::B3::testLinearScanWithCalleeOnStack):
(JSC::B3::testCheckSelect):
(JSC::B3::testCheckSelectCheckSelect):
(JSC::B3::testCheckSelectAndCSE):
(JSC::B3::testLateRegister):
(JSC::B3::testReduceStrengthCheckBottomUseInAnotherBlock):
(JSC::B3::testSomeEarlyRegister):
(JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2):
(JSC::B3::testPinRegisters):
(JSC::B3::testX86LeaAddAddShlLeft):
(JSC::B3::testX86LeaAddAddShlRight):
(JSC::B3::testX86LeaAddAdd):
(JSC::B3::testX86LeaAddShlRight):
(JSC::B3::testX86LeaAddShlLeftScale1):
(JSC::B3::testX86LeaAddShlLeftScale2):
(JSC::B3::testX86LeaAddShlLeftScale4):
(JSC::B3::testX86LeaAddShlLeftScale8):
(JSC::B3::testLoadBaseIndexShift2):
(JSC::B3::testOptimizeMaterialization):
(JSC::B3::testLICMPure):
(JSC::B3::testLICMPureSideExits):
(JSC::B3::testLICMPureWritesPinned):
(JSC::B3::testLICMPureWrites):
(JSC::B3::testLICMReadsPinned):
(JSC::B3::testLICMReads):
(JSC::B3::testLICMPureNotBackwardsDominant):
(JSC::B3::testLICMPureNotBackwardsDominantFoiledByChild):
(JSC::B3::testLICMControlDependent):
(JSC::B3::testLICMControlDependentNotBackwardsDominant):
(JSC::B3::testLICMReadsWritesDifferentHeaps):
(JSC::B3::testWasmBoundsCheck):
(JSC::B3::run):
(main):
2019-02-25 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] stress/function-constructor-reading-from-global-lexical-environment.js fails in 32bit arch
https://bugs.webkit.org/show_bug.cgi?id=195030
<rdar://problem/48385088>
Reviewed by Saam Barati.
While LLInt64 has checkTDZInGlobalPutToScopeIfNecessary for op_put_to_scope GlobalLexicalVar to check the value in the variable slot is not empty,
this check is missing in LLInt32_64. Previously, this check was subsumed accidentally by the WatchpointSet check in GlobalLexicalVar in `notifyWrite`:
because no "put" attempt succeeds here, the status WatchpointSet was ClearWatchpoint, we always go to the slow path, and we always throw the TDZ error
before configuring the WatchpointSet in the slow path. But after r241862, WatchpointSet is not used under non-JIT configuration. This skips WatchpointSet
check and LLInt32_64 starts failing tests because of lack of checkTDZInGlobalPutToScopeIfNecessary. This patch adds checkTDZInGlobalPutToScopeIfNecessary
in LLInt32_64 too. This patch fixes the following four failing tests.
stress/function-constructor-reading-from-global-lexical-environment.js.bytecode-cache
stress/function-constructor-reading-from-global-lexical-environment.js.default
stress/global-lexical-variable-tdz.js.bytecode-cache
stress/global-lexical-variable-tdz.js.default
* llint/LowLevelInterpreter32_64.asm:
2019-02-25 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Make Intl fields lazily-allocated
https://bugs.webkit.org/show_bug.cgi?id=195022
Reviewed by Mark Lam.
This patch makes the following memory footprint optimization in IntlObject.
1. Make IntlObject fields including Intl.Collator lazily-allocated because we already removed direct references from JS builtins to these constructors (@Collator etc.).
2. Move LazyProperty<IntlObject, Structure> structures from IntlObject to JSGlobalObject. This makes sizeof(IntlObject) the same to the other ones of usual runtime Objects,
and drop one MarkedBlock.
* runtime/IntlCollatorConstructor.h:
* runtime/IntlDateTimeFormatConstructor.h:
* runtime/IntlNumberFormatConstructor.h:
* runtime/IntlObject.cpp:
(JSC::createCollatorConstructor):
(JSC::createNumberFormatConstructor):
(JSC::createDateTimeFormatConstructor):
(JSC::createPluralRulesConstructor):
(JSC::IntlObject::finishCreation):
(JSC::IntlObject::visitChildren): Deleted.
* runtime/IntlObject.h:
* runtime/IntlPluralRulesConstructor.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
(JSC::JSGlobalObject::defaultCollator):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::collatorStructure):
(JSC::JSGlobalObject::numberFormatStructure):
(JSC::JSGlobalObject::dateTimeFormatStructure):
(JSC::JSGlobalObject::pluralRulesStructure):
(JSC::JSGlobalObject::intlObject const): Deleted.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncDateTimeFormat):
* runtime/NumberPrototype.cpp:
(JSC::numberProtoFuncToLocaleString):
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncLocaleCompare):
2019-02-25 Tadeu Zagallo <tzagallo@apple.com>
Avoid hashing CompactVariableEnvironment when decoding CompactVariableMap::Handle
https://bugs.webkit.org/show_bug.cgi?id=194937
Reviewed by Saam Barati.
Hashing the CompactVariableEnvironment is expensive and we could avoid it
when decoding multiple handles to the same environment. This is sound because
a pointer to the same CompactVariableEnvironment will hash the same.
* runtime/CachedTypes.cpp:
(JSC::Decoder::handleForEnvironment const):
(JSC::Decoder::setHandleForEnvironment):
(JSC::CachedCompactVariableMapHandle::decode const):
2019-02-25 Tadeu Zagallo <tzagallo@apple.com>
Remove unnecessary WTF:: prefixes in CachedTypes
https://bugs.webkit.org/show_bug.cgi?id=194936
Reviewed by Saam Barati.
Cleanup unnecessary prefixes from Optional, roundUpToMultipleOf and
pageSize.
* runtime/CachedTypes.cpp:
(JSC::Encoder::cachedOffsetForPtr):
(JSC::Encoder::Page::malloc):
(JSC::Encoder::allocateNewPage):
(JSC::CachedPtr::encode):
(JSC::CachedPtr::decode const):
(JSC::CachedOptional::encode):
(JSC::CachedOptional::decode const):
2019-02-25 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Drop direct references to Intl constructors by rewriting Intl JS builtins in C++
https://bugs.webkit.org/show_bug.cgi?id=194976
Reviewed by Michael Saboff.
This patch paves the way to making IntlObject allocation lazy by removing direct references
to Intl constructors (Intl.Collator etc.) from builtin JS. To achieve that,
1. We implement String.prototype.toLocaleCompare and Number.prototype.toLocaleString in C++
instead of JS builtins. Since these functions end up calling ICU C++ runtime, writing them in
JS does not offer performance improvement.
2. We remove @DateTimeFormat constructor reference, and instead, exposing @dateTimeFormat function,
which returns formatted string directly. We still have JS builtins for DateTimeFormat things
because the initialization of its "options" JSObject involves many get_by_id / put_by_id things,
which are efficient in JS. But we avoid exposing @DateTimeFormat directly, so that Intl constructors
can be lazily allocated.
* CMakeLists.txt:
* DerivedSources-input.xcfilelist:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/BuiltinNames.h:
* builtins/DatePrototype.js:
(toLocaleString):
(toLocaleDateString):
(toLocaleTimeString):
* builtins/NumberPrototype.js: Removed.
* builtins/StringPrototype.js:
(intrinsic.StringPrototypeReplaceIntrinsic.replace):
(globalPrivate.getDefaultCollator): Deleted.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
(JSC::JSGlobalObject::defaultCollator):
* runtime/JSGlobalObject.h:
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncDateTimeFormat):
* runtime/JSGlobalObjectFunctions.h:
* runtime/NumberPrototype.cpp:
(JSC::NumberPrototype::finishCreation):
(JSC::throwVMToThisNumberError):
(JSC::numberProtoFuncToExponential):
(JSC::numberProtoFuncToFixed):
(JSC::numberProtoFuncToPrecision):
(JSC::numberProtoFuncToString):
(JSC::numberProtoFuncToLocaleString):
(JSC::numberProtoFuncValueOf):
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
(JSC::stringProtoFuncLocaleCompare):
2019-02-24 Devin Rousso <drousso@apple.com>
Web Inspector: Change the InspectorOverlay to use native rather than canvas
https://bugs.webkit.org/show_bug.cgi?id=105023
<rdar://problem/13443692>
Reviewed by Brian Burg.
* inspector/protocol/OverlayTypes.json: Removed.
Now that the overlay is entirely generated in C++, we no longer need the special prototol
types for transferring data to a JavaScript context.
* inspector/protocol/Debugger.json:
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::setOverlayMessage): Deleted.
Remove `Debugger.setOverlayMessage` command as it hasn't been used and is no longer supported.
* CMakeLists.txt:
* DerivedSources-input.xcfilelist:
* DerivedSources.make:
2019-02-24 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Lazily create sentinel Map and Set buckets
https://bugs.webkit.org/show_bug.cgi?id=194975
Reviewed by Saam Barati.
If VM::canUseJIT() returns false, we can lazily initialize sentinel Map and Set buckets.
This patch adds getters to VM which lazily allocate these buckets. We eagerly initialize
them if VM::canUseJIT() returns true since they can be touched from DFG and FTL.
* bytecode/BytecodeIntrinsicRegistry.cpp:
(JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
(JSC::BytecodeIntrinsicRegistry::sentinelMapBucketValue):
(JSC::BytecodeIntrinsicRegistry::sentinelSetBucketValue):
* bytecode/BytecodeIntrinsicRegistry.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGOperations.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetMapBucketNext):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket):
(JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucketNext):
* runtime/MapConstructor.cpp:
(JSC::mapPrivateFuncMapBucketNext):
* runtime/SetConstructor.cpp:
(JSC::setPrivateFuncSetBucketNext):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::sentinelSetBucketSlow):
(JSC::VM::sentinelMapBucketSlow):
* runtime/VM.h:
(JSC::VM::sentinelSetBucket):
(JSC::VM::sentinelMapBucket):
2019-02-20 Darin Adler <darin@apple.com>
Finish removing String::format
https://bugs.webkit.org/show_bug.cgi?id=194893
Reviewed by Daniel Bates.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::nameForRegister): Use makeString instead of String::format,
using the new "pad" function.
2019-02-23 Robin Morisset <rmorisset@apple.com>
Remove dead code: AdjacencyList::justOneChild()
https://bugs.webkit.org/show_bug.cgi?id=194965
Reviewed by Sam Weinig.
* dfg/DFGAdjacencyList.h:
(JSC::DFG::AdjacencyList::justOneChild const): Deleted.
2019-02-23 Michael Catanzaro <mcatanzaro@igalia.com>
Unreviewed, fix -Wunused-param warning
* jsc.cpp:
2019-02-23 Mark Lam <mark.lam@apple.com>
Add an exception check and some assertions in StringPrototype.cpp.
https://bugs.webkit.org/show_bug.cgi?id=194962
<rdar://problem/48013416>
Reviewed by Yusuke Suzuki and Saam Barati.
* runtime/StringPrototype.cpp:
(JSC::jsSpliceSubstrings):
(JSC::jsSpliceSubstringsWithSeparators):
(JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
2019-02-23 Keith Miller <keith_miller@apple.com>
Add new mac target numbers
https://bugs.webkit.org/show_bug.cgi?id=194955
Reviewed by Tim Horton.
* Configurations/Base.xcconfig:
* Configurations/DebugRelease.xcconfig:
2019-02-22 Robin Morisset <rmorisset@apple.com>
DFGBytecodeParser should not declare that a node won't clobberExit if DFGFixupPhase can later declare it does clobberExit
https://bugs.webkit.org/show_bug.cgi?id=194953
<rdar://problem/47595253>
Reviewed by Saam Barati.
For each node that
(a) may or may not clobberExit depending on their arrayMode
(b) and get their arrayMode from profiling information in DFGBytecodeParser
(c) and can have their arrayMode refined by DFGFixupPhase,
We must make sure to be conservative in the DFGBytecodeParser and treat it as if it unconditionnally clobbered the exit.
Otherwise we will hit a validation failure after fixup if the next node was marked ExitValid and exits to the same semantic origin.
The list of nodes that fit (a) is:
- StringCharAt
- HasIndexProperty
- GetByVal
- PutByValDirect
- PutByVal
- PutByValAlias
- GetIndexedPropertyStorage
Out of these, the following also fit (b) and (c):
- HasIndexedProperty
- GetByVal
- PutByValDirect
- PutByVal
GetByVal already had "m_exitOK = false; // GetByVal must be treated as if it clobbers exit state, since FixupPhase may make it generic."
So we just have to fix the other three the same way.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::handlePutByVal):
2019-02-22 Robin Morisset <rmorisset@apple.com>
B3ReduceStrength: missing peephole optimizations for binary operations
https://bugs.webkit.org/show_bug.cgi?id=194252
Reviewed by Saam Barati.
Adds several sets of optimizations for BitAnd, BitOr and BitXor.
Using BitAnd distributivity over BitOr and BitXor:
Turn any of these (for Op == BitOr || Op == BitXor):
Op(BitAnd(x1, x2), BitAnd(x1, x3))
Op(BitAnd(x2, x1), BitAnd(x1, x3))
Op(BitAnd(x1, x2), BitAnd(x3, x1))
Op(BitAnd(x2, x1), BitAnd(x3, x1))
Into this: BitAnd(Op(x2, x3), x1)
And any of these:
Op(BitAnd(x1, x2), x1)
Op(BitAnd(x2, x1), x1)
Op(x1, BitAnd(x1, x2))
Op(x1, BitAnd(x2, x1))
Into this: BitAnd(Op(x2, x1), x1)
This second set is equivalent to doing x1 => BitAnd(x1, x1), and then applying the first set.
Using de Morgan laws (we represent not as BitXor with allOnes):
BitAnd(BitXor(x1, allOnes), BitXor(x2, allOnes)) => BitXor(BitOr(x1, x2), allOnes)
BitOr(BitXor(x1, allOnes), BitXor(x2, allOnes) => BitXor(BitAnd(x1, x2), allOnes)
BitOr(BitXor(x, allOnes), c) => BitXor(BitAnd(x, ~c), allOnes)
BitAnd(BitXor(x, allOnes), c) => BitXor(BitOr(x, ~c), allOnes)
The latter two are equivalent to doing c => BitXor(~c, allOnes), and then applying the former two.
All of these transformations either reduce the number of operations (which we always do when possible), or bring the expression closer to having:
- BitXor with all ones at the outermost
- then BitAnd
- then other BitXor
- then BitOr at the innermost.
These transformations that don't directly reduce the number of operations are still useful for normalization (helping things like CSE), and also can enable
more optimizations (for example BitXor with all ones can easily cancel each other once they are all at the outermost level).
* b3/B3ReduceStrength.cpp:
* b3/testb3.cpp:
(JSC::B3::testBitAndNotNot):
(JSC::B3::testBitAndNotImm):
(JSC::B3::testBitOrAndAndArgs):
(JSC::B3::testBitOrAndSameArgs):
(JSC::B3::testBitOrNotNot):
(JSC::B3::testBitOrNotImm):
(JSC::B3::testBitXorAndAndArgs):
(JSC::B3::testBitXorAndSameArgs):
(JSC::B3::run):
2019-02-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] putNonEnumerable in JSWrapperMap is too costly
https://bugs.webkit.org/show_bug.cgi?id=194935
Reviewed by Mark Lam.
When we convert Objective-C blocks to JS objects, we need to set up a corresponding function object correctly.
During this allocation, we call [JSValue defineProperty:descriptor] to connect a "prototype" object and "constructor" object.
The problem is that this API has a particularly costly implementation:
[[_context globalObject][@"Object"] invokeMethod:@"defineProperty" withArguments:@[ self, key, descriptor ]];
This wraps each JS objects appear in this code with Objective-C wrapper. And we convert a NSDictionary to JSObject, which
has "writable", "enumerable", "configurable", "value" fields, and call the "defineProperty" JS function through Objective-C wrapper.
This allocates many Objective-C wrappers and JS objects for descriptors. Since JSC has a direct C++ API "defineOwnProperty", we should
bypass these Objective-C APIs and call JSC's code directly.
This patch changes `putNonEnumerable` implementation, from calling [JSValue defineProperty:descriptor] to calling JSC C++ code directly.
We do not change [JSValue defineProperty:descriptor] implementation for now because of two reasons. (1) This is not used in our benchmarks
except for this (converting an Objective-C block to a JS object) one path. And (2) even if we were to re-write [JSValue defineProperty:descriptor]
to be more optimized, we would still want to call the JSC C++ version of defineProperty directly here to avoid NSDictionary allocation for a descriptor.
* API/APIUtils.h:
(setException):
* API/JSWrapperMap.mm:
(putNonEnumerable):
(copyMethodsToObject):
(-[JSObjCClassInfo allocateConstructorAndPrototypeInContext:]):
(-[JSObjCClassInfo wrapperForObject:inContext:]):
2019-02-22 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, build fix after r241954
https://bugs.webkit.org/show_bug.cgi?id=194939
Renaming setCanAccessHeap was incomplete.
* runtime/SmallStrings.cpp:
(JSC::SmallStrings::initializeCommonStrings):
* runtime/VM.cpp:
(JSC::VM::~VM):
2019-02-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] SmallStringsStorage is unnecessary
https://bugs.webkit.org/show_bug.cgi?id=194939
Reviewed by Mark Lam.
SmallStrings hold common small JSStrings. Their underlying StringImpl is also held by SmallStringsStorage.
But it is duplicate since we can get StringImpl from small JSStrings. This patch removes SmallStringsStorage,
and get StringImpls from JSStrings if necessary.
We also add m_canAccessHeap flag to SmallStrings. At the time of VM destruction, JSStrings are destroyed when
VM's Heap is finalized. We must not touch JSStrings before VM's heap (and JSStrings in SmallStrings) is initialized,
and after VM's Heap is destroyed. We add this m_canAccessHeap flag to allow users to get StringImpl during the
this sensitive period. If m_canAccessHeap is false, we get StringImpl from AtomicStringImpl::add.
* runtime/SmallStrings.cpp:
(JSC::SmallStrings::initializeCommonStrings):
(JSC::SmallStrings::singleCharacterStringRep):
(JSC::SmallStringsStorage::rep): Deleted.
(JSC::SmallStringsStorage::SmallStringsStorage): Deleted.
(JSC::SmallStrings::createSingleCharacterString): Deleted.
* runtime/SmallStrings.h:
(JSC::SmallStrings::setCanAccessHeap):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::~VM):
2019-02-22 Tadeu Zagallo <tzagallo@apple.com>
Cache CompactVariableMap::Handle instead of VariableEnvironment for UnlinkedFunctionExecutable
https://bugs.webkit.org/show_bug.cgi?id=194706
Reviewed by Saam Barati.
In https://bugs.webkit.org/show_bug.cgi?id=194583 we started using a
CompactVariableMap::Handle instead of VariableEnvironment for
UnlinkedFunctionExecutables, but we were creating the full environment
to encode the executable in the bytecode cache. This patch changes it so
that we cache the handle instead of the environment. This avoids duplicating
the VariableEnvironment whenever we have to cache two handles that point
to the environment.
* bytecode/UnlinkedFunctionExecutable.h:
* parser/VariableEnvironment.cpp:
(JSC::CompactVariableMap::get):
* parser/VariableEnvironment.h:
* runtime/CachedTypes.cpp:
(JSC::CachedCompactVariableEnvironment::encode):
(JSC::CachedCompactVariableEnvironment::decode const):
(JSC::CachedCompactVariableMapHandle::encode):
(JSC::CachedCompactVariableMapHandle::decode const):
(JSC::CachedFunctionExecutable::encode):
(JSC::CachedFunctionExecutable::decode const):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
2019-02-21 Saam Barati <sbarati@apple.com>
Update JSScript SPI based on feedback
https://bugs.webkit.org/show_bug.cgi?id=194517
Reviewed by Keith Miller.
This patch updates the JSScript SPI in the following ways:
- JSScript can now represent both modules and programs. This is a property
of the script determined during creation.
- JSScript now takes a sourceURL during construction. For modules, this acts
as the module identifier.
- JSScript now has SPI for writing the cache out to disk. We don't do this
automatically.
- JSScript will load the bytecode cache on creation if it exists.
- We retrofit these new requirements on the prior JSScript SPI that
we're going to remove as soon as we can: https://bugs.webkit.org/show_bug.cgi?id=194909.
Previous SPI assumes all JSScripts are modules. Previous SPI also assigns
a sourceURL to the JSScript based on what the module loader decided the
identifier should be. We'll remove this once we remove the old SPI.
This patch also adds SPI to JSContext to evaluate a JSScript. For modules,
this is like returning the result of doing dynamic import. For programs,
this does normal program evaluation.
This patch also fixes a bug in generateBytecode/generateModuleBytecode where
we would try to cache the bytecode even if recursivelyGenerateUnlinkedCodeBlock
returned null. E.g, if the script had a syntax error.
When writing tests, I also discovered that someone previously broke
testapi. This patch also fixes those failures. They were broken when
we switched to using a testapiScripts directory to hold our test .js
scripts.
* API/JSAPIGlobalObject.h:
* API/JSAPIGlobalObject.mm:
(JSC::JSAPIGlobalObject::moduleLoaderResolve):
(JSC::JSAPIGlobalObject::moduleLoaderFetch):
(JSC::JSAPIGlobalObject::loadAndEvaluateJSScriptModule):
* API/JSBase.cpp:
(JSEvaluateScriptInternal):
(JSEvaluateScript):
* API/JSBaseInternal.h: Added.
* API/JSContext.mm:
(-[JSContext evaluateScript:withSourceURL:]):
(-[JSContext evaluateJSScript:]):
* API/JSContextPrivate.h:
* API/JSScript.h:
* API/JSScript.mm:
(+[JSScript scriptWithSource:inVirtualMachine:]):
(+[JSScript scriptFromASCIIFile:inVirtualMachine:withCodeSigning:andBytecodeCache:]):
(createError):
(+[JSScript scriptOfType:inVirtualMachine:withSourceURL:andSource:andBytecodeCache:error:]):
(+[JSScript scriptOfType:inVirtualMachine:memoryMappedFromASCIIFile:withSourceURL:andBytecodeCache:error:]):
(-[JSScript cacheBytecodeWithError:]):
(-[JSScript sourceURL]):
(-[JSScript type]):
(-[JSScript jsSourceCode]):
(-[JSScript writeCache:]):
(-[JSScript setSourceURL:]):
(-[JSScript forceRecreateJSSourceCode]):
(-[JSScript writeCache]): Deleted.
(-[JSScript jsSourceCode:]): Deleted.
* API/JSScriptInternal.h:
* API/tests/FunctionOverridesTest.cpp:
(testFunctionOverrides):
* API/tests/testapi.c:
(main):
* API/tests/testapi.mm:
(tempFile):
(testModuleBytecodeCache):
(testProgramBytecodeCache):
(testBytecodeCacheWithSyntaxError):
(testProgramJSScriptException):
(testLoadBasicFileLegacySPI):
(+[JSContextMemoryMappedLoaderDelegate newContext]):
(-[JSContextMemoryMappedLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
(testLoadBasicFile):
(+[JSContextAugmentedLoaderDelegate newContext]):
(-[JSContextAugmentedLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
(testJSScriptURL):
(testObjectiveCAPI):
(testBytecodeCache): Deleted.
* API/tests/testapiScripts/foo.js: Added.
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/Completion.cpp:
(JSC::generateBytecode):
(JSC::generateModuleBytecode):
2019-02-21 Mark Lam <mark.lam@apple.com>
Add more doesGC() assertions.
https://bugs.webkit.org/show_bug.cgi?id=194911
<rdar://problem/48285723>
Reviewed by Saam Barati and Yusuke Suzuki.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::compileOSRExit):
- Set expectDoesGC here because we no longer have to worry about missing store
barriers in optimized code after this point. This will prevent false positive
assertion failures arising from functions called beneath compileOSRExit().
(JSC::DFG::OSRExit::compileExit):
- Add a comment to explain why the generated ramp needs to set expectDoesGC even
though compileOSRExit() also sets it. Reason: compileOSRExit() is only called
for the first OSR from this code origin, the generated ramp is called for many
subsequents OSR exits from this code origin.
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
- Added a comment for the equivalent reason to the one above.
(JSC::FTL::compileFTLOSRExit):
- Set expectDoesGC here because we no longer have to worry about missing store
barriers in optimized code after this point. This will prevent false positive
assertion failures arising from functions called beneath compileFTLOSRExit().
* heap/CompleteSubspace.cpp:
(JSC::CompleteSubspace::tryAllocateSlow):
* heap/CompleteSubspaceInlines.h:
(JSC::CompleteSubspace::allocateNonVirtual):
- assert expectDoesGC.
* heap/DeferGC.h:
(JSC::DeferGC::~DeferGC):
- assert expectDoesGC.
- Also added WTF_FORBID_HEAP_ALLOCATION to DeferGC, DeferGCForAWhile, and DisallowGC
because all 3 should be stack allocated RAII objects.
* heap/GCDeferralContext.h:
* heap/GCDeferralContextInlines.h:
(JSC::GCDeferralContext::~GCDeferralContext):
- Added WTF_FORBID_HEAP_ALLOCATION.
- assert expectDoesGC.
* heap/Heap.cpp:
(JSC::Heap::collectNow):
(JSC::Heap::collectAsync):
(JSC::Heap::collectSync):
(JSC::Heap::stopIfNecessarySlow):
(JSC::Heap::collectIfNecessaryOrDefer):
* heap/HeapInlines.h:
(JSC::Heap::acquireAccess):
(JSC::Heap::stopIfNecessary):
* heap/LargeAllocation.cpp:
(JSC::LargeAllocation::tryCreate):
* heap/LocalAllocatorInlines.h:
(JSC::LocalAllocator::allocate):
- conservatively assert expectDoesGC on these functions that may trigger a GC
though they don't always do.
* runtime/DisallowScope.h:
- DisallowScope should be stack allocated because it's an RAII object.
* runtime/JSCellInlines.h:
(JSC::tryAllocateCellHelper):
- Remove the expectDoesGC assertion because it is now covered by assertions in
CompleteSubspace, LargeAllocation, and LocalAllocator.
* runtime/RegExpMatchesArray.h:
(JSC::createRegExpMatchesArray):
- assert expectDoesGC.
2019-02-21 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use Fast Malloc as much as possible
https://bugs.webkit.org/show_bug.cgi?id=194316
Reviewed by Mark Lam.
We should use Fast Malloc as much as possible to offer the whole memory view to bmalloc.
* inspector/scripts/codegen/cpp_generator_templates.py:
* inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/generic/expected/enum-values.json-result:
* inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result:
* jit/ExecutableAllocator.h:
* jsc.cpp:
* runtime/JSRunLoopTimer.h:
* tools/VMInspector.h:
* wasm/WasmThunks.h:
2019-02-20 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Remove WatchpointSet creation for SymbolTable entries if VM::canUseJIT() returns false
https://bugs.webkit.org/show_bug.cgi?id=194891
Reviewed by Geoffrey Garen.
WatchpointSet in SymbolTable is used to fold the value into a constant in JIT tiers. And it is
not useful under the non-JIT mode. This patch avoids creation of WatchpointSet in SymbolTable
if VM::canUseJIT() returns false.
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/SymbolTable.cpp:
(JSC::SymbolTableEntry::addWatchpoint): Deleted.
* runtime/SymbolTable.h:
(JSC::SymbolTableEntry::isWatchable const):
(JSC::SymbolTableEntry::watchpointSet):
2019-02-20 Mark Lam <mark.lam@apple.com>
Add code to validate expected GC activity modelled by doesGC() against what the runtime encounters.
https://bugs.webkit.org/show_bug.cgi?id=193938
<rdar://problem/47616277>
Reviewed by Michael Saboff, Saam Barati, and Robin Morisset.
In DFG::SpeculativeJIT::compile() and FTL::LowerDFGToB3::compileNode(), before
emitting code / B3IR for each DFG node, we emit a write to set Heap::m_expectDoesGC
to the value returned by doesGC() for that node. In the runtime (i.e. in allocateCell()
and functions that can resolve a rope), we assert that Heap::m_expectDoesGC is
true.
This validation code is currently only enabled for debug builds. It is disabled
for release builds by default, but it can easily be made to run on release builds
as well by forcing ENABLE_DFG_DOES_GC_VALIDATION to 1 in Heap.h.
To allow this validation code to run on release builds as well, the validation uses
RELEASE_ASSERT instead of ASSERT.
To ensure that Heap.h is #include'd for all files that needs to do this validation
(so that the validation code is accidentally disabled), we guard the validation
code with an if conditional on constexpr bool validateDFGDoesGC (instead of using
a #if ENABLE(DFG_DOES_GC_VALIDATION)). This way, if Heap.h isn't #include'd, the
validation code will fail to build (no silent failures).
Currently, all JSC tests and Layout tests should pass with this validation enabled
in debug builds. We'll only see new failures if there's a regression or if new
tests reveal a previously untested code path that has an undetected issue.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::executeOSRExit):
(JSC::DFG::OSRExit::compileExit):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* heap/Heap.h:
(JSC::Heap::expectDoesGC const):
(JSC::Heap::setExpectDoesGC):
(JSC::Heap::addressOfExpectDoesGC):
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_compareAndJump):
* runtime/JSCellInlines.h:
(JSC::tryAllocateCellHelper):
* runtime/JSString.h:
(JSC::jsSingleCharacterString):
(JSC::JSString::toAtomicString const):
(JSC::JSString::toExistingAtomicString const):
(JSC::JSString::value const):
(JSC::JSString::tryGetValue const):
(JSC::JSRopeString::unsafeView const):
(JSC::JSRopeString::viewWithUnderlyingString const):
(JSC::JSString::unsafeView const):
2019-02-20 Andy Estes <aestes@apple.com>
[Xcode] Add SDKVariant.xcconfig to various Xcode projects
https://bugs.webkit.org/show_bug.cgi?id=194869
Rubber-stamped by Jer Noble.
* JavaScriptCore.xcodeproj/project.pbxproj:
2019-02-19 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Improve ES6 Class instances in Heap Snapshot instances view
https://bugs.webkit.org/show_bug.cgi?id=172848
<rdar://problem/25709212>
Reviewed by Mark Lam.
* heap/HeapSnapshotBuilder.h:
* heap/HeapSnapshotBuilder.cpp:
Update the snapshot version. Change the node's 0 | 1 internal value
to be a 32bit bit flag. This is nice in that it is both compatible
with the previous snapshot version and the same size. We can use more
flags in the future.
(JSC::HeapSnapshotBuilder::json):
In cases where the classInfo gives us "Object" check for a better
class name by checking (o).__proto__.constructor.name. We avoid this
check in cases where (o).hasOwnProperty("constructor") which is the
case for most Foo.prototype objects. Otherwise this would get the
name of the Foo superclass for the Foo.prototype object.
* runtime/JSObject.cpp:
(JSC::JSObject::calculatedClassName):
Handle some possible edge cases that were not handled before, such as
a JSObject without a GlobalObject or an object which doesn't
have a default getPrototype. Try to make the code a little clearer.
2019-02-19 Truitt Savell <tsavell@apple.com>
Unreviewed, rolling out r241784.
Broke all OpenSource builds.
Reverted changeset:
"Web Inspector: Improve ES6 Class instances in Heap Snapshot
instances view"
https://bugs.webkit.org/show_bug.cgi?id=172848
https://trac.webkit.org/changeset/241784
2019-02-19 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Improve ES6 Class instances in Heap Snapshot instances view
https://bugs.webkit.org/show_bug.cgi?id=172848
<rdar://problem/25709212>
Reviewed by Mark Lam.
* heap/HeapSnapshotBuilder.h:
* heap/HeapSnapshotBuilder.cpp:
Update the snapshot version. Change the node's 0 | 1 internal value
to be a 32bit bit flag. This is nice in that it is both compatible
with the previous snapshot version and the same size. We can use more
flags in the future.
(JSC::HeapSnapshotBuilder::json):
In cases where the classInfo gives us "Object" check for a better
class name by checking (o).__proto__.constructor.name. We avoid this
check in cases where (o).hasOwnProperty("constructor") which is the
case for most Foo.prototype objects. Otherwise this would get the
name of the Foo superclass for the Foo.prototype object.
* runtime/JSObject.cpp:
(JSC::JSObject::calculatedClassName):
Handle some possible edge cases that were not handled before, such as
a JSObject without a GlobalObject or an object which doesn't
have a default getPrototype. Try to make the code a little clearer.
2019-02-19 Robin Morisset <rmorisset@apple.com>
B3-O2 incorrectly optimizes this subtest
https://bugs.webkit.org/show_bug.cgi?id=194625
Reviewed by Saam Barati.
Trivial fix. Instead of doing
if (!cond) foo else bar => if (cond) bar else foo
B3LowerToAir was doing
if (x^C) foo else bar => if (cond) bar else foo whenever C&1, even if C was for example 3.
* b3/B3LowerToAir.cpp:
* b3/testb3.cpp:
(JSC::B3::testBitNotOnBooleanAndBranch32):
(JSC::B3::testNotOnBooleanAndBranch32): Added.
2019-02-19 Robin Morisset <rmorisset@apple.com>
CachedCall should not consider it UNLIKELY that it will not stack overflow
https://bugs.webkit.org/show_bug.cgi?id=194831
Reviewed by Mark Lam.
* interpreter/CachedCall.h:
(JSC::CachedCall::CachedCall):
2019-02-19 Mark Lam <mark.lam@apple.com>
Fix DFG doesGC() for TryGetById and ProfileType nodes.
https://bugs.webkit.org/show_bug.cgi?id=194821
<rdar://problem/48206690>
Reviewed by Saam Barati.
Fix doesGC() for the following nodes:
ProfileType:
calls operationProcessTypeProfilerLogDFG(), which can calculatedClassName(),
which can call JSString::tryGetValue(), which can resolve a rope.
TryGetById:
calls operationTryGetByIdOptimize(), which can startWatchingPropertyForReplacements()
on a structure, which can allocate StructureRareData.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
2019-02-18 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Introduce JSNonDestructibleProxy for JavaScriptCore.framework's GlobalThis
https://bugs.webkit.org/show_bug.cgi?id=194799
Reviewed by Saam Barati.
JSProxy is destructible one because we have JSWindowProxy which has ref counted object.
However, JavaScriptCore.framework's JSProxy for GlobalThis does not need to be destructible.
This is important since we need to separate Heap subspaces between destructible and non-destructible objects.
If we can put more and more objects in non-destructible status, we can get rid of low-usage MarkedBlock.
This patch adds JSNonDestructibleProxy, which is not destructible JSProxy. While it inherits JSDestructibleObject,
we can make the subclass still non-destructible thanks to Subspace mechanism. This drops one more low-usage MarkedBlock.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::resetPrototype):
(JSC::JSGlobalObject::finishCreation):
* runtime/JSNonDestructibleProxy.cpp: Added.
* runtime/JSNonDestructibleProxy.h: Added.
(JSC::JSNonDestructibleProxy::subspaceFor):
(JSC::JSNonDestructibleProxy::create):
(JSC::JSNonDestructibleProxy::createStructure):
(JSC::JSNonDestructibleProxy::JSNonDestructibleProxy):
* runtime/JSProxy.h:
(JSC::JSProxy::JSProxy):
2019-02-19 Robin Morisset <rmorisset@apple.com>
B3ReduceStrength::simplifyCFG() could do a lot more on each iteration
https://bugs.webkit.org/show_bug.cgi?id=194475
Reviewed by Saam Barati.
B3ReduceStrength::simplifyCFG() does three optimizations (which I will call A, B and C):
- A makes any terminal that points to a block that is empty except for a jump point to that jump's target instead.
- B transforms any branch or switch that points to a single block into a jump
- C finds blocks ending with jumps, whose successor has a single predecessor, and inline that successor block in place of the jump
It currently is limited in the following way:
- A and C can only fire once per block per iteration
- B can create jumps that would trigger A, but they may not be seen until the next iteration
Both problems are mitigated by going through the blocks in post-order, so that when a block is optimized most of its successors have already been optimized.
In a sense it is the symmetric of the peephole optimizer that goes in pre-order so that when an instruction is optimized most of its children have already been optimized.
On JetStream2 it reduces the average number of iterations from 3.35 to 3.24.
* b3/B3ReduceStrength.cpp:
2019-02-19 Tadeu Zagallo <tzagallo@apple.com>
Move bytecode cache-related filesystem code out of CodeCache
https://bugs.webkit.org/show_bug.cgi?id=194675
Reviewed by Saam Barati.
The code is only used for the bytecode-cache tests, so it should live in
jsc.cpp rather than in the CodeCache. The logic now lives in ShellSourceProvider,
which overrides the a virtual method in SourceProvider, `cacheBytecode`,
in order to write the cache to disk.
* jsc.cpp:
(ShellSourceProvider::create):
(ShellSourceProvider::~ShellSourceProvider):
(ShellSourceProvider::cachePath const):
(ShellSourceProvider::loadBytecode):
(ShellSourceProvider::ShellSourceProvider):
(jscSource):
(GlobalObject::moduleLoaderFetch):
(functionDollarEvalScript):
(runWithOptions):
* parser/SourceProvider.h:
(JSC::SourceProvider::cacheBytecode const):
* runtime/CodeCache.cpp:
(JSC::writeCodeBlock):
* runtime/CodeCache.h:
(JSC::CodeCacheMap::fetchFromDiskImpl):
2019-02-18 Dominik Infuehr <dinfuehr@igalia.com>
[ARM] Fix crash with sampling profiler
https://bugs.webkit.org/show_bug.cgi?id=194772
Reviewed by Mark Lam.
sampling-profiler-richards.js was crashing with an enabled sampling profiler. add32
did not update the stack pointer in a single instruction. The src register was first
moved into the stack pointer, the immediate imm was added in a subsequent instruction.
This was problematic when a signal handler was invoked before applying the immediate,
when the stack pointer is still set to the temporary value. Avoid this by calculating src+imm in
a temporary register and then move it in one go into the stack pointer.
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::add32):
2019-02-18 Mark Lam <mark.lam@apple.com>
Fix DFG doesGC() for CompareEq/Less/LessEq/Greater/GreaterEq and CompareStrictEq nodes.
https://bugs.webkit.org/show_bug.cgi?id=194800
<rdar://problem/48183773>
Reviewed by Yusuke Suzuki.
Fix doesGC() for the following nodes:
CompareEq:
CompareLess:
CompareLessEq:
CompareGreater:
CompareGreaterEq:
CompareStrictEq:
Only return false (i.e. does not GC) for child node use kinds that have
been vetted to not do anything that can GC. For all other use kinds
(including StringUse and BigIntUse), we return true (i.e. does GC).
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
2019-02-16 Darin Adler <darin@apple.com>
Continue reducing use of String::format, now focusing on hex: "%p", "%x", etc.
https://bugs.webkit.org/show_bug.cgi?id=194752
Reviewed by Daniel Bates.
* heap/HeapSnapshotBuilder.cpp:
(JSC::HeapSnapshotBuilder::json): Added back the "0x" that was removed when changing
this file to use appendUnsignedAsHex instead of "%p". The intent at that time was to
keep behavior the same, so let's do that.
* parser/Lexer.cpp:
(JSC::Lexer<T>::invalidCharacterMessage const): Use makeString and hex instead of
String::format and "%04x".
2019-02-18 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add LazyClassStructure::getInitializedOnMainThread
https://bugs.webkit.org/show_bug.cgi?id=194784
<rdar://problem/48154820>
Reviewed by Mark Lam.
LazyClassStructure::get and LazyProperty::get functions do not allow compiler threads to call them. But for booleanPrototype, numberPrototype and symbolPrototype cases,
we would like to call them from compiler threads. We eagerly initialize them if VM::canUseJIT() is true, so that compiler threads can safely call LazyClassStructure::get
and LazyProperty::get for booleanPrototype, numberPrototype and symbolPrototype. But still assertion hits because the assertion requires that these functions need to be
called in non compiler threads. Calling `getConcurrently()` is not possible since symbolPrototype() function is called from both the main thread and compiler threads,
and we would like to lazily initialize SymbolPrototype object if it is called from the main thread, which can happen with non-JIT configuration.
This patch adds `getInitializedOnMainThread()`. Compiler threads can call it only when we know that the value is already initialized on the main thread. The main thread
can call it at anytime and this function lazily initializes the value. This is useful to make some of prototypes lazy with non-JIT configuration: With non-JIT configuration,
this function is always called from the main thread and it initializes the value lazily. Non-JIT configuration does not care about compiler threads since they do not exist.
With JIT configuration, we eagerly initialize them in JSGlobalObject::init so that `getInitializedOnMainThread()` always succeeds.
Basically, `getInitializedOnMainThread()` is `get` with different assertion location: While `get` always crashes if it is called from compiler threads, `getInitializedOnMainThread()`
crashes only when actual initialization happens on compiler threads. We do not merge them since `get` is still useful to find accidental initialization from compiler threads.
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::booleanPrototype const):
(JSC::JSGlobalObject::numberPrototype const):
(JSC::JSGlobalObject::symbolPrototype const):
* runtime/LazyClassStructure.h:
(JSC::LazyClassStructure::getInitializedOnMainThread const):
(JSC::LazyClassStructure::prototypeInitializedOnMainThread const):
(JSC::LazyClassStructure::constructorInitializedOnMainThread const):
* runtime/LazyProperty.h:
(JSC::LazyProperty::get const):
(JSC::LazyProperty::getInitializedOnMainThread const):
2019-02-18 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Better categorize CPU usage per-thread / worker
https://bugs.webkit.org/show_bug.cgi?id=194564
Reviewed by Devin Rousso.
* inspector/protocol/CPUProfiler.json:
Add additional properties per-Event, and new per-Thread object info.
2019-02-18 Tadeu Zagallo <tzagallo@apple.com>
Bytecode cache should a have a boot-specific validation
https://bugs.webkit.org/show_bug.cgi?id=194769
<rdar://problem/48149509>
Reviewed by Keith Miller.
Add the boot UUID to the cached bytecode to enforce that it is not reused
across reboots.
* runtime/CachedTypes.cpp:
(JSC::Encoder::malloc):
(JSC::GenericCacheEntry::GenericCacheEntry):
(JSC::GenericCacheEntry::tag const):
(JSC::CacheEntry::CacheEntry):
(JSC::CacheEntry::decode const):
(JSC::GenericCacheEntry::decode const):
(JSC::encodeCodeBlock):
2019-02-18 Eric Carlson <eric.carlson@apple.com>
Add MSE logging configuration
https://bugs.webkit.org/show_bug.cgi?id=194719
<rdar://problem/48122151>
Reviewed by Joseph Pecoraro.
* inspector/ConsoleMessage.cpp:
(Inspector::messageSourceValue):
* inspector/protocol/Console.json:
* inspector/scripts/codegen/generator.py:
* runtime/ConsoleTypes.h:
2019-02-18 Tadeu Zagallo <tzagallo@apple.com>
Add version number to cached bytecode
https://bugs.webkit.org/show_bug.cgi?id=194768
<rdar://problem/48147968>
Reviewed by Saam Barati.
Add a version number to the bytecode cache that should be unique per build.
* CMakeLists.txt:
* DerivedSources-output.xcfilelist:
* DerivedSources.make:
* runtime/CachedTypes.cpp:
(JSC::Encoder::malloc):
(JSC::GenericCacheEntry::GenericCacheEntry):
(JSC::CacheEntry::CacheEntry):
(JSC::CacheEntry::encode):
(JSC::CacheEntry::decode const):
(JSC::GenericCacheEntry::decode const):
(JSC::decodeCodeBlockImpl):
* runtime/CodeCache.h:
(JSC::CodeCacheMap::fetchFromDiskImpl):
2019-02-17 Saam Barati <sbarati@apple.com>
WasmB3IRGenerator models some effects incorrectly
https://bugs.webkit.org/show_bug.cgi?id=194038
Reviewed by Keith Miller.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::restoreWasmContextInstance):
(JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
These two functions were using global state instead of the
arguments passed into the function.
(JSC::Wasm::B3IRGenerator::addOp<F64ConvertUI64>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::F32ConvertUI64>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::I64TruncUF64>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::I64TruncUF32>):
Any patchpoint that allows scratch register usage must
also say that it clobbers the scratch registers.
2019-02-17 Saam Barati <sbarati@apple.com>
Deadlock when adding a Structure property transition and then doing incremental marking
https://bugs.webkit.org/show_bug.cgi?id=194767
Reviewed by Mark Lam.
This can happen in the following scenario:
You have a Structure S. S is on the mark stack. Then:
1. S grabs its lock
2. S adds a new property transition
3. We find out we need to do some incremental marking
4. We mark S
5. visitChildren on S will try to grab its lock
6. We are now in a deadlock
* heap/Heap.cpp:
(JSC::Heap::performIncrement):
* runtime/Structure.cpp:
(JSC::Structure::addNewPropertyTransition):
2019-02-17 David Kilzer <ddkilzer@apple.com>
Unreviewed, rolling out r241620.
"Causes use-after-free crashes running layout tests with ASan and GuardMalloc."
(Requested by ddkilzer on #webkit.)
Reverted changeset:
"[WTF] Add environment variable helpers"
https://bugs.webkit.org/show_bug.cgi?id=192405
https://trac.webkit.org/changeset/241620
2019-02-17 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r241612.
https://bugs.webkit.org/show_bug.cgi?id=194762
"It regressed JetStream2 parsing tests by ~40%" (Requested by
saamyjoon on #webkit).
Reverted changeset:
"Move bytecode cache-related filesystem code out of CodeCache"
https://bugs.webkit.org/show_bug.cgi?id=194675
https://trac.webkit.org/changeset/241612
2019-02-16 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] JSWrapperObject should not be destructible
https://bugs.webkit.org/show_bug.cgi?id=194743
Reviewed by Saam Barati.
JSWrapperObject should be just a wrapper object for JSValue, thus, it should not be a JSDestructibleObject.
Currently it is destructible object because DateInstance uses it. This patch changes Base of DateInstance from
JSWrapperObject to JSDestructibleObject, and makes JSWrapperObject non-destructible.
* runtime/BigIntObject.cpp:
(JSC::BigIntObject::BigIntObject):
* runtime/BooleanConstructor.cpp:
(JSC::BooleanConstructor::finishCreation):
* runtime/BooleanObject.cpp:
(JSC::BooleanObject::BooleanObject):
* runtime/BooleanObject.h:
* runtime/DateInstance.cpp:
(JSC::DateInstance::DateInstance):
(JSC::DateInstance::finishCreation):
* runtime/DateInstance.h:
* runtime/DatePrototype.cpp:
(JSC::dateProtoFuncGetTime):
(JSC::dateProtoFuncSetTime):
(JSC::setNewValueFromTimeArgs):
(JSC::setNewValueFromDateArgs):
(JSC::dateProtoFuncSetYear):
* runtime/JSCPoison.h:
* runtime/JSWrapperObject.h:
(JSC::JSWrapperObject::JSWrapperObject):
* runtime/NumberObject.cpp:
(JSC::NumberObject::NumberObject):
* runtime/NumberObject.h:
* runtime/StringConstructor.cpp:
(JSC::StringConstructor::finishCreation):
* runtime/StringObject.cpp:
(JSC::StringObject::StringObject):
* runtime/StringObject.h:
(JSC::StringObject::internalValue const):
* runtime/SymbolObject.cpp:
(JSC::SymbolObject::SymbolObject):
* runtime/SymbolObject.h:
2019-02-16 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Shrink UnlinkedFunctionExecutable
https://bugs.webkit.org/show_bug.cgi?id=194733
Reviewed by Mark Lam.
UnlinkedFunctionExecutable has sourceURLDirective and sourceMappingURLDirective. These
directives can be found in the comment of non typical function's source code (Program,
Eval code, and Global function from function constructor etc.), and tricky thing is that
SourceProvider's directives are updated by Parser. The reason why we have these fields in
UnlinkedFunctionExecutable is that we need to update the SourceProvider's directives even
if we skip parsing by using CodeCache. These fields are effective only if (1)
UnlinkedFunctionExecutable is for non typical function things, and (2) it has sourceURLDirective
or sourceMappingURLDirective. This is rare enough to purge them to a separated
UnlinkedFunctionExecutable::RareData to make UnlinkedFunctionExecutable small.
sizeof(UnlinkedFunctionExecutable) is very important since it is super frequently allocated
cell. Furthermore, the current JSC allocates two MarkedBlocks for UnlinkedFunctionExecutable
in JSGlobalObject initialization, but the usage of the second MarkedBlock is quite low (8%).
If we can reduce the size of UnlinkedFunctionExecutable, we can make them one MarkedBlock.
Since UnlinkedFunctionExecutable is allocated from IsoSubspace, we do not need to fit it to
one of size class.
This patch adds RareData to UnlinkedFunctionExecutable and move some rare datas into RareData.
And kill one MarkedBlock allocation in JSC initialization phase.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::UnlinkedFunctionExecutable::ensureRareDataSlow):
* bytecode/UnlinkedFunctionExecutable.h:
* debugger/DebuggerLocation.cpp:
(JSC::DebuggerLocation::DebuggerLocation):
* inspector/ScriptDebugServer.cpp:
(Inspector::ScriptDebugServer::dispatchDidParseSource):
* parser/Lexer.h:
(JSC::Lexer::sourceURLDirective const):
(JSC::Lexer::sourceMappingURLDirective const):
(JSC::Lexer::sourceURL const): Deleted.
(JSC::Lexer::sourceMappingURL const): Deleted.
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
* parser/SourceProvider.h:
(JSC::SourceProvider::sourceURLDirective const):
(JSC::SourceProvider::sourceMappingURLDirective const):
(JSC::SourceProvider::setSourceURLDirective):
(JSC::SourceProvider::setSourceMappingURLDirective):
(JSC::SourceProvider::sourceURL const): Deleted. We rename it from sourceURL to sourceURLDirective
since it is the correct name.
(JSC::SourceProvider::sourceMappingURL const): Deleted. We rename it from sourceMappingURL to
sourceMappingURLDirective since it is the correct name.
* runtime/CachedTypes.cpp:
(JSC::CachedSourceProviderShape::encode):
(JSC::CachedFunctionExecutableRareData::encode):
(JSC::CachedFunctionExecutableRareData::decode const): CachedFunctionExecutable did not have
sourceMappingURL to sourceMappingURLDirective. So this patch keeps the same logic.
(JSC::CachedFunctionExecutable::rareData const):
(JSC::CachedFunctionExecutable::encode):
(JSC::CachedFunctionExecutable::decode const):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
* runtime/CodeCache.h:
(JSC::generateUnlinkedCodeBlockImpl):
* runtime/FunctionExecutable.h:
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::StackFrame::url):
2019-02-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Remove unused global private variables
https://bugs.webkit.org/show_bug.cgi?id=194741
Reviewed by Joseph Pecoraro.
There are some private functions and constants that are no longer referenced from builtin JS code.
This patch cleans up them.
* builtins/BuiltinNames.h:
* builtins/ObjectConstructor.js:
(entries):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
2019-02-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Lazily create empty RegExp
https://bugs.webkit.org/show_bug.cgi?id=194735
Reviewed by Keith Miller.
Some scripts do not have any RegExp. In that case, allocating MarkedBlock for RegExp is costly.
Previously, there was always one RegExp, "empty RegExp". This patch lazily creates it and drop
one MarkedBlock.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/RegExpCache.cpp:
(JSC::RegExpCache::ensureEmptyRegExpSlow):
(JSC::RegExpCache::initialize): Deleted.
* runtime/RegExpCache.h:
(JSC::RegExpCache::ensureEmptyRegExp):
(JSC::RegExpCache::emptyRegExp const): Deleted.
* runtime/RegExpCachedResult.cpp:
(JSC::RegExpCachedResult::lastResult):
* runtime/RegExpCachedResult.h:
* runtime/VM.cpp:
(JSC::VM::VM):
2019-02-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Make builtin objects more lazily initialized under non-JIT mode
https://bugs.webkit.org/show_bug.cgi?id=194727
Reviewed by Saam Barati.
Boolean, Symbol, and Number constructors and prototypes are initialized eagerly, but this is largely
because concurrent compiler can touch NumberPrototype etc. when traversing object's prototypes. This
means that eager initialization is not necessary under non-JIT mode. While we can investigate all the
accesses to these prototypes from the concurrent compiler threads, this "lazily initialize under non-JIT"
is safe and beneficial to non-JIT mode. This patch lazily initializes them under non-JIT mode, and
drop some @Number references to avoid eager initialization. This removes some object allocations and 1
MarkedBlock allocation just for Symbols.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::numberToStringWatchpoint):
(JSC::JSGlobalObject::booleanPrototype const):
(JSC::JSGlobalObject::numberPrototype const):
(JSC::JSGlobalObject::symbolPrototype const):
(JSC::JSGlobalObject::booleanObjectStructure const):
(JSC::JSGlobalObject::symbolObjectStructure const):
(JSC::JSGlobalObject::numberObjectStructure const):
(JSC::JSGlobalObject::stringObjectStructure const):
2019-02-15 Michael Saboff <msaboff@apple.com>
RELEASE_ASSERT at com.apple.JavaScriptCore: JSC::jsSubstringOfResolved
https://bugs.webkit.org/show_bug.cgi?id=194558
Reviewed by Saam Barati.
Added an in bounds check before the read of the next character for Unicode regular expressions
for pattern generation that didn't already have such checks.
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::generatePatternCharacterOnce):
(JSC::Yarr::YarrGenerator::generatePatternCharacterFixed):
(JSC::Yarr::YarrGenerator::generateCharacterClassOnce):
(JSC::Yarr::YarrGenerator::generateCharacterClassFixed):
2019-02-15 Dean Jackson <dino@apple.com>
Allow emulation of user gestures from Web Inspector console
https://bugs.webkit.org/show_bug.cgi?id=194725
<rdar://problem/48126604>
Reviewed by Joseph Pecoraro and Devin Rousso.
* inspector/agents/InspectorRuntimeAgent.cpp: Add a new optional parameter, emulateUserGesture,
to the evaluate function, and mark the function as override so that PageRuntimeAgent
can change the behaviour.
(Inspector::InspectorRuntimeAgent::evaluate):
* inspector/agents/InspectorRuntimeAgent.h:
* inspector/protocol/Runtime.json:
2019-02-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Do not initialize Wasm related data if Wasm is not enabled
https://bugs.webkit.org/show_bug.cgi?id=194728
Reviewed by Mark Lam.
Under non-JIT mode, these data structures are unnecessary. Should not allocate extra memory for that.
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSLock.cpp:
(JSC::JSLock::didAcquireLock):
2019-02-15 Ross Kirsling <ross.kirsling@sony.com>
[WTF] Add environment variable helpers
https://bugs.webkit.org/show_bug.cgi?id=192405
Reviewed by Michael Catanzaro.
* inspector/remote/glib/RemoteInspectorGlib.cpp:
(Inspector::RemoteInspector::RemoteInspector):
(Inspector::RemoteInspector::start):
* jsc.cpp:
(startTimeoutThreadIfNeeded):
* runtime/Options.cpp:
(JSC::overrideOptionWithHeuristic):
(JSC::Options::overrideAliasedOptionWithHeuristic):
(JSC::Options::initialize):
* runtime/VM.cpp:
(JSC::enableAssembler):
(JSC::VM::VM):
* tools/CodeProfiling.cpp:
(JSC::CodeProfiling::notifyAllocator):
Utilize WTF::Environment where possible.
2019-02-15 Mark Lam <mark.lam@apple.com>
SamplingProfiler::stackTracesAsJSON() should escape strings.
https://bugs.webkit.org/show_bug.cgi?id=194649
<rdar://problem/48072386>
Reviewed by Saam Barati.
Ditto for TypeSet::toJSONString() and TypeSet::toJSONString().
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::stackTracesAsJSON):
* runtime/TypeSet.cpp:
(JSC::TypeSet::toJSONString const):
(JSC::StructureShape::toJSONString const):
2019-02-15 Robin Morisset <rmorisset@apple.com>
CodeBlock::jettison should clear related watchpoints
https://bugs.webkit.org/show_bug.cgi?id=194544
Reviewed by Mark Lam.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::jettison):
* dfg/DFGCommonData.h:
(JSC::DFG::CommonData::clearWatchpoints): Added.
* dfg/CommonData.cpp:
(JSC::DFG::CommonData::clearWatchpoints): Added.
2019-02-15 Tadeu Zagallo <tzagallo@apple.com>
Move bytecode cache-related filesystem code out of CodeCache
https://bugs.webkit.org/show_bug.cgi?id=194675
Reviewed by Saam Barati.
That code is only used for the bytecode-cache tests, so it should live in
jsc.cpp rather than in the CodeCache.
* jsc.cpp:
(CliSourceProvider::create):
(CliSourceProvider::~CliSourceProvider):
(CliSourceProvider::cachePath const):
(CliSourceProvider::loadBytecode):
(CliSourceProvider::CliSourceProvider):
(jscSource):
(GlobalObject::moduleLoaderFetch):
(functionDollarEvalScript):
(runWithOptions):
* parser/SourceProvider.h:
(JSC::SourceProvider::cacheBytecode const):
* runtime/CodeCache.cpp:
(JSC::writeCodeBlock):
* runtime/CodeCache.h:
(JSC::CodeCacheMap::fetchFromDiskImpl):
2019-02-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] DFG, FTL, and Wasm worklist creation should be fenced
https://bugs.webkit.org/show_bug.cgi?id=194714
Reviewed by Mark Lam.
Let's consider about the following extreme case.
1. VM (A) is created.
2. Another VM (B) is created on a different thread.
3. (A) is being destroyed. It calls DFG::existingWorklistForIndexOrNull in a destructor.
4. At the same time, (B) starts using DFG Worklist and it is instantiated in call_once.
5. But (A) reads the pointer directly through DFG::existingWorklistForIndexOrNull.
6. (A) sees the half-baked worklist, which may be in the middle of creation.
This patch puts store-store fence just before putting a pointer to a global variable.
This fence is executed only three times at most, for DFG, FTL, and Wasm worklist initializations.
* dfg/DFGWorklist.cpp:
(JSC::DFG::ensureGlobalDFGWorklist):
(JSC::DFG::ensureGlobalFTLWorklist):
* wasm/WasmWorklist.cpp:
(JSC::Wasm::ensureWorklist):
2019-02-15 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r241559 and r241566.
https://bugs.webkit.org/show_bug.cgi?id=194710
Causes layout test crashes under GuardMalloc (Requested by
ryanhaddad on #webkit).
Reverted changesets:
"[WTF] Add environment variable helpers"
https://bugs.webkit.org/show_bug.cgi?id=192405
https://trac.webkit.org/changeset/241559
"Unreviewed build fix for WinCairo Debug after r241559."
https://trac.webkit.org/changeset/241566
2019-02-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Do not even allocate JIT worklists in non-JIT mode
https://bugs.webkit.org/show_bug.cgi?id=194693
Reviewed by Mark Lam.
Heap always allocates JIT worklists for Baseline, DFG, and FTL. While they do not have actual threads, Worklist itself already allocates some memory.
And we do not perform any GC operations that are only meaningful in JIT environment.
1. We add VM::canUseJIT() check in Heap's ensureXXXWorklist things to prevent them from being allocated.
2. We remove DFG marking constraint in non-JIT mode.
3. We do not gather conservative roots from scratch buffers under the non-JIT mode (BTW, # of scratch buffers are always zero in non-JIT mode)
4. We do not visit JITStubRoutineSet.
5. Align JITWorklist function names to the other worklists.
* dfg/DFGOSRExitPreparation.cpp:
(JSC::DFG::prepareCodeOriginForOSRExit):
* dfg/DFGPlan.h:
* dfg/DFGWorklist.cpp:
(JSC::DFG::markCodeBlocks): Deleted.
* dfg/DFGWorklist.h:
* heap/Heap.cpp:
(JSC::Heap::completeAllJITPlans):
(JSC::Heap::iterateExecutingAndCompilingCodeBlocks):
(JSC::Heap::gatherScratchBufferRoots):
(JSC::Heap::removeDeadCompilerWorklistEntries):
(JSC::Heap::stopThePeriphery):
(JSC::Heap::suspendCompilerThreads):
(JSC::Heap::resumeCompilerThreads):
(JSC::Heap::addCoreConstraints):
* jit/JITWorklist.cpp:
(JSC::JITWorklist::existingGlobalWorklistOrNull):
(JSC::JITWorklist::ensureGlobalWorklist):
(JSC::JITWorklist::instance): Deleted.
* jit/JITWorklist.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::jitCompileAndSetHeuristics):
* runtime/VM.cpp:
(JSC::VM::~VM):
(JSC::VM::gatherScratchBufferRoots):
(JSC::VM::gatherConservativeRoots): Deleted.
* runtime/VM.h:
2019-02-15 Saam barati <sbarati@apple.com>
[WebAssembly] Write a new register allocator for Air O0 and make BBQ use it
https://bugs.webkit.org/show_bug.cgi?id=194036
Reviewed by Yusuke Suzuki.
This patch adds a new Air-O0 backend. Air-O0 runs fewer passes and doesn't
use linear scan for register allocation. Instead of linear scan, Air-O0 does
mostly block-local register allocation, and it does this as it's emitting
code directly. The register allocator uses liveness analysis to reduce
the number of spills. Doing register allocation as we're emitting code
allows us to skip editing the IR to insert spills, which saves a non trivial
amount of compile time. For stack allocation, we give each Tmp its own slot.
This is less than ideal. We probably want to do some trivial live range analysis
in the future. The reason this isn't a deal breaker for Wasm is that this patch
makes it so that we reuse Tmps as we're generating Air IR in the AirIRGenerator.
Because Wasm is a stack machine, we trivially know when we kill a stack value (its last use).
This patch is another 25% Wasm startup time speedup. It seems to be worth
another 1% on JetStream2.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp: Added.
(JSC::B3::Air::GenerateAndAllocateRegisters::GenerateAndAllocateRegisters):
(JSC::B3::Air::GenerateAndAllocateRegisters::buildLiveRanges):
(JSC::B3::Air::GenerateAndAllocateRegisters::insertBlocksForFlushAfterTerminalPatchpoints):
(JSC::B3::Air::callFrameAddr):
(JSC::B3::Air::GenerateAndAllocateRegisters::flush):
(JSC::B3::Air::GenerateAndAllocateRegisters::spill):
(JSC::B3::Air::GenerateAndAllocateRegisters::alloc):
(JSC::B3::Air::GenerateAndAllocateRegisters::freeDeadTmpsIfNeeded):
(JSC::B3::Air::GenerateAndAllocateRegisters::assignTmp):
(JSC::B3::Air::GenerateAndAllocateRegisters::isDisallowedRegister):
(JSC::B3::Air::GenerateAndAllocateRegisters::prepareForGeneration):
(JSC::B3::Air::GenerateAndAllocateRegisters::generate):
* b3/air/AirAllocateRegistersAndStackAndGenerateCode.h: Added.
* b3/air/AirCode.cpp:
* b3/air/AirCode.h:
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::prepareForGeneration):
(JSC::B3::Air::generateWithAlreadyAllocatedRegisters):
(JSC::B3::Air::generate):
* b3/air/AirHandleCalleeSaves.cpp:
(JSC::B3::Air::handleCalleeSaves):
* b3/air/AirHandleCalleeSaves.h:
* b3/air/AirTmpMap.h:
* runtime/Options.h:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::didKill):
(JSC::Wasm::AirIRGenerator::newTmp):
(JSC::Wasm::AirIRGenerator::AirIRGenerator):
(JSC::Wasm::parseAndCompileAir):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64TruncUF64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64TruncUF32>):
* wasm/WasmAirIRGenerator.h:
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::didKill):
* wasm/WasmBBQPlan.cpp:
(JSC::Wasm::BBQPlan::compileFunctions):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseBody):
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/WasmValidate.cpp:
(JSC::Wasm::Validate::didKill):
2019-02-14 Saam barati <sbarati@apple.com>
lowerStackArgs should lower Lea32/64 on ARM64 to Add
https://bugs.webkit.org/show_bug.cgi?id=194656
Reviewed by Yusuke Suzuki.
On arm64, Lea is just implemented as an add. However, Air treats it as an
address with a given width. Because of this width, we were incorrectly
computing whether or not this immediate could fit into the instruction itself
or it needed to be explicitly put into a register. This patch makes
AirLowerStackArgs lower Lea to Add on arm64.
* b3/air/AirLowerStackArgs.cpp:
(JSC::B3::Air::lowerStackArgs):
* b3/air/AirOpcode.opcodes:
* b3/air/testair.cpp:
2019-02-14 Saam Barati <sbarati@apple.com>
Cache the results of BytecodeGenerator::getVariablesUnderTDZ
https://bugs.webkit.org/show_bug.cgi?id=194583
<rdar://problem/48028140>
Reviewed by Yusuke Suzuki.
This patch makes it so that getVariablesUnderTDZ caches a result of
CompactVariableMap::Handle. getVariablesUnderTDZ is costly when
it's called in an environment where there are a lot of variables.
This patch makes it so we cache its results. This is profitable when
getVariablesUnderTDZ is called repeatedly with the same environment
state. This is common since we call this every time we encounter a
function definition/expression node.
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createExecutable):
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::popLexicalScopeInternal):
(JSC::BytecodeGenerator::liftTDZCheckIfPossible):
(JSC::BytecodeGenerator::pushTDZVariables):
(JSC::BytecodeGenerator::getVariablesUnderTDZ):
(JSC::BytecodeGenerator::restoreTDZStack):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::makeFunction):
* parser/VariableEnvironment.cpp:
(JSC::CompactVariableMap::Handle::Handle):
(JSC::CompactVariableMap::Handle::operator=):
* parser/VariableEnvironment.h:
(JSC::CompactVariableMap::Handle::operator bool const):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
2019-02-14 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Non-JIT entrypoints should share NativeJITCode per entrypoint type
https://bugs.webkit.org/show_bug.cgi?id=194659
Reviewed by Mark Lam.
Non-JIT entrypoints create NativeJITCode every time it is called. But it is meaningless since these entry point code are identical.
We should create one per entrypoint type (for function, we should have CodeForCall and CodeForConstruct) and continue to use them.
And we use NativeJITCode instead of DirectJITCode if it does not have difference between usual entrypoint and arity check entrypoint.
* dfg/DFGJITCode.h:
* dfg/DFGJITFinalizer.cpp:
(JSC::DFG::JITFinalizer::finalize):
(JSC::DFG::JITFinalizer::finalizeFunction):
* jit/JITCode.cpp:
(JSC::DirectJITCode::initializeCodeRefForDFG):
(JSC::DirectJITCode::initializeCodeRef): Deleted.
(JSC::NativeJITCode::initializeCodeRef): Deleted.
* jit/JITCode.h:
* llint/LLIntEntrypoint.cpp:
(JSC::LLInt::setFunctionEntrypoint):
(JSC::LLInt::setEvalEntrypoint):
(JSC::LLInt::setProgramEntrypoint):
(JSC::LLInt::setModuleProgramEntrypoint): Retagged is removed since the tag is the same.
2019-02-14 Ross Kirsling <ross.kirsling@sony.com>
[WTF] Add environment variable helpers
https://bugs.webkit.org/show_bug.cgi?id=192405
Reviewed by Michael Catanzaro.
* inspector/remote/glib/RemoteInspectorGlib.cpp:
(Inspector::RemoteInspector::RemoteInspector):
(Inspector::RemoteInspector::start):
* jsc.cpp:
(startTimeoutThreadIfNeeded):
* runtime/Options.cpp:
(JSC::overrideOptionWithHeuristic):
(JSC::Options::overrideAliasedOptionWithHeuristic):
(JSC::Options::initialize):
* runtime/VM.cpp:
(JSC::enableAssembler):
(JSC::VM::VM):
* tools/CodeProfiling.cpp:
(JSC::CodeProfiling::notifyAllocator):
Utilize WTF::Environment where possible.
2019-02-14 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Should have default NativeJITCode
https://bugs.webkit.org/show_bug.cgi?id=194634
Reviewed by Mark Lam.
In JSC_useJIT=false mode, we always create identical NativeJITCode for call and construct when we create NativeExecutable.
This is meaningless since we do not modify NativeJITCode after the creation. This patch adds singleton used as a default one.
Since NativeJITCode (& JITCode) is ThreadSafeRefCounted, we can just share it in a whole process level. This removes 446 NativeJITCode
allocations, which takes 14KB.
* runtime/VM.cpp:
(JSC::jitCodeForCallTrampoline):
(JSC::jitCodeForConstructTrampoline):
(JSC::VM::getHostFunction):
2019-02-14 Tadeu Zagallo <tzagallo@apple.com>
generateUnlinkedCodeBlockForFunctions shouldn't need to create a FunctionExecutable just to get its source code
https://bugs.webkit.org/show_bug.cgi?id=194576
Reviewed by Saam Barati.
Extract a new function, `linkedSourceCode` from UnlinkedFunctionExecutable::link
and use it in `generateUnlinkedCodeBlockForFunctions` instead.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::linkedSourceCode const):
(JSC::UnlinkedFunctionExecutable::link):
* bytecode/UnlinkedFunctionExecutable.h:
* runtime/CodeCache.cpp:
(JSC::generateUnlinkedCodeBlockForFunctions):
2019-02-14 Tadeu Zagallo <tzagallo@apple.com>
CachedBitVector's size must be converted from bits to bytes
https://bugs.webkit.org/show_bug.cgi?id=194441
Reviewed by Saam Barati.
CachedBitVector used its size in bits for memcpy. That didn't cause any
issues when encoding, since the size in bits was also used in the allocation,
but would overflow the actual BitVector buffer when decoding.
* runtime/CachedTypes.cpp:
(JSC::CachedBitVector::encode):
(JSC::CachedBitVector::decode const):
2019-02-13 Brian Burg <bburg@apple.com>
Web Inspector: don't include accessibility role in DOM.Node object payloads
https://bugs.webkit.org/show_bug.cgi?id=194623
<rdar://problem/36384037>
Reviewed by Devin Rousso.
Remove property of DOM.Node that is no longer being sent.
* inspector/protocol/DOM.json:
2019-02-13 Keith Miller <keith_miller@apple.com> and Yusuke Suzuki <ysuzuki@apple.com>
We should only make rope strings when concatenating strings long enough.
https://bugs.webkit.org/show_bug.cgi?id=194465
Reviewed by Mark Lam.
This patch stops us from allocating a rope string if the resulting
rope would be smaller than the size of the JSRopeString object we
would need to allocate.
This patch also adds paths so that we don't unnecessarily allocate
JSString cells for primitives we are going to concatenate with a
string anyway.
The important change from the previous one is that we do not apply
the above rule to JSRopeStrings generated by JSStrings. If we convert
it to JSString, comparison of memory consumption becomes the following,
because JSRopeString does not have StringImpl until it is resolved.
sizeof(JSRopeString) v.s. sizeof(JSString) + sizeof(StringImpl) + content
Since sizeof(JSString) + sizeof(StringImpl) is larger than sizeof(JSRopeString),
resolving eagerly increases memory footprint. The point is that we need to
account newly created JSString and JSRopeString from the operands. This is the
reason why this patch adds different thresholds for each jsString functions.
This patch also avoids concatenation for ropes conservatively. Many ropes are
temporary cells. So we do not resolve eagerly if one of operands is already a
rope.
In CLI execution, this change is performance neutral in JetStream2 (run 6 times, 1 for warming up and average in latter 5.).
Before: 159.3778
After: 160.72340000000003
* dfg/DFGOperations.cpp:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSString.h:
(JSC::JSString::isRope const):
* runtime/Operations.cpp:
(JSC::jsAddSlowCase):
* runtime/Operations.h:
(JSC::jsString):
(JSC::jsAddNonNumber):
(JSC::jsAdd):
2019-02-13 Saam Barati <sbarati@apple.com>
AirIRGenerator::addSwitch switch patchpoint needs to model clobbering the scratch register
https://bugs.webkit.org/show_bug.cgi?id=194610
Reviewed by Michael Saboff.
BinarySwitch might use the scratch register. We must model the
effects of that properly. This is already caught by our br-table
tests on arm64.
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::addSwitch):
2019-02-13 Mark Lam <mark.lam@apple.com>
Create a randomized free list for new StructureIDs on StructureIDTable resize.
https://bugs.webkit.org/show_bug.cgi?id=194566
<rdar://problem/47975502>
Reviewed by Michael Saboff.
Also isolate 32-bit implementation of StructureIDTable out more so the 64-bit
implementation is a little easier to read.
This patch appears to be perf neutral on JetStream2 (as run from the command line).
* runtime/StructureIDTable.cpp:
(JSC::StructureIDTable::StructureIDTable):
(JSC::StructureIDTable::makeFreeListFromRange):
(JSC::StructureIDTable::resize):
(JSC::StructureIDTable::allocateID):
(JSC::StructureIDTable::deallocateID):
* runtime/StructureIDTable.h:
(JSC::StructureIDTable::get):
(JSC::StructureIDTable::deallocateID):
(JSC::StructureIDTable::allocateID):
(JSC::StructureIDTable::flushOldTables):
2019-02-13 Tadeu Zagallo <tzagallo@apple.com>
VariableLengthObject::allocate<T> should initialize objects
https://bugs.webkit.org/show_bug.cgi?id=194534
Reviewed by Michael Saboff.
`buffer()` should not be called for empty VariableLengthObjects, but
these cases were not being caught due to the objects not being properly
initialized. Fix it so that allocate calls the constructor and fix the
assertion failues.
* runtime/CachedTypes.cpp:
(JSC::CachedObject::operator new):
(JSC::VariableLengthObject::allocate):
(JSC::CachedVector::encode):
(JSC::CachedVector::decode const):
(JSC::CachedUniquedStringImpl::decode const):
(JSC::CachedBitVector::encode):
(JSC::CachedBitVector::decode const):
(JSC::CachedArray::encode):
(JSC::CachedArray::decode const):
(JSC::CachedImmutableButterfly::CachedImmutableButterfly):
(JSC::CachedBigInt::decode const):
2019-02-13 Tadeu Zagallo <tzagallo@apple.com>
CodeBlocks read from disk should not be re-written
https://bugs.webkit.org/show_bug.cgi?id=194535
Reviewed by Michael Saboff.
Keep track of which CodeBlocks have been read from disk or have already
been serialized in CodeCache.
* runtime/CodeCache.cpp:
(JSC::CodeCache::write):
* runtime/CodeCache.h:
(JSC::SourceCodeValue::SourceCodeValue):
(JSC::CodeCacheMap::fetchFromDiskImpl):
2019-02-13 Tadeu Zagallo <tzagallo@apple.com>
SourceCode should be copied when generating bytecode for functions
https://bugs.webkit.org/show_bug.cgi?id=194536
Reviewed by Saam Barati.
The FunctionExecutable might be collected while generating the bytecode
for nested functions, in which case the SourceCode reference would no
longer be valid.
* runtime/CodeCache.cpp:
(JSC::generateUnlinkedCodeBlockForFunctions):
2019-02-12 Saam barati <sbarati@apple.com>
JSScript needs to retain its cache path NSURL*
https://bugs.webkit.org/show_bug.cgi?id=194577
Reviewed by Tim Horton.
* API/JSScript.mm:
(+[JSScript scriptFromASCIIFile:inVirtualMachine:withCodeSigning:andBytecodeCache:]):
(-[JSScript dealloc]):
2019-02-12 Robin Morisset <rmorisset@apple.com>
Make B3Value::returnsBool() more precise
https://bugs.webkit.org/show_bug.cgi?id=194457
Reviewed by Saam Barati.
It is currently used repeatedly in B3ReduceStrength, as well as once in B3LowerToAir.
It has a needlessly complex rule for BitAnd, and has no rule for other easy cases such as BitOr or Select.
No new tests added as this should be indirectly tested by the already existing tests.
* b3/B3Value.cpp:
(JSC::B3::Value::returnsBool const):
2019-02-12 Michael Catanzaro <mcatanzaro@igalia.com>
Unreviewed, fix -Wimplicit-fallthrough warning after r241140
https://bugs.webkit.org/show_bug.cgi?id=194399
<rdar://problem/47889777>
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
2019-02-12 Michael Catanzaro <mcatanzaro@igalia.com>
[WPE][GTK] Unsafe g_unsetenv() use in WebProcessPool::platformInitialize
https://bugs.webkit.org/show_bug.cgi?id=194370
Reviewed by Darin Adler.
Change a couple WTFLogAlways to use g_warning, for good measure. Of course this isn't
necessary, but it will make errors more visible.
* inspector/remote/glib/RemoteInspectorGlib.cpp:
(Inspector::RemoteInspector::start):
(Inspector::dbusConnectionCallAsyncReadyCallback):
* inspector/remote/glib/RemoteInspectorServer.cpp:
(Inspector::RemoteInspectorServer::start):
2019-02-12 Andy Estes <aestes@apple.com>
[iOSMac] Enable Parental Controls Content Filtering
https://bugs.webkit.org/show_bug.cgi?id=194521
<rdar://39732376>
Reviewed by Tim Horton.
* Configurations/FeatureDefines.xcconfig:
2019-02-11 Mark Lam <mark.lam@apple.com>
Randomize insertion of deallocated StructureIDs into the StructureIDTable's free list.
https://bugs.webkit.org/show_bug.cgi?id=194512
<rdar://problem/47975465>
Reviewed by Yusuke Suzuki.
* runtime/StructureIDTable.cpp:
(JSC::StructureIDTable::StructureIDTable):
(JSC::StructureIDTable::allocateID):
(JSC::StructureIDTable::deallocateID):
* runtime/StructureIDTable.h:
2019-02-10 Mark Lam <mark.lam@apple.com>
Remove the RELEASE_ASSERT check for duplicate cases in the BinarySwitch constructor.
https://bugs.webkit.org/show_bug.cgi?id=194493
<rdar://problem/36380852>
Reviewed by Yusuke Suzuki.
Having duplicate cases in the BinarySwitch is not a correctness issue. It is
however not good for performance and memory usage. As such, a debug ASSERT will
do. We'll also do an audit of the clients of BinarySwitch to see if it's
possible to be instantiated with duplicate cases in
https://bugs.webkit.org/show_bug.cgi?id=194492 later.
Also added some value dumps to the RELEASE_ASSERT to help debug the issue when we
see duplicate cases.
* jit/BinarySwitch.cpp:
(JSC::BinarySwitch::BinarySwitch):
2019-02-10 Darin Adler <darin@apple.com>
Switch uses of StringBuilder with String::format for hex numbers to use HexNumber.h instead
https://bugs.webkit.org/show_bug.cgi?id=194485
Reviewed by Daniel Bates.
* heap/HeapSnapshotBuilder.cpp:
(JSC::HeapSnapshotBuilder::json): Use appendUnsignedAsHex along with
reinterpret_cast<uintptr_t> to replace uses of String::format with "%p".
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::encode): Removed some unneeded casts in StringBuilder code,
including one in a call to appendByteAsHex.
(JSC::globalFuncEscape): Ditto.
2019-02-10 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r241230.
https://bugs.webkit.org/show_bug.cgi?id=194488
"It regressed JetStream2 by ~6%" (Requested by saamyjoon on
#webkit).
Reverted changeset:
"We should only make rope strings when concatenating strings
long enough."
https://bugs.webkit.org/show_bug.cgi?id=194465
https://trac.webkit.org/changeset/241230
2019-02-10 Saam barati <sbarati@apple.com>
BBQ-Air: Emit better code for switch
https://bugs.webkit.org/show_bug.cgi?id=194053
Reviewed by Yusuke Suzuki.
Instead of emitting a linear set of jumps for Switch, this patch
makes the BBQ-Air backend emit a binary switch.
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::addSwitch):
2019-02-09 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, Lexer should use isLatin1 implementation in WTF
https://bugs.webkit.org/show_bug.cgi?id=194466
Follow-up after r241233 pointed by Darin.
* parser/Lexer.cpp:
(JSC::isLatin1): Deleted.
2019-02-09 Darin Adler <darin@apple.com>
Eliminate unnecessary String temporaries by using StringConcatenateNumbers
https://bugs.webkit.org/show_bug.cgi?id=194021
Reviewed by Geoffrey Garen.
* inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::count): Remove String::number and let
makeString do the conversion without allocating/destroying a String.
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::objectGroupForBreakpointAction): Ditto.
(Inspector::InspectorDebuggerAgent::setBreakpointByUrl): Ditto.
(Inspector::InspectorDebuggerAgent::setBreakpoint): Ditto.
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty): Ditto.
* runtime/NumberPrototype.cpp:
(JSC::numberProtoFuncToFixed): Use String::numberToStringFixedWidth instead
of calling numberToFixedWidthString to do the same thing.
(JSC::numberProtoFuncToPrecision): Use String::number instead of calling
numberToFixedPrecisionString to do the same thing.
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::reportTopFunctions): Ditto.
2019-02-09 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, rolling in r241237 again
https://bugs.webkit.org/show_bug.cgi?id=194469
* runtime/JSString.h:
(JSC::jsSubstring):
2019-02-09 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r241237.
https://bugs.webkit.org/show_bug.cgi?id=194474
Shows significant memory increase in WSL (Requested by
yusukesuzuki on #webkit).
Reverted changeset:
"[WTF] Use BufferInternal StringImpl if substring StringImpl
takes more memory"
https://bugs.webkit.org/show_bug.cgi?id=194469
https://trac.webkit.org/changeset/241237
2019-02-08 Yusuke Suzuki <ysuzuki@apple.com>
[WTF] Use BufferInternal StringImpl if substring StringImpl takes more memory
https://bugs.webkit.org/show_bug.cgi?id=194469
Reviewed by Geoffrey Garen.
* runtime/JSString.h:
(JSC::jsSubstring):
2019-02-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] CachedTypes should use jsString instead of JSString::create
https://bugs.webkit.org/show_bug.cgi?id=194471
Reviewed by Mark Lam.
Use jsString() here because JSString::create is a bit low-level API and it requires some invariant like "length is not zero".
* runtime/CachedTypes.cpp:
(JSC::CachedJSValue::decode const):
2019-02-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Increase StructureIDTable initial capacity
https://bugs.webkit.org/show_bug.cgi?id=194468
Reviewed by Mark Lam.
Currently, # of structures just after initializing JSGlobalObject (precisely, initializing GlobalObject in
JSC shell), 281, already exceeds the current initial value 256. We should increase the capacity since
unnecessary resizing requires more operations, keeps old StructureID array until GC happens, and makes
more memory dirty. We also remove some structures that are no longer used.
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::callbackObjectStructure const):
(JSC::JSGlobalObject::propertyNameIteratorStructure const): Deleted.
* runtime/StructureIDTable.h:
* runtime/VM.h:
2019-02-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] String.fromCharCode's slow path always generates 16bit string
https://bugs.webkit.org/show_bug.cgi?id=194466
Reviewed by Keith Miller.
String.fromCharCode(a1) has a fast path and the most frequently used. And String.fromCharCode(a1, a2, ...)
goes to the slow path. However, in the slow path, we always create 16bit string. 16bit string takes 2x memory,
and even worse, taints ropes 16bit if 16bit string is included in the given rope. We find that acorn-wtb
creates very large strings multiple times with String.fromCharCode, and String.fromCharCode always produces
16bit string. However, only few strings are actually 16bit strings. This patch attempts to make 8bit string
as much as possible.
It improves non JIT acorn-wtb's peak and current memory footprint by 6% and 3% respectively.
* runtime/StringConstructor.cpp:
(JSC::stringFromCharCode):
2019-02-08 Keith Miller <keith_miller@apple.com>
We should only make rope strings when concatenating strings long enough.
https://bugs.webkit.org/show_bug.cgi?id=194465
Reviewed by Saam Barati.
This patch stops us from allocating a rope string if the resulting
rope would be smaller than the size of the JSRopeString object we
would need to allocate.
This patch also adds paths so that we don't unnecessarily allocate
JSString cells for primitives we are going to concatenate with a
string anyway.
* dfg/DFGOperations.cpp:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSString.h:
* runtime/Operations.cpp:
(JSC::jsAddSlowCase):
* runtime/Operations.h:
(JSC::jsString):
(JSC::jsAdd):
2019-02-08 Saam barati <sbarati@apple.com>
Nodes that rely on being dominated by CheckInBounds should have a child edge to it
https://bugs.webkit.org/show_bug.cgi?id=194334
<rdar://problem/47844327>
Reviewed by Mark Lam.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::convertToHasIndexedProperty):
* dfg/DFGIntegerCheckCombiningPhase.cpp:
(JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
* dfg/DFGNodeType.h:
* dfg/DFGSSALoweringPhase.cpp:
(JSC::DFG::SSALoweringPhase::lowerBoundsCheck):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileHasIndexedProperty):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCheckInBounds):
(JSC::FTL::DFG::LowerDFGToB3::compileHasIndexedProperty):
2019-02-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Shrink sizeof(CodeBlock) more
https://bugs.webkit.org/show_bug.cgi?id=194419
Reviewed by Mark Lam.
This patch further shrinks the size of CodeBlock, from 352 to 296 (304).
1. CodeBlock copies so many data from ScriptExecutable even if ScriptExecutable
has the same information. These data is not touched in CodeBlock::~CodeBlock,
so we can just use the data in ScriptExecutable instead of holding it in CodeBlock.
2. We remove m_instructions pointer since the ownership is managed by UnlinkedCodeBlock.
And we do not touch it in CodeBlock::~CodeBlock.
3. We move m_calleeSaveRegisters from CodeBlock to CodeBlock::JITData. For baseline and LLInt
cases, this patch offers RegisterAtOffsetList::llintBaselineCalleeSaveRegisters() which returns
singleton to `const RegisterAtOffsetList*` usable for LLInt and Baseline JIT CodeBlocks.
4. Move m_catchProfiles to RareData and materialize only when op_catch's slow path is called.
5. Drop ownerScriptExecutable. ownerExecutable() returns ScriptExecutable*.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::hash const):
(JSC::CodeBlock::sourceCodeForTools const):
(JSC::CodeBlock::dumpAssumingJITType const):
(JSC::CodeBlock::dumpSource):
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::finalizeLLIntInlineCaches):
(JSC::CodeBlock::setCalleeSaveRegisters):
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffset):
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
(JSC::CodeBlock::lineNumberForBytecodeOffset):
(JSC::CodeBlock::expressionRangeForBytecodeOffset const):
(JSC::CodeBlock::hasOpDebugForLineAndColumn):
(JSC::CodeBlock::newReplacement):
(JSC::CodeBlock::replacement):
(JSC::CodeBlock::computeCapabilityLevel):
(JSC::CodeBlock::jettison):
(JSC::CodeBlock::calleeSaveRegisters const):
(JSC::CodeBlock::calleeSaveSpaceAsVirtualRegisters):
(JSC::CodeBlock::updateOSRExitCounterAndCheckIfNeedToReoptimize):
(JSC::CodeBlock::getArrayProfile):
(JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
(JSC::CodeBlock::notifyLexicalBindingUpdate):
(JSC::CodeBlock::tryGetValueProfileForBytecodeOffset):
(JSC::CodeBlock::validate):
(JSC::CodeBlock::outOfLineJumpTarget):
(JSC::CodeBlock::arithProfileForBytecodeOffset):
(JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::specializationKind const):
(JSC::CodeBlock::isStrictMode const):
(JSC::CodeBlock::isConstructor const):
(JSC::CodeBlock::codeType const):
(JSC::CodeBlock::isKnownNotImmediate):
(JSC::CodeBlock::instructions const):
(JSC::CodeBlock::ownerExecutable const):
(JSC::CodeBlock::thisRegister const):
(JSC::CodeBlock::source const):
(JSC::CodeBlock::sourceOffset const):
(JSC::CodeBlock::firstLineColumnOffset const):
(JSC::CodeBlock::createRareDataIfNecessary):
(JSC::CodeBlock::ownerScriptExecutable const): Deleted.
(JSC::CodeBlock::setThisRegister): Deleted.
(JSC::CodeBlock::calleeSaveRegisters const): Deleted.
* bytecode/EvalCodeBlock.h:
* bytecode/FunctionCodeBlock.h:
* bytecode/GlobalCodeBlock.h:
(JSC::GlobalCodeBlock::GlobalCodeBlock):
* bytecode/ModuleProgramCodeBlock.h:
* bytecode/ProgramCodeBlock.h:
* debugger/Debugger.cpp:
(JSC::Debugger::toggleBreakpoint):
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::sourceID const):
(JSC::DebuggerCallFrame::sourceIDForCallFrame):
* debugger/DebuggerScope.cpp:
(JSC::DebuggerScope::location const):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::InlineStackEntry::executable):
(JSC::DFG::ByteCodeParser::inliningCost):
(JSC::DFG::ByteCodeParser::parseCodeBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::isSupportedForInlining):
(JSC::DFG::mightCompileEval):
(JSC::DFG::mightCompileProgram):
(JSC::DFG::mightCompileFunctionForCall):
(JSC::DFG::mightCompileFunctionForConstruct):
(JSC::DFG::canUseOSRExitFuzzing):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::executableFor):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compileFunction):
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareOSREntry):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::restoreCalleeSavesFor):
(JSC::DFG::saveCalleeSavesFor):
(JSC::DFG::saveOrCopyCalleeSavesFor):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::handleExitCounts):
* dfg/DFGOperations.cpp:
* dfg/DFGToFTLDeferredCompilationCallback.cpp:
(JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidComplete):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* interpreter/CallFrame.cpp:
(JSC::CallFrame::callerSourceOrigin):
* interpreter/Interpreter.cpp:
(JSC::eval):
(JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::calleeSaveRegisters):
(JSC::StackVisitor::Frame::sourceURL const):
(JSC::StackVisitor::Frame::sourceID):
(JSC::StackVisitor::Frame::computeLineAndColumn const):
* interpreter/StackVisitor.h:
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitSaveCalleeSavesFor):
(JSC::AssemblyHelpers::emitSaveOrCopyCalleeSavesFor):
(JSC::AssemblyHelpers::emitRestoreCalleeSavesFor):
* jit/CallFrameShuffleData.cpp:
(JSC::CallFrameShuffleData::setupCalleeSaveRegisters):
* jit/JIT.cpp:
(JSC::JIT::compileWithoutLinking):
* jit/JITToDFGDeferredCompilationCallback.cpp:
(JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
* jit/JITWorklist.cpp:
(JSC::JITWorklist::Plan::finalize):
(JSC::JITWorklist::compileNow):
* jit/RegisterAtOffsetList.cpp:
(JSC::RegisterAtOffsetList::llintBaselineCalleeSaveRegisters):
* jit/RegisterAtOffsetList.h:
(JSC::RegisterAtOffsetList::at const):
* runtime/ErrorInstance.cpp:
(JSC::appendSourceToError):
* runtime/ScriptExecutable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
* runtime/StackFrame.cpp:
(JSC::StackFrame::sourceID const):
(JSC::StackFrame::sourceURL const):
(JSC::StackFrame::computeLineAndColumn const):
2019-02-08 Robin Morisset <rmorisset@apple.com>
B3LowerMacros wrongly sets m_changed to true in the case of AtomicWeakCAS on x86
https://bugs.webkit.org/show_bug.cgi?id=194460
Reviewed by Mark Lam.
Trivial fix, should already be covered by testAtomicWeakCAS in testb3.cpp.
* b3/B3LowerMacros.cpp:
2019-02-08 Mark Lam <mark.lam@apple.com>
Use maxSingleCharacterString in comparisons instead of literal constants.
https://bugs.webkit.org/show_bug.cgi?id=194452
Reviewed by Yusuke Suzuki.
This way, if we ever change maxSingleCharacterString, it won't break all this code
that relies on it being 0xff implicitly.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileStringSlice):
(JSC::DFG::SpeculativeJIT::compileGetByValOnString):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
(JSC::FTL::DFG::LowerDFGToB3::compileStringSlice):
* jit/ThunkGenerators.cpp:
(JSC::stringGetByValGenerator):
(JSC::charToString):
2019-02-08 Mark Lam <mark.lam@apple.com>
Fix DFG's doesGC() for CheckTierUp*, GetByVal, PutByVal*, and StringCharAt nodes.
https://bugs.webkit.org/show_bug.cgi?id=194446
<rdar://problem/47926792>
Reviewed by Saam Barati.
Fix doesGC() for the following nodes:
CheckTierUpAtReturn:
Calls triggerTierUpNow(), which calls triggerFTLReplacementCompile(),
which calls Worklist::completeAllReadyPlansForVM(), which uses DeferGC.
CheckTierUpInLoop:
Calls triggerTierUpNowInLoop(), which calls tierUpCommon(), which calls
Worklist::completeAllReadyPlansForVM(), which uses DeferGC.
CheckTierUpAndOSREnter:
Calls triggerOSREntryNow(), which calls tierUpCommon(), which calls
Worklist::completeAllReadyPlansForVM(), which uses DeferGC.
GetByVal:
case Array::String calls operationSingleCharacterString(), which calls
jsSingleCharacterString(), which can allocate a string.
PutByValDirect:
PutByVal:
PutByValAlias:
For the DFG only, the integer TypeArrays calls compilePutByValForIntTypedArray(),
which may call slow paths operationPutByValDirectStrict(), operationPutByValDirectNonStrict(),
operationPutByValStrict(), or operationPutByValNonStrict(). All of these
slow paths call putByValInternal(), which may create exception objects, or
call the generic JSValue::put() which may execute arbitrary code.
StringCharAt:
Can call operationSingleCharacterString(), which calls jsSingleCharacterString(),
which can allocate a string.
Also fix DFG::SpeculativeJIT::compileGetByValOnString() and FTL's compileStringCharAt()
to use the maxSingleCharacterString constant instead of a literal constant.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByValOnString):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
2019-02-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] SourceProviderCacheItem should be small
https://bugs.webkit.org/show_bug.cgi?id=194432
Reviewed by Saam Barati.
Some JetStream2 tests stress the JS parser. At that time, so many SourceProviderCacheItems are created.
While they are removed when full-GC happens, it significantly increases the peak memory usage.
This patch reduces the size of SourceProviderCacheItem from 56 to 32.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionInfo):
* parser/ParserModes.h:
* parser/ParserTokens.h:
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::endFunctionToken const):
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
2019-02-07 Robin Morisset <rmorisset@apple.com>
Fix Abs(Neg(x)) -> Abs(x) optimization in B3ReduceStrength
https://bugs.webkit.org/show_bug.cgi?id=194420
Reviewed by Saam Barati.
In https://bugs.webkit.org/show_bug.cgi?id=194250, I added an optimization: Abs(Neg(x)) -> Abs(x).
But I introduced two bugs, one is that I actually implemented Abs(Neg(x)) -> x, and the other is that the test is looking at Abs(Abs(x)) instead (both were stupid copy-paste mistakes).
This trivial patch fixes both.
* b3/B3ReduceStrength.cpp:
* b3/testb3.cpp:
(JSC::B3::testAbsNegArg):
2019-02-07 Keith Miller <keith_miller@apple.com>
Better error messages for module loader SPI
https://bugs.webkit.org/show_bug.cgi?id=194421
Reviewed by Saam Barati.
* API/JSAPIGlobalObject.mm:
(JSC::JSAPIGlobalObject::moduleLoaderImportModule):
2019-02-07 Mark Lam <mark.lam@apple.com>
Fix more doesGC() for CheckTraps, GetMapBucket, and Switch nodes.
https://bugs.webkit.org/show_bug.cgi?id=194399
<rdar://problem/47889777>
Reviewed by Yusuke Suzuki.
Fix doesGC() for the following nodes:
CheckTraps:
We normally will not emit this node because Options::usePollingTraps() is
false by default. However, as it is implemented now, CheckTraps can GC
because it can allocate a TerminatedExecutionException. If we make the
TerminatedExecutionException a singleton allocated at initialization time,
doesGC() can return false for CheckTraps.
https://bugs.webkit.org/show_bug.cgi?id=194323
GetMapBucket:
Can call operationJSMapFindBucket() or operationJSSetFindBucket(),
which calls HashMapImpl::findBucket(), which calls jsMapHash(), which
can resolve a rope.
Switch:
If switchData kind is SwitchChar, can call operationResolveRope() .
If switchData kind is SwitchString and the child use kind is not StringIdentUse,
can call operationSwitchString() which resolves ropes.
DirectTailCall:
ForceOSRExit:
Return:
TailCallForwardVarargs:
TailCallVarargs:
Throw:
These are terminal nodes. It shouldn't really matter what doesGC() returns
for them, but following our conservative practice, unless we have a good
reason for doesGC() to return false, we should just return true.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
2019-02-07 Robin Morisset <rmorisset@apple.com>
B3ReduceStrength: missing peephole optimizations for Neg and Sub
https://bugs.webkit.org/show_bug.cgi?id=194250
Reviewed by Saam Barati.
Adds the following optimizations for integers:
- Sub(x, x) => 0
Already covered by the test testSubArg
- Sub(x1, Neg(x2)) => Add (x1, x2)
Added test: testSubNeg
- Neg(Sub(x1, x2)) => Sub(x2, x1)
Added test: testNegSub
- Add(Neg(x1), x2) => Sub(x2, x1)
Added test: testAddNeg1
- Add(x1, Neg(x2)) => Sub(x1, x2)
Added test: testAddNeg2
Adds the following optimization for floating point values:
- Abs(Neg(x)) => Abs(x)
Added test: testAbsNegArg
Adds the following optimization:
Also did some trivial refactoring, using m_value->isInteger() everywhere instead of isInt(m_value->type()), and using replaceWithNew<Value> instead of replaceWithNewValue(m_proc.add<Value(..))
* b3/B3ReduceStrength.cpp:
* b3/testb3.cpp:
(JSC::B3::testAddNeg1):
(JSC::B3::testAddNeg2):
(JSC::B3::testSubNeg):
(JSC::B3::testNegSub):
(JSC::B3::testAbsAbsArg):
(JSC::B3::testAbsNegArg):
(JSC::B3::run):
2019-02-06 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use BufferInternal single character StringImpl for SmallStrings
https://bugs.webkit.org/show_bug.cgi?id=194374
Reviewed by Geoffrey Garen.
Currently, we first create a large StringImpl, and create bunch of substrings with length = 1.
But pointer is larger than single character. BufferInternal StringImpl with single character
is more memory efficient.
* runtime/SmallStrings.cpp:
(JSC::SmallStringsStorage::SmallStringsStorage):
(JSC::SmallStrings::SmallStrings):
* runtime/SmallStrings.h:
2019-02-06 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] InitializeEntrypointArguments should produce SpecCellCheck if FlushFormat is FlushedCell
https://bugs.webkit.org/show_bug.cgi?id=194369
<rdar://problem/47813087>
Reviewed by Saam Barati.
InitializeEntrypointArguments says SpecCell if the FlushFormat is FlushedCell. But this actually has
JSEmpty if it is TDZ. This incorrectly proved type information removes necessary CheckNotEmpty in
constant folding phase.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2019-02-06 Devin Rousso <drousso@apple.com>
Web Inspector: DOM: don't send the entire function string with each event listener
https://bugs.webkit.org/show_bug.cgi?id=194293
<rdar://problem/47822809>
Reviewed by Joseph Pecoraro.
* inspector/protocol/DOM.json:
* runtime/JSFunction.h:
Export `calculatedDisplayName`.
2019-02-06 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] PrivateName to PublicName hash table is wasteful
https://bugs.webkit.org/show_bug.cgi?id=194277
Reviewed by Michael Saboff.
PrivateNames account for a lot of memory in the initial JSC footprint. BuiltinNames have Identifier fields corresponding to these PrivateNames
which makes the sizeof(BuiltinNames) about 6KB. It also maintains hash tables for "PublicName to PrivateName" and "PrivateName to PublicName",
each of which takes 16KB memory. While "PublicName to PrivateName" functionality is used in builtin JS (parsing "@xxx" and get a private
name for "xxx"), "PrivateName to PublicName" is rarely used. Holding 16KB hash table for rarely used feature is costly.
In this patch, we add some rules to remove "PrivateName to PublicName" hash table.
1. PrivateName's content should be the same to PublicName.
2. If PrivateName is not actually a private name (we introduced hacky mapping like "@iteratorSymbol" => Symbol.iterator),
the public name should be easily crafted from the given PrivateName.
We modify the content of private names to ensure (1). And for (2), we can meet this requirement by ensuring that the "@xxxSymbol"
is converted to "Symbol.xxx". (1) and (2) allow us to convert a private name to a public name without a large hash table.
We also remove unused identifiers in CommonIdentifiers. And we also move some of them to WebCore's WebCoreBuiltinNames if it is only used in
WebCore.
* builtins/BuiltinNames.cpp:
(JSC::BuiltinNames::BuiltinNames):
* builtins/BuiltinNames.h:
(JSC::BuiltinNames::lookUpPrivateName const):
(JSC::BuiltinNames::getPublicName const):
(JSC::BuiltinNames::checkPublicToPrivateMapConsistency):
(JSC::BuiltinNames::appendExternalName):
(JSC::BuiltinNames::lookUpPublicName const): Deleted.
* builtins/BuiltinUtils.h:
* bytecode/BytecodeDumper.cpp:
(JSC::BytecodeDumper<Block>::dumpIdentifiers):
* bytecompiler/NodesCodegen.cpp:
(JSC::BytecodeIntrinsicNode::emit_intrinsic_getByIdDirectPrivate):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_putByIdDirectPrivate):
* parser/Lexer.cpp:
(JSC::Lexer<LChar>::parseIdentifier):
(JSC::Lexer<UChar>::parseIdentifier):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::createGeneratorParameters):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
(JSC::Parser<LexerType>::parseClassDeclaration):
(JSC::Parser<LexerType>::parseExportDeclaration):
(JSC::Parser<LexerType>::parseMemberExpression):
* parser/ParserArena.h:
(JSC::IdentifierArena::makeIdentifier):
* runtime/CachedTypes.cpp:
(JSC::CachedUniquedStringImpl::encode):
(JSC::CachedUniquedStringImpl::decode const):
* runtime/CommonIdentifiers.cpp:
(JSC::CommonIdentifiers::CommonIdentifiers):
(JSC::CommonIdentifiers::lookUpPrivateName const):
(JSC::CommonIdentifiers::getPublicName const):
(JSC::CommonIdentifiers::lookUpPublicName const): Deleted.
* runtime/CommonIdentifiers.h:
* runtime/ExceptionHelpers.cpp:
(JSC::createUndefinedVariableError):
* runtime/Identifier.cpp:
(JSC::Identifier::dump const):
* runtime/Identifier.h:
* runtime/IdentifierInlines.h:
(JSC::Identifier::fromUid):
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::JSTypedArrayViewPrototype::finishCreation):
* tools/JSDollarVM.cpp:
(JSC::functionGetPrivateProperty):
2019-02-06 Keith Rollin <krollin@apple.com>
Really enable the automatic checking and regenerations of .xcfilelists during builds
https://bugs.webkit.org/show_bug.cgi?id=194357
<rdar://problem/47861231>
Reviewed by Chris Dumez.
Bug 194124 was supposed to enable the automatic checking and
regenerating of .xcfilelist files during the build. While related
changes were included in that patch, the change to actually enable the
operation somehow was omitted. This patch actually enables the
operation. The check-xcfilelist.sh scripts now check
WK_DISABLE_CHECK_XCFILELISTS, and if it's "1", opts-out the developer
from the checking.
* Scripts/check-xcfilelists.sh:
2019-02-06 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Unify indirectEvalExecutableSpace and directEvalExecutableSpace
https://bugs.webkit.org/show_bug.cgi?id=194339
Reviewed by Michael Saboff.
DirectEvalExecutable and IndirectEvalExecutable have completely same memory layout.
They have even the same structure. This patch unifies the subspaces for them.
* runtime/DirectEvalExecutable.h:
* runtime/EvalExecutable.h:
(JSC::EvalExecutable::subspaceFor):
* runtime/IndirectEvalExecutable.h:
* runtime/VM.cpp:
* runtime/VM.h:
(JSC::VM::forEachScriptExecutableSpace):
2019-02-06 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] NativeExecutable should be smaller
https://bugs.webkit.org/show_bug.cgi?id=194331
Reviewed by Michael Saboff.
NativeExecutable takes 88 bytes now. Since our GC rounds the size with 16, it actually takes 96 bytes in IsoSubspaces.
Since a lot of NativeExecutable are allocated, we already has two MarkedBlocks even just after JSGlobalObject initialization.
This patch makes sizeof(NativeExecutable) 64 bytes, which is 32 bytes smaller than 96 bytes. Now our JSGlobalObject initialization
only takes one MarkedBlock for NativeExecutable.
To make NativeExecutable smaller,
1. m_numParametersForCall and m_numParametersForConstruct in ExecutableBase are only meaningful in ScriptExecutable subclasses. Since
they are not touched from JIT, we can remove them from ExecutableBase and move them to ScriptExecutable.
2. DOMJIT::Signature* is rarely used. Rather than having it in NativeExecutable, we should put it in NativeJITCode. Since NativeExecutable
always has JITCode, we can safely query the value from NativeExecutable. This patch creates NativeDOMJITCode, which is a subclass of
NativeJITCode, and instantiated only when DOMJIT::Signature* is given.
3. Move Intrinsic to a member of ScriptExecutable or JITCode. Since JITCode has some paddings to put things, we can leverage this to put
Intrinsic for NativeExecutable.
We also move "clearCode" code from ExecutableBase to ScriptExecutable since it is only valid for ScriptExecutable subclasses.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CallVariant.h:
* interpreter/Interpreter.cpp:
* jit/JITCode.cpp:
(JSC::DirectJITCode::DirectJITCode):
(JSC::NativeJITCode::NativeJITCode):
(JSC::NativeDOMJITCode::NativeDOMJITCode):
* jit/JITCode.h:
(JSC::JITCode::signature const):
(JSC::JITCode::intrinsic):
* jit/JITOperations.cpp:
* jit/JITThunks.cpp:
(JSC::JITThunks::hostFunctionStub):
* jit/Repatch.cpp:
* llint/LLIntSlowPaths.cpp:
* runtime/ExecutableBase.cpp:
(JSC::ExecutableBase::dump const):
(JSC::ExecutableBase::hashFor const):
(JSC::ExecutableBase::hasClearableCode const): Deleted.
(JSC::ExecutableBase::clearCode): Deleted.
* runtime/ExecutableBase.h:
(JSC::ExecutableBase::ExecutableBase):
(JSC::ExecutableBase::isModuleProgramExecutable):
(JSC::ExecutableBase::isHostFunction const):
(JSC::ExecutableBase::generatedJITCodeForCall const):
(JSC::ExecutableBase::generatedJITCodeForConstruct const):
(JSC::ExecutableBase::generatedJITCodeFor const):
(JSC::ExecutableBase::generatedJITCodeForCall): Deleted.
(JSC::ExecutableBase::generatedJITCodeForConstruct): Deleted.
(JSC::ExecutableBase::generatedJITCodeFor): Deleted.
(JSC::ExecutableBase::offsetOfNumParametersFor): Deleted.
(JSC::ExecutableBase::hasJITCodeForCall const): Deleted.
(JSC::ExecutableBase::hasJITCodeForConstruct const): Deleted.
(JSC::ExecutableBase::intrinsic const): Deleted.
* runtime/ExecutableBaseInlines.h: Added.
(JSC::ExecutableBase::intrinsic const):
(JSC::ExecutableBase::hasJITCodeForCall const):
(JSC::ExecutableBase::hasJITCodeForConstruct const):
* runtime/JSBoundFunction.cpp:
* runtime/JSType.cpp:
(WTF::printInternal):
* runtime/JSType.h:
* runtime/NativeExecutable.cpp:
(JSC::NativeExecutable::create):
(JSC::NativeExecutable::createStructure):
(JSC::NativeExecutable::NativeExecutable):
(JSC::NativeExecutable::signatureFor const):
(JSC::NativeExecutable::intrinsic const):
* runtime/NativeExecutable.h:
* runtime/ScriptExecutable.cpp:
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::clearCode):
(JSC::ScriptExecutable::installCode):
(JSC::ScriptExecutable::hasClearableCode const):
* runtime/ScriptExecutable.h:
(JSC::ScriptExecutable::intrinsic const):
(JSC::ScriptExecutable::hasJITCodeForCall const):
(JSC::ScriptExecutable::hasJITCodeForConstruct const):
* runtime/VM.cpp:
(JSC::VM::getHostFunction):
2019-02-06 Pablo Saavedra <psaavedra@igalia.com>
Build failure after r240431
https://bugs.webkit.org/show_bug.cgi?id=194330
Reviewed by Žan Doberšek.
* API/glib/JSCOptions.cpp:
2019-02-05 Mark Lam <mark.lam@apple.com>
Fix DFG's doesGC() for a few more nodes.
https://bugs.webkit.org/show_bug.cgi?id=194307
<rdar://problem/47832956>
Reviewed by Yusuke Suzuki.
Fix doesGC() for the following nodes:
NumberToStringWithValidRadixConstant:
Calls operationInt32ToStringWithValidRadix(), which calls int32ToString(),
which can allocate a string.
Calls operationInt52ToStringWithValidRadix(), which calls int52ToString(),
which can allocate a string.
Calls operationDoubleToStringWithValidRadix(), which calls numberToString(),
which can allocate a string.
RegExpExecNonGlobalOrSticky: calls createRegExpMatchesArray() which allocates
memory for all kinds of objects.
RegExpMatchFast: calls operationRegExpMatchFastString(), which calls
RegExpObject::execInline() and RegExpObject::matchGlobal(). Both of
these allocates memory for the match result.
RegExpMatchFastGlobal: calls operationRegExpMatchFastGlobalString(), which
calls RegExpObject's collectMatches(), which allocates an array amongst
other objects.
StringFromCharCode:
If the uint32 code to convert is greater than maxSingleCharacterString,
we'll call operationStringFromCharCode(), which calls jsSingleCharacterString(),
which allocates a new string if the code is greater than maxSingleCharacterString.
Also fix SpeculativeJIT::compileFromCharCode() and FTL's compileStringFromCharCode()
to use maxSingleCharacterString instead of a literal constant.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileFromCharCode):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):
2019-02-05 Keith Rollin <krollin@apple.com>
Enable the automatic checking and regenerations of .xcfilelists during builds
https://bugs.webkit.org/show_bug.cgi?id=194124
<rdar://problem/47721277>
Reviewed by Tim Horton.
Bug 193790 add a facility for checking -- during build time -- that
any needed .xcfilelist files are up-to-date and for updating them if
they are not. This facility was initially opt-in by setting
WK_ENABLE_CHECK_XCFILELISTS until other pieces were in place and until
the process seemed robust. Its now time to enable this facility and
make it opt-out. If there is a need to disable this facility, set and
export WK_DISABLE_CHECK_XCFILELISTS=1 in your environment before
running `make` or `build-webkit`, or before running Xcode from the
command line.
Additionally, remove the step that generates a list of source files
going into the UnifiedSources build step. It's only necessarily to
specify Sources.txt and SourcesCocoa.txt as inputs.
* JavaScriptCore.xcodeproj/project.pbxproj:
* UnifiedSources-input.xcfilelist: Removed.
2019-02-05 Keith Rollin <krollin@apple.com>
Update .xcfilelist files
https://bugs.webkit.org/show_bug.cgi?id=194121
<rdar://problem/47720863>
Reviewed by Tim Horton.
Preparatory to enabling the facility for automatically updating the
.xcfilelist files, check in a freshly-updated set so that not everyone
runs up against having to regenerate them themselves.
* DerivedSources-input.xcfilelist:
* DerivedSources-output.xcfilelist:
2019-02-05 Andy VanWagoner <andy@vanwagoner.family>
[INTL] improve efficiency of Intl.NumberFormat formatToParts
https://bugs.webkit.org/show_bug.cgi?id=185557
Reviewed by Mark Lam.
Since field nesting depth is minimal, this algorithm should be effectively O(n),
where n is the number of characters in the formatted string.
It may be less memory efficient than the previous impl, since the intermediate Vector
is the length of the string, instead of the count of the fields.
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::formatToParts):
* runtime/IntlNumberFormat.h:
2019-02-05 Mark Lam <mark.lam@apple.com>
Move DFG nodes that clobberize() says will write(Heap) to the doesGC() list that returns true.
https://bugs.webkit.org/show_bug.cgi?id=194298
<rdar://problem/47827555>
Reviewed by Saam Barati.
We do this for 3 reasons:
1. It's clearer when reading doesGC()'s code that these nodes will return true.
2. If things change in the future where clobberize() no longer reports these nodes
as write(Heap), each node should be vetted first to make sure that it can never
GC before being moved back to the doesGC() list that returns false.
3. This reduces the list of nodes that we need to audit to make sure doesGC() is
correct in its claims about the nodes' GCing possibility.
The list of nodes moved are:
ArrayPush
ArrayPop
Call
CallEval
CallForwardVarargs
CallVarargs
Construct
ConstructForwardVarargs
ConstructVarargs
DefineDataProperty
DefineAccessorProperty
DeleteById
DeleteByVal
DirectCall
DirectConstruct
DirectTailCallInlinedCaller
GetById
GetByIdDirect
GetByIdDirectFlush
GetByIdFlush
GetByIdWithThis
GetByValWithThis
GetDirectPname
GetDynamicVar
HasGenericProperty
HasOwnProperty
HasStructureProperty
InById
InByVal
InstanceOf
InstanceOfCustom
LoadVarargs
NumberToStringWithRadix
PutById
PutByIdDirect
PutByIdFlush
PutByIdWithThis
PutByOffset
PutByValWithThis
PutDynamicVar
PutGetterById
PutGetterByVal
PutGetterSetterById
PutSetterById
PutSetterByVal
PutStack
PutToArguments
RegExpExec
RegExpTest
ResolveScope
ResolveScopeForHoistingFuncDeclInEval
TailCall
TailCallForwardVarargsInlinedCaller
TailCallInlinedCaller
TailCallVarargsInlinedCaller
ToNumber
ToPrimitive
ValueNegate
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
2019-02-05 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Shrink sizeof(UnlinkedCodeBlock)
https://bugs.webkit.org/show_bug.cgi?id=194281
Reviewed by Michael Saboff.
This patch first attempts to reduce the size of UnlinkedCodeBlock in a relatively simpler way. Reordering members, remove unused member, and
move rarely used members to RareData. This changes sizeof(UnlinkedCodeBlock) from 312 to 256.
Still we have several chances to reduce sizeof(UnlinkedCodeBlock). Making more Vectors to RefCountedArrays can be done with some restructuring
of generatorification phase. It would be possible to remove m_sourceURLDirective and m_sourceMappingURLDirective from UnlinkedCodeBlock since
they should be in SourceProvider and that should be enough. These changes require some intrusive modifications and we make them as a future work.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::bitVectors const): Deleted.
* bytecode/CodeType.h:
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
(JSC::UnlinkedCodeBlock::shrinkToFit):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::bitVector):
(JSC::UnlinkedCodeBlock::addBitVector):
(JSC::UnlinkedCodeBlock::addSetConstant):
(JSC::UnlinkedCodeBlock::constantRegisters):
(JSC::UnlinkedCodeBlock::numberOfConstantIdentifierSets const):
(JSC::UnlinkedCodeBlock::constantIdentifierSets):
(JSC::UnlinkedCodeBlock::codeType const):
(JSC::UnlinkedCodeBlock::didOptimize const):
(JSC::UnlinkedCodeBlock::setDidOptimize):
(JSC::UnlinkedCodeBlock::usesGlobalObject const): Deleted.
(JSC::UnlinkedCodeBlock::setGlobalObjectRegister): Deleted.
(JSC::UnlinkedCodeBlock::globalObjectRegister const): Deleted.
(JSC::UnlinkedCodeBlock::bitVectors const): Deleted.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitLoad):
(JSC::BytecodeGenerator::emitLoadGlobalObject): Deleted.
* bytecompiler/BytecodeGenerator.h:
* runtime/CachedTypes.cpp:
(JSC::CachedCodeBlockRareData::encode):
(JSC::CachedCodeBlockRareData::decode const):
(JSC::CachedCodeBlock::scopeRegister const):
(JSC::CachedCodeBlock::codeType const):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
(JSC::CachedCodeBlock<CodeBlockType>::decode const):
(JSC::CachedCodeBlock<CodeBlockType>::encode):
(JSC::CachedCodeBlock::globalObjectRegister const): Deleted.
2019-02-04 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, add missing exception checks after r240637
https://bugs.webkit.org/show_bug.cgi?id=193546
* tools/JSDollarVM.cpp:
(JSC::functionShadowChickenFunctionsOnStack):
2019-02-04 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Shrink size of VM by lazily allocating IsoSubspaces for non-common types
https://bugs.webkit.org/show_bug.cgi?id=193993
Reviewed by Keith Miller.
JSC::VM has a lot of IsoSubspaces, and each takes 504B. This unnecessarily makes VM so large.
And some of them are rarely used. We should allocate it lazily.
In this patch, we make some `IsoSubspaces` `std::unique_ptr<IsoSubspace>`. And we add ensureXXXSpace
functions which allocate IsoSubspaces lazily. This function is used by subspaceFor<> in each class.
And we also add subspaceForConcurrently<> function, which is called from concurrent JIT tiers. This
returns nullptr if the subspace is not allocated yet. JSCell::subspaceFor now takes second template
parameter which tells the function whether subspaceFor is concurrently done. If the IsoSubspace is
lazily created, we may return nullptr for the concurrent access. We ensure the space's initialization
by using WTF::storeStoreFence when lazily allocating it.
In GC's constraint solving, we may touch these lazily allocated spaces. At that time, we check the
existence of the space before touching this. This is not racy because the main thread is stopped when
the constraint solving is working.
This changes sizeof(VM) from 64736 to 56472.
Another interesting thing is that we removed `PreventCollectionScope preventCollectionScope(heap);` in
`Subspace::initialize`. This is really dangerous API since it easily causes dead-lock between the
collector and the mutator if IsoSubspace is dynamically created. We do want to make IsoSubspaces
dynamically-created ones since the requirement of the pre-allocation poses a scalability problem
of IsoSubspace adoption because IsoSubspace is large. Registered Subspace is only touched in the
EndPhase, and the peripheries should be stopped when running EndPhase. Thus, as long as the main thread
can run this IsoSubspace code, the collector is never EndPhase. So this is safe.
* API/JSCallbackFunction.h:
* API/ObjCCallbackFunction.h:
(JSC::ObjCCallbackFunction::subspaceFor):
* API/glib/JSCCallbackFunction.h:
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::visitChildren):
(JSC::CodeBlock::finalizeUnconditionally):
* bytecode/CodeBlock.h:
* bytecode/EvalCodeBlock.h:
* bytecode/ExecutableToCodeBlockEdge.h:
* bytecode/FunctionCodeBlock.h:
* bytecode/ModuleProgramCodeBlock.h:
* bytecode/ProgramCodeBlock.h:
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
* bytecode/UnlinkedFunctionExecutable.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
(JSC::DFG::SpeculativeJIT::compileMakeRope):
(JSC::DFG::SpeculativeJIT::compileNewObject):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
(JSC::FTL::DFG::LowerDFGToB3::allocateObject):
(JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject):
(JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedCell):
* heap/Heap.cpp:
(JSC::Heap::finalizeUnconditionalFinalizers):
(JSC::Heap::deleteAllCodeBlocks):
(JSC::Heap::deleteAllUnlinkedCodeBlocks):
(JSC::Heap::addCoreConstraints):
* heap/Subspace.cpp:
(JSC::Subspace::initialize):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize):
(JSC::AssemblyHelpers::emitAllocateVariableSizedCell):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_new_object):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_new_object):
* runtime/DirectArguments.h:
* runtime/DirectEvalExecutable.h:
* runtime/ErrorInstance.h:
(JSC::ErrorInstance::subspaceFor):
* runtime/ExecutableBase.h:
* runtime/FunctionExecutable.h:
* runtime/IndirectEvalExecutable.h:
* runtime/InferredValue.cpp:
(JSC::InferredValue::visitChildren):
* runtime/InferredValue.h:
* runtime/InferredValueInlines.h:
(JSC::InferredValue::finalizeUnconditionally):
* runtime/InternalFunction.h:
* runtime/JSAsyncFunction.h:
* runtime/JSAsyncGeneratorFunction.h:
* runtime/JSBoundFunction.h:
* runtime/JSCell.h:
(JSC::subspaceFor):
(JSC::subspaceForConcurrently):
* runtime/JSCellInlines.h:
(JSC::allocatorForNonVirtualConcurrently):
* runtime/JSCustomGetterSetterFunction.h:
* runtime/JSDestructibleObject.h:
* runtime/JSFunction.h:
* runtime/JSGeneratorFunction.h:
* runtime/JSImmutableButterfly.h:
* runtime/JSLexicalEnvironment.h:
(JSC::JSLexicalEnvironment::subspaceFor):
* runtime/JSNativeStdFunction.h:
* runtime/JSSegmentedVariableObject.h:
* runtime/JSString.h:
* runtime/ModuleProgramExecutable.h:
* runtime/NativeExecutable.h:
* runtime/ProgramExecutable.h:
* runtime/PropertyMapHashTable.h:
* runtime/ProxyRevoke.h:
* runtime/ScopedArguments.h:
* runtime/ScriptExecutable.cpp:
(JSC::ScriptExecutable::clearCode):
(JSC::ScriptExecutable::installCode):
* runtime/Structure.h:
* runtime/StructureRareData.h:
* runtime/SubspaceAccess.h: Copied from Source/JavaScriptCore/runtime/InferredValueInlines.h.
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
(JSC::VM::SpaceAndSet::SpaceAndSet):
(JSC::VM::SpaceAndSet::setFor):
(JSC::VM::forEachScriptExecutableSpace):
(JSC::VM::SpaceAndFinalizerSet::SpaceAndFinalizerSet): Deleted.
(JSC::VM::SpaceAndFinalizerSet::finalizerSetFor): Deleted.
(JSC::VM::ScriptExecutableSpaceAndSet::ScriptExecutableSpaceAndSet): Deleted.
(JSC::VM::ScriptExecutableSpaceAndSet::clearableCodeSetFor): Deleted.
(JSC::VM::UnlinkedFunctionExecutableSpaceAndSet::UnlinkedFunctionExecutableSpaceAndSet): Deleted.
(JSC::VM::UnlinkedFunctionExecutableSpaceAndSet::clearableCodeSetFor): Deleted.
* runtime/WeakMapImpl.h:
(JSC::WeakMapImpl::subspaceFor):
* wasm/js/JSWebAssemblyCodeBlock.h:
* wasm/js/JSWebAssemblyMemory.h:
* wasm/js/WebAssemblyFunction.h:
* wasm/js/WebAssemblyWrapperFunction.h:
2019-02-04 Keith Miller <keith_miller@apple.com>
Change llint operand macros to inline functions
https://bugs.webkit.org/show_bug.cgi?id=194248
Reviewed by Mark Lam.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::getNonConstantOperand):
(JSC::LLInt::getOperand):
(JSC::LLInt::llint_trace_value):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::getByVal):
(JSC::LLInt::genericCall):
(JSC::LLInt::varargsSetup):
(JSC::LLInt::commonCallEval):
2019-02-04 Robin Morisset <rmorisset@apple.com>
when lowering AssertNotEmpty, create the value before creating the patchpoint
https://bugs.webkit.org/show_bug.cgi?id=194231
Reviewed by Saam Barati.
This is a very simple change: we should never generate B3 IR where an instruction depends on a value that comes later in the instruction stream.
AssertNotEmpty was generating some such IR, it probably slipped through until now because it is a rather rare and tricky instruction to generate.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileAssertNotEmpty):
2019-02-04 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] ExecutableToCodeBlockEdge should be smaller
https://bugs.webkit.org/show_bug.cgi?id=194244
Reviewed by Michael Saboff.
ExecutableToCodeBlockEdge is allocated so many times. However its memory layout is not efficient.
sizeof(ExecutableToCodeBlockEdge) is 24bytes, but it discards 7bytes due to one bool m_isActive flag.
Because our size classes are rounded by 16bytes, ExecutableToCodeBlockEdge takes 32bytes. So, half of
it is wasted. We should fit it into 16bytes so that we can efficiently allocate it.
In this patch, we leverages TypeInfoMayBePrototype bit in JSTypeInfo. It is a bit special TypeInfo bit
since this is per-cell bit. We rename this to TypeInfoPerCellBit, and use it as a `m_isActive` mark in
ExecutableToCodeBlockEdge. In JSObject subclasses, we use it as MayBePrototype flag.
Since this flag is not changed in CAS style, we must not change this in concurrent threads. This is OK
for ExecutableToCodeBlockEdge's m_isActive flag since this is touched on the main thread (ScriptExecutable::installCode
does not touch it if it is called in non-main threads).
* bytecode/ExecutableToCodeBlockEdge.cpp:
(JSC::ExecutableToCodeBlockEdge::finishCreation):
(JSC::ExecutableToCodeBlockEdge::visitChildren):
(JSC::ExecutableToCodeBlockEdge::activate):
(JSC::ExecutableToCodeBlockEdge::deactivate):
(JSC::ExecutableToCodeBlockEdge::isActive const):
* bytecode/ExecutableToCodeBlockEdge.h:
* runtime/JSCell.h:
* runtime/JSCellInlines.h:
(JSC::JSCell::perCellBit const):
(JSC::JSCell::setPerCellBit):
(JSC::JSCell::mayBePrototype const): Deleted.
(JSC::JSCell::didBecomePrototype): Deleted.
* runtime/JSObject.cpp:
(JSC::JSObject::setPrototypeDirect):
* runtime/JSObject.h:
* runtime/JSObjectInlines.h:
(JSC::JSObject::mayBePrototype const):
(JSC::JSObject::didBecomePrototype):
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::perCellBit):
(JSC::TypeInfo::mergeInlineTypeFlags):
(JSC::TypeInfo::mayBePrototype): Deleted.
2019-02-04 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Shrink size of FunctionExecutable
https://bugs.webkit.org/show_bug.cgi?id=194191
Reviewed by Michael Saboff.
This patch reduces the size of FunctionExecutable. Since it is allocated in IsoSubspace, reducing the size directly
improves the allocation efficiency.
1. ScriptExecutable (base class of FunctionExecutable) has several members, but it is meaningful only in FunctionExecutable.
We remove this from ScriptExecutable, and move it to FunctionExecutable.
2. FunctionExecutable has several data which are rarely used. One for FunctionOverrides functionality, which is typically
used for JSC debugging purpose, and another is TypeSet and offsets for type profiler. We move them to RareData and reduce
the size of FunctionExecutable in the common case.
This patch changes the size of FunctionExecutable from 176 to 144.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpSource):
(JSC::CodeBlock::finishCreation):
* dfg/DFGNode.h:
(JSC::DFG::Node::OpInfoWrapper::as const):
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::computeLineAndColumn const):
* runtime/ExecutableBase.h:
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::FunctionExecutable::ensureRareDataSlow):
* runtime/FunctionExecutable.h:
* runtime/Intrinsic.h:
* runtime/ModuleProgramExecutable.cpp:
(JSC::ModuleProgramExecutable::ModuleProgramExecutable):
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::ProgramExecutable):
* runtime/ScriptExecutable.cpp:
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::overrideLineNumber const):
(JSC::ScriptExecutable::typeProfilingStartOffset const):
(JSC::ScriptExecutable::typeProfilingEndOffset const):
* runtime/ScriptExecutable.h:
(JSC::ScriptExecutable::firstLine const):
(JSC::ScriptExecutable::setOverrideLineNumber): Deleted.
(JSC::ScriptExecutable::hasOverrideLineNumber const): Deleted.
(JSC::ScriptExecutable::overrideLineNumber const): Deleted.
(JSC::ScriptExecutable::typeProfilingStartOffset const): Deleted.
(JSC::ScriptExecutable::typeProfilingEndOffset const): Deleted.
* runtime/StackFrame.cpp:
(JSC::StackFrame::computeLineAndColumn const):
* tools/JSDollarVM.cpp:
(JSC::functionReturnTypeFor):
2019-02-04 Mark Lam <mark.lam@apple.com>
DFG's doesGC() is incorrect about the SameValue node's behavior.
https://bugs.webkit.org/show_bug.cgi?id=194211
<rdar://problem/47608913>
Reviewed by Saam Barati.
Only the DoubleRepUse case is guaranteed to not GC. The other case may GC because
it calls operationSameValue() which may allocate memory for resolving ropes.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
2019-02-03 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] UnlinkedMetadataTable assumes that MetadataTable is destroyed before it is destructed, but order of destruction of JS heap cells are not guaranteed
https://bugs.webkit.org/show_bug.cgi?id=194031
Reviewed by Saam Barati.
UnlinkedMetadataTable assumes that MetadataTable linked against this UnlinkedMetadataTable is already destroyed when UnlinkedMetadataTable is destroyed.
This means that UnlinkedCodeBlock is destroyed after all the linked CodeBlocks are destroyed. But this assumption is not valid since GC's finalizer
sweeps objects without considering the dependencies among swept objects. UnlinkedMetadataTable can be destroyed even before linked MetadataTable is
destroyed if UnlinkedCodeBlock is destroyed before linked CodeBlock is destroyed.
To make the above assumption valid, we make UnlinkedMetadataTable RefCounted object, and make MetadataTable hold the strong ref to UnlinkedMetadataTable.
This ensures that UnlinkedMetadataTable is destroyed after all the linked MetadataTables are destroyed.
* bytecode/MetadataTable.cpp:
(JSC::MetadataTable::MetadataTable):
(JSC::MetadataTable::~MetadataTable):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
(JSC::UnlinkedCodeBlock::visitChildren):
(JSC::UnlinkedCodeBlock::estimatedSize):
(JSC::UnlinkedCodeBlock::setInstructions):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::metadata):
(JSC::UnlinkedCodeBlock::metadataSizeInBytes):
* bytecode/UnlinkedMetadataTable.h:
(JSC::UnlinkedMetadataTable::create):
* bytecode/UnlinkedMetadataTableInlines.h:
(JSC::UnlinkedMetadataTable::UnlinkedMetadataTable):
* runtime/CachedTypes.cpp:
(JSC::CachedMetadataTable::decode const):
(JSC::CachedCodeBlock::metadata const):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
(JSC::CachedCodeBlock<CodeBlockType>::decode const):
(JSC::CachedCodeBlock<CodeBlockType>::encode):
2019-02-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Decouple JIT related data from CodeBlock
https://bugs.webkit.org/show_bug.cgi?id=194187
Reviewed by Saam Barati.
CodeBlock holds bunch of data which is only used after JIT starts compiling it.
We have three types of data in CodeBlock.
1. The data which is always used. CodeBlock needs to hold it.
2. The data which is touched even in LLInt, but it is only meaningful in JIT tiers. The example is profiling.
3. The data which is used after the JIT compiler starts running for the given CodeBlock.
This patch decouples (3) from CodeBlock as CodeBlock::JITData. Even if we have bunch of CodeBlocks, only small
number of them gets JIT compilation. Always allocating (3) data enlarges the size of CodeBlock, leading to the
memory waste. Potentially we can decouple (2) in another data structure, but we first do (3) since (3) is beneficial
in both non-JIT and *JIT* modes.
JITData is created only when JIT compiler wants to use it. So it can be concurrently created and used, so it is guarded
by the lock of CodeBlock.
The size of CodeBlock is reduced from 512 to 352.
This patch improves memory footprint and gets 1.1% improvement in RAMification.
Footprint geomean: 36696503 (34.997 MB)
Peak Footprint geomean: 38595988 (36.808 MB)
Score: 37634263 (35.891 MB)
Footprint geomean: 37172768 (35.451 MB)
Peak Footprint geomean: 38978288 (37.173 MB)
Score: 38064824 (36.301 MB)
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::~CodeBlock):
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::ensureJITDataSlow):
(JSC::CodeBlock::finalizeBaselineJITInlineCaches):
(JSC::CodeBlock::getICStatusMap):
(JSC::CodeBlock::addStubInfo):
(JSC::CodeBlock::addJITAddIC):
(JSC::CodeBlock::addJITMulIC):
(JSC::CodeBlock::addJITSubIC):
(JSC::CodeBlock::addJITNegIC):
(JSC::CodeBlock::findStubInfo):
(JSC::CodeBlock::addByValInfo):
(JSC::CodeBlock::addCallLinkInfo):
(JSC::CodeBlock::getCallLinkInfoForBytecodeIndex):
(JSC::CodeBlock::addRareCaseProfile):
(JSC::CodeBlock::rareCaseProfileForBytecodeOffset):
(JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset):
(JSC::CodeBlock::resetJITData):
(JSC::CodeBlock::stronglyVisitStrongReferences):
(JSC::CodeBlock::shrinkToFit):
(JSC::CodeBlock::linkIncomingCall):
(JSC::CodeBlock::linkIncomingPolymorphicCall):
(JSC::CodeBlock::unlinkIncomingCalls):
(JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
(JSC::CodeBlock::dumpValueProfiles):
(JSC::CodeBlock::setPCToCodeOriginMap):
(JSC::CodeBlock::findPC):
(JSC::CodeBlock::dumpMathICStats):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::ensureJITData):
(JSC::CodeBlock::setJITCodeMap):
(JSC::CodeBlock::jitCodeMap):
(JSC::CodeBlock::likelyToTakeSlowCase):
(JSC::CodeBlock::couldTakeSlowCase):
(JSC::CodeBlock::lazyOperandValueProfiles):
(JSC::CodeBlock::stubInfoBegin): Deleted.
(JSC::CodeBlock::stubInfoEnd): Deleted.
(JSC::CodeBlock::callLinkInfosBegin): Deleted.
(JSC::CodeBlock::callLinkInfosEnd): Deleted.
(JSC::CodeBlock::jitCodeMap const): Deleted.
(JSC::CodeBlock::numberOfRareCaseProfiles): Deleted.
* bytecode/MethodOfGettingAValueProfile.cpp:
(JSC::MethodOfGettingAValueProfile::emitReportValue const):
(JSC::MethodOfGettingAValueProfile::reportValue):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* jit/JIT.h:
* jit/JITOperations.cpp:
(JSC::tryGetByValOptimize):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::privateCompileGetByVal):
(JSC::JIT::privateCompilePutByVal):
2018-12-16 Darin Adler <darin@apple.com>
Convert additional String::format clients to alternative approaches
https://bugs.webkit.org/show_bug.cgi?id=192746
Reviewed by Alexey Proskuryakov.
* inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::stopTiming): Use makeString
and FormattedNumber::fixedWidth.
2019-02-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Remove some of IsoSubspaces for JSFunction subclasses
https://bugs.webkit.org/show_bug.cgi?id=194177
Reviewed by Saam Barati.
JSGeneratorFunction, JSAsyncFunction, and JSAsyncGeneratorFunction do not add any fields / classInfo methods.
We can share the IsoSubspace for JSFunction.
* runtime/JSAsyncFunction.h:
* runtime/JSAsyncGeneratorFunction.h:
* runtime/JSGeneratorFunction.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2019-02-01 Mark Lam <mark.lam@apple.com>
Remove invalid assertion in DFG's compileDoubleRep().
https://bugs.webkit.org/show_bug.cgi?id=194130
<rdar://problem/47699474>
Reviewed by Saam Barati.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileDoubleRep):
2019-02-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Unify CodeBlock IsoSubspaces
https://bugs.webkit.org/show_bug.cgi?id=194167
Reviewed by Saam Barati.
When we move CodeBlock into its IsoSubspace, we create IsoSubspaces for each subclass of CodeBlock.
But this is not necessary since,
1. They do not override the classInfo methods.
2. sizeof(ProgramCodeBlock etc.) == sizeof(CodeBlock) since subclasses adds no additional fields.
Creating IsoSubspace for each subclass is costly in terms of memory. Especially, IsoSubspace for
ProgramCodeBlock is. We typically create only one ProgramCodeBlock, and it means the rest of the
MarkedBlock (16KB - sizeof(footer) - sizeof(ProgramCodeBlock)) is just wasted.
This patch unifies these IsoSubspaces into one.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::destroy):
* bytecode/CodeBlock.h:
* bytecode/EvalCodeBlock.cpp:
(JSC::EvalCodeBlock::destroy): Deleted.
* bytecode/EvalCodeBlock.h: We drop some utility functions in EvalCodeBlock and use UnlinkedEvalCodeBlock's one directly.
* bytecode/FunctionCodeBlock.cpp:
(JSC::FunctionCodeBlock::destroy): Deleted.
* bytecode/FunctionCodeBlock.h:
* bytecode/GlobalCodeBlock.h:
* bytecode/ModuleProgramCodeBlock.cpp:
(JSC::ModuleProgramCodeBlock::destroy): Deleted.
* bytecode/ModuleProgramCodeBlock.h:
* bytecode/ProgramCodeBlock.cpp:
(JSC::ProgramCodeBlock::destroy): Deleted.
* bytecode/ProgramCodeBlock.h:
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
(JSC::VM::forEachCodeBlockSpace):
2019-02-01 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, follow-up after r240859
https://bugs.webkit.org/show_bug.cgi?id=194145
Replace OOB HeapCellType with cellHeapCellType since they are completely the same.
And rename cellDangerousBitsSpace back to cellSpace.
* runtime/JSCellInlines.h:
(JSC::JSCell::subspaceFor):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2019-02-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Remove cellJSValueOOBSpace
https://bugs.webkit.org/show_bug.cgi?id=194145
Reviewed by Mark Lam.
* runtime/JSObject.h:
(JSC::JSObject::subspaceFor): Deleted.
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2019-01-31 Mark Lam <mark.lam@apple.com>
Remove poisoning from CodeBlock and LLInt code.
https://bugs.webkit.org/show_bug.cgi?id=194113
Reviewed by Yusuke Suzuki.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::~CodeBlock):
(JSC::CodeBlock::setConstantRegisters):
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::finalizeLLIntInlineCaches):
(JSC::CodeBlock::jettison):
(JSC::CodeBlock::predictedMachineCodeSize):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::vm const):
(JSC::CodeBlock::addConstant):
(JSC::CodeBlock::heap const):
(JSC::CodeBlock::replaceConstant):
* llint/LLIntOfflineAsmConfig.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::handleHostCall):
(JSC::LLInt::setUpCall):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2019-01-31 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Remove finalizer in AsyncFromSyncIteratorPrototype
https://bugs.webkit.org/show_bug.cgi?id=194107
Reviewed by Saam Barati.
AsyncFromSyncIteratorPrototype uses the finalizer, but it is not necessary since it does not hold any objects which require destruction.
We drop this finalizer. And we also make methods of AsyncFromSyncIteratorPrototype lazily allocated.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/AsyncFromSyncIteratorPrototype.cpp:
(JSC::AsyncFromSyncIteratorPrototype::AsyncFromSyncIteratorPrototype):
(JSC::AsyncFromSyncIteratorPrototype::finishCreation):
(JSC::AsyncFromSyncIteratorPrototype::create):
* runtime/AsyncFromSyncIteratorPrototype.h:
2019-01-31 Tadeu Zagallo <tzagallo@apple.com>
Fix `runJITThreadLimitTests` in testapi
https://bugs.webkit.org/show_bug.cgi?id=194064
<rdar://problem/46139147>
Reviewed by Mark Lam.
Fix typo where `targetNumberOfThreads` was not being used.
* API/tests/testapi.mm:
(runJITThreadLimitTests):
2019-01-31 Tadeu Zagallo <tzagallo@apple.com>
testapi fails RELEASE_ASSERT(codeBlock) in fetchFromDisk() of CodeCache.h
https://bugs.webkit.org/show_bug.cgi?id=194112
Reviewed by Mark Lam.
`testBytecodeCache` does not populate the bytecode cache for the global
CodeBlock, so it should only enable `forceDiskCache` after its execution.
* API/tests/testapi.mm:
(testBytecodeCache):
2019-01-31 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, follow-up after r240796
Initialize WriteBarrier<InferredValue> in the constructor. Otherwise, GC can see the broken one
when allocating InferredValue in FunctionExecutable::finishCreation.
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::FunctionExecutable::finishCreation):
2019-01-31 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Do not use InferredValue in non-JIT configuration
https://bugs.webkit.org/show_bug.cgi?id=194084
Reviewed by Saam Barati.
InferredValue is not meaningful if our VM is non-JIT configuration. InferredValue is used to watch the instantiation of the FunctionExecutable's
JSFunction and SymbolTable's JSScope to explore the chance of folding them into constants in DFG and FTL. If it is instantiated only once, we can
put a watchpoint and fold it into this constant. But if JIT is disabled, we do not need to care it.
Even in non-JIT configuration, we still use InferredValue for FunctionExecutable to determine whether the given FunctionExecutable is preferable
target for poly proto. If JSFunction for the FunctionExecutable is used as a constructor and instantiated more than once, poly proto Structure
seems appropriate for objects created by this JSFunction. But at that time, only thing we would like to know is that whether JSFunction for this
FunctionExecutable is instantiated multiple times. This does not require the full feature of InferredValue, WatchpointState is enough.
To summarize, since nobody uses InferredValue feature in non-JIT configuration, we should not create it.
* bytecode/ObjectAllocationProfileInlines.h:
(JSC::ObjectAllocationProfile::initializeProfile):
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::finishCreation):
(JSC::FunctionExecutable::visitChildren):
* runtime/FunctionExecutable.h:
* runtime/InferredValue.cpp:
(JSC::InferredValue::create):
* runtime/JSAsyncFunction.cpp:
(JSC::JSAsyncFunction::create):
* runtime/JSAsyncGeneratorFunction.cpp:
(JSC::JSAsyncGeneratorFunction::create):
* runtime/JSFunction.cpp:
(JSC::JSFunction::create):
* runtime/JSFunctionInlines.h:
(JSC::JSFunction::createWithInvalidatedReallocationWatchpoint):
* runtime/JSGeneratorFunction.cpp:
(JSC::JSGeneratorFunction::create):
* runtime/JSSymbolTableObject.h:
(JSC::JSSymbolTableObject::setSymbolTable):
* runtime/SymbolTable.cpp:
(JSC::SymbolTable::finishCreation):
* runtime/VM.cpp:
(JSC::VM::VM):
2019-01-31 Fujii Hironori <Hironori.Fujii@sony.com>
[CMake][JSC] Changing ud_opcode.py should trigger invoking ud_opcode.py
https://bugs.webkit.org/show_bug.cgi?id=194085
Reviewed by Yusuke Suzuki.
r240730 changed ud_itab.py and caused incremental build failures
for Ninja builds.
* CMakeLists.txt: Added ud_itab.py and optable.xml to UDIS_GEN_DEP.
2019-01-30 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Symbol should be in destructibleCellSpace
https://bugs.webkit.org/show_bug.cgi?id=194082
Reviewed by Saam Barati.
Because Symbol's member was not poisoned, we changed the subspace for Symbol from destructibleCellSpace
to cellJSValueOOBSpace. But the problem is cellJSValueOOBSpace is a space for cells which are not
destructible. As a result, Symbol::destroy is never called, and SymbolImpl is leaked. This patch makes
Symbol's space destructibleCellSpace to appropriately call the destructor.
* runtime/Symbol.h:
2019-01-30 Michael Catanzaro <mcatanzaro@igalia.com>
Unreviewed, rolling out r240755.
This was not correct
Reverted changeset:
"Unreviewed, fix GCC build after r240730"
https://bugs.webkit.org/show_bug.cgi?id=194041
https://trac.webkit.org/changeset/240755
2019-01-30 Michael Catanzaro <mcatanzaro@igalia.com>
Unreviewed, fix GCC build after r240730
https://bugs.webkit.org/show_bug.cgi?id=194041
<rdar://problem/47680981>
* disassembler/udis86/ud_itab.py:
(UdItabGenerator.genOpcodeTablesLookupIndex):
2019-01-30 Tadeu Zagallo <tzagallo@apple.com>
testapi's `testBytecodeCache` does not need to run the code twice
https://bugs.webkit.org/show_bug.cgi?id=194046
Reviewed by Mark Lam.
Since we populate the cache eagerly (unlike the stress tests) we don't
need to run the code twice.
* API/tests/testapi.mm:
(testBytecodeCache):
2019-01-30 Saam barati <sbarati@apple.com>
[WebAssembly] Change BBQ to generate Air IR
https://bugs.webkit.org/show_bug.cgi?id=191802
<rdar://problem/47651718>
Reviewed by Keith Miller.
This patch adds a new Wasm compiler for the BBQ tier. Instead
of compiling using B3-01, we now generate Air code directly.
The goal of doing this was to speed up compile times for Wasm
programs.
This patch provides us with a 20-30% compile time speedup. However, I
have ideas on how to improve compile times even further. For example,
we should probably implement a faster running register allocator:
https://bugs.webkit.org/show_bug.cgi?id=194036
We can also improve on the code we generate.
We should emit better code for Switch: https://bugs.webkit.org/show_bug.cgi?id=194053
And we should do better instruction selection in various
areas: https://bugs.webkit.org/show_bug.cgi?id=193999
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* b3/B3LowerToAir.cpp:
* b3/B3StackmapSpecial.h:
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::emitDefaultPrologue):
* b3/air/AirCode.h:
* b3/air/AirTmp.h:
(JSC::B3::Air::Tmp::Tmp):
* runtime/Options.h:
* wasm/WasmAirIRGenerator.cpp: Added.
(JSC::Wasm::ConstrainedTmp::ConstrainedTmp):
(JSC::Wasm::TypedTmp::TypedTmp):
(JSC::Wasm::TypedTmp::operator== const):
(JSC::Wasm::TypedTmp::operator!= const):
(JSC::Wasm::TypedTmp::operator bool const):
(JSC::Wasm::TypedTmp::operator Tmp const):
(JSC::Wasm::TypedTmp::operator Arg const):
(JSC::Wasm::TypedTmp::tmp const):
(JSC::Wasm::TypedTmp::type const):
(JSC::Wasm::AirIRGenerator::ControlData::ControlData):
(JSC::Wasm::AirIRGenerator::ControlData::dump const):
(JSC::Wasm::AirIRGenerator::ControlData::type const):
(JSC::Wasm::AirIRGenerator::ControlData::signature const):
(JSC::Wasm::AirIRGenerator::ControlData::hasNonVoidSignature const):
(JSC::Wasm::AirIRGenerator::ControlData::targetBlockForBranch):
(JSC::Wasm::AirIRGenerator::ControlData::convertIfToBlock):
(JSC::Wasm::AirIRGenerator::ControlData::resultForBranch const):
(JSC::Wasm::AirIRGenerator::emptyExpression):
(JSC::Wasm::AirIRGenerator::fail const):
(JSC::Wasm::AirIRGenerator::setParser):
(JSC::Wasm::AirIRGenerator::toTmpVector):
(JSC::Wasm::AirIRGenerator::validateInst):
(JSC::Wasm::AirIRGenerator::extractArg):
(JSC::Wasm::AirIRGenerator::append):
(JSC::Wasm::AirIRGenerator::appendEffectful):
(JSC::Wasm::AirIRGenerator::newTmp):
(JSC::Wasm::AirIRGenerator::g32):
(JSC::Wasm::AirIRGenerator::g64):
(JSC::Wasm::AirIRGenerator::f32):
(JSC::Wasm::AirIRGenerator::f64):
(JSC::Wasm::AirIRGenerator::tmpForType):
(JSC::Wasm::AirIRGenerator::addPatchpoint):
(JSC::Wasm::AirIRGenerator::emitPatchpoint):
(JSC::Wasm::AirIRGenerator::emitCheck):
(JSC::Wasm::AirIRGenerator::emitCCall):
(JSC::Wasm::AirIRGenerator::moveOpForValueType):
(JSC::Wasm::AirIRGenerator::instanceValue):
(JSC::Wasm::AirIRGenerator::fixupPointerPlusOffset):
(JSC::Wasm::AirIRGenerator::restoreWasmContextInstance):
(JSC::Wasm::AirIRGenerator::AirIRGenerator):
(JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
(JSC::Wasm::AirIRGenerator::emitThrowException):
(JSC::Wasm::AirIRGenerator::addLocal):
(JSC::Wasm::AirIRGenerator::addConstant):
(JSC::Wasm::AirIRGenerator::addArguments):
(JSC::Wasm::AirIRGenerator::getLocal):
(JSC::Wasm::AirIRGenerator::addUnreachable):
(JSC::Wasm::AirIRGenerator::addGrowMemory):
(JSC::Wasm::AirIRGenerator::addCurrentMemory):
(JSC::Wasm::AirIRGenerator::setLocal):
(JSC::Wasm::AirIRGenerator::getGlobal):
(JSC::Wasm::AirIRGenerator::setGlobal):
(JSC::Wasm::AirIRGenerator::emitCheckAndPreparePointer):
(JSC::Wasm::sizeOfLoadOp):
(JSC::Wasm::AirIRGenerator::emitLoadOp):
(JSC::Wasm::AirIRGenerator::load):
(JSC::Wasm::sizeOfStoreOp):
(JSC::Wasm::AirIRGenerator::emitStoreOp):
(JSC::Wasm::AirIRGenerator::store):
(JSC::Wasm::AirIRGenerator::addSelect):
(JSC::Wasm::AirIRGenerator::emitTierUpCheck):
(JSC::Wasm::AirIRGenerator::addLoop):
(JSC::Wasm::AirIRGenerator::addTopLevel):
(JSC::Wasm::AirIRGenerator::addBlock):
(JSC::Wasm::AirIRGenerator::addIf):
(JSC::Wasm::AirIRGenerator::addElse):
(JSC::Wasm::AirIRGenerator::addElseToUnreachable):
(JSC::Wasm::AirIRGenerator::addReturn):
(JSC::Wasm::AirIRGenerator::addBranch):
(JSC::Wasm::AirIRGenerator::addSwitch):
(JSC::Wasm::AirIRGenerator::endBlock):
(JSC::Wasm::AirIRGenerator::addEndToUnreachable):
(JSC::Wasm::AirIRGenerator::addCall):
(JSC::Wasm::AirIRGenerator::addCallIndirect):
(JSC::Wasm::AirIRGenerator::unify):
(JSC::Wasm::AirIRGenerator::unifyValuesWithBlock):
(JSC::Wasm::AirIRGenerator::dump):
(JSC::Wasm::AirIRGenerator::origin):
(JSC::Wasm::parseAndCompileAir):
(JSC::Wasm::AirIRGenerator::emitChecksForModOrDiv):
(JSC::Wasm::AirIRGenerator::emitModOrDiv):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32DivS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32RemS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32DivU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32RemU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64DivS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64RemS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64DivU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64RemU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Ctz>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Ctz>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Popcnt>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Popcnt>):
(JSC::Wasm::AirIRGenerator::addOp<F64ConvertUI64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32ConvertUI64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Nearest>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Nearest>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Trunc>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Trunc>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32TruncSF64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32TruncSF32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32TruncUF64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32TruncUF32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64TruncSF64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64TruncUF64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64TruncSF32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64TruncUF32>):
(JSC::Wasm::AirIRGenerator::addShift):
(JSC::Wasm::AirIRGenerator::addIntegerSub):
(JSC::Wasm::AirIRGenerator::addFloatingPointAbs):
(JSC::Wasm::AirIRGenerator::addFloatingPointBinOp):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Ceil>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Mul>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Sub>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Le>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32DemoteF64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Min>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Ne>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Lt>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Max>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Mul>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Div>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Clz>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Copysign>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64ConvertUI32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32ReinterpretI32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64And>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Ne>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Gt>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Sqrt>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Ge>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64GtS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64GtU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Eqz>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Div>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Add>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Or>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32LeU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32LeS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Ne>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Clz>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Neg>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32And>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32LtU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Rotr>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Abs>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32LtS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Eq>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Copysign>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32ConvertSI64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Rotl>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Lt>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64ConvertSI32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Eq>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Le>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Ge>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32ShrU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32ConvertUI32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32ShrS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32GeU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Ceil>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32GeS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Shl>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Floor>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Xor>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Abs>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Min>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Mul>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Sub>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32ReinterpretF32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Add>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Sub>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Or>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64LtU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64LtS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64ConvertSI64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Xor>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64GeU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Mul>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Sub>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64PromoteF32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Add>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64GeS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64ExtendUI32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Ne>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64ReinterpretI64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Eq>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Eq>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Floor>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32ConvertSI32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Eqz>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64ReinterpretF64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64ShrS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64ShrU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Sqrt>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Shl>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Gt>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32WrapI64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Rotl>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Rotr>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32GtU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64ExtendSI32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32GtS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Neg>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Max>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64LeU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64LeS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Add>):
* wasm/WasmAirIRGenerator.h: Added.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::emptyExpression):
* wasm/WasmBBQPlan.cpp:
(JSC::Wasm::BBQPlan::compileFunctions):
* wasm/WasmCallingConvention.cpp:
(JSC::Wasm::jscCallingConventionAir):
(JSC::Wasm::wasmCallingConventionAir):
* wasm/WasmCallingConvention.h:
(JSC::Wasm::CallingConvention::CallingConvention):
(JSC::Wasm::CallingConvention::marshallArgumentImpl const):
(JSC::Wasm::CallingConvention::marshallArgument const):
(JSC::Wasm::CallingConventionAir::CallingConventionAir):
(JSC::Wasm::CallingConventionAir::prologueScratch const):
(JSC::Wasm::CallingConventionAir::marshallArgumentImpl const):
(JSC::Wasm::CallingConventionAir::marshallArgument const):
(JSC::Wasm::CallingConventionAir::headerSizeInBytes):
(JSC::Wasm::CallingConventionAir::loadArguments const):
(JSC::Wasm::CallingConventionAir::setupCall const):
(JSC::Wasm::nextJSCOffset):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/WasmValidate.cpp:
(JSC::Wasm::Validate::emptyExpression):
2019-01-30 Robin Morisset <rmorisset@apple.com>
Object.keys can now lead to a PhantomNewArrayBuffer, OSR exit from the FTL should know how to materialize a NewArrayBuffer in that case
https://bugs.webkit.org/show_bug.cgi?id=194050
<rdar://problem/47595592>
Following https://bugs.webkit.org/show_bug.cgi?id=190047, PhantomNewArrayBuffer is no longer guaranteed to originate from a NewArrayBuffer in the baseline jit.
It can now come from Object.keys, which is a function call. We must teach the FTL how to OSR exit in that case.
Reviewed by Yusuke Suzuki.
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
2019-01-30 Tadeu Zagallo <tzagallo@apple.com>
Remove assertion that CachedSymbolTables should have no RareData
https://bugs.webkit.org/show_bug.cgi?id=194037
Reviewed by Mark Lam.
It turns out that we don't need to cache the SymbolTableRareData and
we should not assert that it's empty.
* runtime/CachedTypes.cpp:
(JSC::CachedSymbolTable::encode):
2019-01-30 Tadeu Zagallo <tzagallo@apple.com>
CachedBytecode's move constructor should not call `freeDataIfOwned`
https://bugs.webkit.org/show_bug.cgi?id=194045
Reviewed by Mark Lam.
That might result in freeing a garbage value
* parser/SourceProvider.h:
(JSC::CachedBytecode::CachedBytecode):
2019-01-30 Keith Miller <keith_miller@apple.com>
mul32 should convert powers of 2 to an lshift
https://bugs.webkit.org/show_bug.cgi?id=193957
Reviewed by Yusuke Suzuki.
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::mul32):
* assembler/testmasm.cpp:
(JSC::int32Operands):
(JSC::testMul32WithImmediates):
(JSC::run):
2019-01-30 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Make disassembler data structures constant read-only data
https://bugs.webkit.org/show_bug.cgi?id=194041
Reviewed by Mark Lam.
Bunch of disassembler data structures are not marked "const", which prevents the loader to put them in read-only region.
This patch makes them "const".
* disassembler/ARM64/A64DOpcode.cpp:
* disassembler/udis86/ud_itab.py:
(UdItabGenerator.genOpcodeTablesLookupIndex):
(UdItabGenerator.genInsnTable):
(UdItabGenerator.genMnemonicsList):
(genItabH):
* disassembler/udis86/udis86_decode.h:
* disassembler/udis86/udis86_syn.c:
* disassembler/udis86/udis86_syn.h:
* disassembler/udis86/udis86_types.h:
2019-01-30 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, update the builtin test results
https://bugs.webkit.org/show_bug.cgi?id=194015
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
* Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
2019-01-30 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Make global static variables "const" as much as possible
https://bugs.webkit.org/show_bug.cgi?id=194015
Reviewed by Mark Lam.
Some of global static variables are not "const". For example, `static const char* name = ...`
is not constant variable. We should make it `static const char* const name = ...`.
* Scripts/wkbuiltins/builtins_generate_combined_header.py:
(generate_externs_for_object):
* Scripts/wkbuiltins/builtins_generate_separate_header.py:
(generate_externs_for_object):
* Scripts/wkbuiltins/builtins_generator.py:
(BuiltinsGenerator.generate_embedded_code_string_section_for_data):
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::additionBlindedConstant):
* b3/air/AirFormTable.h:
* b3/air/opcode_generator.rb:
* runtime/JSObject.cpp:
(JSC::JSObject::visitButterfly):
* tools/CodeProfile.cpp:
* tools/CodeProfile.h:
2019-01-29 Keith Miller <keith_miller@apple.com>
Remove default constructor from LLIntPrototypeLoadAdaptiveStructureWatchpoint
https://bugs.webkit.org/show_bug.cgi?id=194000
<rdar://problem/47642894>
Reviewed by Mark Lam.
default constructor is unused and
LLIntPrototypeLoadAdaptiveStructureWatchpoint has a reference
data member which causes sadness.
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
2019-01-29 Ross Kirsling <ross.kirsling@sony.com>
Remove FIXME for Annex B.3.5's "for-of var" subcase.
Rubber-stamped by Yusuke Suzuki.
This subcase is removed from the spec in https://github.com/tc39/ecma262/pull/1393.
* parser/Parser.h:
(JSC::Parser::declareHoistedVariable):
2019-01-29 Mark Lam <mark.lam@apple.com>
Remove unneeded CPU(BIG_ENDIAN) handling in LLInt after new bytecode format.
https://bugs.webkit.org/show_bug.cgi?id=132333
Reviewed by Yusuke Suzuki.
* bytecode/InstructionStream.h:
(JSC::InstructionStreamWriter::write):
- The 32-bit write() function need not invert the order of the bytes written to
the bytecode stream for CPU(BUG_ENDIAN) because the incoming uint32_t value to
be written is already in big endian order for CPU(BUG_ENDIAN) platforms.
* llint/LLIntOfflineAsmConfig.h:
- OFFLINE_ASM_BIG_ENDIAN is no longer needed nor used after the new bytecode format.
2019-01-29 Mark Lam <mark.lam@apple.com>
ValueRecovery::recover() should purify NaN values it recovers.
https://bugs.webkit.org/show_bug.cgi?id=193978
<rdar://problem/47625488>
Reviewed by Saam Barati.
According to DFG::OSRExit::executeOSRExit() and DFG::OSRExit::compileExit(),
recovered DoubleDisplacedInJSStack values need to be purified.
ValueRecovery::recover() should do the same.
* bytecode/ValueRecovery.cpp:
(JSC::ValueRecovery::recover const):
2019-01-29 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] FTL should handle LocalAllocator*
https://bugs.webkit.org/show_bug.cgi?id=193980
Reviewed by Saam Barati.
At some point, Allocator holds LocalAllocator* instead of 32bit integer. In FTL allocation path, we fail to use this constant LocalAllocator*
because the FTL still use the incoming value as 32bit integer there.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::allocateHeapCell):
2019-01-29 Keith Rollin <krollin@apple.com>
Add .xcfilelists to Run Script build phases
https://bugs.webkit.org/show_bug.cgi?id=193792
<rdar://problem/47201785>
Reviewed by Alex Christensen.
As part of supporting XCBuild, update the necessary Run Script build
phases in their Xcode projects to refer to their associated
.xcfilelist files.
Note that the addition of these files bumps the Xcode project version
number to something that's Xcode 10 compatible. This change means that
older versions of the Xcode IDE can't read these projects. Nor can it
fully load workspaces that refer to these projects (the updated
projects are shown as non-expandable placeholders). `xcodebuild` can
still build these projects; it's just that the IDE can't open them.
* JavaScriptCore.xcodeproj/project.pbxproj:
2019-01-29 Dominik Infuehr <dinfuehr@igalia.com>
[ARM] Check for negative zero instead of just zero
https://bugs.webkit.org/show_bug.cgi?id=193689
Reviewed by Mark Lam.
ARM now performs a negative zero check in branchConvertDoubleToInt32 instead
of just bailing out for zero.
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::branchConvertDoubleToInt32):
2019-01-28 Devin Rousso <drousso@apple.com>
Web Inspector: provide a way to edit page WebRTC settings on a remote target
https://bugs.webkit.org/show_bug.cgi?id=193863
<rdar://problem/47572764>
Reviewed by Joseph Pecoraro.
* inspector/protocol/Page.json:
Add more values to the `Setting` enum type:
- `ICECandidateFilteringEnabled`
- `MediaCaptureRequiresSecureConnection`
- `MockCaptureDevicesEnabled`
2019-01-28 Ross Kirsling <ross.kirsling@sony.com>
Remove unnecessary `using namespace WTF`s (or at least restrict their scope).
https://bugs.webkit.org/show_bug.cgi?id=193941
Reviewed by Alex Christensen.
* API/JSWeakObjectMapRefPrivate.cpp:
* bytecompiler/NodesCodegen.cpp:
* heap/MachineStackMarker.cpp:
* jit/ExecutableAllocator.cpp:
* jsc.cpp:
* parser/Nodes.cpp:
* runtime/DateConstructor.cpp:
* runtime/DateConversion.cpp:
* runtime/DateInstance.cpp:
* runtime/DatePrototype.cpp:
* runtime/InitializeThreading.cpp:
* runtime/IteratorOperations.cpp:
* runtime/JSDateMath.cpp:
* runtime/JSGlobalObjectFunctions.cpp:
* runtime/StringPrototype.cpp:
* runtime/VM.cpp:
* testRegExp.cpp:
* tools/JSDollarVM.cpp:
* yarr/YarrInterpreter.cpp:
* yarr/YarrJIT.cpp:
* yarr/YarrPattern.cpp:
* yarr/YarrUnicodeProperties.cpp:
2019-01-28 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Reduce size of memory used for ShadowChicken
https://bugs.webkit.org/show_bug.cgi?id=193546
Reviewed by Mark Lam.
This patch lazily instantiate ShadowChicken. We do not need this until we start logging ShadowChicken packets.
The removal of ShadowChicken saves 55KB memory.
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::create):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::ensureShadowChickenPacket):
* heap/Heap.cpp:
(JSC::Heap::stopThePeriphery):
(JSC::Heap::addCoreConstraints):
* jit/CCallHelpers.cpp:
(JSC::CCallHelpers::ensureShadowChickenPacket):
* jit/JITExceptions.cpp:
(JSC::genericUnwind):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_log_shadow_chicken_prologue):
(JSC::JIT::emit_op_log_shadow_chicken_tail):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_log_shadow_chicken_prologue):
(JSC::JIT::emit_op_log_shadow_chicken_tail):
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::setDebugger):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::setDebugger): Deleted.
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::ensureShadowChicken):
* runtime/VM.h:
(JSC::VM::shadowChicken):
* tools/JSDollarVM.cpp:
(JSC::functionShadowChickenFunctionsOnStack):
(JSC::changeDebuggerModeWhenIdle):
2019-01-28 Andy Estes <aestes@apple.com>
[watchOS] Enable Parental Controls content filtering
https://bugs.webkit.org/show_bug.cgi?id=193939
<rdar://problem/46641912>
Reviewed by Ryosuke Niwa.
* Configurations/FeatureDefines.xcconfig:
2019-01-28 Mark Lam <mark.lam@apple.com>
ToString node actually does GC.
https://bugs.webkit.org/show_bug.cgi?id=193920
<rdar://problem/46695900>
Reviewed by Yusuke Suzuki.
Other than for StringObjectUse and StringOrStringObjectUse, ToString and
CallStringConstructor can allocate new JSStrings, and hence, can GC.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
2019-01-28 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] RegExpConstructor should not have own IsoSubspace
https://bugs.webkit.org/show_bug.cgi?id=193801
Reviewed by Mark Lam.
This patch finally removes RegExpConstructor's cached data to JSGlobalObject and remove IsoSubspace for RegExpConstructor.
sizeof(RegExpConstructor) != sizeof(InternalFunction), so that we have 16KB memory just for RegExpConstructor. But cached
regexp matching data (e.g. `RegExp.$1`) is per-JSGlobalObject one, and we can move this data to JSGlobalObject and remove
it from RegExpConstructor members.
We introduce RegExpGlobalData, which holds the per-global RegExp matching data. And we perform `performMatch` etc. with
JSGlobalObject instead of RegExpConstructor. This change requires small changes in DFG / FTL's RecordRegExpCachedResult
node since its 1st argument is changed from RegExpConstructor to JSGlobalObject.
We also move emptyRegExp from RegExpPrototype to VM's RegExpCache because it is more natural place to put it.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* dfg/DFGOperations.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileRecordRegExpCachedResult):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* ftl/FTLAbstractHeapRepository.cpp:
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileRecordRegExpCachedResult):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::regExpGlobalData):
(JSC::JSGlobalObject::regExpGlobalDataOffset):
(JSC::JSGlobalObject::regExpConstructor const): Deleted.
* runtime/RegExpCache.cpp:
(JSC::RegExpCache::initialize):
* runtime/RegExpCache.h:
(JSC::RegExpCache::emptyRegExp const):
* runtime/RegExpCachedResult.cpp:
(JSC::RegExpCachedResult::visitAggregate):
(JSC::RegExpCachedResult::visitChildren): Deleted.
* runtime/RegExpCachedResult.h:
(JSC::RegExpCachedResult::RegExpCachedResult): Deleted.
* runtime/RegExpConstructor.cpp:
(JSC::RegExpConstructor::RegExpConstructor):
(JSC::regExpConstructorDollar):
(JSC::regExpConstructorInput):
(JSC::regExpConstructorMultiline):
(JSC::regExpConstructorLastMatch):
(JSC::regExpConstructorLastParen):
(JSC::regExpConstructorLeftContext):
(JSC::regExpConstructorRightContext):
(JSC::setRegExpConstructorInput):
(JSC::setRegExpConstructorMultiline):
(JSC::RegExpConstructor::destroy): Deleted.
(JSC::RegExpConstructor::visitChildren): Deleted.
(JSC::RegExpConstructor::getBackref): Deleted.
(JSC::RegExpConstructor::getLastParen): Deleted.
(JSC::RegExpConstructor::getLeftContext): Deleted.
(JSC::RegExpConstructor::getRightContext): Deleted.
* runtime/RegExpConstructor.h:
(JSC::RegExpConstructor::performMatch): Deleted.
(JSC::RegExpConstructor::recordMatch): Deleted.
* runtime/RegExpGlobalData.cpp: Added.
(JSC::RegExpGlobalData::visitAggregate):
(JSC::RegExpGlobalData::getBackref):
(JSC::RegExpGlobalData::getLastParen):
(JSC::RegExpGlobalData::getLeftContext):
(JSC::RegExpGlobalData::getRightContext):
* runtime/RegExpGlobalData.h: Added.
(JSC::RegExpGlobalData::cachedResult):
(JSC::RegExpGlobalData::setMultiline):
(JSC::RegExpGlobalData::multiline const):
(JSC::RegExpGlobalData::input):
(JSC::RegExpGlobalData::offsetOfCachedResult):
* runtime/RegExpGlobalDataInlines.h: Added.
(JSC::RegExpGlobalData::setInput):
(JSC::RegExpGlobalData::performMatch):
(JSC::RegExpGlobalData::recordMatch):
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::matchGlobal):
* runtime/RegExpObjectInlines.h:
(JSC::RegExpObject::execInline):
(JSC::RegExpObject::matchInline):
(JSC::collectMatches):
* runtime/RegExpPrototype.cpp:
(JSC::RegExpPrototype::finishCreation):
(JSC::regExpProtoFuncSearchFast):
(JSC::RegExpPrototype::visitChildren): Deleted.
* runtime/RegExpPrototype.h:
* runtime/StringPrototype.cpp:
(JSC::removeUsingRegExpSearch):
(JSC::replaceUsingRegExpSearch):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2018-12-15 Darin Adler <darin@apple.com>
Replace many uses of String::format with more type-safe alternatives
https://bugs.webkit.org/show_bug.cgi?id=192742
Reviewed by Mark Lam.
* inspector/InjectedScriptBase.cpp:
(Inspector::InjectedScriptBase::makeCall): Use makeString.
(Inspector::InjectedScriptBase::makeAsyncCall): Ditto.
* inspector/InspectorBackendDispatcher.cpp:
(Inspector::BackendDispatcher::getPropertyValue): Ditto.
* inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::enable): Ditto.
* jsc.cpp:
(FunctionJSCStackFunctor::operator() const): Ditto.
* runtime/CodeCache.cpp:
(JSC::writeCodeBlock): Use makeString's numeric capabilities instead of
using String::number.
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::initializeDateTimeFormat): Use string concatenation.
* runtime/IntlObject.cpp:
(JSC::canonicalizeLocaleList): Ditto.
2019-01-27 Chris Fleizach <cfleizach@apple.com>
AX: Introduce a static accessibility tree
https://bugs.webkit.org/show_bug.cgi?id=193348
<rdar://problem/47203295>
Reviewed by Ryosuke Niwa.
* Configurations/FeatureDefines.xcconfig:
2019-01-26 Devin Rousso <drousso@apple.com>
Web Inspector: provide a way to edit the user agent of a remote target
https://bugs.webkit.org/show_bug.cgi?id=193862
<rdar://problem/47359292>
Reviewed by Joseph Pecoraro.
* inspector/protocol/Page.json:
Add `overrideUserAgent` command.
2019-01-25 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] NativeErrorConstructor should not have own IsoSubspace
https://bugs.webkit.org/show_bug.cgi?id=193713
Reviewed by Saam Barati.
This removes an additional member in NativeErrorConstructor, and make sizeof(NativeErrorConstructor) == sizeof(InternalFunction).
We also make error constructors lazily allocated by using LazyClassStructure. Since error structures are not accessed from DFG / FTL
threads, this is OK. While TypeError constructor is eagerly allocated because it is touched from our builtin JS as @TypeError, we should
offer some function instead of exposing TypeError constructor in the future, and remove this @TypeError reference. This change removes
IsoSubspace for NativeErrorConstructor in VM. We also remove @Error and @RangeError references for builtins since they are no longer
referenced.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* builtins/BuiltinNames.h:
* interpreter/Interpreter.h:
* runtime/Error.cpp:
(JSC::createEvalError):
(JSC::createRangeError):
(JSC::createReferenceError):
(JSC::createSyntaxError):
(JSC::createTypeError):
(JSC::createURIError):
(WTF::printInternal): Deleted.
* runtime/Error.h:
* runtime/ErrorPrototype.cpp:
(JSC::ErrorPrototype::create):
(JSC::ErrorPrototype::finishCreation):
* runtime/ErrorPrototype.h:
(JSC::ErrorPrototype::create): Deleted.
* runtime/ErrorType.cpp: Added.
(JSC::errorTypeName):
(WTF::printInternal):
* runtime/ErrorType.h: Added.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::initializeErrorConstructor):
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::internalPromiseConstructor const):
(JSC::JSGlobalObject::errorStructure const):
(JSC::JSGlobalObject::evalErrorConstructor const): Deleted.
(JSC::JSGlobalObject::rangeErrorConstructor const): Deleted.
(JSC::JSGlobalObject::referenceErrorConstructor const): Deleted.
(JSC::JSGlobalObject::syntaxErrorConstructor const): Deleted.
(JSC::JSGlobalObject::typeErrorConstructor const): Deleted.
(JSC::JSGlobalObject::URIErrorConstructor const): Deleted.
* runtime/NativeErrorConstructor.cpp:
(JSC::NativeErrorConstructor<errorType>::NativeErrorConstructor):
(JSC::NativeErrorConstructorBase::finishCreation):
(JSC::NativeErrorConstructor<errorType>::constructNativeErrorConstructor):
(JSC::NativeErrorConstructor<errorType>::callNativeErrorConstructor):
(JSC::NativeErrorConstructor::NativeErrorConstructor): Deleted.
(JSC::NativeErrorConstructor::finishCreation): Deleted.
(JSC::NativeErrorConstructor::visitChildren): Deleted.
(JSC::Interpreter::constructWithNativeErrorConstructor): Deleted.
(JSC::Interpreter::callNativeErrorConstructor): Deleted.
* runtime/NativeErrorConstructor.h:
(JSC::NativeErrorConstructorBase::createStructure):
(JSC::NativeErrorConstructorBase::NativeErrorConstructorBase):
* runtime/NativeErrorPrototype.cpp:
(JSC::NativeErrorPrototype::finishCreation): Deleted.
* runtime/NativeErrorPrototype.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
* wasm/js/WasmToJS.cpp:
(JSC::Wasm::handleBadI64Use):
2019-01-25 Devin Rousso <drousso@apple.com>
Web Inspector: provide a way to edit page settings on a remote target
https://bugs.webkit.org/show_bug.cgi?id=193813
<rdar://problem/47359510>
Reviewed by Joseph Pecoraro.
* inspector/protocol/Page.json:
Add `overrideSetting` command with supporting `Setting` enum type.
2019-01-25 Keith Rollin <krollin@apple.com>
Update Xcode projects with "Check .xcfilelists" build phase
https://bugs.webkit.org/show_bug.cgi?id=193790
<rdar://problem/47201374>
Reviewed by Alex Christensen.
Support for XCBuild includes specifying inputs and outputs to various
Run Script build phases. These inputs and outputs are specified as
.xcfilelist files. Once created, these .xcfilelist files need to be
kept up-to-date. In order to check that they are up-to-date or not,
add an Xcode build step that invokes an external script that performs
the checking. If the .xcfilelists are found to be out-of-date, update
them, halt the build, and instruct the developer to restart the build
with up-to-date files.
At this time, the checking and regenerating is performed only if the
WK_ENABLE_CHECK_XCFILELISTS environment variable is set to 1. People
who want to use this facility can set this variable and test out the
checking/regenerating. Once it seems like there are no egregious
issues that upset a developer's workflow, we'll unconditionally enable
this facility.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Scripts/check-xcfilelists.sh: Added.
2019-01-25 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Exclude Debugger Threads from CPU Usage values in Web Inspector
https://bugs.webkit.org/show_bug.cgi?id=193796
<rdar://problem/47532910>
Reviewed by Devin Rousso.
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::machThread):
* runtime/SamplingProfiler.h:
Expose the mach_port_t of the SamplingProfiler thread
so it can be tested against later.
2019-01-25 Alex Christensen <achristensen@webkit.org>
Fix Windows build after r240511
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
2019-01-25 Keith Rollin <krollin@apple.com>
Update Xcode projects with "Apply Configuration to XCFileLists" build target
https://bugs.webkit.org/show_bug.cgi?id=193781
<rdar://problem/47201153>
Reviewed by Alex Christensen.
Part of generating the .xcfilelists used as part of adopting XCBuild
includes running `make DerivedSources.make` from a standalone script.
It’s important for this invocation to have the same environment as
when the actual build invokes `make DerivedSources.make`. If the
environments are different, then the two invocations will provide
different results. In order to get the same environment in the
standalone script, have the script launch xcodebuild targeting the
"Apply Configuration to XCFileLists" build target, which will then
re-invoke our standalone script. The script is now running again, this
time in an environment with all workspace, project, target, xcconfig
and other environment variables established.
The "Apply Configuration to XCFileLists" build target accomplishes
this task via a small embedded shell script that consists only of:
eval "${WK_SUBLAUNCH_SCRIPT_PARAMETERS[@]}"
The process that invokes "Apply Configuration to XCFileLists" first
sets WK_SUBLAUNCH_SCRIPT_PARAMETERS to an array of commands to be
evaluated and exports it into the shell environment. When xcodebuild
is invoked, it inherits the value of this variable and can `eval` the
contents of that variable. Our external standalone script can then set
WK_SUBLAUNCH_SCRIPT_PARAMETERS to the path to itself, along with a set
of command-line parameters needed to restart itself in the appropriate
state.
* JavaScriptCore.xcodeproj/project.pbxproj:
2019-01-25 Tadeu Zagallo <tzagallo@apple.com>
Add API to generate and consume cached bytecode
https://bugs.webkit.org/show_bug.cgi?id=193401
<rdar://problem/47514099>
Reviewed by Keith Miller.
Add the `generateBytecode` and `generateModuleBytecode` functions to
generate serialized bytecode for a given `SourceCode`. These functions
will eagerly generate code for all the nested functions.
Additionally, update the API methods in JSScript to generate and use the
bytecode when the bytecodeCache path is provided.
* API/JSAPIGlobalObject.mm:
(JSC::JSAPIGlobalObject::moduleLoaderFetch):
* API/JSContext.mm:
(-[JSContext wrapperMap]):
* API/JSContextInternal.h:
* API/JSScript.mm:
(+[JSScript scriptWithSource:inVirtualMachine:]):
(+[JSScript scriptFromASCIIFile:inVirtualMachine:withCodeSigning:andBytecodeCache:]):
(-[JSScript dealloc]):
(-[JSScript readCache]):
(-[JSScript writeCache]):
(-[JSScript hash]):
(-[JSScript source]):
(-[JSScript cachedBytecode]):
(-[JSScript jsSourceCode:]):
* API/JSScriptInternal.h:
* API/JSScriptSourceProvider.h: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
(JSScriptSourceProvider::create):
(JSScriptSourceProvider::JSScriptSourceProvider):
* API/JSScriptSourceProvider.mm: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
(JSScriptSourceProvider::hash const):
(JSScriptSourceProvider::source const):
(JSScriptSourceProvider::cachedBytecode const):
* API/JSVirtualMachine.mm:
(-[JSVirtualMachine vm]):
* API/JSVirtualMachineInternal.h:
* API/tests/testapi.mm:
(testBytecodeCache):
(-[JSContextFileLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
(testObjectiveCAPI):
* JavaScriptCore.xcodeproj/project.pbxproj:
* SourcesCocoa.txt:
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
* bytecode/UnlinkedFunctionExecutable.h:
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::source const):
* parser/SourceProvider.h:
(JSC::CachedBytecode::CachedBytecode):
(JSC::CachedBytecode::operator=):
(JSC::CachedBytecode::data const):
(JSC::CachedBytecode::size const):
(JSC::CachedBytecode::owned const):
(JSC::CachedBytecode::~CachedBytecode):
(JSC::CachedBytecode::freeDataIfOwned):
(JSC::SourceProvider::cachedBytecode const):
* parser/UnlinkedSourceCode.h:
(JSC::UnlinkedSourceCode::provider const):
* runtime/CodeCache.cpp:
(JSC::generateUnlinkedCodeBlockForFunctions):
(JSC::writeCodeBlock):
(JSC::serializeBytecode):
* runtime/CodeCache.h:
(JSC::CodeCacheMap::fetchFromDiskImpl):
(JSC::CodeCacheMap::findCacheAndUpdateAge):
(JSC::generateUnlinkedCodeBlockImpl):
(JSC::generateUnlinkedCodeBlock):
* runtime/Completion.cpp:
(JSC::generateBytecode):
(JSC::generateModuleBytecode):
* runtime/Completion.h:
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
2019-01-25 Keith Rollin <krollin@apple.com>
Update WebKitAdditions.xcconfig with correct order of variable definitions
https://bugs.webkit.org/show_bug.cgi?id=193793
<rdar://problem/47532439>
Reviewed by Alex Christensen.
XCBuild changes the way xcconfig variables are evaluated. In short,
all config file assignments are now considered in part of the
evaluation. When using the new build system and an .xcconfig file
contains multiple assignments of the same build setting:
- Later assignments using $(inherited) will inherit from earlier
assignments in the xcconfig file.
- Later assignments not using $(inherited) will take precedence over
earlier assignments. An assignment to a more general setting will
mask an earlier assignment to a less general setting. For example,
an assignment without a condition ('FOO = bar') will completely mask
an earlier assignment with a condition ('FOO[sdk=macos*] = quux').
This affects some of our .xcconfig files, in that sometimes platform-
or sdk-specific definitions appear before the general definitions.
Under the new evaluations rules, the general definitions alway take
effect because they always overwrite the more-specific definitions. The
solution is to swap the order, so that the general definitions are
established first, and then conditionally overwritten by the
more-specific definitions.
* Configurations/Version.xcconfig:
2019-01-25 Keith Rollin <krollin@apple.com>
Update existing .xcfilelists
https://bugs.webkit.org/show_bug.cgi?id=193791
<rdar://problem/47201706>
Reviewed by Alex Christensen.
Many .xcfilelist files were added in r238824 in order to support
XCBuild. Update these with recent changes to the set of build files
and with the current generate-xcfilelist script.
* DerivedSources-input.xcfilelist:
* DerivedSources-output.xcfilelist:
* UnifiedSources-input.xcfilelist:
* UnifiedSources-output.xcfilelist:
2019-01-25 Jon Davis <jond@apple.com>
Update JavaScriptCore feature status entries.
https://bugs.webkit.org/show_bug.cgi?id=193797
Reviewed by Mark Lam.
Updated feature status for Async Iteration, and Object rest/spread.
* features.json:
2019-01-24 Keith Miller <keith_miller@apple.com>
Remove usage of internal macro from private header
https://bugs.webkit.org/show_bug.cgi?id=193809
Reviewed by Saam Barati.
Also, add a new file to include all of our API headers to make sure
they don't accidentally include C++ or internal values.
* API/JSScript.h:
* API/tests/testIncludes.m: Added.
* JavaScriptCore.xcodeproj/project.pbxproj:
2019-01-24 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] ErrorConstructor should not have own IsoSubspace
https://bugs.webkit.org/show_bug.cgi?id=193800
Reviewed by Saam Barati.
Similar to r240456, sizeof(ErrorConstructor) != sizeof(InternalFunction), and that is why we have
IsoSubspace errorConstructorSpace in VM. But it is allocated only one-per-JSGlobalObject, and it is
too costly to have IsoSubspace which allocates 16KB. Since stackTraceLimit information is per
JSGlobalObject information, we should have m_stackTraceLimit in JSGlobalObject instead and put
ErrorConstructor in InternalFunction's IsoSubspace. As r230813 (moving InternalFunction and subclasses
into IsoSubspaces) described,
"subclasses that are the same size as InternalFunction share its subspace. I did this because the subclasses
appear to just override methods, which are called dynamically via the structure or class of the object.
So, I don't see a type confusion risk if UAF is used to allocate one kind of InternalFunction over another."
Then, putting ErrorConstructor in InternalFunction IsoSubspace is fine since it meets the above condition.
This patch removes m_stackTraceLimit in ErrorConstructor, and drops IsoSubspace for errorConstructorSpace.
This reduces the memory usage.
* interpreter/Interpreter.h:
* runtime/Error.cpp:
(JSC::getStackTrace):
* runtime/ErrorConstructor.cpp:
(JSC::ErrorConstructor::ErrorConstructor):
(JSC::ErrorConstructor::finishCreation):
(JSC::constructErrorConstructor):
(JSC::callErrorConstructor):
(JSC::ErrorConstructor::put):
(JSC::ErrorConstructor::deleteProperty):
(JSC::Interpreter::constructWithErrorConstructor): Deleted.
(JSC::Interpreter::callErrorConstructor): Deleted.
* runtime/ErrorConstructor.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::JSGlobalObject):
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::stackTraceLimit const):
(JSC::JSGlobalObject::setStackTraceLimit):
(JSC::JSGlobalObject::errorConstructor const): Deleted.
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2019-01-24 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: CPU Usage Timeline
https://bugs.webkit.org/show_bug.cgi?id=193730
<rdar://problem/46797201>
Reviewed by Devin Rousso.
* CMakeLists.txt:
* DerivedSources-input.xcfilelist:
* DerivedSources.make:
New files.
* inspector/protocol/CPUProfiler.json: Added.
New domain that follows the pattern of Memory/ScriptProfiler.
* inspector/protocol/Timeline.json:
New enum to auto-start a CPU instrument in the backend.
2019-01-24 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] SharedArrayBufferConstructor and ArrayBufferConstructor should not have their own IsoSubspace
https://bugs.webkit.org/show_bug.cgi?id=193774
Reviewed by Mark Lam.
We put all the instances of InternalFunction and its subclasses in IsoSubspace to make safer from UAF.
But since IsoSubspace requires the memory layout of instances is the same, we created different IsoSubspace
for subclasses of InternalFunction if sizeof(subclass) != sizeof(InternalFunction). One example is
ArrayBufferConstructor and SharedArrayBufferConstructor. But it is too costly to allocate 16KB page just
for these two constructor instances. They are only two instances per JSGlobalObject.
This patch makes sizeof(ArrayBufferConstructor) == sizeof(InternalFunction) so that they can use IsoSubspace
of InternalFunction. We introduce JSGenericArrayBufferConstructor, and it takes ArrayBufferSharingMode as
its template parameter. We define JSArrayBufferConstructor as JSGenericArrayBufferConstructor<ArrayBufferSharingMode::Default>
and JSSharedArrayBufferConstructor as JSGenericArrayBufferConstructor<ArrayBufferSharingMode::Shared> so that
we do not need to hold ArrayBufferSharingMode in the field of the constructor. This change removes IsoSubspace
for ArrayBufferConstructors, and reduces the memory usage.
* runtime/JSArrayBufferConstructor.cpp:
(JSC::JSGenericArrayBufferConstructor<sharingMode>::JSGenericArrayBufferConstructor):
(JSC::JSGenericArrayBufferConstructor<sharingMode>::finishCreation):
(JSC::JSGenericArrayBufferConstructor<sharingMode>::constructArrayBuffer):
(JSC::JSGenericArrayBufferConstructor<sharingMode>::createStructure):
(JSC::JSGenericArrayBufferConstructor<sharingMode>::info):
(JSC::JSArrayBufferConstructor::JSArrayBufferConstructor): Deleted.
(JSC::JSArrayBufferConstructor::finishCreation): Deleted.
(JSC::JSArrayBufferConstructor::create): Deleted.
(JSC::JSArrayBufferConstructor::createStructure): Deleted.
(JSC::constructArrayBuffer): Deleted.
* runtime/JSArrayBufferConstructor.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObject.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2019-01-24 Yusuke Suzuki <ysuzuki@apple.com>
stress/const-semantics.js fails a dfg-eager / ftl-eager run with an ASAN release build.
https://bugs.webkit.org/show_bug.cgi?id=190693
Reviewed by Michael Saboff.
JITStubRoutine's fields are marked only when JITStubRoutine::m_mayBeExecuting is true.
This becomes true when we find the executable address in our conservative roots, which
means that we could be executing it right now. This means that object liveness in
JITStubRoutine depends on the information gathered in ConservativeRoots. However, our
constraints are separated, "Conservative Scan" and "JIT Stub Routines". They can even
be executed concurrently, so that "JIT Stub Routines" may miss to mark the actually
executing JITStubRoutine because "Conservative Scan" finds it later.
When finalizing the GC, we delete the dead JITStubRoutines. At that time, since
"Conservative Scan" already finishes, we do not delete some JITStubRoutines which do not
mark the depending objects. Then, in the next cycle, we find JITStubRoutines still live,
attempt to mark the depending objects, and encounter the dead objects which are collected
in the previous cycles.
This patch removes "JIT Stub Routines" and merge it to "Conservative Scan". Since
"Conservative Scan" and "JIT Stub Routines" need to be executed only when the execution
happens (ensured by GreyedByExecution and CollectionPhase check), this change is OK for
GC stop time.
* heap/ConservativeRoots.h:
(JSC::ConservativeRoots::roots const):
(JSC::ConservativeRoots::roots): Deleted.
* heap/Heap.cpp:
(JSC::Heap::addCoreConstraints):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::append):
* heap/SlotVisitor.h:
* jit/GCAwareJITStubRoutine.cpp:
(JSC::GCAwareJITStubRoutine::GCAwareJITStubRoutine):
* jit/GCAwareJITStubRoutine.h:
2019-01-24 Saam Barati <sbarati@apple.com>
Update ARM64EHash
https://bugs.webkit.org/show_bug.cgi?id=193776
<rdar://problem/47526457>
Reviewed by Mark Lam.
See radar for details.
* assembler/AssemblerBuffer.h:
(JSC::ARM64EHash::update):
(JSC::ARM64EHash::finalHash const):
2019-01-24 Saam Barati <sbarati@apple.com>
Object Allocation Sinking phase can move a node that walks the stack into a place where the InlineCallFrame is no longer valid
https://bugs.webkit.org/show_bug.cgi?id=193751
<rdar://problem/47280215>
Reviewed by Michael Saboff.
The Object Allocation Sinking phase may move allocations around inside
of the program. However, it was not ensuring that it's still possible
to walk the stack at the point in the program that it moved the allocation to.
Certain InlineCallFrames rely on data in the stack when taking a stack trace.
All allocation sites can do a stack walk (we do a stack walk when we GC).
Conservatively, this patch says we're ok to move this allocation if we are
moving within the same InlineCallFrame. We could be more precise and do an
analysis of stack writes. However, this scenario is so rare that we just
take the conservative-and-straight-forward approach of checking that the place
we're moving to is the same InlineCallFrame as the allocation site.
In general, this issue arises anytime we do any kind of code motion.
Interestingly, LICM gets this right. It gets it right because the only
InlineCallFrames we can't move out of are the InlineCallFrames that
have metadata stored on the stack (callee for closure calls and argument
count for varargs calls). LICM doesn't have this issue because it relies
on Clobberize for doing its effects analysis. In clobberize, we model every
node within an InlineCallFrame that meets the above criteria as reading
from those stack fields. Consequently, LICM won't hoist any node in that
InlineCallFrame past the beginning of the InlineCallFrame since the IR
we generate to set up such an InlineCallFrame contains writes to that
stack location.
* dfg/DFGObjectAllocationSinkingPhase.cpp:
2019-01-24 Guillaume Emont <guijemont@igalia.com>
[JSC] Reenable baseline JIT on mips
https://bugs.webkit.org/show_bug.cgi?id=192983
Reviewed by Mark Lam.
Use $s0 as metadata register and make sure it's properly saved and
restored.
* jit/GPRInfo.h:
* jit/RegisterSet.cpp:
(JSC::RegisterSet::vmCalleeSaveRegisters):
(JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
* llint/LowLevelInterpreter.asm:
* offlineasm/mips.rb:
2019-01-24 Carlos Garcia Campos <cgarcia@igalia.com>
[GLIB] Expose JavaScriptCore options in GLib public API
https://bugs.webkit.org/show_bug.cgi?id=188742
Reviewed by Michael Catanzaro.
Add new API to set, get and iterate JSC options.
* API/glib/JSCOptions.cpp: Added.
(valueFromGValue):
(valueToGValue):
(jscOptionsSetValue):
(jscOptionsGetValue):
(jsc_options_set_boolean):
(jsc_options_get_boolean):
(jsc_options_set_int):
(jsc_options_get_int):
(jsc_options_set_uint):
(jsc_options_get_uint):
(jsc_options_set_size):
(jsc_options_get_size):
(jsc_options_set_double):
(jsc_options_get_double):
(jsc_options_set_string):
(jsc_options_get_string):
(jsc_options_set_range_string):
(jsc_options_get_range_string):
(jscOptionsType):
(jsc_options_foreach):
(setOptionEntry):
(jsc_options_get_option_group):
* API/glib/JSCOptions.h: Added.
* API/glib/docs/jsc-glib-4.0-sections.txt:
* API/glib/docs/jsc-glib-docs.sgml:
* API/glib/jsc.h:
* GLib.cmake:
2019-01-23 Mark Lam <mark.lam@apple.com>
ARM64E should not ENABLE(SEPARATED_WX_HEAP).
https://bugs.webkit.org/show_bug.cgi?id=193744
<rdar://problem/46262952>
Reviewed by Saam Barati.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::copyCompactAndLinkCode):
2019-01-23 Yusuke Suzuki <ysuzuki@apple.com>
[DFG] AvailabilityMap::pruneByLiveness should make non-live operands Availability::unavailable instead of Availability()
https://bugs.webkit.org/show_bug.cgi?id=193711
<rdar://problem/47250262>
Reviewed by Saam Barati.
When pruning OSR Availability based on bytecode liveness, we accidentally clear the Availability (making it DeadFlush) instead of
making it Availability::unavailable() (Making it ConflictingFlush). In OSRAvailabilityAnalysisPhase, we perform forward analysis.
We first clear all the availability of basic blocks DeadFlush, which is an empty set. And then, we set operands in the root block
ConflictingFlush. In this forward analysis, DeadFlush is BOTTOM, and ConflictingFlush is TOP. Then, we propagate information by
merging availability until we reach to the fixed-point. As an optimization, we perform "pruning" of the availability in the head
of the basic blocks. We remove availabilities of operands which are not live in the bytecode liveness at the head of the basic block.
The problem is, when removing availabilities, we set DeadFlush for them instead of ConflictingFlush. Basically, it means that we set
BOTTOM (an empty set) instead of TOP. Let's consider the following simple example. We have 6 basic blocks, and they are connected
as follows.
BB0 -> BB1 -> BB2 -> BB4
| \ ^
v > BB3 /
BB5
And consider about loc1 in FTL, which is required to be recovered in BB4's OSR exit.
BB0 does nothing
head: loc1 is dead
tail: loc1 is dead
BB1 has MovHint @1, loc1
head: loc1 is dead
tail: loc1 is live
BB2 does nothing
head: loc1 is live
tail: loc1 is live
BB3 has PutStack @1, loc1
head: loc1 is live
tail: loc1 is live
BB4 has OSR exit using loc1
head: loc1 is live
tail: loc1 is live (in bytecode)
BB5 does nothing
head: loc1 is dead
tail: loc1 is dead
In our OSR Availability analysis, we always prune loc1 result in BB1's head since its head says "loc1 is dead".
But at that time, we clear the availability for loc1, which makes it DeadFlush, instead of making it ConflictingFlush.
So, the flush format of loc1 in each tail of BB is like this.
BB0
ConflictingFlush (because all the local operands are initialized with ConflictingFlush)
BB1
DeadFlush+@1 (pruning clears it)
BB2
DeadFlush+@1 (since it is propagated from BB1)
BB3
FlushedJSValue+@1 with loc1 (since it has PutStack)
BB4
FlushedJSValue+@1 with loc1 (since MERGE(DeadFlush, FlushedJSValue) = FlushedJSValue)
BB5
DeadFlush (pruning clears it)
Then, if we go the path BB0->BB1->BB2->BB4, we read the value from the stack while it is not flushed.
The correct fix is making availability "unavailable" when pruning based on bytecode liveness.
* dfg/DFGAvailabilityMap.cpp:
(JSC::DFG::AvailabilityMap::pruneByLiveness): When pruning availability, we first set all the operands Availability::unavailable(),
and copy the calculated value from the current availability map.
* dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
(JSC::DFG::OSRAvailabilityAnalysisPhase::run): Add logging things for debugging.
2019-01-23 David Kilzer <ddkilzer@apple.com>
[JSC] Duplicate global variables: JSC::opcodeLengths
<https://webkit.org/b/193714>
<rdar://problem/47340200>
Reviewed by Mark Lam.
* bytecode/Opcode.cpp:
(JSC::opcodeLengths): Move array implementation here and mark
const.
* bytecode/Opcode.h:
(JSC::opcodeLengths): Change to extern declaration.
2019-01-23 Carlos Garcia Campos <cgarcia@igalia.com>
[GLIB] Remote Inspector: no data displayed
https://bugs.webkit.org/show_bug.cgi?id=193569
Reviewed by Michael Catanzaro.
Release the remote inspector mutex before using RemoteConnectionToTarget in RemoteInspector::setup() to avoid a
deadlock.
* inspector/remote/glib/RemoteInspectorGlib.cpp:
(Inspector::RemoteInspector::receivedSetupMessage):
(Inspector::RemoteInspector::setup):
2019-01-22 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, fix initial global lexical binding epoch
https://bugs.webkit.org/show_bug.cgi?id=193603
<rdar://problem/47380869>
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
2019-01-22 Yusuke Suzuki <ysuzuki@apple.com>
REGRESSION(r239612) Crash at runtime due to broken DFG assumption
https://bugs.webkit.org/show_bug.cgi?id=193709
<rdar://problem/47363838>
Unreviewed, rollout to watch the tests.
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::fixupObjectToString): Deleted.
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileObjectToString): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileToStringOrCallStringConstructorOrStringValueOf):
(JSC::FTL::DFG::LowerDFGToB3::compileObjectToString): Deleted.
* runtime/Intrinsic.cpp:
(JSC::intrinsicName):
* runtime/Intrinsic.h:
* runtime/ObjectPrototype.cpp:
(JSC::ObjectPrototype::finishCreation):
(JSC::objectProtoFuncToString):
* runtime/ObjectPrototype.h:
* runtime/ObjectPrototypeInlines.h: Removed.
* runtime/StructureRareData.h:
2019-01-22 Devin Rousso <drousso@apple.com>
Web Inspector: expose Audit and Recording versions to the frontend
https://bugs.webkit.org/show_bug.cgi?id=193262
<rdar://problem/47130684>
Reviewed by Joseph Pecoraro.
* inspector/protocol/Audit.json:
* inspector/protocol/Recording.json:
Add `version` values.
* inspector/scripts/codegen/models.py:
(Protocol.parse_domain):
(Domain.__init__):
(Domain.version): Added.
(Domains):
* inspector/scripts/codegen/generator.py:
(Generator.version_for_domain): Added.
* inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
(CppProtocolTypesHeaderGenerator.generate_output):
(CppProtocolTypesHeaderGenerator._generate_versions): Added.
* inspector/scripts/codegen/generate_js_backend_commands.py:
(JSBackendCommandsGenerator.should_generate_domain):
(JSBackendCommandsGenerator.generate_domain):
* inspector/scripts/tests/generic/version.json: Added.
* inspector/scripts/tests/generic/expected/version.json-result: Added.
* inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/generic/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/generic/expected/domain-availability.json-result:
* inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/generic/expected/enum-values.json-result:
* inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/generic/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
* inspector/scripts/tests/generic/expected/type-with-open-parameters.json-result:
* inspector/scripts/tests/ios/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result:
2019-01-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Intl constructors should fit in sizeof(InternalFunction)
https://bugs.webkit.org/show_bug.cgi?id=193661
Reviewed by Mark Lam.
Previously all the Intl constructors have their own subspace. This is because these constructors have different size from InternalFunction.
But it is too costly approach in terms of the memory usage since these constructors are only one per JSGlobalObject. This patch attempts to
reduce the memory size consumed by these Intl objects by holding instance structures in IntlObject instead of in each Intl constructors.
So that we can make sizeof(Intl constructors) == sizeof(InternalFunction) and drop costly subspaces. Since this patch drops subspaces in VM,
it also significantly reduces the sizeof(VM), from 76696 to 74680.
This patch also includes the preparation for making Intl properties lazy. But currently it is not possible since @Collator reference exists
in builtin code.
* CMakeLists.txt:
* DerivedSources.make:
* runtime/IntlCollatorConstructor.cpp:
(JSC::IntlCollatorConstructor::create):
(JSC::IntlCollatorConstructor::finishCreation):
(JSC::constructIntlCollator):
(JSC::callIntlCollator):
(JSC::IntlCollatorConstructor::visitChildren): Deleted.
* runtime/IntlCollatorConstructor.h:
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::IntlDateTimeFormatConstructor::create):
(JSC::IntlDateTimeFormatConstructor::finishCreation):
(JSC::constructIntlDateTimeFormat):
(JSC::callIntlDateTimeFormat):
(JSC::IntlDateTimeFormatConstructor::visitChildren): Deleted.
* runtime/IntlDateTimeFormatConstructor.h:
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::IntlNumberFormatConstructor::create):
(JSC::IntlNumberFormatConstructor::finishCreation):
(JSC::constructIntlNumberFormat):
(JSC::callIntlNumberFormat):
(JSC::IntlNumberFormatConstructor::visitChildren): Deleted.
* runtime/IntlNumberFormatConstructor.h:
* runtime/IntlObject.cpp:
(JSC::createCollatorConstructor):
(JSC::createNumberFormatConstructor):
(JSC::createDateTimeFormatConstructor):
(JSC::createPluralRulesConstructor):
(JSC::IntlObject::create):
(JSC::IntlObject::finishCreation):
(JSC::IntlObject::visitChildren):
* runtime/IntlObject.h:
* runtime/IntlPluralRulesConstructor.cpp:
(JSC::IntlPluralRulesConstructor::create):
(JSC::IntlPluralRulesConstructor::finishCreation):
(JSC::constructIntlPluralRules):
(JSC::IntlPluralRulesConstructor::visitChildren): Deleted.
* runtime/IntlPluralRulesConstructor.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::intlObject const):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2019-01-22 Saam Barati <sbarati@apple.com>
Unreviewed. Rollout r240223. It regressed JetStream2 by 1%.
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
2019-01-22 Tadeu Zagallo <tzagallo@apple.com>
Unreviewed, restore bytecode cache-related JSC options deleted in r240254
https://bugs.webkit.org/show_bug.cgi?id=192782
The JSC options were committed as part of r240210, which got rolled out in
r240224. However, the options got re-landed in r240248 and then deleted
again in 240254 (immediately before the caching code code landed in 240255)
* runtime/Options.h:
2019-01-22 Tadeu Zagallo <tzagallo@apple.com>
Cache bytecode to disk
https://bugs.webkit.org/show_bug.cgi?id=192782
<rdar://problem/46084932>
Reviewed by Keith Miller.
Add the logic to serialize and deserialize the new JSC bytecode. For now,
the cache is only used for tests.
Each class that can be serialized has a counterpart in CachedTypes, which
handles the decoding and encoding. When decoding, the cached objects are
mmap'd from disk, but only used for creating instances of the respective
in-memory version of each object. Ideally, the mmap'd objects should be
used at runtime in the future.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* builtins/BuiltinNames.cpp:
(JSC::BuiltinNames::BuiltinNames):
* builtins/BuiltinNames.h:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::setConstantIdentifierSetRegisters):
* bytecode/CodeBlock.h:
* bytecode/HandlerInfo.h:
(JSC::UnlinkedHandlerInfo::UnlinkedHandlerInfo):
* bytecode/InstructionStream.h:
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::addSetConstant):
(JSC::UnlinkedCodeBlock::constantIdentifierSets):
* bytecode/UnlinkedEvalCodeBlock.h:
* bytecode/UnlinkedFunctionCodeBlock.h:
* bytecode/UnlinkedFunctionExecutable.h:
* bytecode/UnlinkedGlobalCodeBlock.h:
(JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock):
* bytecode/UnlinkedMetadataTable.h:
* bytecode/UnlinkedModuleProgramCodeBlock.h:
* bytecode/UnlinkedProgramCodeBlock.h:
* interpreter/Interpreter.cpp:
* jsc.cpp:
(functionQuit):
(runJSC):
* parser/SourceCode.h:
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::operator!= const):
* parser/UnlinkedSourceCode.h:
* parser/VariableEnvironment.h:
* runtime/CachedTypes.cpp: Added.
(JSC::Encoder::Allocation::buffer const):
(JSC::Encoder::Allocation::offset const):
(JSC::Encoder::Allocation::Allocation):
(JSC::Encoder::Encoder):
(JSC::Encoder::vm):
(JSC::Encoder::malloc):
(JSC::Encoder::offsetOf):
(JSC::Encoder::cachePtr):
(JSC::Encoder::offsetForPtr):
(JSC::Encoder::release):
(JSC::Encoder::Page::Page):
(JSC::Encoder::Page::malloc):
(JSC::Encoder::Page::buffer const):
(JSC::Encoder::Page::size const):
(JSC::Encoder::Page::getOffset const):
(JSC::Encoder::allocateNewPage):
(JSC::Decoder::Decoder):
(JSC::Decoder::~Decoder):
(JSC::Decoder::vm):
(JSC::Decoder::offsetOf):
(JSC::Decoder::cacheOffset):
(JSC::Decoder::addFinalizer):
(JSC::encode):
(JSC::decode):
(JSC::VariableLengthObject::buffer const):
(JSC::VariableLengthObject::allocate):
(JSC::CachedPtr::encode):
(JSC::CachedPtr::decode const):
(JSC::CachedPtr::operator-> const):
(JSC::CachedPtr::get const):
(JSC::CachedRefPtr::encode):
(JSC::CachedRefPtr::decode const):
(JSC::CachedWriteBarrier::encode):
(JSC::CachedWriteBarrier::decode const):
(JSC::CachedVector::encode):
(JSC::CachedVector::decode const):
(JSC::CachedPair::encode):
(JSC::CachedPair::decode const):
(JSC::CachedHashMap::encode):
(JSC::CachedHashMap::decode const):
(JSC::CachedUniquedStringImpl::encode):
(JSC::CachedUniquedStringImpl::decode const):
(JSC::CachedStringImpl::encode):
(JSC::CachedStringImpl::decode const):
(JSC::CachedString::encode):
(JSC::CachedString::decode const):
(JSC::CachedIdentifier::encode):
(JSC::CachedIdentifier::decode const):
(JSC::CachedOptional::encode):
(JSC::CachedOptional::decode const):
(JSC::CachedOptional::decodeAsPtr const):
(JSC::CachedSimpleJumpTable::encode):
(JSC::CachedSimpleJumpTable::decode const):
(JSC::CachedStringJumpTable::encode):
(JSC::CachedStringJumpTable::decode const):
(JSC::CachedCodeBlockRareData::encode):
(JSC::CachedCodeBlockRareData::decode const):
(JSC::CachedBitVector::encode):
(JSC::CachedBitVector::decode const):
(JSC::CachedHashSet::encode):
(JSC::CachedHashSet::decode const):
(JSC::CachedConstantIdentifierSetEntry::encode):
(JSC::CachedConstantIdentifierSetEntry::decode const):
(JSC::CachedVariableEnvironment::encode):
(JSC::CachedVariableEnvironment::decode const):
(JSC::CachedArray::encode):
(JSC::CachedArray::decode const):
(JSC::CachedScopedArgumentsTable::encode):
(JSC::CachedScopedArgumentsTable::decode const):
(JSC::CachedSymbolTableEntry::encode):
(JSC::CachedSymbolTableEntry::decode const):
(JSC::CachedSymbolTable::encode):
(JSC::CachedSymbolTable::decode const):
(JSC::CachedImmutableButterfly::encode):
(JSC::CachedImmutableButterfly::decode const):
(JSC::CachedRegExp::encode):
(JSC::CachedRegExp::decode const):
(JSC::CachedTemplateObjectDescriptor::encode):
(JSC::CachedTemplateObjectDescriptor::decode const):
(JSC::CachedBigInt::encode):
(JSC::CachedBigInt::decode const):
(JSC::CachedJSValue::encode):
(JSC::CachedJSValue::decode const):
(JSC::CachedInstructionStream::encode):
(JSC::CachedInstructionStream::decode const):
(JSC::CachedMetadataTable::encode):
(JSC::CachedMetadataTable::decode const):
(JSC::CachedSourceOrigin::encode):
(JSC::CachedSourceOrigin::decode const):
(JSC::CachedTextPosition::encode):
(JSC::CachedTextPosition::decode const):
(JSC::CachedSourceProviderShape::encode):
(JSC::CachedSourceProviderShape::decode const):
(JSC::CachedStringSourceProvider::encode):
(JSC::CachedStringSourceProvider::decode const):
(JSC::CachedWebAssemblySourceProvider::encode):
(JSC::CachedWebAssemblySourceProvider::decode const):
(JSC::CachedSourceProvider::encode):
(JSC::CachedSourceProvider::decode const):
(JSC::CachedUnlinkedSourceCodeShape::encode):
(JSC::CachedUnlinkedSourceCodeShape::decode const):
(JSC::CachedSourceCode::encode):
(JSC::CachedSourceCode::decode const):
(JSC::CachedFunctionExecutable::firstLineOffset const):
(JSC::CachedFunctionExecutable::lineCount const):
(JSC::CachedFunctionExecutable::unlinkedFunctionNameStart const):
(JSC::CachedFunctionExecutable::unlinkedBodyStartColumn const):
(JSC::CachedFunctionExecutable::unlinkedBodyEndColumn const):
(JSC::CachedFunctionExecutable::startOffset const):
(JSC::CachedFunctionExecutable::sourceLength const):
(JSC::CachedFunctionExecutable::parametersStartOffset const):
(JSC::CachedFunctionExecutable::typeProfilingStartOffset const):
(JSC::CachedFunctionExecutable::typeProfilingEndOffset const):
(JSC::CachedFunctionExecutable::parameterCount const):
(JSC::CachedFunctionExecutable::features const):
(JSC::CachedFunctionExecutable::sourceParseMode const):
(JSC::CachedFunctionExecutable::isInStrictContext const):
(JSC::CachedFunctionExecutable::hasCapturedVariables const):
(JSC::CachedFunctionExecutable::isBuiltinFunction const):
(JSC::CachedFunctionExecutable::isBuiltinDefaultClassConstructor const):
(JSC::CachedFunctionExecutable::constructAbility const):
(JSC::CachedFunctionExecutable::constructorKind const):
(JSC::CachedFunctionExecutable::functionMode const):
(JSC::CachedFunctionExecutable::scriptMode const):
(JSC::CachedFunctionExecutable::superBinding const):
(JSC::CachedFunctionExecutable::derivedContextType const):
(JSC::CachedFunctionExecutable::name const):
(JSC::CachedFunctionExecutable::ecmaName const):
(JSC::CachedFunctionExecutable::inferredName const):
(JSC::CachedCodeBlock::instructions const):
(JSC::CachedCodeBlock::thisRegister const):
(JSC::CachedCodeBlock::scopeRegister const):
(JSC::CachedCodeBlock::globalObjectRegister const):
(JSC::CachedCodeBlock::sourceURLDirective const):
(JSC::CachedCodeBlock::sourceMappingURLDirective const):
(JSC::CachedCodeBlock::usesEval const):
(JSC::CachedCodeBlock::isStrictMode const):
(JSC::CachedCodeBlock::isConstructor const):
(JSC::CachedCodeBlock::hasCapturedVariables const):
(JSC::CachedCodeBlock::isBuiltinFunction const):
(JSC::CachedCodeBlock::superBinding const):
(JSC::CachedCodeBlock::scriptMode const):
(JSC::CachedCodeBlock::isArrowFunctionContext const):
(JSC::CachedCodeBlock::isClassContext const):
(JSC::CachedCodeBlock::wasCompiledWithDebuggingOpcodes const):
(JSC::CachedCodeBlock::constructorKind const):
(JSC::CachedCodeBlock::derivedContextType const):
(JSC::CachedCodeBlock::evalContextType const):
(JSC::CachedCodeBlock::hasTailCalls const):
(JSC::CachedCodeBlock::lineCount const):
(JSC::CachedCodeBlock::endColumn const):
(JSC::CachedCodeBlock::numVars const):
(JSC::CachedCodeBlock::numCalleeLocals const):
(JSC::CachedCodeBlock::numParameters const):
(JSC::CachedCodeBlock::features const):
(JSC::CachedCodeBlock::parseMode const):
(JSC::CachedCodeBlock::codeType const):
(JSC::CachedCodeBlock::rareData const):
(JSC::CachedProgramCodeBlock::encode):
(JSC::CachedProgramCodeBlock::decode const):
(JSC::CachedModuleCodeBlock::encode):
(JSC::CachedModuleCodeBlock::decode const):
(JSC::CachedEvalCodeBlock::encode):
(JSC::CachedEvalCodeBlock::decode const):
(JSC::CachedFunctionCodeBlock::encode):
(JSC::CachedFunctionCodeBlock::decode const):
(JSC::UnlinkedFunctionCodeBlock::UnlinkedFunctionCodeBlock):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
(JSC::CachedCodeBlock<CodeBlockType>::decode const):
(JSC::UnlinkedProgramCodeBlock::UnlinkedProgramCodeBlock):
(JSC::UnlinkedModuleProgramCodeBlock::UnlinkedModuleProgramCodeBlock):
(JSC::UnlinkedEvalCodeBlock::UnlinkedEvalCodeBlock):
(JSC::CachedFunctionExecutable::encode):
(JSC::CachedFunctionExecutable::decode const):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::CachedCodeBlock<CodeBlockType>::encode):
(JSC::CachedSourceCodeKey::encode):
(JSC::CachedSourceCodeKey::decode const):
(JSC::CacheEntry::encode):
(JSC::CacheEntry:: const):
(JSC:: const):
(JSC::encodeCodeBlock):
(JSC::decodeCodeBlockImpl):
* runtime/CachedTypes.h: Copied from Source/JavaScriptCore/bytecode/UnlinkedGlobalCodeBlock.h.
(JSC::decodeCodeBlock):
* runtime/CodeCache.cpp:
(JSC::CodeCacheMap::pruneSlowCase):
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
(JSC::CodeCache::write):
* runtime/CodeCache.h:
(JSC::CodeCacheMap::begin):
(JSC::CodeCacheMap::end):
(JSC::CodeCacheMap::fetchFromDiskImpl):
(JSC::CodeCacheMap::findCacheAndUpdateAge):
(JSC::writeCodeBlock):
* runtime/JSBigInt.cpp:
* runtime/JSBigInt.h:
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/RegExp.h:
* runtime/ScopedArgumentsTable.h:
* runtime/StackFrame.h:
* runtime/StructureInlines.h:
* runtime/SymbolTable.h:
2019-01-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Invalidate old scope operations using global lexical binding epoch
https://bugs.webkit.org/show_bug.cgi?id=193603
<rdar://problem/47380869>
Reviewed by Saam Barati.
Even if the global lexical binding does not shadow the global property at that time, we need to clear the cached information in
scope related operations since we may have a global property previously. Consider the following example,
foo = 0;
function get() { return foo; }
print(get()); // 0
print(get()); // 0
delete globalThis.foo;
$.evalScript(`const foo = 42;`);
print(get()); // Should be 42, but it returns 0 if the cached information in get() is not cleared.
To invalidate the cache easily, we introduce global lexical binding epoch. It is bumped every time we introduce a new lexical binding
into JSGlobalLexicalEnvironment, since that name could shadow the global property name previously. In op_resolve_scope, we first check
the epoch stored in the metadata, and go to slow path if it is not equal to the current epoch. Our slow path code convert the scope
operation to the appropriate one even if the resolve type is not UnresolvedProperty type. After updating the resolve type of the bytecode,
we update the cached epoch to the current one, so that we can use the cached information as long as we stay in the same epoch.
In op_get_from_scope and op_put_to_scope, we do not use this epoch since Structure check can do the same thing instead. If op_resolve_type
is updated by the epoch, and if it starts returning JSGlobalLexicalEnvironment instead JSGlobalObject, obviously the structure check fails.
And in the slow path, we update op_get_from_scope and op_put_to_scope appropriately.
So, the metadata for scope related bytecodes are eventually updated to the appropriate one. In DFG and FTL, we use the watchpoint based approach.
In DFG and FTL, we concurrently attempt to get the watchpoint for the lexical binding and look into it by using `isStillValid()` to avoid
infinite compile-and-fail loop.
When the global lexical binding epoch overflows we iterate all the live CodeBlock and update the op_resolve_scope's epoch. Even if the shadowing
happens, it is OK if we bump the epoch, since op_resolve_scope will return JSGlobalLexicalEnvironment instead of JSGlobalObject, and following
structure check in op_put_to_scope and op_get_from_scope fail. We do not need to update op_get_from_scope and op_put_to_scope because of the same
reason.
* bytecode/BytecodeList.rb:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::notifyLexicalBindingUpdate):
(JSC::CodeBlock::notifyLexicalBindingShadowing): Deleted.
* bytecode/CodeBlock.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGDesiredGlobalProperties.cpp:
(JSC::DFG::DesiredGlobalProperties::isStillValidOnMainThread):
* dfg/DFGDesiredGlobalProperties.h:
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::watchGlobalProperty):
* dfg/DFGGraph.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::isStillValidOnMainThread):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_resolve_scope):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_resolve_scope):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
(JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::bumpGlobalLexicalBindingEpoch):
(JSC::JSGlobalObject::getReferencedPropertyWatchpointSet):
(JSC::JSGlobalObject::ensureReferencedPropertyWatchpointSet):
(JSC::JSGlobalObject::notifyLexicalBindingShadowing): Deleted.
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::globalLexicalBindingEpoch const):
(JSC::JSGlobalObject::globalLexicalBindingEpochOffset):
(JSC::JSGlobalObject::addressOfGlobalLexicalBindingEpoch):
* runtime/Options.cpp:
(JSC::correctOptions):
(JSC::Options::initialize):
(JSC::Options::setOptions):
(JSC::Options::setOptionWithoutAlias):
* runtime/Options.h:
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties):
2019-01-21 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, roll out r240220 due to date-format-xparb regression
https://bugs.webkit.org/show_bug.cgi?id=193603
* bytecode/BytecodeList.rb:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::notifyLexicalBindingShadowing):
(JSC::CodeBlock::notifyLexicalBindingUpdate): Deleted.
* bytecode/CodeBlock.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGDesiredGlobalProperties.cpp:
(JSC::DFG::DesiredGlobalProperties::isStillValidOnMainThread):
* dfg/DFGDesiredGlobalProperties.h:
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::watchGlobalProperty): Deleted.
* dfg/DFGGraph.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::isStillValidOnMainThread):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_resolve_scope):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_resolve_scope):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
(JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::notifyLexicalBindingShadowing):
(JSC::JSGlobalObject::getReferencedPropertyWatchpointSet):
(JSC::JSGlobalObject::ensureReferencedPropertyWatchpointSet):
(JSC::JSGlobalObject::bumpGlobalLexicalBindingEpoch): Deleted.
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::globalLexicalBindingEpoch const): Deleted.
(JSC::JSGlobalObject::globalLexicalBindingEpochOffset): Deleted.
(JSC::JSGlobalObject::addressOfGlobalLexicalBindingEpoch): Deleted.
* runtime/Options.cpp:
(JSC::Options::initialize):
(JSC::Options::setOptions):
(JSC::Options::setOptionWithoutAlias):
(JSC::correctOptions): Deleted.
* runtime/Options.h:
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties):
2019-01-21 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] StrictModeTypeErrorFunction is no longer used
https://bugs.webkit.org/show_bug.cgi?id=193662
Reviewed by Mark Lam.
StrictModeTypeErrorFunction is no longer used. This patch drops it. Furthermore, it also allows us to drop
strictModeTypeErrorFunctionSpace from VM.
* runtime/Error.cpp:
(JSC::StrictModeTypeErrorFunction::destroy): Deleted.
* runtime/Error.h:
(): Deleted.
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2019-01-21 Caio Lima <ticaiolima@gmail.com>
DoesGC rule is wrong for nodes with BigIntUse
https://bugs.webkit.org/show_bug.cgi?id=193652
Reviewed by Saam Barati.
Former rule was that ValueOp does not GC. However this is wrong, since
these operations can trigger GC and mess up memory management. In the end, this
will generate wrong code because we will have wrong GC epoch value during
Store Barrier Insertion phase.
We changed this to consider BigIntUse for such nodes and properly return true when
they are BigIntUse.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
2019-01-21 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Lazily initialize JSModuleLoader
https://bugs.webkit.org/show_bug.cgi?id=193646
Reviewed by Keith Miller and Saam Barati.
Lazily initialize JSModuleLoader so that we do not need to initialize it until we need modules.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::moduleLoader const):
2019-01-20 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] sub op with 0 should be optimized
https://bugs.webkit.org/show_bug.cgi?id=190751
Reviewed by Mark Lam.
LLInt sometimes emit `subp 0, %rxx`. For example, `maxFrameExtentForSlowPathCall` is 0 in X86_64, ARM64, and ARM64E.
So `subp maxFrameExtentForSlowPathCall sp` becomes `subp 0, %rsp`. While `addp 0, %rsp` is removed in offlineasm,
sub operation does not have such an optimization. This patch applies the same optimization to sub operation already
done in add operation. Since the CPU flags changed in offlineasm's these operations are not considered (if these flags
are required, we use special branch operations instead), this optimization is sane.
One problem is that zero-extension of the 32bit register in 64bit architecture. If the instruction emission is skipped,
this won't be happen. Currently, we align our sub to add operation: we skip emission in this case.
* offlineasm/arm64.rb:
* offlineasm/x86.rb:
2019-01-20 Saam Barati <sbarati@apple.com>
DFG: When inlining DataView set* intrinsics we need to set undefined as our result
https://bugs.webkit.org/show_bug.cgi?id=193644
<rdar://problem/46209745>
Reviewed by Yusuke Suzuki.
This patch also makes it so we fail fast when we make this mistake.
I've made this mistake more than once.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2019-01-20 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Reduce size of SourceProvider
https://bugs.webkit.org/show_bug.cgi?id=193544
Reviewed by Saam Barati.
This patch attempts to reduce the dirty memory footprint by the following 3 optimizations.
1. Reordering the members of SourceProvider to reduce the size. This affects on JSC, and CachedScriptSourceProvider used in WebCore.
2. Create one SourceProvider for all the builtin code and use substring to create builtin JS functions.
This reduces # of SourceProvider created for builtins.
3. Drop m_validated flag in SourceProvider since nobody uses it. It also deletes dead code in Parser.cpp.
Unfortunately, MSVC does not accept super long C string literal. So instead, we construct combined string in a form of C array.
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
* Scripts/wkbuiltins/builtins_generate_combined_header.py:
(BuiltinsCombinedHeaderGenerator.generate_output):
* Scripts/wkbuiltins/builtins_generate_combined_implementation.py:
(BuiltinsCombinedImplementationGenerator.generate_output):
* Scripts/wkbuiltins/builtins_generate_separate_implementation.py:
(BuiltinsSeparateImplementationGenerator.generate_output):
* Scripts/wkbuiltins/builtins_generator.py:
(BuiltinsGenerator.generate_embedded_code_data_for_function):
(BuiltinsGenerator.generate_embedded_code_string_section_for_data):
(BuiltinsGenerator.generate_embedded_code_string_section_for_function): Deleted.
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::BuiltinExecutables):
(JSC::JSC_FOREACH_BUILTIN_CODE):
(JSC::BuiltinExecutables::createExecutable):
* builtins/BuiltinExecutables.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::Parser):
(JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
(JSC::Parser<LexerType>::shouldCheckPropertyForUnderscoreProtoDuplicate):
(JSC::Parser<LexerType>::parseObjectLiteral):
(JSC::Parser<LexerType>::parseUnaryExpression):
* parser/Parser.h:
* parser/SourceCode.h:
* parser/SourceProvider.cpp:
(JSC::SourceProvider::SourceProvider):
* parser/SourceProvider.h:
(JSC::SourceProvider::isValid const): Deleted.
(JSC::SourceProvider::setValid): Deleted.
* runtime/CachedTypes.cpp:
(JSC::CachedSourceProviderShape::encode):
(JSC::CachedSourceProviderShape::decode const):
2019-01-20 Michael Catanzaro <mcatanzaro@igalia.com>
Unreviewed, fix -Wint-in-bool-context warning
https://bugs.webkit.org/show_bug.cgi?id=193483
<rdar://problem/47280522>
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::addCheckStructureForOriginalStringObjectUse):
2019-01-20 Saam Barati <sbarati@apple.com>
Rollout r240210: It broke tests on iOS
https://bugs.webkit.org/show_bug.cgi?id=193640
Unreviewed. ~2650 tests are failing on iOS.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* builtins/BuiltinNames.cpp:
(JSC::BuiltinNames::BuiltinNames):
* builtins/BuiltinNames.h:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::setConstantIdentifierSetRegisters):
* bytecode/CodeBlock.h:
* bytecode/HandlerInfo.h:
* bytecode/InstructionStream.h:
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::addSetConstant):
(JSC::UnlinkedCodeBlock::constantIdentifierSets):
* bytecode/UnlinkedEvalCodeBlock.h:
* bytecode/UnlinkedFunctionCodeBlock.h:
* bytecode/UnlinkedFunctionExecutable.h:
* bytecode/UnlinkedGlobalCodeBlock.h:
(JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock):
* bytecode/UnlinkedMetadataTable.h:
* bytecode/UnlinkedModuleProgramCodeBlock.h:
* bytecode/UnlinkedProgramCodeBlock.h:
* interpreter/Interpreter.cpp:
* jsc.cpp:
(functionQuit):
(runJSC):
* parser/SourceCode.h:
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::operator!= const): Deleted.
* parser/UnlinkedSourceCode.h:
* parser/VariableEnvironment.h:
* runtime/CachedTypes.cpp:
(): Deleted.
(JSC::Encoder::Allocation::buffer const): Deleted.
(JSC::Encoder::Allocation::offset const): Deleted.
(JSC::Encoder::Allocation::Allocation): Deleted.
(JSC::Encoder::Encoder): Deleted.
(JSC::Encoder::vm): Deleted.
(JSC::Encoder::malloc): Deleted.
(JSC::Encoder::offsetOf): Deleted.
(JSC::Encoder::cachePtr): Deleted.
(JSC::Encoder::offsetForPtr): Deleted.
(JSC::Encoder::release): Deleted.
(JSC::Encoder::Page::Page): Deleted.
(JSC::Encoder::Page::malloc): Deleted.
(JSC::Encoder::Page::buffer const): Deleted.
(JSC::Encoder::Page::size const): Deleted.
(JSC::Encoder::Page::getOffset const): Deleted.
(JSC::Encoder::allocateNewPage): Deleted.
(JSC::Decoder::Decoder): Deleted.
(JSC::Decoder::~Decoder): Deleted.
(JSC::Decoder::vm): Deleted.
(JSC::Decoder::offsetOf): Deleted.
(JSC::Decoder::cacheOffset): Deleted.
(JSC::Decoder::addFinalizer): Deleted.
(JSC::encode): Deleted.
(JSC::decode): Deleted.
(JSC::VariableLengthObject::buffer const): Deleted.
(JSC::VariableLengthObject::allocate): Deleted.
(JSC::CachedPtr::encode): Deleted.
(JSC::CachedPtr::decode const): Deleted.
(JSC::CachedPtr::operator-> const): Deleted.
(JSC::CachedPtr::get const): Deleted.
(JSC::CachedRefPtr::encode): Deleted.
(JSC::CachedRefPtr::decode const): Deleted.
(JSC::CachedWriteBarrier::encode): Deleted.
(JSC::CachedWriteBarrier::decode const): Deleted.
(JSC::CachedVector::encode): Deleted.
(JSC::CachedVector::decode const): Deleted.
(JSC::CachedPair::encode): Deleted.
(JSC::CachedPair::decode const): Deleted.
(JSC::CachedHashMap::encode): Deleted.
(JSC::CachedHashMap::decode const): Deleted.
(JSC::CachedUniquedStringImpl::encode): Deleted.
(JSC::CachedUniquedStringImpl::decode const): Deleted.
(JSC::CachedStringImpl::encode): Deleted.
(JSC::CachedStringImpl::decode const): Deleted.
(JSC::CachedString::encode): Deleted.
(JSC::CachedString::decode const): Deleted.
(JSC::CachedIdentifier::encode): Deleted.
(JSC::CachedIdentifier::decode const): Deleted.
(JSC::CachedOptional::encode): Deleted.
(JSC::CachedOptional::decode const): Deleted.
(JSC::CachedOptional::decodeAsPtr const): Deleted.
(JSC::CachedSimpleJumpTable::encode): Deleted.
(JSC::CachedSimpleJumpTable::decode const): Deleted.
(JSC::CachedStringJumpTable::encode): Deleted.
(JSC::CachedStringJumpTable::decode const): Deleted.
(JSC::CachedCodeBlockRareData::encode): Deleted.
(JSC::CachedCodeBlockRareData::decode const): Deleted.
(JSC::CachedBitVector::encode): Deleted.
(JSC::CachedBitVector::decode const): Deleted.
(JSC::CachedHashSet::encode): Deleted.
(JSC::CachedHashSet::decode const): Deleted.
(JSC::CachedConstantIdentifierSetEntry::encode): Deleted.
(JSC::CachedConstantIdentifierSetEntry::decode const): Deleted.
(JSC::CachedVariableEnvironment::encode): Deleted.
(JSC::CachedVariableEnvironment::decode const): Deleted.
(JSC::CachedArray::encode): Deleted.
(JSC::CachedArray::decode const): Deleted.
(JSC::CachedScopedArgumentsTable::encode): Deleted.
(JSC::CachedScopedArgumentsTable::decode const): Deleted.
(JSC::CachedSymbolTableEntry::encode): Deleted.
(JSC::CachedSymbolTableEntry::decode const): Deleted.
(JSC::CachedSymbolTable::encode): Deleted.
(JSC::CachedSymbolTable::decode const): Deleted.
(JSC::CachedImmutableButterfly::encode): Deleted.
(JSC::CachedImmutableButterfly::decode const): Deleted.
(JSC::CachedRegExp::encode): Deleted.
(JSC::CachedRegExp::decode const): Deleted.
(JSC::CachedTemplateObjectDescriptor::encode): Deleted.
(JSC::CachedTemplateObjectDescriptor::decode const): Deleted.
(JSC::CachedBigInt::encode): Deleted.
(JSC::CachedBigInt::decode const): Deleted.
(JSC::CachedJSValue::encode): Deleted.
(JSC::CachedJSValue::decode const): Deleted.
(JSC::CachedInstructionStream::encode): Deleted.
(JSC::CachedInstructionStream::decode const): Deleted.
(JSC::CachedMetadataTable::encode): Deleted.
(JSC::CachedMetadataTable::decode const): Deleted.
(JSC::CachedSourceOrigin::encode): Deleted.
(JSC::CachedSourceOrigin::decode const): Deleted.
(JSC::CachedTextPosition::encode): Deleted.
(JSC::CachedTextPosition::decode const): Deleted.
(JSC::CachedSourceProviderShape::encode): Deleted.
(JSC::CachedSourceProviderShape::decode const): Deleted.
(JSC::CachedStringSourceProvider::encode): Deleted.
(JSC::CachedStringSourceProvider::decode const): Deleted.
(JSC::CachedWebAssemblySourceProvider::encode): Deleted.
(JSC::CachedWebAssemblySourceProvider::decode const): Deleted.
(JSC::CachedSourceProvider::encode): Deleted.
(JSC::CachedSourceProvider::decode const): Deleted.
(JSC::CachedUnlinkedSourceCodeShape::encode): Deleted.
(JSC::CachedUnlinkedSourceCodeShape::decode const): Deleted.
(JSC::CachedSourceCode::encode): Deleted.
(JSC::CachedSourceCode::decode const): Deleted.
(JSC::CachedFunctionExecutable::firstLineOffset const): Deleted.
(JSC::CachedFunctionExecutable::lineCount const): Deleted.
(JSC::CachedFunctionExecutable::unlinkedFunctionNameStart const): Deleted.
(JSC::CachedFunctionExecutable::unlinkedBodyStartColumn const): Deleted.
(JSC::CachedFunctionExecutable::unlinkedBodyEndColumn const): Deleted.
(JSC::CachedFunctionExecutable::startOffset const): Deleted.
(JSC::CachedFunctionExecutable::sourceLength const): Deleted.
(JSC::CachedFunctionExecutable::parametersStartOffset const): Deleted.
(JSC::CachedFunctionExecutable::typeProfilingStartOffset const): Deleted.
(JSC::CachedFunctionExecutable::typeProfilingEndOffset const): Deleted.
(JSC::CachedFunctionExecutable::parameterCount const): Deleted.
(JSC::CachedFunctionExecutable::features const): Deleted.
(JSC::CachedFunctionExecutable::sourceParseMode const): Deleted.
(JSC::CachedFunctionExecutable::isInStrictContext const): Deleted.
(JSC::CachedFunctionExecutable::hasCapturedVariables const): Deleted.
(JSC::CachedFunctionExecutable::isBuiltinFunction const): Deleted.
(JSC::CachedFunctionExecutable::isBuiltinDefaultClassConstructor const): Deleted.
(JSC::CachedFunctionExecutable::constructAbility const): Deleted.
(JSC::CachedFunctionExecutable::constructorKind const): Deleted.
(JSC::CachedFunctionExecutable::functionMode const): Deleted.
(JSC::CachedFunctionExecutable::scriptMode const): Deleted.
(JSC::CachedFunctionExecutable::superBinding const): Deleted.
(JSC::CachedFunctionExecutable::derivedContextType const): Deleted.
(JSC::CachedFunctionExecutable::name const): Deleted.
(JSC::CachedFunctionExecutable::ecmaName const): Deleted.
(JSC::CachedFunctionExecutable::inferredName const): Deleted.
(JSC::CachedCodeBlock::instructions const): Deleted.
(JSC::CachedCodeBlock::thisRegister const): Deleted.
(JSC::CachedCodeBlock::scopeRegister const): Deleted.
(JSC::CachedCodeBlock::globalObjectRegister const): Deleted.
(JSC::CachedCodeBlock::sourceURLDirective const): Deleted.
(JSC::CachedCodeBlock::sourceMappingURLDirective const): Deleted.
(JSC::CachedCodeBlock::usesEval const): Deleted.
(JSC::CachedCodeBlock::isStrictMode const): Deleted.
(JSC::CachedCodeBlock::isConstructor const): Deleted.
(JSC::CachedCodeBlock::hasCapturedVariables const): Deleted.
(JSC::CachedCodeBlock::isBuiltinFunction const): Deleted.
(JSC::CachedCodeBlock::superBinding const): Deleted.
(JSC::CachedCodeBlock::scriptMode const): Deleted.
(JSC::CachedCodeBlock::isArrowFunctionContext const): Deleted.
(JSC::CachedCodeBlock::isClassContext const): Deleted.
(JSC::CachedCodeBlock::wasCompiledWithDebuggingOpcodes const): Deleted.
(JSC::CachedCodeBlock::constructorKind const): Deleted.
(JSC::CachedCodeBlock::derivedContextType const): Deleted.
(JSC::CachedCodeBlock::evalContextType const): Deleted.
(JSC::CachedCodeBlock::hasTailCalls const): Deleted.
(JSC::CachedCodeBlock::lineCount const): Deleted.
(JSC::CachedCodeBlock::endColumn const): Deleted.
(JSC::CachedCodeBlock::numVars const): Deleted.
(JSC::CachedCodeBlock::numCalleeLocals const): Deleted.
(JSC::CachedCodeBlock::numParameters const): Deleted.
(JSC::CachedCodeBlock::features const): Deleted.
(JSC::CachedCodeBlock::parseMode const): Deleted.
(JSC::CachedCodeBlock::codeType const): Deleted.
(JSC::CachedCodeBlock::rareData const): Deleted.
(JSC::CachedProgramCodeBlock::encode): Deleted.
(JSC::CachedProgramCodeBlock::decode const): Deleted.
(JSC::CachedModuleCodeBlock::encode): Deleted.
(JSC::CachedModuleCodeBlock::decode const): Deleted.
(JSC::CachedEvalCodeBlock::encode): Deleted.
(JSC::CachedEvalCodeBlock::decode const): Deleted.
(JSC::CachedFunctionCodeBlock::encode): Deleted.
(JSC::CachedFunctionCodeBlock::decode const): Deleted.
(JSC::UnlinkedFunctionCodeBlock::UnlinkedFunctionCodeBlock): Deleted.
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): Deleted.
(JSC::CachedCodeBlock<CodeBlockType>::decode const): Deleted.
(JSC::UnlinkedProgramCodeBlock::UnlinkedProgramCodeBlock): Deleted.
(JSC::UnlinkedModuleProgramCodeBlock::UnlinkedModuleProgramCodeBlock): Deleted.
(JSC::UnlinkedEvalCodeBlock::UnlinkedEvalCodeBlock): Deleted.
(JSC::CachedFunctionExecutable::encode): Deleted.
(JSC::CachedFunctionExecutable::decode const): Deleted.
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable): Deleted.
(JSC::CachedCodeBlock<CodeBlockType>::encode): Deleted.
(JSC::CachedSourceCodeKey::encode): Deleted.
(JSC::CachedSourceCodeKey::decode const): Deleted.
(JSC::CacheEntry::encode): Deleted.
(JSC::CacheEntry:: const): Deleted.
(JSC:: const): Deleted.
(JSC::encodeCodeBlock): Deleted.
(JSC::decodeCodeBlockImpl): Deleted.
* runtime/CachedTypes.h:
(JSC::decodeCodeBlock): Deleted.
* runtime/CodeCache.cpp:
(JSC::CodeCacheMap::pruneSlowCase):
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
(JSC::CodeCache::write): Deleted.
* runtime/CodeCache.h:
(JSC::CodeCacheMap::findCacheAndUpdateAge):
(JSC::CodeCache::clear):
(JSC::CodeCacheMap::begin): Deleted.
(JSC::CodeCacheMap::end): Deleted.
(JSC::CodeCacheMap::fetchFromDiskImpl): Deleted.
(): Deleted.
(JSC::writeCodeBlock): Deleted.
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::offsetOfData):
(JSC::JSBigInt::dataStorage):
* runtime/JSBigInt.h:
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/Options.h:
* runtime/RegExp.h:
* runtime/ScopedArgumentsTable.h:
* runtime/StackFrame.h:
* runtime/StructureInlines.h:
* runtime/SymbolTable.h:
2019-01-20 Saam Barati <sbarati@apple.com>
MovHint must merge NodeBytecodeUsesAsValue for its child in backwards propagation
https://bugs.webkit.org/show_bug.cgi?id=186916
<rdar://problem/41396612>
Reviewed by Yusuke Suzuki.
Otherwise, we may not think we care about the non-integral part in
a division (or perhaps overflow in an add, etc). Consider a program
like this:
```return a / b```
That gets compiled to:
```
a: ArithDiv // We don't check that the remainder is zero here.
b: MovHint(@a)
c: ForceOSRExit
d: Unreachable
```
If we don't inform @a that we care about its result in full number
accuracy, it will choose to ignore its non-integral remainder. This
makes sense if *everybody* that all uses of the Div only cared about
the integral part. However, OSR exit is not one of those users. OSR
exit cares about the fractional bits in such a Div.
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
2019-01-20 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Invalidate old scope operations using global lexical binding epoch
https://bugs.webkit.org/show_bug.cgi?id=193603
<rdar://problem/47380869>
Reviewed by Saam Barati.
Even if the global lexical binding does not shadow the global property at that time, we need to clear the cached information in
scope related operations since we may have a global property previously. Consider the following example,
foo = 0;
function get() { return foo; }
print(get()); // 0
print(get()); // 0
delete globalThis.foo;
$.evalScript(`const foo = 42;`);
print(get()); // Should be 42, but it returns 0 if the cached information in get() is not cleared.
To invalidate the cache easily, we introduce global lexical binding epoch. It is bumped every time we introduce a new lexical binding
into JSGlobalLexicalEnvironment, since that name could shadow the global property name previously. In op_resolve_scope, we first check
the epoch stored in the metadata, and go to slow path if it is not equal to the current epoch. Our slow path code convert the scope
operation to the appropriate one even if the resolve type is not UnresolvedProperty type. After updating the resolve type of the bytecode,
we update the cached epoch to the current one, so that we can use the cached information as long as we stay in the same epoch.
In op_get_from_scope and op_put_to_scope, we do not use this epoch since Structure check can do the same thing instead. If op_resolve_type
is updated by the epoch, and if it starts returning JSGlobalLexicalEnvironment instead JSGlobalObject, obviously the structure check fails.
And in the slow path, we update op_get_from_scope and op_put_to_scope appropriately.
So, the metadata for scope related bytecodes are eventually updated to the appropriate one. In DFG and FTL, we use the watchpoint based approach.
In DFG and FTL, we concurrently attempt to get the watchpoint for the lexical binding and look into it by using `isStillValid()` to avoid
infinite compile-and-fail loop.
When the global lexical binding epoch overflows we iterate all the live CodeBlock and update the op_resolve_scope's epoch. Even if the shadowing
happens, it is OK if we bump the epoch, since op_resolve_scope will return JSGlobalLexicalEnvironment instead of JSGlobalObject, and following
structure check in op_put_to_scope and op_get_from_scope fail. We do not need to update op_get_from_scope and op_put_to_scope because of the same
reason.
* bytecode/BytecodeList.rb:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::notifyLexicalBindingUpdate):
(JSC::CodeBlock::notifyLexicalBindingShadowing): Deleted.
* bytecode/CodeBlock.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGDesiredGlobalProperties.cpp:
(JSC::DFG::DesiredGlobalProperties::isStillValidOnMainThread):
* dfg/DFGDesiredGlobalProperties.h:
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::watchGlobalProperty):
* dfg/DFGGraph.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::isStillValidOnMainThread):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_resolve_scope):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_resolve_scope):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
(JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::bumpGlobalLexicalBindingEpoch):
(JSC::JSGlobalObject::getReferencedPropertyWatchpointSet):
(JSC::JSGlobalObject::ensureReferencedPropertyWatchpointSet):
(JSC::JSGlobalObject::notifyLexicalBindingShadowing): Deleted.
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::globalLexicalBindingEpoch const):
(JSC::JSGlobalObject::globalLexicalBindingEpochOffset):
(JSC::JSGlobalObject::addressOfGlobalLexicalBindingEpoch):
* runtime/Options.cpp:
(JSC::correctOptions):
(JSC::Options::initialize):
(JSC::Options::setOptions):
(JSC::Options::setOptionWithoutAlias):
* runtime/Options.h:
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties):
2019-01-20 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Shrink data structure size in JSC/heap
https://bugs.webkit.org/show_bug.cgi?id=193612
Reviewed by Saam Barati.
This patch reduces the size of data structures in JSC/heap. Basically, we reorder the members to remove paddings.
For Subspace, we drop CellAttributes `m_attributes`. Instead, we use `heapCellType->attributes()`. And we use
FreeList::cellSize() instead of holding m_cellSize in LocalAllocator.
This change reduces the size of JSC::VM too since it includes JSC::Heap. The size of VM becomes from 78208 to 76696.
* heap/BlockDirectory.cpp:
* heap/BlockDirectory.h:
* heap/CollectionScope.h:
* heap/CompleteSubspace.cpp:
(JSC::CompleteSubspace::allocatorForSlow):
* heap/FreeList.h:
(JSC::FreeList::offsetOfCellSize):
(JSC::FreeList::cellSize const):
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::updateObjectCounts):
(JSC::Heap::addToRememberedSet):
(JSC::Heap::runBeginPhase):
(JSC::Heap::willStartCollection):
(JSC::Heap::pruneStaleEntriesFromWeakGCMaps):
(JSC::Heap::deleteSourceProviderCaches):
(JSC::Heap::notifyIncrementalSweeper):
(JSC::Heap::updateAllocationLimits):
* heap/Heap.h:
* heap/IsoAlignedMemoryAllocator.h:
* heap/LargeAllocation.cpp:
* heap/LocalAllocator.cpp:
(JSC::LocalAllocator::LocalAllocator):
* heap/LocalAllocator.h:
(JSC::LocalAllocator::cellSize const):
(JSC::LocalAllocator::offsetOfCellSize):
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::MarkedSpace):
* heap/MarkedSpace.h:
* heap/MarkingConstraint.h:
* heap/Subspace.cpp:
(JSC::Subspace::initialize):
* heap/Subspace.h:
(JSC::Subspace::attributes const): Deleted.
* heap/SubspaceInlines.h:
(JSC::Subspace::forEachMarkedCell):
(JSC::Subspace::forEachMarkedCellInParallel):
(JSC::Subspace::forEachLiveCell):
(JSC::Subspace::attributes const):
2019-01-20 Tadeu Zagallo <tzagallo@apple.com>
Cache bytecode to disk
https://bugs.webkit.org/show_bug.cgi?id=192782
<rdar://problem/46084932>
Reviewed by Keith Miller.
Add the logic to serialize and deserialize the new JSC bytecode. For now,
the cache is only used for tests.
Each class that can be serialized has a counterpart in CachedTypes, which
handles the decoding and encoding. When decoding, the cached objects are
mmap'd from disk, but only used for creating instances of the respective
in-memory version of each object. Ideally, the mmap'd objects should be
used at runtime in the future.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* builtins/BuiltinNames.cpp:
(JSC::BuiltinNames::BuiltinNames):
* builtins/BuiltinNames.h:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::setConstantIdentifierSetRegisters):
* bytecode/CodeBlock.h:
* bytecode/HandlerInfo.h:
(JSC::UnlinkedHandlerInfo::UnlinkedHandlerInfo):
* bytecode/InstructionStream.h:
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::addSetConstant):
(JSC::UnlinkedCodeBlock::constantIdentifierSets):
* bytecode/UnlinkedEvalCodeBlock.h:
* bytecode/UnlinkedFunctionCodeBlock.h:
* bytecode/UnlinkedFunctionExecutable.h:
* bytecode/UnlinkedGlobalCodeBlock.h:
(JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock):
* bytecode/UnlinkedMetadataTable.h:
* bytecode/UnlinkedModuleProgramCodeBlock.h:
* bytecode/UnlinkedProgramCodeBlock.h:
* interpreter/Interpreter.cpp:
* jsc.cpp:
(functionQuit):
(runJSC):
* parser/SourceCode.h:
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::operator!= const):
* parser/UnlinkedSourceCode.h:
* parser/VariableEnvironment.h:
* runtime/CachedTypes.cpp: Added.
(JSC::Encoder::Allocation::buffer const):
(JSC::Encoder::Allocation::offset const):
(JSC::Encoder::Allocation::Allocation):
(JSC::Encoder::Encoder):
(JSC::Encoder::vm):
(JSC::Encoder::malloc):
(JSC::Encoder::offsetOf):
(JSC::Encoder::cachePtr):
(JSC::Encoder::offsetForPtr):
(JSC::Encoder::release):
(JSC::Encoder::Page::Page):
(JSC::Encoder::Page::malloc):
(JSC::Encoder::Page::buffer const):
(JSC::Encoder::Page::size const):
(JSC::Encoder::Page::getOffset const):
(JSC::Encoder::allocateNewPage):
(JSC::Decoder::Decoder):
(JSC::Decoder::~Decoder):
(JSC::Decoder::vm):
(JSC::Decoder::offsetOf):
(JSC::Decoder::cacheOffset):
(JSC::Decoder::addFinalizer):
(JSC::encode):
(JSC::decode):
(JSC::VariableLengthObject::buffer const):
(JSC::VariableLengthObject::allocate):
(JSC::CachedPtr::encode):
(JSC::CachedPtr::decode const):
(JSC::CachedPtr::operator-> const):
(JSC::CachedPtr::get const):
(JSC::CachedRefPtr::encode):
(JSC::CachedRefPtr::decode const):
(JSC::CachedWriteBarrier::encode):
(JSC::CachedWriteBarrier::decode const):
(JSC::CachedVector::encode):
(JSC::CachedVector::decode const):
(JSC::CachedPair::encode):
(JSC::CachedPair::decode const):
(JSC::CachedHashMap::encode):
(JSC::CachedHashMap::decode const):
(JSC::CachedUniquedStringImpl::encode):
(JSC::CachedUniquedStringImpl::decode const):
(JSC::CachedStringImpl::encode):
(JSC::CachedStringImpl::decode const):
(JSC::CachedString::encode):
(JSC::CachedString::decode const):
(JSC::CachedIdentifier::encode):
(JSC::CachedIdentifier::decode const):
(JSC::CachedOptional::encode):
(JSC::CachedOptional::decode const):
(JSC::CachedOptional::decodeAsPtr const):
(JSC::CachedSimpleJumpTable::encode):
(JSC::CachedSimpleJumpTable::decode const):
(JSC::CachedStringJumpTable::encode):
(JSC::CachedStringJumpTable::decode const):
(JSC::CachedCodeBlockRareData::encode):
(JSC::CachedCodeBlockRareData::decode const):
(JSC::CachedBitVector::encode):
(JSC::CachedBitVector::decode const):
(JSC::CachedHashSet::encode):
(JSC::CachedHashSet::decode const):
(JSC::CachedConstantIdentifierSetEntry::encode):
(JSC::CachedConstantIdentifierSetEntry::decode const):
(JSC::CachedVariableEnvironment::encode):
(JSC::CachedVariableEnvironment::decode const):
(JSC::CachedArray::encode):
(JSC::CachedArray::decode const):
(JSC::CachedScopedArgumentsTable::encode):
(JSC::CachedScopedArgumentsTable::decode const):
(JSC::CachedSymbolTableEntry::encode):
(JSC::CachedSymbolTableEntry::decode const):
(JSC::CachedSymbolTable::encode):
(JSC::CachedSymbolTable::decode const):
(JSC::CachedImmutableButterfly::encode):
(JSC::CachedImmutableButterfly::decode const):
(JSC::CachedRegExp::encode):
(JSC::CachedRegExp::decode const):
(JSC::CachedTemplateObjectDescriptor::encode):
(JSC::CachedTemplateObjectDescriptor::decode const):
(JSC::CachedBigInt::encode):
(JSC::CachedBigInt::decode const):
(JSC::CachedJSValue::encode):
(JSC::CachedJSValue::decode const):
(JSC::CachedInstructionStream::encode):
(JSC::CachedInstructionStream::decode const):
(JSC::CachedMetadataTable::encode):
(JSC::CachedMetadataTable::decode const):
(JSC::CachedSourceOrigin::encode):
(JSC::CachedSourceOrigin::decode const):
(JSC::CachedTextPosition::encode):
(JSC::CachedTextPosition::decode const):
(JSC::CachedSourceProviderShape::encode):
(JSC::CachedSourceProviderShape::decode const):
(JSC::CachedStringSourceProvider::encode):
(JSC::CachedStringSourceProvider::decode const):
(JSC::CachedWebAssemblySourceProvider::encode):
(JSC::CachedWebAssemblySourceProvider::decode const):
(JSC::CachedSourceProvider::encode):
(JSC::CachedSourceProvider::decode const):
(JSC::CachedUnlinkedSourceCodeShape::encode):
(JSC::CachedUnlinkedSourceCodeShape::decode const):
(JSC::CachedSourceCode::encode):
(JSC::CachedSourceCode::decode const):
(JSC::CachedFunctionExecutable::firstLineOffset const):
(JSC::CachedFunctionExecutable::lineCount const):
(JSC::CachedFunctionExecutable::unlinkedFunctionNameStart const):
(JSC::CachedFunctionExecutable::unlinkedBodyStartColumn const):
(JSC::CachedFunctionExecutable::unlinkedBodyEndColumn const):
(JSC::CachedFunctionExecutable::startOffset const):
(JSC::CachedFunctionExecutable::sourceLength const):
(JSC::CachedFunctionExecutable::parametersStartOffset const):
(JSC::CachedFunctionExecutable::typeProfilingStartOffset const):
(JSC::CachedFunctionExecutable::typeProfilingEndOffset const):
(JSC::CachedFunctionExecutable::parameterCount const):
(JSC::CachedFunctionExecutable::features const):
(JSC::CachedFunctionExecutable::sourceParseMode const):
(JSC::CachedFunctionExecutable::isInStrictContext const):
(JSC::CachedFunctionExecutable::hasCapturedVariables const):
(JSC::CachedFunctionExecutable::isBuiltinFunction const):
(JSC::CachedFunctionExecutable::isBuiltinDefaultClassConstructor const):
(JSC::CachedFunctionExecutable::constructAbility const):
(JSC::CachedFunctionExecutable::constructorKind const):
(JSC::CachedFunctionExecutable::functionMode const):
(JSC::CachedFunctionExecutable::scriptMode const):
(JSC::CachedFunctionExecutable::superBinding const):
(JSC::CachedFunctionExecutable::derivedContextType const):
(JSC::CachedFunctionExecutable::name const):
(JSC::CachedFunctionExecutable::ecmaName const):
(JSC::CachedFunctionExecutable::inferredName const):
(JSC::CachedCodeBlock::instructions const):
(JSC::CachedCodeBlock::thisRegister const):
(JSC::CachedCodeBlock::scopeRegister const):
(JSC::CachedCodeBlock::globalObjectRegister const):
(JSC::CachedCodeBlock::sourceURLDirective const):
(JSC::CachedCodeBlock::sourceMappingURLDirective const):
(JSC::CachedCodeBlock::usesEval const):
(JSC::CachedCodeBlock::isStrictMode const):
(JSC::CachedCodeBlock::isConstructor const):
(JSC::CachedCodeBlock::hasCapturedVariables const):
(JSC::CachedCodeBlock::isBuiltinFunction const):
(JSC::CachedCodeBlock::superBinding const):
(JSC::CachedCodeBlock::scriptMode const):
(JSC::CachedCodeBlock::isArrowFunctionContext const):
(JSC::CachedCodeBlock::isClassContext const):
(JSC::CachedCodeBlock::wasCompiledWithDebuggingOpcodes const):
(JSC::CachedCodeBlock::constructorKind const):
(JSC::CachedCodeBlock::derivedContextType const):
(JSC::CachedCodeBlock::evalContextType const):
(JSC::CachedCodeBlock::hasTailCalls const):
(JSC::CachedCodeBlock::lineCount const):
(JSC::CachedCodeBlock::endColumn const):
(JSC::CachedCodeBlock::numVars const):
(JSC::CachedCodeBlock::numCalleeLocals const):
(JSC::CachedCodeBlock::numParameters const):
(JSC::CachedCodeBlock::features const):
(JSC::CachedCodeBlock::parseMode const):
(JSC::CachedCodeBlock::codeType const):
(JSC::CachedCodeBlock::rareData const):
(JSC::CachedProgramCodeBlock::encode):
(JSC::CachedProgramCodeBlock::decode const):
(JSC::CachedModuleCodeBlock::encode):
(JSC::CachedModuleCodeBlock::decode const):
(JSC::CachedEvalCodeBlock::encode):
(JSC::CachedEvalCodeBlock::decode const):
(JSC::CachedFunctionCodeBlock::encode):
(JSC::CachedFunctionCodeBlock::decode const):
(JSC::UnlinkedFunctionCodeBlock::UnlinkedFunctionCodeBlock):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
(JSC::CachedCodeBlock<CodeBlockType>::decode const):
(JSC::UnlinkedProgramCodeBlock::UnlinkedProgramCodeBlock):
(JSC::UnlinkedModuleProgramCodeBlock::UnlinkedModuleProgramCodeBlock):
(JSC::UnlinkedEvalCodeBlock::UnlinkedEvalCodeBlock):
(JSC::CachedFunctionExecutable::encode):
(JSC::CachedFunctionExecutable::decode const):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::CachedCodeBlock<CodeBlockType>::encode):
(JSC::CachedSourceCodeKey::encode):
(JSC::CachedSourceCodeKey::decode const):
(JSC::CacheEntry::encode):
(JSC::CacheEntry:: const):
(JSC:: const):
(JSC::encodeCodeBlock):
(JSC::decodeCodeBlockImpl):
* runtime/CachedTypes.h: Copied from Source/JavaScriptCore/bytecode/UnlinkedGlobalCodeBlock.h.
(JSC::decodeCodeBlock):
* runtime/CodeCache.cpp:
(JSC::CodeCacheMap::pruneSlowCase):
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
(JSC::CodeCache::write):
* runtime/CodeCache.h:
(JSC::CodeCacheMap::begin):
(JSC::CodeCacheMap::end):
(JSC::CodeCacheMap::fetchFromDiskImpl):
(JSC::CodeCacheMap::findCacheAndUpdateAge):
(JSC::writeCodeBlock):
* runtime/JSBigInt.cpp:
* runtime/JSBigInt.h:
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/Options.h:
* runtime/RegExp.h:
* runtime/ScopedArgumentsTable.h:
* runtime/StackFrame.h:
* runtime/StructureInlines.h:
* runtime/SymbolTable.h:
2019-01-20 Antoine Quint <graouts@apple.com>
Add a POINTER_EVENTS feature flag
https://bugs.webkit.org/show_bug.cgi?id=193577
<rdar://problem/47408511>
Unreviewed. Also enable Pointer Events for iosmac.
* Configurations/FeatureDefines.xcconfig:
2019-01-19 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Reorder JSSegmentedVariableObject member for preparation of JSGlobalObject memory reduction
https://bugs.webkit.org/show_bug.cgi?id=193609
Reviewed by Sam Weinig.
Basically, we should order the members in large => small order not to add paddings.
* runtime/JSSegmentedVariableObject.h:
2019-01-19 Antoine Quint <graouts@apple.com>
Add a POINTER_EVENTS feature flag
https://bugs.webkit.org/show_bug.cgi?id=193577
Reviewed by Dean Jackson.
* Configurations/FeatureDefines.xcconfig:
2019-01-18 Keith Miller <keith_miller@apple.com>
JSScript API should only take ascii files.
https://bugs.webkit.org/show_bug.cgi?id=193420
Reviewed by Saam Barati.
This patch leaves the UTF8 method for binary compatablity, which
will be removed later.
* API/JSScript.h:
* API/JSScript.mm:
(fillBufferWithContentsOfFile):
(+[JSScript scriptFromASCIIFile:inVirtualMachine:withCodeSigning:andBytecodeCache:]):
(+[JSScript scriptFromUTF8File:inVirtualMachine:withCodeSigning:andBytecodeCache:]):
* API/tests/testapi.mm:
(-[JSContextFileLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
2019-01-18 David Kilzer <ddkilzer@apple.com>
Follow-up: Gigacages should start allocations from a slide
<https://bugs.webkit.org/show_bug.cgi?id=193523>
<rdar://problem/44958707>
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::caged): Add UNUSED_PARAM(kind) to
fix the build.
2019-01-18 Jer Noble <jer.noble@apple.com>
SDK_VARIANT build destinations should be separate from non-SDK_VARIANT builds
https://bugs.webkit.org/show_bug.cgi?id=189553
Reviewed by Tim Horton.
* Configurations/Base.xcconfig:
* Configurations/SDKVariant.xcconfig: Added.
2019-01-18 Keith Miller <keith_miller@apple.com>
Gigacages should start allocations from a slide
https://bugs.webkit.org/show_bug.cgi?id=193523
Reviewed by Mark Lam.
This patch changes some macros into constants since macros are the
devil.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::caged):
* llint/LowLevelInterpreter64.asm:
2019-01-18 Matt Lewis <jlewis3@apple.com>
Unreviewed, rolling out r240160.
This broke multiple internal builds.
Reverted changeset:
"Gigacages should start allocations from a slide"
https://bugs.webkit.org/show_bug.cgi?id=193523
https://trac.webkit.org/changeset/240160
2019-01-18 Keith Miller <keith_miller@apple.com>
Gigacages should start allocations from a slide
https://bugs.webkit.org/show_bug.cgi?id=193523
Reviewed by Mark Lam.
This patch changes some macros into constants since macros are the
devil.
* llint/LowLevelInterpreter64.asm:
2019-01-17 Mark Lam <mark.lam@apple.com>
Audit bytecode fields and ensure that LLInt instructions for accessing them are appropriate.
https://bugs.webkit.org/show_bug.cgi?id=193557
<rdar://problem/47369125>
Reviewed by Yusuke Suzuki.
1. Rename some bytecode fields so that it's easier to discern whether the LLInt
is accessing them the right way:
- distinguish between targetVirtualRegister and targetLabel.
- name all StructureID fields as structureID (oldStructureID, newStructureID)
instead of structure (oldStructure, newStructure).
2. Use bitwise_cast in struct Fits when sizeof(T) == size.
This prevents potential undefined behavior issues arising from doing
assignments with reinterpret_cast'ed pointers.
3. Make Special::Pointer an unsigned type (previously int).
Make ResolveType an unsigned type (previously int).
4. In LowLevelInterpreter*.asm:
- rename the op macro argument to opcodeName or opcodeStruct respectively.
This makes it clearer which argument type the macro is working with.
- rename the name macro argument to opcodeName.
- fix operator types to match the field type being accessed. The following
may have resulted in bugs before:
1. The following should be read with getu() instead of get() because they
are unsigned ints:
OpSwitchImm::m_tableIndex
OpSwitchChar::m_tableIndex
OpGetFromArguments::m_index
OpPutToArguments::m_index
OpGetRestLength::m_numParametersToSkip
OpJneqPtr::m_specialPointer should also be read with getu() though this
wasn't a bug because it was previously an int by default, and is only
changed to an unsigned int in this patch.
2.The following should be read with loadi (not loadp) because they are of
unsigned type (not a pointer):
OpResolveScope::Metadata::m_resolveType
CodeBlock::m_numParameters (see prepareForTailCall)
3. OpPutToScope::Metadata::m_operand should be read with loadp (not loadis)
because it is a uintptr_t.
4. The following should be read with loadi (not loadis) because they are
unsigned ints:
OpNegate::Metadata::m_arithProfile + ArithProfile::m_bits
OpPutById::Metadata::m_oldStructureID
OpPutToScope::Metadata::m_getPutInfo + GetPutInfo::m_operand
These may not have manifested in bugs because the operations that follow
the load are 32-bit instructions which ignore the high word.
5. Give class GetPutInfo a default constructor so that we can use bitwise_cast
on it. Also befriend LLIntOffsetsExtractor so that we can take the offset of
m_operand in it.
* bytecode/ArithProfile.h:
* bytecode/BytecodeList.rb:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::finalizeLLIntInlineCaches):
* bytecode/Fits.h:
* bytecode/GetByIdMetadata.h:
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFromLLInt):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::clearLLIntGetByIdCache):
* bytecode/PreciseJumpTargetsInlines.h:
(JSC::jumpTargetForInstruction):
(JSC::updateStoredJumpTargetsForInstruction):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
* bytecode/SpecialPointer.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::Label::setLocation):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_compareAndJump):
(JSC::JIT::emit_compareUnsignedAndJump):
(JSC::JIT::emit_compareAndJumpSlow):
* jit/JITArithmetic32_64.cpp:
(JSC::JIT::emit_compareAndJump):
(JSC::JIT::emit_compareUnsignedAndJump):
(JSC::JIT::emit_compareAndJumpSlow):
(JSC::JIT::emitBinaryDoubleOp):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_jmp):
(JSC::JIT::emit_op_jfalse):
(JSC::JIT::emit_op_jeq_null):
(JSC::JIT::emit_op_jneq_null):
(JSC::JIT::emit_op_jneq_ptr):
(JSC::JIT::emit_op_jeq):
(JSC::JIT::emit_op_jtrue):
(JSC::JIT::emit_op_jneq):
(JSC::JIT::compileOpStrictEqJump):
(JSC::JIT::emitSlow_op_jstricteq):
(JSC::JIT::emitSlow_op_jnstricteq):
(JSC::JIT::emit_op_check_tdz):
(JSC::JIT::emitSlow_op_jeq):
(JSC::JIT::emitSlow_op_jneq):
(JSC::JIT::emit_op_profile_type):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_jmp):
(JSC::JIT::emit_op_jfalse):
(JSC::JIT::emit_op_jtrue):
(JSC::JIT::emit_op_jeq_null):
(JSC::JIT::emit_op_jneq_null):
(JSC::JIT::emit_op_jneq_ptr):
(JSC::JIT::emit_op_jeq):
(JSC::JIT::emitSlow_op_jeq):
(JSC::JIT::emit_op_jneq):
(JSC::JIT::emitSlow_op_jneq):
(JSC::JIT::compileOpStrictEqJump):
(JSC::JIT::emitSlow_op_jstricteq):
(JSC::JIT::emitSlow_op_jnstricteq):
(JSC::JIT::emit_op_check_tdz):
(JSC::JIT::emit_op_profile_type):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::setupGetByIdPrototypeCache):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
* runtime/GetPutInfo.h:
2019-01-17 Truitt Savell <tsavell@apple.com>
Unreviewed, rolling out r240124.
This commit broke an internal build.
Reverted changeset:
"SDK_VARIANT build destinations should be separate from non-
SDK_VARIANT builds"
https://bugs.webkit.org/show_bug.cgi?id=189553
https://trac.webkit.org/changeset/240124
2019-01-17 Jer Noble <jer.noble@apple.com>
SDK_VARIANT build destinations should be separate from non-SDK_VARIANT builds
https://bugs.webkit.org/show_bug.cgi?id=189553
Reviewed by Tim Horton.
* Configurations/Base.xcconfig:
* Configurations/SDKVariant.xcconfig: Added.
2019-01-17 Saam barati <sbarati@apple.com>
StringObjectUse should not be a structure check for the original string object structure
https://bugs.webkit.org/show_bug.cgi?id=193483
<rdar://problem/47280522>
Reviewed by Yusuke Suzuki.
Prior to this patch, the use kind for StringObjectUse implied that we
do a StructureCheck on the input operand for the *original* StringObject
structure. This is generally not how we use UseKinds, so it's no surprise
that this is buggy. A UseKind should map to a set of SpeculatedTypes, not an
actual set of structures. This patch changes the meaning of StringObjectUse
to mean an object where jsDynamicCast<StringObject*> would succeed.
This patch also fixes a bug that was caused by the old and weird usage of the
UseKind to mean StructureCheck. Consider a program like this:
```
S1 = Original StringObject structure
S2 = Original StringObject structure with the field "f" added
a: GetLocal()
b: CheckStructure(@a, {S2})
c: ToString(StringObject:@a)
```
According to AI, in the above program, we would exit at @c, since
StringObject:@a implies a structure check of {S1}, and the intersection
of {S1} and {S2} is {}. So, we'd convert the program to be:
```
a: GetLocal()
b: CheckStructure(@a, {S2})
c: Check(StringObject:@a)
d: Unreachable
```
However, AI would set the proof status of the StringObject:@a edge
to be proven, since the SpeculatedType for @a is SpecStringObject.
This was incorrect of AI to do because the SpeculatedType itself
didn't capture the full power of StringObjectUse. However, having
a UseKind mean CheckStructure is weird precisely because what AI was
doing is a natural fit to how we typically we think about UseKinds.
So the above program would then incorrectly be converted to this, and
we'd crash when reaching the Unreachable node:
```
a: GetLocal()
b: CheckStructure(@a, {S2})
d: Unreachable
```
This patch makes it so that StringObjectUse just means that the object that
filters through a StringObjectUse check must !!jsDynamicCast<StringObject*>.
This is now in line with all other UseKinds. It also lets us simplify a bunch
of other code that had weird checks for the StringObjectUse UseKind.
This patch also makes it so that anywhere where we used to rely on
StringObjectUse implying a structure check we actually emit an explicit
CheckStructure node.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/ExitKind.cpp:
(JSC::exitKindToString):
* bytecode/ExitKind.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGCSEPhase.cpp:
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGEdgeUsesStructure.h: Removed.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::attemptToForceStringArrayModeByToStringConversion):
(JSC::DFG::FixupPhase::addCheckStructureForOriginalStringObjectUse):
(JSC::DFG::FixupPhase::fixupToPrimitive):
(JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor):
(JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
(JSC::DFG::FixupPhase::isStringObjectUse): Deleted.
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::canOptimizeStringObjectAccess):
* dfg/DFGMayExit.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOrStringValueOf):
(JSC::DFG::SpeculativeJIT::speculateStringObject):
(JSC::DFG::SpeculativeJIT::speculateStringOrStringObject):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure): Deleted.
* dfg/DFGUseKind.h:
(JSC::DFG::alreadyChecked):
(JSC::DFG::usesStructure): Deleted.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileToStringOrCallStringConstructorOrStringValueOf):
(JSC::FTL::DFG::LowerDFGToB3::speculateStringObject):
(JSC::FTL::DFG::LowerDFGToB3::speculateStringOrStringObject):
(JSC::FTL::DFG::LowerDFGToB3::speculateStringObjectForCell):
(JSC::FTL::DFG::LowerDFGToB3::speculateStringObjectForStructureID): Deleted.
* runtime/JSType.cpp:
(WTF::printInternal):
* runtime/JSType.h:
* runtime/StringObject.h:
(JSC::StringObject::createStructure):
* runtime/StringPrototype.h:
2019-01-17 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Add generateHeapSnapshotForGCDebugging function to dump GCDebugging data
https://bugs.webkit.org/show_bug.cgi?id=193526
Reviewed by Michael Saboff.
This patch adds generateHeapSnapshotForGCDebugging to JSC shell to dump heap snapshot JSON string with GCDebugging option.
GCDebuggingSnapshot mode is slightly different from InspectorSnapshot in terms of both the output data and the behavior.
It always takes full snapshot, and it reports internal data too. This is useful to view the live heap objects after running
the code. Also, generateHeapSnapshotForGCDebugging returns String instead of parsing it to JSObject internally by calling
JSON.parse. If we convert the String to bunch of objects by using JSON.parse, it is difficult to call generateHeapSnapshotForGCDebugging
multiple times for debugging. Currently, it only generates a large string, which is easily distinguishable in the heap inspector tool.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionGenerateHeapSnapshotForGCDebugging):
2019-01-17 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] ToThis omission in DFGByteCodeParser is wrong
https://bugs.webkit.org/show_bug.cgi?id=193513
<rdar://problem/45842236>
Reviewed by Saam Barati.
DFGByteCodeParser omitted ToThis node when we have `ToThis(ToThis(value))`. This semantics is wrong if ToThis has different semantics
in the sloppy mode and the strict mode. If we convert `ToThisInSloppyMode(ToThisInStrictMode(boolean))` to `ToThisInStrictMode(boolean)`,
we get boolean instead of BooleanObject.
This optimization is introduced more than 7 years ago, and from that, we have several optimizations that can remove such ToThis nodes
in BytecodeParser, AI, and Fixup. Furthermore, this optimization is simply wrong since `toThis()` function of JSCell can be defined
as they want. Before ensuring all the toThis function is safe, we should not fold `ToThis(ToThis(value))` => `ToThis(value)`.
This patch just removes the problematic optimization. The performance numbers look neutral.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
2019-01-16 Mark Lam <mark.lam@apple.com>
Refactor new bytecode structs so that the fields are prefixed with "m_".
https://bugs.webkit.org/show_bug.cgi?id=193467
Reviewed by Saam Barati and Tadeu Zagallo.
This makes it easier to do a manual audit of type correctness of the LLInt
instructions used to access these fields. Without this change, it would be
difficult (and error prone) to distinguish the difference between field names and
macro variables. This audit will be done after this patch lands.
* bytecode/BytecodeGeneratorification.cpp:
(JSC::BytecodeGeneratorification::BytecodeGeneratorification):
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFromLLInt):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::finalizeLLIntInlineCaches):
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffset):
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
(JSC::CodeBlock::getArrayProfile):
(JSC::CodeBlock::notifyLexicalBindingShadowing):
(JSC::CodeBlock::tryGetValueProfileForBytecodeOffset):
(JSC::CodeBlock::arithProfileForPC):
(JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
* bytecode/CodeBlockInlines.h:
(JSC::CodeBlock::forEachValueProfile):
(JSC::CodeBlock::forEachArrayProfile):
(JSC::CodeBlock::forEachArrayAllocationProfile):
(JSC::CodeBlock::forEachObjectAllocationProfile):
(JSC::CodeBlock::forEachLLIntCallLinkInfo):
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFromLLInt):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::clearLLIntGetByIdCache):
* bytecode/PreciseJumpTargetsInlines.h:
(JSC::jumpTargetForInstruction):
(JSC::extractStoredJumpTargetsForInstruction):
(JSC::updateStoredJumpTargetsForInstruction):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::dumpLineColumnEntry):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::fuseCompareAndJump):
(JSC::BytecodeGenerator::fuseTestAndJmp):
(JSC::BytecodeGenerator::emitEqualityOp):
(JSC::BytecodeGenerator::endSwitch):
(JSC::StructureForInContext::finalize):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleCall):
(JSC::DFG::ByteCodeParser::handleVarargsCall):
(JSC::DFG::ByteCodeParser::parseGetById):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::handlePutByVal):
(JSC::DFG::ByteCodeParser::handlePutAccessorById):
(JSC::DFG::ByteCodeParser::handlePutAccessorByVal):
(JSC::DFG::ByteCodeParser::handleNewFunc):
(JSC::DFG::ByteCodeParser::handleNewFuncExp):
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareCatchOSREntry):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
* generator/Argument.rb:
* generator/Metadata.rb:
* generator/Opcode.rb:
* jit/JIT.h:
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_unsigned):
(JSC::JIT::emit_compareAndJump):
(JSC::JIT::emit_compareUnsignedAndJump):
(JSC::JIT::emit_compareUnsigned):
(JSC::JIT::emit_compareAndJumpSlow):
(JSC::JIT::emit_op_inc):
(JSC::JIT::emit_op_dec):
(JSC::JIT::emit_op_mod):
(JSC::JIT::emit_op_negate):
(JSC::JIT::emitBitBinaryOpFastPath):
(JSC::JIT::emit_op_bitnot):
(JSC::JIT::emitRightShiftFastPath):
(JSC::JIT::emit_op_add):
(JSC::JIT::emitMathICFast):
(JSC::JIT::emitMathICSlow):
(JSC::JIT::emit_op_div):
(JSC::JIT::emit_op_mul):
(JSC::JIT::emit_op_sub):
* jit/JITArithmetic32_64.cpp:
(JSC::JIT::emit_compareAndJump):
(JSC::JIT::emit_compareUnsignedAndJump):
(JSC::JIT::emit_compareUnsigned):
(JSC::JIT::emit_compareAndJumpSlow):
(JSC::JIT::emit_op_unsigned):
(JSC::JIT::emit_op_inc):
(JSC::JIT::emit_op_dec):
(JSC::JIT::emitBinaryDoubleOp):
(JSC::JIT::emit_op_mod):
* jit/JITCall.cpp:
(JSC::JIT::emitPutCallResult):
(JSC::JIT::compileSetupFrame):
(JSC::JIT::compileCallEvalSlowCase):
(JSC::JIT::compileTailCall):
(JSC::JIT::compileOpCall):
* jit/JITCall32_64.cpp:
(JSC::JIT::emitPutCallResult):
(JSC::JIT::emit_op_ret):
(JSC::JIT::compileSetupFrame):
(JSC::JIT::compileCallEvalSlowCase):
(JSC::JIT::compileOpCall):
* jit/JITInlines.h:
(JSC::JIT::emitValueProfilingSiteIfProfiledOpcode):
(JSC::JIT::emitValueProfilingSite):
(JSC::JIT::copiedGetPutInfo):
(JSC::JIT::copiedArithProfile):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_mov):
(JSC::JIT::emit_op_end):
(JSC::JIT::emit_op_jmp):
(JSC::JIT::emit_op_new_object):
(JSC::JIT::emitSlow_op_new_object):
(JSC::JIT::emit_op_overrides_has_instance):
(JSC::JIT::emit_op_instanceof):
(JSC::JIT::emitSlow_op_instanceof):
(JSC::JIT::emit_op_is_empty):
(JSC::JIT::emit_op_is_undefined):
(JSC::JIT::emit_op_is_undefined_or_null):
(JSC::JIT::emit_op_is_boolean):
(JSC::JIT::emit_op_is_number):
(JSC::JIT::emit_op_is_cell_with_type):
(JSC::JIT::emit_op_is_object):
(JSC::JIT::emit_op_ret):
(JSC::JIT::emit_op_to_primitive):
(JSC::JIT::emit_op_set_function_name):
(JSC::JIT::emit_op_not):
(JSC::JIT::emit_op_jfalse):
(JSC::JIT::emit_op_jeq_null):
(JSC::JIT::emit_op_jneq_null):
(JSC::JIT::emit_op_jneq_ptr):
(JSC::JIT::emit_op_eq):
(JSC::JIT::emit_op_jeq):
(JSC::JIT::emit_op_jtrue):
(JSC::JIT::emit_op_neq):
(JSC::JIT::emit_op_jneq):
(JSC::JIT::emit_op_throw):
(JSC::JIT::compileOpStrictEq):
(JSC::JIT::compileOpStrictEqJump):
(JSC::JIT::emitSlow_op_jstricteq):
(JSC::JIT::emitSlow_op_jnstricteq):
(JSC::JIT::emit_op_to_number):
(JSC::JIT::emit_op_to_string):
(JSC::JIT::emit_op_to_object):
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_get_parent_scope):
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emit_op_switch_char):
(JSC::JIT::emit_op_switch_string):
(JSC::JIT::emit_op_debug):
(JSC::JIT::emit_op_eq_null):
(JSC::JIT::emit_op_neq_null):
(JSC::JIT::emit_op_get_scope):
(JSC::JIT::emit_op_to_this):
(JSC::JIT::emit_op_create_this):
(JSC::JIT::emit_op_check_tdz):
(JSC::JIT::emitSlow_op_eq):
(JSC::JIT::emitSlow_op_neq):
(JSC::JIT::emitSlow_op_jeq):
(JSC::JIT::emitSlow_op_jneq):
(JSC::JIT::emitSlow_op_instanceof_custom):
(JSC::JIT::emit_op_new_regexp):
(JSC::JIT::emitNewFuncCommon):
(JSC::JIT::emitNewFuncExprCommon):
(JSC::JIT::emit_op_new_array):
(JSC::JIT::emit_op_new_array_with_size):
(JSC::JIT::emit_op_has_structure_property):
(JSC::JIT::emit_op_has_indexed_property):
(JSC::JIT::emitSlow_op_has_indexed_property):
(JSC::JIT::emit_op_get_direct_pname):
(JSC::JIT::emit_op_enumerator_structure_pname):
(JSC::JIT::emit_op_enumerator_generic_pname):
(JSC::JIT::emit_op_profile_type):
(JSC::JIT::emit_op_log_shadow_chicken_prologue):
(JSC::JIT::emit_op_log_shadow_chicken_tail):
(JSC::JIT::emit_op_profile_control_flow):
(JSC::JIT::emit_op_argument_count):
(JSC::JIT::emit_op_get_rest_length):
(JSC::JIT::emit_op_get_argument):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_mov):
(JSC::JIT::emit_op_end):
(JSC::JIT::emit_op_jmp):
(JSC::JIT::emit_op_new_object):
(JSC::JIT::emitSlow_op_new_object):
(JSC::JIT::emit_op_overrides_has_instance):
(JSC::JIT::emit_op_instanceof):
(JSC::JIT::emitSlow_op_instanceof):
(JSC::JIT::emitSlow_op_instanceof_custom):
(JSC::JIT::emit_op_is_empty):
(JSC::JIT::emit_op_is_undefined):
(JSC::JIT::emit_op_is_undefined_or_null):
(JSC::JIT::emit_op_is_boolean):
(JSC::JIT::emit_op_is_number):
(JSC::JIT::emit_op_is_cell_with_type):
(JSC::JIT::emit_op_is_object):
(JSC::JIT::emit_op_to_primitive):
(JSC::JIT::emit_op_set_function_name):
(JSC::JIT::emit_op_not):
(JSC::JIT::emit_op_jfalse):
(JSC::JIT::emit_op_jtrue):
(JSC::JIT::emit_op_jeq_null):
(JSC::JIT::emit_op_jneq_null):
(JSC::JIT::emit_op_jneq_ptr):
(JSC::JIT::emit_op_eq):
(JSC::JIT::emitSlow_op_eq):
(JSC::JIT::emit_op_jeq):
(JSC::JIT::emitSlow_op_jeq):
(JSC::JIT::emit_op_neq):
(JSC::JIT::emitSlow_op_neq):
(JSC::JIT::emit_op_jneq):
(JSC::JIT::emitSlow_op_jneq):
(JSC::JIT::compileOpStrictEq):
(JSC::JIT::compileOpStrictEqJump):
(JSC::JIT::emitSlow_op_jstricteq):
(JSC::JIT::emitSlow_op_jnstricteq):
(JSC::JIT::emit_op_eq_null):
(JSC::JIT::emit_op_neq_null):
(JSC::JIT::emit_op_throw):
(JSC::JIT::emit_op_to_number):
(JSC::JIT::emit_op_to_string):
(JSC::JIT::emit_op_to_object):
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_get_parent_scope):
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emit_op_switch_char):
(JSC::JIT::emit_op_switch_string):
(JSC::JIT::emit_op_debug):
(JSC::JIT::emit_op_get_scope):
(JSC::JIT::emit_op_create_this):
(JSC::JIT::emit_op_to_this):
(JSC::JIT::emit_op_check_tdz):
(JSC::JIT::emit_op_has_structure_property):
(JSC::JIT::emit_op_has_indexed_property):
(JSC::JIT::emitSlow_op_has_indexed_property):
(JSC::JIT::emit_op_get_direct_pname):
(JSC::JIT::emit_op_enumerator_structure_pname):
(JSC::JIT::emit_op_enumerator_generic_pname):
(JSC::JIT::emit_op_profile_type):
(JSC::JIT::emit_op_log_shadow_chicken_prologue):
(JSC::JIT::emit_op_log_shadow_chicken_tail):
* jit/JITOperations.cpp:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emitGetByValWithCachedId):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emit_op_put_by_val):
(JSC::JIT::emitGenericContiguousPutByVal):
(JSC::JIT::emitArrayStoragePutByVal):
(JSC::JIT::emitPutByValWithCachedId):
(JSC::JIT::emitSlow_op_put_by_val):
(JSC::JIT::emit_op_put_getter_by_id):
(JSC::JIT::emit_op_put_setter_by_id):
(JSC::JIT::emit_op_put_getter_setter_by_id):
(JSC::JIT::emit_op_put_getter_by_val):
(JSC::JIT::emit_op_put_setter_by_val):
(JSC::JIT::emit_op_del_by_id):
(JSC::JIT::emit_op_del_by_val):
(JSC::JIT::emit_op_try_get_by_id):
(JSC::JIT::emitSlow_op_try_get_by_id):
(JSC::JIT::emit_op_get_by_id_direct):
(JSC::JIT::emitSlow_op_get_by_id_direct):
(JSC::JIT::emit_op_get_by_id):
(JSC::JIT::emit_op_get_by_id_with_this):
(JSC::JIT::emitSlow_op_get_by_id):
(JSC::JIT::emitSlow_op_get_by_id_with_this):
(JSC::JIT::emit_op_put_by_id):
(JSC::JIT::emitSlow_op_put_by_id):
(JSC::JIT::emit_op_in_by_id):
(JSC::JIT::emitSlow_op_in_by_id):
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emitSlow_op_get_from_scope):
(JSC::JIT::emit_op_put_to_scope):
(JSC::JIT::emit_op_get_from_arguments):
(JSC::JIT::emit_op_put_to_arguments):
(JSC::JIT::emitIntTypedArrayPutByVal):
(JSC::JIT::emitFloatTypedArrayPutByVal):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_put_getter_by_id):
(JSC::JIT::emit_op_put_setter_by_id):
(JSC::JIT::emit_op_put_getter_setter_by_id):
(JSC::JIT::emit_op_put_getter_by_val):
(JSC::JIT::emit_op_put_setter_by_val):
(JSC::JIT::emit_op_del_by_id):
(JSC::JIT::emit_op_del_by_val):
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emitGetByValWithCachedId):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emit_op_put_by_val):
(JSC::JIT::emitGenericContiguousPutByVal):
(JSC::JIT::emitArrayStoragePutByVal):
(JSC::JIT::emitPutByValWithCachedId):
(JSC::JIT::emitSlow_op_put_by_val):
(JSC::JIT::emit_op_try_get_by_id):
(JSC::JIT::emitSlow_op_try_get_by_id):
(JSC::JIT::emit_op_get_by_id_direct):
(JSC::JIT::emitSlow_op_get_by_id_direct):
(JSC::JIT::emit_op_get_by_id):
(JSC::JIT::emitSlow_op_get_by_id):
(JSC::JIT::emit_op_get_by_id_with_this):
(JSC::JIT::emitSlow_op_get_by_id_with_this):
(JSC::JIT::emit_op_put_by_id):
(JSC::JIT::emitSlow_op_put_by_id):
(JSC::JIT::emit_op_in_by_id):
(JSC::JIT::emitSlow_op_in_by_id):
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emitSlow_op_get_from_scope):
(JSC::JIT::emit_op_put_to_scope):
(JSC::JIT::emit_op_get_from_arguments):
(JSC::JIT::emit_op_put_to_arguments):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::setupGetByIdPrototypeCache):
(JSC::LLInt::getByVal):
(JSC::LLInt::genericCall):
(JSC::LLInt::varargsSetup):
(JSC::LLInt::commonCallEval):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
(JSC::updateArithProfileForUnaryArithOp):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
(JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
2019-01-15 Mark Lam <mark.lam@apple.com>
JSFunction::canUseAllocationProfile() should account for builtin functions with no own prototypes.
https://bugs.webkit.org/show_bug.cgi?id=193423
<rdar://problem/46209355>
Reviewed by Saam Barati.
JSFunction::canUseAllocationProfile() should return false for most builtins
because the majority of them have no prototype property. The only exception to
this is the few builtin functions that are explicitly used as constructors.
For these builtin constructors, JSFunction::canUseAllocationProfile() should also
return false if the prototype property is a getter or custom getter because
getting the prototype would then be effectful.
* dfg/DFGOperations.cpp:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSFunctionInlines.h:
(JSC::JSFunction::canUseAllocationProfile):
* runtime/PropertySlot.h:
2019-01-15 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Use KnownStringUse for GetByVal(Array::String) since AI would offer wider type information and offer non-string type after removing Check(String)
https://bugs.webkit.org/show_bug.cgi?id=193438
<rdar://problem/45581249>
Reviewed by Saam Barati and Keith Miller.
GetByVal(Array::String) emits Check(String) before that. But AI can broaden type constraint in the second run.
After the first run removes Check(String), it would happen that AI starts saying the type of 1st child is not String.
To claim that it *is* a String type, we should use KnownStringUse here.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode): StringCharAt and GetByVal(Array::String) share the underlying compiler code. We should
change StringUse => KnownStringUse for StringCharAt too. And StringCharAt and StringCharCodeAt potentially have the same
problem. This patch fixes it too.
* dfg/DFGSSALoweringPhase.cpp:
(JSC::DFG::SSALoweringPhase::lowerBoundsCheck):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt):
2019-01-15 Saam Barati <sbarati@apple.com>
Try ripping out inferred types because it might be a performance improvement
https://bugs.webkit.org/show_bug.cgi?id=190906
Reviewed by Yusuke Suzuki.
This patch removes inferred types from JSC. Initial evidence shows that
this might be around a ~1% speedup on Speedometer2 and JetStream2.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateImpl):
* bytecode/Fits.h:
* bytecode/PutByIdFlags.cpp:
(WTF::printInternal):
* bytecode/PutByIdFlags.h:
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
(JSC::PutByIdStatus::computeForStubInfo):
(JSC::PutByIdStatus::computeFor):
* bytecode/PutByIdVariant.cpp:
(JSC::PutByIdVariant::operator=):
(JSC::PutByIdVariant::replace):
(JSC::PutByIdVariant::transition):
(JSC::PutByIdVariant::setter):
(JSC::PutByIdVariant::attemptToMerge):
(JSC::PutByIdVariant::dumpInContext const):
* bytecode/PutByIdVariant.h:
(JSC::PutByIdVariant::requiredType const): Deleted.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::isType const): Deleted.
* dfg/DFGAbstractValue.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleGetByOffset):
(JSC::DFG::ByteCodeParser::handlePutByOffset):
(JSC::DFG::ByteCodeParser::load):
(JSC::DFG::ByteCodeParser::store):
(JSC::DFG::ByteCodeParser::handlePutById):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
(JSC::DFG::ConstantFoldingPhase::emitGetByOffset):
(JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
* dfg/DFGDesiredInferredType.h: Removed.
* dfg/DFGDesiredWatchpoints.cpp:
(JSC::DFG::DesiredWatchpoints::reallyAdd):
(JSC::DFG::DesiredWatchpoints::areStillValid const):
(JSC::DFG::DesiredWatchpoints::dumpInContext const):
(JSC::DFG::InferredTypeAdaptor::add): Deleted.
* dfg/DFGDesiredWatchpoints.h:
(JSC::DFG::DesiredWatchpoints::isWatched):
(JSC::DFG::InferredTypeAdaptor::hasBeenInvalidated): Deleted.
(JSC::DFG::InferredTypeAdaptor::dumpInContext): Deleted.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
(JSC::DFG::Graph::inferredValueForProperty):
(JSC::DFG::Graph::inferredTypeFor): Deleted.
* dfg/DFGGraph.h:
(JSC::DFG::Graph::registerInferredType): Deleted.
(JSC::DFG::Graph::inferredTypeForProperty): Deleted.
* dfg/DFGInferredTypeCheck.cpp: Removed.
* dfg/DFGInferredTypeCheck.h: Removed.
* dfg/DFGNode.h:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset):
(JSC::FTL::DFG::LowerDFGToB3::checkInferredType): Deleted.
* generator/DSL.rb:
* heap/Heap.cpp:
(JSC::Heap::finalizeUnconditionalFinalizers):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::branchIfNotType): Deleted.
* jit/AssemblyHelpers.h:
* jit/Repatch.cpp:
(JSC::tryCachePutByID):
* llint/LLIntOffsetsExtractor.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/InferredStructure.cpp:
(JSC::InferredStructure::InferredStructure): Deleted.
* runtime/InferredStructure.h:
(): Deleted.
* runtime/InferredStructureWatchpoint.cpp:
(JSC::InferredStructureWatchpoint::fireInternal): Deleted.
* runtime/InferredType.cpp: Removed.
* runtime/InferredType.h: Removed.
* runtime/InferredTypeInlines.h: Removed.
* runtime/InferredTypeTable.cpp: Removed.
* runtime/InferredTypeTable.h: Removed.
* runtime/JSObjectInlines.h:
(JSC::JSObject::putDirectInternal):
* runtime/Structure.cpp:
(JSC::Structure::materializePropertyTable):
(JSC::Structure::addNewPropertyTransition):
(JSC::Structure::removePropertyTransition):
(JSC::Structure::willStoreValueSlow):
(JSC::Structure::visitChildren):
* runtime/Structure.h:
(JSC::PropertyMapEntry::PropertyMapEntry):
* runtime/StructureInlines.h:
(JSC::Structure::get):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2019-01-15 Tomas Popela <tpopela@redhat.com>
Unreviewed: Fix the -Wformat compiler warnings
* jsc.cpp:
(jscmain):
2019-01-15 Caio Lima <ticaiolima@gmail.com>
DFGByteCodeParser rules for bitwise operations should consider type of their operands
https://bugs.webkit.org/show_bug.cgi?id=192966
Reviewed by Yusuke Suzuki.
This patch is changing the logic how we lower bitwise operations, to
consider only the type of input nodes and fix them during FixupPhase,
if necessary. We are also changing the prediction propagation rules
for ValueBitOp to use `getHeapPrediction()`.
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo):
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasInt32Result):
(JSC::DFG::Node::hasNumberOrAnyIntResult):
(JSC::DFG::Node::hasHeapPrediction):
* dfg/DFGPredictionPropagationPhase.cpp:
2019-01-15 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Generate the DOMDebugger domain for Augmenting Agents (ObjC protocol)
https://bugs.webkit.org/show_bug.cgi?id=193409
<rdar://problem/44349411>
Reviewed by Devin Rousso.
* inspector/scripts/codegen/objc_generator.py:
(ObjCGenerator):
Generate DOMDebugger domain ObjC interfaces.
2019-01-15 Devin Rousso <drousso@apple.com>
Web Inspector: Audit: create new IDL type for exposing special functionality in test context
https://bugs.webkit.org/show_bug.cgi?id=193149
<rdar://problem/46801218>
Reviewed by Joseph Pecoraro.
Create a new `AuditAgent` (and various subclasses for different inspection targets)
* inspector/protocol/Audit.json: Added.
Add a `run` command that is a simpler version of `Runtime.evaluate`, except that it expects
a function string instead of an arbitrary JavaScript expression.
Add `setup` and `teardown` commands that create a JavaScript object that will be passed in
to the test as an argument. Keep this object alive so that tests can add to the object and
have later tests use what was added.
* inspector/agents/InspectorAuditAgent.h: Added.
* inspector/agents/InspectorAuditAgent.cpp: Added.
(Inspector::InspectorAuditAgent::InspectorAuditAgent):
(Inspector::InspectorAuditAgent::didCreateFrontendAndBackend):
(Inspector::InspectorAuditAgent::willDestroyFrontendAndBackend):
(Inspector::InspectorAuditAgent::setup):
(Inspector::InspectorAuditAgent::run):
(Inspector::InspectorAuditAgent::teardown):
(Inspector::InspectorAuditAgent::hasActiveAudit):
(Inspector::InspectorAuditAgent::populateAuditObject):
* inspector/agents/JSGlobalObjectAuditAgent.h: Added.
* inspector/agents/JSGlobalObjectAuditAgent.cpp: Added.
(Inspector::JSGlobalObjectAuditAgent::JSGlobalObjectAuditAgent):
(Inspector::JSGlobalObjectAuditAgent::injectedScriptForEval):
* inspector/JSGlobalObjectInspectorController.h:
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
(Inspector::JSGlobalObjectInspectorController::connectFrontend):
(Inspector::JSGlobalObjectInspectorController::jsAgentContext): Added.
(Inspector::JSGlobalObjectInspectorController::createLazyAgents): Added.
* inspector/InjectedScript.h:
* inspector/InjectedScript.cpp:
(Inspector::InjectedScript::execute): Added.
(Inspector::InjectedScript::arrayFromVector): Added.
Create a version of `evaluate` that accepts a list of values to be passed in as arguments
to the function that was created by the `eval` of the given `functionString`.
* inspector/InjectedScriptSource.js:
(InjectedScript.prototype.execute): Added.
(InjectedScript.prototype.evaluate):
(InjectedScript.prototype.evaluateOnCallFrame):
(InjectedScript.prototype._evaluateAndWrap):
(InjectedScript.prototype._wrapAndSaveCall): Added.
(InjectedScript.prototype._wrapCall): Added.
(InjectedScript.prototype._evaluateOn):
Refactor the `eval` and `saveResult` logic to allow for more flexibility for other callers.
* CMakeLists.txt:
* DerivedSources-input.xcfilelist:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* UnifiedSources-input.xcfilelist:
2019-01-14 Michael Saboff <msaboff@apple.com>
Add option to JSC to dump memory footprint on script completion
https://bugs.webkit.org/show_bug.cgi?id=193422
Reviewed by Mark Lam.
Added the --footprint option to dump peak and current memory usage. This uses the same
OS calls added in r2362362.
* jsc.cpp:
(printUsageStatement):
(CommandLine::parseArguments):
(jscmain):
2019-01-14 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] AI should check the given constant's array type when folding GetByVal into constant
https://bugs.webkit.org/show_bug.cgi?id=193413
<rdar://problem/46092389>
Reviewed by Keith Miller.
If GetByVal's DFG::ArrayMode's type is Array::Double, we expect that the result of GetByVal is Double, since we already performed CheckStructure or CheckArray
to ensure this array type. But this assumption on the given value becomes wrong in AI, since CheckStructure may not perform filtering. And the proven AbstractValue
in GetByVal would not be expected one.
We have the graph before performing constant folding.
53:<!0:-> GetLocal(Check:Untyped:@77, JS|MustGen|UseAsOther, Array, arg2(C<Array>/FlushedCell), R:Stack(7), bc#37, ExitValid) predicting Array
54:< 1:-> JSConstant(JS|PureNum|UseAsOther|UseAsInt|ReallyWantsInt, BoolInt32, Int32: 0, bc#37, ExitValid)
93:<!0:-> CheckStructure(Cell:@53, MustGen, [%C7:Array], R:JSCell_structureID, Exits, bc#37, ExitValid)
94:< 1:-> GetButterfly(Check:Cell:@53, Storage|PureInt, R:JSObject_butterfly, Exits, bc#37, ExitValid)
55:<!0:-> GetByVal(Check:KnownCell:@53, Check:Int32:@54, Check:Untyped:@94, Double|MustGen|VarArgs|PureInt, AnyIntAsDouble|NonIntAsdouble, Double+OriginalCopyOnWriteArray+SaneChain+AsIs+Read, R:Butterfly_publicLength,IndexedDoubleProperties, Exits, bc#37, ExitValid) predicting StringIdent|NonIntAsdouble
And 53 is converted to JSConstant in the constant folding. It leads to constant folding attempt in GetByVal.
53:< 1:-> JSConstant(JS|UseAsOther, Array, Weak:Object: 0x117fb4370 with butterfly 0x8000e4050 (Structure %BV:Array), StructureID: 104, bc#37, ExitValid)
54:< 1:-> JSConstant(JS|PureNum|UseAsOther|UseAsInt|ReallyWantsInt, BoolInt32, Int32: 0, bc#37, ExitValid)
93:<!0:-> CheckStructure(Cell:@53, MustGen, [%C7:Array], R:JSCell_structureID, Exits, bc#37, ExitValid)
94:< 1:-> GetButterfly(Check:Cell:@53, Storage|PureInt, R:JSObject_butterfly, Exits, bc#37, ExitValid)
55:<!0:-> GetByVal(Check:KnownCell:@53, Check:Int32:@54, Check:Untyped:@94, Double|MustGen|VarArgs|PureInt, AnyIntAsDouble|NonIntAsdouble, Double+OriginalCopyOnWriteArray+SaneChain+AsIs+Read, R:Butterfly_publicLength,IndexedDoubleProperties, Exits, bc#37, ExitValid) predicting StringIdent|NonIntAsdouble
GetByVal gets constant Array from @53, and attempt to perform constant folding by leverating CoW state: if the given array's butterfly is CoW and we performed CoW array check for this GetByVal, the array would not be changed as long as the check works.
However, CheckStructure for @53 does not filter anything at AI. So, if @53 is CopyOnWrite | Contiguous array (not CopyOnWrite | Double array!), GetByVal will get a JSValue. But it does not meet the requirement of GetByVal since it has Double Array mode, and says it returns Double.
Here, CheckStructure is valid because structure of the constant object would be changed. What we should do is additional CoW & ArrayShape check in GetByVal when folding since this node leverages CoW's interesting feature,
"If CoW array check (CheckStructure etc.) is emitted by GetByVal's DFG::ArrayMode, the content is not changed from the creation!".
This patch adds ArrayShape check in addition to CoW status check in GetByVal.
Unfortunately, this crash is very flaky. In the above case, if @53 stays GetLocal after the constant folding phase, this issue does not occur. We can see this crash in r238109, but it is really hard to reproduce it in the current ToT.
I verified this fix works in r238109 with the attached test.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::fixTypeForRepresentation):
2019-01-14 Caio Lima <ticaiolima@gmail.com>
[BigInt] Literal parsing is crashing when used inside a Object Literal
https://bugs.webkit.org/show_bug.cgi?id=193404
Reviewed by Yusuke Suzuki.
Former implementation was relying into token.m_data.radix after the
call of `next()` into Parser.cpp. This is not safe because next
clobbers token.m_data.radix in some cases (e.g is CLOSEBRACE).
Now we get radix value before calling `next()` into parser and store
in a local variable.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parsePrimaryExpression):
2019-01-14 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Do not use asArrayModes() with Structures because it discards TypedArray information
https://bugs.webkit.org/show_bug.cgi?id=193372
Reviewed by Saam Barati.
When RegisteredStructureSet is filtered with AbstractValue, we use structure, SpeculationType, and ArrayModes.
However, we use asArrayModes() function with IndexingMode to compute the ArrayModes in AbstractValue. This is
wrong since this discards TypedArray ArrayModes. As a result, if RegisteredStructureSet with TypedArrays is
filtered with ArrayModes of AbstractValue populated from TypedArrays, we filter all the structures out since
AbstractValue's ArrayModes become NonArray, which is wrong with the TypedArrays' ArrayModes. This leads to
incorrect FTL code generation with MultiGetByOffset etc. nodes because,
1. AI think that this MultiGetByOffset never succeeds since all the values of RegisteredStructureSet are filtered out by the AbstractValue.
2. AI says the state of MultiGetByOffset is invalid since AI think it never succeeds.
3. So subsequent code becomes FTL crash code since AI think the execution should do OSR exit.
4. Then, FTL emits the code for MultiGetByOffset, and emits crash after that.
5. But in reality, the incoming value can match to the one of the RegisteredStructureSet value since (1)'s structures are incorrectly filtered by the incorrect ArrayModes.
6. Then, the execution goes on, and falls into the FTL crash.
This patch fixes the incorrect ArrayModes calculation by the following changes
1. Rename asArrayModes to asArrayModesIgnoringTypedArrays.
2. Fix incorrect asArrayModesIgnoringTypedArrays use in our code. Use arrayModesFromStructure instead.
3. Fix OSR exit code which stores incorrect ArrayModes to the profiles.
* bytecode/ArrayProfile.cpp:
(JSC::dumpArrayModes):
(JSC::ArrayProfile::computeUpdatedPrediction):
* bytecode/ArrayProfile.h:
(JSC::asArrayModesIgnoringTypedArrays):
(JSC::arrayModesFromStructure):
(JSC::arrayModesIncludeIgnoringTypedArrays):
(JSC::shouldUseSlowPutArrayStorage):
(JSC::shouldUseFastArrayStorage):
(JSC::shouldUseContiguous):
(JSC::shouldUseDouble):
(JSC::shouldUseInt32):
(JSC::asArrayModes): Deleted.
(JSC::arrayModeFromStructure): Deleted.
(JSC::arrayModesInclude): Deleted.
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::observeTransitions):
(JSC::DFG::AbstractValue::set):
(JSC::DFG::AbstractValue::mergeOSREntryValue):
(JSC::DFG::AbstractValue::contains const):
* dfg/DFGAbstractValue.h:
(JSC::DFG::AbstractValue::observeTransition):
(JSC::DFG::AbstractValue::validate const):
(JSC::DFG::AbstractValue::observeIndexingTypeTransition):
* dfg/DFGArrayMode.cpp:
(JSC::DFG::ArrayMode::fromObserved):
(JSC::DFG::ArrayMode::alreadyChecked const):
* dfg/DFGArrayMode.h:
(JSC::DFG::ArrayMode::structureWouldPassArrayModeFiltering):
(JSC::DFG::ArrayMode::arrayModesThatPassFiltering const):
(JSC::DFG::ArrayMode::arrayModesWithIndexingShape const):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::executeOSRExit):
(JSC::DFG::OSRExit::compileExit):
* dfg/DFGRegisteredStructureSet.cpp:
(JSC::DFG::RegisteredStructureSet::filterArrayModes):
(JSC::DFG::RegisteredStructureSet::arrayModesFromStructures const):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* jit/JITInlines.h:
(JSC::JIT::chooseArrayMode):
(JSC::arrayProfileSaw): Deleted.
* runtime/JSType.h:
(JSC::isTypedArrayType):
2019-01-14 Mark Lam <mark.lam@apple.com>
Re-enable ability to build --cloop builds.
https://bugs.webkit.org/show_bug.cgi?id=192955
<rdar://problem/46882363>
Reviewed by Saam barati and Keith Miller.
* Configurations/FeatureDefines.xcconfig:
2019-01-14 Mark Lam <mark.lam@apple.com>
Fix all CLoop JSC test failures (including some LLInt bugs due to recent bytecode format change).
https://bugs.webkit.org/show_bug.cgi?id=193402
<rdar://problem/46012309>
Reviewed by Keith Miller.
The CLoop builds via build-jsc were previously completely disabled after our
change to enable ASM LLInt build without the JIT. As a result, JSC tests have
regressed on CLoop builds. The CLoop builds and tests will be re-enabled when
the fix for https://bugs.webkit.org/show_bug.cgi?id=192955 lands. This patch
fixes all the regressions (and some old bugs) so that the CLoop test bots won't
be red when CLoop build gets re-enabled.
In this patch, we do the following:
1. Change CLoopStack::grow() to set the new CLoop stack top at the maximum
allocated capacity (after discounting the reserved zone) as opposed to setting
it only at the level that the client requested.
This fixes a small performance bug that I happened to noticed when I was
debugging a stack issue. It does not affect correctness.
2. In LowLevelInterpreter32_64.asm:
1. Fix loadConstantOrVariableTag() to use subi for computing the constant
index because the VirtualRegister offset and FirstConstantRegisterIndex
values it is operating on are both signed ints. This is just to be
pedantic. The previous use of subu will still produce a correct value.
2. Fix llintOpWithReturn() to use getu (instead of get) for reading
OpIsCellWithType::type because it is of type JSType, which is a uint8_t.
3. Fix llintOpWithMetadata() to use loadis for loading
OpGetById::Metadata::modeMetadata.protoLoadMode.cachedOffset[t5] because it
is of type PropertyOffset, which is a signed int.
4. Fix commonCallOp() to use getu for loading fields argv and argc because they
are of type unsigned for OpCall, OpConstruct, and OpTailCall, which are the
clients of commonCallOp.
5. Fix llintOpWithMetadata() and getClosureVar() to use loadp for loading
OpGetFromScope::Metadata::operand because it is of type uintptr_t.
3. In LowLevelInterpreter64.asm:
1. Fix llintOpWithReturn() to use getu for reading OpIsCellWithType::type
because it is of type JSType, which is a uint8_t.
2. Fix llintOpWithMetadata() to use loadi for loading
OpGetById::Metadata::modeMetadata.protoLoadMode.structure[t2] because it is
of type StructureID, which is a uint32_t.
Fix llintOpWithMetadata() to use loadis for loading
OpGetById::Metadata::modeMetadata.protoLoadMode.cachedOffset[t2] because it
is of type PropertyOffset, which is a signed int.
3. commonOp() should reload the metadataTable for op_catch because unlike
for the ASM LLInt, the exception unwinding code is not able to restore
"callee saved registers" for the CLoop interpreter because the CLoop uses
pseudo-registers (see the CLoopRegister class).
This was the source of many exotic Cloop failures after the bytecode format
change (which introduced the metadataTable callee saved register). Hence,
we fix it by reloading metadataTable's value on re-entry via op_catch for
exception handling. We already take care of restoring it in op_ret.
4. Fix llintOpWithMetadata() and getClosureVar() to use loadp for loading
OpGetFromScope::Metadata::operand because it is of type uintptr_t.
4. In LowLevelInterpreter.asm:
Fix metadata() to use loadi for loading metadataTable offsets because they are
of type unsigned. This was also a source of many exotic CLoop test failures.
5. Change CLoopRegister into a class with a uintptr_t as its storage element.
Previously, we were using a union to convert between various value types that
we would store in this pseudo-register. This method of type conversion is
undefined behavior according to the C++ spec. As a result, the C++ compiler
may choose to elide some CLoop statements, thereby resulting in some exotic
bugs.
We fix this by now always using accessor methods and assignment operators to
ensure that we use bitwise_cast to do the type conversions. Since bitwise_cast
uses a memcpy, this ensures that there's no undefined behavior, and that CLoop
statements won't get elided willy-nilly by the compiler.
Ditto for the CloopDobleRegisters.
Similarly, use bitwise_cast for ints2Double() and double2Ints() utility
functions.
Also use bitwise_cast (instead of reinterpret_cast) for the CLoop CAST macro.
6. Fix cloop.rb to use the new CLoopRegister and CLoopDoubleRegister classes.
Add a clLValue accessor for offlineasm operand types to distinguish
LValue use of the operands from RValue uses.
Replace the use of clearHighWord() with simply casting to uint32_t. This is
more efficient for the C++ compiler (and help speed up debug build runs).
Also fix 32-bit arithmetic operations to only set the lower 32-bit value of
the pseudo registers. This fixes some CLoop JSC test failures.
This patch has been manually tested with the JSC tests on the following builds:
64bit X86 ASM LLLint (without JIT), 64bit and 32bit X86 CLoop, and ARMv7 Cloop.
* interpreter/CLoopStack.cpp:
(JSC::CLoopStack::grow):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter.cpp:
(JSC::CLoopRegister::i const):
(JSC::CLoopRegister::u const):
(JSC::CLoopRegister::i32 const):
(JSC::CLoopRegister::u32 const):
(JSC::CLoopRegister::i8 const):
(JSC::CLoopRegister::u8 const):
(JSC::CLoopRegister::ip const):
(JSC::CLoopRegister::i8p const):
(JSC::CLoopRegister::vp const):
(JSC::CLoopRegister::cvp const):
(JSC::CLoopRegister::callFrame const):
(JSC::CLoopRegister::execState const):
(JSC::CLoopRegister::instruction const):
(JSC::CLoopRegister::vm const):
(JSC::CLoopRegister::cell const):
(JSC::CLoopRegister::protoCallFrame const):
(JSC::CLoopRegister::nativeFunc const):
(JSC::CLoopRegister::i64 const):
(JSC::CLoopRegister::u64 const):
(JSC::CLoopRegister::encodedJSValue const):
(JSC::CLoopRegister::opcode const):
(JSC::CLoopRegister::operator ExecState*):
(JSC::CLoopRegister::operator const Instruction*):
(JSC::CLoopRegister::operator JSCell*):
(JSC::CLoopRegister::operator ProtoCallFrame*):
(JSC::CLoopRegister::operator Register*):
(JSC::CLoopRegister::operator VM*):
(JSC::CLoopRegister::operator=):
(JSC::CLoopRegister::bitsAsDouble const):
(JSC::CLoopRegister::bitsAsInt64 const):
(JSC::CLoopDoubleRegister::operator T const):
(JSC::CLoopDoubleRegister::d const):
(JSC::CLoopDoubleRegister::bitsAsInt64 const):
(JSC::CLoopDoubleRegister::operator=):
(JSC::LLInt::ints2Double):
(JSC::LLInt::double2Ints):
(JSC::LLInt::decodeResult):
(JSC::CLoop::execute):
(JSC::LLInt::Ints2Double): Deleted.
(JSC::LLInt::Double2Ints): Deleted.
(JSC::CLoopRegister::CLoopRegister): Deleted.
(JSC::CLoopRegister::clearHighWord): Deleted.
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* offlineasm/cloop.rb:
2019-01-14 Keith Miller <keith_miller@apple.com>
JSC should have a module loader API
https://bugs.webkit.org/show_bug.cgi?id=191121
Reviewed by Michael Saboff.
This patch adds a new delegate to JSContext that is called to fetch
any resolved module. The resolution of a module identifier is computed
as if it were a URL on the web with the caveat that it must be a file URL.
A new class JSScript has also been added that is similar to JSScriptRef.
Right now all JSScripts are copied into memory. In the future we should
mmap the provided file into memory so the OS can evict it to disk under
pressure. Additionally, the API does not make use of the code signing path
nor the bytecode caching path, which we will add in subsequent patches.
Lastly, a couple of new convenience methods have been added. C API
conversion, can now toRef a JSValue with just a vm rather than
requiring an ExecState. Secondly, there is now a call wrapper that
does not require CallData and CallType since many places don't
care about this.
* API/APICast.h:
(toRef):
* API/JSAPIGlobalObject.cpp: Copied from Source/JavaScriptCore/API/JSVirtualMachineInternal.h.
* API/JSAPIGlobalObject.h: Added.
(JSC::JSAPIGlobalObject::create):
(JSC::JSAPIGlobalObject::createStructure):
(JSC::JSAPIGlobalObject::JSAPIGlobalObject):
* API/JSAPIGlobalObject.mm: Added.
(JSC::JSAPIGlobalObject::moduleLoaderResolve):
(JSC::JSAPIGlobalObject::moduleLoaderImportModule):
(JSC::JSAPIGlobalObject::moduleLoaderFetch):
(JSC::JSAPIGlobalObject::moduleLoaderCreateImportMetaProperties):
* API/JSAPIValueWrapper.h:
(JSC::jsAPIValueWrapper): Deleted.
* API/JSContext.h:
* API/JSContext.mm:
(-[JSContext moduleLoaderDelegate]):
(-[JSContext setModuleLoaderDelegate:]):
* API/JSContextInternal.h:
* API/JSContextPrivate.h:
* API/JSContextRef.cpp:
(JSGlobalContextCreateInGroup):
* API/JSScript.h: Added.
* API/JSScript.mm: Added.
(+[JSScript scriptWithSource:inVirtualMachine:]):
(fillBufferWithContentsOfFile):
(+[JSScript scriptFromUTF8File:inVirtualMachine:withCodeSigning:andBytecodeCache:]):
(getJSScriptSourceCode):
* API/JSScriptInternal.h: Copied from Source/JavaScriptCore/API/JSVirtualMachineInternal.h.
* API/JSValueInternal.h:
* API/JSVirtualMachineInternal.h:
* API/tests/testapi.mm:
(+[JSContextFetchDelegate contextWithBlockForFetch:]):
(-[JSContextFetchDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
(checkModuleCodeRan):
(checkModuleWasRejected):
(testFetch):
(testFetchWithTwoCycle):
(testFetchWithThreeCycle):
(testLoaderResolvesAbsoluteScriptURL):
(testLoaderRejectsNilScriptURL):
(testLoaderRejectsFailedFetch):
(testImportModuleTwice):
(+[JSContextFileLoaderDelegate newContext]):
(resolvePathToScripts):
(-[JSContextFileLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
(testLoadBasicFile):
(testObjectiveCAPI):
* API/tests/testapiScripts/basic.js: Copied from Source/JavaScriptCore/API/JSVirtualMachineInternal.h.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* SourcesCocoa.txt:
* config.h:
* postprocess-headers.sh:
* runtime/CallData.cpp:
(JSC::call):
* runtime/CallData.h:
* runtime/Completion.cpp:
(JSC::loadAndEvaluateModule):
* runtime/Completion.h:
* runtime/JSCast.h:
(JSC::jsSecureCast):
* runtime/JSGlobalObject.cpp:
(JSC::createProxyProperty):
2019-01-14 Dominik Infuehr <dinfuehr@igalia.com>
Fix property access on ARM with the baseline JIT
https://bugs.webkit.org/show_bug.cgi?id=193393
Reviewed by Yusuke Suzuki.
Code was still using currentInstruction[4] to access the instruction's metadata.
Updated to use metadata.getPutInfo and metadata.resolveType.
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emit_op_put_to_scope):
2019-01-12 Timothy Hatcher <timothy@apple.com>
Have prefers-color-scheme: light always match on macOS versions before Mojave.
https://bugs.webkit.org/show_bug.cgi?id=191655
rdar://problem/46074680
Reviewed by Megan Gardner.
* Configurations/FeatureDefines.xcconfig: ENABLE_DARK_MODE_CSS_macosx for all OS versions.
2019-01-12 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Unreviewed, fix scope check assertions
https://bugs.webkit.org/show_bug.cgi?id=193308
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::notifyLexicalBindingShadowing):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::notifyLexicalBindingShadowing):
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties):
2019-01-11 John Wilander <wilander@apple.com>
Compile out Web API Statistics Collection
https://bugs.webkit.org/show_bug.cgi?id=193370
<rdar://problem/45388584>
Reviewed by Brent Fulgham.
* Configurations/FeatureDefines.xcconfig:
Defined ENABLE_WEB_API_STATISTICS, off by default.
2019-01-11 Saam barati <sbarati@apple.com>
DFG combined liveness can be wrong for terminal basic blocks
https://bugs.webkit.org/show_bug.cgi?id=193304
<rdar://problem/45268632>
Reviewed by Yusuke Suzuki.
If a block doesn't have any successors, it can't rely on the typical
backwards liveness propagation that CombinedLiveness was doing. The phase
first got what was live in bytecode and IR at the heads of each block. Then
for each block, it made the live at tail the union of the live at head for
each successor. For a terminal block though, this could be wrong. We could
end up saying nothing is live even though many things may be live in bytecode.
We must account for what's bytecode live at the end of the block. Consider a
block that ends with:
```
ForceOSRExit
Unreachable
```
Things may definitely be live in bytecode at the tail. However, we'll
report nothing as being alive. This probably subtly breaks many analyses,
but we have a test case of it breaking the interference analysis that
the ArgumentsEliminationPhase performs.
* dfg/DFGBasicBlock.h:
(JSC::DFG::BasicBlock::last const):
* dfg/DFGCombinedLiveness.cpp:
(JSC::DFG::addBytecodeLiveness):
(JSC::DFG::liveNodesAtHead):
(JSC::DFG::CombinedLiveness::CombinedLiveness):
* dfg/DFGCombinedLiveness.h:
2019-01-11 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Global lexical bindings can shadow global variables if it is `configurable = true`
https://bugs.webkit.org/show_bug.cgi?id=193308
<rdar://problem/45546542>
Reviewed by Saam Barati.
Previously, we assumed that lexical bindings in JSGlobalLexicalEnvironment cannot shadow existing global properties.
However, it is wrong. According to the spec, we can shadow global properties if a property's attribute is configurable = true.
For example, we execute two scripts.
script1.js
bar = 42;
function load() { return bar; }
print(bar); // 42
print(load()); // 42
script2.js
let bar = 0; // This lexical binding can shadow the global.bar defined in script1.js
print(bar); // 0
print(load()); // 0
In JSC, we cache GlobalProperty resolve type and its associated information in op_resolve_type, op_get_from_scope, and op_put_to_scope.
They attempt to load a property from JSGlobalObject directly. However, once the newly added lexical binding starts shadowing this, our existing instructions
become invalid since they do not respect JSGlobalLexicalEnvironment.
In this patch, we fix this issue by introducing the following mechanisms.
1. We have a HashMap<property name, watchpoint set> in JSGlobalObject. DFG and FTL create a watchpoint set with the property name if the generated code
depends on GlobalProperty condition of op_resolve_scope etc. These watchpoint will be fired when the shadowing happens, so that our generated DFG and FTL
code will be invalidated if it depends on the condition which is no longer valid.
2. When we detect shadowing, we iterate all the live CodeBlocks which globalObject is the target one. And we rewrite instructions in them from GlobalProperty
to GlobalLexicalVar (or Dynamic precisely). So, the subsequent LLInt code just works well. "Dynamic" conversion happens when your op_put_to_scope attempts to
put a value onto a const lexical binding. This fails and it should throw a type error.
3. GlobalProperty scope operations in Baseline JIT start checking ResolveType in metadata, and emit code for GlobalProperty and GlobalLexicalVar. Once the rewrite
happens, baseline JIT continues working because it checks the rewritten metadata's ResolveType.
We use this mechanism (which is similar to haveABadTime() thing) because,
1. Shadowing should be super rare. Before r214145, we made these cases as SytaxError. Thus, before r214145, this type of code cannot be executed in WebKit.
And the number of the live CodeBlocks for the given JSGlobalObject should be small. This supports introducing rather simple (but not so efficient) mechanism
instead of the complicated one.
2. Rewriting instructions immediately forces GlobalProperty => GlobalLexicalVar / Dynamic conversion in all the possible CodeBlock. This allows us to avoid
compilation failure loop in DFG and FTL: DFG and FTL codes are invalidated by the watchpoint, but we may attempt to compile the code with the invalidated watchpoint
and GlobalProperty status if we do not rewrite it. One possible other implementation is having and checking a counter in instruction, and every time we introduce
a new shadow binding, bump the counter. And eventually executed instruction will go to the slow path and rewrite itself. However, this way leaves the not-executed-again-yet
instructions as is, and DFG and FTL repeatedly fail to compile if we just watch the invalidated watchpoint for that. Rewriting all the existing GlobalProperty immediately
avoids this situation easily.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::notifyLexicalBindingShadowing):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::scriptMode const):
* bytecode/Watchpoint.h:
(JSC::WatchpointSet::create):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGDesiredGlobalProperties.cpp: Added.
(JSC::DFG::DesiredGlobalProperties::isStillValidOnMainThread):
(JSC::DFG::DesiredGlobalProperties::reallyAdd):
* dfg/DFGDesiredGlobalProperties.h: Added.
(JSC::DFG::DesiredGlobalProperties::addLazily):
We need this DesiredGlobalProperties mechanism since we do not want to ref() the UniquedStringImpl in DFG and FTL thread.
We keep JSGlobalObject* and identifierNumber, and materialize WatchpointSets for each JSGlobalObject's property referenced
from DFG and FTL and inject CodeBlock jettison watchpoints in the main thread.
* dfg/DFGDesiredGlobalProperty.h: Added.
(JSC::DFG::DesiredGlobalProperty::DesiredGlobalProperty):
(JSC::DFG::DesiredGlobalProperty::globalObject const):
(JSC::DFG::DesiredGlobalProperty::identifierNumber const):
(JSC::DFG::DesiredGlobalProperty::operator== const):
(JSC::DFG::DesiredGlobalProperty::operator!= const):
(JSC::DFG::DesiredGlobalProperty::isHashTableDeletedValue const):
(JSC::DFG::DesiredGlobalProperty::hash const):
(JSC::DFG::DesiredGlobalProperty::dumpInContext const):
(JSC::DFG::DesiredGlobalProperty::dump const):
(JSC::DFG::DesiredGlobalPropertyHash::hash):
(JSC::DFG::DesiredGlobalPropertyHash::equal):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::globalProperties):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::reallyAdd):
(JSC::DFG::Plan::isStillValidOnMainThread):
(JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
(JSC::DFG::Plan::cancel):
* dfg/DFGPlan.h:
(JSC::DFG::Plan::globalProperties):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emit_op_put_to_scope):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emit_op_put_to_scope):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::addStaticGlobals):
(JSC::JSGlobalObject::notifyLexicalBindingShadowing):
(JSC::JSGlobalObject::getReferencedPropertyWatchpointSet):
(JSC::JSGlobalObject::ensureReferencedPropertyWatchpointSet):
* runtime/JSGlobalObject.h:
* runtime/ProgramExecutable.cpp:
(JSC::hasRestrictedGlobalProperty):
(JSC::ProgramExecutable::initializeGlobalProperties):
2019-01-11 Dominik Infuehr <dinfuehr@igalia.com>
Enable DFG on ARM/Linux again
https://bugs.webkit.org/show_bug.cgi?id=192496
Reviewed by Yusuke Suzuki.
After changing the bytecode format DFG was disabled on all 32-bit
architectures. Enable DFG now again on ARM/Linux. Do not use register
r11 in compiled DFG mode since it is already used in LLInt as metadataTable
register. Also clean up code since ARM traditional isn't supported anymore.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
(JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
* jit/CallFrameShuffler.cpp:
(JSC::CallFrameShuffler::CallFrameShuffler):
* jit/GPRInfo.h:
(JSC::GPRInfo::toIndex):
* llint/LowLevelInterpreter32_64.asm:
* offlineasm/arm.rb:
2019-01-10 Brian Burg <bburg@apple.com>
Web Inspector: incorrect type signature used for protocol enums in async command results
https://bugs.webkit.org/show_bug.cgi?id=193331
Reviewed by Devin Rousso.
When an enum is returned by an async command, the type signature should be that of the
Inspector::Protocol::* generated enum, rather than the underlying primitive type (i.e., String).
* inspector/scripts/codegen/cpp_generator.py:
(CppGenerator.cpp_type_for_formal_async_parameter):
* inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
Rebaseline generator test results.
2019-01-10 Brian Burg <bburg@apple.com>
Rebaseline inspector generator test results after recent changes.
Unreviewed test gardening.
* inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/generic/expected/fail-on-domain-availability-value.json-error:
2019-01-10 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r239825.
https://bugs.webkit.org/show_bug.cgi?id=193330
Broke tests on armv7/linux bots (Requested by guijemont on
#webkit).
Reverted changeset:
"Enable DFG on ARM/Linux again"
https://bugs.webkit.org/show_bug.cgi?id=192496
https://trac.webkit.org/changeset/239825
2019-01-10 Dominik Infuehr <dinfuehr@igalia.com>
Enable DFG on ARM/Linux again
https://bugs.webkit.org/show_bug.cgi?id=192496
Reviewed by Yusuke Suzuki.
After changing the bytecode format DFG was disabled on all 32-bit
architectures. Enable DFG now again on ARM/Linux. Do not use register
r11 in compiled DFG mode since it is already used in LLInt as metadataTable
register. Also clean up code since ARM traditional isn't supported anymore.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
(JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
* jit/CallFrameShuffler.cpp:
(JSC::CallFrameShuffler::CallFrameShuffler):
* jit/GPRInfo.h:
(JSC::GPRInfo::toIndex):
* llint/LowLevelInterpreter32_64.asm:
* offlineasm/arm.rb:
2019-01-09 Mark Lam <mark.lam@apple.com>
Restore bytecode dumper's ability to dump jump target as offset#(->targetBytecodeIndex#).
https://bugs.webkit.org/show_bug.cgi?id=193300
Reviewed by Saam Barati.
For example, instead of:
[ 95] jtrue loc11, 9
We can now again (as before the bytecode format rewrite) have:
[ 95] jtrue loc11, 9(->104)
* bytecode/BytecodeDumper.cpp:
(JSC::BytecodeDumper<Block>::printLocationAndOp):
* bytecode/BytecodeDumper.h:
(JSC::BytecodeDumper::dumpValue):
2019-01-09 Mark Lam <mark.lam@apple.com>
Gigacage disabling checks should handle the GIGACAGE_ALLOCATION_CAN_FAIL case properly.
https://bugs.webkit.org/show_bug.cgi?id=193292
<rdar://problem/46485450>
Reviewed by Yusuke Suzuki.
* runtime/VM.h:
(JSC::VM::gigacageAuxiliarySpace):
2019-01-08 Keith Miller <keith_miller@apple.com>
builtins should be able to use async/await
https://bugs.webkit.org/show_bug.cgi?id=193263
Reviewed by Saam Barati.
This patch makes it possible to use async functions when writing builtin JS code.
* Scripts/wkbuiltins/builtins_generator.py:
(BuiltinsGenerator.generate_embedded_code_string_section_for_function):
* Scripts/wkbuiltins/builtins_model.py:
(BuiltinFunction.__init__):
(BuiltinFunction.fromString):
(BuiltinFunction.__str__):
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createExecutable):
* builtins/ModuleLoader.js:
(requestInstantiate):
(async.loadModule):
(async.loadAndEvaluateModule):
(async.requestImportModule):
(loadModule): Deleted.
(): Deleted.
(loadAndEvaluateModule): Deleted.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
2019-01-08 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Array.prototype.flat/flatMap have a minor bug in ArraySpeciesCreate
https://bugs.webkit.org/show_bug.cgi?id=193127
Reviewed by Saam Barati.
`== null` is frequently used idiom to check `null` or `undefined` in JS.
However, it has a problem in terms of the builtin JS implementation: it
returns true if masquerade-as-undefined objects (e.g. document.all) come.
In this patch, we introduce a convenient builtin intrinsic @isUndefinedOrNull,
which is equivalent to C++ `JSValue::isUndefinedOrNull`. It does not consider
about masquerade-as-undefined objects, so that we can use it instead of
`value === null || value === @undefined`. We introduce is_undefined_or_null
bytecode, IsUndefinedOrNull DFG node and its DFG and FTL backends. Since
Null and Undefined have some bit patterns, we can implement this query
very efficiently.
* builtins/ArrayIteratorPrototype.js:
(next):
* builtins/ArrayPrototype.js:
(globalPrivate.arraySpeciesCreate):
* builtins/GlobalOperations.js:
(globalPrivate.speciesConstructor):
(globalPrivate.copyDataProperties):
(globalPrivate.copyDataPropertiesNoExclusions):
* builtins/MapIteratorPrototype.js:
(next):
* builtins/SetIteratorPrototype.js:
(next):
* builtins/StringIteratorPrototype.js:
(next):
* builtins/StringPrototype.js:
(match):
(repeat):
(padStart):
(padEnd):
(intrinsic.StringPrototypeReplaceIntrinsic.replace):
(search):
(split):
(concat):
(globalPrivate.createHTML):
* builtins/TypedArrayPrototype.js:
(globalPrivate.typedArraySpeciesConstructor):
(map):
(filter):
* bytecode/BytecodeIntrinsicRegistry.h:
* bytecode/BytecodeList.rb:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitIsUndefinedOrNull):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::BytecodeIntrinsicNode::emit_intrinsic_isUndefinedOrNull):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileIsUndefinedOrNull):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_is_undefined_or_null):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_is_undefined_or_null):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2019-01-08 David Kilzer <ddkilzer@apple.com>
Leak of VectorBufferBase.m_buffer (16-64 bytes) under JSC::CompactVariableEnvironment in com.apple.WebKit.WebContent running layout tests
<https://webkit.org/b/193264>
<rdar://problem/46651026>
Reviewed by Yusuke Suzuki.
* parser/VariableEnvironment.cpp:
(JSC::CompactVariableMap::Handle::~Handle): Call delete on
m_environment instead of fastFree() to make sure the destructors
for the Vector instance variables are run. This fixes the leaks
because calling fastFree() would only free the
CompactVariableEnvironment object, but not the heap-based
buffers allocated for the Vector instance variables.
2019-01-08 Joseph Pecoraro <pecoraro@apple.com>
ASSERT when paused in debugger and console evaluation causes exception
https://bugs.webkit.org/show_bug.cgi?id=193246
Reviewed by Mark Lam.
* runtime/VM.cpp:
(JSC::VM::throwException):
Improve assertion to allow for the debugger's evaluate on call frame condition.
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::callFrameAtDebuggerEntry const):
(JSC::JSGlobalObject::setCallFrameAtDebuggerEntry):
Debugger call frame only used by assertions.
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::evaluateWithScopeExtension):
* debugger/DebuggerEvalEnabler.h:
(JSC::DebuggerEvalEnabler::DebuggerEvalEnabler):
(JSC::DebuggerEvalEnabler::~DebuggerEvalEnabler):
When evaluating on a call frame, set a debug GlobalObject state.
2019-01-08 Keith Miller <keith_miller@apple.com>
Move JSValueMakeSymbol to private header
https://bugs.webkit.org/show_bug.cgi?id=193254
Reviewed by Saam Barati.
When moving other functions in JSValueRef I guess I forgot to move this one.
* API/JSObjectRefPrivate.h:
* API/JSValueRef.h:
2019-01-08 Mark Lam <mark.lam@apple.com>
Fix some typos in comments.
Not reviewed.
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
2019-01-08 Tadeu Zagallo <tzagallo@apple.com>
LLInt put_by_id uses the wrong load instruction for loading flags from the metadata
https://bugs.webkit.org/show_bug.cgi?id=193221
Reviewed by Mark Lam.
The flags are only 4 bytes, but were loaded with loadp. It used to work,
since the flags were followed by a 4-byte padding, but it broke after the
struct was compacted in r239626.
* llint/LowLevelInterpreter64.asm:
2019-01-07 Devin Rousso <drousso@apple.com>
Web Inspector: extend XHR breakpoints to work with fetch
https://bugs.webkit.org/show_bug.cgi?id=185843
<rdar://problem/40431027>
Reviewed by Matt Baker.
* inspector/protocol/DOMDebugger.json:
Rename `XHR` to `URL`.
* inspector/protocol/Debugger.json:
Add `Fetch` to `reason` enum for the `Debugger.paused` event.
2019-01-07 Devin Rousso <drousso@apple.com>
Web Inspector: Network: show secure connection details per-request
https://bugs.webkit.org/show_bug.cgi?id=191539
<rdar://problem/45979891>
Reviewed by Joseph Pecoraro.
* inspector/protocol/Security.json:
Add `Connection` type.
* inspector/protocol/Network.json:
Send `Security.Connection` information when request metrics become available.
2019-01-04 Tadeu Zagallo <tzagallo@apple.com>
Baseline version of get_by_id may corrupt metadata
https://bugs.webkit.org/show_bug.cgi?id=193085
<rdar://problem/23453006>
Reviewed by Saam Barati.
The Baseline version of get_by_id unconditionally calls `emitArrayProfilingSiteForBytecodeIndexWithCell`
if the property is `length`. However, since the bytecode rewrite, get_by_id only has an ArrayProfile entry
in the metadata if its mode is `GetByIdMode::ArrayLength`. That might result in one of two bad things:
1) get_by_id's mode is not ArrayLength, and a duplicate, out-of-line ArrayProfile entry will be created by
`CodeBlock::getOrAddArrayProfile`.
2) get_by_id's mode *is* ArrayLength and we generate the array profiling code pointing to the ArrayProfile
that lives in the metadata table. This works fine as long as get_by_id does not change modes. If that happens,
the JIT code will write into the metadata table, overwriting the 'GetByIdModeMetadata` for another mode.
Add a check to the Baseline version of get_by_id so that we only do the ArrayProfiling if the get_by_id's
mode is ArrayLength
* bytecode/BytecodeList.rb:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::getArrayProfile):
(JSC::CodeBlock::addArrayProfile): Deleted.
(JSC::CodeBlock::getOrAddArrayProfile): Deleted.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::numberOfArrayProfiles const): Deleted.
(JSC::CodeBlock::arrayProfiles): Deleted.
* bytecode/CodeBlockInlines.h:
(JSC::CodeBlock::forEachArrayProfile):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::emitArrayProfilingSiteForBytecodeIndexWithCell): Deleted.
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_get_by_id):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_get_by_id):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
2019-01-02 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Optimize Object.prototype.toString
https://bugs.webkit.org/show_bug.cgi?id=193031
Reviewed by Saam Barati.
Object.prototype.toString is frequently used for type checking.
It is called many times in wtb-lebab.js. This patch optimizes
Object.prototype.toString by the following two optimizations.
1. We should emit code looking up cached to string in DFG and FTL.
toString's result is cached in the Structure. We emit a fast path code
in DFG and FTL to lookup this cache.
2. We should not create objects for primitive values in major cases.
When Object.prototype.toString(primitive) is called, this primitive is converted
to an object by calling ToObject. But if the result is appropriately cached in
the Structure, we should get it in the fast path without creating this object.
When converting primitives to objects, Structures used in these newly created objects
are known (Structure for StringObject etc.). So we can first query the cached string
before actually converting primitives to objects.
This patch improves wtb-lebab.js by roughly 2%.
before: lebab: 8.90 runs/s
after : lebab: 9.09 runs/s
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::fixupObjectToString):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileObjectToString):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileObjectToString):
* runtime/Intrinsic.cpp:
(JSC::intrinsicName):
* runtime/Intrinsic.h:
* runtime/ObjectPrototype.cpp:
(JSC::ObjectPrototype::finishCreation):
(JSC::objectProtoFuncToString):
* runtime/ObjectPrototype.h:
* runtime/ObjectPrototypeInlines.h: Added.
(JSC::structureForPrimitiveValue):
(JSC::objectToString):
* runtime/StructureRareData.h:
2019-01-03 Michael Saboff <msaboff@apple.com>
DFG IntegerRangeOptimization phase exceeding loop limit shouldn't ASSERT
https://bugs.webkit.org/show_bug.cgi?id=193094
Reviewed by Saam Barati.
Removed this debug only ASSERT as one can construct test cases that will exceed the giveUpThreshold
amount. This can be done with a large switch statement with at least one const or variable case
clause. Such code bytecompiles to compare / jtrue sequences. Increasing the giveUpThreshold count
doesn't help with the eventual code generated as B3 has optimizations to coalesce compare / branch
code sequences even when we don't run the IntegerRangeOptimization phase.
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
2019-01-02 Devin Rousso <webkit@devinrousso.com>
Web Inspector: Implement `queryObjects` Command Line API
https://bugs.webkit.org/show_bug.cgi?id=176766
<rdar://problem/34890689>
Reviewed by Joseph Pecoraro.
Introduces a new Command Line function called `queryObjects` that will return an array of
object that have the given constructor/prototype argument in their prototype chain.
- `queryObjects(Promise)` will return an array of all Promises.
- `queryObjects(Foo)` will return all objects created with the constructor `Foo`.
Currently, an error is thrown if the first argument is one of the following:
- Object
- Object.prototype
- Function
- Function.prototype
- Array
- Array.prototype
- Map
- Map.prototype
- Set
- Set.prototype
- Proxy
The reason for this is that we don't want to expose any internal/builtin objects, as some of
them are highly sensitive and undefined behaviour can occur if they are modified.
* inspector/JSInjectedScriptHost.h:
* inspector/JSInjectedScriptHost.cpp:
(Inspector::checkForbiddenPrototype): Added.
(Inspector::JSInjectedScriptHost::queryObjects): Added.
Does a GC and then iterates over all live JSCell in the heap to find these objects.
* inspector/JSInjectedScriptHostPrototype.cpp:
(Inspector::JSInjectedScriptHostPrototype::finishCreation):
(Inspector::jsInjectedScriptHostPrototypeFunctionQueryObjects): Added.
* inspector/InjectedScriptSource.js:
(queryObjects): Added.
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::promisePrototype): Added.
2018-12-31 Keith Miller <keith_miller@apple.com>
SourceProviders should use an actual URL instead of a string
https://bugs.webkit.org/show_bug.cgi?id=192734
Reviewed by Yusuke Suzuki.
This will be useful for the Module loader API in the future where
by default it will use the relative path from the referring module
to resolve dependencies.
I didn't change the JSC shell's urls to be absolute paths as it
caused problems with the stack traces in our Chakra tests. Since
the absolute paths included system directories the diff would
appear incorrect.
See: https://bugs.webkit.org/show_bug.cgi?id=193077
* API/JSBase.cpp:
(JSEvaluateScript):
(JSCheckScriptSyntax):
* API/JSScriptRef.cpp:
(OpaqueJSScript::create):
(OpaqueJSScript::OpaqueJSScript):
* API/glib/JSCContext.cpp:
(jsc_context_check_syntax):
* jsc.cpp:
(jscSource):
(GlobalObject::moduleLoaderFetch):
(functionCheckModuleSyntax):
(runWithOptions):
* parser/SourceCode.h:
(JSC::makeSource):
* parser/SourceProvider.cpp:
(JSC::SourceProvider::SourceProvider):
* parser/SourceProvider.h:
(JSC::SourceProvider::url const):
(JSC::StringSourceProvider::create):
(JSC::StringSourceProvider::StringSourceProvider):
(JSC::WebAssemblySourceProvider::create):
(JSC::WebAssemblySourceProvider::WebAssemblySourceProvider):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* tools/CodeProfile.h:
(JSC::CodeProfile::CodeProfile):
* tools/FunctionOverrides.cpp:
(JSC::initializeOverrideInfo):
2019-01-01 Jeff Miller <jeffm@apple.com>
Update user-visible copyright strings to include 2019
https://bugs.webkit.org/show_bug.cgi?id=192811
Reviewed by Mark Lam.
* Info.plist:
2018-12-30 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Identifier validity should be based on ID_Start / ID_Continue properties
https://bugs.webkit.org/show_bug.cgi?id=193050
Reviewed by Yusuke Suzuki.
From https://tc39.github.io/ecma262/#sec-names-and-keywords:
UnicodeIDStart::
any Unicode code point with the Unicode property "ID_Start"
UnicodeIDContinue::
any Unicode code point with the Unicode property "ID_Continue"
* parser/Lexer.cpp:
(JSC::Lexer<T>::Lexer):
(JSC::isNonLatin1IdentStart):
(JSC::isNonLatin1IdentPart):
(JSC::isIdentPart):
(JSC::Lexer<T>::lex):
Ensure identifier start / part is based on ID_Start / ID_Continue.
(Implies a special case for U+00B7, which is Latin-1 but Other_ID_Continue.)
2018-12-28 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Remove one indirection in JSObject::toStringName
https://bugs.webkit.org/show_bug.cgi?id=193037
Reviewed by Keith Miller.
We should not have additional one-level indirection in JSObject::toStringName.
JSObject::toStringName is dispatched through methodTable. Even after that, we
need to call JSObject::className function through methodTable again. But className
function is rarely defined. So instead of introducing this indirection here,
classes having className functions should have toStringName function too. This can
remove one-level indirection in toStringName in major cases.
* API/JSCallbackObject.h:
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::toStringName):
* debugger/DebuggerScope.cpp:
(JSC::DebuggerScope::toStringName):
* debugger/DebuggerScope.h:
* runtime/JSObject.cpp:
(JSC::JSObject::toStringName):
2018-12-27 Alex Christensen <achristensen@webkit.org>
Resurrect Mac CMake build
https://bugs.webkit.org/show_bug.cgi?id=192658
Reviewed by Yusuke Suzuki.
* PlatformMac.cmake:
2018-12-25 Fujii Hironori <Hironori.Fujii@sony.com>
[JSC][Win][Clang] warning: implicit conversion from 'size_t' (aka 'unsigned long long') to 'int32_t' (aka 'int') changes value from 18446744073709551552 to -64 [-Wconstant-conversion]
https://bugs.webkit.org/show_bug.cgi?id=193035
Reviewed by Yusuke Suzuki.
Clang-cl reports a compilation warning for implicit conversion
from -64 size_t to int. Replaced '-maxFrameExtentForSlowPathCall'
with '-static_cast<int32_t>(maxFrameExtentForSlowPathCall)'.
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
* jit/JIT.cpp:
(JSC::JIT::compileWithoutLinking):
* jit/ThunkGenerators.cpp:
(JSC::slowPathFor):
2018-12-13 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[BigInt] Support BigInt in JSON.stringify
https://bugs.webkit.org/show_bug.cgi?id=192624
Reviewed by Saam Barati.
This patch adds BigInt support to JSON.stringify, specified in [1].
[1]: https://tc39.github.io/proposal-bigint/#sec-serializejsonproperty
* runtime/JSONObject.cpp:
(JSC::unwrapBoxedPrimitive):
(JSC::Stringifier::toJSON):
(JSC::Stringifier::toJSONImpl):
(JSC::Stringifier::appendStringifiedValue):
2018-12-21 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Use appendUnbarriered for cached own keys
https://bugs.webkit.org/show_bug.cgi?id=192981
Reviewed by Saam Barati.
m_cachedOwnKeys would be changed to sentinel after checking `thisObject->m_cachedOwnKeys.unvalidatedGet() != cachedOwnKeysSentinel()`
and before executing `visitor.append(thisObject->m_cachedOwnKeys)`. We never do this now, but might in the future.
To make the code safe, we should use appendUnbarriered to mark non sentinel cell.
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::visitChildren):
2018-12-20 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Use Ref<> as much as possible
https://bugs.webkit.org/show_bug.cgi?id=192808
Reviewed by Alex Christensen.
* API/JSTypedArray.cpp:
(JSObjectMakeTypedArrayWithBytesNoCopy):
* API/JSWeakObjectMapRefPrivate.cpp:
* bytecompiler/StaticPropertyAnalyzer.h:
(JSC::StaticPropertyAnalyzer::newObject):
* dfg/DFGDesiredWatchpoints.cpp:
(JSC::DFG::ArrayBufferViewWatchpointAdaptor::add):
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::sweeper):
* heap/Heap.h:
* heap/IsoCellSet.cpp:
(JSC::IsoCellSet::parallelNotEmptyMarkedBlockSource):
* heap/IsoCellSet.h:
* heap/IsoCellSetInlines.h:
(JSC::IsoCellSet::forEachMarkedCellInParallel):
* heap/Subspace.cpp:
(JSC::Subspace::parallelDirectorySource):
(JSC::Subspace::parallelNotEmptyMarkedBlockSource):
* heap/Subspace.h:
* heap/SubspaceInlines.h:
(JSC::Subspace::forEachMarkedCellInParallel):
* jsc.cpp:
(functionDollarAgentReceiveBroadcast):
* runtime/ArrayBuffer.cpp:
(JSC::ArrayBuffer::slice const):
(JSC::ArrayBuffer::sliceImpl const):
* runtime/ArrayBuffer.h:
* runtime/ArrayBufferNeuteringWatchpoint.cpp:
(JSC::ArrayBufferNeuteringWatchpoint::ArrayBufferNeuteringWatchpoint):
(JSC::ArrayBufferNeuteringWatchpoint::fireAll):
* runtime/ArrayBufferNeuteringWatchpoint.h:
* runtime/JSArrayBufferPrototype.cpp:
(JSC::arrayBufferProtoFuncSlice):
2018-12-21 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Crashes seen under Inspector::ScriptCallFrame::~ScriptCallFrame
https://bugs.webkit.org/show_bug.cgi?id=180373
<rdar://problem/33894170>
Rubber-stamped by Devin Rousso.
* inspector/AsyncStackTrace.cpp:
(Inspector::AsyncStackTrace::truncate):
The `lastUnlockedAncestor->remove()` may release the only reference to it's
parent which we intend to use later but don't hold a RefPtr to. Keep the
parent alive explicitly by protecting it.
2018-12-20 Chris Dumez <cdumez@apple.com>
Use Optional::hasValue() instead of Optional::has_value()
https://bugs.webkit.org/show_bug.cgi?id=192948
Reviewed by Tim Horton.
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
(CppBackendDispatcherImplementationGenerator._generate_async_dispatcher_class_for_domain):
(CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
2018-12-20 Keith Miller <keith_miller@apple.com>
Add support for globalThis
https://bugs.webkit.org/show_bug.cgi?id=165171
Reviewed by Mark Lam.
This patch adds support for the globalThis property on the global
object. The globalThis property spec is in stage three and is
quite simple. For reference: http://tc39.github.io/proposal-global/
* runtime/JSGlobalObject.cpp:
2018-12-20 Chris Dumez <cdumez@apple.com>
Use Optional::valueOr() instead of Optional::value_or()
https://bugs.webkit.org/show_bug.cgi?id=192933
Reviewed by Geoffrey Garen.
* inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
(Inspector::RemoteConnectionToTarget::setup):
* inspector/remote/glib/RemoteConnectionToTargetGlib.cpp:
(Inspector::RemoteConnectionToTarget::setup):
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::SourceCodeKey):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
2018-12-20 Joseph Pecoraro <pecoraro@apple.com>
ITMLKit Inspector: Elements tab does not show DOM Tree
https://bugs.webkit.org/show_bug.cgi?id=192910
<rdar://problem/46680585>
Reviewed by Brian Burg.
* inspector/agents/InspectorAgent.h:
* inspector/agents/InspectorAgent.cpp:
(Inspector::InspectorAgent::enable):
(Inspector::InspectorAgent::activateExtraDomain):
(Inspector::InspectorAgent::activateExtraDomains):
Send extra domains immediately instead of waiting until
the Inspector domain is enabled. This will ensure the frontend
hears about extra augmented domains before augmenting agents
get a chance to send any messages.
2018-12-20 Mark Lam <mark.lam@apple.com>
Fix a typo in slow_path_construct_arityCheck and operationConstructArityCheck.
https://bugs.webkit.org/show_bug.cgi?id=192939
<rdar://problem/46869516>
Reviewed by Keith Miller.
* jit/JITOperations.cpp:
* runtime/CommonSlowPaths.cpp:
2018-12-20 Caio Lima <ticaiolima@gmail.com>
[BigInt] We should enable CSE into arithmetic operations that speculate BigIntUse
https://bugs.webkit.org/show_bug.cgi?id=192723
Reviewed by Yusuke Suzuki.
This patch is adjusting clobberize rules into ValueOp nodes to enable
more optimizations when we speculate BigIntUse. In such case, DFG now
is able to apply CSE, LICM and commutativity on nodes like
ValueAdd(BigInt, BigInt), ValueSub(BigInt, BigInt), etc.
Here are the numbers we can observe with some microbenchmarks:
baseline changes
big-int-cse 108.2733+-0.8445 ^ 80.9897+-4.9781 ^ definitely 1.3369x faster
big-int-licm 75.6641+-0.3477 ^ 57.8144+-1.6043 ^ definitely 1.3087x faster
big-int-global-cse 145.3557+-1.0552 ^ 86.5866+-0.3025 ^ definitely 1.6787x faster
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
2018-12-19 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r239377.
https://bugs.webkit.org/show_bug.cgi?id=192921
broke 32-bit JSC tests (Requested by keith_miller on #webkit).
Reverted changeset:
"[BigInt] We should enable CSE into arithmetic operations that
speculate BigIntUse"
https://bugs.webkit.org/show_bug.cgi?id=192723
https://trac.webkit.org/changeset/239377
2018-12-19 Chris Dumez <cdumez@apple.com>
wtf/Optional.h: move-constructor and move-assignment operator should disengage the value being moved from
https://bugs.webkit.org/show_bug.cgi?id=192728
<rdar://problem/46746779>
Reviewed by Geoff Garen.
* API/*:
* Scripts/*:
* assembler/*:
* b3/*:
* bytecode/*:
* bytecompiler/*:
* debugger/*:
* dfg/*:
* ftl/*:
* heap/*:
* inspector/*:
* jit/*:
* llint/*:
* parser/*:
* runtime/*:
* tools/*:
* wasm/*:
* yarr/*:
2018-12-18 Simon Fraser <simon.fraser@apple.com>
Web Inspector: Timelines: correctly label Intersection Observer callbacks
https://bugs.webkit.org/show_bug.cgi?id=192669
<rdar://problem/46702490>
Reviewed by Joseph Pecoraro.
Add InspectorInstrumentation::willFireObserverCallback() and use it to wrap calls
to Intersection Observer, Performance Observer and Mutation Observer callbacks so
that they get correctly labeled in the Inspector timeline.
* inspector/protocol/Timeline.json:
2018-12-18 Mark Lam <mark.lam@apple.com>
JSPropertyNameEnumerator should cache the iterated object's structure only after getting its property names.
https://bugs.webkit.org/show_bug.cgi?id=192464
<rdar://problem/46519455>
Reviewed by Saam Barati.
This is because the process of getting its property names may cause some lazy
properties to be reified, and the structure will change. This is needed in order
for get_direct_pname to work correctly.
* runtime/JSPropertyNameEnumerator.h:
(JSC::propertyNameEnumerator):
2018-12-19 Caio Lima <ticaiolima@gmail.com>
[BigInt] We should enable CSE into arithmetic operations that speculate BigIntUse
https://bugs.webkit.org/show_bug.cgi?id=192723
Reviewed by Saam Barati.
This patch is adjusting clobberize rules into ValueOp nodes to enable
more optimizations when we speculate BigIntUse. In such case, DFG now
is able to apply CSE, LICM and commutativity on nodes like
ValueAdd(BigInt, BigInt), ValueSub(BigInt, BigInt), etc.
Here are the numbers we can observe with some microbenchmarks:
baseline changes
big-int-cse 108.2733+-0.8445 ^ 80.9897+-4.9781 ^ definitely 1.3369x faster
big-int-licm 75.6641+-0.3477 ^ 57.8144+-1.6043 ^ definitely 1.3087x faster
big-int-global-cse 145.3557+-1.0552 ^ 86.5866+-0.3025 ^ definitely 1.6787x faster
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
2018-12-19 Tadeu Zagallo <tzagallo@apple.com>
String overflow in JSC::createError results in ASSERT in WTF::makeString
https://bugs.webkit.org/show_bug.cgi?id=192833
<rdar://problem/45706868>
Reviewed by Mark Lam.
JSC::createError was calling WTF::makeString which would result in an
assertion failure when the string was too big. Change it to call
WTF::tryMakeString instead and return an OutOfMemory error if we fail
to create the error string.
* runtime/ExceptionHelpers.cpp:
(JSC::createError):
2018-12-18 Ross Kirsling <ross.kirsling@sony.com>
Error message for `-x ** y` contains a typo.
https://bugs.webkit.org/show_bug.cgi?id=192832
Reviewed by Saam Barati.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseBinaryExpression):
Make corrections to error message: "amiguous" -> "ambiguous", "parenthesis" -> "parentheses"
2018-12-18 Saam Barati <sbarati@apple.com>
Update ARM64EHash
https://bugs.webkit.org/show_bug.cgi?id=192823
<rdar://problem/45468257>
Reviewed by Mark Lam.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::ARM64Assembler):
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::AbstractMacroAssembler):
* assembler/AssemblerBuffer.h:
(JSC::ARM64EHash::update):
(JSC::ARM64EHash::finalHash const):
(JSC::AssemblerBuffer::AssemblerBuffer):
(JSC::AssemblerBuffer::putIntegralUnchecked):
(JSC::ARM64EHash::ARM64EHash): Deleted.
(JSC::ARM64EHash::hash const): Deleted.
(JSC::ARM64EHash::randomSeed const): Deleted.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::copyCompactAndLinkCode):
2018-12-18 Mark Lam <mark.lam@apple.com>
JSON.stringify() should throw OOM on StringBuilder overflows.
https://bugs.webkit.org/show_bug.cgi?id=192822
<rdar://problem/46670577>
Reviewed by Saam Barati.
* runtime/JSONObject.cpp:
(JSC::Stringifier::stringify):
(JSC::Stringifier::appendStringifiedValue):
(JSC::Stringifier::Holder::appendNextProperty):
2018-12-18 Ross Kirsling <ross.kirsling@sony.com>
Redeclaration of var over let/const/class should be a syntax error.
https://bugs.webkit.org/show_bug.cgi?id=192298
Reviewed by Keith Miller.
From https://tc39.github.io/ecma262/#sec-block-static-semantics-early-errors:
It is a Syntax Error if any element of the LexicallyDeclaredNames of StatementList also occurs in the
VarDeclaredNames of StatementList.
Accordingly, this patch ensures that { let x; { var x; } } and { { var x; } let x; } are syntax errors.
For the "var after" scenario:
When checking for existing lexically-declared names, we can't simply check the current var scope;
we need to check *all* enclosing scopes up to (and including) the current var scope. In so doing,
we must also avoid violating the Annex B.3.5 condition that allows `try {} catch (e) { var e; }`.
For the "var before" scenario:
We ensure that lexical scopes always keep track of the vars being hoisted over them; this gives us
a simple way to check the current block's var-declared names prior to making a lexical declaration.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseTryStatement):
* parser/Parser.h:
(JSC::Scope::Scope):
(JSC::Scope::setIsSimpleCatchParameterScope): Added.
(JSC::Scope::isSimpleCatchParameterScope): Added.
(JSC::Scope::declareVariable):
(JSC::Scope::addVariableBeingHoisted): Added.
(JSC::Scope::declareLexicalVariable):
(JSC::Scope::hasDeclaredVariable):
(JSC::Scope::hasLexicallyDeclaredVariable): Added.
(JSC::Parser::declareHoistedVariable): Added.
(JSC::Parser::declareVariable):
2018-12-18 David Kilzer <ddkilzer@apple.com>
clang-tidy: Use const reference for MediaTime parameter to prevent object copy
<https://webkit.org/b/192814>
Reviewed by Mark Lam.
* runtime/JSCJSValue.h:
(JSC::jsNumber):
2018-12-18 Saam Barati <sbarati@apple.com>
Unreviewed. Appease a build error where we weren't using a variable defined in an "if"
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2018-12-17 Mark Lam <mark.lam@apple.com>
Array unshift/shift should not race against the AI in the compiler thread.
https://bugs.webkit.org/show_bug.cgi?id=192795
<rdar://problem/46724263>
Reviewed by Saam Barati.
The Array unshift and shift operations for ArrayStorage type arrays are protected
using the cellLock. The AbstractInterpreter's foldGetByValOnConstantProperty()
function does grab the cellLock before reading a value from the array's ArrayStorage,
but does not get the array butterfly under the protection of the cellLock.
This is insufficient and racy. For ArrayStorage type arrays, the fetching of the
butterfly also needs to be protected by the cellLock. The unshift / shift
operations can move values around in the butterfly. Hence, the fact that AI has
fetched a butterfly pointer (while ensuring no structure change) is insufficient
to guarantee that the values in the butterfly haven't shifted.
Having AI hold the cellLock the whole time (from before fetching the butterfly
till after reading the value from it) eliminates this race. Note: we only need
to do this for ArrayStorage type arrays.
Note also that though AI is holding the cellLock in this case, we still need to
ensure that the array structure hasn't changed around the fetching of the butterfly.
This is because operations other than unshift and shift are guarded by this
protocol, and not the cellLock.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* runtime/JSArray.cpp:
(JSC::JSArray::unshiftCountSlowCase):
2018-12-16 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Optimize Object.keys by caching own keys results in StructureRareData
https://bugs.webkit.org/show_bug.cgi?id=190047
Reviewed by Saam Barati.
Object.keys is one of the most frequently used function in web-tooling-benchmarks (WTB).
Object.keys is dominant in lebab of WTB, and frequently called in babel and others.
Since our Structure knows the shape of JSObject, we can cache the result of Object.keys
in Structure (StructureRareData) as we cache JSPropertyNameEnumerator in StructureRareData.
This patch caches the result of Object.keys in StructureRareData. The cached array is created
as JSImmutableButterfly. And Object.keys creates CoW from this data. Currently, the lifetime
strategy of this JSImmutableButterfly is the same to cached JSPropertyNameEnumerator. It is
referenced from Structure, and collected when Structure is collected.
This improves several benchmarks in SixSpeed.
baseline patched
object-assign.es5 350.1710+-3.6303 ^ 226.0368+-4.7558 ^ definitely 1.5492x faster
for-of-object.es6 269.1941+-3.3430 ^ 127.9317+-2.3875 ^ definitely 2.1042x faster
And it improves WTB lebab by 11.8%.
Before: lebab: 6.10 runs/s
After: lebab: 6.82 runs/s
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.cpp:
(JSC::DFG::Node::convertToNewArrayBuffer):
* dfg/DFGNode.h:
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileObjectKeys):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileObjectKeys):
* runtime/Butterfly.h:
(JSC::ContiguousData::Data::setStartingValue):
* runtime/Intrinsic.cpp:
(JSC::intrinsicName):
* runtime/Intrinsic.h:
* runtime/JSImmutableButterfly.h:
(JSC::JSImmutableButterfly::JSImmutableButterfly):
We set JSEmpty to the underlying butterfly storage if indexing type is Contiguous.
Otherwise, JSImmutableButterfly is half-baked one until all the storage is filled with some meaningful values, it leads to crash
if half-baked JSImmutableButterfly is exposed to GC.
* runtime/ObjectConstructor.cpp:
(JSC::ownPropertyKeys):
* runtime/Structure.cpp:
(JSC::Structure::canCachePropertyNameEnumerator const):
* runtime/Structure.h:
* runtime/StructureInlines.h:
(JSC::Structure::setCachedOwnKeys):
(JSC::Structure::cachedOwnKeys const):
(JSC::Structure::cachedOwnKeysIgnoringSentinel const):
(JSC::Structure::canCacheOwnKeys const):
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::visitChildren):
(JSC::StructureRareData::cachedPropertyNameEnumerator const): Deleted.
(JSC::StructureRareData::setCachedPropertyNameEnumerator): Deleted.
* runtime/StructureRareData.h:
* runtime/StructureRareDataInlines.h:
(JSC::StructureRareData::cachedPropertyNameEnumerator const):
(JSC::StructureRareData::setCachedPropertyNameEnumerator):
(JSC::StructureRareData::cachedOwnKeys const):
(JSC::StructureRareData::cachedOwnKeysIgnoringSentinel const):
(JSC::StructureRareData::cachedOwnKeysConcurrently const):
(JSC::StructureRareData::setCachedOwnKeys):
(JSC::StructureRareData::previousID const): Deleted.
* runtime/VM.cpp:
(JSC::VM::VM):
2018-12-17 Mark Lam <mark.lam@apple.com>
SamplingProfiler's isValidFramePointer() should reject address at stack origin.
https://bugs.webkit.org/show_bug.cgi?id=192779
<rdar://problem/46775869>
Reviewed by Saam Barati.
isValidFramePointer() was previously treating the address at StackBounds::origin()
as valid stack memory. This is not true. StackBounds::origin() is actually the
first address beyond valid stack memory. This is now fixed.
* runtime/SamplingProfiler.cpp:
(JSC::FrameWalker::isValidFramePointer):
2018-12-17 Mark Lam <mark.lam@apple.com>
Suppress ASAN on valid stack accesses in Probe-based OSRExit::executeOSRExit().
https://bugs.webkit.org/show_bug.cgi?id=192776
<rdar://problem/46772368>
Reviewed by Keith Miller.
1. Add some asanUnsafe methods to the Register class.
2. Update the probe-based OSRExit::executeOSRExit() to use these asanUnsafe methods.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::executeOSRExit):
* interpreter/Register.h:
(JSC::Register::asanUnsafeUnboxedInt32 const):
(JSC::Register::asanUnsafeUnboxedInt52 const):
(JSC::Register::asanUnsafeUnboxedStrictInt52 const):
(JSC::Register::asanUnsafeUnboxedDouble const):
(JSC::Register::asanUnsafeUnboxedCell const):
2018-12-17 Mark Lam <mark.lam@apple.com>
Fix stale assertion in attemptToForceStringArrayModeByToStringConversion().
https://bugs.webkit.org/show_bug.cgi?id=192770
<rdar://problem/46449037>
Reviewed by Keith Miller.
This assertion was added before Array::OriginalNonArray was introduced. It just
needs to be updated to allow for Array::OriginalNonArray.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::attemptToForceStringArrayModeByToStringConversion):
2018-12-17 Matt Lewis <jlewis3@apple.com>
Unreviewed, rolling out r239254.
This broke the Windows 10 Debug build
Reverted changeset:
"Replace many uses of String::format with more type-safe
alternatives"
https://bugs.webkit.org/show_bug.cgi?id=192742
https://trac.webkit.org/changeset/239254
2018-12-15 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Unreviewed, suppress warnings in Linux
* jsc.cpp:
(jscmain):
2018-12-15 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Null pointer dereference in JSC::WriteBarrierBase()
https://bugs.webkit.org/show_bug.cgi?id=191252
Reviewed by Keith Miller.
JSPromiseDeferred::create can return nullptr and an exception if stack overflow happens.
We would like to make it RELEASE_ASSERT since the current module mechanism is not immune
to stack overflow.
This patch renames JSPromiseDeferred::create to JSPromiseDeferred::tryCreate to tell that
it can return nullptr. And we insert error checks or assertions after this call.
* jsc.cpp:
(GlobalObject::moduleLoaderImportModule):
(GlobalObject::moduleLoaderFetch):
* runtime/Completion.cpp:
(JSC::rejectPromise):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncImportModule):
* runtime/JSInternalPromiseDeferred.cpp:
(JSC::JSInternalPromiseDeferred::tryCreate):
(JSC::JSInternalPromiseDeferred::create): Deleted.
* runtime/JSInternalPromiseDeferred.h:
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::importModule):
(JSC::JSModuleLoader::resolve):
(JSC::JSModuleLoader::fetch):
(JSC::moduleLoaderParseModule):
* runtime/JSPromise.h:
* runtime/JSPromiseDeferred.cpp:
(JSC::JSPromiseDeferred::tryCreate):
* runtime/JSPromiseDeferred.h:
* wasm/js/WebAssemblyPrototype.cpp:
(JSC::webAssemblyCompileFunc):
(JSC::webAssemblyInstantiateFunc):
(JSC::webAssemblyCompileStreamingInternal):
(JSC::webAssemblyInstantiateStreamingInternal):
2018-12-15 Darin Adler <darin@apple.com>
Use warning-ignoring macros more consistently and simply
https://bugs.webkit.org/show_bug.cgi?id=192743
Reviewed by Mark Lam.
* dfg/DFGSpeculativeJIT64.cpp: Use IGNORE_WARNINGS_BEGIN/END instead of
IGNORE_CLANG_WARNINGS_BEGIN/END. Other callsites are using the non-clang-specific
one for this warning, "implicit-fallthrough", and it seems there is no special
need to use the clang-specific one here.
* llint/LLIntData.cpp: Ditto, but here it's "missing-noreturn"."
* tools/CodeProfiling.cpp: Ditto.
2018-12-15 Darin Adler <darin@apple.com>
Replace many uses of String::format with more type-safe alternatives
https://bugs.webkit.org/show_bug.cgi?id=192742
Reviewed by Mark Lam.
* inspector/InjectedScriptBase.cpp:
(Inspector::InjectedScriptBase::makeCall): Use makeString.
(Inspector::InjectedScriptBase::makeAsyncCall): Ditto.
* inspector/InspectorBackendDispatcher.cpp:
(Inspector::BackendDispatcher::getPropertyValue): Ditto.
* inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::enable): Ditto.
* jsc.cpp:
(FunctionJSCStackFunctor::operator() const): Ditto.
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::initializeDateTimeFormat): Use string concatenation.
* runtime/IntlObject.cpp:
(JSC::canonicalizeLocaleList): Ditto.
2018-12-14 Darin Adler <darin@apple.com>
LiteralParser has a bunch of uses of String::format with untrusted data
https://bugs.webkit.org/show_bug.cgi?id=108883
rdar://problem/13666409
Reviewed by Mark Lam.
* runtime/LiteralParser.cpp:
(JSC::LiteralParser<CharType>::Lexer::lex): Use makeString instead of String::format.
(JSC::LiteralParser<CharType>::Lexer::lexStringSlow): Ditto.
(JSC::LiteralParser<CharType>::parse): Ditto.
* runtime/LiteralParser.h:
(JSC::LiteralParser::getErrorMessage): Use string concatenation instead of
String::format.
2018-12-14 Mark Lam <mark.lam@apple.com>
CallFrame::convertToStackOverflowFrame() needs to keep the top CodeBlock alive.
https://bugs.webkit.org/show_bug.cgi?id=192717
<rdar://problem/46660677>
Reviewed by Saam Barati.
When throwing a StackOverflowError, we convert the topCallFrame into a
StackOverflowFrame. Previously, we would nullify the codeBlock field in the frame
because a StackOverflowFrame is only a sentinel and doesn't really correspond to
any CodeBlocks. However, this is a problem because the topCallFrame may be the
only remaining place that references the CodeBlock that the stack overflow is
triggered in. The way we handle exceptions in JIT code is to return (from the
runtime operation function throwing the exception) to the JIT code to check for
the exception and if needed, do some clean up before jumping to the exception
handling thunk. As a result, we need to keep that JIT code alive, which means we
need to keep its CodeBlock alive. We only need to keep this CodeBlock alive until
we've unwound (in terms of exception handling) out of it.
We fix this issue by storing the CodeBlock to keep alive in the StackOverflowFrame
for the GC to scan while the frame is still on the stack.
We removed the call to convertToStackOverflowFrame() in
lookupExceptionHandlerFromCallerFrame() because it is redundant.
lookupExceptionHandlerFromCallerFrame() will only every be called after
a StackOverFlowError has been thrown. Hence, the top frame is already
guaranteed to be a StackOverflowFrame, and there should always be a
StackOverFlowError exception pending. We added assertions for these
instead.
* interpreter/CallFrame.cpp:
(JSC::CallFrame::convertToStackOverflowFrame):
* interpreter/CallFrame.h:
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::codeBlockFromCallFrameCallee):
(JSC::CommonSlowPaths::arityCheckFor):
* runtime/VM.h:
(JSC::VM::exceptionForInspection const):
2018-12-14 David Kilzer <ddkilzer@apple.com>
clang-tidy: Fix unnecessary copy of objects for operator==() methods
<https://webkit.org/b/192712>
<rdar://problem/46739332>
Reviewed by Andy Estes.
* b3/air/AirAllocateRegistersByGraphColoring.cpp:
(JSC::B3::Air::(anonymous namespace)::AbstractColoringAllocator::InterferenceEdge::operator==):
- Change argument from const to const reference to avoid a copy.
2018-12-14 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r239153, r239154, and r239155.
https://bugs.webkit.org/show_bug.cgi?id=192715
Caused flaky GC-related crashes seen with layout tests
(Requested by ryanhaddad on #webkit).
Reverted changesets:
"[JSC] Optimize Object.keys by caching own keys results in
StructureRareData"
https://bugs.webkit.org/show_bug.cgi?id=190047
https://trac.webkit.org/changeset/239153
"Unreviewed, build fix after r239153"
https://bugs.webkit.org/show_bug.cgi?id=190047
https://trac.webkit.org/changeset/239154
"Unreviewed, build fix after r239153, part 2"
https://bugs.webkit.org/show_bug.cgi?id=190047
https://trac.webkit.org/changeset/239155
2018-12-14 Keith Miller <keith_miller@apple.com>
Callers of JSString::getIndex should check for OOM exceptions
https://bugs.webkit.org/show_bug.cgi?id=192709
Reviewed by Mark Lam.
This patch also allows Strings to OOM when the StringObject wrapper
attempts to look up an own property on the string.
Remove isExtensibleImpl because it's only used in one place and call
isStructureExtensible instead.
* runtime/JSObject.cpp:
(JSC::JSObject::isExtensible):
* runtime/JSObject.h:
(JSC::JSObject::isExtensibleImpl): Deleted.
* runtime/JSString.h:
(JSC::JSString::getStringPropertySlot):
* runtime/StringObject.cpp:
(JSC::StringObject::defineOwnProperty):
2018-12-13 Fujii Hironori <Hironori.Fujii@sony.com>
[WinCairo][Clang] DLLLauncherMain.cpp: warning: unused function 'prependPath' and 'appleApplicationSupportDirectory'
https://bugs.webkit.org/show_bug.cgi?id=192688
Reviewed by Ross Kirsling.
These functions are used only in AppleWin port.
* shell/DLLLauncherMain.cpp:
(copyEnvironmentVariable): Moved.
(getStringValue): Enclosed with #if !defined(WIN_CAIRO).
(applePathFromRegistry): Ditto.
(appleApplicationSupportDirectory): Ditto.
(prependPath): Ditto.
2018-12-13 Dominik Infuehr <dinfuehr@igalia.com>
Improve GDB output for LLInt on Linux
https://bugs.webkit.org/show_bug.cgi?id=192660
Reviewed by Yusuke Suzuki.
Annotate assembly code generated for LLInt with the bytecode operation. When debugging
LLInt assembly code GDB is then able to show which bytecode instruction is implemented by
the current assembly code. This also works for linux-perf.
* llint/LowLevelInterpreter.cpp:
* offlineasm/arm.rb:
2018-12-13 Mark Lam <mark.lam@apple.com>
Add a missing exception check.
https://bugs.webkit.org/show_bug.cgi?id=192626
<rdar://problem/46662163>
Reviewed by Keith Miller.
* runtime/ScopedArguments.h:
2018-12-13 Saam Barati <sbarati@apple.com>
The JSC shell should listen for memory pressure events and respond to them
https://bugs.webkit.org/show_bug.cgi?id=192647
Reviewed by Keith Miller.
We want the JSC shell to behave more like the WebContent process when
it comes to running performance tests. One way to make the shell
more like this is to have it respond to memory pressure events in
a similar way as the WebContent process. This makes it easier to run
benchmarks like JetStream2 on the CLI on iOS.
* jsc.cpp:
(jscmain):
* runtime/VM.cpp:
(JSC::VM::drainMicrotasks):
* runtime/VM.h:
(JSC::VM::setOnEachMicrotaskTick):
2018-12-13 Mark Lam <mark.lam@apple.com>
Ensure that StructureFlags initialization always starts with Base::StructureFlags.
https://bugs.webkit.org/show_bug.cgi?id=192686
Reviewed by Keith Miller.
This is purely a refactoring effort to make the code consistently start all
StructureFlags initialization with Base::StructureFlags. Previously, sometimes
Base::StructureFlags is appended at the end, and sometimes, it is expressed using
the name of the superclass. This patch makes the code all consistent and easier
to do a quick eye scan audit on to verify that no StructureFlags are forgetting
to inherit Base::StructureFlags.
Also added a static_assert in JSCallbackObject.h and JSBoundFunction.h. Both of
these implement a customHasInstance() method, and rely on ImplementsHasInstance
being included in the StructureFlags, and conversely, ImplementsDefaultHasInstance
has to be excluded.
JSBoundFunction.h is the only case where a bit (ImplementsDefaultHasInstance)
needs to be masked out of the inherited Base::StructureFlags.
* API/JSCallbackObject.h:
* runtime/ArrayConstructor.h:
* runtime/ArrayIteratorPrototype.h:
* runtime/Exception.h:
* runtime/FunctionRareData.h:
* runtime/InferredType.h:
* runtime/InferredTypeTable.h:
* runtime/InferredValue.h:
* runtime/JSBoundFunction.h:
* runtime/MapPrototype.h:
* runtime/SetPrototype.h:
* runtime/StringPrototype.h:
* runtime/SymbolConstructor.h:
2018-12-13 Mark Lam <mark.lam@apple.com>
Add the JSC_traceBaselineJITExecution option for tracing baseline JIT execution.
https://bugs.webkit.org/show_bug.cgi?id=192684
Reviewed by Saam Barati.
This dataLogs the bytecode execution order of baseline JIT code when the
JSC_traceBaselineJITExecution option is true.
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* runtime/Options.h:
2018-12-13 David Kilzer <ddkilzer@apple.com>
clang-tidy: Fix unnecessary object copies in JavaScriptCore
<https://webkit.org/b/192680>
<rdar://problem/46708767>
Reviewed by Mark Lam.
* assembler/testmasm.cpp:
(JSC::invoke):
- Make MacroAssemblerCodeRef<JSEntryPtrTag> argument a const
reference.
* b3/testb3.cpp:
(JSC::B3::checkDisassembly):
- Make CString argument a const reference.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileStringEquality):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetByIdWithThis):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetByIdWithThis):
- Make JITCompiler::JumpList arguments a const reference.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::checkStructure):
- Make RegisteredStructureSet argument a const reference.
* jsc.cpp:
(GlobalObject::moduleLoaderImportModule): Make local auto
variables const references.
(Workers::report): Make String argument a const reference.
(addOption): Make Identifier argument a const reference.
(runJSC): Make CString loop variable a const reference.
2018-12-13 Devin Rousso <drousso@apple.com>
Web Inspector: remove DOM.BackendNodeId and associated commands/events
https://bugs.webkit.org/show_bug.cgi?id=192478
Reviewed by Matt Baker.
* inspector/protocol/DOM.json:
2018-12-13 Caio Lima <ticaiolima@gmail.com>
[BigInt] Add ValueDiv into DFG
https://bugs.webkit.org/show_bug.cgi?id=186178
Reviewed by Yusuke Suzuki.
This patch is introducing a new node type called ValueDiv. This node
is responsible to handle Untyped and Bigint specialization of division
operator, while the ArithDiv variant handles Number/Boolean cases.
BigInt specialization generates following speedup into simple
benchmark:
noSpec changes
big-int-simple-div 10.6013+-0.4682 ^ 8.4518+-0.0943 ^ definitely 1.2543x faster
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::makeDivSafe):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupArithDiv):
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::arithNodeFlags):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueDiv):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGValidate.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileValueDiv):
(JSC::FTL::DFG::LowerDFGToB3::compileArithDiv):
(JSC::FTL::DFG::LowerDFGToB3::compileArithBitNot):
2018-12-13 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Unreviewed, build fix after r239153, part 2
https://bugs.webkit.org/show_bug.cgi?id=190047
* runtime/StructureRareDataInlines.h:
(JSC::StructureRareData::cachedOwnKeys const):
2018-12-13 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Unreviewed, build fix after r239153
https://bugs.webkit.org/show_bug.cgi?id=190047
* runtime/StructureRareDataInlines.h:
(JSC::StructureRareData::cachedOwnKeys const):
2018-12-10 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Optimize Object.keys by caching own keys results in StructureRareData
https://bugs.webkit.org/show_bug.cgi?id=190047
Reviewed by Keith Miller.
Object.keys is one of the most frequently used function in web-tooling-benchmarks (WTB).
Object.keys is dominant in lebab of WTB, and frequently called in babel and others.
Since our Structure knows the shape of JSObject, we can cache the result of Object.keys
in Structure (StructureRareData) as we cache JSPropertyNameEnumerator in StructureRareData.
This patch caches the result of Object.keys in StructureRareData. The cached array is created
as JSImmutableButterfly. And Object.keys creates CoW from this data. Currently, the lifetime
strategy of this JSImmutableButterfly is the same to cached JSPropertyNameEnumerator. It is
referenced from Structure, and collected when Structure is collected.
This improves several benchmarks in SixSpeed.
baseline patched
object-assign.es5 350.1710+-3.6303 ^ 226.0368+-4.7558 ^ definitely 1.5492x faster
for-of-object.es6 269.1941+-3.3430 ^ 127.9317+-2.3875 ^ definitely 2.1042x faster
And it improves WTB lebab by 11.8%.
Before: lebab: 6.10 runs/s
After: lebab: 6.82 runs/s
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.cpp:
(JSC::DFG::Node::convertToNewArrayBuffer):
* dfg/DFGNode.h:
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileObjectKeys):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileObjectKeys):
* runtime/Intrinsic.cpp:
(JSC::intrinsicName):
* runtime/Intrinsic.h:
* runtime/JSImmutableButterfly.h:
(JSC::JSImmutableButterfly::createSentinel):
* runtime/ObjectConstructor.cpp:
(JSC::ownPropertyKeys):
* runtime/Structure.cpp:
(JSC::Structure::canCachePropertyNameEnumerator const):
* runtime/Structure.h:
* runtime/StructureInlines.h:
(JSC::Structure::setCachedOwnKeys):
(JSC::Structure::cachedOwnKeys const):
(JSC::Structure::canCacheOwnKeys const):
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::visitChildren):
(JSC::StructureRareData::cachedPropertyNameEnumerator const): Deleted.
(JSC::StructureRareData::setCachedPropertyNameEnumerator): Deleted.
* runtime/StructureRareData.h:
* runtime/StructureRareDataInlines.h:
(JSC::StructureRareData::cachedPropertyNameEnumerator const):
(JSC::StructureRareData::setCachedPropertyNameEnumerator):
(JSC::StructureRareData::cachedOwnKeys const):
(JSC::StructureRareData::cachedOwnKeysConcurrently const):
(JSC::StructureRareData::setCachedOwnKeys):
(JSC::StructureRareData::previousID const): Deleted.
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2018-12-12 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[DFG][FTL] Add NewSymbol
https://bugs.webkit.org/show_bug.cgi?id=192620
Reviewed by Saam Barati.
This patch introduces NewSymbol DFG node into DFG and FTL tiers. The main goal of this patch is not optimize
NewSymbol code faster. Rather than that, this patch intends to offer SpecSymbol type information into DFG's
data flow to optimize generated code in FTL backend.
We add NewSymbol DFG node, which may take an argument. If an argument is not given, NewSymbol is for `Symbol()`.
If an argument is given, ToString is emitted to this argument before passing it to NewSymbol. So NewSymbol node
itself does not perform any type checks. ToString performs effects, but NewSymbol doesn't have any side observable
effects. So we can decouple Symbol(description) call into NewSymbol(ToString(description)).
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGClobbersExitState.cpp:
(JSC::DFG::clobbersExitState):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGMayExit.cpp:
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewSymbol):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStoreBarrierInsertionPhase.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileNewSymbol):
2018-12-12 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[BigInt] Implement DFG/FTL typeof for BigInt
https://bugs.webkit.org/show_bug.cgi?id=192619
Reviewed by Keith Miller.
This patch implements typeof for BigInt in DFG and FTL. Our DFG and FTL tiers now correctly consider about BigInt
in the code generated for typeof.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::boolify): We add (SpecCell - SpecString) type filter for proven type since isString
check is already performed here.
(JSC::FTL::DFG::LowerDFGToB3::buildTypeOf): We use (SpecCell - SpecObject - SpecString) type filter for proven type
since String and Object are already checked here. If we know the proven type does not include Symbol type here, we
can omit the code for Symbol type.
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitTypeOf):
2018-12-11 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[BigInt] Simplify boolean context evaluation by leveraging JSString::offsetOfLength() == JSBigInt::offsetOfLength()
https://bugs.webkit.org/show_bug.cgi?id=192615
Reviewed by Saam Barati.
JSString and JSBigInt have similar concept in terms of the implementation.
Both are immutable, JSCells, and have length information. m_length is located
just after JSCell header part, we can ensure `JSString::offsetOfLength() == JSBigInt::offsetOfLength()`,
and it allows us to optimize the boolean context evaluation.
This patch leverages the above information to reduce the code size for the boolean context evaluation.
* ftl/FTLAbstractHeapRepository.cpp:
(JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::boolify):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitConvertValueToBoolean):
(JSC::AssemblyHelpers::branchIfValue):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::JSBigInt):
(JSC::JSBigInt::offsetOfLength): Deleted.
* runtime/JSBigInt.h:
2018-12-11 Justin Michaud <justin_michaud@apple.com>
Implement feature flag for CSS Typed OM
https://bugs.webkit.org/show_bug.cgi?id=192610
Reviewed by Ryosuke Niwa.
* Configurations/FeatureDefines.xcconfig:
2018-12-10 Don Olmstead <don.olmstead@sony.com>
Move ENABLE_RESOURCE_LOAD_STATISTICS to FeatureDefines.xcconfig
https://bugs.webkit.org/show_bug.cgi?id=192573
Reviewed by Simon Fraser.
* Configurations/FeatureDefines.xcconfig:
2018-12-10 Mark Lam <mark.lam@apple.com>
PropertyAttribute needs a CustomValue bit.
https://bugs.webkit.org/show_bug.cgi?id=191993
<rdar://problem/46264467>
Reviewed by Saam Barati.
This is because GetByIdStatus needs to distinguish CustomValue properties from
other types, and its only means of doing so is via the property's attributes.
Previously, there's nothing in the property's attributes that can indicate that
the property is a CustomValue.
We fix this by doing the following:
1. Added a PropertyAttribute::CustomValue bit.
2. Added a PropertyAttribute::CustomAccessorOrValue convenience bit mask that is
CustomAccessor | CustomValue.
3. Since CustomGetterSetter properties are only set via JSObject::putDirectCustomAccessor(),
we added a check in JSObject::putDirectCustomAccessor() to see if the attributes
bits include PropertyAttribute::CustomAccessor. If not, then the property
must be a CustomValue, and we'll add the PropertyAttribute::CustomValue bit
to the attributes bits.
This ensures that the property attributes is sufficient to tell us if the
property contains a CustomGetterSetter.
4. Updated all checks for PropertyAttribute::CustomAccessor to check for
PropertyAttribute::CustomAccessorOrValue instead if their intent is to check
for the presence of a CustomGetterSetter as opposed to checking specifically
for one that is used as a CustomAccessor.
This includes all the Structure transition code that needs to capture the
attributes change when a CustomValue has been added.
5. Filtered out the PropertyAttribute::CustomValue bit in PropertyDescriptor.
The fact that we're using a CustomGetterSetter as a CustomValue should remain
invisible to the descriptor. This is because the descriptor should describe
a CustomValue no differently from a plain value.
6. Added some asserts to ensure that property attributes are as expected, and to
document some invariants.
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFromLLInt):
(JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::GetByIdStatus::computeFor):
* bytecode/InByIdStatus.cpp:
(JSC::InByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
* bytecode/PropertyCondition.cpp:
(JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFor):
* runtime/JSFunction.cpp:
(JSC::getCalculatedDisplayName):
* runtime/JSObject.cpp:
(JSC::JSObject::putDirectCustomAccessor):
(JSC::JSObject::putDirectNonIndexAccessor):
(JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):
* runtime/JSObject.h:
(JSC::JSObject::putDirectIndex):
(JSC::JSObject::fillCustomGetterPropertySlot):
(JSC::JSObject::putDirect):
* runtime/JSObjectInlines.h:
(JSC::JSObject::putDirectInternal):
* runtime/PropertyDescriptor.cpp:
(JSC::PropertyDescriptor::setDescriptor):
(JSC::PropertyDescriptor::setCustomDescriptor):
(JSC::PropertyDescriptor::setAccessorDescriptor):
* runtime/PropertySlot.h:
(JSC::PropertySlot::setCustomGetterSetter):
2018-12-10 Mark Lam <mark.lam@apple.com>
LinkBuffer::copyCompactAndLinkCode() needs to be aware of ENABLE(SEPARATED_WX_HEAP).
https://bugs.webkit.org/show_bug.cgi?id=192569
<rdar://problem/45615617>
Reviewed by Saam Barati.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::copyCompactAndLinkCode):
2018-12-10 Caio Lima <ticaiolima@gmail.com>
[BigInt] Add ValueMul into DFG
https://bugs.webkit.org/show_bug.cgi?id=186175
Reviewed by Yusuke Suzuki.
This patch is adding a new DFG node called ValueMul. This node is
responsible to handle multiplication operations that can result into
non-number values. We emit such node during DFGByteCodeParser when the
operands are not numbers. During FixupPhase, we change this
operation to ArithMul if we can speculate Number/Boolean operands.
The BigInt specialization shows a small progression:
noSpec changes
big-int-simple-mul 18.8090+-1.0435 ^ 17.4305+-0.2673 ^ definitely 1.0791x faster
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::makeSafe):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupMultiplication):
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::arithNodeFlags):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueMul):
(JSC::DFG::SpeculativeJIT::compileArithMul):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGValidate.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileValueMul):
(JSC::FTL::DFG::LowerDFGToB3::compileArithMul):
2018-12-08 Mark Lam <mark.lam@apple.com>
Reduce size of PropertySlot and PutPropertySlot.
https://bugs.webkit.org/show_bug.cgi?id=192526
Reviewed by Keith Miller.
With some minor adjustments, we can reduce the size of PropertySlot from 80 bytes
(19 padding bytes) to 64 bytes (3 padding bytes), and PutPropertySlot from 40
bytes (4 padding bytes) to 32 bytes (0 padding bytes but with 6 unused bits).
These measurements are for a 64-bit build.
* runtime/PropertySlot.h:
* runtime/PutPropertySlot.h:
(JSC::PutPropertySlot::PutPropertySlot):
2018-12-08 Dominik Infuehr <dinfuehr@igalia.com>
Record right offset with aligned wide instructions
https://bugs.webkit.org/show_bug.cgi?id=192006
Reviewed by Yusuke Suzuki.
Aligning bytecode instructions inserts nops into the instruction stream.
Emitting an instruction did not record the actual start of the instruction with
aligned instructions, but the nop just before the actual instruction. This was
problematic with the StaticPropertyAnalyzer that used the wrong instruction offset.
* bytecode/InstructionStream.h:
(JSC::InstructionStream::MutableRef::clone):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::alignWideOpcode):
(JSC::BytecodeGenerator::emitCreateThis):
(JSC::BytecodeGenerator::emitNewObject):
* generator/Opcode.rb:
2018-12-07 Tadeu Zagallo <tzagallo@apple.com>
Align the metadata table on all platforms
https://bugs.webkit.org/show_bug.cgi?id=192050
<rdar://problem/46312674>
Reviewed by Mark Lam.
Although certain platforms don't require the metadata to be aligned,
values were being concurrently read and written to ValueProfiles,
which caused crashes since these operations are not atomic on unaligned
addresses.
* bytecode/Opcode.cpp:
(JSC::metadataAlignment):
* bytecode/Opcode.h:
* bytecode/UnlinkedMetadataTableInlines.h:
(JSC::UnlinkedMetadataTable::finalize):
2018-12-05 Mark Lam <mark.lam@apple.com>
speculationFromCell() should speculate non-Identifier strings as SpecString instead of SpecStringVar.
https://bugs.webkit.org/show_bug.cgi?id=192441
<rdar://problem/46480355>
Reviewed by Saam Barati.
This is because a regular String (non-Identifier) can be converted into an
Identifier. During DFG/FTL compilation, AbstractValue::checkConsistency() may
expect a value to be of type SpecStringVar, but the mutator thread may have
converted the string into an Identifier. This creates a race where
AbstractValue::checkConsistency() may fail because it sees a SpecStringIdent when
it expects the a SpecStringVar.
The fix is to speculate non-Identifier strings as type SpecString which allows it
to be SpecStringVar or SpecStringIndent.
* bytecode/SpeculatedType.cpp:
(JSC::speculationFromCell):
2018-12-04 Mark Lam <mark.lam@apple.com>
DFG's StrengthReduction phase should not reduce Construct into DirectContruct when the executable does not have constructAbility.
https://bugs.webkit.org/show_bug.cgi?id=192386
<rdar://problem/46445516>
Reviewed by Saam Barati.
This violates an invariant documented by a RELEASE_ASSERT in operationLinkDirectCall().
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
2018-12-04 Caio Lima <ticaiolima@gmail.com>
[ESNext][BigInt] Support logic operations
https://bugs.webkit.org/show_bug.cgi?id=179903
Reviewed by Yusuke Suzuki.
We are introducing in this patch the ToBoolean support for JSBigInt.
With this change, we can implement the correct behavior of BigInt as
operand of logical opertions. During JIT genertion into DFG and FTL,
we are using JSBigInt::m_length to verify if the number is 0n or not,
following the same approach used by JSString. This is also safe in the case
of BigInt, because only 0n has m_length == 0.
We are not including BigInt speculation into Branch nodes in this
patch, but the plan is to implement it in further patches.
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::boolify):
(JSC::FTL::DFG::LowerDFGToB3::isBigInt):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitConvertValueToBoolean):
(JSC::AssemblyHelpers::branchIfValue):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::isZero const):
(JSC::JSBigInt::offsetOfLength):
(JSC::JSBigInt::toBoolean const):
(JSC::JSBigInt::isZero): Deleted.
* runtime/JSBigInt.h:
* runtime/JSCellInlines.h:
(JSC::JSCell::toBoolean const):
(JSC::JSCell::pureToBoolean const):
2018-12-04 Devin Rousso <drousso@apple.com>
Web Inspector: Audit: tests should support async operations
https://bugs.webkit.org/show_bug.cgi?id=192171
<rdar://problem/46423562>
Reviewed by Joseph Pecoraro.
Add `awaitPromise` command for executing a callback when a Promise gets settled.
Drive-by: allow `wasThrown` to be optional, instead of expecting it to always have a value.
* inspector/protocol/Runtime.json:
* inspector/InjectedScriptSource.js:
(InjectedScript.prototype.awaitPromise): Added.
* inspector/InjectedScript.h:
* inspector/InjectedScript.cpp:
(Inspector::InjectedScript::evaluate):
(Inspector::InjectedScript::awaitPromise): Added.
(Inspector::InjectedScript::callFunctionOn):
(Inspector::InjectedScript::evaluateOnCallFrame):
* inspector/InjectedScriptBase.h:
* inspector/InjectedScriptBase.cpp:
(Inspector::InjectedScriptBase::makeEvalCall):
(Inspector::InjectedScriptBase::makeAsyncCall): Added.
(Inspector::InjcetedScriptBase::checkCallResult): Added.
(Inspector::InjcetedScriptBase::checkAsyncCallResult): Added.
* inspector/agents/InspectorRuntimeAgent.h:
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::evaluate):
(Inspector::InspectorRuntimeAgent::awaitPromise):
(Inspector::InspectorRuntimeAgent::callFunctionOn):
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::evaluateOnCallFrame):
2018-12-03 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r238833.
Breaks macOS and iOS debug builds.
Reverted changeset:
"[ESNext][BigInt] Support logic operations"
https://bugs.webkit.org/show_bug.cgi?id=179903
https://trac.webkit.org/changeset/238833
2018-12-03 Caio Lima <ticaiolima@gmail.com>
[ESNext][BigInt] Support logic operations
https://bugs.webkit.org/show_bug.cgi?id=179903
Reviewed by Yusuke Suzuki.
We are introducing in this patch the ToBoolean support for JSBigInt.
With this change, we can implement the correct behavior of BigInt as
operand of logical opertions. During JIT genertion into DFG and FTL,
we are using JSBigInt::m_length to verify if the number is 0n or not,
following the same approach used by JSString. This is also safe in the case
of BigInt, because only 0n has m_length == 0.
We are not including BigInt speculation into Branch nodes in this
patch, but the plan is to implement it in further patches.
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::boolify):
(JSC::FTL::DFG::LowerDFGToB3::isBigInt):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitConvertValueToBoolean):
(JSC::AssemblyHelpers::branchIfValue):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::isZero const):
(JSC::JSBigInt::offsetOfLength):
(JSC::JSBigInt::toBoolean const):
(JSC::JSBigInt::isZero): Deleted.
* runtime/JSBigInt.h:
* runtime/JSCellInlines.h:
(JSC::JSCell::toBoolean const):
(JSC::JSCell::pureToBoolean const):
2018-12-03 Keith Rollin <krollin@apple.com>
Add .xcfilelist files
https://bugs.webkit.org/show_bug.cgi?id=192082
<rdar://problem/46312533>
Reviewed by Brent Fulgham.
Add .xcfilelist files for Generate Derived Sources and Generate
Unified Sources build phases in Xcode. These are just being staged for
now; they'll be added to the Xcode projects later.
* DerivedSources-input.xcfilelist: Added.
* DerivedSources-output.xcfilelist: Added.
* UnifiedSources-input.xcfilelist: Added.
* UnifiedSources-output.xcfilelist: Added.
2018-12-03 Mark Lam <mark.lam@apple.com>
Fix the bytecode code generator scripts to pretty print BytecodeStructs.h and BytecodeIndices.h.
https://bugs.webkit.org/show_bug.cgi?id=192271
Reviewed by Keith Miller.
This makes the generated code style compliant and human readable.
* generator/Argument.rb:
* generator/DSL.rb:
* generator/Fits.rb:
* generator/Metadata.rb:
* generator/Opcode.rb:
2018-12-02 Zalan Bujtas <zalan@apple.com>
Add a runtime feature flag for LayoutFormattingContext.
https://bugs.webkit.org/show_bug.cgi?id=192280
Reviewed by Simon Fraser.
* Configurations/FeatureDefines.xcconfig:
2018-12-02 Caio Lima <ticaiolima@gmail.com>
[ESNext][BigInt] Implement support for "<<" and ">>"
https://bugs.webkit.org/show_bug.cgi?id=186233
Reviewed by Yusuke Suzuki.
This patch is introducing the support for BigInt into lshift and
rshift into LLint and Baseline layers.
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::createWithLength):
(JSC::JSBigInt::leftShift):
(JSC::JSBigInt::signedRightShift):
(JSC::JSBigInt::leftShiftByAbsolute):
(JSC::JSBigInt::rightShiftByAbsolute):
(JSC::JSBigInt::rightShiftByMaximum):
(JSC::JSBigInt::toShiftAmount):
* runtime/JSBigInt.h:
2018-12-01 Simon Fraser <simon.fraser@apple.com>
Heap.h refers to the non-existent HeapStatistics
https://bugs.webkit.org/show_bug.cgi?id=187882
Reviewed by Keith Miller.
Just remove the "friend class HeapStatistics".
* heap/Heap.h:
2018-11-29 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Keep TypeMaybeBigInt small
https://bugs.webkit.org/show_bug.cgi?id=192203
Reviewed by Saam Barati.
As BigInt is being implemented, more and more bytecodes start returning BigInt.
It means that ResultType of these bytecodes include TypeMaybeBigInt. However,
TypeMaybeBigInt was large number 0x20, leading to wide instruction since ResultType
easily becomes larger than 32 (e.g. TypeInt32 | TypeMaybeBigInt == 33).
This patch sorts the numbers of TypeMaybeXXX based on the frequency of appearance in
the code.
* parser/ResultType.h:
2018-11-30 Dean Jackson <dino@apple.com>
Try to fix Windows build by using strcmp instead of strcasecmp.
* jsc.cpp:
(isMJSFile):
2018-11-30 Mark Lam <mark.lam@apple.com>
Fix the bytecode code generator scripts to pretty print Bytecodes.h.
https://bugs.webkit.org/show_bug.cgi?id=192258
Reviewed by Keith Miller.
This makes Bytecodes.h more human readable.
* generator/DSL.rb:
* generator/Section.rb:
2018-11-30 Mark Lam <mark.lam@apple.com>
Add the generator directory to the Xcode project.
https://bugs.webkit.org/show_bug.cgi?id=192252
Reviewed by Michael Saboff.
This is so that we can work with these bytecode class generator files easily in Xcode.
* JavaScriptCore.xcodeproj/project.pbxproj:
2018-11-30 Don Olmstead <don.olmstead@sony.com>
Rename ENABLE_SUBTLE_CRYPTO to ENABLE_WEB_CRYPTO
https://bugs.webkit.org/show_bug.cgi?id=192197
Reviewed by Jiewen Tan.
* Configurations/FeatureDefines.xcconfig:
2018-11-30 Dean Jackson <dino@apple.com>
Add first-class support for .mjs files in jsc binary
https://bugs.webkit.org/show_bug.cgi?id=192190
<rdar://problem/46375715>
Reviewed by Keith Miller.
Treat files with a .mjs extension as a module, regardless
of whether or not the --module-file argument was given.
* jsc.cpp:
(printUsageStatement): Update usage.
(isMJSFile): Helper to look for .mjs extensions.
(CommandLine::parseArguments): Pick the appropriate script type.
2018-11-30 Caio Lima <ticaiolima@gmail.com>
[BigInt] Implement ValueBitXor into DFG
https://bugs.webkit.org/show_bug.cgi?id=190264
Reviewed by Yusuke Suzuki.
This patch is splitting the BitXor node into ArithBitXor and
ValueBitXor. This is necessary due the introduction of
BigInt, since BitXor operations now can result into Int32 or BigInt.
In such case, we use ArithBitXor when operands are Int and fallback to
ValueBitXor when operands are anything else. In the case of
ValueBitXor, we speculate BigInt when op1 and op2 are predicted as
BigInt as well. BigInt specialization consist into call
`operationBigIntBitXor` function, that calls JSBigInt::bitXor.
* bytecode/BytecodeList.rb:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::arithProfileForPC):
* bytecode/Opcode.h:
(JSC::padOpcodeName):
* bytecompiler/BytecodeGenerator.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo):
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueBitwiseOp):
(JSC::DFG::SpeculativeJIT::compileBitwiseOp):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::bitOp):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileValueBitXor):
(JSC::FTL::DFG::LowerDFGToB3::compileArithBitXor):
(JSC::FTL::DFG::LowerDFGToB3::compileBitXor): Deleted.
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_bitxor):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
2018-11-29 Justin Michaud <justin_michaud@apple.com>
CSS Painting API should pass 'this' correctly to paint callback, and repaint when properties change.
https://bugs.webkit.org/show_bug.cgi?id=191443
Reviewed by Dean Jackson.
Export the simpler construct() method for use in WebCore.
* runtime/ConstructData.h:
2018-11-28 Mark Lam <mark.lam@apple.com>
ENABLE_SEPARATED_WX_HEAP needs to be defined in Platform.h.
https://bugs.webkit.org/show_bug.cgi?id=192110
<rdar://problem/46317746>
Reviewed by Saam Barati.
* config.h:
2018-11-28 Keith Rollin <krollin@apple.com>
Update generate-{derived,unified}-sources scripts to support generating .xcfilelist files
https://bugs.webkit.org/show_bug.cgi?id=192031
<rdar://problem/46286816>
Reviewed by Alex Christensen.
The Generate Derived Sources and Generate Unified Sources build phases
in Xcode need to have their inputs and outputs specified. This
specification will come in the form of .xcfilelist files that will be
attached to these build phases. There is one .xcfilelist file that
lists the input file and one that lists the output files. As part of
this work, the various generate-{derived,unified}-sources scripts that
are executed in these Generate build phases are modified to help in
the creation of these .xcfilelist files. In particular, they can now
be invoked with command-line parameters. These parameters are then
used to alter the normal execution of these scripts, causing them to
produce the .xcfilelist files as opposed to actually generating the
files that are listed in those files.
* Scripts/generate-derived-sources.sh:
* Scripts/generate-unified-sources.sh:
2018-11-28 Keith Rollin <krollin@apple.com>
Revert print_all_generated_files work in r238008; tighten up target specifications
https://bugs.webkit.org/show_bug.cgi?id=192025
<rdar://problem/46284301>
Reviewed by Alex Christensen.
In r238008, I added a facility for DerivedSources.make makefiles to
print out the list of files that they generate. This output was used
in the generation of .xcfilelist files used to specify the output of
the associated Generate Derived Sources build phases in Xcode. This
approach worked, but it meant that people would need to follow a
specific convention to keep this mechanism working.
Instead of continuing this approach, I'm going to implement a new
facility based on the output of `make` when passed the -d flag (which
prints dependency information). This new mechanism is completely
automatic and doesn't need maintainers to follow a convention. To that
end, remove most of the work performed in r238008 that supports the
print_all_generated_files target.
At the same time, it's important for the sets of targets and their
dependencies to be complete and correct. Therefore, also include
changes to bring those up-to-date. As part of that, you'll see
prevalent use of a particular technique. Here's an example:
BYTECODE_FILES = \
Bytecodes.h \
BytecodeIndices.h \
BytecodeStructs.h \
InitBytecodes.asm \
#
BYTECODE_FILES_PATTERNS = $(subst .,%,$(BYTECODE_FILES))
all : $(BYTECODE_FILES)
$(BYTECODE_FILES_PATTERNS): $(wildcard $(JavaScriptCore)/generator/*.rb) $(JavaScriptCore)/bytecode/BytecodeList.rb
...
These lines indicate a set of generated files (those specified in
BYTECODE_FILES). These files are generated by the BytecodeList.rb
tool. But, as opposed to the normal rule where a single foo.output is
generated by foo.input plus some additional dependencies, this rule
produces multiple output files from a tool whose connection to the
output files is not immediately clear. A special approach is needed
where a single rule produces multiple output files. The normal way to
implement this is to use an .INTERMEDIATE target. However, we used
this approach in the past and ran into a problem with it, addressing
it with an alternate approach in r210507. The above example shows this
approach. The .'s in the list of target files are replaced with %'s,
and the result is used as the left side of the dependency rule.
* DerivedSources.make:
2018-11-28 Keith Rollin <krollin@apple.com>
Remove Postprocess Headers dependencies
https://bugs.webkit.org/show_bug.cgi?id=192023
<rdar://problem/46283377>
Reviewed by Mark Lam.
JavaScriptCore's Xcode Postprocess Headers build phase used to have a
dependency on a specific handful of files. In r234227, the script used
in this phase (postprocess-headers.sh) was completely rewritten to
operate on *all* files in JSC's Public and Private headers directories
instead of just this handful. This rewrite makes the previous
dependency specification insufficient, leading to incorrect
incremental builds if the right files weren't touched. Address this by
removing the dependencies completely. This will cause
postprocess-headers.sh to always be executed, even when none of its
files are touch. Running this script all the time is OK, since it has
built-in protections against unnecessarily touching files that haven't
changed.
* JavaScriptCore.xcodeproj/project.pbxproj:
2018-11-27 Mark Lam <mark.lam@apple.com>
ENABLE_FAST_JIT_PERMISSIONS should be false for iosmac.
https://bugs.webkit.org/show_bug.cgi?id=192055
<rdar://problem/46288783>
Reviewed by Saam Barati.
* Configurations/FeatureDefines.xcconfig:
2018-11-27 Saam barati <sbarati@apple.com>
r238510 broke scopes of size zero
https://bugs.webkit.org/show_bug.cgi?id=192033
<rdar://problem/46281734>
Reviewed by Keith Miller.
In r238510, I wrote the loop like this:
`for (ScopeOffset offset { 0 }; offset <= symbolTable->maxScopeOffset(); offset += 1)`
This breaks for scopes of size zero because maxScopeOffset() will be UINT_MAX.
This patch fixes this by writing the loop as:
`for (unsigned offset = 0; offset < symbolTable->scopeSize(); ++offset)`
* dfg/DFGObjectAllocationSinkingPhase.cpp:
2018-11-27 Mark Lam <mark.lam@apple.com>
ASSERTION FAILED: capacity && isPageAligned(capacity) in JSC::CLoopStack::CLoopStack(JSC::VM&).
https://bugs.webkit.org/show_bug.cgi?id=192018
Reviewed by Saam Barati.
This assertion failed because the regress-191579.js test was specifying
--maxPerThreadStackUsage=400000 i.e. it was running with a stack size that is not
page aligned. Given that the user can specify any arbitrary stack size, and the
CLoop stack expects to be page aligned, we'll just round up the requested capacity
to the next page alignment.
* interpreter/CLoopStack.cpp:
(JSC::CLoopStack::CLoopStack):
2018-11-27 Mark Lam <mark.lam@apple.com>
[Re-landing] NaNs read from Wasm code needs to be be purified.
https://bugs.webkit.org/show_bug.cgi?id=191056
<rdar://problem/45660341>
Reviewed by Filip Pizlo.
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
2018-11-27 Timothy Hatcher <timothy@apple.com>
Web Inspector: Add support for forcing color scheme appearance in DOM tree.
https://bugs.webkit.org/show_bug.cgi?id=191820
rdar://problem/46153172
Reviewed by Devin Rousso.
* inspector/protocol/Page.json: Added setForcedAppearance.
Also added the defaultAppearanceDidChange event and Appearance enum.
2018-11-27 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r238509.
Causes JSC tests to fail on iOS.
Reverted changeset:
"NaNs read from Wasm code needs to be be purified."
https://bugs.webkit.org/show_bug.cgi?id=191056
https://trac.webkit.org/changeset/238509
2018-11-27 Mark Lam <mark.lam@apple.com>
Introducing a ENABLE_SEPARATED_WX_HEAP macro.
https://bugs.webkit.org/show_bug.cgi?id=192013
<rdar://problem/45494310>
Reviewed by Keith Miller.
This makes the code a little more readable.
I put the definition of ENABLE_SEPARATED_WX_HEAP in JSC's config.h instead of
Platform.h because ENABLE_SEPARATED_WX_HEAP is only needed inside JSC. Also,
ENABLE_SEPARATED_WX_HEAP depends on ENABLE(FAST_JIT_PERMISSIONS), which is only
defined for JSC.
* config.h:
* jit/ExecutableAllocator.cpp:
(JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
(JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
* jit/ExecutableAllocator.h:
(JSC::performJITMemcpy):
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
2018-11-26 Caio Lima <ticaiolima@gmail.com>
Re-introduce op_bitnot
https://bugs.webkit.org/show_bug.cgi?id=190923
Reviewed by Yusuke Suzuki.
With the introduction of BigInt as a new type, we can't emit bitwise
not as `x ^ -1` anymore, because this is incompatible with the new type.
Based on that, this Patch is adding `op_bitnot` as a new operation
into LLInt, as well as introducing ArithBitNot node into DFG to support
JIT compilation of such opcode. We will use the ValueProfile of this
intruction in the future to generate better code when its operand
is not Int32.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::not32):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::not32):
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::not32):
* bytecode/BytecodeList.rb:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* bytecode/Opcode.h:
(JSC::padOpcodeName):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitUnaryOp):
* bytecompiler/NodesCodegen.cpp:
(JSC::UnaryPlusNode::emitBytecode):
(JSC::BitwiseNotNode::emitBytecode): Deleted.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileBitwiseNot):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileArithBitNot):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JIT.h:
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_bitnot):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* offlineasm/cloop.rb:
* parser/NodeConstructors.h:
(JSC::BitwiseNotNode::BitwiseNotNode):
* parser/Nodes.h:
* parser/ResultType.h:
(JSC::ResultType::bigIntOrInt32Type):
(JSC::ResultType::forBitOp):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
2018-11-26 Saam barati <sbarati@apple.com>
InPlaceAbstractState::endBasicBlock rule for SetLocal should filter the value based on the flush format
https://bugs.webkit.org/show_bug.cgi?id=191956
<rdar://problem/45665806>
Reviewed by Yusuke Suzuki.
This is a similar bug to what Keith fixed in r232134. The issue is if we have
a program like this:
a: JSConstant(jsNumber(0))
b: SetLocal(Int32:@a, loc1, FlushedInt32)
c: ArrayifyToStructure(Cell:@a)
d: Jump(...)
At the point in the program right after the Jump, a GetLocal for loc1
would return whatever the ArrayifyToStructure resulting type is. This breaks
the invariant that a GetLocal must return a value that is a subtype of its
FlushFormat. InPlaceAbstractState::endBasicBlock will know if a SetLocal is
the final node touching a local slot. If so, it'll see if any nodes later
in the block may have refined the type of the value stored in that slot. If
so, endBasicBlock() further refines the type to ensure that any GetLocals
loading from the same slot will result in having this more refined type.
However, we must ensure that this logic only considers types within the
hierarchy of the variable access data's FlushFormat, otherwise, we may
break the invariant that a GetLocal's type is a subtype of its FlushFormat.
* dfg/DFGInPlaceAbstractState.cpp:
(JSC::DFG::InPlaceAbstractState::endBasicBlock):
2018-11-26 Saam barati <sbarati@apple.com>
Object allocation sinking phase needs to iterate each scope offset instead of just iterating the symbol table's hashmap when handling an activation
https://bugs.webkit.org/show_bug.cgi?id=191958
<rdar://problem/46221877>
Reviewed by Yusuke Suzuki.
There may be more entries in an activation than unique variables
in a symbol table's hashmap. For example, if you have two parameters
to a function, and they both are the same name, and the function
uses eval, we'll end up with two scope slots, but only a single
entry in the hashmap in the symbol table. Object allocation sinking
phase was previously iterating over the hashmap, assuming these
values were equivalent. This is wrong in the above case. Instead,
we need to iterate over each scope offset.
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* runtime/GenericOffset.h:
(JSC::GenericOffset::operator+=):
(JSC::GenericOffset::operator-=):
2018-11-26 Mark Lam <mark.lam@apple.com>
NaNs read from Wasm code needs to be be purified.
https://bugs.webkit.org/show_bug.cgi?id=191056
<rdar://problem/45660341>
Reviewed by Filip Pizlo.
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
2018-11-26 Tadeu Zagallo <tzagallo@apple.com>
ASSERTION FAILED: m_outOfLineJumpTargets.contains(bytecodeOffset)
https://bugs.webkit.org/show_bug.cgi?id=191716
<rdar://problem/45723878>
Reviewed by Saam Barati.
After https://bugs.webkit.org/show_bug.cgi?id=187373, when updating
jump targets during generatorification, we only stored the new jump
target when it changed. However, the out-of-line jump targets are
cleared at the beginning of the pass, so we need to store it
unconditionally.
* bytecode/PreciseJumpTargetsInlines.h:
(JSC::extractStoredJumpTargetsForInstruction):
(JSC::updateStoredJumpTargetsForInstruction):
2018-11-23 Wenson Hsieh <wenson_hsieh@apple.com>
Enable drag and drop support for iOSMac
https://bugs.webkit.org/show_bug.cgi?id=191818
<rdar://problem/43907454>
Reviewed by Dean Jackson.
* Configurations/FeatureDefines.xcconfig:
2018-11-22 Mark Lam <mark.lam@apple.com>
Make the jsc shell's dumpException() more robust against long exception strings.
https://bugs.webkit.org/show_bug.cgi?id=191910
<rdar://problem/46212980>
Reviewed by Michael Saboff.
This only affects the dumping of the exception string in the jsc shell due to
unhandled exceptions or exceptions at shell boot time before any JS code is
running.
* jsc.cpp:
(dumpException):
2018-11-21 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Drop ARM_TRADITIONAL support in LLInt, baseline JIT, and DFG
https://bugs.webkit.org/show_bug.cgi?id=191675
Reviewed by Mark Lam.
We no longer maintain ARM_TRADITIONAL LLInt and JIT in JSC. This architecture will use
CLoop instead. This patch removes ARM_TRADITIONAL support in LLInt and JIT.
Discussed in https://lists.webkit.org/pipermail/webkit-dev/2018-October/030220.html.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* assembler/ARMAssembler.cpp: Removed.
* assembler/ARMAssembler.h: Removed.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::linkCode):
(JSC::LinkBuffer::dumpCode):
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::patchableBranch32):
* assembler/MacroAssemblerARM.cpp: Removed.
* assembler/MacroAssemblerARM.h: Removed.
* assembler/PerfLog.cpp:
* assembler/PerfLog.h:
* assembler/ProbeContext.h:
(JSC::Probe::CPUState::pc):
(JSC::Probe::CPUState::fp):
(JSC::Probe::CPUState::sp):
* assembler/testmasm.cpp:
(JSC::isPC):
(JSC::testProbeModifiesStackPointer):
(JSC::testProbeModifiesStackValues):
* bytecode/InlineAccess.h:
(JSC::InlineAccess::sizeForPropertyAccess):
(JSC::InlineAccess::sizeForPropertyReplace):
(JSC::InlineAccess::sizeForLengthAccess):
* dfg/DFGSpeculativeJIT.h:
* disassembler/CapstoneDisassembler.cpp:
(JSC::tryToDisassemble):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::debugCall):
* jit/AssemblyHelpers.h:
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsImpl):
(JSC::CCallHelpers::prepareForTailCallSlow):
* jit/CallFrameShuffler.cpp:
(JSC::CallFrameShuffler::prepareForTailCall):
* jit/HostCallReturnValue.cpp:
* jit/JITMathIC.h:
(JSC::isProfileEmpty):
* jit/RegisterSet.cpp:
(JSC::RegisterSet::reservedHardwareRegisters):
(JSC::RegisterSet::calleeSaveRegisters):
(JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
(JSC::RegisterSet::dfgCalleeSaveRegisters):
* jit/Repatch.cpp:
(JSC::forceICFailure):
* jit/ThunkGenerators.cpp:
(JSC::nativeForGenerator):
* llint/LLIntOfflineAsmConfig.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* offlineasm/arm.rb:
* offlineasm/backends.rb:
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::generateEnter):
(JSC::Yarr::YarrGenerator::generateReturn):
2018-11-21 Saam barati <sbarati@apple.com>
DFGSpeculativeJIT should not &= exitOK with mayExit(node)
https://bugs.webkit.org/show_bug.cgi?id=191897
<rdar://problem/45871998>
Reviewed by Mark Lam.
exitOK is a statement about it being legal to exit. mayExit() is about being
conservative and returning false only if an OSR exit *could never* happen.
mayExit() tries to be as smart as possible to see if it can return false.
It can't return false if a runtime exit *could* happen. However, there is
code in the compiler where mayExit() returns false (because it uses data
generated from AI about type checks being proved), but the code we emit in the
compiler backend unconditionally generates an OSR exit, even if that exit may
never execute. For example, let's say we have this IR:
SomeNode(Boolean:@input)
And we always emit code like this as a way of emitting a boolean type check:
jump L1 if input == true
jump L1 if input == false
emit an OSR exit
In such a program, when we generate the above OSR exit, in a validationEnabled()
build, and if @input is proved to be a boolean, we'll end up crashing because we
have the bogus assertion saying !exitOK. This is one reason why things are cleaner
if we don't conflate mayExit() with exitOK.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2018-11-21 Saam barati <sbarati@apple.com>
Fix assertion in KnownCellUse inside SpeculativeJIT::speculate
https://bugs.webkit.org/show_bug.cgi?id=191895
<rdar://problem/46167406>
Reviewed by Mark Lam.
We were asserting that the input edge should have type SpecCell but it should
really be SpecCellCheck since the type filter for KnownCellUse is SpecCellCheck.
This patch cleans up that assertion code by joining a bunch of cases into a
single function call which grabs the type filter for the edge UseKind and
asserts that the incoming edge meets the type filter criteria.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::speculate):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::speculate):
2018-11-21 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Use ProtoCallFrame::numberOfRegisters instead of raw number `4`
https://bugs.webkit.org/show_bug.cgi?id=191877
Reviewed by Sam Weinig.
Instead of hard-coding `4` into LowLevelInterpreter, use ProtoCallFrame::numberOfRegisters.
* interpreter/ProtoCallFrame.h:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2018-11-21 Mark Lam <mark.lam@apple.com>
Creating a wasm memory that is bigger than the ArrayBuffer limit but smaller than the spec limit should throw OOME not RangeError.
https://bugs.webkit.org/show_bug.cgi?id=191776
<rdar://problem/46152851>
Reviewed by Saam Barati.
* wasm/WasmMemory.cpp:
(JSC::Wasm::Memory::tryCreate):
- return nullptr if the requested bytes exceed MAX_ARRAY_BUFFER_SIZE.
The clients will already do a null check and throw an OutOfMemoryError if needed.
(JSC::Wasm::Memory::grow):
- throw OOME if newPageCount.bytes() > MAX_ARRAY_BUFFER_SIZE.
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::constructJSWebAssemblyMemory):
- throw OOME if newPageCount.bytes() > MAX_ARRAY_BUFFER_SIZE.
2018-11-21 Caio Lima <ticaiolima@gmail.com>
[BigInt] JSBigInt::createWithLength should throw when length is greater than JSBigInt::maxLength
https://bugs.webkit.org/show_bug.cgi?id=190836
Reviewed by Saam Barati and Yusuke Suzuki.
In this patch we are creating a new method called `JSBigInt::createWithLengthUnchecked`
where we allocate a BigInt trusting the length received as argument.
With this additional method, we now check if length passed to
`JSBigInt::tryCreateWithLength` is not greater than JSBigInt::maxLength.
When the length is greater than JSBigInt::maxLength, we then throw OOM
exception.
This required us to change the interface of some JSBigInt operations to
receive `ExecState*` instead of `VM&`. We changed only operations that
can throw because of OOM.
We beleive that this approach of throwing instead of finishing the
execution abruptly is better because JS programs can catch such
exception and handle this issue properly.
* dfg/DFGOperations.cpp:
* jit/JITOperations.cpp:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::createZero):
(JSC::JSBigInt::tryCreateWithLength):
(JSC::JSBigInt::createWithLengthUnchecked):
(JSC::JSBigInt::createFrom):
(JSC::JSBigInt::multiply):
(JSC::JSBigInt::divide):
(JSC::JSBigInt::copy):
(JSC::JSBigInt::unaryMinus):
(JSC::JSBigInt::remainder):
(JSC::JSBigInt::add):
(JSC::JSBigInt::sub):
(JSC::JSBigInt::bitwiseAnd):
(JSC::JSBigInt::bitwiseOr):
(JSC::JSBigInt::bitwiseXor):
(JSC::JSBigInt::absoluteAdd):
(JSC::JSBigInt::absoluteSub):
(JSC::JSBigInt::absoluteDivWithDigitDivisor):
(JSC::JSBigInt::absoluteDivWithBigIntDivisor):
(JSC::JSBigInt::absoluteLeftShiftAlwaysCopy):
(JSC::JSBigInt::absoluteBitwiseOp):
(JSC::JSBigInt::absoluteAddOne):
(JSC::JSBigInt::absoluteSubOne):
(JSC::JSBigInt::toStringGeneric):
(JSC::JSBigInt::rightTrim):
(JSC::JSBigInt::allocateFor):
(JSC::JSBigInt::createWithLength): Deleted.
* runtime/JSBigInt.h:
* runtime/Operations.cpp:
(JSC::jsAddSlowCase):
* runtime/Operations.h:
(JSC::jsSub):
(JSC::jsMul):
2018-11-20 Mark Lam <mark.lam@apple.com>
Remove invalid assertion in VMTraps::SignalSender's SignalAction.
https://bugs.webkit.org/show_bug.cgi?id=191856
<rdar://problem/46089992>
Reviewed by Yusuke Suzuki.
The ASSERT(vm.traps().needTrapHandling()) assertion in SignalSender's SigAction
function is invalid because we can't be sure that the trap has been handled yet
by the time the trap fires. This is because the main thread may also check traps
(in LLInt, baseline JIT and VM runtime code). There's a race to handle the trap.
Hence, the SigAction cannot assume that the trap still needs handling by the time
it is executed. This patch removed the invalid assertion.
Also renamed m_trapSet to m_condition because it is a AutomaticThreadCondition,
and all the ways it is used is as a condvar. The m_trapSet name doesn't seem
appropriate nor meaningful.
* runtime/VMTraps.cpp:
(JSC::VMTraps::tryInstallTrapBreakpoints):
- Added a !needTrapHandling() check as an optimization: there's no need to install
VMTrap breakpoints if someone already beat us to handling the trap (remember,
the main thread is racing against the VMTraps signalling thread to handle the
trap too). We only need to install the VMTraps breakpoints if we need DFG/FTL
compiled code to deopt so that they can check and handle pending traps. If the
trap has already been handled, it's better to not deopt any DFG/FTL functions.
(JSC::VMTraps::willDestroyVM):
(JSC::VMTraps::fireTrap):
(JSC::VMTraps::VMTraps):
* runtime/VMTraps.h:
2018-11-21 Dominik Infuehr <dinfuehr@igalia.com>
Enable JIT on ARM/Linux
https://bugs.webkit.org/show_bug.cgi?id=191548
Reviewed by Yusuke Suzuki.
Enable JIT by default on ARMv7/Linux after it was disabled with
recent bytcode format change.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::getICStatusMap):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::metadata):
* bytecode/InByIdStatus.cpp:
(JSC::InByIdStatus::computeFor):
* bytecode/Instruction.h:
(JSC::Instruction::cast):
* bytecode/MetadataTable.h:
(JSC::MetadataTable::forEach):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFor):
(JSC::PutByIdStatus::hasExitSite): Deleted.
* bytecode/PutByIdStatus.h:
* dfg/DFGOSRExit.cpp:
(JSC::DFG::reifyInlinedCallFrames):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
* generator/Argument.rb:
* generator/Opcode.rb:
* jit/GPRInfo.h:
* jit/JIT.h:
* jit/JITArithmetic32_64.cpp:
(JSC::JIT::emit_compareAndJump):
(JSC::JIT::emit_compareUnsignedAndJump):
(JSC::JIT::emit_compareUnsigned):
(JSC::JIT::emit_compareAndJumpSlow):
(JSC::JIT::emit_op_unsigned):
(JSC::JIT::emit_op_inc):
(JSC::JIT::emit_op_dec):
(JSC::JIT::emitBinaryDoubleOp):
(JSC::JIT::emit_op_mod):
(JSC::JIT::emitSlow_op_mod):
* jit/JITCall32_64.cpp:
(JSC::JIT::emitPutCallResult):
(JSC::JIT::emit_op_ret):
(JSC::JIT::emitSlow_op_call):
(JSC::JIT::emitSlow_op_tail_call):
(JSC::JIT::emitSlow_op_call_eval):
(JSC::JIT::emitSlow_op_call_varargs):
(JSC::JIT::emitSlow_op_tail_call_varargs):
(JSC::JIT::emitSlow_op_tail_call_forward_arguments):
(JSC::JIT::emitSlow_op_construct_varargs):
(JSC::JIT::emitSlow_op_construct):
(JSC::JIT::emit_op_call):
(JSC::JIT::emit_op_tail_call):
(JSC::JIT::emit_op_call_eval):
(JSC::JIT::emit_op_call_varargs):
(JSC::JIT::emit_op_tail_call_varargs):
(JSC::JIT::emit_op_tail_call_forward_arguments):
(JSC::JIT::emit_op_construct_varargs):
(JSC::JIT::emit_op_construct):
(JSC::JIT::compileSetupFrame):
(JSC::JIT::compileCallEval):
(JSC::JIT::compileCallEvalSlowCase):
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
(JSC::JIT::compileSetupVarargsFrame): Deleted.
* jit/JITInlines.h:
(JSC::JIT::updateTopCallFrame):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_catch):
(JSC::JIT::emitSlow_op_loop_hint):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_mov):
(JSC::JIT::emit_op_end):
(JSC::JIT::emit_op_jmp):
(JSC::JIT::emit_op_new_object):
(JSC::JIT::emitSlow_op_new_object):
(JSC::JIT::emit_op_overrides_has_instance):
(JSC::JIT::emit_op_instanceof):
(JSC::JIT::emit_op_instanceof_custom):
(JSC::JIT::emitSlow_op_instanceof):
(JSC::JIT::emitSlow_op_instanceof_custom):
(JSC::JIT::emit_op_is_empty):
(JSC::JIT::emit_op_is_undefined):
(JSC::JIT::emit_op_is_boolean):
(JSC::JIT::emit_op_is_number):
(JSC::JIT::emit_op_is_cell_with_type):
(JSC::JIT::emit_op_is_object):
(JSC::JIT::emit_op_to_primitive):
(JSC::JIT::emit_op_set_function_name):
(JSC::JIT::emit_op_not):
(JSC::JIT::emit_op_jfalse):
(JSC::JIT::emit_op_jtrue):
(JSC::JIT::emit_op_jeq_null):
(JSC::JIT::emit_op_jneq_null):
(JSC::JIT::emit_op_jneq_ptr):
(JSC::JIT::emit_op_eq):
(JSC::JIT::emitSlow_op_eq):
(JSC::JIT::emit_op_jeq):
(JSC::JIT::emitSlow_op_jeq):
(JSC::JIT::emit_op_neq):
(JSC::JIT::emitSlow_op_neq):
(JSC::JIT::emit_op_jneq):
(JSC::JIT::emitSlow_op_jneq):
(JSC::JIT::compileOpStrictEq):
(JSC::JIT::emit_op_stricteq):
(JSC::JIT::emit_op_nstricteq):
(JSC::JIT::compileOpStrictEqJump):
(JSC::JIT::emit_op_jstricteq):
(JSC::JIT::emit_op_jnstricteq):
(JSC::JIT::emitSlow_op_jstricteq):
(JSC::JIT::emitSlow_op_jnstricteq):
(JSC::JIT::emit_op_eq_null):
(JSC::JIT::emit_op_neq_null):
(JSC::JIT::emit_op_throw):
(JSC::JIT::emit_op_to_number):
(JSC::JIT::emit_op_to_string):
(JSC::JIT::emit_op_to_object):
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_identity_with_profile):
(JSC::JIT::emit_op_get_parent_scope):
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emit_op_switch_char):
(JSC::JIT::emit_op_switch_string):
(JSC::JIT::emit_op_debug):
(JSC::JIT::emit_op_enter):
(JSC::JIT::emit_op_get_scope):
(JSC::JIT::emit_op_create_this):
(JSC::JIT::emit_op_to_this):
(JSC::JIT::emit_op_check_tdz):
(JSC::JIT::emit_op_has_structure_property):
(JSC::JIT::privateCompileHasIndexedProperty):
(JSC::JIT::emit_op_has_indexed_property):
(JSC::JIT::emitSlow_op_has_indexed_property):
(JSC::JIT::emit_op_get_direct_pname):
(JSC::JIT::emit_op_enumerator_structure_pname):
(JSC::JIT::emit_op_enumerator_generic_pname):
(JSC::JIT::emit_op_profile_type):
(JSC::JIT::emit_op_log_shadow_chicken_prologue):
(JSC::JIT::emit_op_log_shadow_chicken_tail):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_put_getter_by_id):
(JSC::JIT::emit_op_put_setter_by_id):
(JSC::JIT::emit_op_put_getter_setter_by_id):
(JSC::JIT::emit_op_put_getter_by_val):
(JSC::JIT::emit_op_put_setter_by_val):
(JSC::JIT::emit_op_del_by_id):
(JSC::JIT::emit_op_del_by_val):
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emitGetByValWithCachedId):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emit_op_put_by_val_direct):
(JSC::JIT::emit_op_put_by_val):
(JSC::JIT::emitGenericContiguousPutByVal):
(JSC::JIT::emitArrayStoragePutByVal):
(JSC::JIT::emitPutByValWithCachedId):
(JSC::JIT::emitSlow_op_put_by_val):
(JSC::JIT::emit_op_try_get_by_id):
(JSC::JIT::emitSlow_op_try_get_by_id):
(JSC::JIT::emit_op_get_by_id_direct):
(JSC::JIT::emitSlow_op_get_by_id_direct):
(JSC::JIT::emit_op_get_by_id):
(JSC::JIT::emitSlow_op_get_by_id):
(JSC::JIT::emit_op_get_by_id_with_this):
(JSC::JIT::emitSlow_op_get_by_id_with_this):
(JSC::JIT::emit_op_put_by_id):
(JSC::JIT::emitSlow_op_put_by_id):
(JSC::JIT::emit_op_in_by_id):
(JSC::JIT::emitSlow_op_in_by_id):
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emitSlow_op_get_from_scope):
(JSC::JIT::emit_op_put_to_scope):
(JSC::JIT::emitSlow_op_put_to_scope):
(JSC::JIT::emit_op_get_from_arguments):
(JSC::JIT::emit_op_put_to_arguments):
* jit/RegisterSet.cpp:
(JSC::RegisterSet::vmCalleeSaveRegisters):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LowLevelInterpreter.asm:
* runtime/SamplingProfiler.cpp:
(JSC::tryGetBytecodeIndex):
2018-11-20 Saam barati <sbarati@apple.com>
Merging an IC variant may lead to the IC status containing overlapping structure sets
https://bugs.webkit.org/show_bug.cgi?id=191869
<rdar://problem/45403453>
Reviewed by Mark Lam.
When merging two IC variant lists, we may end up in a world where we have
overlapping structure sets. We defend against this when we append a new
variant, but we should also defend against it once we merge in a new variant.
Consider this case with MultiPutByOffset, where we merge two PutByIdStatuses
together, P1 and P2.
Let's consider these structures:
s1 = {}
s2 = {p: 0}
s3 = {p: 0, p2: 1}
P1 contains these variants:
Transition: [s1 => s2]
Replace: [s2, s3]
P2 contains:
Replace: [s2]
Because of the ordering of the variants, we may end up combining
P2's replace into P1's transition, forming this new list:
Transition: [(s1, s2) => s2]
Replace: [s2, s3]
Obviously the ideal thing here is to have some ordering when we merge
in variants to choose the most ideal option. It'd be ideal for P2's
Replace to be merged into P1's replace.
If we notice that this is super important, we can implement some kind
of ordering. None of our tests (until this patch) stress this. This patch
just makes it so we defend against this crazy scenario by falling back
to the slow path gracefully. This prevents us from emitting invalid
IR in FTL->B3 lowering by creating a switch with two case labels being
identical values.
* bytecode/ICStatusUtils.h:
(JSC::appendICStatusVariant):
2018-11-20 Fujii Hironori <Hironori.Fujii@sony.com>
REGRESSION(r238039) WebCore::JSDOMGlobalObject::createStructure is using JSC::Structure::create without including StructureInlines.h
https://bugs.webkit.org/show_bug.cgi?id=191626
<rdar://problem/46161064>
Unreviewed adding comment for my change r238366.
* runtime/Structure.h: Added a comment for Structure::create.
2018-11-19 Mark Lam <mark.lam@apple.com>
globalFuncImportModule() should return a promise when it clears exceptions.
https://bugs.webkit.org/show_bug.cgi?id=191792
<rdar://problem/46090763>
Reviewed by Michael Saboff.
If we're clearing the exceptions in a CatchScope, then it means that we've handled
the exception, and is able to proceed in a normal manner. Hence, we should not
return the empty JSValue in this case: instead, we should return a Promise as
expected by import's API.
The only time when we can't return a promise is when we fail to create a Promise.
In that case, we should be propagating the exception.
Hence, globalFuncImportModule() contains a ThrowScope (for propagating the
exception that arises from failure to create the Promise) wrapping a CatchScope
(for catching any exception that arises from failure to execute the import).
Also fixed similar issues, and some exception check issues in JSModuleLoader and
the jsc shell.
* jsc.cpp:
(GlobalObject::moduleLoaderImportModule):
(GlobalObject::moduleLoaderFetch):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncImportModule):
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::loadAndEvaluateModule):
(JSC::JSModuleLoader::loadModule):
(JSC::JSModuleLoader::requestImportModule):
(JSC::JSModuleLoader::importModule):
(JSC::JSModuleLoader::resolve):
(JSC::JSModuleLoader::fetch):
(JSC::moduleLoaderParseModule):
(JSC::moduleLoaderResolveSync):
2018-11-19 Alex Christensen <achristensen@webkit.org>
Add SPI to disable JIT in a WKWebView
https://bugs.webkit.org/show_bug.cgi?id=191822
<rdar://problem/28119360>
Reviewed by Geoffrey Garen.
* jit/ExecutableAllocator.cpp:
(JSC::jitDisabled):
(JSC::allowJIT):
(JSC::ExecutableAllocator::setJITEnabled):
* jit/ExecutableAllocator.h:
(JSC::ExecutableAllocator::setJITEnabled):
2018-11-19 Fujii Hironori <Hironori.Fujii@sony.com>
[MSVC] X86Assembler.h(108): error C2666: 'WebCore::operator -': 7 overloads have similar conversions
https://bugs.webkit.org/show_bug.cgi?id=189467
<rdar://problem/44290945>
Reviewed by Mark Lam.
This issue has happened several times. And, it seems that it will
take more time for Microsoft to fix the MSVC bug. We need a
effective workaround not to repeat this issue until they fix MSVC.
Remove ": int8_t" of RegisterID only for COMPILER(MSVC).
* assembler/X86Assembler.h: Added JSC_X86_ASM_REGISTER_ID_ENUM_BASE_TYPE macro.
2018-11-19 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[WebAssembly] I64 arguments / return value check should be moved from callWebAssemblyFunction to JSToWasm wrapper
https://bugs.webkit.org/show_bug.cgi?id=190512
Reviewed by Keith Miller.
This patch moves I64 arguments / return value check from callWebAssemblyFunction to JSToWasm wrapper. Since this
check can be done when compiling the function, we should encode the result into the generated wrapper instead of
checking every time we call callWebAssemblyFunction. This change is also one of the steps removing callWebAssemblyFunction
entirely.
* wasm/WasmExceptionType.h:
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::createJSToWasmWrapper):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
* wasm/js/WebAssemblyWrapperFunction.cpp:
(JSC::callWebAssemblyWrapperFunction):
2018-11-12 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Consider removing double load for accessing the instructions from LLInt
https://bugs.webkit.org/show_bug.cgi?id=190932
Reviewed by Mark Lam.
Changing InstructionStream to RefCountedArray like structure involves so much changes
including BytecodeGraph, PreciseJumpTargets etc. Instead, CodeBlock simply hold a raw
pointer to the InstructionStream's data. Since InstructionStream is not changed
anymore, this pointer is valid while CodeBlock is live.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
* bytecode/CodeBlock.h:
* bytecode/InstructionStream.h:
(JSC::InstructionStream::rawPointer const):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2018-11-18 Fujii Hironori <Hironori.Fujii@sony.com>
REGRESSION(r238039) WebCore::JSDOMGlobalObject::createStructure is using JSC::Structure::create without including StructureInlines.h
https://bugs.webkit.org/show_bug.cgi?id=191626
Reviewed by Yusuke Suzuki.
JSC::Structure::create is used everywhere. It should be defined in
Structure.h, not in StructureInlines.h.
* runtime/Structure.h:
(JSC::Structure::create): Moved.
* runtime/StructureInlines.h: Moved JSC::Structure::create.
2018-11-18 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Unreviewed, rolling in the rest of r237254
https://bugs.webkit.org/show_bug.cgi?id=190340
* parser/ParserModes.h:
* parser/ParserTokens.h:
(JSC::JSTextPosition::JSTextPosition):
(JSC::JSTokenLocation::JSTokenLocation): Deleted.
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
2018-11-17 Devin Rousso <drousso@apple.com>
Web Inspector: Network: add button to show system certificate dialog
https://bugs.webkit.org/show_bug.cgi?id=191458
<rdar://problem/45977019>
Reviewed by Joseph Pecoraro.
* inspector/protocol/Network.json:
Add `getSerializedCertificate` command.
2018-11-17 Dominik Infuehr <dinfuehr@igalia.com>
Fix build with disabled DFG/FTL
https://bugs.webkit.org/show_bug.cgi?id=191256
Reviewed by Yusuke Suzuki.
Fix compilation errors and warnings with both DFG and FTL
disabled at compile-time.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::getICStatusMap):
* bytecode/InByIdStatus.cpp:
(JSC::InByIdStatus::computeFor):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFor):
(JSC::PutByIdStatus::hasExitSite): Deleted.
* bytecode/PutByIdStatus.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_catch):
2018-11-16 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Keep Web Inspector window alive across process swaps (PSON) (Local Inspector)
https://bugs.webkit.org/show_bug.cgi?id=191740
<rdar://problem/45470897>
Reviewed by Timothy Hatcher.
* inspector/InspectorFrontendChannel.h:
Expose EnumTraits for ConnectionType for WebKit IPC messages.
2018-11-16 Filip Pizlo <fpizlo@apple.com>
All users of ArrayBuffer should agree on the same max size
https://bugs.webkit.org/show_bug.cgi?id=191771
Reviewed by Mark Lam.
Array buffers cannot be larger than 0x7fffffff, because otherwise loading typedArray.length in the DFG/FTL would produce
a uint32 or would require a signedness check, neither of which sounds reasonable. It's better to just bound their max size
instead.
* runtime/ArrayBuffer.cpp:
(JSC::ArrayBufferContents::ArrayBufferContents):
(JSC::ArrayBufferContents::tryAllocate):
(JSC::ArrayBufferContents::transferTo):
(JSC::ArrayBufferContents::copyTo):
(JSC::ArrayBufferContents::shareWith):
* runtime/ArrayBuffer.h:
* wasm/WasmMemory.cpp:
(JSC::Wasm::Memory::tryCreate):
(JSC::Wasm::Memory::grow):
* wasm/WasmPageCount.h:
2018-11-16 Saam Barati <sbarati@apple.com>
KnownCellUse should also have SpecCellCheck as its type filter
https://bugs.webkit.org/show_bug.cgi?id=191729
<rdar://problem/45872852>
Reviewed by Filip Pizlo.
We write transformations in the compiler like this where we emit edges with
KnownCellUse if we know we're inserting code at a point where we're dominated
by a Cell check:
a: SomeValue
b: Something(Cell:@a)
c: SomethingElse(@b)
d: CheckNotEmpty(@a)
=>
a: SomeValue
b: Something(Cell:@a)
e: RandomOtherThing(KnownCellUse:@a)
c: SomethingElse(@b)
d: CheckNotEmpty(@a)
However, doing this used to lead to subtly incorrect programs since KnownCellUse
did not allow the empty value to flow through it. We used to end up incorrectly
deleting @d in the above program. We fix this, we make KnownCellUse allow the empty
value to flow through.
* dfg/DFGUseKind.h:
(JSC::DFG::typeFilterFor):
2018-11-16 Tadeu Zagallo <tzagallo@apple.com>
Fix assertion failure on BytecodeGenerator::recordOpcode
https://bugs.webkit.org/show_bug.cgi?id=191724
<rdar://problem/45724395>
Reviewed by Saam Barati.
Since https://bugs.webkit.org/show_bug.cgi?id=187373, we were not
restoring m_lastInstruction after patching the bytecode when
finalizing StructureForInContexts, only m_lastOpcodeID, which led to
the assertion failure.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::StructureForInContext::finalize):
2018-11-15 Mark Lam <mark.lam@apple.com>
RegExpObject's collectMatches should not be using JSArray::push to fill in its match results.
https://bugs.webkit.org/show_bug.cgi?id=191730
<rdar://problem/46048517>
Reviewed by Saam Barati.
According to the spec https://www.ecma-international.org/ecma-262/9.0/index.html#sec-regexp.prototype-@@match,
the RegExp match results are filled in using the spec's CreateDataProperty()
function which does not consult the prototype for setters. JSArray:push()
consults the prototype for setters. We should be using putDirectIndex() instead.
* runtime/RegExpObjectInlines.h:
(JSC::collectMatches):
2018-11-15 Mark Lam <mark.lam@apple.com>
RegExp operations should not take fast patch if lastIndex is not numeric.
https://bugs.webkit.org/show_bug.cgi?id=191731
<rdar://problem/46017305>
Reviewed by Saam Barati.
This is because if lastIndex is an object with a valueOf() method, it can execute
arbitrary code which may have side effects, and side effects are not permitted by
the RegExp fast paths.
* builtins/RegExpPrototype.js:
(globalPrivate.hasObservableSideEffectsForRegExpMatch):
(overriddenName.string_appeared_here.search):
(globalPrivate.hasObservableSideEffectsForRegExpSplit):
(intrinsic.RegExpTestIntrinsic.test):
* builtins/StringPrototype.js:
(globalPrivate.hasObservableSideEffectsForStringReplace):
2018-11-15 Keith Rollin <krollin@apple.com>
Delete old .xcfilelist files
https://bugs.webkit.org/show_bug.cgi?id=191669
<rdar://problem/46081994>
Reviewed by Chris Dumez.
.xcfilelist files were created and added to the Xcode project files in
https://trac.webkit.org/changeset/238008/webkit. However, they caused
build issues and they were removed from the Xcode projects in
https://trac.webkit.org/changeset/238055/webkit. This check-in removes
the files from the repository altogether. They'll ultimately be
replaced with new files with names that indicate whether the
associated files are inputs to the Run Script phase or are files
created by the Run Script phase.
* DerivedSources.xcfilelist: Removed.
* UnifiedSources.xcfilelist: Removed.
2018-11-14 Keith Rollin <krollin@apple.com>
Move scripts for Derived and Unified Sources to external files
https://bugs.webkit.org/show_bug.cgi?id=191670
<rdar://problem/46082278>
Reviewed by Keith Miller.
Move the scripts in the Generate Derived Sources and Generate Unified
Sources Run Script phases from the Xcode projects to external shell
script files. Then invoke those scripts from the Run Script phases.
This refactoring is being performed to support later work that will
invoke these scripts in other contexts.
The scripts were maintained as-is when making the move. I did a little
reformatting and added 'set -e' to the top of each file, but that's
it.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Scripts/generate-derived-sources.sh: Added.
* Scripts/generate-unified-sources.sh: Added.
2018-11-14 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Pass Inspector::FrontendChannel as a reference connect/disconnect methods
https://bugs.webkit.org/show_bug.cgi?id=191612
Reviewed by Matt Baker.
* inspector/InspectorFrontendRouter.cpp:
(Inspector::FrontendRouter::connectFrontend):
(Inspector::FrontendRouter::disconnectFrontend):
* inspector/InspectorFrontendRouter.h:
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::connectFrontend):
(Inspector::JSGlobalObjectInspectorController::disconnectFrontend):
* inspector/JSGlobalObjectInspectorController.h:
* inspector/remote/RemoteControllableTarget.h:
* inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
(Inspector::RemoteConnectionToTarget::setup):
(Inspector::RemoteConnectionToTarget::close):
* inspector/remote/glib/RemoteConnectionToTargetGlib.cpp:
(Inspector::RemoteConnectionToTarget::setup):
(Inspector::RemoteConnectionToTarget::close):
* runtime/JSGlobalObjectDebuggable.cpp:
(JSC::JSGlobalObjectDebuggable::connect):
(JSC::JSGlobalObjectDebuggable::disconnect):
* runtime/JSGlobalObjectDebuggable.h:
2018-11-14 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Keep Web Inspector window alive across process swaps (PSON) (Remote Inspector)
https://bugs.webkit.org/show_bug.cgi?id=191494
<rdar://problem/45469854>
Reviewed by Devin Rousso.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
New domain and resources.
* inspector/protocol/Target.json: Added.
New protocol domain, modeled after Worker.json, to allow for
multiplexing between different targets.
* inspector/InspectorTarget.h:
Each target will instantiate an InspectorTarget and must
provide an identifier, type, and means of connecting/disconnecting
to a frontend channel.
* inspector/agents/InspectorTargetAgent.cpp: Added.
(Inspector::InspectorTargetAgent::InspectorTargetAgent):
(Inspector::InspectorTargetAgent::didCreateFrontendAndBackend):
(Inspector::InspectorTargetAgent::willDestroyFrontendAndBackend):
(Inspector::InspectorTargetAgent::exists):
(Inspector::InspectorTargetAgent::initialized):
(Inspector::InspectorTargetAgent::sendMessageToTarget):
(Inspector::InspectorTargetAgent::sendMessageFromTargetToFrontend):
(Inspector::targetTypeToProtocolType):
(Inspector::buildTargetInfoObject):
(Inspector::InspectorTargetAgent::targetCreated):
(Inspector::InspectorTargetAgent::targetTerminated):
(Inspector::InspectorTargetAgent::connectToTargets):
(Inspector::InspectorTargetAgent::disconnectFromTargets):
* inspector/agents/InspectorTargetAgent.h: Added.
TargetAgent holds a list of targets, and connects/disconnects to each
of the targets when a frontend connects/disconnects.
* inspector/scripts/codegen/generator.py:
Better enum casing of ServiceWorker.
2018-11-14 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Unreviewed, rolling in CodeCache in r237254
https://bugs.webkit.org/show_bug.cgi?id=190340
Land the CodeCache part without adding an additional hash value.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
* bytecode/UnlinkedFunctionExecutable.h:
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::SourceCodeKey):
(JSC::SourceCodeKey::operator== const):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
* runtime/CodeCache.h:
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/FunctionExecutable.h:
2018-11-13 Saam Barati <sbarati@apple.com>
ProxyObject should check for VMInquiry and return early before throwing a stack overflow exception
https://bugs.webkit.org/show_bug.cgi?id=191601
Reviewed by Mark Lam.
This doesn't fix any bugs today, but it may reduce future bugs. It was
always weird that ProxyObject::getOwnPropertySlot with VMInquiry might
throw a stack overflow error instead of just returning false like it
normally does when VMInquiry is passed in.
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::getOwnPropertySlotCommon):
2018-11-13 Saam Barati <sbarati@apple.com>
TypeProfileLog::processLogEntries should stash away any pending exceptions and re-apply them to the VM
https://bugs.webkit.org/show_bug.cgi?id=191600
Reviewed by Mark Lam.
processLogEntries will call into calculatedClassName, which will clear
any exceptions it encounters (it assumes that they're stack overflow exceptions).
However, this code may be called when an exception is already pending on the
VM (e.g, when we throw an exception in the DFG, we compile an OSR exit
offramp, which may compile a baseline codeblock, which will process
the type profiler log). To get around this, processLogEntires should stash
away and re-apply any pending exceptions.
* dfg/DFGDriver.cpp:
(JSC::DFG::compileImpl):
* dfg/DFGOperations.cpp:
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
* jit/JIT.cpp:
(JSC::JIT::doMainThreadPreparationBeforeCompile):
* jit/JITOperations.cpp:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/TypeProfilerLog.cpp:
(JSC::TypeProfilerLog::processLogEntries):
* runtime/TypeProfilerLog.h:
* runtime/VM.cpp:
(JSC::VM::dumpTypeProfilerData):
* runtime/VM.h:
(JSC::VM::DeferExceptionScope::DeferExceptionScope):
* tools/JSDollarVM.cpp:
(JSC::functionFindTypeForExpression):
(JSC::functionReturnTypeFor):
2018-11-13 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r238132.
The test added with this change is timing out on Debug JSC
bots.
Reverted changeset:
"[BigInt] JSBigInt::createWithLength should throw when length
is greater than JSBigInt::maxLength"
https://bugs.webkit.org/show_bug.cgi?id=190836
https://trac.webkit.org/changeset/238132
2018-11-12 Mark Lam <mark.lam@apple.com>
Add OOM detection to StringPrototype's substituteBackreferences().
https://bugs.webkit.org/show_bug.cgi?id=191563
<rdar://problem/45720428>
Reviewed by Saam Barati.
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* runtime/StringPrototype.cpp:
(JSC::substituteBackreferencesSlow):
(JSC::substituteBackreferencesInline):
(JSC::substituteBackreferences):
(JSC::replaceUsingRegExpSearch):
(JSC::replaceUsingStringSearch):
* runtime/StringPrototype.h:
2018-11-13 Mark Lam <mark.lam@apple.com>
LLIntSlowPath's llint_loop_osr and llint_replace should set the topCallFrame.
https://bugs.webkit.org/show_bug.cgi?id=191579
<rdar://problem/45942472>
Reviewed by Saam Barati.
Both of these functions do a lot of work. It would be good for the topCallFrame
to be correct should we need to throw an exception.
For example, we've observed the following crash trace:
* frame #0: WTFCrash() at Assertions.cpp:253
frame #1: ...
frame #2: JSC::StructureIDTable::get(this=0x00006040000162f0, structureID=1874583248) at StructureIDTable.h:129
frame #3: JSC::VM::getStructure(this=0x0000604000016210, id=4022066896) at VM.h:705
frame #4: JSC::JSCell::structure(this=0x00007ffeefbbde30, vm=0x0000604000016210) const at JSCellInlines.h:125
frame #5: JSC::JSCell::classInfo(this=0x00007ffeefbbde30, vm=0x0000604000016210) const at JSCellInlines.h:335
frame #6: JSC::JSCell::inherits(this=0x00007ffeefbbde30, vm=0x0000604000016210, info=0x0000000105eaf020) const at JSCellInlines.h:302
frame #7: JSC::JSObject* JSC::jsCast<JSC::JSObject*, JSC::JSCell>(from=0x00007ffeefbbde30) at JSCast.h:36
frame #8: JSC::asObject(cell=0x00007ffeefbbde30) at JSObject.h:1299
frame #9: JSC::asObject(value=JSValue @ 0x00007ffeefbba380) at JSObject.h:1304
frame #10: JSC::Register::object(this=0x00007ffeefbbdd58) const at JSObject.h:1514
frame #11: JSC::ExecState::jsCallee(this=0x00007ffeefbbdd40) const at CallFrame.h:107
frame #12: JSC::ExecState::isStackOverflowFrame(this=0x00007ffeefbbdd40) const at CallFrameInlines.h:36
frame #13: JSC::StackVisitor::StackVisitor(this=0x00007ffeefbba860, startFrame=0x00007ffeefbbdd40, vm=0x0000631000000800) at StackVisitor.cpp:52
frame #14: JSC::StackVisitor::StackVisitor(this=0x00007ffeefbba860, startFrame=0x00007ffeefbbdd40, vm=0x0000631000000800) at StackVisitor.cpp:41
frame #15: void JSC::StackVisitor::visit<(JSC::StackVisitor::EmptyEntryFrameAction)0, JSC::Interpreter::getStackTrace(JSC::JSCell*, WTF::Vector<JSC::StackFrame, 0ul, WTF::CrashOnOverflow, 16ul>&, unsigned long, unsigned long)::$_3>(startFrame=0x00007ffeefbbdd40, vm=0x0000631000000800, functor=0x00007ffeefbbaa60)::$_3 const&) at StackVisitor.h:147
frame #16: JSC::Interpreter::getStackTrace(this=0x0000602000005db0, owner=0x000062d00020cbe0, results=0x00006020000249d0, framesToSkip=0, maxStackSize=1) at Interpreter.cpp:437
frame #17: JSC::getStackTrace(exec=0x000062d00002c048, vm=0x0000631000000800, obj=0x000062d00020cbe0, useCurrentFrame=true) at Error.cpp:170
frame #18: JSC::ErrorInstance::finishCreation(this=0x000062d00020cbe0, exec=0x000062d00002c048, vm=0x0000631000000800, message=0x00007ffeefbbb800, useCurrentFrame=true) at ErrorInstance.cpp:119
frame #19: JSC::ErrorInstance::create(exec=0x000062d00002c048, vm=0x0000631000000800, structure=0x000062d0000f5730, message=0x00007ffeefbbb800, appender=0x0000000000000000, type=TypeNothing, useCurrentFrame=true)(WTF::String const&, WTF::String const&, JSC::RuntimeType, JSC::ErrorInstance::SourceTextWhereErrorOccurred), JSC::RuntimeType, bool) at ErrorInstance.h:49
frame #20: JSC::createRangeError(exec=0x000062d00002c048, globalObject=0x000062d00002c000, message=0x00007ffeefbbb800, appender=0x0000000000000000)(WTF::String const&, WTF::String const&, JSC::RuntimeType, JSC::ErrorInstance::SourceTextWhereErrorOccurred)) at Error.cpp:68
frame #21: JSC::createRangeError(exec=0x000062d00002c048, globalObject=0x000062d00002c000, message=0x00007ffeefbbb800) at Error.cpp:316
frame #22: JSC::createStackOverflowError(exec=0x000062d00002c048, globalObject=0x000062d00002c000) at ExceptionHelpers.cpp:77
frame #23: JSC::createStackOverflowError(exec=0x000062d00002c048) at ExceptionHelpers.cpp:72
frame #24: JSC::throwStackOverflowError(exec=0x000062d00002c048, scope=0x00007ffeefbbbaa0) at ExceptionHelpers.cpp:335
frame #25: JSC::ProxyObject::getOwnPropertySlotCommon(this=0x000062d000200e40, exec=0x000062d00002c048, propertyName=PropertyName @ 0x00007ffeefbbba80, slot=0x00007ffeefbbc720) at ProxyObject.cpp:372
frame #26: JSC::ProxyObject::getOwnPropertySlot(object=0x000062d000200e40, exec=0x000062d00002c048, propertyName=PropertyName @ 0x00007ffeefbbbd40, slot=0x00007ffeefbbc720) at ProxyObject.cpp:395
frame #27: JSC::JSObject::getNonIndexPropertySlot(this=0x000062d000200e40, exec=0x000062d00002c048, propertyName=PropertyName @ 0x00007ffeefbbbea0, slot=0x00007ffeefbbc720) at JSObjectInlines.h:150
frame #28: bool JSC::JSObject::getPropertySlot<false>(this=0x000062d000200e40, exec=0x000062d00002c048, propertyName=PropertyName @ 0x00007ffeefbbc320, slot=0x00007ffeefbbc720) at JSObject.h:1424
frame #29: JSC::JSObject::calculatedClassName(object=0x000062d000200e40) at JSObject.cpp:535
frame #30: JSC::Structure::toStructureShape(this=0x000062d000007410, value=JSValue @ 0x00007ffeefbbcae0, sawPolyProtoStructure=0x00007ffeefbbcf60) at Structure.cpp:1142
frame #31: JSC::TypeProfilerLog::processLogEntries(this=0x000060400000a950, reason=0x00007ffeefbbd5c0) at TypeProfilerLog.cpp:89
frame #32: JSC::JIT::doMainThreadPreparationBeforeCompile(this=0x0000619000034da0) at JIT.cpp:951
frame #33: JSC::JITWorklist::Plan::Plan(this=0x0000619000034d80, codeBlock=0x000062d0001d88c0, loopOSREntryBytecodeOffset=0) at JITWorklist.cpp:43
frame #34: JSC::JITWorklist::Plan::Plan(this=0x0000619000034d80, codeBlock=0x000062d0001d88c0, loopOSREntryBytecodeOffset=0) at JITWorklist.cpp:42
frame #35: JSC::JITWorklist::compileLater(this=0x0000616000001b80, codeBlock=0x000062d0001d88c0, loopOSREntryBytecodeOffset=0) at JITWorklist.cpp:256
frame #36: JSC::LLInt::jitCompileAndSetHeuristics(codeBlock=0x000062d0001d88c0, exec=0x00007ffeefbbde30, loopOSREntryBytecodeOffset=0) at LLIntSlowPaths.cpp:391
frame #37: llint_replace(exec=0x00007ffeefbbde30, pc=0x00006040000161ba) at LLIntSlowPaths.cpp:516
frame #38: llint_entry at LowLevelInterpreter64.asm:98
frame #39: vmEntryToJavaScript at LowLevelInterpreter64.asm:296
...
This crash occurred because StackVisitor was seeing an invalid topCallFrame while
trying to capture the Error stack while throwing a StackOverflowError below
llint_replace. While in this specific example, it is questionable whether we
should be executing JS code below TypeProfilerLog::processLogEntries(), it is
correct to have set the topCallFrame in llint_replace. We do this by calling
LLINT_BEGIN_NO_SET_PC() at the top of llint_replace.
We also do the same for llint_osr.
Note: both of these LLInt slow path functions are called with a fully initialized
CallFrame. Hence, there's no issue with setting topCallFrame to their CallFrames
for these functions.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
2018-11-13 Caio Lima <ticaiolima@gmail.com>
[BigInt] JSBigInt::createWithLength should throw when length is greater than JSBigInt::maxLength
https://bugs.webkit.org/show_bug.cgi?id=190836
Reviewed by Saam Barati.
In this patch we are creating a new method called `JSBigInt::createWithLengthUnchecked`
where we allocate a BigInt trusting the length received as argument.
With this additional method, we now check if length passed to
`JSBigInt::createWithLength` is not greater than JSBigInt::maxLength.
When the length is greater than maxLength, we then throw OOM
exception.
This required change the interface of some JSBigInt operations to
receive `ExecState*` instead of `VM&`. We changed only operations that
can throw because of OOM.
We beleive that this approach of throwing instead of finishing the
execution abruptly is better because JS programs can catch such
exception and handle this issue properly.
* dfg/DFGOperations.cpp:
* jit/JITOperations.cpp:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::createZero):
(JSC::JSBigInt::tryCreateWithLength):
(JSC::JSBigInt::createWithLengthUnchecked):
(JSC::JSBigInt::createFrom):
(JSC::JSBigInt::multiply):
(JSC::JSBigInt::divide):
(JSC::JSBigInt::copy):
(JSC::JSBigInt::unaryMinus):
(JSC::JSBigInt::remainder):
(JSC::JSBigInt::add):
(JSC::JSBigInt::sub):
(JSC::JSBigInt::bitwiseAnd):
(JSC::JSBigInt::bitwiseOr):
(JSC::JSBigInt::bitwiseXor):
(JSC::JSBigInt::absoluteAdd):
(JSC::JSBigInt::absoluteSub):
(JSC::JSBigInt::absoluteDivWithDigitDivisor):
(JSC::JSBigInt::absoluteDivWithBigIntDivisor):
(JSC::JSBigInt::absoluteLeftShiftAlwaysCopy):
(JSC::JSBigInt::absoluteBitwiseOp):
(JSC::JSBigInt::absoluteAddOne):
(JSC::JSBigInt::absoluteSubOne):
(JSC::JSBigInt::toStringGeneric):
(JSC::JSBigInt::rightTrim):
(JSC::JSBigInt::allocateFor):
(JSC::JSBigInt::createWithLength): Deleted.
* runtime/JSBigInt.h:
* runtime/Operations.cpp:
(JSC::jsAddSlowCase):
* runtime/Operations.h:
(JSC::jsSub):
(JSC::jsMul):
2018-11-12 Devin Rousso <drousso@apple.com>
Web Inspector: Network: show secure certificate details per-request
https://bugs.webkit.org/show_bug.cgi?id=191447
<rdar://problem/30019476>
Reviewed by Joseph Pecoraro.
Add Security domain to hold security related protocol types.
* CMakeLists.txt:
* DerivedSources.make:
* inspector/protocol/Network.json:
* inspector/protocol/Security.json: Added.
* inspector/scripts/codegen/objc_generator.py:
(ObjCGenerator):
2018-11-12 Saam barati <sbarati@apple.com>
Unreviewed. Rollout 238026: It caused ~8% JetStream 2 regressions on some iOS devices
https://bugs.webkit.org/show_bug.cgi?id=191555
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
* bytecode/UnlinkedFunctionExecutable.h:
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::SourceCodeKey):
(JSC::SourceCodeKey::operator== const):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
* runtime/CodeCache.h:
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/FunctionExecutable.h:
2018-11-11 Benjamin Poulain <benjamin@webkit.org>
Fix a fixme: rename wtfObjcMsgSend to wtfObjCMsgSend
https://bugs.webkit.org/show_bug.cgi?id=191492
Reviewed by Alex Christensen.
Rename file.
* API/JSValue.mm:
2018-11-10 Benjamin Poulain <benjamin@webkit.org>
Fix a fixme: rename wtfObjcMsgSend to wtfObjCMsgSend
https://bugs.webkit.org/show_bug.cgi?id=191492
Reviewed by Alex Christensen.
* API/JSValue.mm:
2018-11-10 Michael Catanzaro <mcatanzaro@igalia.com>
Unreviewed, silence -Wunused-variable warning
* bytecode/Opcode.h:
(JSC::padOpcodeName):
2018-11-09 Keith Rollin <krollin@apple.com>
Unreviewed build fix after https://bugs.webkit.org/show_bug.cgi?id=191324
Remove the use of .xcfilelists until their side-effects are better
understood.
* JavaScriptCore.xcodeproj/project.pbxproj:
2018-11-09 Keith Miller <keith_miller@apple.com>
LLInt VectorSizeOffset should be based on offset extraction
https://bugs.webkit.org/show_bug.cgi?id=191468
Reviewed by Yusuke Suzuki.
This patch also adds some usings to LLIntOffsetsExtractor that
make it possible to use the bare names of Vector/RefCountedArray
in offsets extraction.
* llint/LLIntOffsetsExtractor.cpp:
* llint/LowLevelInterpreter.asm:
2018-11-09 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Unreviewed, rolling in CodeCache in r237254
https://bugs.webkit.org/show_bug.cgi?id=190340
Land the CodeCache part, which uses DefaultHash<>::Hash instead of computeHash.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
* bytecode/UnlinkedFunctionExecutable.h:
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::SourceCodeKey):
(JSC::SourceCodeKey::operator== const):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
* runtime/CodeCache.h:
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/FunctionExecutable.h:
2018-11-08 Keith Miller <keith_miller@apple.com>
put_by_val opcodes need to add the number tag as a 64-bit register
https://bugs.webkit.org/show_bug.cgi?id=191456
Reviewed by Saam Barati.
Previously the LLInt would add it as a pointer sized value. That is
wrong if pointer size is less 64-bits.
* llint/LowLevelInterpreter64.asm:
2018-11-08 Ross Kirsling <ross.kirsling@sony.com>
[JSC] isStrWhiteSpace seems redundant with Lexer<UChar>::isWhiteSpace
https://bugs.webkit.org/show_bug.cgi?id=191439
Reviewed by Saam Barati.
* CMakeLists.txt:
* runtime/ParseInt.h:
(JSC::isStrWhiteSpace):
Define isStrWhiteSpace in terms of isWhiteSpace and isLineTerminator.
2018-11-08 Michael Saboff <msaboff@apple.com>
Options::useRegExpJIT() should use jitEnabledByDefault() just like useJIT()
https://bugs.webkit.org/show_bug.cgi?id=191444
Reviewed by Saam Barati.
* runtime/Options.h:
2018-11-08 Fujii Hironori <Hironori.Fujii@sony.com>
[Win] UDis86Disassembler.cpp: warning: format specifies type 'unsigned long' but the argument has type 'uintptr_t' (aka 'unsigned long long')
https://bugs.webkit.org/show_bug.cgi?id=191416
Reviewed by Saam Barati.
* disassembler/UDis86Disassembler.cpp:
(JSC::tryToDisassembleWithUDis86): Use PRIxPTR for uintptr_t.
2018-11-08 Keith Rollin <krollin@apple.com>
Create .xcfilelist files
https://bugs.webkit.org/show_bug.cgi?id=191324
<rdar://problem/45852819>
Reviewed by Alex Christensen.
As part of preparing for enabling XCBuild, create and use .xcfilelist
files. These files are using during Run Script build phases in an
Xcode project. If a Run Script build phase produces new files that are
used later as inputs to subsequent build phases, XCBuild needs to know
about these files. These files can be either specified in an "output
files" section of the Run Script phase editor, or in .xcfilelist files
that are associated with the Run Script build phase.
This patch takes the second approach. It consists of three sets of changes:
- Modify the DerivedSources.make files to have a
'print_all_generated_files" target that produces a list of the files
they create.
- Create a shell script that produces .xcfilelist files from the
output of the previous step, as well as for the files created in the
Generate Unified Sources build steps.
- Add the new .xcfilelist files to the associated projects.
Note that, with these changes, the Xcode workspace and projects can no
longer be fully loaded into Xcode 9. Xcode will attempt to load the
projects that have .xcfilelist files associated with them, but will
fail and display a placeholder for those projects instead. It's
expected that all developers are using Xcode 10 by now and that not
being able to load into Xcode 9 is not a practical issue. Keep in mind
that this is strictly an IDE issue, and that the projects can still be
built with `xcodebuild`.
Also note that the shell script that creates the .xcfilelist files can
also be used to verify that the set of files that's currently checked
in is up-to-date. This checking can be used as part of a check-in hook
or part of check-webkit-style to sooner catch cases where the
.xcfilelist files need to be regenerated.
* DerivedSources.make:
* DerivedSources.xcfilelist: Added.
* JavaScriptCore.xcodeproj/project.pbxproj:
* UnifiedSources.xcfilelist: Added.
2018-11-08 Ross Kirsling <ross.kirsling@sony.com>
U+180E is no longer a whitespace character
https://bugs.webkit.org/show_bug.cgi?id=191415
Reviewed by Saam Barati.
Mongolian Vowel Separator stopped being a valid whitespace character as of ES2016.
(https://github.com/tc39/ecma262/pull/300)
* parser/Lexer.h:
(JSC::Lexer<UChar>::isWhiteSpace):
* runtime/ParseInt.h:
(JSC::isStrWhiteSpace):
* yarr/create_regex_tables:
2018-11-08 Keith Miller <keith_miller@apple.com>
jitEnabledByDefault() should be on useJIT not useBaselineJIT
https://bugs.webkit.org/show_bug.cgi?id=191434
Reviewed by Saam Barati.
* runtime/Options.h:
2018-11-08 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Restrict domains at the target level instead of only at the window level
https://bugs.webkit.org/show_bug.cgi?id=191344
Reviewed by Devin Rousso.
* inspector/protocol/Console.json:
* inspector/protocol/Debugger.json:
* inspector/protocol/Heap.json:
* inspector/protocol/Runtime.json:
Remove workerSupported as it is now no longer necessary. It is implied
by availability being empty (meaning it is supported everywhere).
* inspector/protocol/Inspector.json:
* inspector/protocol/ScriptProfiler.json:
Restrict to "javascript" and "web" debuggables, not available in workers.
* inspector/protocol/Worker.json:
Cleanup, remove empty types list.
* inspector/protocol/Recording.json:
Cleanup, only expose this in the "web" domain for now.
* inspector/scripts/codegen/generate_js_backend_commands.py:
(JSBackendCommandsGenerator.generate_domain):
* inspector/scripts/codegen/models.py:
(Protocol.parse_domain):
Allow a list of debuggable types. Add "worker" even though it is unused
since that is a type we would want to allow or consider.
(Domain.__init__):
(Domains):
Remove now unnecessary workerSupported code.
Allow availability on a domain with only types.
* inspector/scripts/tests/generic/expected/worker-supported-domains.json-result: Removed.
* inspector/scripts/tests/generic/worker-supported-domains.json: Removed.
2018-11-07 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Consider removing double load for accessing the MetadataTable from LLInt
https://bugs.webkit.org/show_bug.cgi?id=190933
Reviewed by Keith Miller.
This patch removes double load for accesses to MetadataTable from LLInt.
MetadataTable is now specially RefCounted class, which has interesting memory layout.
When refcount becomes 0, MetadataTable asks UnlinkedMetadataTable to destroy itself.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::estimatedSize):
(JSC::CodeBlock::visitChildren):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::metadata):
* bytecode/CodeBlockInlines.h:
(JSC::CodeBlock::forEachValueProfile):
(JSC::CodeBlock::forEachArrayProfile):
(JSC::CodeBlock::forEachArrayAllocationProfile):
(JSC::CodeBlock::forEachObjectAllocationProfile):
(JSC::CodeBlock::forEachLLIntCallLinkInfo):
* bytecode/MetadataTable.cpp:
(JSC::MetadataTable::MetadataTable):
(JSC::MetadataTable::~MetadataTable):
(JSC::MetadataTable::sizeInBytes):
* bytecode/MetadataTable.h:
(JSC::MetadataTable::get):
(JSC::MetadataTable::forEach):
(JSC::MetadataTable::ref const):
(JSC::MetadataTable::deref const):
(JSC::MetadataTable::refCount const):
(JSC::MetadataTable::hasOneRef const):
(JSC::MetadataTable::buffer):
(JSC::MetadataTable::linkingData const):
(JSC::MetadataTable::getImpl):
* bytecode/UnlinkedMetadataTable.h:
(JSC::UnlinkedMetadataTable::buffer const):
* bytecode/UnlinkedMetadataTableInlines.h:
(JSC::UnlinkedMetadataTable::UnlinkedMetadataTable):
(JSC::UnlinkedMetadataTable::~UnlinkedMetadataTable):
(JSC::UnlinkedMetadataTable::addEntry):
(JSC::UnlinkedMetadataTable::sizeInBytes):
(JSC::UnlinkedMetadataTable::finalize):
(JSC::UnlinkedMetadataTable::link):
(JSC::UnlinkedMetadataTable::unlink):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
2018-11-07 Caio Lima <ticaiolima@gmail.com>
[BigInt] Add support to BigInt into ValueAdd
https://bugs.webkit.org/show_bug.cgi?id=186177
Reviewed by Keith Miller.
We are adding a very primitive specialization case of BigInts into ValueAdd.
When compiling a speculated version of this node to BigInt, we are currently
calling 'operationAddBigInt', a function that expects only BigInts as
parameter and effectly add numbers using JSBigInt::add. To properly
speculate BigInt operands, we changed ArithProfile to observe when
its result is a BigInt. With this new observation, we are able to identify
when ValueAdd results into a String or BigInt.
Here are some numbers for this specialization running
microbenchmarks:
big-int-simple-add 21.5411+-1.1096 ^ 15.3502+-0.7027 ^ definitely 1.4033x faster
big-int-add-prediction-propagation 13.7762+-0.5578 ^ 10.8117+-0.5330 ^ definitely 1.2742x faster
* bytecode/ArithProfile.cpp:
(JSC::ArithProfile::emitObserveResult):
(JSC::ArithProfile::shouldEmitSetNonNumeric const):
(JSC::ArithProfile::shouldEmitSetBigInt const):
(JSC::ArithProfile::emitSetNonNumeric const):
(JSC::ArithProfile::emitSetBigInt const):
(WTF::printInternal):
(JSC::ArithProfile::shouldEmitSetNonNumber const): Deleted.
(JSC::ArithProfile::emitSetNonNumber const): Deleted.
* bytecode/ArithProfile.h:
(JSC::ArithProfile::observedUnaryInt):
(JSC::ArithProfile::observedUnaryNumber):
(JSC::ArithProfile::observedBinaryIntInt):
(JSC::ArithProfile::observedBinaryNumberInt):
(JSC::ArithProfile::observedBinaryIntNumber):
(JSC::ArithProfile::observedBinaryNumberNumber):
(JSC::ArithProfile::didObserveNonInt32 const):
(JSC::ArithProfile::didObserveNonNumeric const):
(JSC::ArithProfile::didObserveBigInt const):
(JSC::ArithProfile::setObservedNonNumeric):
(JSC::ArithProfile::setObservedBigInt):
(JSC::ArithProfile::observeResult):
(JSC::ArithProfile::didObserveNonNumber const): Deleted.
(JSC::ArithProfile::setObservedNonNumber): Deleted.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::makeSafe):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::mayHaveNonNumericResult):
(JSC::DFG::Node::mayHaveBigIntResult):
(JSC::DFG::Node::mayHaveNonNumberResult): Deleted.
* dfg/DFGNodeFlags.cpp:
(JSC::DFG::dumpNodeFlags):
* dfg/DFGNodeFlags.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueAdd):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
* runtime/CommonSlowPaths.cpp:
(JSC::updateArithProfileForUnaryArithOp):
(JSC::updateArithProfileForBinaryArithOp):
2018-11-07 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Fix "Javascript" => "JavaScript" enum in protocol generated objects
https://bugs.webkit.org/show_bug.cgi?id=191340
Reviewed by Devin Rousso.
* inspector/ConsoleMessage.cpp:
(Inspector::messageSourceValue):
Use new enum name.
* inspector/scripts/codegen/generator.py:
Correct the casing of "JavaScript".
2018-11-07 Tadeu Zagallo <tzagallo@apple.com>
Align wide opcodes in the instruction stream
https://bugs.webkit.org/show_bug.cgi?id=191254
Reviewed by Keith Miller.
Pad the bytecode with nops to ensure that wide opcodes are 4-byte
aligned on platforms that don't like unaligned memory access.
For that, add a new type to represent jump targets, BoundLabel, which
delays computing the offset in case we need to emit nops for padding.
Extra padding is also emitted before op_yield and at the of each
BytecodeWriter fragment, to ensure that the bytecode remains aligned
after the rewriting.
As a side effect, we can longer guarantee that the point immediately
before emitting an opcode is the start of that opcode, since nops
might be emitted in between if the opcode needs to be wide. To fix
that, we only take the offset of opcodes after they have been emitted,
using `m_lastInstruction.offset()`.
* bytecode/BytecodeDumper.h:
(JSC::BytecodeDumper::dumpValue):
* bytecode/BytecodeGeneratorification.cpp:
(JSC::BytecodeGeneratorification::run):
* bytecode/BytecodeList.rb:
* bytecode/BytecodeRewriter.h:
(JSC::BytecodeRewriter::Fragment::align):
(JSC::BytecodeRewriter::insertFragmentBefore):
(JSC::BytecodeRewriter::insertFragmentAfter):
* bytecode/Fits.h:
* bytecode/InstructionStream.h:
(JSC::InstructionStreamWriter::ref):
* bytecode/PreciseJumpTargetsInlines.h:
(JSC::updateStoredJumpTargetsForInstruction):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::Label::setLocation):
(JSC::BoundLabel::target):
(JSC::BoundLabel::saveTarget):
(JSC::BoundLabel::commitTarget):
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::recordOpcode):
(JSC::BytecodeGenerator::alignWideOpcode):
(JSC::BytecodeGenerator::emitProfileControlFlow):
(JSC::BytecodeGenerator::emitResolveScope):
(JSC::BytecodeGenerator::emitGetFromScope):
(JSC::BytecodeGenerator::emitPutToScope):
(JSC::BytecodeGenerator::emitGetById):
(JSC::BytecodeGenerator::emitDirectGetById):
(JSC::BytecodeGenerator::emitPutById):
(JSC::BytecodeGenerator::emitDirectPutById):
(JSC::BytecodeGenerator::emitGetByVal):
(JSC::BytecodeGenerator::emitCreateThis):
(JSC::BytecodeGenerator::beginSwitch):
(JSC::BytecodeGenerator::endSwitch):
(JSC::BytecodeGenerator::emitRequireObjectCoercible):
(JSC::BytecodeGenerator::emitYieldPoint):
(JSC::BytecodeGenerator::emitToThis):
(JSC::Label::bind): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::recordOpcode): Deleted.
* bytecompiler/Label.h:
(JSC::BoundLabel::BoundLabel):
(JSC::BoundLabel::operator int):
(JSC::Label::bind):
* generator/Opcode.rb:
2018-11-07 Tadeu Zagallo <tzagallo@apple.com>
REGRESSION(r237547): Test failures on 32-bit JSC since the JIT was disabled
https://bugs.webkit.org/show_bug.cgi?id=191184
Reviewed by Saam Barati.
Fix API test on CLoop: we can only disable the LLInt when the JIT is enabled.
* API/tests/PingPongStackOverflowTest.cpp:
(testPingPongStackOverflow):
2018-11-06 Justin Fan <justin_fan@apple.com>
[WebGPU] Experimental prototype for WebGPURenderPipeline and WebGPUSwapChain
https://bugs.webkit.org/show_bug.cgi?id=191291
Reviewed by Myles Maxfield.
Properly disable WEBGPU on all non-Metal platforms for now.
* Configurations/FeatureDefines.xcconfig:
2018-11-06 Keith Rollin <krollin@apple.com>
Adjust handling of Include paths that need quoting
https://bugs.webkit.org/show_bug.cgi?id=191314
<rdar://problem/45849143>
Reviewed by Dan Bernstein.
There are several places in the JavaScriptCore Xcode project where the
paths defined in HEADER_SEARCH_PATHS are quoted. That is, the
definitions look like:
HEADER_SEARCH_PATHS = (
"\"${BUILT_PRODUCTS_DIR}/DerivedSources/JavaScriptCore\"",
"\"${BUILT_PRODUCTS_DIR}/LLIntOffsets/${ARCHS}\"",
"\"$(JAVASCRIPTCORE_FRAMEWORKS_DIR)/JavaScriptCore.framework/PrivateHeaders\"",
"$(inherited)",
);
The idea here is presumably to have the resulting $(CPP) command have
-I options where the associated paths are themselves quoted,
protecting against space characters in the paths.
This approach to quote management can break under Xcode 9. If
.xcfilelist files are added to the project, the 'objectVersion' value
in the Xcode project file is changed from 46 to 51. If a project with
objectVersion=51 is presented to Xcode 9 (as can happen when we build
for older OS's), it produces build lines where the quotes are escaped,
thereby becoming part of the path. The build then fails because a
search for a file normally found in a directory called "Foo" will be
looked for in "\"Foo\"", which doesn't exist.
Simply removing the escaped quotes from the HEADER_SEARCH_PATHS
definition doesn't work, leading to paths that need quoting due to
space characters but that don't get this quoting (the part of the path
after the space appears to simply go missing).
Removing the escaped quotes from the HEADER_SEARCH_PATHS and moving
the definitions to the .xcconfig fixes this problem.
* Configurations/ToolExecutable.xcconfig:
* JavaScriptCore.xcodeproj/project.pbxproj:
2018-11-06 Michael Saboff <msaboff@apple.com>
Multiple stress/regexp-compile-oom.js tests are failing on High Sierra Debug and Release JSC testers.
https://bugs.webkit.org/show_bug.cgi?id=191271
Reviewed by Saam Barati.
Fixed use of ThrowScope my adding release() calls. Found a few places where we needed
RETURN_IF_EXCEPTION(). After some code inspections determined that we need to cover the
exception bubbling for String.match() with a global RegExp as well as String.replace()
and String.search().
* runtime/RegExpObjectInlines.h:
(JSC::RegExpObject::matchInline):
(JSC::collectMatches):
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoFuncSearchFast):
* runtime/StringPrototype.cpp:
(JSC::removeUsingRegExpSearch):
(JSC::replaceUsingRegExpSearch):
2018-11-05 Don Olmstead <don.olmstead@sony.com>
Fix typos in closing ENABLE guards
https://bugs.webkit.org/show_bug.cgi?id=191273
Reviewed by Keith Miller.
* ftl/FTLForOSREntryJITCode.h:
* ftl/FTLJITCode.h:
* jsc.cpp:
* wasm/WasmMemoryInformation.h:
* wasm/WasmPageCount.h:
2018-11-05 Keith Miller <keith_miller@apple.com>
Make static_asserts in APICast into bitwise_cast
https://bugs.webkit.org/show_bug.cgi?id=191272
Reviewed by Filip Pizlo.
* API/APICast.h:
(toJS):
(toJSForGC):
(toRef):
2018-11-05 Dominik Infuehr <dinfuehr@igalia.com>
Enable LLInt on ARMv7/Linux
https://bugs.webkit.org/show_bug.cgi?id=191190
Reviewed by Yusuke Suzuki.
After enabling the new bytecode format in r237547, C_LOOP was
forced on all 32-bit platforms. Now enable LLInt again on
ARMv7-Thumb2/Linux.
This adds a callee-saved register in ARMv7/Linux for the metadataTable and
stores/restores it on LLInt function calls. It also introduces the globaladdr-
instruction for the ARM-offlineasm to access the opcode-table.
* jit/GPRInfo.h:
* jit/RegisterSet.cpp:
(JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* offlineasm/arm.rb:
* offlineasm/asm.rb:
* offlineasm/instructions.rb:
2018-11-05 Fujii Hironori <Hironori.Fujii@sony.com>
[Win][Clang][JSC] JIT::is64BitType reports "warning: explicit specialization cannot have a storage class"
https://bugs.webkit.org/show_bug.cgi?id=191146
Reviewed by Yusuke Suzuki.
* jit/JIT.h: Changed is64BitType from a template class method to a
template inner class.
2018-11-02 Keith Miller <keith_miller@apple.com>
Assert JSValues can fit into a pointer when API casting
https://bugs.webkit.org/show_bug.cgi?id=191220
Reviewed by Michael Saboff.
* API/APICast.h:
(toJS):
(toJSForGC):
(toRef):
2018-11-02 Michael Saboff <msaboff@apple.com>
Rolling in r237753 with unreviewed build fix.
Fixed issues with DECLARE_THROW_SCOPE placement.
2018-11-02 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r237753.
Introduced JSC test failures
Reverted changeset:
"Running out of stack space not properly handled in
RegExp::compile() and its callers"
https://bugs.webkit.org/show_bug.cgi?id=191206
https://trac.webkit.org/changeset/237753
2018-11-02 Michael Saboff <msaboff@apple.com>
Running out of stack space not properly handled in RegExp::compile() and its callers
https://bugs.webkit.org/show_bug.cgi?id=191206
Reviewed by Filip Pizlo.
Eliminated two RELEASE_ASSERT_NOT_REACHED() for errors returned by Yarr parsing code. Bubbled those errors
up to where they are turned into the appropriate exceptions in matchInline(). If the errors are not due
to syntax, we reset the RegExp state in case the parsing is tried with a smaller stack.
* runtime/RegExp.cpp:
(JSC::RegExp::compile):
(JSC::RegExp::compileMatchOnly):
* runtime/RegExp.h:
* runtime/RegExpInlines.h:
(JSC::RegExp::compileIfNecessary):
(JSC::RegExp::matchInline):
(JSC::RegExp::compileIfNecessaryMatchOnly):
* runtime/RegExpObjectInlines.h:
(JSC::RegExpObject::execInline):
* yarr/YarrErrorCode.h:
(JSC::Yarr::hasHardError):
2018-11-02 Keith Miller <keith_miller@apple.com>
API should use wrapper object if address is 32-bit
https://bugs.webkit.org/show_bug.cgi?id=191203
Reviewed by Filip Pizlo.
* API/APICast.h:
(toJS):
(toJSForGC):
(toRef):
2018-11-02 Tadeu Zagallo <tzagallo@apple.com>
Metadata should not be copyable
https://bugs.webkit.org/show_bug.cgi?id=191193
Reviewed by Keith Miller.
We should only ever hold references to the entry in the metadata table.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finalizeLLIntInlineCaches):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* generator/Metadata.rb:
2018-11-02 Tadeu Zagallo <tzagallo@apple.com>
REGRESSION(r237547): Exception handlers should be aware of wide opcodes when JIT is disabled
https://bugs.webkit.org/show_bug.cgi?id=191175
Reviewed by Keith Miller.
https://bugs.webkit.org/show_bug.cgi?id=191108 did not handle the case where JIT is not enabled
* jit/JITExceptions.cpp:
(JSC::genericUnwind):
* llint/LLIntData.h:
(JSC::LLInt::getWideCodePtr):
2018-11-01 Fujii Hironori <Hironori.Fujii@sony.com>
Rename <wtf/unicode/UTF8.h> to <wtf/unicode/UTF8Conversion.h> in order to avoid conflicting with ICU's unicode/utf8.h
https://bugs.webkit.org/show_bug.cgi?id=189693
Reviewed by Yusuke Suzuki.
* API/JSClassRef.cpp: Replaced <wtf/unicode/UTF8.h> with <wtf/unicode/UTF8Conversion.h>.
* API/JSStringRef.cpp: Ditto.
* runtime/JSGlobalObjectFunctions.cpp: Ditto.
* wasm/WasmParser.h: Ditto.
2018-11-01 Keith Miller <keith_miller@apple.com>
Unreviewed, JavaScriptCore should only guarantee to produce a
modulemap if we are building for iOSMac.
* Configurations/JavaScriptCore.xcconfig:
2018-10-31 Devin Rousso <drousso@apple.com>
Web Inspector: Canvas: create a setting for auto-recording newly created contexts
https://bugs.webkit.org/show_bug.cgi?id=190856
Reviewed by Brian Burg.
* inspector/protocol/Canvas.json:
Add `setRecordingAutoCaptureFrameCount` command for setting the number of frames to record
immediately after a context is created.
* inspector/protocol/Recording.json:
Add `creation` value for `Initiator` enum.
2018-10-31 Devin Rousso <drousso@apple.com>
Web Inspector: display low-power enter/exit events in Timelines and Network node waterfalls
https://bugs.webkit.org/show_bug.cgi?id=190641
<rdar://problem/45319049>
Reviewed by Joseph Pecoraro.
* inspector/protocol/DOM.json:
Add `videoLowPowerChanged` event that is fired when `InspectorDOMAgent` is able to determine
whether a video element's low power state has changed.
2018-10-31 Tadeu Zagallo <tzagallo@apple.com>
Adjust inlining threshold for new bytecode format
https://bugs.webkit.org/show_bug.cgi?id=191115
Reviewed by Saam Barati.
The new format reduced the number of operands for many opcodes, which
changed inlining decisions and impacted performance negatively.
* runtime/Options.h:
2018-10-31 Tadeu Zagallo <tzagallo@apple.com>
REGRESSION(r237547): Exception handlers should be aware of wide opcodes
https://bugs.webkit.org/show_bug.cgi?id=191108
<rdar://problem/45690700>
Reviewed by Saam Barati.
When linking the handler, we need to check whether the target op_catch is
wide or narrow in order to chose the right code pointer for the handler.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
2018-10-31 Dominik Infuehr <dinfuehr@igalia.com>
Align entries in metadata table
https://bugs.webkit.org/show_bug.cgi?id=191062
Reviewed by Filip Pizlo.
Entries in the metadata table need to be aligned on some 32-bit
architectures.
* bytecode/MetadataTable.h:
(JSC::MetadataTable::forEach):
* bytecode/Opcode.cpp:
(JSC::metadataAlignment):
* bytecode/Opcode.h:
* bytecode/UnlinkedMetadataTableInlines.h:
(JSC::UnlinkedMetadataTable::finalize):
* generator/Section.rb:
2018-10-31 Jim Mason <jmason@ibinx.com>
Static global 'fastHandlerInstalled' conditionally declared in WasmFaultSignalHandler.cpp
https://bugs.webkit.org/show_bug.cgi?id=191063
Reviewed by Yusuke Suzuki.
* wasm/WasmFaultSignalHandler.cpp:
2018-10-30 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC][LLInt] Compact LLInt ASM code by removing unnecessary instructions
https://bugs.webkit.org/show_bug.cgi?id=191092
Reviewed by Saam Barati.
Looking through LLIntAssembly.h, we can find several inefficiencies. This patch fixes the
following things to tighten LLInt ASM code.
1. Remove unnecessary load instructions. Use jmp with BaseIndex directly.
2. Introduce strength reduction for mul instructions in offlineasm layer. This is now critical
since mul instruction is executed in `metadata` operation in LLInt. If the given immediate is
a power of two, we convert it to lshift instruction.
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* offlineasm/arm64.rb:
* offlineasm/instructions.rb:
* offlineasm/x86.rb:
2018-10-30 Don Olmstead <don.olmstead@sony.com>
[PlayStation] Enable JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=191072
Reviewed by Brent Fulgham.
Add platform files for the PlayStation port.
* PlatformPlayStation.cmake: Added.
2018-10-30 Alexey Proskuryakov <ap@apple.com>
Clean up some obsolete MAX_ALLOWED macros
https://bugs.webkit.org/show_bug.cgi?id=190916
Reviewed by Tim Horton.
* API/JSManagedValue.mm:
* API/JSVirtualMachine.mm:
* API/JSWrapperMap.mm:
2018-10-30 Ross Kirsling <ross.kirsling@sony.com>
useProbeOSRExit causes failures for Win64 DFG JIT
https://bugs.webkit.org/show_bug.cgi?id=190656
Reviewed by Keith Miller.
* assembler/ProbeContext.cpp:
(JSC::Probe::executeProbe):
If lowWatermark is expected to equal lowWatermarkFromVisitingDirtyPages *regardless* of the input param,
then let's just call lowWatermarkFromVisitingDirtyPages instead.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::executeOSRExit):
The result of VariableEventStream::reconstruct appears to be inappropriate for direct use as a stack pointer offset;
mimic the non-probe case and use requiredRegisterCountForExit from DFGCommonData instead.
(Also, stop redundantly setting the stack pointer twice in a row.)
2018-10-30 Yusuke Suzuki <yusukesuzuki@slowstart.org>
"Unreviewed, partial rolling in r237254"
https://bugs.webkit.org/show_bug.cgi?id=190340
This only adds Parser.{cpp,h}. And it is not used in this patch.
It examines that the regression is related to exact Parser changes.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseSingleFunction):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
(JSC::parse):
(JSC::parseFunctionForFunctionConstructor):
2018-10-29 Mark Lam <mark.lam@apple.com>
Correctly detect string overflow when using the 'Function' constructor.
https://bugs.webkit.org/show_bug.cgi?id=184883
<rdar://problem/36320331>
Reviewed by Saam Barati.
Added StringBuilder::hasOverflowed() checks, and throwing OutOfMemoryErrors if
we detect an overflow.
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::encode):
(JSC::decode):
* runtime/JSONObject.cpp:
(JSC::Stringifier::stringify):
(JSC::Stringifier::appendStringifiedValue):
2018-10-29 Tadeu Zagallo <tzagallo@apple.com>
Unreviewed, fix JSC on arm64e after r237547
https://bugs.webkit.org/show_bug.cgi?id=187373
Unreviewed.
Remove unused move guarded by POINTER_PROFILING that was trashing the
metadata on arm64e.
* llint/LowLevelInterpreter64.asm:
2018-10-29 Keith Miller <keith_miller@apple.com>
JSC should explicitly list its modulemap file
https://bugs.webkit.org/show_bug.cgi?id=191032
Reviewed by Saam Barati.
The automagically generated module map file for JSC will
include headers where they may not work out of the box.
This patch makes it so we now export the same modulemap
that used to be provided via the legacy system.
* Configurations/JavaScriptCore.xcconfig:
* JavaScriptCore.modulemap: Added.
* JavaScriptCore.xcodeproj/project.pbxproj:
2018-10-29 Tim Horton <timothy_horton@apple.com>
Modernize WebKit nibs and lprojs for localization's sake
https://bugs.webkit.org/show_bug.cgi?id=190911
<rdar://problem/45349466>
Reviewed by Dan Bernstein.
* JavaScriptCore.xcodeproj/project.pbxproj:
English->en
2018-10-29 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r237492.
https://bugs.webkit.org/show_bug.cgi?id=191035
"It regresses JetStream 2 by 5% on some iOS devices"
(Requested by saamyjoon on #webkit).
Reverted changeset:
"Unreviewed, partial rolling in r237254"
https://bugs.webkit.org/show_bug.cgi?id=190340
https://trac.webkit.org/changeset/237492
2018-10-29 Tadeu Zagallo <tzagallo@apple.com>
Add support for GetStack FlushedDouble
https://bugs.webkit.org/show_bug.cgi?id=191012
<rdar://problem/45265141>
Reviewed by Saam Barati.
LowerDFGToB3::compileGetStack assumed that we would not emit GetStack
for doubles, but it turns out it may arise from the PutStack sinking
phase: if we sink a PutStack into a successor block, other predecessors
will emit a GetStack followed by a Upsilon.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetStack):
2018-10-29 Tadeu Zagallo <tzagallo@apple.com>
New bytecode format for JSC
https://bugs.webkit.org/show_bug.cgi?id=187373
<rdar://problem/44186758>
Reviewed by Filip Pizlo.
Replace unlinked and linked bytecode with a new immutable bytecode that does not embed
any addresses. Instructions can be encoded as narrow (1-byte operands) or wide (4-byte
operands) and might contain an extra operand, the metadataID. The metadataID is used to
access the instruction's mutable data in a side table in the CodeBlock (the MetadataTable).
Bytecodes now must be structs declared in the new BytecodeList.rb. All bytecodes give names
and types to all its operands. Additionally, reading a bytecode from the instruction stream
requires decoding the whole bytecode, i.e. it's no longer possible to access arbitrary
operands directly from the stream.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* assembler/MacroAssemblerCodeRef.h:
(JSC::ReturnAddressPtr::ReturnAddressPtr):
(JSC::ReturnAddressPtr::value const):
(JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr):
(JSC::MacroAssemblerCodePtr::createFromExecutableAddress):
* bytecode/ArithProfile.h:
(JSC::ArithProfile::ArithProfile):
* bytecode/ArrayAllocationProfile.h:
(JSC::ArrayAllocationProfile::ArrayAllocationProfile):
* bytecode/ArrayProfile.h:
* bytecode/BytecodeBasicBlock.cpp:
(JSC::isJumpTarget):
(JSC::BytecodeBasicBlock::computeImpl):
(JSC::BytecodeBasicBlock::compute):
* bytecode/BytecodeBasicBlock.h:
(JSC::BytecodeBasicBlock::leaderOffset const):
(JSC::BytecodeBasicBlock::totalLength const):
(JSC::BytecodeBasicBlock::offsets const):
(JSC::BytecodeBasicBlock::BytecodeBasicBlock):
(JSC::BytecodeBasicBlock::addLength):
* bytecode/BytecodeDumper.cpp:
(JSC::BytecodeDumper<Block>::printLocationAndOp):
(JSC::BytecodeDumper<Block>::dumpBytecode):
(JSC::BytecodeDumper<Block>::dumpIdentifiers):
(JSC::BytecodeDumper<Block>::dumpConstants):
(JSC::BytecodeDumper<Block>::dumpExceptionHandlers):
(JSC::BytecodeDumper<Block>::dumpSwitchJumpTables):
(JSC::BytecodeDumper<Block>::dumpStringSwitchJumpTables):
(JSC::BytecodeDumper<Block>::dumpBlock):
* bytecode/BytecodeDumper.h:
(JSC::BytecodeDumper::dumpOperand):
(JSC::BytecodeDumper::dumpValue):
(JSC::BytecodeDumper::BytecodeDumper):
(JSC::BytecodeDumper::block const):
* bytecode/BytecodeGeneratorification.cpp:
(JSC::BytecodeGeneratorification::BytecodeGeneratorification):
(JSC::BytecodeGeneratorification::enterPoint const):
(JSC::BytecodeGeneratorification::instructions const):
(JSC::GeneratorLivenessAnalysis::run):
(JSC::BytecodeGeneratorification::run):
(JSC::performGeneratorification):
* bytecode/BytecodeGeneratorification.h:
* bytecode/BytecodeGraph.h:
(JSC::BytecodeGraph::blockContainsBytecodeOffset):
(JSC::BytecodeGraph::findBasicBlockForBytecodeOffset):
(JSC::BytecodeGraph::findBasicBlockWithLeaderOffset):
(JSC::BytecodeGraph::BytecodeGraph):
* bytecode/BytecodeKills.h:
* bytecode/BytecodeList.json: Removed.
* bytecode/BytecodeList.rb: Added.
* bytecode/BytecodeLivenessAnalysis.cpp:
(JSC::BytecodeLivenessAnalysis::dumpResults):
* bytecode/BytecodeLivenessAnalysis.h:
* bytecode/BytecodeLivenessAnalysisInlines.h:
(JSC::isValidRegisterForLiveness):
(JSC::BytecodeLivenessPropagation::stepOverInstruction):
* bytecode/BytecodeRewriter.cpp:
(JSC::BytecodeRewriter::applyModification):
(JSC::BytecodeRewriter::execute):
(JSC::BytecodeRewriter::adjustJumpTargetsInFragment):
(JSC::BytecodeRewriter::insertImpl):
(JSC::BytecodeRewriter::adjustJumpTarget):
(JSC::BytecodeRewriter::adjustJumpTargets):
* bytecode/BytecodeRewriter.h:
(JSC::BytecodeRewriter::InsertionPoint::InsertionPoint):
(JSC::BytecodeRewriter::Fragment::Fragment):
(JSC::BytecodeRewriter::Fragment::appendInstruction):
(JSC::BytecodeRewriter::BytecodeRewriter):
(JSC::BytecodeRewriter::insertFragmentBefore):
(JSC::BytecodeRewriter::insertFragmentAfter):
(JSC::BytecodeRewriter::removeBytecode):
(JSC::BytecodeRewriter::adjustAbsoluteOffset):
(JSC::BytecodeRewriter::adjustJumpTarget):
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFromLLInt):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::estimatedSize):
(JSC::CodeBlock::visitChildren):
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::finalizeLLIntInlineCaches):
(JSC::CodeBlock::addJITAddIC):
(JSC::CodeBlock::addJITMulIC):
(JSC::CodeBlock::addJITSubIC):
(JSC::CodeBlock::addJITNegIC):
(JSC::CodeBlock::stronglyVisitStrongReferences):
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffset):
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
(JSC::CodeBlock::hasOpDebugForLineAndColumn):
(JSC::CodeBlock::getArrayProfile):
(JSC::CodeBlock::updateAllArrayPredictions):
(JSC::CodeBlock::predictedMachineCodeSize):
(JSC::CodeBlock::tryGetValueProfileForBytecodeOffset):
(JSC::CodeBlock::valueProfilePredictionForBytecodeOffset):
(JSC::CodeBlock::valueProfileForBytecodeOffset):
(JSC::CodeBlock::validate):
(JSC::CodeBlock::outOfLineJumpOffset):
(JSC::CodeBlock::outOfLineJumpTarget):
(JSC::CodeBlock::arithProfileForBytecodeOffset):
(JSC::CodeBlock::arithProfileForPC):
(JSC::CodeBlock::couldTakeSpecialFastCase):
(JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::addMathIC):
(JSC::CodeBlock::outOfLineJumpOffset):
(JSC::CodeBlock::bytecodeOffset):
(JSC::CodeBlock::instructions const):
(JSC::CodeBlock::instructionCount const):
(JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters):
(JSC::CodeBlock::metadata):
(JSC::CodeBlock::metadataSizeInBytes):
(JSC::CodeBlock::numberOfNonArgumentValueProfiles):
(JSC::CodeBlock::totalNumberOfValueProfiles):
* bytecode/CodeBlockInlines.h: Added.
(JSC::CodeBlock::forEachValueProfile):
(JSC::CodeBlock::forEachArrayProfile):
(JSC::CodeBlock::forEachArrayAllocationProfile):
(JSC::CodeBlock::forEachObjectAllocationProfile):
(JSC::CodeBlock::forEachLLIntCallLinkInfo):
* bytecode/Fits.h: Added.
* bytecode/GetByIdMetadata.h: Copied from Source/JavaScriptCore/bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h.
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFromLLInt):
* bytecode/Instruction.h:
(JSC::Instruction::Instruction):
(JSC::Instruction::Impl::opcodeID const):
(JSC::Instruction::opcodeID const):
(JSC::Instruction::name const):
(JSC::Instruction::isWide const):
(JSC::Instruction::size const):
(JSC::Instruction::is const):
(JSC::Instruction::as const):
(JSC::Instruction::cast):
(JSC::Instruction::cast const):
(JSC::Instruction::narrow const):
(JSC::Instruction::wide const):
* bytecode/InstructionStream.cpp: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
(JSC::InstructionStream::InstructionStream):
(JSC::InstructionStream::sizeInBytes const):
* bytecode/InstructionStream.h: Added.
(JSC::InstructionStream::BaseRef::BaseRef):
(JSC::InstructionStream::BaseRef::operator=):
(JSC::InstructionStream::BaseRef::operator-> const):
(JSC::InstructionStream::BaseRef::ptr const):
(JSC::InstructionStream::BaseRef::operator!= const):
(JSC::InstructionStream::BaseRef::next const):
(JSC::InstructionStream::BaseRef::offset const):
(JSC::InstructionStream::BaseRef::isValid const):
(JSC::InstructionStream::BaseRef::unwrap const):
(JSC::InstructionStream::MutableRef::freeze const):
(JSC::InstructionStream::MutableRef::operator->):
(JSC::InstructionStream::MutableRef::ptr):
(JSC::InstructionStream::MutableRef::operator Ref):
(JSC::InstructionStream::MutableRef::unwrap):
(JSC::InstructionStream::iterator::operator*):
(JSC::InstructionStream::iterator::operator++):
(JSC::InstructionStream::begin const):
(JSC::InstructionStream::end const):
(JSC::InstructionStream::at const):
(JSC::InstructionStream::size const):
(JSC::InstructionStreamWriter::InstructionStreamWriter):
(JSC::InstructionStreamWriter::ref):
(JSC::InstructionStreamWriter::seek):
(JSC::InstructionStreamWriter::position):
(JSC::InstructionStreamWriter::write):
(JSC::InstructionStreamWriter::rewind):
(JSC::InstructionStreamWriter::finalize):
(JSC::InstructionStreamWriter::swap):
(JSC::InstructionStreamWriter::iterator::operator*):
(JSC::InstructionStreamWriter::iterator::operator++):
(JSC::InstructionStreamWriter::begin):
(JSC::InstructionStreamWriter::end):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::clearLLIntGetByIdCache):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* bytecode/MetadataTable.cpp: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
(JSC::MetadataTable::MetadataTable):
(JSC::DeallocTable::withOpcodeType):
(JSC::MetadataTable::~MetadataTable):
(JSC::MetadataTable::sizeInBytes):
* bytecode/MetadataTable.h: Copied from Source/JavaScriptCore/runtime/Watchdog.h.
(JSC::MetadataTable::get):
(JSC::MetadataTable::forEach):
(JSC::MetadataTable::getImpl):
* bytecode/Opcode.cpp:
(JSC::metadataSize):
* bytecode/Opcode.h:
(JSC::padOpcodeName):
* bytecode/OpcodeInlines.h:
(JSC::isOpcodeShape):
(JSC::getOpcodeType):
* bytecode/OpcodeSize.h: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
* bytecode/PreciseJumpTargets.cpp:
(JSC::getJumpTargetsForInstruction):
(JSC::computePreciseJumpTargetsInternal):
(JSC::computePreciseJumpTargets):
(JSC::recomputePreciseJumpTargets):
(JSC::findJumpTargetsForInstruction):
* bytecode/PreciseJumpTargets.h:
* bytecode/PreciseJumpTargetsInlines.h:
(JSC::jumpTargetForInstruction):
(JSC::extractStoredJumpTargetsForInstruction):
(JSC::updateStoredJumpTargetsForInstruction):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
* bytecode/SpecialPointer.cpp:
(WTF::printInternal):
* bytecode/SpecialPointer.h:
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
(JSC::UnlinkedCodeBlock::visitChildren):
(JSC::UnlinkedCodeBlock::estimatedSize):
(JSC::UnlinkedCodeBlock::lineNumberForBytecodeOffset):
(JSC::dumpLineColumnEntry):
(JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset const):
(JSC::UnlinkedCodeBlock::setInstructions):
(JSC::UnlinkedCodeBlock::instructions const):
(JSC::UnlinkedCodeBlock::applyModification):
(JSC::UnlinkedCodeBlock::addOutOfLineJumpTarget):
(JSC::UnlinkedCodeBlock::outOfLineJumpOffset):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::addPropertyAccessInstruction):
(JSC::UnlinkedCodeBlock::propertyAccessInstructions const):
(JSC::UnlinkedCodeBlock::addOpProfileControlFlowBytecodeOffset):
(JSC::UnlinkedCodeBlock::opProfileControlFlowBytecodeOffsets const):
(JSC::UnlinkedCodeBlock::metadata):
(JSC::UnlinkedCodeBlock::metadataSizeInBytes):
(JSC::UnlinkedCodeBlock::outOfLineJumpOffset):
(JSC::UnlinkedCodeBlock::replaceOutOfLineJumpTargets):
* bytecode/UnlinkedInstructionStream.cpp: Removed.
* bytecode/UnlinkedInstructionStream.h: Removed.
* bytecode/UnlinkedMetadataTable.h: Copied from Source/JavaScriptCore/bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h.
* bytecode/UnlinkedMetadataTableInlines.h: Added.
(JSC::UnlinkedMetadataTable::UnlinkedMetadataTable):
(JSC::UnlinkedMetadataTable::~UnlinkedMetadataTable):
(JSC::UnlinkedMetadataTable::addEntry):
(JSC::UnlinkedMetadataTable::sizeInBytes):
(JSC::UnlinkedMetadataTable::finalize):
(JSC::UnlinkedMetadataTable::link):
(JSC::UnlinkedMetadataTable::unlink):
* bytecode/VirtualRegister.cpp:
(JSC::VirtualRegister::VirtualRegister):
* bytecode/VirtualRegister.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::Label::setLocation):
(JSC::Label::bind):
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeVarLexicalEnvironment):
(JSC::BytecodeGenerator::emitEnter):
(JSC::BytecodeGenerator::emitLoopHint):
(JSC::BytecodeGenerator::emitJump):
(JSC::BytecodeGenerator::emitCheckTraps):
(JSC::BytecodeGenerator::rewind):
(JSC::BytecodeGenerator::fuseCompareAndJump):
(JSC::BytecodeGenerator::fuseTestAndJmp):
(JSC::BytecodeGenerator::emitJumpIfTrue):
(JSC::BytecodeGenerator::emitJumpIfFalse):
(JSC::BytecodeGenerator::emitJumpIfNotFunctionCall):
(JSC::BytecodeGenerator::emitJumpIfNotFunctionApply):
(JSC::BytecodeGenerator::moveLinkTimeConstant):
(JSC::BytecodeGenerator::moveEmptyValue):
(JSC::BytecodeGenerator::emitMove):
(JSC::BytecodeGenerator::emitUnaryOp):
(JSC::BytecodeGenerator::emitBinaryOp):
(JSC::BytecodeGenerator::emitToObject):
(JSC::BytecodeGenerator::emitToNumber):
(JSC::BytecodeGenerator::emitToString):
(JSC::BytecodeGenerator::emitTypeOf):
(JSC::BytecodeGenerator::emitInc):
(JSC::BytecodeGenerator::emitDec):
(JSC::BytecodeGenerator::emitEqualityOp):
(JSC::BytecodeGenerator::emitProfileType):
(JSC::BytecodeGenerator::emitProfileControlFlow):
(JSC::BytecodeGenerator::pushLexicalScopeInternal):
(JSC::BytecodeGenerator::emitResolveScopeForHoistingFuncDeclInEval):
(JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
(JSC::BytecodeGenerator::emitOverridesHasInstance):
(JSC::BytecodeGenerator::emitResolveScope):
(JSC::BytecodeGenerator::emitGetFromScope):
(JSC::BytecodeGenerator::emitPutToScope):
(JSC::BytecodeGenerator::emitInstanceOf):
(JSC::BytecodeGenerator::emitInstanceOfCustom):
(JSC::BytecodeGenerator::emitInByVal):
(JSC::BytecodeGenerator::emitInById):
(JSC::BytecodeGenerator::emitTryGetById):
(JSC::BytecodeGenerator::emitGetById):
(JSC::BytecodeGenerator::emitDirectGetById):
(JSC::BytecodeGenerator::emitPutById):
(JSC::BytecodeGenerator::emitDirectPutById):
(JSC::BytecodeGenerator::emitPutGetterById):
(JSC::BytecodeGenerator::emitPutSetterById):
(JSC::BytecodeGenerator::emitPutGetterSetter):
(JSC::BytecodeGenerator::emitPutGetterByVal):
(JSC::BytecodeGenerator::emitPutSetterByVal):
(JSC::BytecodeGenerator::emitDeleteById):
(JSC::BytecodeGenerator::emitGetByVal):
(JSC::BytecodeGenerator::emitPutByVal):
(JSC::BytecodeGenerator::emitDirectPutByVal):
(JSC::BytecodeGenerator::emitDeleteByVal):
(JSC::BytecodeGenerator::emitSuperSamplerBegin):
(JSC::BytecodeGenerator::emitSuperSamplerEnd):
(JSC::BytecodeGenerator::emitIdWithProfile):
(JSC::BytecodeGenerator::emitUnreachable):
(JSC::BytecodeGenerator::emitGetArgument):
(JSC::BytecodeGenerator::emitCreateThis):
(JSC::BytecodeGenerator::emitTDZCheck):
(JSC::BytecodeGenerator::emitNewObject):
(JSC::BytecodeGenerator::emitNewArrayBuffer):
(JSC::BytecodeGenerator::emitNewArray):
(JSC::BytecodeGenerator::emitNewArrayWithSpread):
(JSC::BytecodeGenerator::emitNewArrayWithSize):
(JSC::BytecodeGenerator::emitNewRegExp):
(JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
(JSC::BytecodeGenerator::emitNewDefaultConstructor):
(JSC::BytecodeGenerator::emitNewFunction):
(JSC::BytecodeGenerator::emitSetFunctionNameIfNeeded):
(JSC::BytecodeGenerator::emitCall):
(JSC::BytecodeGenerator::emitCallInTailPosition):
(JSC::BytecodeGenerator::emitCallEval):
(JSC::BytecodeGenerator::emitExpectedFunctionSnippet):
(JSC::BytecodeGenerator::emitCallVarargs):
(JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
(JSC::BytecodeGenerator::emitConstructVarargs):
(JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition):
(JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary):
(JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary):
(JSC::BytecodeGenerator::emitCallDefineProperty):
(JSC::BytecodeGenerator::emitReturn):
(JSC::BytecodeGenerator::emitEnd):
(JSC::BytecodeGenerator::emitConstruct):
(JSC::BytecodeGenerator::emitStrcat):
(JSC::BytecodeGenerator::emitToPrimitive):
(JSC::BytecodeGenerator::emitGetScope):
(JSC::BytecodeGenerator::emitPushWithScope):
(JSC::BytecodeGenerator::emitGetParentScope):
(JSC::BytecodeGenerator::emitDebugHook):
(JSC::BytecodeGenerator::emitCatch):
(JSC::BytecodeGenerator::emitThrow):
(JSC::BytecodeGenerator::emitArgumentCount):
(JSC::BytecodeGenerator::emitThrowStaticError):
(JSC::BytecodeGenerator::beginSwitch):
(JSC::prepareJumpTableForSwitch):
(JSC::prepareJumpTableForStringSwitch):
(JSC::BytecodeGenerator::endSwitch):
(JSC::BytecodeGenerator::emitGetEnumerableLength):
(JSC::BytecodeGenerator::emitHasGenericProperty):
(JSC::BytecodeGenerator::emitHasIndexedProperty):
(JSC::BytecodeGenerator::emitHasStructureProperty):
(JSC::BytecodeGenerator::emitGetPropertyEnumerator):
(JSC::BytecodeGenerator::emitEnumeratorStructurePropertyName):
(JSC::BytecodeGenerator::emitEnumeratorGenericPropertyName):
(JSC::BytecodeGenerator::emitToIndexString):
(JSC::BytecodeGenerator::emitIsCellWithType):
(JSC::BytecodeGenerator::emitIsObject):
(JSC::BytecodeGenerator::emitIsNumber):
(JSC::BytecodeGenerator::emitIsUndefined):
(JSC::BytecodeGenerator::emitIsEmpty):
(JSC::BytecodeGenerator::emitRestParameter):
(JSC::BytecodeGenerator::emitRequireObjectCoercible):
(JSC::BytecodeGenerator::emitYieldPoint):
(JSC::BytecodeGenerator::emitYield):
(JSC::BytecodeGenerator::emitGetAsyncIterator):
(JSC::BytecodeGenerator::emitDelegateYield):
(JSC::BytecodeGenerator::emitFinallyCompletion):
(JSC::BytecodeGenerator::emitJumpIf):
(JSC::ForInContext::finalize):
(JSC::StructureForInContext::finalize):
(JSC::IndexedForInContext::finalize):
(JSC::StaticPropertyAnalysis::record):
(JSC::BytecodeGenerator::emitToThis):
* bytecompiler/BytecodeGenerator.h:
(JSC::StructureForInContext::addGetInst):
(JSC::BytecodeGenerator::recordOpcode):
(JSC::BytecodeGenerator::addMetadataFor):
(JSC::BytecodeGenerator::emitUnaryOp):
(JSC::BytecodeGenerator::kill):
(JSC::BytecodeGenerator::instructions const):
(JSC::BytecodeGenerator::write):
(JSC::BytecodeGenerator::withWriter):
* bytecompiler/Label.h:
(JSC::Label::Label):
(JSC::Label::bind):
* bytecompiler/NodesCodegen.cpp:
(JSC::ArrayNode::emitBytecode):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_argumentCount):
(JSC::ApplyFunctionCallDotNode::emitBytecode):
(JSC::BitwiseNotNode::emitBytecode):
(JSC::BinaryOpNode::emitBytecode):
(JSC::EqualNode::emitBytecode):
(JSC::StrictEqualNode::emitBytecode):
(JSC::emitReadModifyAssignment):
(JSC::ForInNode::emitBytecode):
(JSC::CaseBlockNode::emitBytecodeForBlock):
(JSC::FunctionNode::emitBytecode):
(JSC::ClassExprNode::emitBytecode):
* bytecompiler/ProfileTypeBytecodeFlag.cpp: Copied from Source/JavaScriptCore/bytecode/VirtualRegister.cpp.
(WTF::printInternal):
* bytecompiler/ProfileTypeBytecodeFlag.h: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
* bytecompiler/RegisterID.h:
* bytecompiler/StaticPropertyAnalysis.h:
(JSC::StaticPropertyAnalysis::create):
(JSC::StaticPropertyAnalysis::StaticPropertyAnalysis):
* bytecompiler/StaticPropertyAnalyzer.h:
(JSC::StaticPropertyAnalyzer::createThis):
(JSC::StaticPropertyAnalyzer::newObject):
(JSC::StaticPropertyAnalyzer::putById):
(JSC::StaticPropertyAnalyzer::mov):
(JSC::StaticPropertyAnalyzer::kill):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addCall):
(JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
(JSC::DFG::ByteCodeParser::getArrayMode):
(JSC::DFG::ByteCodeParser::handleCall):
(JSC::DFG::ByteCodeParser::handleVarargsCall):
(JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
(JSC::DFG::ByteCodeParser::inlineCall):
(JSC::DFG::ByteCodeParser::handleCallVariant):
(JSC::DFG::ByteCodeParser::handleVarargsInlining):
(JSC::DFG::ByteCodeParser::handleInlining):
(JSC::DFG::ByteCodeParser::handleMinMax):
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
(JSC::DFG::ByteCodeParser::handleDOMJITCall):
(JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
(JSC::DFG::ByteCodeParser::handleDOMJITGetter):
(JSC::DFG::ByteCodeParser::handleModuleNamespaceLoad):
(JSC::DFG::ByteCodeParser::handleTypedArrayConstructor):
(JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::handlePutById):
(JSC::DFG::ByteCodeParser::parseGetById):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::parseCodeBlock):
(JSC::DFG::ByteCodeParser::handlePutByVal):
(JSC::DFG::ByteCodeParser::handlePutAccessorById):
(JSC::DFG::ByteCodeParser::handlePutAccessorByVal):
(JSC::DFG::ByteCodeParser::handleNewFunc):
(JSC::DFG::ByteCodeParser::handleNewFuncExp):
(JSC::DFG::ByteCodeParser::parse):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGCapabilities.h:
(JSC::DFG::capabilityLevel):
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareCatchOSREntry):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueAdd):
(JSC::DFG::SpeculativeJIT::compileValueSub):
(JSC::DFG::SpeculativeJIT::compileValueNegate):
(JSC::DFG::SpeculativeJIT::compileArithMul):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
(JSC::FTL::DFG::LowerDFGToB3::compileValueSub):
(JSC::FTL::DFG::LowerDFGToB3::compileUnaryMathIC):
(JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC):
(JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
(JSC::FTL::DFG::LowerDFGToB3::compileArithMul):
(JSC::FTL::DFG::LowerDFGToB3::compileValueNegate):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
* generate-bytecode-files: Removed.
* generator/Argument.rb: Added.
* generator/Assertion.rb: Added.
* generator/DSL.rb: Added.
* generator/Fits.rb: Added.
* generator/GeneratedFile.rb: Added.
* generator/Metadata.rb: Added.
* generator/Opcode.rb: Added.
* generator/OpcodeGroup.rb: Added.
* generator/Options.rb: Added.
* generator/Section.rb: Added.
* generator/Template.rb: Added.
* generator/Type.rb: Added.
* generator/main.rb: Added.
* interpreter/AbstractPC.h:
* interpreter/CallFrame.cpp:
(JSC::CallFrame::currentVPC const):
(JSC::CallFrame::setCurrentVPC):
* interpreter/CallFrame.h:
(JSC::CallSiteIndex::CallSiteIndex):
(JSC::ExecState::setReturnPC):
* interpreter/Interpreter.cpp:
(WTF::printInternal):
* interpreter/Interpreter.h:
* interpreter/InterpreterInlines.h:
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::dump const):
* interpreter/VMEntryRecord.h:
* jit/JIT.cpp:
(JSC::JIT::JIT):
(JSC::JIT::emitSlowCaseCall):
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
(JSC::JIT::compileWithoutLinking):
(JSC::JIT::link):
* jit/JIT.h:
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_jless):
(JSC::JIT::emit_op_jlesseq):
(JSC::JIT::emit_op_jgreater):
(JSC::JIT::emit_op_jgreatereq):
(JSC::JIT::emit_op_jnless):
(JSC::JIT::emit_op_jnlesseq):
(JSC::JIT::emit_op_jngreater):
(JSC::JIT::emit_op_jngreatereq):
(JSC::JIT::emitSlow_op_jless):
(JSC::JIT::emitSlow_op_jlesseq):
(JSC::JIT::emitSlow_op_jgreater):
(JSC::JIT::emitSlow_op_jgreatereq):
(JSC::JIT::emitSlow_op_jnless):
(JSC::JIT::emitSlow_op_jnlesseq):
(JSC::JIT::emitSlow_op_jngreater):
(JSC::JIT::emitSlow_op_jngreatereq):
(JSC::JIT::emit_op_below):
(JSC::JIT::emit_op_beloweq):
(JSC::JIT::emit_op_jbelow):
(JSC::JIT::emit_op_jbeloweq):
(JSC::JIT::emit_op_unsigned):
(JSC::JIT::emit_compareAndJump):
(JSC::JIT::emit_compareUnsignedAndJump):
(JSC::JIT::emit_compareUnsigned):
(JSC::JIT::emit_compareAndJumpSlow):
(JSC::JIT::emit_op_inc):
(JSC::JIT::emit_op_dec):
(JSC::JIT::emit_op_mod):
(JSC::JIT::emitSlow_op_mod):
(JSC::JIT::emit_op_negate):
(JSC::JIT::emitSlow_op_negate):
(JSC::JIT::emitBitBinaryOpFastPath):
(JSC::JIT::emit_op_bitand):
(JSC::JIT::emit_op_bitor):
(JSC::JIT::emit_op_bitxor):
(JSC::JIT::emit_op_lshift):
(JSC::JIT::emitRightShiftFastPath):
(JSC::JIT::emit_op_rshift):
(JSC::JIT::emit_op_urshift):
(JSC::getOperandTypes):
(JSC::JIT::emit_op_add):
(JSC::JIT::emitSlow_op_add):
(JSC::JIT::emitMathICFast):
(JSC::JIT::emitMathICSlow):
(JSC::JIT::emit_op_div):
(JSC::JIT::emit_op_mul):
(JSC::JIT::emitSlow_op_mul):
(JSC::JIT::emit_op_sub):
(JSC::JIT::emitSlow_op_sub):
* jit/JITCall.cpp:
(JSC::JIT::emitPutCallResult):
(JSC::JIT::compileSetupFrame):
(JSC::JIT::compileCallEval):
(JSC::JIT::compileCallEvalSlowCase):
(JSC::JIT::compileTailCall):
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
(JSC::JIT::emit_op_call):
(JSC::JIT::emit_op_tail_call):
(JSC::JIT::emit_op_call_eval):
(JSC::JIT::emit_op_call_varargs):
(JSC::JIT::emit_op_tail_call_varargs):
(JSC::JIT::emit_op_tail_call_forward_arguments):
(JSC::JIT::emit_op_construct_varargs):
(JSC::JIT::emit_op_construct):
(JSC::JIT::emitSlow_op_call):
(JSC::JIT::emitSlow_op_tail_call):
(JSC::JIT::emitSlow_op_call_eval):
(JSC::JIT::emitSlow_op_call_varargs):
(JSC::JIT::emitSlow_op_tail_call_varargs):
(JSC::JIT::emitSlow_op_tail_call_forward_arguments):
(JSC::JIT::emitSlow_op_construct_varargs):
(JSC::JIT::emitSlow_op_construct):
* jit/JITDisassembler.cpp:
(JSC::JITDisassembler::JITDisassembler):
* jit/JITExceptions.cpp:
(JSC::genericUnwind):
* jit/JITInlines.h:
(JSC::JIT::emitDoubleGetByVal):
(JSC::JIT::emitLoadForArrayMode):
(JSC::JIT::emitContiguousGetByVal):
(JSC::JIT::emitArrayStorageGetByVal):
(JSC::JIT::appendCallWithExceptionCheckSetJSValueResultWithProfile):
(JSC::JIT::sampleInstruction):
(JSC::JIT::emitValueProfilingSiteIfProfiledOpcode):
(JSC::JIT::emitValueProfilingSite):
(JSC::JIT::jumpTarget):
(JSC::JIT::copiedGetPutInfo):
(JSC::JIT::copiedArithProfile):
* jit/JITMathIC.h:
(JSC::isProfileEmpty):
(JSC::JITBinaryMathIC::JITBinaryMathIC):
(JSC::JITUnaryMathIC::JITUnaryMathIC):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_mov):
(JSC::JIT::emit_op_end):
(JSC::JIT::emit_op_jmp):
(JSC::JIT::emit_op_new_object):
(JSC::JIT::emitSlow_op_new_object):
(JSC::JIT::emit_op_overrides_has_instance):
(JSC::JIT::emit_op_instanceof):
(JSC::JIT::emitSlow_op_instanceof):
(JSC::JIT::emit_op_instanceof_custom):
(JSC::JIT::emit_op_is_empty):
(JSC::JIT::emit_op_is_undefined):
(JSC::JIT::emit_op_is_boolean):
(JSC::JIT::emit_op_is_number):
(JSC::JIT::emit_op_is_cell_with_type):
(JSC::JIT::emit_op_is_object):
(JSC::JIT::emit_op_ret):
(JSC::JIT::emit_op_to_primitive):
(JSC::JIT::emit_op_set_function_name):
(JSC::JIT::emit_op_not):
(JSC::JIT::emit_op_jfalse):
(JSC::JIT::emit_op_jeq_null):
(JSC::JIT::emit_op_jneq_null):
(JSC::JIT::emit_op_jneq_ptr):
(JSC::JIT::emit_op_eq):
(JSC::JIT::emit_op_jeq):
(JSC::JIT::emit_op_jtrue):
(JSC::JIT::emit_op_neq):
(JSC::JIT::emit_op_jneq):
(JSC::JIT::emit_op_throw):
(JSC::JIT::compileOpStrictEq):
(JSC::JIT::emit_op_stricteq):
(JSC::JIT::emit_op_nstricteq):
(JSC::JIT::compileOpStrictEqJump):
(JSC::JIT::emit_op_jstricteq):
(JSC::JIT::emit_op_jnstricteq):
(JSC::JIT::emitSlow_op_jstricteq):
(JSC::JIT::emitSlow_op_jnstricteq):
(JSC::JIT::emit_op_to_number):
(JSC::JIT::emit_op_to_string):
(JSC::JIT::emit_op_to_object):
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_identity_with_profile):
(JSC::JIT::emit_op_get_parent_scope):
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emit_op_switch_char):
(JSC::JIT::emit_op_switch_string):
(JSC::JIT::emit_op_debug):
(JSC::JIT::emit_op_eq_null):
(JSC::JIT::emit_op_neq_null):
(JSC::JIT::emit_op_enter):
(JSC::JIT::emit_op_get_scope):
(JSC::JIT::emit_op_to_this):
(JSC::JIT::emit_op_create_this):
(JSC::JIT::emit_op_check_tdz):
(JSC::JIT::emitSlow_op_eq):
(JSC::JIT::emitSlow_op_neq):
(JSC::JIT::emitSlow_op_jeq):
(JSC::JIT::emitSlow_op_jneq):
(JSC::JIT::emitSlow_op_instanceof_custom):
(JSC::JIT::emit_op_loop_hint):
(JSC::JIT::emitSlow_op_loop_hint):
(JSC::JIT::emit_op_check_traps):
(JSC::JIT::emit_op_nop):
(JSC::JIT::emit_op_super_sampler_begin):
(JSC::JIT::emit_op_super_sampler_end):
(JSC::JIT::emitSlow_op_check_traps):
(JSC::JIT::emit_op_new_regexp):
(JSC::JIT::emitNewFuncCommon):
(JSC::JIT::emit_op_new_func):
(JSC::JIT::emit_op_new_generator_func):
(JSC::JIT::emit_op_new_async_generator_func):
(JSC::JIT::emit_op_new_async_func):
(JSC::JIT::emitNewFuncExprCommon):
(JSC::JIT::emit_op_new_func_exp):
(JSC::JIT::emit_op_new_generator_func_exp):
(JSC::JIT::emit_op_new_async_func_exp):
(JSC::JIT::emit_op_new_async_generator_func_exp):
(JSC::JIT::emit_op_new_array):
(JSC::JIT::emit_op_new_array_with_size):
(JSC::JIT::emit_op_has_structure_property):
(JSC::JIT::privateCompileHasIndexedProperty):
(JSC::JIT::emit_op_has_indexed_property):
(JSC::JIT::emitSlow_op_has_indexed_property):
(JSC::JIT::emit_op_get_direct_pname):
(JSC::JIT::emit_op_enumerator_structure_pname):
(JSC::JIT::emit_op_enumerator_generic_pname):
(JSC::JIT::emit_op_profile_type):
(JSC::JIT::emit_op_log_shadow_chicken_prologue):
(JSC::JIT::emit_op_log_shadow_chicken_tail):
(JSC::JIT::emit_op_profile_control_flow):
(JSC::JIT::emit_op_argument_count):
(JSC::JIT::emit_op_get_rest_length):
(JSC::JIT::emit_op_get_argument):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_to_this):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emitGetByValWithCachedId):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emit_op_put_by_val_direct):
(JSC::JIT::emit_op_put_by_val):
(JSC::JIT::emitGenericContiguousPutByVal):
(JSC::JIT::emitArrayStoragePutByVal):
(JSC::JIT::emitPutByValWithCachedId):
(JSC::JIT::emitSlow_op_put_by_val):
(JSC::JIT::emit_op_put_getter_by_id):
(JSC::JIT::emit_op_put_setter_by_id):
(JSC::JIT::emit_op_put_getter_setter_by_id):
(JSC::JIT::emit_op_put_getter_by_val):
(JSC::JIT::emit_op_put_setter_by_val):
(JSC::JIT::emit_op_del_by_id):
(JSC::JIT::emit_op_del_by_val):
(JSC::JIT::emit_op_try_get_by_id):
(JSC::JIT::emitSlow_op_try_get_by_id):
(JSC::JIT::emit_op_get_by_id_direct):
(JSC::JIT::emitSlow_op_get_by_id_direct):
(JSC::JIT::emit_op_get_by_id):
(JSC::JIT::emit_op_get_by_id_with_this):
(JSC::JIT::emitSlow_op_get_by_id):
(JSC::JIT::emitSlow_op_get_by_id_with_this):
(JSC::JIT::emit_op_put_by_id):
(JSC::JIT::emitSlow_op_put_by_id):
(JSC::JIT::emit_op_in_by_id):
(JSC::JIT::emitSlow_op_in_by_id):
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emitSlow_op_get_from_scope):
(JSC::JIT::emit_op_put_to_scope):
(JSC::JIT::emitSlow_op_put_to_scope):
(JSC::JIT::emit_op_get_from_arguments):
(JSC::JIT::emit_op_put_to_arguments):
(JSC::JIT::privateCompileGetByVal):
(JSC::JIT::privateCompileGetByValWithCachedId):
(JSC::JIT::privateCompilePutByVal):
(JSC::JIT::privateCompilePutByValWithCachedId):
(JSC::JIT::emitDoubleLoad):
(JSC::JIT::emitContiguousLoad):
(JSC::JIT::emitArrayStorageLoad):
(JSC::JIT::emitDirectArgumentsGetByVal):
(JSC::JIT::emitScopedArgumentsGetByVal):
(JSC::JIT::emitIntTypedArrayGetByVal):
(JSC::JIT::emitFloatTypedArrayGetByVal):
(JSC::JIT::emitIntTypedArrayPutByVal):
(JSC::JIT::emitFloatTypedArrayPutByVal):
* jit/RegisterSet.cpp:
(JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
* jit/SlowPathCall.h:
(JSC::JITSlowPathCall::JITSlowPathCall):
* llint/LLIntData.cpp:
(JSC::LLInt::initialize):
(JSC::LLInt::Data::performAssertions):
* llint/LLIntData.h:
(JSC::LLInt::exceptionInstructions):
(JSC::LLInt::opcodeMap):
(JSC::LLInt::opcodeMapWide):
(JSC::LLInt::getOpcode):
(JSC::LLInt::getOpcodeWide):
(JSC::LLInt::getWideCodePtr):
* llint/LLIntOffsetsExtractor.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::llint_trace_operand):
(JSC::LLInt::llint_trace_value):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::entryOSR):
(JSC::LLInt::setupGetByIdPrototypeCache):
(JSC::LLInt::getByVal):
(JSC::LLInt::handleHostCall):
(JSC::LLInt::setUpCall):
(JSC::LLInt::genericCall):
(JSC::LLInt::varargsSetup):
(JSC::LLInt::commonCallEval):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter.cpp:
(JSC::CLoopRegister::operator const Instruction*):
(JSC::CLoop::execute):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* offlineasm/arm64.rb:
* offlineasm/asm.rb:
* offlineasm/ast.rb:
* offlineasm/cloop.rb:
* offlineasm/generate_offset_extractor.rb:
* offlineasm/instructions.rb:
* offlineasm/offsets.rb:
* offlineasm/parser.rb:
* offlineasm/transform.rb:
* offlineasm/x86.rb:
* parser/ResultType.h:
(JSC::ResultType::dump const):
(JSC::OperandTypes::first const):
(JSC::OperandTypes::second const):
(JSC::OperandTypes::dump const):
* profiler/ProfilerBytecodeSequence.cpp:
(JSC::Profiler::BytecodeSequence::BytecodeSequence):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
(JSC::updateArithProfileForUnaryArithOp):
(JSC::updateArithProfileForBinaryArithOp):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
(JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
* runtime/ExceptionFuzz.cpp:
(JSC::doExceptionFuzzing):
* runtime/ExceptionFuzz.h:
(JSC::doExceptionFuzzingIfEnabled):
* runtime/GetPutInfo.cpp: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
(JSC::GetPutInfo::dump const):
(WTF::printInternal):
* runtime/GetPutInfo.h:
(JSC::GetPutInfo::operand const):
* runtime/JSCPoison.h:
* runtime/JSType.cpp: Added.
(WTF::printInternal):
* runtime/JSType.h:
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::StackFrame::displayName):
* runtime/SamplingProfiler.h:
(JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame):
* runtime/SlowPathReturnType.h:
(JSC::encodeResult):
(JSC::decodeResult):
* runtime/VM.h:
* runtime/Watchdog.h:
* tools/HeapVerifier.cpp:
2018-10-27 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Unreviewed, partial rolling in r237254
https://bugs.webkit.org/show_bug.cgi?id=190340
We do not use the added function right now to investigate what is the reason of the regression.
It also does not include any Parser.{h,cpp} changes to ensure that Parser.cpp's inlining decision
seems culprit of the regression on iOS devices.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
* bytecode/UnlinkedFunctionExecutable.h:
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::SourceCodeKey):
(JSC::SourceCodeKey::operator== const):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
* runtime/CodeCache.h:
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/FunctionExecutable.h:
2018-10-26 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r237479 and r237484.
https://bugs.webkit.org/show_bug.cgi?id=190978
broke JSC on iOS (Requested by tadeuzagallo on #webkit).
Reverted changesets:
"New bytecode format for JSC"
https://bugs.webkit.org/show_bug.cgi?id=187373
https://trac.webkit.org/changeset/237479
"Gardening: Build fix after r237479."
https://bugs.webkit.org/show_bug.cgi?id=187373
https://trac.webkit.org/changeset/237484
2018-10-26 Tadeu Zagallo <tzagallo@apple.com>
Gardening: Build fix after r237479.
https://bugs.webkit.org/show_bug.cgi?id=187373
Unreviewed.
* Configurations/JSC.xcconfig:
* JavaScriptCore.xcodeproj/project.pbxproj:
* llint/LLIntData.cpp:
(JSC::LLInt::initialize):
2018-10-26 Tadeu Zagallo <tzagallo@apple.com>
New bytecode format for JSC
https://bugs.webkit.org/show_bug.cgi?id=187373
<rdar://problem/44186758>
Reviewed by Filip Pizlo.
Replace unlinked and linked bytecode with a new immutable bytecode that does not embed
any addresses. Instructions can be encoded as narrow (1-byte operands) or wide (4-byte
operands) and might contain an extra operand, the metadataID. The metadataID is used to
access the instruction's mutable data in a side table in the CodeBlock (the MetadataTable).
Bytecodes now must be structs declared in the new BytecodeList.rb. All bytecodes give names
and types to all its operands. Additionally, reading a bytecode from the instruction stream
requires decoding the whole bytecode, i.e. it's no longer possible to access arbitrary
operands directly from the stream.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* assembler/MacroAssemblerCodeRef.h:
(JSC::ReturnAddressPtr::ReturnAddressPtr):
(JSC::ReturnAddressPtr::value const):
(JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr):
(JSC::MacroAssemblerCodePtr::createFromExecutableAddress):
* bytecode/ArithProfile.h:
(JSC::ArithProfile::ArithProfile):
* bytecode/ArrayAllocationProfile.h:
(JSC::ArrayAllocationProfile::ArrayAllocationProfile):
* bytecode/ArrayProfile.h:
* bytecode/BytecodeBasicBlock.cpp:
(JSC::isJumpTarget):
(JSC::BytecodeBasicBlock::computeImpl):
(JSC::BytecodeBasicBlock::compute):
* bytecode/BytecodeBasicBlock.h:
(JSC::BytecodeBasicBlock::leaderOffset const):
(JSC::BytecodeBasicBlock::totalLength const):
(JSC::BytecodeBasicBlock::offsets const):
(JSC::BytecodeBasicBlock::BytecodeBasicBlock):
(JSC::BytecodeBasicBlock::addLength):
* bytecode/BytecodeDumper.cpp:
(JSC::BytecodeDumper<Block>::printLocationAndOp):
(JSC::BytecodeDumper<Block>::dumpBytecode):
(JSC::BytecodeDumper<Block>::dumpIdentifiers):
(JSC::BytecodeDumper<Block>::dumpConstants):
(JSC::BytecodeDumper<Block>::dumpExceptionHandlers):
(JSC::BytecodeDumper<Block>::dumpSwitchJumpTables):
(JSC::BytecodeDumper<Block>::dumpStringSwitchJumpTables):
(JSC::BytecodeDumper<Block>::dumpBlock):
* bytecode/BytecodeDumper.h:
(JSC::BytecodeDumper::dumpOperand):
(JSC::BytecodeDumper::dumpValue):
(JSC::BytecodeDumper::BytecodeDumper):
(JSC::BytecodeDumper::block const):
* bytecode/BytecodeGeneratorification.cpp:
(JSC::BytecodeGeneratorification::BytecodeGeneratorification):
(JSC::BytecodeGeneratorification::enterPoint const):
(JSC::BytecodeGeneratorification::instructions const):
(JSC::GeneratorLivenessAnalysis::run):
(JSC::BytecodeGeneratorification::run):
(JSC::performGeneratorification):
* bytecode/BytecodeGeneratorification.h:
* bytecode/BytecodeGraph.h:
(JSC::BytecodeGraph::blockContainsBytecodeOffset):
(JSC::BytecodeGraph::findBasicBlockForBytecodeOffset):
(JSC::BytecodeGraph::findBasicBlockWithLeaderOffset):
(JSC::BytecodeGraph::BytecodeGraph):
* bytecode/BytecodeKills.h:
* bytecode/BytecodeList.json: Removed.
* bytecode/BytecodeList.rb: Added.
* bytecode/BytecodeLivenessAnalysis.cpp:
(JSC::BytecodeLivenessAnalysis::dumpResults):
* bytecode/BytecodeLivenessAnalysis.h:
* bytecode/BytecodeLivenessAnalysisInlines.h:
(JSC::isValidRegisterForLiveness):
(JSC::BytecodeLivenessPropagation::stepOverInstruction):
* bytecode/BytecodeRewriter.cpp:
(JSC::BytecodeRewriter::applyModification):
(JSC::BytecodeRewriter::execute):
(JSC::BytecodeRewriter::adjustJumpTargetsInFragment):
(JSC::BytecodeRewriter::insertImpl):
(JSC::BytecodeRewriter::adjustJumpTarget):
(JSC::BytecodeRewriter::adjustJumpTargets):
* bytecode/BytecodeRewriter.h:
(JSC::BytecodeRewriter::InsertionPoint::InsertionPoint):
(JSC::BytecodeRewriter::Fragment::Fragment):
(JSC::BytecodeRewriter::Fragment::appendInstruction):
(JSC::BytecodeRewriter::BytecodeRewriter):
(JSC::BytecodeRewriter::insertFragmentBefore):
(JSC::BytecodeRewriter::insertFragmentAfter):
(JSC::BytecodeRewriter::removeBytecode):
(JSC::BytecodeRewriter::adjustAbsoluteOffset):
(JSC::BytecodeRewriter::adjustJumpTarget):
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFromLLInt):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::estimatedSize):
(JSC::CodeBlock::visitChildren):
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::finalizeLLIntInlineCaches):
(JSC::CodeBlock::addJITAddIC):
(JSC::CodeBlock::addJITMulIC):
(JSC::CodeBlock::addJITSubIC):
(JSC::CodeBlock::addJITNegIC):
(JSC::CodeBlock::stronglyVisitStrongReferences):
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffset):
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
(JSC::CodeBlock::hasOpDebugForLineAndColumn):
(JSC::CodeBlock::getArrayProfile):
(JSC::CodeBlock::updateAllArrayPredictions):
(JSC::CodeBlock::predictedMachineCodeSize):
(JSC::CodeBlock::tryGetValueProfileForBytecodeOffset):
(JSC::CodeBlock::valueProfilePredictionForBytecodeOffset):
(JSC::CodeBlock::valueProfileForBytecodeOffset):
(JSC::CodeBlock::validate):
(JSC::CodeBlock::outOfLineJumpOffset):
(JSC::CodeBlock::outOfLineJumpTarget):
(JSC::CodeBlock::arithProfileForBytecodeOffset):
(JSC::CodeBlock::arithProfileForPC):
(JSC::CodeBlock::couldTakeSpecialFastCase):
(JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::addMathIC):
(JSC::CodeBlock::outOfLineJumpOffset):
(JSC::CodeBlock::bytecodeOffset):
(JSC::CodeBlock::instructions const):
(JSC::CodeBlock::instructionCount const):
(JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters):
(JSC::CodeBlock::metadata):
(JSC::CodeBlock::metadataSizeInBytes):
(JSC::CodeBlock::numberOfNonArgumentValueProfiles):
(JSC::CodeBlock::totalNumberOfValueProfiles):
* bytecode/CodeBlockInlines.h: Added.
(JSC::CodeBlock::forEachValueProfile):
(JSC::CodeBlock::forEachArrayProfile):
(JSC::CodeBlock::forEachArrayAllocationProfile):
(JSC::CodeBlock::forEachObjectAllocationProfile):
(JSC::CodeBlock::forEachLLIntCallLinkInfo):
* bytecode/Fits.h: Added.
* bytecode/GetByIdMetadata.h: Copied from Source/JavaScriptCore/bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h.
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFromLLInt):
* bytecode/Instruction.h:
(JSC::Instruction::Instruction):
(JSC::Instruction::Impl::opcodeID const):
(JSC::Instruction::opcodeID const):
(JSC::Instruction::name const):
(JSC::Instruction::isWide const):
(JSC::Instruction::size const):
(JSC::Instruction::is const):
(JSC::Instruction::as const):
(JSC::Instruction::cast):
(JSC::Instruction::cast const):
(JSC::Instruction::narrow const):
(JSC::Instruction::wide const):
* bytecode/InstructionStream.cpp: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
(JSC::InstructionStream::InstructionStream):
(JSC::InstructionStream::sizeInBytes const):
* bytecode/InstructionStream.h: Added.
(JSC::InstructionStream::BaseRef::BaseRef):
(JSC::InstructionStream::BaseRef::operator=):
(JSC::InstructionStream::BaseRef::operator-> const):
(JSC::InstructionStream::BaseRef::ptr const):
(JSC::InstructionStream::BaseRef::operator!= const):
(JSC::InstructionStream::BaseRef::next const):
(JSC::InstructionStream::BaseRef::offset const):
(JSC::InstructionStream::BaseRef::isValid const):
(JSC::InstructionStream::BaseRef::unwrap const):
(JSC::InstructionStream::MutableRef::freeze const):
(JSC::InstructionStream::MutableRef::operator->):
(JSC::InstructionStream::MutableRef::ptr):
(JSC::InstructionStream::MutableRef::operator Ref):
(JSC::InstructionStream::MutableRef::unwrap):
(JSC::InstructionStream::iterator::operator*):
(JSC::InstructionStream::iterator::operator++):
(JSC::InstructionStream::begin const):
(JSC::InstructionStream::end const):
(JSC::InstructionStream::at const):
(JSC::InstructionStream::size const):
(JSC::InstructionStreamWriter::InstructionStreamWriter):
(JSC::InstructionStreamWriter::ref):
(JSC::InstructionStreamWriter::seek):
(JSC::InstructionStreamWriter::position):
(JSC::InstructionStreamWriter::write):
(JSC::InstructionStreamWriter::rewind):
(JSC::InstructionStreamWriter::finalize):
(JSC::InstructionStreamWriter::swap):
(JSC::InstructionStreamWriter::iterator::operator*):
(JSC::InstructionStreamWriter::iterator::operator++):
(JSC::InstructionStreamWriter::begin):
(JSC::InstructionStreamWriter::end):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::clearLLIntGetByIdCache):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* bytecode/MetadataTable.cpp: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
(JSC::MetadataTable::MetadataTable):
(JSC::DeallocTable::withOpcodeType):
(JSC::MetadataTable::~MetadataTable):
(JSC::MetadataTable::sizeInBytes):
* bytecode/MetadataTable.h: Copied from Source/JavaScriptCore/runtime/Watchdog.h.
(JSC::MetadataTable::get):
(JSC::MetadataTable::forEach):
(JSC::MetadataTable::getImpl):
* bytecode/Opcode.cpp:
(JSC::metadataSize):
* bytecode/Opcode.h:
(JSC::padOpcodeName):
* bytecode/OpcodeInlines.h:
(JSC::isOpcodeShape):
(JSC::getOpcodeType):
* bytecode/OpcodeSize.h: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
* bytecode/PreciseJumpTargets.cpp:
(JSC::getJumpTargetsForInstruction):
(JSC::computePreciseJumpTargetsInternal):
(JSC::computePreciseJumpTargets):
(JSC::recomputePreciseJumpTargets):
(JSC::findJumpTargetsForInstruction):
* bytecode/PreciseJumpTargets.h:
* bytecode/PreciseJumpTargetsInlines.h:
(JSC::jumpTargetForInstruction):
(JSC::extractStoredJumpTargetsForInstruction):
(JSC::updateStoredJumpTargetsForInstruction):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
* bytecode/SpecialPointer.cpp:
(WTF::printInternal):
* bytecode/SpecialPointer.h:
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
(JSC::UnlinkedCodeBlock::visitChildren):
(JSC::UnlinkedCodeBlock::estimatedSize):
(JSC::UnlinkedCodeBlock::lineNumberForBytecodeOffset):
(JSC::dumpLineColumnEntry):
(JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset const):
(JSC::UnlinkedCodeBlock::setInstructions):
(JSC::UnlinkedCodeBlock::instructions const):
(JSC::UnlinkedCodeBlock::applyModification):
(JSC::UnlinkedCodeBlock::addOutOfLineJumpTarget):
(JSC::UnlinkedCodeBlock::outOfLineJumpOffset):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::addPropertyAccessInstruction):
(JSC::UnlinkedCodeBlock::propertyAccessInstructions const):
(JSC::UnlinkedCodeBlock::addOpProfileControlFlowBytecodeOffset):
(JSC::UnlinkedCodeBlock::opProfileControlFlowBytecodeOffsets const):
(JSC::UnlinkedCodeBlock::metadata):
(JSC::UnlinkedCodeBlock::metadataSizeInBytes):
(JSC::UnlinkedCodeBlock::outOfLineJumpOffset):
(JSC::UnlinkedCodeBlock::replaceOutOfLineJumpTargets):
* bytecode/UnlinkedInstructionStream.cpp: Removed.
* bytecode/UnlinkedInstructionStream.h: Removed.
* bytecode/UnlinkedMetadataTable.h: Copied from Source/JavaScriptCore/bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h.
* bytecode/UnlinkedMetadataTableInlines.h: Added.
(JSC::UnlinkedMetadataTable::UnlinkedMetadataTable):
(JSC::UnlinkedMetadataTable::~UnlinkedMetadataTable):
(JSC::UnlinkedMetadataTable::addEntry):
(JSC::UnlinkedMetadataTable::sizeInBytes):
(JSC::UnlinkedMetadataTable::finalize):
(JSC::UnlinkedMetadataTable::link):
(JSC::UnlinkedMetadataTable::unlink):
* bytecode/VirtualRegister.cpp:
(JSC::VirtualRegister::VirtualRegister):
* bytecode/VirtualRegister.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::Label::setLocation):
(JSC::Label::bind):
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeVarLexicalEnvironment):
(JSC::BytecodeGenerator::emitEnter):
(JSC::BytecodeGenerator::emitLoopHint):
(JSC::BytecodeGenerator::emitJump):
(JSC::BytecodeGenerator::emitCheckTraps):
(JSC::BytecodeGenerator::rewind):
(JSC::BytecodeGenerator::fuseCompareAndJump):
(JSC::BytecodeGenerator::fuseTestAndJmp):
(JSC::BytecodeGenerator::emitJumpIfTrue):
(JSC::BytecodeGenerator::emitJumpIfFalse):
(JSC::BytecodeGenerator::emitJumpIfNotFunctionCall):
(JSC::BytecodeGenerator::emitJumpIfNotFunctionApply):
(JSC::BytecodeGenerator::moveLinkTimeConstant):
(JSC::BytecodeGenerator::moveEmptyValue):
(JSC::BytecodeGenerator::emitMove):
(JSC::BytecodeGenerator::emitUnaryOp):
(JSC::BytecodeGenerator::emitBinaryOp):
(JSC::BytecodeGenerator::emitToObject):
(JSC::BytecodeGenerator::emitToNumber):
(JSC::BytecodeGenerator::emitToString):
(JSC::BytecodeGenerator::emitTypeOf):
(JSC::BytecodeGenerator::emitInc):
(JSC::BytecodeGenerator::emitDec):
(JSC::BytecodeGenerator::emitEqualityOp):
(JSC::BytecodeGenerator::emitProfileType):
(JSC::BytecodeGenerator::emitProfileControlFlow):
(JSC::BytecodeGenerator::pushLexicalScopeInternal):
(JSC::BytecodeGenerator::emitResolveScopeForHoistingFuncDeclInEval):
(JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
(JSC::BytecodeGenerator::emitOverridesHasInstance):
(JSC::BytecodeGenerator::emitResolveScope):
(JSC::BytecodeGenerator::emitGetFromScope):
(JSC::BytecodeGenerator::emitPutToScope):
(JSC::BytecodeGenerator::emitInstanceOf):
(JSC::BytecodeGenerator::emitInstanceOfCustom):
(JSC::BytecodeGenerator::emitInByVal):
(JSC::BytecodeGenerator::emitInById):
(JSC::BytecodeGenerator::emitTryGetById):
(JSC::BytecodeGenerator::emitGetById):
(JSC::BytecodeGenerator::emitDirectGetById):
(JSC::BytecodeGenerator::emitPutById):
(JSC::BytecodeGenerator::emitDirectPutById):
(JSC::BytecodeGenerator::emitPutGetterById):
(JSC::BytecodeGenerator::emitPutSetterById):
(JSC::BytecodeGenerator::emitPutGetterSetter):
(JSC::BytecodeGenerator::emitPutGetterByVal):
(JSC::BytecodeGenerator::emitPutSetterByVal):
(JSC::BytecodeGenerator::emitDeleteById):
(JSC::BytecodeGenerator::emitGetByVal):
(JSC::BytecodeGenerator::emitPutByVal):
(JSC::BytecodeGenerator::emitDirectPutByVal):
(JSC::BytecodeGenerator::emitDeleteByVal):
(JSC::BytecodeGenerator::emitSuperSamplerBegin):
(JSC::BytecodeGenerator::emitSuperSamplerEnd):
(JSC::BytecodeGenerator::emitIdWithProfile):
(JSC::BytecodeGenerator::emitUnreachable):
(JSC::BytecodeGenerator::emitGetArgument):
(JSC::BytecodeGenerator::emitCreateThis):
(JSC::BytecodeGenerator::emitTDZCheck):
(JSC::BytecodeGenerator::emitNewObject):
(JSC::BytecodeGenerator::emitNewArrayBuffer):
(JSC::BytecodeGenerator::emitNewArray):
(JSC::BytecodeGenerator::emitNewArrayWithSpread):
(JSC::BytecodeGenerator::emitNewArrayWithSize):
(JSC::BytecodeGenerator::emitNewRegExp):
(JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
(JSC::BytecodeGenerator::emitNewDefaultConstructor):
(JSC::BytecodeGenerator::emitNewFunction):
(JSC::BytecodeGenerator::emitSetFunctionNameIfNeeded):
(JSC::BytecodeGenerator::emitCall):
(JSC::BytecodeGenerator::emitCallInTailPosition):
(JSC::BytecodeGenerator::emitCallEval):
(JSC::BytecodeGenerator::emitExpectedFunctionSnippet):
(JSC::BytecodeGenerator::emitCallVarargs):
(JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
(JSC::BytecodeGenerator::emitConstructVarargs):
(JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition):
(JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary):
(JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary):
(JSC::BytecodeGenerator::emitCallDefineProperty):
(JSC::BytecodeGenerator::emitReturn):
(JSC::BytecodeGenerator::emitEnd):
(JSC::BytecodeGenerator::emitConstruct):
(JSC::BytecodeGenerator::emitStrcat):
(JSC::BytecodeGenerator::emitToPrimitive):
(JSC::BytecodeGenerator::emitGetScope):
(JSC::BytecodeGenerator::emitPushWithScope):
(JSC::BytecodeGenerator::emitGetParentScope):
(JSC::BytecodeGenerator::emitDebugHook):
(JSC::BytecodeGenerator::emitCatch):
(JSC::BytecodeGenerator::emitThrow):
(JSC::BytecodeGenerator::emitArgumentCount):
(JSC::BytecodeGenerator::emitThrowStaticError):
(JSC::BytecodeGenerator::beginSwitch):
(JSC::prepareJumpTableForSwitch):
(JSC::prepareJumpTableForStringSwitch):
(JSC::BytecodeGenerator::endSwitch):
(JSC::BytecodeGenerator::emitGetEnumerableLength):
(JSC::BytecodeGenerator::emitHasGenericProperty):
(JSC::BytecodeGenerator::emitHasIndexedProperty):
(JSC::BytecodeGenerator::emitHasStructureProperty):
(JSC::BytecodeGenerator::emitGetPropertyEnumerator):
(JSC::BytecodeGenerator::emitEnumeratorStructurePropertyName):
(JSC::BytecodeGenerator::emitEnumeratorGenericPropertyName):
(JSC::BytecodeGenerator::emitToIndexString):
(JSC::BytecodeGenerator::emitIsCellWithType):
(JSC::BytecodeGenerator::emitIsObject):
(JSC::BytecodeGenerator::emitIsNumber):
(JSC::BytecodeGenerator::emitIsUndefined):
(JSC::BytecodeGenerator::emitIsEmpty):
(JSC::BytecodeGenerator::emitRestParameter):
(JSC::BytecodeGenerator::emitRequireObjectCoercible):
(JSC::BytecodeGenerator::emitYieldPoint):
(JSC::BytecodeGenerator::emitYield):
(JSC::BytecodeGenerator::emitGetAsyncIterator):
(JSC::BytecodeGenerator::emitDelegateYield):
(JSC::BytecodeGenerator::emitFinallyCompletion):
(JSC::BytecodeGenerator::emitJumpIf):
(JSC::ForInContext::finalize):
(JSC::StructureForInContext::finalize):
(JSC::IndexedForInContext::finalize):
(JSC::StaticPropertyAnalysis::record):
(JSC::BytecodeGenerator::emitToThis):
* bytecompiler/BytecodeGenerator.h:
(JSC::StructureForInContext::addGetInst):
(JSC::BytecodeGenerator::recordOpcode):
(JSC::BytecodeGenerator::addMetadataFor):
(JSC::BytecodeGenerator::emitUnaryOp):
(JSC::BytecodeGenerator::kill):
(JSC::BytecodeGenerator::instructions const):
(JSC::BytecodeGenerator::write):
(JSC::BytecodeGenerator::withWriter):
* bytecompiler/Label.h:
(JSC::Label::Label):
(JSC::Label::bind):
* bytecompiler/NodesCodegen.cpp:
(JSC::ArrayNode::emitBytecode):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_argumentCount):
(JSC::ApplyFunctionCallDotNode::emitBytecode):
(JSC::BitwiseNotNode::emitBytecode):
(JSC::BinaryOpNode::emitBytecode):
(JSC::EqualNode::emitBytecode):
(JSC::StrictEqualNode::emitBytecode):
(JSC::emitReadModifyAssignment):
(JSC::ForInNode::emitBytecode):
(JSC::CaseBlockNode::emitBytecodeForBlock):
(JSC::FunctionNode::emitBytecode):
(JSC::ClassExprNode::emitBytecode):
* bytecompiler/ProfileTypeBytecodeFlag.cpp: Copied from Source/JavaScriptCore/bytecode/VirtualRegister.cpp.
(WTF::printInternal):
* bytecompiler/ProfileTypeBytecodeFlag.h: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
* bytecompiler/RegisterID.h:
* bytecompiler/StaticPropertyAnalysis.h:
(JSC::StaticPropertyAnalysis::create):
(JSC::StaticPropertyAnalysis::StaticPropertyAnalysis):
* bytecompiler/StaticPropertyAnalyzer.h:
(JSC::StaticPropertyAnalyzer::createThis):
(JSC::StaticPropertyAnalyzer::newObject):
(JSC::StaticPropertyAnalyzer::putById):
(JSC::StaticPropertyAnalyzer::mov):
(JSC::StaticPropertyAnalyzer::kill):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addCall):
(JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
(JSC::DFG::ByteCodeParser::getArrayMode):
(JSC::DFG::ByteCodeParser::handleCall):
(JSC::DFG::ByteCodeParser::handleVarargsCall):
(JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
(JSC::DFG::ByteCodeParser::inlineCall):
(JSC::DFG::ByteCodeParser::handleCallVariant):
(JSC::DFG::ByteCodeParser::handleVarargsInlining):
(JSC::DFG::ByteCodeParser::handleInlining):
(JSC::DFG::ByteCodeParser::handleMinMax):
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
(JSC::DFG::ByteCodeParser::handleDOMJITCall):
(JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
(JSC::DFG::ByteCodeParser::handleDOMJITGetter):
(JSC::DFG::ByteCodeParser::handleModuleNamespaceLoad):
(JSC::DFG::ByteCodeParser::handleTypedArrayConstructor):
(JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::handlePutById):
(JSC::DFG::ByteCodeParser::parseGetById):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::parseCodeBlock):
(JSC::DFG::ByteCodeParser::handlePutByVal):
(JSC::DFG::ByteCodeParser::handlePutAccessorById):
(JSC::DFG::ByteCodeParser::handlePutAccessorByVal):
(JSC::DFG::ByteCodeParser::handleNewFunc):
(JSC::DFG::ByteCodeParser::handleNewFuncExp):
(JSC::DFG::ByteCodeParser::parse):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGCapabilities.h:
(JSC::DFG::capabilityLevel):
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareCatchOSREntry):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueAdd):
(JSC::DFG::SpeculativeJIT::compileValueSub):
(JSC::DFG::SpeculativeJIT::compileValueNegate):
(JSC::DFG::SpeculativeJIT::compileArithMul):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
(JSC::FTL::DFG::LowerDFGToB3::compileValueSub):
(JSC::FTL::DFG::LowerDFGToB3::compileUnaryMathIC):
(JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC):
(JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
(JSC::FTL::DFG::LowerDFGToB3::compileArithMul):
(JSC::FTL::DFG::LowerDFGToB3::compileValueNegate):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
* generate-bytecode-files: Removed.
* generator/Argument.rb: Added.
* generator/Assertion.rb: Added.
* generator/DSL.rb: Added.
* generator/Fits.rb: Added.
* generator/GeneratedFile.rb: Added.
* generator/Metadata.rb: Added.
* generator/Opcode.rb: Added.
* generator/OpcodeGroup.rb: Added.
* generator/Options.rb: Added.
* generator/Section.rb: Added.
* generator/Template.rb: Added.
* generator/Type.rb: Added.
* generator/main.rb: Added.
* interpreter/AbstractPC.h:
* interpreter/CallFrame.cpp:
(JSC::CallFrame::currentVPC const):
(JSC::CallFrame::setCurrentVPC):
* interpreter/CallFrame.h:
(JSC::CallSiteIndex::CallSiteIndex):
(JSC::ExecState::setReturnPC):
* interpreter/Interpreter.cpp:
(WTF::printInternal):
* interpreter/Interpreter.h:
* interpreter/InterpreterInlines.h:
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::dump const):
* interpreter/VMEntryRecord.h:
* jit/JIT.cpp:
(JSC::JIT::JIT):
(JSC::JIT::emitSlowCaseCall):
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
(JSC::JIT::compileWithoutLinking):
(JSC::JIT::link):
* jit/JIT.h:
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_jless):
(JSC::JIT::emit_op_jlesseq):
(JSC::JIT::emit_op_jgreater):
(JSC::JIT::emit_op_jgreatereq):
(JSC::JIT::emit_op_jnless):
(JSC::JIT::emit_op_jnlesseq):
(JSC::JIT::emit_op_jngreater):
(JSC::JIT::emit_op_jngreatereq):
(JSC::JIT::emitSlow_op_jless):
(JSC::JIT::emitSlow_op_jlesseq):
(JSC::JIT::emitSlow_op_jgreater):
(JSC::JIT::emitSlow_op_jgreatereq):
(JSC::JIT::emitSlow_op_jnless):
(JSC::JIT::emitSlow_op_jnlesseq):
(JSC::JIT::emitSlow_op_jngreater):
(JSC::JIT::emitSlow_op_jngreatereq):
(JSC::JIT::emit_op_below):
(JSC::JIT::emit_op_beloweq):
(JSC::JIT::emit_op_jbelow):
(JSC::JIT::emit_op_jbeloweq):
(JSC::JIT::emit_op_unsigned):
(JSC::JIT::emit_compareAndJump):
(JSC::JIT::emit_compareUnsignedAndJump):
(JSC::JIT::emit_compareUnsigned):
(JSC::JIT::emit_compareAndJumpSlow):
(JSC::JIT::emit_op_inc):
(JSC::JIT::emit_op_dec):
(JSC::JIT::emit_op_mod):
(JSC::JIT::emitSlow_op_mod):
(JSC::JIT::emit_op_negate):
(JSC::JIT::emitSlow_op_negate):
(JSC::JIT::emitBitBinaryOpFastPath):
(JSC::JIT::emit_op_bitand):
(JSC::JIT::emit_op_bitor):
(JSC::JIT::emit_op_bitxor):
(JSC::JIT::emit_op_lshift):
(JSC::JIT::emitRightShiftFastPath):
(JSC::JIT::emit_op_rshift):
(JSC::JIT::emit_op_urshift):
(JSC::getOperandTypes):
(JSC::JIT::emit_op_add):
(JSC::JIT::emitSlow_op_add):
(JSC::JIT::emitMathICFast):
(JSC::JIT::emitMathICSlow):
(JSC::JIT::emit_op_div):
(JSC::JIT::emit_op_mul):
(JSC::JIT::emitSlow_op_mul):
(JSC::JIT::emit_op_sub):
(JSC::JIT::emitSlow_op_sub):
* jit/JITCall.cpp:
(JSC::JIT::emitPutCallResult):
(JSC::JIT::compileSetupFrame):
(JSC::JIT::compileCallEval):
(JSC::JIT::compileCallEvalSlowCase):
(JSC::JIT::compileTailCall):
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
(JSC::JIT::emit_op_call):
(JSC::JIT::emit_op_tail_call):
(JSC::JIT::emit_op_call_eval):
(JSC::JIT::emit_op_call_varargs):
(JSC::JIT::emit_op_tail_call_varargs):
(JSC::JIT::emit_op_tail_call_forward_arguments):
(JSC::JIT::emit_op_construct_varargs):
(JSC::JIT::emit_op_construct):
(JSC::JIT::emitSlow_op_call):
(JSC::JIT::emitSlow_op_tail_call):
(JSC::JIT::emitSlow_op_call_eval):
(JSC::JIT::emitSlow_op_call_varargs):
(JSC::JIT::emitSlow_op_tail_call_varargs):
(JSC::JIT::emitSlow_op_tail_call_forward_arguments):
(JSC::JIT::emitSlow_op_construct_varargs):
(JSC::JIT::emitSlow_op_construct):
* jit/JITDisassembler.cpp:
(JSC::JITDisassembler::JITDisassembler):
* jit/JITExceptions.cpp:
(JSC::genericUnwind):
* jit/JITInlines.h:
(JSC::JIT::emitDoubleGetByVal):
(JSC::JIT::emitLoadForArrayMode):
(JSC::JIT::emitContiguousGetByVal):
(JSC::JIT::emitArrayStorageGetByVal):
(JSC::JIT::appendCallWithExceptionCheckSetJSValueResultWithProfile):
(JSC::JIT::sampleInstruction):
(JSC::JIT::emitValueProfilingSiteIfProfiledOpcode):
(JSC::JIT::emitValueProfilingSite):
(JSC::JIT::jumpTarget):
(JSC::JIT::copiedGetPutInfo):
(JSC::JIT::copiedArithProfile):
* jit/JITMathIC.h:
(JSC::isProfileEmpty):
(JSC::JITBinaryMathIC::JITBinaryMathIC):
(JSC::JITUnaryMathIC::JITUnaryMathIC):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_mov):
(JSC::JIT::emit_op_end):
(JSC::JIT::emit_op_jmp):
(JSC::JIT::emit_op_new_object):
(JSC::JIT::emitSlow_op_new_object):
(JSC::JIT::emit_op_overrides_has_instance):
(JSC::JIT::emit_op_instanceof):
(JSC::JIT::emitSlow_op_instanceof):
(JSC::JIT::emit_op_instanceof_custom):
(JSC::JIT::emit_op_is_empty):
(JSC::JIT::emit_op_is_undefined):
(JSC::JIT::emit_op_is_boolean):
(JSC::JIT::emit_op_is_number):
(JSC::JIT::emit_op_is_cell_with_type):
(JSC::JIT::emit_op_is_object):
(JSC::JIT::emit_op_ret):
(JSC::JIT::emit_op_to_primitive):
(JSC::JIT::emit_op_set_function_name):
(JSC::JIT::emit_op_not):
(JSC::JIT::emit_op_jfalse):
(JSC::JIT::emit_op_jeq_null):
(JSC::JIT::emit_op_jneq_null):
(JSC::JIT::emit_op_jneq_ptr):
(JSC::JIT::emit_op_eq):
(JSC::JIT::emit_op_jeq):
(JSC::JIT::emit_op_jtrue):
(JSC::JIT::emit_op_neq):
(JSC::JIT::emit_op_jneq):
(JSC::JIT::emit_op_throw):
(JSC::JIT::compileOpStrictEq):
(JSC::JIT::emit_op_stricteq):
(JSC::JIT::emit_op_nstricteq):
(JSC::JIT::compileOpStrictEqJump):
(JSC::JIT::emit_op_jstricteq):
(JSC::JIT::emit_op_jnstricteq):
(JSC::JIT::emitSlow_op_jstricteq):
(JSC::JIT::emitSlow_op_jnstricteq):
(JSC::JIT::emit_op_to_number):
(JSC::JIT::emit_op_to_string):
(JSC::JIT::emit_op_to_object):
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_identity_with_profile):
(JSC::JIT::emit_op_get_parent_scope):
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emit_op_switch_char):
(JSC::JIT::emit_op_switch_string):
(JSC::JIT::emit_op_debug):
(JSC::JIT::emit_op_eq_null):
(JSC::JIT::emit_op_neq_null):
(JSC::JIT::emit_op_enter):
(JSC::JIT::emit_op_get_scope):
(JSC::JIT::emit_op_to_this):
(JSC::JIT::emit_op_create_this):
(JSC::JIT::emit_op_check_tdz):
(JSC::JIT::emitSlow_op_eq):
(JSC::JIT::emitSlow_op_neq):
(JSC::JIT::emitSlow_op_jeq):
(JSC::JIT::emitSlow_op_jneq):
(JSC::JIT::emitSlow_op_instanceof_custom):
(JSC::JIT::emit_op_loop_hint):
(JSC::JIT::emitSlow_op_loop_hint):
(JSC::JIT::emit_op_check_traps):
(JSC::JIT::emit_op_nop):
(JSC::JIT::emit_op_super_sampler_begin):
(JSC::JIT::emit_op_super_sampler_end):
(JSC::JIT::emitSlow_op_check_traps):
(JSC::JIT::emit_op_new_regexp):
(JSC::JIT::emitNewFuncCommon):
(JSC::JIT::emit_op_new_func):
(JSC::JIT::emit_op_new_generator_func):
(JSC::JIT::emit_op_new_async_generator_func):
(JSC::JIT::emit_op_new_async_func):
(JSC::JIT::emitNewFuncExprCommon):
(JSC::JIT::emit_op_new_func_exp):
(JSC::JIT::emit_op_new_generator_func_exp):
(JSC::JIT::emit_op_new_async_func_exp):
(JSC::JIT::emit_op_new_async_generator_func_exp):
(JSC::JIT::emit_op_new_array):
(JSC::JIT::emit_op_new_array_with_size):
(JSC::JIT::emit_op_has_structure_property):
(JSC::JIT::privateCompileHasIndexedProperty):
(JSC::JIT::emit_op_has_indexed_property):
(JSC::JIT::emitSlow_op_has_indexed_property):
(JSC::JIT::emit_op_get_direct_pname):
(JSC::JIT::emit_op_enumerator_structure_pname):
(JSC::JIT::emit_op_enumerator_generic_pname):
(JSC::JIT::emit_op_profile_type):
(JSC::JIT::emit_op_log_shadow_chicken_prologue):
(JSC::JIT::emit_op_log_shadow_chicken_tail):
(JSC::JIT::emit_op_profile_control_flow):
(JSC::JIT::emit_op_argument_count):
(JSC::JIT::emit_op_get_rest_length):
(JSC::JIT::emit_op_get_argument):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_to_this):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emitGetByValWithCachedId):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emit_op_put_by_val_direct):
(JSC::JIT::emit_op_put_by_val):
(JSC::JIT::emitGenericContiguousPutByVal):
(JSC::JIT::emitArrayStoragePutByVal):
(JSC::JIT::emitPutByValWithCachedId):
(JSC::JIT::emitSlow_op_put_by_val):
(JSC::JIT::emit_op_put_getter_by_id):
(JSC::JIT::emit_op_put_setter_by_id):
(JSC::JIT::emit_op_put_getter_setter_by_id):
(JSC::JIT::emit_op_put_getter_by_val):
(JSC::JIT::emit_op_put_setter_by_val):
(JSC::JIT::emit_op_del_by_id):
(JSC::JIT::emit_op_del_by_val):
(JSC::JIT::emit_op_try_get_by_id):
(JSC::JIT::emitSlow_op_try_get_by_id):
(JSC::JIT::emit_op_get_by_id_direct):
(JSC::JIT::emitSlow_op_get_by_id_direct):
(JSC::JIT::emit_op_get_by_id):
(JSC::JIT::emit_op_get_by_id_with_this):
(JSC::JIT::emitSlow_op_get_by_id):
(JSC::JIT::emitSlow_op_get_by_id_with_this):
(JSC::JIT::emit_op_put_by_id):
(JSC::JIT::emitSlow_op_put_by_id):
(JSC::JIT::emit_op_in_by_id):
(JSC::JIT::emitSlow_op_in_by_id):
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emitSlow_op_get_from_scope):
(JSC::JIT::emit_op_put_to_scope):
(JSC::JIT::emitSlow_op_put_to_scope):
(JSC::JIT::emit_op_get_from_arguments):
(JSC::JIT::emit_op_put_to_arguments):
(JSC::JIT::privateCompileGetByVal):
(JSC::JIT::privateCompileGetByValWithCachedId):
(JSC::JIT::privateCompilePutByVal):
(JSC::JIT::privateCompilePutByValWithCachedId):
(JSC::JIT::emitDoubleLoad):
(JSC::JIT::emitContiguousLoad):
(JSC::JIT::emitArrayStorageLoad):
(JSC::JIT::emitDirectArgumentsGetByVal):
(JSC::JIT::emitScopedArgumentsGetByVal):
(JSC::JIT::emitIntTypedArrayGetByVal):
(JSC::JIT::emitFloatTypedArrayGetByVal):
(JSC::JIT::emitIntTypedArrayPutByVal):
(JSC::JIT::emitFloatTypedArrayPutByVal):
* jit/RegisterSet.cpp:
(JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
* jit/SlowPathCall.h:
(JSC::JITSlowPathCall::JITSlowPathCall):
* llint/LLIntData.cpp:
(JSC::LLInt::initialize):
(JSC::LLInt::Data::performAssertions):
* llint/LLIntData.h:
(JSC::LLInt::exceptionInstructions):
(JSC::LLInt::opcodeMap):
(JSC::LLInt::opcodeMapWide):
(JSC::LLInt::getOpcode):
(JSC::LLInt::getOpcodeWide):
(JSC::LLInt::getWideCodePtr):
* llint/LLIntOffsetsExtractor.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::llint_trace_operand):
(JSC::LLInt::llint_trace_value):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::entryOSR):
(JSC::LLInt::setupGetByIdPrototypeCache):
(JSC::LLInt::getByVal):
(JSC::LLInt::handleHostCall):
(JSC::LLInt::setUpCall):
(JSC::LLInt::genericCall):
(JSC::LLInt::varargsSetup):
(JSC::LLInt::commonCallEval):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter.cpp:
(JSC::CLoopRegister::operator const Instruction*):
(JSC::CLoop::execute):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* offlineasm/arm64.rb:
* offlineasm/asm.rb:
* offlineasm/ast.rb:
* offlineasm/cloop.rb:
* offlineasm/generate_offset_extractor.rb:
* offlineasm/instructions.rb:
* offlineasm/offsets.rb:
* offlineasm/parser.rb:
* offlineasm/transform.rb:
* offlineasm/x86.rb:
* parser/ResultType.h:
(JSC::ResultType::dump const):
(JSC::OperandTypes::first const):
(JSC::OperandTypes::second const):
(JSC::OperandTypes::dump const):
* profiler/ProfilerBytecodeSequence.cpp:
(JSC::Profiler::BytecodeSequence::BytecodeSequence):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
(JSC::updateArithProfileForUnaryArithOp):
(JSC::updateArithProfileForBinaryArithOp):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
(JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
* runtime/ExceptionFuzz.cpp:
(JSC::doExceptionFuzzing):
* runtime/ExceptionFuzz.h:
(JSC::doExceptionFuzzingIfEnabled):
* runtime/GetPutInfo.cpp: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
(JSC::GetPutInfo::dump const):
(WTF::printInternal):
* runtime/GetPutInfo.h:
(JSC::GetPutInfo::operand const):
* runtime/JSCPoison.h:
* runtime/JSType.cpp: Added.
(WTF::printInternal):
* runtime/JSType.h:
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::StackFrame::displayName):
* runtime/SamplingProfiler.h:
(JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame):
* runtime/SlowPathReturnType.h:
(JSC::encodeResult):
(JSC::decodeResult):
* runtime/VM.h:
* runtime/Watchdog.h:
* tools/HeapVerifier.cpp:
2018-10-26 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r237445.
https://bugs.webkit.org/show_bug.cgi?id=190972
Cause performance regression on iOS devices (Requested by
yusukesuzuki on #webkit).
Reverted changeset:
"Unreviewed, partial rolling in r237254"
https://bugs.webkit.org/show_bug.cgi?id=190340
https://trac.webkit.org/changeset/237445
2018-10-26 Mark Lam <mark.lam@apple.com>
Fix missing edge cases with JSGlobalObjects having a bad time.
https://bugs.webkit.org/show_bug.cgi?id=189028
<rdar://problem/45204939>
Reviewed by Saam Barati.
Consider the following scenario:
let object O1 (of global G1) have an indexing type that is not SlowPut.
let global G2 have a bad time.
let object O2 (of global G2) be set as the prototype of O1.
let object O3 (of global G2) have indexed accessors.
In the existing code, if we set O3 as O2's prototype, we'll have a bug where
O1 will not be made aware that that there are indexed accessors in its prototype
chain.
In this patch, we solve this issue by introducing a new invariant:
A prototype chain is considered to possibly have indexed accessors if any
object in the chain belongs to a global object that is having a bad time.
We apply this invariant as follows:
1. Enhance JSGlobalObject::haveABadTime() to also check if other global objects are
affected by it having a bad time. If so, it also ensures that those affected
global objects have a bad time.
The original code for JSGlobalObject::haveABadTime() uses a ObjectsWithBrokenIndexingFinder
to find all objects affected by the global object having a bad time. We enhance
ObjectsWithBrokenIndexingFinder to also check for the possibility that any global
objects may be affected by other global objects having a bad time i.e.
let g1 = global1
let g2 = global2
let o1 = an object in g1
let o2 = an object in g2
let g1 have a bad time
g2 is affected if
o1 is in the prototype chain of o2,
and o2 may be a prototype.
If the ObjectsWithBrokenIndexingFinder does find the possibility of other global
objects being affected, it will abort its heap scan and let haveABadTime() take
a slow path to do a more complete multi global object scan.
The slow path works as follows:
1. Iterate the heap and record the graph of all global object dependencies.
For each global object, record the list of other global objects that are
affected by it.
2. Compute a list of global objects that need to have a bad time using the
current global object dependency graph.
3. For each global object in the list of affected global objects, fire their
HaveABadTime watchpoint and convert all their array structures to the
SlowPut alternatives.
4. Re-run ObjectsWithBrokenIndexingFinder to find all objects that are affected
by any of the globals in the list from (2).
2. Enhance Structure::mayInterceptIndexedAccesses() to also return true if the
structure's global object is having a bad time.
Note: there are 3 scenarios that we need to consider:
let g1 = global1
let g2 = global2
let o1 = an object in g1
let o2 = an object in g2
Scenario 1: o2 is a prototype, and
g1 has a bad time after o1 is inserted into the o2's prototype chain.
Scenario 2: o2 is a prototype, and
o1 is inserted into the o2's prototype chain after g1 has a bad time.
Scenario 3: o2 is NOT a prototype, and
o1 is inserted into the o2's prototype chain after g1 has a bad time.
For scenario 1, when g1 has a bad time, we need to also make sure g2 has
a bad time. This is handled by enhancement 1 above.
For scenario 2, when o1 is inserted into o2's prototype chain, we need to check
if o1's global object has a bad time. If so, then we need to make sure o2's
global also has a bad time (because o2 is a prototype) and convert o2's
storage type to SlowPut. This is handled by enhancement 2 above in conjunction
with JSObject::setPrototypeDirect().
For scenario 3, when o1 is inserted into o2's prototype chain, we need to check
if o1's global object has a bad time. If so, then we only need to convert o2's
storage type to SlowPut (because o2 is NOT a prototype). This is handled by
enhancement 2 above.
3. Also add $vm.isHavingABadTime(), $vm.createGlobalObject() to enable us to
write some tests for this issue.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::fireWatchpointAndMakeAllArrayStructuresSlowPut):
(JSC::JSGlobalObject::haveABadTime):
* runtime/JSGlobalObject.h:
* runtime/JSObject.h:
(JSC::JSObject::mayInterceptIndexedAccesses): Deleted.
* runtime/JSObjectInlines.h:
(JSC::JSObject::mayInterceptIndexedAccesses):
* runtime/Structure.h:
* runtime/StructureInlines.h:
(JSC::Structure::mayInterceptIndexedAccesses const):
* tools/JSDollarVM.cpp:
(JSC::functionHaveABadTime):
(JSC::functionIsHavingABadTime):
(JSC::functionCreateGlobalObject):
(JSC::JSDollarVM::finishCreation):
2018-10-26 Keith Miller <keith_miller@apple.com>
JSC xcconfig should set DEFINES_MODULE
https://bugs.webkit.org/show_bug.cgi?id=190952
Reviewed by Mark Lam.
This should mean that the JavaScriptCore.framework will have a module map.
* Configurations/JavaScriptCore.xcconfig:
2018-10-25 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] havingABadTimeWatchpoint is not required in Array#indexOf optimization
https://bugs.webkit.org/show_bug.cgi?id=190941
Reviewed by Saam Barati.
While "Rest" operation fast path requires havingABadTimeWatchpoint since it allocates
JSArray, Array#{indexOf,lastIndexOf} do not require it when we use the fast path for them.
This patch removes watching on havingABadTimeWatchpoint in Array#indexOf. The test causing
"havingABadTime" is already included in our test suites (e.g. array-indexof-have-a-bad-time.js).
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* runtime/JSArrayInlines.h:
(JSC::JSArray::canDoFastIndexedAccess):
* runtime/JSGlobalObject.h:
* runtime/JSGlobalObjectInlines.h:
(JSC::JSGlobalObject::isArrayPrototypeIteratorProtocolFastAndNonObservable):
(JSC::JSGlobalObject::isArrayPrototypeIndexedAccessFastAndNonObservable): Deleted.
2018-10-25 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Unreviewed, partial rolling in r237254
https://bugs.webkit.org/show_bug.cgi?id=190340
We do not use the added function right now to investigate what is the reason of the regression.
If it causes the regression, it seems that Parser.cpp's inlining decision seems culprit.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
* bytecode/UnlinkedFunctionExecutable.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseSingleFunction):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
(JSC::parse):
(JSC::parseFunctionForFunctionConstructor):
* parser/ParserModes.h:
* parser/ParserTokens.h:
(JSC::JSTextPosition::JSTextPosition):
(JSC::JSTokenLocation::JSTokenLocation): Deleted.
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::SourceCodeKey):
(JSC::SourceCodeKey::operator== const):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
* runtime/CodeCache.h:
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/FunctionExecutable.h:
2018-10-25 Brent Fulgham <bfulgham@apple.com>
Unreviewed build fix for Visual Studio 2017
* API/tests/testapi.c:
(testMarkingConstraintsAndHeapFinalizers):
(main):
2018-10-25 Devin Rousso <drousso@apple.com>
Web Inspector: display fullscreen enter/exit events in Timelines and Network node waterfalls
https://bugs.webkit.org/show_bug.cgi?id=189874
<rdar://problem/44700000>
Reviewed by Joseph Pecoraro.
* inspector/protocol/DOM.json:
Allow `data` to be passed to the frontend with `didFireEvent`.
2018-10-25 Ross Kirsling <ross.kirsling@sony.com>
Cleanup: inline constexpr is redundant as constexpr implies inline
https://bugs.webkit.org/show_bug.cgi?id=190819
Reviewed by Mark Lam.
* bytecode/ArrayProfile.h:
(JSC::asArrayModes):
* runtime/IndexingType.h:
(JSC::isCopyOnWrite):
* runtime/MathCommon.h:
(JSC::maxSafeInteger):
(JSC::minSafeInteger):
* runtime/StackAlignment.h:
(JSC::stackAlignmentBytes):
(JSC::stackAlignmentRegisters):
2018-10-24 Megan Gardner <megan_gardner@apple.com>
Turn on Conic Gradients
https://bugs.webkit.org/show_bug.cgi?id=190810
Reviewed by Tim Horton.
* Configurations/FeatureDefines.xcconfig:
2018-10-24 Michael Saboff <msaboff@apple.com>
Increase executable memory pool from 64MB to 128MB for ARM64
https://bugs.webkit.org/show_bug.cgi?id=190453
Unreviewed, rolling back in r237024.
The original change did impact ARES-6 performance by 4-8%. That will
be investigated separately.
2018-10-22 Keith Rollin <krollin@apple.com>
Use Location = "Relative to Build Products" rather than "Relative to Group"
https://bugs.webkit.org/show_bug.cgi?id=190781
Reviewed by Alexey Proskuryakov.
Almost all Derived Files are included in Xcode projects with the
Location attribute set to "Relative to Group". While this currently
works, the Derived Files can no longer be found when enabling XCBuild
(which has stricter requirements). Fix this by setting the Location
attribute to "Relative to Build Products".
* JavaScriptCore.xcodeproj/project.pbxproj:
2018-10-22 Mark Lam <mark.lam@apple.com>
DFGAbstractValue::m_arrayModes expects IndexingMode values, not IndexingType.
https://bugs.webkit.org/show_bug.cgi?id=190515
<rdar://problem/45222379>
Reviewed by Saam Barati.
1. Fixes calls to asArrayModes() to take a structure's IndexingMode instead of
IndexingType.
2. DFG's compileNewArrayBuffer()'s HaveABadTime case was previously using the
node's indexingType (instead of indexingMode) to choose the array structure
to use for creating an array buffer with. This turns out to not be an issue
because when the VM is in having a bad time, all the
arrayStructureForIndexingTypeDuringAllocation structure pointers will point to
the SlowPutArrayStorage structure anyway. However, to be strictly correct,
we'll fix it to use the structure for the node's indexingMode.
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::set):
(JSC::DFG::AbstractValue::mergeOSREntryValue):
* dfg/DFGAbstractValue.h:
(JSC::DFG::AbstractValue::validate const):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::executeOSRExit):
* dfg/DFGRegisteredStructureSet.cpp:
(JSC::DFG::RegisteredStructureSet::arrayModesFromStructures const):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewArrayBuffer):
2018-10-19 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r237254.
https://bugs.webkit.org/show_bug.cgi?id=190760
"It regresses JetStream 2 by 5% on some iOS devices"
(Requested by saamyjoon on #webkit).
Reverted changeset:
"[JSC] JSC should have "parseFunction" to optimize Function
constructor"
https://bugs.webkit.org/show_bug.cgi?id=190340
https://trac.webkit.org/changeset/237254
2018-10-19 Saam Barati <sbarati@apple.com>
vmCall should check if we exit before emitting an OSR exit due to exceptions
https://bugs.webkit.org/show_bug.cgi?id=190740
<rdar://problem/45220139>
Reviewed by Mark Lam.
The bug we were seeing is the MovHint removal phase would
eliminate a superfluous MovHint. This left a certain range
of nodes in a state where they would not be able to reconstruct
values for an OSR exit. This is OK, since this phase proved those
nodes don't exit. However, some of these nodes may use the vmCall
construct in FTLLower. vmCall used to unconditionally emit an
exception check after each call. However, if such a call happens
in the range of nodes where we can't exit, we would end up generating
an invalid exit (and running with validateFTLOSRExitLiveness flag
would find this issue).
This patch makes vmCall check to see if the node can exit before
emitting an exception check. A node not being able to exit implies
that it can't exit for exceptions, therefore, by definition, it can't
throw an exception.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::vmCall):
2018-10-19 Caio Lima <ticaiolima@gmail.com>
[ESNext][BigInt] Implement support for "^"
https://bugs.webkit.org/show_bug.cgi?id=186235
Reviewed by Yusuke Suzuki.
This patch is introducing support for BigInt into bitwise xor
operation. We are including only support into LLInt and Baseline.
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::bitwiseXor):
(JSC::JSBigInt::absoluteXor):
* runtime/JSBigInt.h:
2018-10-19 Caio Lima <ticaiolima@gmail.com>
[BigInt] Add ValueSub into DFG
https://bugs.webkit.org/show_bug.cgi?id=186176
Reviewed by Yusuke Suzuki.
We are introducing in this patch a new node called ValueSub. This node
is necessary due to introduction of BigInt, making subtraction
operations result in non-Number values in some cases. In such case, ValueSub is
responsible to handle Untyped and BigInt operations.
In addition, we are also creating a speculative path when both
operands are BigInt. According to a simple BigInt subtraction microbenchmark,
this represents a speedup of ~1.2x faster.
big-int-simple-sub 14.6427+-0.5652 ^ 11.9559+-0.6485 ^ definitely 1.2247x faster
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::addSpeculationMode):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueSub):
(JSC::DFG::SpeculativeJIT::compileArithSub):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGValidate.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
(JSC::FTL::DFG::LowerDFGToB3::compileValueSub):
2018-10-18 Alexey Proskuryakov <ap@apple.com>
Switch from PLATFORM(IOS) to PLATFORM(IOS_FAMILY)
https://bugs.webkit.org/show_bug.cgi?id=190729
Reviewed by Tim Horton.
* API/JSBase.cpp:
* API/JSWrapperMap.mm:
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::cacheFlush):
* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::cacheFlush):
* assembler/AssemblerCommon.h:
(JSC::isIOS):
* heap/FullGCActivityCallback.cpp:
(JSC::FullGCActivityCallback::doCollection):
* heap/Heap.cpp:
(JSC::Heap::overCriticalMemoryThreshold):
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::collectIfNecessaryOrDefer):
* heap/Heap.h:
* inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
(Inspector::RemoteConnectionToTarget::dispatchAsyncOnTarget):
* jit/ExecutableAllocator.cpp:
(JSC::allowJIT):
* jit/ExecutableAllocator.h:
* jit/RegisterSet.cpp:
(JSC::RegisterSet::reservedHardwareRegisters):
(JSC::RegisterSet::calleeSaveRegisters):
* jit/ThunkGenerators.cpp:
* jsc.cpp:
(main):
* runtime/MathCommon.cpp:
* runtime/Options.cpp:
(JSC::overrideDefaults):
(JSC::recomputeDependentOptions):
* runtime/Options.h:
2018-10-18 Ross Kirsling <ross.kirsling@sony.com>
delete expression should not throw without a reference
https://bugs.webkit.org/show_bug.cgi?id=190637
Reviewed by Yusuke Suzuki.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseUnaryExpression):
Eliminate non-spec-compliant switch case.
2018-10-18 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] JSC should have "parseFunction" to optimize Function constructor
https://bugs.webkit.org/show_bug.cgi?id=190340
Reviewed by Mark Lam.
The current Function constructor is suboptimal. We parse the piece of the same code three times to meet
the spec requirement. (1) check parameters syntax, (2) check body syntax, and (3) parse the entire function.
And to parse 1-3 correctly, we create two strings, the parameters and the entire function. This operation
is really costly and ideally we should meet the above requirement by the one time parsing.
To meet the above requirement, we add a special function for Parser, parseSingleFunction. This function
takes `std::optional<int> functionConstructorParametersEndPosition` and check this end position is correct in the parser.
For example, if we run the code,
Function('/*', '*/){')
According to the spec, this should produce '/*' parameter string and '*/){' body string. And parameter
string should be syntax-checked by the parser, and raise the error since it is incorrect. Instead of doing
that, in our implementation, we first create the entire string.
function anonymous(/*) {
*/){
}
And we parse it. At that time, we also pass the end position of the parameters to the parser. In the above case,
the position of the `function anonymous(/*)' <> is passed. And in the parser, we check that the last token
offset of the parameters is the given end position. This check allows us to raise the error correctly to the
above example while we parse the entire function only once. And we do not need to create two strings too.
This improves the performance of the Function constructor significantly. And web-tooling-benchmark/uglify-js is
significantly sped up (28.2%).
Before:
uglify-js: 2.94 runs/s
After:
uglify-js: 3.77 runs/s
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
* bytecode/UnlinkedFunctionExecutable.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseSingleFunction):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
(JSC::parse):
(JSC::parseFunctionForFunctionConstructor):
* parser/ParserModes.h:
* parser/ParserTokens.h:
(JSC::JSTextPosition::JSTextPosition):
(JSC::JSTokenLocation::JSTokenLocation): Deleted.
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::SourceCodeKey):
(JSC::SourceCodeKey::operator== const):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
* runtime/CodeCache.h:
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/FunctionExecutable.h:
2018-10-18 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r237242.
https://bugs.webkit.org/show_bug.cgi?id=190701
it breaks "stress/sampling-profiler-basic.js" (Requested by
caiolima on #webkit).
Reverted changeset:
"[BigInt] Add ValueSub into DFG"
https://bugs.webkit.org/show_bug.cgi?id=186176
https://trac.webkit.org/changeset/237242
2018-10-18 Takafumi Kubota <takafumi.kubota1012@sslab.ics.keio.ac.jp>
Missing #pragma once in WasmOpcodeOrigin.h
https://bugs.webkit.org/show_bug.cgi?id=190699
Reviewed by Yusuke Suzuki.
This patch add ''#pragma once'' into WasmOpcodeOrigin.h to avoid the
multiple inclusion that can happen in the unified build
configuration.
* wasm/WasmOpcodeOrigin.h:
2018-10-17 Wenson Hsieh <wenson_hsieh@apple.com>
Enable the datalist element by default on iOS and macOS
https://bugs.webkit.org/show_bug.cgi?id=190594
<rdar://problem/45281159>
Reviewed by Ryosuke Niwa and Tim Horton.
* Configurations/FeatureDefines.xcconfig:
2018-10-17 Caio Lima <ticaiolima@gmail.com>
[BigInt] Add ValueSub into DFG
https://bugs.webkit.org/show_bug.cgi?id=186176
Reviewed by Yusuke Suzuki.
We are introducing in this patch a new node called ValueSub. This node
is necessary due to introduction of BigInt, making subtraction
operations result in non-Number values in some cases. In such case, ValueSub is
responsible to handle Untyped and BigInt operations.
In addition, we are also creating a speculative path when both
operands are BigInt. According to a simple BigInt subtraction microbenchmark,
this represents a speedup of ~1.2x faster.
big-int-simple-sub 14.6427+-0.5652 ^ 11.9559+-0.6485 ^ definitely 1.2247x faster
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::addSpeculationMode):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueSub):
(JSC::DFG::SpeculativeJIT::compileArithSub):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGValidate.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
(JSC::FTL::DFG::LowerDFGToB3::compileValueSub):
2018-10-17 Mark Lam <mark.lam@apple.com>
The parser should not emit a ApplyFunctionCallDotNode for Reflect.apply.
https://bugs.webkit.org/show_bug.cgi?id=190671
<rdar://problem/45201145>
Reviewed by Saam Barati.
The bytecode generator does not currently know how to inline Reflect.apply (see
https://bugs.webkit.org/show_bug.cgi?id=190668). Hence, it's a waste of time to
emit the ApplyFunctionCallDotNode since the function check against Function.apply
that it will generate will always fail.
Also fixed CallVariant::dump() to be able to handle dumping a non-executable
callee. Reflect.apply used to trip this up. Any object with an apply property
invoked as a function could also trip this up. This is now fixed.
* bytecode/CallVariant.cpp:
(JSC::CallVariant::dump const):
* bytecompiler/NodesCodegen.cpp:
(JSC::ApplyFunctionCallDotNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::makeFunctionCallNode):
2018-10-17 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r237024.
https://bugs.webkit.org/show_bug.cgi?id=190673
"It regressed ARES6 on iOS devices by 4-8%" (Requested by
saamyjoon on #webkit).
Reverted changeset:
"Increase executable memory pool from 64MB to 128MB for ARM64"
https://bugs.webkit.org/show_bug.cgi?id=190453
https://trac.webkit.org/changeset/237024
2018-10-17 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Use WTF::Function instead of std::function
https://bugs.webkit.org/show_bug.cgi?id=190665
Reviewed by Keith Miller.
We should use WTF::Function as much as possible. It allocates memory from bmalloc instead of standard malloc.
* runtime/JSNativeStdFunction.h:
2018-10-17 Keith Miller <keith_miller@apple.com>
Remove debug logging from generate_offsets_extractor.rb
https://bugs.webkit.org/show_bug.cgi?id=190667
Reviewed by Mark Lam.
* offlineasm/generate_offset_extractor.rb:
2018-10-17 Keith Miller <keith_miller@apple.com>
AI does not clear Phantom allocation nodes.
https://bugs.webkit.org/show_bug.cgi?id=190694
Reviewed by Saam Barati.
Phantom nodes claim to have a result so they should make sure they clear
their abstract values.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2018-10-17 Keith Miller <keith_miller@apple.com>
Unreviewed, fix windows build.
* offlineasm/generate_offset_extractor.rb:
2018-10-17 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] More aggressively use `constexpr` in LowLevelInterpreter.asm for constant values
https://bugs.webkit.org/show_bug.cgi?id=190659
Reviewed by Keith Miller.
Asking the actual constant value to the JSC binary is always the best way to get the correct value.
The value is correctly updated once the original value is changed. We would like to encourage this
approach more in LowLevelInterpreter.asm.
This patch expands the coverage of this approach. We make ObservedType, ResultType, and ArithProfile
constexpr-friendly to produce the magic value used in LowLevelInterpreter.asm at compiling time.
This change allows us to easily extend ArithProfile in the future to adopt BigInt efficiently.
We additionally use `constexpr` for several constant values in LowLevelInterpreter.asm.
* assembler/MaxFrameExtentForSlowPathCall.h:
Use this value in LowLevelInterpreter.asm directly. We also make them constexpr. And we add CPU(ARM64E).
* bytecode/ArithProfile.h:
(JSC::ObservedType::ObservedType):
(JSC::ObservedType::sawInt32 const):
(JSC::ObservedType::isOnlyInt32 const):
(JSC::ObservedType::sawNumber const):
(JSC::ObservedType::isOnlyNumber const):
(JSC::ObservedType::sawNonNumber const):
(JSC::ObservedType::isOnlyNonNumber const):
(JSC::ObservedType::isEmpty const):
(JSC::ObservedType::bits const):
(JSC::ObservedType::withInt32 const):
(JSC::ObservedType::withNumber const):
(JSC::ObservedType::withNonNumber const):
(JSC::ObservedType::withoutNonNumber const):
(JSC::ObservedType::operator== const):
(JSC::ArithProfile::ArithProfile):
(JSC::ArithProfile::fromInt):
(JSC::ArithProfile::observedUnaryInt):
(JSC::ArithProfile::observedUnaryNumber):
(JSC::ArithProfile::observedBinaryIntInt):
(JSC::ArithProfile::observedBinaryNumberInt):
(JSC::ArithProfile::observedBinaryIntNumber):
(JSC::ArithProfile::observedBinaryNumberNumber):
(JSC::ArithProfile::lhsObservedType const):
(JSC::ArithProfile::rhsObservedType const):
(JSC::ArithProfile::bits const):
Make ObservedType and ArithProfile constexpr-friendly.
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
Make several ASSERTs to STATIC_ASSERTs. Remove some unnecessary checks.
* llint/LLIntOffsetsExtractor.cpp:
* llint/LowLevelInterpreter.asm:
Remove unused constant values. Use constexpr more and more aggressively.
* parser/ResultType.h:
(JSC::ResultType::ResultType):
(JSC::ResultType::isInt32 const):
(JSC::ResultType::definitelyIsNumber const):
(JSC::ResultType::definitelyIsString const):
(JSC::ResultType::definitelyIsBoolean const):
(JSC::ResultType::definitelyIsBigInt const):
(JSC::ResultType::mightBeNumber const):
(JSC::ResultType::isNotNumber const):
(JSC::ResultType::mightBeBigInt const):
(JSC::ResultType::isNotBigInt const):
(JSC::ResultType::nullType):
(JSC::ResultType::booleanType):
(JSC::ResultType::numberType):
(JSC::ResultType::numberTypeIsInt32):
(JSC::ResultType::stringOrNumberType):
(JSC::ResultType::addResultType):
(JSC::ResultType::stringType):
(JSC::ResultType::bigIntType):
(JSC::ResultType::unknownType):
(JSC::ResultType::forAdd):
(JSC::ResultType::forLogicalOp):
(JSC::ResultType::forBitOp):
(JSC::ResultType::bits const):
Make ResultType constexpr-friendly.
* runtime/JSCJSValue.h:
Use offsetof instead of OBJECT_OFFSETOF. It is OK since EncodedValueDescriptor is POD.
This change makes TagOffset and PayloadOffset macros constexpr-friendly while OBJECT_OFFSETOF
cannot be used in constexpr since it uses reinterpret_cast.
2018-10-17 Keith Miller <keith_miller@apple.com>
Unreviewed revert Fujii's revert in r237214 with new WinCairo build fix.
2018-10-16 Mark Lam <mark.lam@apple.com>
GetIndexedPropertyStorage can GC.
https://bugs.webkit.org/show_bug.cgi?id=190625
<rdar://problem/45309366>
Reviewed by Saam Barati.
This is because if the ArrayMode type is String, the DFG and FTL will be emitting
a call to operationResolveRope, and operationResolveRope can GC. This patch
updates doesGC() to reflect this.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
2018-10-16 Fujii Hironori <Hironori.Fujii@sony.com>
Unreviewed, rolling out r237188, r237189, and r237197.
It breaks WinCairo Debug builds and Release LayoutTests
Reverted changesets:
https://bugs.webkit.org/show_bug.cgi?id=189708
https://trac.webkit.org/changeset/237188
"Unreviewed, forgot to add untracked files."
https://trac.webkit.org/changeset/237189
"isASTErroneous in offlineasm should de-macroify before
looking for Errors"
https://bugs.webkit.org/show_bug.cgi?id=190634
https://trac.webkit.org/changeset/237197
2018-10-16 Devin Rousso <drousso@apple.com>
Web Inspector: Canvas: capture previously saved states and add them to the recording payload
https://bugs.webkit.org/show_bug.cgi?id=190473
Reviewed by Joseph Pecoraro.
* inspector/protocol/Recording.json:
Add `states` key to `InitialState` object.
2018-10-16 Keith Miller <keith_miller@apple.com>
isASTErroneous in offlineasm should de-macroify before looking for Errors
https://bugs.webkit.org/show_bug.cgi?id=190634
Reviewed by Mark Lam.
If a macro isn't usable in a configuration it might still cause us to
think the ast is invalid. This change runs the de-macroifier before
looking for errors.
Also, it adds a missing include to Printer.h.
* assembler/Printer.h:
* offlineasm/settings.rb:
2018-10-16 Justin Michaud <justin_michaud@apple.com>
Implement feature flag and bindings for CSS Painting API
https://bugs.webkit.org/show_bug.cgi?id=190237
Reviewed by Ryosuke Niwa.
* Configurations/FeatureDefines.xcconfig:
2018-10-16 Keith Miller <keith_miller@apple.com>
Unreviewed, forgot to add untracked files.
* llint/LLIntSettingsExtractor.cpp: Added.
(main):
* offlineasm/generate_settings_extractor.rb: Added.
2018-10-16 Keith Miller <keith_miller@apple.com>
Unreviewed, reland https://bugs.webkit.org/show_bug.cgi?id=189708 with build fix.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* llint/LLIntOffsetsExtractor.cpp:
(JSC::LLIntOffsetsExtractor::dummy):
* offlineasm/generate_offset_extractor.rb:
* offlineasm/offsets.rb:
* offlineasm/settings.rb:
2018-10-16 Keith Miller <keith_miller@apple.com>
Unreviewed, add missing include.
* runtime/BasicBlockLocation.h:
2018-10-15 Keith Miller <keith_miller@apple.com>
Support arm64 CPUs with a 32-bit address space
https://bugs.webkit.org/show_bug.cgi?id=190273
Reviewed by Michael Saboff.
This patch adds support for arm64_32 in the LLInt. In order to
make this work we needed to add a new type that reflects the size
of a cpu register. This type is called CPURegister or UCPURegister
for the unsigned version. Most places that used void* or intptr_t
to refer to a register have been changed to use this new type.
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/ARM64Assembler.h:
(JSC::isInt):
(JSC::is4ByteAligned):
(JSC::PairPostIndex::PairPostIndex):
(JSC::PairPreIndex::PairPreIndex):
(JSC::ARM64Assembler::readPointer):
(JSC::ARM64Assembler::readCallTarget):
(JSC::ARM64Assembler::computeJumpType):
(JSC::ARM64Assembler::linkCompareAndBranch):
(JSC::ARM64Assembler::linkConditionalBranch):
(JSC::ARM64Assembler::linkTestAndBranch):
(JSC::ARM64Assembler::loadRegisterLiteral):
(JSC::ARM64Assembler::loadStoreRegisterPairPostIndex):
(JSC::ARM64Assembler::loadStoreRegisterPairPreIndex):
(JSC::ARM64Assembler::loadStoreRegisterPairOffset):
(JSC::ARM64Assembler::loadStoreRegisterPairNonTemporal):
(JSC::isInt7): Deleted.
(JSC::isInt11): Deleted.
* assembler/CPU.h:
(JSC::isAddress64Bit):
(JSC::isAddress32Bit):
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::shouldBlind):
* assembler/MacroAssemblerARM64.cpp:
(JSC::MacroAssemblerARM64::collectCPUFeatures):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::load):
(JSC::MacroAssemblerARM64::store):
(JSC::MacroAssemblerARM64::isInIntRange): Deleted.
* assembler/Printer.h:
* assembler/ProbeContext.h:
(JSC::Probe::CPUState::gpr):
(JSC::Probe::CPUState::spr):
(JSC::Probe::Context::gpr):
(JSC::Probe::Context::spr):
* b3/B3ConstPtrValue.h:
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::isArgValidForRep):
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::stackSlot const):
(JSC::B3::Air::Arg::special const):
* b3/air/testair.cpp:
* b3/testb3.cpp:
(JSC::B3::testStoreConstantPtr):
(JSC::B3::testInterpreter):
(JSC::B3::testAddShl32):
(JSC::B3::testLoadBaseIndexShift32):
* bindings/ScriptFunctionCall.cpp:
(Deprecated::ScriptCallArgumentHandler::appendArgument):
* bindings/ScriptFunctionCall.h:
* bytecode/CodeBlock.cpp:
(JSC::roundCalleeSaveSpaceAsVirtualRegisters):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::restoreCalleeSavesFor):
(JSC::DFG::saveCalleeSavesFor):
(JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
(JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* disassembler/UDis86Disassembler.cpp:
(JSC::tryToDisassembleWithUDis86):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileWeakMapGet):
* heap/MachineStackMarker.cpp:
(JSC::copyMemory):
* interpreter/CallFrame.h:
(JSC::ExecState::returnPC const):
(JSC::ExecState::hasReturnPC const):
(JSC::ExecState::clearReturnPC):
(JSC::ExecState::returnPCOffset):
(JSC::ExecState::isGlobalExec const):
(JSC::ExecState::setReturnPC):
* interpreter/CalleeBits.h:
(JSC::CalleeBits::boxWasm):
(JSC::CalleeBits::isWasm const):
(JSC::CalleeBits::asWasmCallee const):
* interpreter/Interpreter.cpp:
(JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
* interpreter/VMEntryRecord.h:
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::clearStackFrame):
* jit/RegisterAtOffset.h:
(JSC::RegisterAtOffset::offsetAsIndex const):
* jit/RegisterAtOffsetList.cpp:
(JSC::RegisterAtOffsetList::RegisterAtOffsetList):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LLIntOfflineAsmConfig.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter64.asm:
* offlineasm/arm64.rb:
* offlineasm/asm.rb:
* offlineasm/ast.rb:
* offlineasm/backends.rb:
* offlineasm/parser.rb:
* offlineasm/x86.rb:
* runtime/BasicBlockLocation.cpp:
(JSC::BasicBlockLocation::dumpData const):
(JSC::BasicBlockLocation::emitExecuteCode const):
* runtime/BasicBlockLocation.h:
* runtime/HasOwnPropertyCache.h:
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::inplaceMultiplyAdd):
(JSC::JSBigInt::digitDiv):
* runtime/JSBigInt.h:
* runtime/JSObject.h:
* runtime/Options.cpp:
(JSC::jitEnabledByDefault):
* runtime/Options.h:
* runtime/RegExp.cpp:
(JSC::RegExp::printTraceData):
* runtime/SamplingProfiler.cpp:
(JSC::CFrameWalker::walk):
* runtime/SlowPathReturnType.h:
(JSC::encodeResult):
(JSC::decodeResult):
* tools/SigillCrashAnalyzer.cpp:
(JSC::SigillCrashAnalyzer::dumpCodeBlock):
2018-10-15 Justin Fan <justin_fan@apple.com>
Add WebGPU 2018 feature flag and experimental feature flag
https://bugs.webkit.org/show_bug.cgi?id=190509
Reviewed by Dean Jackson.
Re-add ENABLE_WEBGPU, an experimental feature flag, and a RuntimeEnabledFeature
for the 2018 WebGPU prototype.
* Configurations/FeatureDefines.xcconfig:
2018-10-15 Timothy Hatcher <timothy@apple.com>
Add support for prefers-color-scheme media query
https://bugs.webkit.org/show_bug.cgi?id=190499
rdar://problem/45212025
Reviewed by Dean Jackson.
* Configurations/FeatureDefines.xcconfig: Added ENABLE_DARK_MODE_CSS.
2018-10-15 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r237084, r237088, r237098, and
r237114.
https://bugs.webkit.org/show_bug.cgi?id=190602
Breaks internal builds. (Requested by ryanhaddad on #webkit).
Reverted changesets:
"Separate configuration extraction from offset extraction"
https://bugs.webkit.org/show_bug.cgi?id=189708
https://trac.webkit.org/changeset/237084
"Gardening: Build fix after r237084."
https://bugs.webkit.org/show_bug.cgi?id=189708
https://trac.webkit.org/changeset/237088
"Gardening: Build fix after r237084."
https://bugs.webkit.org/show_bug.cgi?id=189708
https://trac.webkit.org/changeset/237098
"REGRESSION (r237084): JavaScriptCore fails to build on Linux"
https://trac.webkit.org/changeset/237114
2018-10-15 Keith Miller <keith_miller@apple.com>
BytecodeDumper should print all switch labels
https://bugs.webkit.org/show_bug.cgi?id=190596
Reviewed by Saam Barati.
Right now the bytecode dumper only prints the default target not any of the
non-default targets.
* bytecode/BytecodeDumper.cpp:
(JSC::BytecodeDumper<Block>::dumpBytecode):
2018-10-15 Saam barati <sbarati@apple.com>
Emit fjcvtzs on ARM64E on Darwin
https://bugs.webkit.org/show_bug.cgi?id=184023
Reviewed by Yusuke Suzuki and Filip Pizlo.
ARMv8.3 introduced the fjcvtzs instruction which does double->int32
conversion using the semantics defined by JavaScript:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0801g/hko1477562192868.html
This patch teaches JSC to use that instruction when possible.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::fjcvtzs):
(JSC::ARM64Assembler::fjcvtzsInsn):
* assembler/MacroAssemblerARM64.cpp:
(JSC::MacroAssemblerARM64::collectCPUFeatures):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::supportsDoubleToInt32ConversionUsingJavaScriptSemantics):
(JSC::MacroAssemblerARM64::convertDoubleToInt32UsingJavaScriptSemantics):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueToInt32):
* disassembler/ARM64/A64DOpcode.cpp:
* disassembler/ARM64/A64DOpcode.h:
(JSC::ARM64Disassembler::A64DOpcode::appendInstructionName):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::doubleToInt32):
* jit/JITRightShiftGenerator.cpp:
(JSC::JITRightShiftGenerator::generateFastPath):
* runtime/MathCommon.h:
(JSC::toInt32):
2018-10-15 Saam Barati <sbarati@apple.com>
JSArray::shiftCountWithArrayStorage is wrong when an array has holes
https://bugs.webkit.org/show_bug.cgi?id=190262
<rdar://problem/44986241>
Reviewed by Mark Lam.
We would take the fast path for shiftCountWithArrayStorage when the array
hasHoles(). However, the code for this was wrong. It'd incorrectly update
ArrayStorage::m_numValuesInVector. Since the hasHoles() for ArrayStorage
path is never taken in JetStream 2, this patch just removes that from
the fast path. Instead, we just fallback to the slow path when hasHoles().
If we find evidence that this matters for real use cases, we can
figure out a way to make the fast path work.
* runtime/JSArray.cpp:
(JSC::JSArray::shiftCountWithArrayStorage):
2018-10-15 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r237054.
https://bugs.webkit.org/show_bug.cgi?id=190593
"this regressed JetStream 2 by 6% on iOS" (Requested by
saamyjoon on #webkit).
Reverted changeset:
"[JSC] JSC should have "parseFunction" to optimize Function
constructor"
https://bugs.webkit.org/show_bug.cgi?id=190340
https://trac.webkit.org/changeset/237054
2018-10-14 David Kilzer <ddkilzer@apple.com>
REGRESSION (r237084): JavaScriptCore fails to build on Linux
<https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10949>
* llint/LLIntSettingsExtractor.cpp: Attempt to fix build by
including <stdio.h>.
2018-10-15 Alex Christensen <achristensen@webkit.org>
Shrink more enum classes
https://bugs.webkit.org/show_bug.cgi?id=190540
Reviewed by Chris Dumez.
* runtime/ConsoleTypes.h:
2018-10-15 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Disable DOMJIT on 32bit architecture
https://bugs.webkit.org/show_bug.cgi?id=190387
Reviewed by Mark Lam.
We disable DOMJIT on 32bit architecture due to exhaustion of registers.
* runtime/Options.h:
2018-10-15 Alex Christensen <achristensen@webkit.org>
Include EnumTraits.h less
https://bugs.webkit.org/show_bug.cgi?id=190535
Reviewed by Chris Dumez.
* runtime/ConsoleTypes.h:
2018-10-14 Mark Lam <mark.lam@apple.com>
Gardening: Build fix after r237084.
https://bugs.webkit.org/show_bug.cgi?id=189708
Unreviewd.
* llint/LLIntOffsetsExtractor.cpp:
2018-10-14 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Remove Option::useAsyncIterator
https://bugs.webkit.org/show_bug.cgi?id=190567
Reviewed by Saam Barati.
Async iterator is enabled by default at 2017-08-09. It is already shipped in several releases,
and we can think that it is already mature. Let's drop the option `Option::useAsyncIterator`.
* Configurations/FeatureDefines.xcconfig:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
(JSC::BytecodeGenerator::emitNewFunction):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionMetadata):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseForStatement):
(JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseProperty):
(JSC::Parser<LexerType>::parseAsyncFunctionExpression):
* runtime/Options.h:
2018-10-14 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Remove Options::useObjectRestSpread
https://bugs.webkit.org/show_bug.cgi?id=190568
Reviewed by Saam Barati.
Options::useObjectRestSpread is enabled by default at 2017-06-27. It is already shipped in several releases,
and we can think that it is mature. Let's drop Options::useObjectRestSpread() flag.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::Parser):
(JSC::Parser<LexerType>::parseDestructuringPattern):
(JSC::Parser<LexerType>::parseProperty):
* parser/Parser.h:
* runtime/Options.h:
2018-10-13 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] JSON.stringify can accept call-with-no-arguments
https://bugs.webkit.org/show_bug.cgi?id=190343
Reviewed by Mark Lam.
JSON.stringify can accept `JSON.stringify()` call (call-with-no-arguments) according to the spec[1].
Instead of throwing an error, we should take the first argument as `undefined` if it is not given.
[1]: https://tc39.github.io/ecma262/#sec-json.stringify
* runtime/JSONObject.cpp:
(JSC::JSONProtoFuncStringify):
2018-10-12 Tadeu Zagallo <tzagallo@apple.com>
Gardening: Build fix after r237084.
https://bugs.webkit.org/show_bug.cgi?id=189708
Unreviewd.
* JavaScriptCore.xcodeproj/project.pbxproj:
2018-10-12 Tadeu Zagallo <tzagallo@apple.com>
Separate configuration extraction from offset extraction
https://bugs.webkit.org/show_bug.cgi?id=189708
Reviewed by Keith Miller.
Instead of generating a file with all offsets for every combination of
configurations, we first generate a file with only the configuration
indices and pass that to the offset extractor. The offset extractor then
only generates the offsets for valid configurations
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* llint/LLIntOffsetsExtractor.cpp:
(JSC::LLIntOffsetsExtractor::dummy):
* llint/LLIntSettingsExtractor.cpp: Added.
(main):
* offlineasm/generate_offset_extractor.rb:
* offlineasm/generate_settings_extractor.rb: Added.
* offlineasm/offsets.rb:
* offlineasm/settings.rb:
2018-10-12 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r237063.
Caused layout test fast/dom/Window/window-postmessage-clone-
deep-array.html to fail on macOS and iOS Debug bots.
Reverted changeset:
"[JSC] Remove gcc warnings on mips and armv7"
https://bugs.webkit.org/show_bug.cgi?id=188598
https://trac.webkit.org/changeset/237063
2018-10-11 Guillaume Emont <guijemont@igalia.com>
[JSC] Remove gcc warnings on mips and armv7
https://bugs.webkit.org/show_bug.cgi?id=188598
Reviewed by Mark Lam.
Fix many gcc/clang warnings that are false positives, mostly alignment
issues.
* assembler/MacroAssemblerPrinter.cpp:
(JSC::Printer::printMemory):
Use bitwise_cast instead of reinterpret_cast.
* assembler/testmasm.cpp:
(JSC::floatOperands):
marked as potentially unused as it is not used on all platforms.
(JSC::testProbeModifiesStackValues):
modifiedFlags is not used on mips, so don't declare it.
* bytecode/CodeBlock.h:
Make ScriptExecutable::prepareForExecution() return an
std::optional<Exception*> instead of a JSObject*.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::executeProgram):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
(JSC::Interpreter::prepareForRepeatCall):
(JSC::Interpreter::execute):
(JSC::Interpreter::executeModuleProgram):
Update calling code for the prototype change of
ScriptExecutable::prepareForExecution().
* jit/JITOperations.cpp: Same as for Interpreter.cpp.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setUpCall): Same as for Interpreter.cpp.
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::dataStorage):
Use bitwise_cast instead of reinterpret_cast.
* runtime/ScriptExecutable.cpp:
* runtime/ScriptExecutable.h:
Make ScriptExecutable::prepareForExecution() return an
std::optional<Exception*> instead of a JSObject*.
* tools/JSDollarVM.cpp:
(JSC::codeBlockFromArg): Use bitwise_cast instead of reinterpret_cast.
2018-10-11 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Use currentStackPointer more
https://bugs.webkit.org/show_bug.cgi?id=190503
Reviewed by Saam Barati.
* runtime/VM.cpp:
(JSC::VM::committedStackByteCount):
2018-10-08 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] JSC should have "parseFunction" to optimize Function constructor
https://bugs.webkit.org/show_bug.cgi?id=190340
Reviewed by Mark Lam.
The current Function constructor is suboptimal. We parse the piece of the same code three times to meet
the spec requirement. (1) check parameters syntax, (2) check body syntax, and (3) parse the entire function.
And to parse 1-3 correctly, we create two strings, the parameters and the entire function. This operation
is really costly and ideally we should meet the above requirement by the one time parsing.
To meet the above requirement, we add a special function for Parser, parseSingleFunction. This function
takes `std::optional<int> functionConstructorParametersEndPosition` and check this end position is correct in the parser.
For example, if we run the code,
Function('/*', '*/){')
According to the spec, this should produce '/*' parameter string and '*/){' body string. And parameter
string should be syntax-checked by the parser, and raise the error since it is incorrect. Instead of doing
that, in our implementation, we first create the entire string.
function anonymous(/*) {
*/){
}
And we parse it. At that time, we also pass the end position of the parameters to the parser. In the above case,
the position of the `function anonymous(/*)' <> is passed. And in the parser, we check that the last token
offset of the parameters is the given end position. This check allows us to raise the error correctly to the
above example while we parse the entire function only once. And we do not need to create two strings too.
This improves the performance of the Function constructor significantly. And web-tooling-benchmark/uglify-js is
significantly sped up (28.2%).
Before:
uglify-js: 2.94 runs/s
After:
uglify-js: 3.77 runs/s
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
* bytecode/UnlinkedFunctionExecutable.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseSingleFunction):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parsePropertyMethod):
(JSC::Parser<LexerType>::parseGetterSetter):
(JSC::Parser<LexerType>::parseFunctionExpression):
(JSC::Parser<LexerType>::parseAsyncFunctionExpression):
(JSC::Parser<LexerType>::parseArrowFunctionExpression):
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
(JSC::parse):
(JSC::parseFunctionForFunctionConstructor):
* parser/ParserModes.h:
* parser/ParserTokens.h:
(JSC::JSTextPosition::JSTextPosition):
(JSC::JSTokenLocation::JSTokenLocation): Deleted.
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::SourceCodeKey):
(JSC::SourceCodeKey::operator== const):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
* runtime/CodeCache.h:
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/FunctionExecutable.h:
2018-10-11 Ross Kirsling <ross.kirsling@sony.com>
Fix non-existent define `CPU(JSVALUE64)`
https://bugs.webkit.org/show_bug.cgi?id=190479
Reviewed by Yusuke Suzuki.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsImpl):
Correct CPU(JSVALUE64) to USE(JSVALUE64).
2018-10-11 Keith Rollin <krollin@apple.com>
CURRENT_ARCH should not be used in Run Script phase.
https://bugs.webkit.org/show_bug.cgi?id=190407
<rdar://problem/45133556>
Reviewed by Alexey Proskuryakov.
CURRENT_ARCH is used in a number of Xcode Run Script phases. However,
CURRENT_ARCH is not well-defined during this phase (and may even have
the value "undefined") since this phase is run just once per build
rather than once per supported architecture. Migrate away from
CURRENT_ARCH in favor of ARCHS, either by iterating over ARCHS and
performing an operation for each value, or by picking the first entry
in ARCHS and using that as a representative value.
* JavaScriptCore.xcodeproj/project.pbxproj: Store
LLIntDesiredOffsets.h into a directory with a name based on ARCHS
rather than CURRENT_ARCH.
2018-10-10 Mark Lam <mark.lam@apple.com>
Changes towards allowing use of the ASAN detect_stack_use_after_return option.
https://bugs.webkit.org/show_bug.cgi?id=190405
<rdar://problem/45131464>
Reviewed by Michael Saboff.
The ASAN detect_stack_use_after_return option checks for use of stack variables
after they have been freed. It does this by allocating relevant stack variables
in heap memory (instead of on the stack) if the code ever takes the address of
those stack variables. Unfortunately, this is a common idiom that we use to
compute the approximate stack pointer value. As a result, on such ASAN runs, the
computed approximate stack pointer value will point into the heap instead of the
stack. This breaks the VM's expectations and wreaks havoc.
To fix this, we use the newly introduced WTF::currentStackPointer() instead of
taking the address of stack variables.
We also need to enhance ExceptionScopes to be able to work with ASAN
detect_stack_use_after_return which will allocated the scope in the heap. We
work around this by passing the current stack pointer of the instantiating calling
frame into the scope constructor, and using that for the position check in
~ThrowScope() instead.
The above is only a start towards enabling ASAN detect_stack_use_after_return on
the VM. There are still other issues to be resolved before we can run with this
ASAN option.
* runtime/CatchScope.h:
* runtime/ExceptionEventLocation.h:
(JSC::ExceptionEventLocation::ExceptionEventLocation):
* runtime/ExceptionScope.h:
(JSC::ExceptionScope::stackPosition const):
* runtime/JSLock.cpp:
(JSC::JSLock::didAcquireLock):
* runtime/ThrowScope.cpp:
(JSC::ThrowScope::~ThrowScope):
* runtime/ThrowScope.h:
* runtime/VM.h:
(JSC::VM::needExceptionCheck const):
(JSC::VM::isSafeToRecurse const):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
* yarr/YarrPattern.cpp:
(JSC::Yarr::YarrPatternConstructor::isSafeToRecurse const):
2018-10-10 Devin Rousso <drousso@apple.com>
Web Inspector: create special Network waterfall for media events
https://bugs.webkit.org/show_bug.cgi?id=189773
<rdar://problem/44626605>
Reviewed by Joseph Pecoraro.
* inspector/protocol/DOM.json:
Add `didFireEvent` event that is fired when specific event listeners added by
`InspectorInstrumentation::addEventListenersToNode` are fired.
2018-10-10 Michael Saboff <msaboff@apple.com>
Increase executable memory pool from 64MB to 128MB for ARM64
https://bugs.webkit.org/show_bug.cgi?id=190453
Reviewed by Saam Barati.
* jit/ExecutableAllocator.cpp:
2018-10-10 Devin Rousso <drousso@apple.com>
Web Inspector: notify the frontend when a canvas has started recording via console.record
https://bugs.webkit.org/show_bug.cgi?id=190306
Reviewed by Brian Burg.
* inspector/protocol/Canvas.json:
Add `recordingStarted` event.
* inspector/protocol/Recording.json:
Add `Initiator` enum for determining who started the recording.
2018-10-10 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Rename createXXX to tryCreateXXX if it can return RefPtr
https://bugs.webkit.org/show_bug.cgi?id=190429
Reviewed by Saam Barati.
Some createXXX functions can fail. But sometimes the caller does not perform error checking.
To make it explicit that these functions can fail, we rename these functions from createXXX
to tryCreateXXX. In this patch, we focus on non-JS-managed factory functions. If the factory
function does not fail, it should return Ref<>. Otherwise, it should be named as tryCreateXXX
and it should return RefPtr<>.
This patch mainly focuses on TypedArray factory functions. Previously, these functions are
`RefPtr<XXXArray> create(...)`. This patch changes them to `RefPtr<XXXArray> tryCreate(...)`.
And we also introduce `Ref<XXXArray> create(...)` function which internally performs
RELEASE_ASSERT on the result of `tryCreate(...)`.
And we also convert OpaqueJSString::create to OpaqueJSString::tryCreate since it can fail.
This change actually finds one place which does not perform any null checkings while it uses
`RefPtr<> create(...)` function.
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::getOwnPropertySlot):
(JSC::JSCallbackObject<Parent>::put):
(JSC::JSCallbackObject<Parent>::putByIndex):
(JSC::JSCallbackObject<Parent>::deleteProperty):
(JSC::JSCallbackObject<Parent>::callbackGetter):
* API/JSClassRef.h:
(StaticValueEntry::StaticValueEntry):
* API/JSContext.mm:
(-[JSContext evaluateScript:withSourceURL:]):
(-[JSContext setName:]):
* API/JSContextRef.cpp:
(JSGlobalContextCopyName):
(JSContextCreateBacktrace):
* API/JSObjectRef.cpp:
(JSObjectCopyPropertyNames):
* API/JSScriptRef.cpp:
* API/JSStringRef.cpp:
(JSStringCreateWithCharactersNoCopy):
* API/JSValue.mm:
(+[JSValue valueWithNewRegularExpressionFromPattern:flags:inContext:]):
(+[JSValue valueWithNewErrorFromMessage:inContext:]):
(+[JSValue valueWithNewSymbolFromDescription:inContext:]):
(performPropertyOperation):
(-[JSValue invokeMethod:withArguments:]):
(containerValueToObject):
(objectToValueWithoutCopy):
(objectToValue):
* API/JSValueRef.cpp:
(JSValueCreateJSONString):
(JSValueToStringCopy):
* API/OpaqueJSString.cpp:
(OpaqueJSString::tryCreate):
(OpaqueJSString::create): Deleted.
* API/OpaqueJSString.h:
* API/glib/JSCContext.cpp:
(evaluateScriptInContext):
* API/glib/JSCValue.cpp:
(jsc_value_new_string_from_bytes):
* ftl/FTLLazySlowPath.h:
(JSC::FTL::LazySlowPath::createGenerator):
* ftl/FTLLazySlowPathCall.h:
(JSC::FTL::createLazyCallGenerator):
* ftl/FTLOSRExit.cpp:
(JSC::FTL::OSRExitDescriptor::emitOSRExit):
(JSC::FTL::OSRExitDescriptor::emitOSRExitLater):
(JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
* ftl/FTLOSRExit.h:
* ftl/FTLPatchpointExceptionHandle.cpp:
(JSC::FTL::PatchpointExceptionHandle::create):
(JSC::FTL::PatchpointExceptionHandle::createHandle):
* ftl/FTLPatchpointExceptionHandle.h:
* heap/EdenGCActivityCallback.h:
(JSC::GCActivityCallback::tryCreateEdenTimer):
(JSC::GCActivityCallback::createEdenTimer): Deleted.
* heap/FullGCActivityCallback.h:
(JSC::GCActivityCallback::tryCreateFullTimer):
(JSC::GCActivityCallback::createFullTimer): Deleted.
* heap/GCActivityCallback.h:
* heap/Heap.cpp:
(JSC::Heap::Heap):
* inspector/AsyncStackTrace.cpp:
(Inspector::AsyncStackTrace::create):
* inspector/AsyncStackTrace.h:
* jsc.cpp:
(fillBufferWithContentsOfFile):
* runtime/ArrayBuffer.h:
* runtime/GenericTypedArrayView.h:
* runtime/GenericTypedArrayViewInlines.h:
(JSC::GenericTypedArrayView<Adaptor>::create):
(JSC::GenericTypedArrayView<Adaptor>::tryCreate):
(JSC::GenericTypedArrayView<Adaptor>::createUninitialized):
(JSC::GenericTypedArrayView<Adaptor>::tryCreateUninitialized):
(JSC::GenericTypedArrayView<Adaptor>::subarray const):
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::possiblySharedImpl):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::possiblySharedTypedImpl):
(JSC::JSGenericTypedArrayView<Adaptor>::unsharedTypedImpl):
* wasm/WasmMemory.cpp:
(JSC::Wasm::Memory::create):
(JSC::Wasm::Memory::tryCreate):
* wasm/WasmMemory.h:
* wasm/WasmTable.cpp:
(JSC::Wasm::Table::tryCreate):
(JSC::Wasm::Table::create): Deleted.
* wasm/WasmTable.h:
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::create):
* wasm/js/JSWebAssemblyMemory.cpp:
(JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::constructJSWebAssemblyMemory):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
* wasm/js/WebAssemblyTableConstructor.cpp:
(JSC::constructJSWebAssemblyTable):
2018-10-09 Devin Rousso <drousso@apple.com>
Web Inspector: show redirect requests in Network and Timelines tabs
https://bugs.webkit.org/show_bug.cgi?id=150005
<rdar://problem/5378164>
Reviewed by Joseph Pecoraro.
* inspector/protocol/Network.json:
Add missing fields to `ResourceTiming`.
2018-10-09 Claudio Saavedra <csaavedra@igalia.com>
[WPE] Explicitly link against gmodule where used
https://bugs.webkit.org/show_bug.cgi?id=190398
Reviewed by Michael Catanzaro.
* PlatformWPE.cmake:
2018-10-08 Justin Fan <justin_fan@apple.com>
WebGPU: Rename old WebGPU prototype to WebMetal
https://bugs.webkit.org/show_bug.cgi?id=190325
<rdar://problem/44990443>
Reviewed by Dean Jackson.
Rename WebGPU prototype files to WebMetal in preparation for implementing the new (Oct 2018) WebGPU interface.
* Configurations/FeatureDefines.xcconfig:
* inspector/protocol/Canvas.json:
* inspector/scripts/codegen/generator.py:
2018-10-08 Aditya Keerthi <akeerthi@apple.com>
Make <input type=color> a runtime enabled (on-by-default) feature
https://bugs.webkit.org/show_bug.cgi?id=189162
Reviewed by Wenson Hsieh and Tim Horton.
* Configurations/FeatureDefines.xcconfig:
2018-10-08 Devin Rousso <drousso@apple.com>
Web Inspector: group media network entries by the node that triggered the request
https://bugs.webkit.org/show_bug.cgi?id=189606
<rdar://problem/44438527>
Reviewed by Brian Burg.
* inspector/protocol/Network.json:
Add an optional `nodeId` field to the `Initiator` object that is set it is possible to
determine which ancestor node triggered the load. It may not correspond directly to the node
with the href/src, as that url may only be used by an ancestor for loading.
2018-10-07 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC][Linux] Use non-truncated name for JIT workers in Linux
https://bugs.webkit.org/show_bug.cgi?id=190339
Reviewed by Mark Lam.
The current thread names are meaningless in Linux environment. We do not want to
have truncated name in Linux: we want to have clear name in Linux. Instead, we
should have the name for Linux separately from the name used in the non-Linux
environments. This patch adds FTLWorker, DFGWorker, and JITWorker names for
Linux environment.
* dfg/DFGWorklist.cpp:
(JSC::DFG::createWorklistName):
(JSC::DFG::Worklist::Worklist):
(JSC::DFG::Worklist::create):
(JSC::DFG::ensureGlobalDFGWorklist):
(JSC::DFG::ensureGlobalFTLWorklist):
* dfg/DFGWorklist.h:
* jit/JITWorklist.cpp:
2018-10-07 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Name Heap threads
https://bugs.webkit.org/show_bug.cgi?id=190337
Reviewed by Mark Lam.
Name heap threads as "Heap Helper Thread". In Linux, we name it "HeapHelper" since
Linux does not accept the name longer than 15. We do not want to use the short name
for non-Linux environment. And we want to have clear name in Linux: truncated name
is not good. So, having the two names is the only way.
* heap/HeapHelperPool.cpp:
(JSC::heapHelperPool):
2018-10-07 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Avoid creating ProgramExecutable in checkSyntax
https://bugs.webkit.org/show_bug.cgi?id=190332
Reviewed by Mark Lam.
uglify-js in web-tooling-benchmark executes massive number of Function constructor calls.
In Function constructor code, we perform checkSyntax for body and parameters. So fast checkSyntax
is important when the performance of Function constructor matters. Current checkSyntax code
unnecessarily allocates ProgramExecutable. This patch removes this allocation and improves
the benchmark score slightly.
Before:
uglify-js: 2.87 runs/s
After:
uglify-js: 2.94 runs/s
* runtime/Completion.cpp:
(JSC::checkSyntaxInternal):
(JSC::checkSyntax):
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::checkSyntax): Deleted.
* runtime/ProgramExecutable.h:
2018-10-06 Caio Lima <ticaiolima@gmail.com>
[ESNext][BigInt] Implement support for "|"
https://bugs.webkit.org/show_bug.cgi?id=186229
Reviewed by Yusuke Suzuki.
This patch is introducing support for BigInt into bitwise "or" operator.
In addition, we are also introducing 2 new DFG nodes, named "ArithBitOr" and
"ValueBitOr", to replace "BitOr" node. The idea is to follow the
difference that we make on Arith<op> and Value<op>, where ArithBitOr
handles cases when the operands are Int32 and ValueBitOr handles
the remaining cases.
We are also changing op_bitor to use ValueProfile. We are using
ValueProfile during DFG generation to emit "ArithBitOr" when
outcome prediction is Int32.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::arithProfileForPC):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitBinaryOp):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo):
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
(JSC::DFG::bitwiseOp):
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueBitwiseOp):
(JSC::DFG::SpeculativeJIT::compileBitwiseOp):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::bitOp):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileValueBitOr):
(JSC::FTL::DFG::LowerDFGToB3::compileArithBitOr):
(JSC::FTL::DFG::LowerDFGToB3::compileBitOr): Deleted.
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_bitor):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::bitwiseAnd):
(JSC::JSBigInt::bitwiseOr):
(JSC::JSBigInt::absoluteBitwiseOp):
(JSC::JSBigInt::absoluteAddOne):
* runtime/JSBigInt.h:
2018-10-05 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Use new extra memory reporting in SparseArrayMap
https://bugs.webkit.org/show_bug.cgi?id=190278
Reviewed by Keith Miller.
This patch switches the extra memory reporting mechanism from deprecatedReportExtraMemory
to reportExtraMemoryAllocated & reportExtraMemoryVisited in SparseArrayMap.
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::add):
(JSC::SparseArrayValueMap::visitChildren):
2018-10-05 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC][Linux] Support Perf JITDump logging
https://bugs.webkit.org/show_bug.cgi?id=189893
Reviewed by Mark Lam.
This patch adds Linux `perf` command's JIT Dump support. It allows JSC to tell perf about JIT code information.
We add a command line option, `--logJITCodeForPerf`, which dumps `jit-%pid.dump` in the current directory.
By using this dump and perf.data output, we can annotate JIT code with profiling information.
$ echo "(function f() { var s = 0; for (var i = 0; i < 1000000000; i++) { s += i; } return s; })();" > test.js
$ perf record -k mono ../../WebKitBuild/perf/Release/bin/jsc test.js --logJITCodeForPerf=true
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.182 MB perf.data (4346 samples) ]
$ perf inject --jit -i perf.data -o perf.jit.data
$ perf report -i perf.jit.data
* Sources.txt:
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::finalizeCodeWithDisassemblyImpl):
* assembler/LinkBuffer.h:
(JSC::LinkBuffer::finalizeCodeWithDisassembly):
* assembler/PerfLog.cpp: Added.
(JSC::PerfLog::singleton):
(JSC::generateTimestamp):
(JSC::getCurrentThreadID):
(JSC::PerfLog::PerfLog):
(JSC::PerfLog::write):
(JSC::PerfLog::flush):
(JSC::PerfLog::log):
* assembler/PerfLog.h: Added.
* jit/ExecutableAllocator.cpp:
(JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
* runtime/Options.cpp:
(JSC::Options::isAvailable):
* runtime/Options.h:
2018-10-05 Mark Lam <mark.lam@apple.com>
Gardening: Build fix after r236880.
https://bugs.webkit.org/show_bug.cgi?id=190317
Unreviewed.
* jit/ExecutableAllocator.h:
2018-10-05 Mark Lam <mark.lam@apple.com>
performJITMemcpy() should handle the case when the executable allocator is not initialized yet.
https://bugs.webkit.org/show_bug.cgi?id=190317
<rdar://problem/45039398>
Reviewed by Saam Barati.
When SeparatedWXHeaps is in use, jitWriteThunkGenerator() will call performJITMemcpy()
to copy memory before the JIT fixed memory pool is initialize. Before r236864,
performJITMemcpy() would just do a memcpy in that case. We need to restore the
equivalent behavior.
* jit/ExecutableAllocator.cpp:
(JSC::isJITPC):
* jit/ExecutableAllocator.h:
(JSC::performJITMemcpy):
2018-10-05 Carlos Eduardo Ramalho <cadubentzen@gmail.com>
[WPE][JSC] Use Unified Sources for Platform-specific sources
https://bugs.webkit.org/show_bug.cgi?id=190300
Reviewed by Yusuke Suzuki.
Currently the GTK port already used Unified Sources with the same source files.
As WPE has conditional code using gmodule, we need to add GLIB_GMODULE_LIBRARIES
to the list of libraries to link with.
* PlatformWPE.cmake:
* SourcesWPE.txt: Added.
* shell/PlatformWPE.cmake:
2018-10-05 Mike Gorse <mgorse@alum.wpi.edu>
[GTK] build fails with python 3 if LANG and LC_TYPE are unset
https://bugs.webkit.org/show_bug.cgi?id=190258
Reviewed by Konstantin Tokarev.
* Scripts/cssmin.py: Set stdout to UTF-8 on python 3.
* Scripts/generateIntlCanonicalizeLanguage.py: Open files with
encoding=UTF-8 on Python 3.
* yarr/generateYarrCanonicalizeUnicode: Ditto.
* yarr/generateYarrUnicodePropertyTables.py: Ditto.
2018-10-04 Mark Lam <mark.lam@apple.com>
Move start/EndOfFixedExecutableMemoryPool pointers into the FixedVMPoolExecutableAllocator object.
https://bugs.webkit.org/show_bug.cgi?id=190295
<rdar://problem/19197193>
Reviewed by Saam Barati.
This allows us to use the tagging logic already baked into MacroAssemblerCodePtr
instead of needing to use our own custom version here.
* jit/ExecutableAllocator.cpp:
(JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
(JSC::FixedVMPoolExecutableAllocator::memoryStart):
(JSC::FixedVMPoolExecutableAllocator::memoryEnd):
(JSC::FixedVMPoolExecutableAllocator::isJITPC):
(JSC::ExecutableAllocator::allocate):
(JSC::startOfFixedExecutableMemoryPoolImpl):
(JSC::endOfFixedExecutableMemoryPoolImpl):
(JSC::isJITPC):
* jit/ExecutableAllocator.h:
2018-10-04 Mark Lam <mark.lam@apple.com>
Disable Options::useWebAssemblyFastMemory() on linux if ASAN signal handling is not disabled.
https://bugs.webkit.org/show_bug.cgi?id=190283
<rdar://problem/45015752>
Reviewed by Keith Miller.
* runtime/Options.cpp:
(JSC::Options::initialize):
* wasm/WasmFaultSignalHandler.cpp:
(JSC::Wasm::enableFastMemory):
2018-10-03 Ross Kirsling <ross.kirsling@sony.com>
[JSC] print() changes CRLF to CRCRLF on Windows
https://bugs.webkit.org/show_bug.cgi?id=190228
Reviewed by Mark Lam.
* jsc.cpp:
(main):
Ultimately, this is just the normal behavior of printf in text mode on Windows.
Since we're reading in files as binary, we need to be printing out as binary too
(just as we do in DumpRenderTree and ImageDiff.)
2018-10-03 Saam barati <sbarati@apple.com>
lowXYZ in FTLLower should always filter the type of the incoming edge
https://bugs.webkit.org/show_bug.cgi?id=189939
<rdar://problem/44407030>
Reviewed by Michael Saboff.
For example, the FTL may know more about data flow than AI in certain programs,
and it needs to inform AI of these data flow properties to appease the assertion
we have in AI that a node must perform type checks on its child nodes.
For example, consider this program:
```
bb#1
a: Phi // Let's say it has an Int32 result, so it goes into the int32 hash table in FTLLower
Branch(..., #2, #3)
bb#2
ArrayifyToStructure(Cell:@a) // This modifies @a to have the its previous type union the type of some structure set.
Jump(#3)
bb#3
c: Add(Int32:@something, Int32:@a)
```
When the Add node does lowInt32() for @a, FTL lower used to just grab it
from the int32 hash table without filtering the AbstractValue. However,
the parent node is asking for a type check to happen, so we must inform
AI of this "type check" if we want to appease the assertion that all nodes
perform type checks for their edges that semantically perform type checks.
This patch makes it so we filter the AbstractValue in the lowXYZ even
if FTLLower proved the value must be XYZ.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compilePhi):
(JSC::FTL::DFG::LowerDFGToB3::simulatedTypeCheck):
(JSC::FTL::DFG::LowerDFGToB3::lowInt32):
(JSC::FTL::DFG::LowerDFGToB3::lowCell):
(JSC::FTL::DFG::LowerDFGToB3::lowBoolean):
2018-10-03 Michael Saboff <msaboff@apple.com>
Command line jsc should report memory footprint in bytes
https://bugs.webkit.org/show_bug.cgi?id=190267
Reviewed by Mark Lam.
Change to leave the footprint values from the system unmodified.
* jsc.cpp:
(JSCMemoryFootprint::finishCreation):
2018-10-03 Mark Lam <mark.lam@apple.com>
Suppress unreachable code warning for LLIntAssembly.h code.
https://bugs.webkit.org/show_bug.cgi?id=190263
<rdar://problem/44986532>
Reviewed by Saam Barati.
This is needed because LLIntAssembly.h is template generated from LowLevelInterpreter
asm files, and may contain dead code which are harmless, but will trip up the warning.
We should suppress the warning so that it doesn't break builds.
* llint/LowLevelInterpreter.cpp:
(JSC::CLoop::execute):
2018-10-03 Dan Bernstein <mitz@apple.com>
JavaScriptCore part of [Xcode] Update some build settings as recommended by Xcode 10
https://bugs.webkit.org/show_bug.cgi?id=190250
Reviewed by Alex Christensen.
* API/tests/Regress141275.mm:
(-[JSTEvaluator _sourcePerform]): Addressed newly-enabled CLANG_WARN_OBJC_IMPLICIT_RETAIN_SELF
by making the self-retaining explicit.
* API/tests/testapi.cpp:
(testCAPIViaCpp): Addressed newly-enabled CLANG_WARN_UNREACHABLE_CODE by breaking out of the
loop instead of returning from the lambda.
* Configurations/Base.xcconfig: Enabled CLANG_WARN_COMMA, CLANG_WARN_UNREACHABLE_CODE,
CLANG_WARN_DEPRECATED_OBJC_IMPLEMENTATIONS, CLANG_WARN_OBJC_IMPLICIT_RETAIN_SELF, and
CLANG_ANALYZER_LOCALIZABILITY_NONLOCALIZED.
* JavaScriptCore.xcodeproj/project.pbxproj: Removed a duplicate reference to
UnlinkedFunctionExecutable.h, and let Xcode update the project file.
* assembler/MacroAssemblerPrinter.cpp:
(JSC::Printer::printAllRegisters): Addressed newly-enabled CLANG_WARN_COMMA by replacing
some commas with semicolons.
2018-10-03 Mark Lam <mark.lam@apple.com>
Make string MaxLength for all WTF and JS strings consistently equal to INT_MAX.
https://bugs.webkit.org/show_bug.cgi?id=190187
<rdar://problem/42512909>
Reviewed by Michael Saboff.
Allowing different max string lengths at each level opens up opportunities for
bugs to creep in. With 2 different max length values, it is more difficult to
keep the story straight on how we do overflow / bounds checks at each place in
the code. It's also difficult to tell if a seemingly valid check at the WTF level
will have bad ramifications at the JSC level. Also, it's also not meaningful to
support a max length > INT_MAX. To eliminate this class of bugs, we'll
standardize on a MaxLength of INT_MAX at all levels.
We'll also standardize the way we do length overflow checks on using
CheckedArithmetic, and add some asserts to document the assumptions of the code.
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
- Fix OOM error handling which crashed a test after the new MaxLength was applied.
* runtime/JSString.h:
(JSC::JSString::finishCreation):
(JSC::JSString::createHasOtherOwner):
(JSC::JSString::setLength):
* runtime/JSStringInlines.h:
(JSC::jsMakeNontrivialString):
* runtime/Operations.h:
(JSC::jsString):
2018-10-03 Koby Boyango <koby.b@mce-sys.com>
[JSC] Add a C++ callable overload of objectConstructorSeal
https://bugs.webkit.org/show_bug.cgi?id=190137
Reviewed by Yusuke Suzuki.
* runtime/ObjectConstructor.cpp:
* runtime/ObjectConstructor.h:
2018-10-02 Dominik Infuehr <dinfuehr@igalia.com>
Fix Disassembler-output on ARM Thumb2
https://bugs.webkit.org/show_bug.cgi?id=190203
On ARMv7 with Thumb2 addresses have bit 0 set to 1 to force
execution in thumb mode for jumps and calls. The actual machine
instructions are still aligned to 2-bytes though. Use dataLocation() as
start address for disassembling since it unsets the thumb bit.
Until now the disassembler would start at the wrong address (off by 1),
resulting in the wrong disassembled machine instructions.
Reviewed by Mark Lam.
* disassembler/CapstoneDisassembler.cpp:
(JSC::tryToDisassemble):
2018-10-02 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Add stub of ExecutableAllocator used when JIT is disabled
https://bugs.webkit.org/show_bug.cgi?id=190215
Reviewed by Mark Lam.
When ENABLE(JIT) is disabled, we do not use JIT. But we ExecutableAllocator is still available since
it is guarded by ENABLE(ASSEMBLER). ENABLE(ASSEMBLER) is necessary for LLInt ASM interpreter since
our MacroAssembler tells machine architecture information. Eventually, we would like to decouple
this machine architecture information from MacroAssembler. But for now, we use ENABLE(ASSEMBLER)
for LLInt ASM interpreter even if JIT is disabled by ENABLE(JIT).
To ensure any executable memory allocation is not done, we add a stub of ExecutableAllocator for
non-JIT configurations. This does not have any functionality allocating executable memory, thus
any accidental operation cannot attempt to allocate executable memory if ENABLE(JIT) = OFF.
* jit/ExecutableAllocator.cpp:
(JSC::ExecutableAllocator::initializeAllocator):
(JSC::ExecutableAllocator::singleton):
* jit/ExecutableAllocator.h:
(JSC::ExecutableAllocator::isValid const):
(JSC::ExecutableAllocator::underMemoryPressure):
(JSC::ExecutableAllocator::memoryPressureMultiplier):
(JSC::ExecutableAllocator::dumpProfile):
(JSC::ExecutableAllocator::allocate):
(JSC::ExecutableAllocator::isValidExecutableMemory):
(JSC::ExecutableAllocator::committedByteCount):
(JSC::ExecutableAllocator::getLock const):
(JSC::performJITMemcpy):
2018-10-01 Dean Jackson <dino@apple.com>
Remove CSS Animation Triggers
https://bugs.webkit.org/show_bug.cgi?id=190175
<rdar://problem/44925626>
Reviewed by Simon Fraser.
* Configurations/FeatureDefines.xcconfig:
2018-10-02 Caio Lima <ticaiolima@gmail.com>
[BigInt] BigInt.proptotype.toString is broken when radix is power of 2
https://bugs.webkit.org/show_bug.cgi?id=190033
Reviewed by Yusuke Suzuki.
The implementation of JSBigInt::toStringToGeneric doesn't handle power
of 2 radix when JSBigInt length is >= 2. To handle such cases, we
implemented JSBigInt::toStringBasePowerOfTwo that follows the
algorithm that groups bits using mask of (2 ^ n) - 1 to extract every
digit.
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::toString):
(JSC::JSBigInt::toStringBasePowerOfTwo):
* runtime/JSBigInt.h:
2018-10-01 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Add branchIfNaN and branchIfNotNaN
https://bugs.webkit.org/show_bug.cgi?id=190122
Reviewed by Mark Lam.
Add AssemblyHelpers::{branchIfNaN, branchIfNotNaN} to make code more readable.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
(JSC::DFG::SpeculativeJIT::compileDoubleRep):
(JSC::DFG::SpeculativeJIT::getIntTypedArrayStoreOperand):
(JSC::DFG::SpeculativeJIT::compileSpread):
(JSC::DFG::SpeculativeJIT::compileNewArray):
(JSC::DFG::SpeculativeJIT::speculateRealNumber):
(JSC::DFG::SpeculativeJIT::speculateDoubleRepReal):
(JSC::DFG::SpeculativeJIT::compileNormalizeMapKey):
(JSC::DFG::SpeculativeJIT::compileHasIndexedProperty):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::purifyNaN):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::branchIfNaN):
(JSC::AssemblyHelpers::branchIfNotNaN):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitGenericContiguousPutByVal):
(JSC::JIT::emitDoubleLoad):
(JSC::JIT::emitFloatTypedArrayGetByVal):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emitGenericContiguousPutByVal):
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::createJSToWasmWrapper):
2018-10-01 Mark Lam <mark.lam@apple.com>
Function.toString() should also copy the source code Functions that are class definitions.
https://bugs.webkit.org/show_bug.cgi?id=190186
<rdar://problem/44733360>
Reviewed by Saam Barati.
Previously, if the Function is a class definition, functionProtoFuncToString()
would create a String using StringView::toStringWithoutCopying(), and use that
String to make a JSString. This is not a problem if the underlying SourceProvider
(that backs the characters in that StringView) is immortal. However, this is
not always the case in practice.
This patch fixes this issue by changing functionProtoFuncToString() to create the
String using StringView::toString() instead, which makes a copy of the underlying
characters buffer. This detaches the resultant JSString from the SourceProvider
characters buffer that it was created from, and ensure that the underlying
characters buffer of the string will be alive for the entire lifetime of the
JSString.
* runtime/FunctionPrototype.cpp:
(JSC::functionProtoFuncToString):
2018-10-01 Keith Miller <keith_miller@apple.com>
Create a RELEASE_AND_RETURN macro for ExceptionScopes
https://bugs.webkit.org/show_bug.cgi?id=190163
Reviewed by Mark Lam.
The new RELEASE_AND_RETURN does all the work for cases
where you want to return the result of some expression
without explicitly checking for an exception. This is
much like the existing RETURN_IF_EXCEPTION macro.
* dfg/DFGOperations.cpp:
(JSC::DFG::newTypedArrayWithSize):
* interpreter/Interpreter.cpp:
(JSC::eval):
* jit/JITOperations.cpp:
(JSC::getByVal):
* jsc.cpp:
(functionDollarAgentReceiveBroadcast):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setUpCall):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::varargsSetup):
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::toJSON const):
* runtime/AbstractModuleRecord.cpp:
(JSC::AbstractModuleRecord::hostResolveImportedModule):
* runtime/ArrayConstructor.cpp:
(JSC::constructArrayWithSizeQuirk):
* runtime/ArrayPrototype.cpp:
(JSC::getProperty):
(JSC::fastJoin):
(JSC::arrayProtoFuncToString):
(JSC::arrayProtoFuncToLocaleString):
(JSC::arrayProtoFuncJoin):
(JSC::arrayProtoFuncPop):
(JSC::arrayProtoPrivateFuncConcatMemcpy):
* runtime/BigIntConstructor.cpp:
(JSC::toBigInt):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::opInByVal):
* runtime/ConstructData.cpp:
(JSC::construct):
* runtime/DateConstructor.cpp:
(JSC::dateParse):
* runtime/DatePrototype.cpp:
(JSC::dateProtoFuncToPrimitiveSymbol):
* runtime/DirectArguments.h:
* runtime/ErrorConstructor.cpp:
(JSC::Interpreter::constructWithErrorConstructor):
* runtime/ErrorPrototype.cpp:
(JSC::errorProtoFuncToString):
* runtime/ExceptionScope.h:
* runtime/FunctionConstructor.cpp:
(JSC::constructFunction):
* runtime/FunctionPrototype.cpp:
(JSC::functionProtoFuncToString):
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments<Type>::defineOwnProperty):
* runtime/GetterSetter.cpp:
(JSC::callGetter):
* runtime/IntlCollatorConstructor.cpp:
(JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
* runtime/IntlCollatorPrototype.cpp:
(JSC::IntlCollatorFuncCompare):
(JSC::IntlCollatorPrototypeFuncResolvedOptions):
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::IntlDateTimeFormatFuncFormatDateTime):
(JSC::IntlDateTimeFormatPrototypeFuncFormatToParts):
(JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::IntlNumberFormatFuncFormatNumber):
(JSC::IntlNumberFormatPrototypeFuncFormatToParts):
(JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
* runtime/IntlObject.cpp:
(JSC::intlNumberOption):
* runtime/IntlObjectInlines.h:
(JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
* runtime/IntlPluralRules.cpp:
(JSC::IntlPluralRules::resolvedOptions):
* runtime/IntlPluralRulesConstructor.cpp:
(JSC::IntlPluralRulesConstructorFuncSupportedLocalesOf):
* runtime/IntlPluralRulesPrototype.cpp:
(JSC::IntlPluralRulesPrototypeFuncSelect):
(JSC::IntlPluralRulesPrototypeFuncResolvedOptions):
* runtime/JSArray.cpp:
(JSC::JSArray::defineOwnProperty):
(JSC::JSArray::put):
(JSC::JSArray::setLength):
(JSC::JSArray::unshiftCountWithAnyIndexingType):
* runtime/JSArrayBufferPrototype.cpp:
(JSC::arrayBufferProtoGetterFuncByteLength):
(JSC::sharedArrayBufferProtoGetterFuncByteLength):
* runtime/JSArrayInlines.h:
(JSC::toLength):
* runtime/JSBoundFunction.cpp:
(JSC::boundFunctionCall):
(JSC::boundFunctionConstruct):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive):
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::toIndex const):
(JSC::JSValue::toPropertyKey const):
(JSC::JSValue::get const):
(JSC::JSValue::getPropertySlot const):
(JSC::JSValue::getOwnPropertySlot const):
(JSC::JSValue::equalSlowCaseInline):
* runtime/JSDataView.cpp:
(JSC::JSDataView::put):
(JSC::JSDataView::defineOwnProperty):
* runtime/JSFunction.cpp:
(JSC::JSFunction::put):
(JSC::JSFunction::defineOwnProperty):
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayViewWithArguments):
(JSC::constructGenericTypedArrayView):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::set):
(JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::speciesConstruct):
(JSC::genericTypedArrayViewProtoFuncJoin):
(JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::put):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::decode):
(JSC::globalFuncEval):
(JSC::globalFuncProtoGetter):
* runtime/JSInternalPromise.cpp:
(JSC::JSInternalPromise::then):
* runtime/JSModuleEnvironment.cpp:
(JSC::JSModuleEnvironment::put):
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::provideFetch):
(JSC::JSModuleLoader::loadAndEvaluateModule):
(JSC::JSModuleLoader::loadModule):
(JSC::JSModuleLoader::linkAndEvaluateModule):
(JSC::JSModuleLoader::requestImportModule):
(JSC::JSModuleLoader::getModuleNamespaceObject):
(JSC::moduleLoaderRequestedModules):
* runtime/JSONObject.cpp:
(JSC::Stringifier::stringify):
(JSC::Stringifier::toJSON):
(JSC::Walker::walk):
(JSC::JSONProtoFuncStringify):
* runtime/JSObject.cpp:
(JSC::ordinarySetSlow):
(JSC::JSObject::putInlineSlow):
(JSC::JSObject::toPrimitive const):
(JSC::JSObject::hasInstance):
(JSC::JSObject::toNumber const):
(JSC::JSObject::defineOwnIndexedProperty):
(JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
(JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
(JSC::JSObject::defineOwnNonIndexProperty):
* runtime/JSObject.h:
(JSC::JSObject::get const):
* runtime/JSObjectInlines.h:
(JSC::JSObject::getPropertySlot const):
(JSC::JSObject::putInlineForJSObject):
* runtime/MapConstructor.cpp:
(JSC::constructMap):
* runtime/NativeErrorConstructor.cpp:
(JSC::Interpreter::constructWithNativeErrorConstructor):
* runtime/ObjectConstructor.cpp:
(JSC::constructObject):
(JSC::objectConstructorGetPrototypeOf):
(JSC::objectConstructorGetOwnPropertyDescriptor):
(JSC::objectConstructorGetOwnPropertyDescriptors):
(JSC::objectConstructorGetOwnPropertyNames):
(JSC::objectConstructorGetOwnPropertySymbols):
(JSC::objectConstructorKeys):
(JSC::objectConstructorDefineProperty):
(JSC::objectConstructorDefineProperties):
(JSC::objectConstructorCreate):
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncToLocaleString):
(JSC::objectProtoFuncToString):
* runtime/Operations.cpp:
(JSC::jsAddSlowCase):
* runtime/Operations.h:
(JSC::jsString):
(JSC::jsLess):
(JSC::jsLessEq):
* runtime/ParseInt.h:
(JSC::toStringView):
* runtime/ProxyConstructor.cpp:
(JSC::constructProxyObject):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::toStringName):
(JSC::performProxyGet):
(JSC::ProxyObject::performInternalMethodGetOwnProperty):
(JSC::ProxyObject::performHasProperty):
(JSC::ProxyObject::getOwnPropertySlotCommon):
(JSC::ProxyObject::performPut):
(JSC::ProxyObject::putByIndexCommon):
(JSC::performProxyCall):
(JSC::performProxyConstruct):
(JSC::ProxyObject::performDelete):
(JSC::ProxyObject::performPreventExtensions):
(JSC::ProxyObject::performIsExtensible):
(JSC::ProxyObject::performDefineOwnProperty):
(JSC::ProxyObject::performSetPrototype):
(JSC::ProxyObject::performGetPrototype):
* runtime/ReflectObject.cpp:
(JSC::reflectObjectConstruct):
(JSC::reflectObjectDefineProperty):
(JSC::reflectObjectGet):
(JSC::reflectObjectGetOwnPropertyDescriptor):
(JSC::reflectObjectGetPrototypeOf):
(JSC::reflectObjectOwnKeys):
(JSC::reflectObjectSet):
* runtime/RegExpConstructor.cpp:
(JSC::constructRegExp):
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::defineOwnProperty):
(JSC::RegExpObject::matchGlobal):
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoFuncTestFast):
(JSC::regExpProtoFuncExec):
(JSC::regExpProtoFuncToString):
* runtime/ScriptExecutable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
* runtime/SetConstructor.cpp:
(JSC::constructSet):
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::putEntry):
(JSC::SparseArrayEntry::put):
* runtime/StringConstructor.cpp:
(JSC::stringFromCharCode):
(JSC::stringFromCodePoint):
* runtime/StringObject.cpp:
(JSC::StringObject::put):
(JSC::StringObject::putByIndex):
(JSC::StringObject::defineOwnProperty):
* runtime/StringPrototype.cpp:
(JSC::jsSpliceSubstrings):
(JSC::jsSpliceSubstringsWithSeparators):
(JSC::removeUsingRegExpSearch):
(JSC::replaceUsingRegExpSearch):
(JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
(JSC::replaceUsingStringSearch):
(JSC::repeatCharacter):
(JSC::replace):
(JSC::stringProtoFuncReplaceUsingRegExp):
(JSC::stringProtoFuncReplaceUsingStringSearch):
(JSC::stringProtoFuncSplitFast):
(JSC::stringProtoFuncToLowerCase):
(JSC::stringProtoFuncToUpperCase):
(JSC::toLocaleCase):
(JSC::trimString):
(JSC::stringProtoFuncIncludes):
(JSC::builtinStringIncludesInternal):
(JSC::normalize):
(JSC::stringProtoFuncNormalize):
* runtime/SymbolPrototype.cpp:
(JSC::symbolProtoFuncToString):
(JSC::symbolProtoFuncValueOf):
* tools/JSDollarVM.cpp:
(WTF::functionWasmStreamingParserAddBytes):
(JSC::functionGetPrivateProperty):
* wasm/js/WebAssemblyCompileErrorConstructor.cpp:
(JSC::constructJSWebAssemblyCompileError):
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::constructJSWebAssemblyModule):
(JSC::WebAssemblyModuleConstructor::createModule):
* wasm/js/WebAssemblyTableConstructor.cpp:
(JSC::constructJSWebAssemblyTable):
* wasm/js/WebAssemblyWrapperFunction.cpp:
(JSC::callWebAssemblyWrapperFunction):
2018-10-01 Koby Boyango <koby.b@mce-sys.com>
[JSC] Add a JSONStringify overload that receives a JSValue space
https://bugs.webkit.org/show_bug.cgi?id=190131
Reviewed by Yusuke Suzuki.
* runtime/JSONObject.cpp:
* runtime/JSONObject.h:
2018-10-01 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r236647.
https://bugs.webkit.org/show_bug.cgi?id=190124
Breaking test stress/big-int-to-string.js (Requested by
caiolima_ on #webkit).
Reverted changeset:
"[BigInt] BigInt.proptotype.toString is broken when radix is
power of 2"
https://bugs.webkit.org/show_bug.cgi?id=190033
https://trac.webkit.org/changeset/236647
2018-10-01 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[WebAssembly] Move type conversion code of JSToWasm return type to JS wasm wrapper
https://bugs.webkit.org/show_bug.cgi?id=189498
Reviewed by Saam Barati.
To call JS-to-Wasm code we need to convert the result value from wasm function to
the JS type. Previously this is done by callWebAssemblyFunction by using swtich
over signature.returnType(). But since we know the value of `signature.returnType()`
at compiling phase, we can emit a small conversion code directly to JSToWasm glue
and remove this switch from callWebAssemblyFunction.
In JSToWasm glue code, we do not have tag registers. So we use DoNotHaveTagRegisters
in boxInt32 and boxDouble. Since boxDouble does not have DoNotHaveTagRegisters version,
we add an implementation for that.
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::boxDouble):
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::createJSToWasmWrapper):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
2018-09-30 Caio Lima <ticaiolima@gmail.com>
[BigInt] BigInt.proptotype.toString is broken when radix is power of 2
https://bugs.webkit.org/show_bug.cgi?id=190033
Reviewed by Yusuke Suzuki.
The implementation of JSBigInt::toStringToGeneric doesn't handle power
of 2 radix when JSBigInt length is >= 2. To handle such cases, we
implemented JSBigInt::toStringBasePowerOfTwo that follows the
algorithm that groups bits using mask of (2 ^ n) - 1 to extract every
digit.
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::toString):
(JSC::JSBigInt::toStringBasePowerOfTwo):
* runtime/JSBigInt.h:
2018-09-28 Caio Lima <ticaiolima@gmail.com>
[ESNext][BigInt] Implement support for "&"
https://bugs.webkit.org/show_bug.cgi?id=186228
Reviewed by Yusuke Suzuki.
This patch introduces support of BigInt into bitwise "&" operation.
We are also introducing the ValueBitAnd DFG node, that is responsible
to take care of JIT for non-Int32 operands. With the introduction of this
new node, we renamed the BitAnd node to ArithBitAnd. The ArithBitAnd
follows the behavior of ArithAdd and other arithmetic nodes, where
the Arith<op> version always results in Number (in the case of
ArithBitAnd, its is always an Int32).
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitBinaryOp):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo):
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueBitwiseOp):
(JSC::DFG::SpeculativeJIT::compileBitwiseOp):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::bitOp):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileValueBitAnd):
(JSC::FTL::DFG::LowerDFGToB3::compileArithBitAnd):
(JSC::FTL::DFG::LowerDFGToB3::compileBitAnd): Deleted.
* jit/JIT.h:
* jit/JITArithmetic.cpp:
(JSC::JIT::emitBitBinaryOpFastPath):
(JSC::JIT::emit_op_bitand):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::JSBigInt):
(JSC::JSBigInt::initialize):
(JSC::JSBigInt::createZero):
(JSC::JSBigInt::createFrom):
(JSC::JSBigInt::bitwiseAnd):
(JSC::JSBigInt::absoluteBitwiseOp):
(JSC::JSBigInt::absoluteAnd):
(JSC::JSBigInt::absoluteOr):
(JSC::JSBigInt::absoluteAndNot):
(JSC::JSBigInt::absoluteAddOne):
(JSC::JSBigInt::absoluteSubOne):
* runtime/JSBigInt.h:
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::toBigIntOrInt32 const):
2018-09-28 Mark Lam <mark.lam@apple.com>
Gardening: speculative build fix.
<rdar://problem/44869924>
Not reviewed.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::copyCompactAndLinkCode):
2018-09-28 Guillaume Emont <guijemont@igalia.com>
[JSC] [Armv7] Add a copy function argument to MacroAssemblerARMv7::link() and pass it down to the assembler's linking functions.
https://bugs.webkit.org/show_bug.cgi?id=190080
Reviewed by Mark Lam.
* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::link):
(JSC::ARMv7Assembler::linkJumpT1):
(JSC::ARMv7Assembler::linkJumpT2):
(JSC::ARMv7Assembler::linkJumpT3):
(JSC::ARMv7Assembler::linkJumpT4):
(JSC::ARMv7Assembler::linkConditionalJumpT4):
(JSC::ARMv7Assembler::linkBX):
(JSC::ARMv7Assembler::linkConditionalBX):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::link):
2018-09-27 Saam barati <sbarati@apple.com>
Verify the contents of AssemblerBuffer on arm64e
https://bugs.webkit.org/show_bug.cgi?id=190057
<rdar://problem/38916630>
Reviewed by Mark Lam.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::ARM64Assembler):
(JSC::ARM64Assembler::fillNops):
(JSC::ARM64Assembler::link):
(JSC::ARM64Assembler::linkJumpOrCall):
(JSC::ARM64Assembler::linkCompareAndBranch):
(JSC::ARM64Assembler::linkConditionalBranch):
(JSC::ARM64Assembler::linkTestAndBranch):
(JSC::ARM64Assembler::unlinkedCode): Deleted.
* assembler/ARMAssembler.h:
(JSC::ARMAssembler::fillNops):
* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::unlinkedCode): Deleted.
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::emitNops):
(JSC::AbstractMacroAssembler::AbstractMacroAssembler):
* assembler/AssemblerBuffer.h:
(JSC::ARM64EHash::ARM64EHash):
(JSC::ARM64EHash::update):
(JSC::ARM64EHash::hash const):
(JSC::ARM64EHash::randomSeed const):
(JSC::AssemblerBuffer::AssemblerBuffer):
(JSC::AssemblerBuffer::putShort):
(JSC::AssemblerBuffer::putIntUnchecked):
(JSC::AssemblerBuffer::putInt):
(JSC::AssemblerBuffer::hash const):
(JSC::AssemblerBuffer::data const):
(JSC::AssemblerBuffer::putIntegralUnchecked):
(JSC::AssemblerBuffer::append): Deleted.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::copyCompactAndLinkCode):
* assembler/MIPSAssembler.h:
(JSC::MIPSAssembler::fillNops):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::jumpsToLink):
(JSC::MacroAssemblerARM64::link):
(JSC::MacroAssemblerARM64::unlinkedCode): Deleted.
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::jumpsToLink):
(JSC::MacroAssemblerARMv7::unlinkedCode): Deleted.
* assembler/X86Assembler.h:
(JSC::X86Assembler::fillNops):
2018-09-27 Mark Lam <mark.lam@apple.com>
ByValInfo should not use integer offsets.
https://bugs.webkit.org/show_bug.cgi?id=190070
<rdar://problem/44803430>
Reviewed by Saam Barati.
Also moved some fields around to allow the ByValInfo struct to be more densely packed.
* bytecode/ByValInfo.h:
(JSC::ByValInfo::ByValInfo):
* jit/JIT.cpp:
(JSC::JIT::link):
* jit/JITOpcodes.cpp:
(JSC::JIT::privateCompileHasIndexedProperty):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::privateCompileHasIndexedProperty):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::privateCompileGetByVal):
(JSC::JIT::privateCompileGetByValWithCachedId):
(JSC::JIT::privateCompilePutByVal):
(JSC::JIT::privateCompilePutByValWithCachedId):
2018-09-27 Saam barati <sbarati@apple.com>
DFG::OSRExit::m_patchableCodeOffset should not be an int
https://bugs.webkit.org/show_bug.cgi?id=190066
<rdar://problem/39498244>
Reviewed by Mark Lam.
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::linkOSRExits):
(JSC::DFG::JITCompiler::link):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::codeLocationForRepatch const):
(JSC::DFG::OSRExit::compileOSRExit):
(JSC::DFG::OSRExit::setPatchableCodeOffset): Deleted.
(JSC::DFG::OSRExit::getPatchableCodeOffsetAsJump const): Deleted.
(JSC::DFG::OSRExit::correctJump): Deleted.
* dfg/DFGOSRExit.h:
* dfg/DFGOSRExitCompilationInfo.h:
2018-09-27 Saam barati <sbarati@apple.com>
Don't use int offsets in StructureStubInfo
https://bugs.webkit.org/show_bug.cgi?id=190064
<rdar://problem/44784719>
Reviewed by Mark Lam.
* bytecode/InlineAccess.cpp:
(JSC::linkCodeInline):
* bytecode/StructureStubInfo.h:
(JSC::StructureStubInfo::slowPathCallLocation):
(JSC::StructureStubInfo::doneLocation):
(JSC::StructureStubInfo::slowPathStartLocation):
* jit/JITInlineCacheGenerator.cpp:
(JSC::JITInlineCacheGenerator::finalize):
2018-09-27 Mark Lam <mark.lam@apple.com>
DFG::OSREntry::m_machineCodeOffset should be a CodeLocation.
https://bugs.webkit.org/show_bug.cgi?id=190054
<rdar://problem/44803543>
Reviewed by Saam Barati.
* dfg/DFGJITCode.h:
(JSC::DFG::JITCode::appendOSREntryData):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::noticeOSREntry):
* dfg/DFGOSREntry.cpp:
(JSC::DFG::OSREntryData::dumpInContext const):
(JSC::DFG::prepareOSREntry):
* dfg/DFGOSREntry.h:
* runtime/JSCPtrTag.h:
2018-09-27 Mark Lam <mark.lam@apple.com>
JITMathIC should not use integer offsets into machine code.
https://bugs.webkit.org/show_bug.cgi?id=190030
<rdar://problem/44803307>
Reviewed by Saam Barati.
We'll replace them with CodeLocation smart pointers instead.
* jit/JITMathIC.h:
(JSC::isProfileEmpty):
2018-09-26 Mark Lam <mark.lam@apple.com>
Options::useSeparatedWXHeap() should always be false when ENABLE(FAST_JIT_PERMISSIONS) && CPU(ARM64E).
https://bugs.webkit.org/show_bug.cgi?id=190022
<rdar://problem/44800928>
Reviewed by Saam Barati.
* jit/ExecutableAllocator.cpp:
(JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
(JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
* jit/ExecutableAllocator.h:
(JSC::performJITMemcpy):
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
2018-09-26 Mark Lam <mark.lam@apple.com>
Assert that performJITMemcpy() is always called with instruction size aligned addresses on ARM64.
https://bugs.webkit.org/show_bug.cgi?id=190016
<rdar://problem/44802875>
Reviewed by Saam Barati.
Also assert in performJITMemcpy() that the entire buffer to be copied will fit in
JIT memory.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::fillNops):
(JSC::ARM64Assembler::replaceWithVMHalt):
(JSC::ARM64Assembler::replaceWithJump):
(JSC::ARM64Assembler::replaceWithLoad):
(JSC::ARM64Assembler::replaceWithAddressComputation):
(JSC::ARM64Assembler::setPointer):
(JSC::ARM64Assembler::repatchInt32):
(JSC::ARM64Assembler::repatchCompact):
(JSC::ARM64Assembler::linkJumpOrCall):
(JSC::ARM64Assembler::linkCompareAndBranch):
(JSC::ARM64Assembler::linkConditionalBranch):
(JSC::ARM64Assembler::linkTestAndBranch):
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::copyCompactAndLinkCode):
(JSC::LinkBuffer::linkCode):
* jit/ExecutableAllocator.h:
(JSC::performJITMemcpy):
2018-09-25 Keith Miller <keith_miller@apple.com>
Move Symbol API to SPI
https://bugs.webkit.org/show_bug.cgi?id=189946
Reviewed by Michael Saboff.
Some of the property access methods on JSValue needed to be moved
to a category so that SPI overloads don't result in a compiler
error for internal users.
Additionally, this patch does not move the new enum entry for
Symbols in the JSType enumeration.
* API/JSObjectRef.h:
* API/JSObjectRefPrivate.h:
* API/JSValue.h:
* API/JSValuePrivate.h:
* API/JSValueRef.h:
2018-09-26 Keith Miller <keith_miller@apple.com>
We should zero unused property storage when rebalancing array storage.
https://bugs.webkit.org/show_bug.cgi?id=188151
Reviewed by Michael Saboff.
In unshiftCountSlowCase we sometimes will move property storage to the right even when net adding elements.
This can happen because we "balance" the pre/post-capacity in that code so we need to zero the unused
property storage.
* runtime/JSArray.cpp:
(JSC::JSArray::unshiftCountSlowCase):
2018-09-26 Yusuke Suzuki <yusukesuzuki@slowstart.org>
Unreviewed, add scope verification handling
https://bugs.webkit.org/show_bug.cgi?id=189780
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncIndexOf):
(JSC::arrayProtoFuncLastIndexOf):
2018-09-26 Koby Boyango <koby.b@mce.systems>
[JSC] offlineasm parser should handle CRLF in asm files
https://bugs.webkit.org/show_bug.cgi?id=189949
Reviewed by Mark Lam.
* offlineasm/parser.rb:
2018-09-20 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Optimize Array#lastIndexOf
https://bugs.webkit.org/show_bug.cgi?id=189780
Reviewed by Saam Barati.
Optimize Array#lastIndexOf as the same to Array#indexOf. We add a fast path
for JSArray with contiguous storage.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncLastIndexOf):
2018-09-25 Saam Barati <sbarati@apple.com>
Calls to baselineCodeBlockForOriginAndBaselineCodeBlock in operationMaterializeObjectInOSR should actually pass in the baseline CodeBlock
https://bugs.webkit.org/show_bug.cgi?id=189940
<rdar://problem/43640987>
Reviewed by Mark Lam.
We were calling baselineCodeBlockForOriginAndBaselineCodeBlock with the FTL
CodeBlock. There is nothing semantically wrong with doing that (except for
poor naming), however, the poor naming here led us to make a real semantic
mistake. We wanted the baseline CodeBlock's constant pool, but we were
accessing the FTL CodeBlock's constant pool accidentally. We need to
access the baseline CodeBlock's constant pool when we update the NewArrayBuffer
constant value.
* bytecode/InlineCallFrame.h:
(JSC::baselineCodeBlockForOriginAndBaselineCodeBlock):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
2018-09-25 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Stricter block syntax in generated ObjC protocol interfaces
https://bugs.webkit.org/show_bug.cgi?id=189962
<rdar://problem/44648287>
Reviewed by Brian Burg.
* inspector/scripts/codegen/generate_objc_header.py:
(ObjCHeaderGenerator._callback_block_for_command):
If there are no return parameters include "void" in the block signature.
* inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/generic/expected/domain-availability.json-result:
* inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/generic/expected/worker-supported-domains.json-result:
* inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result:
Rebaseline test results.
2018-09-24 Joseph Pecoraro <pecoraro@apple.com>
Remove AUTHORS and THANKS files which are stale
https://bugs.webkit.org/show_bug.cgi?id=189941
Reviewed by Darin Adler.
Included mentions below so their names are still in ChangeLogs.
* AUTHORS: Removed.
Harri Porten (porten@kde.org) and Peter Kelly (pmk@post.com).
These authors remain mentioned in copyrights in source files.
* THANKS: Removed.
Richard Moore <rich@kde.org> - for filling the Math object with some life
Daegeun Lee <realking@mizi.com> - for pointing out some bugs and providing much code for the String and Date object.
Marco Pinelli <pinmc@libero.it> - for his patches
Christian Kirsch <ck@held.mind.de> - for his contribution to the Date object
2018-09-24 Fujii Hironori <Hironori.Fujii@sony.com>
Rename WTF_COMPILER_GCC_OR_CLANG to WTF_COMPILER_GCC_COMPATIBLE
https://bugs.webkit.org/show_bug.cgi?id=189733
Reviewed by Michael Catanzaro.
* assembler/ARM64Assembler.h:
* assembler/ARMAssembler.h:
(JSC::ARMAssembler::cacheFlush):
* assembler/MacroAssemblerARM.cpp:
(JSC::isVFPPresent):
* assembler/MacroAssemblerARM64.cpp:
* assembler/MacroAssemblerARMv7.cpp:
* assembler/MacroAssemblerMIPS.cpp:
* assembler/MacroAssemblerX86Common.cpp:
* heap/HeapCell.cpp:
* heap/HeapCell.h:
* jit/HostCallReturnValue.h:
* jit/JIT.h:
* jit/JITOperations.cpp:
* jit/ThunkGenerators.cpp:
* runtime/ArrayConventions.cpp:
(JSC::clearArrayMemset):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::digitDiv):
2018-09-24 Saam Barati <sbarati@apple.com>
Array.prototype.indexOf fast path needs to ensure the length is still valid after performing effects
https://bugs.webkit.org/show_bug.cgi?id=189922
<rdar://problem/44651275>
Reviewed by Mark Lam.
The implementation was first getting the length to iterate up to,
then getting the starting index. However, getting the starting
index may perform effects. e.g, it could change the length of the
array. This changes it so we verify the length is still valid.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncIndexOf):
2018-09-24 Tadeu Zagallo <tzagallo@apple.com>
offlineasm: fix macro scoping
https://bugs.webkit.org/show_bug.cgi?id=189902
Reviewed by Mark Lam.
In the code below, the reference to `f` in `g`, which should refer to
the outer macro definition will instead refer to the f argument of the
anonymous macro passed to `g`. That leads to this code failing to
compile (f expected 0 args but got 1).
```
macro f(x)
move x, t0
end
macro g(fn)
fn(macro () f(42) end)
end
g(macro(f) f() end)
```
* offlineasm/ast.rb:
* offlineasm/transform.rb:
2018-09-24 Tadeu Zagallo <tzagallo@apple.com>
Add forEach method for iterating CodeBlock's ValueProfiles
https://bugs.webkit.org/show_bug.cgi?id=189897
Reviewed by Mark Lam.
Add method to abstract how we find ValueProfiles in a CodeBlock in
preparation for https://bugs.webkit.org/show_bug.cgi?id=189785, when
ValueProfiles will be stored in the MetadataTable.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
(JSC::CodeBlock::updateAllValueProfilePredictions):
(JSC::CodeBlock::shouldOptimizeNow):
(JSC::CodeBlock::dumpValueProfiles):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::forEachValueProfile):
(JSC::CodeBlock::numberOfArgumentValueProfiles):
(JSC::CodeBlock::valueProfileForArgument):
(JSC::CodeBlock::numberOfValueProfiles):
(JSC::CodeBlock::valueProfile):
(JSC::CodeBlock::totalNumberOfValueProfiles): Deleted.
(JSC::CodeBlock::getFromAllValueProfiles): Deleted.
* tools/HeapVerifier.cpp:
(JSC::HeapVerifier::validateJSCell):
2018-09-24 Saam barati <sbarati@apple.com>
ArgumentsEliminationPhase should snip basic blocks after proven OSR exits
https://bugs.webkit.org/show_bug.cgi?id=189682
<rdar://problem/43557315>
Reviewed by Mark Lam.
Otherwise, if we have code like this:
```
a: Arguments
b: GetButterfly(@a)
c: ForceExit
d: GetArrayLength(@a, @b)
```
it will get transformed into this invalid DFG IR:
```
a: PhantomArguments
b: Check(@a)
c: ForceExit
d: GetArrayLength(@a, @b)
```
And we will fail DFG validation since @b does not have a result.
The fix is to just remove all nodes after the ForceExit and plant an
Unreachable after it. So the above code program will now turn into this:
```
a: PhantomArguments
b: Check(@a)
c: ForceExit
e: Unreachable
```
* dfg/DFGArgumentsEliminationPhase.cpp:
2018-09-22 Saam barati <sbarati@apple.com>
The sampling should not use Strong<CodeBlock> in its machineLocation field
https://bugs.webkit.org/show_bug.cgi?id=189319
Reviewed by Filip Pizlo.
The sampling profiler has a CLI mode where we gather information about inline
call frames. That data structure was using a Strong<CodeBlock>. We were
constructing this Strong<CodeBlock> during GC concurrently to processing all
the Strong handles. This is a bug since we end up corrupting that data
structure. This patch fixes this by just making this data structure use the
sampling profiler's mechanism for holding onto and properly visiting heap pointers.
* inspector/agents/InspectorScriptProfilerAgent.cpp:
(Inspector::InspectorScriptProfilerAgent::trackingComplete):
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::processUnverifiedStackTraces):
(JSC::SamplingProfiler::reportTopFunctions):
(JSC::SamplingProfiler::reportTopBytecodes):
These CLI helpers needed a DeferGC otherwise we may end up deadlocking when we
cause a GC to happen while already holding the sampling profiler's
lock.
2018-09-21 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Enable LLInt ASM interpreter on X64 and ARM64 in non JIT configuration
https://bugs.webkit.org/show_bug.cgi?id=189778
Reviewed by Keith Miller.
LLInt ASM interpreter is 2x and 15% faster than CLoop interpreter on
Linux and macOS respectively. We would like to enable it for non JIT
configurations in X86_64 and ARM64.
This patch enables LLInt for non JIT builds in X86_64 and ARM64 architectures.
Previously, we switch LLInt ASM interpreter and CLoop by using ENABLE(JIT)
configuration. But it is wrong in the new scenario since we have a build
configuration that uses LLInt ASM interpreter and JIT is disabled. We introduce
ENABLE(C_LOOP) option, which represents that we use CLoop. And we replace
ENABLE(JIT) with ENABLE(C_LOOP) if the previous ENABLE(JIT) is essentially just
related to LLInt ASM interpreter and not related to JIT.
We also replace some ENABLE(JIT) configurations with ENABLE(ASSEMBLER).
ENABLE(ASSEMBLER) is now enabled even if we disable JIT since MacroAssembler
has machine register information that is used in LLInt ASM interpreter.
* API/tests/PingPongStackOverflowTest.cpp:
(testPingPongStackOverflow):
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/MaxFrameExtentForSlowPathCall.h:
* bytecode/CallReturnOffsetToBytecodeOffset.h: Removed. It is no longer used.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::calleeSaveRegisters const):
(JSC::CodeBlock::numberOfLLIntBaselineCalleeSaveRegisters):
(JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters):
(JSC::CodeBlock::calleeSaveSpaceAsVirtualRegisters):
* bytecode/Opcode.h:
(JSC::padOpcodeName):
* heap/Heap.cpp:
(JSC::Heap::gatherJSStackRoots):
(JSC::Heap::stopThePeriphery):
* interpreter/CLoopStack.cpp:
* interpreter/CLoopStack.h:
* interpreter/CLoopStackInlines.h:
* interpreter/EntryFrame.h:
* interpreter/Interpreter.cpp:
(JSC::Interpreter::Interpreter):
(JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
* interpreter/Interpreter.h:
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::calleeSaveRegisters):
* interpreter/VMEntryRecord.h:
* jit/ExecutableAllocator.h:
* jit/FPRInfo.h:
(WTF::printInternal):
* jit/GPRInfo.cpp:
* jit/GPRInfo.h:
(WTF::printInternal):
* jit/HostCallReturnValue.cpp:
(JSC::getHostCallReturnValueWithExecState): Moved. They are used in LLInt ASM interpreter too.
* jit/HostCallReturnValue.h:
* jit/JITOperations.cpp:
(JSC::getHostCallReturnValueWithExecState): Deleted.
* jit/JITOperationsMSVC64.cpp:
* jit/Reg.cpp:
* jit/Reg.h:
* jit/RegisterAtOffset.cpp:
* jit/RegisterAtOffset.h:
* jit/RegisterAtOffsetList.cpp:
* jit/RegisterAtOffsetList.h:
* jit/RegisterMap.h:
* jit/RegisterSet.cpp:
* jit/RegisterSet.h:
* jit/TempRegisterSet.cpp:
* jit/TempRegisterSet.h:
* llint/LLIntCLoop.cpp:
* llint/LLIntCLoop.h:
* llint/LLIntData.cpp:
(JSC::LLInt::initialize):
(JSC::LLInt::Data::performAssertions):
* llint/LLIntData.h:
* llint/LLIntOfflineAsmConfig.h:
* llint/LLIntOpcode.h:
* llint/LLIntPCRanges.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LLIntThunks.cpp:
* llint/LowLevelInterpreter.cpp:
* llint/LowLevelInterpreter.h:
* runtime/JSCJSValue.h:
* runtime/MachineContext.h:
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::processUnverifiedStackTraces): Enable SamplingProfiler
for LLInt ASM interpreter with non JIT configuration.
* runtime/TestRunnerUtils.cpp:
(JSC::optimizeNextInvocation):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::getHostFunction):
(JSC::VM::updateSoftReservedZoneSize):
(JSC::sanitizeStackForVM):
(JSC::VM::committedStackByteCount):
* runtime/VM.h:
* runtime/VMInlines.h:
(JSC::VM::ensureStackCapacityFor):
(JSC::VM::isSafeToRecurseSoft const):
2018-09-21 Keith Miller <keith_miller@apple.com>
Add Promise SPI
https://bugs.webkit.org/show_bug.cgi?id=189809
Reviewed by Saam Barati.
The Patch adds new SPI to create promises. It's mostly SPI because
I want to see how internal users react to it before we make it
public.
This patch adds a couple of new Obj-C SPI methods. The first
creates a new promise using the same API that JS does where the
user provides an executor callback. If an exception is raised
in/to that callback the promise is automagically rejected. The
other methods create a pre-resolved or rejected promise as this
appears to be a common way to initialize a promise.
I was also considering adding a second version of executor API
where it would catch specific Obj-C exceptions. This would work by
taking a Class paramter and checking isKindOfClass: on the
exception. I decided against this as nothing else in our API
handles Obj-C exceptions. I'm pretty sure the VM will end up in a
corrupt state if an Obj-C exception unwinds through JS frames.
This patch adds a new C function that will create a "deferred"
promise. A deferred promise is a style of creating promise/futures
where the resolve and reject functions are passed as outputs of a
function. I went with this style for the C SPI because we don't have
any concept of forwarding exceptions in the C API.
In order to make the C API work I refactored a bit of the promise code
so that we can call a static method on JSDeferredPromise and just get
the components without allocating an extra cell wrapper.
* API/JSContext.mm:
(+[JSContext currentCallee]):
* API/JSObjectRef.cpp:
(JSObjectMakeDeferredPromise):
* API/JSObjectRefPrivate.h:
* API/JSValue.mm:
(+[JSValue valueWithNewPromiseInContext:fromExecutor:]):
(+[JSValue valueWithNewPromiseResolvedWithResult:inContext:]):
(+[JSValue valueWithNewPromiseRejectedWithReason:inContext:]):
* API/JSValuePrivate.h: Added.
* API/JSVirtualMachine.mm:
* API/JSVirtualMachinePrivate.h:
* API/tests/testapi.c:
(main):
* API/tests/testapi.cpp:
(APIContext::operator JSC::ExecState*):
(TestAPI::failed const):
(TestAPI::check):
(TestAPI::basicSymbol):
(TestAPI::symbolsTypeof):
(TestAPI::symbolsGetPropertyForKey):
(TestAPI::symbolsSetPropertyForKey):
(TestAPI::symbolsHasPropertyForKey):
(TestAPI::symbolsDeletePropertyForKey):
(TestAPI::promiseResolveTrue):
(TestAPI::promiseRejectTrue):
(testCAPIViaCpp):
(TestAPI::run): Deleted.
* API/tests/testapi.mm:
(testObjectiveCAPIMain):
(promiseWithExecutor):
(promiseRejectOnJSException):
(promiseCreateResolved):
(promiseCreateRejected):
(parallelPromiseResolveTest):
(testObjectiveCAPI):
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/JSInternalPromiseDeferred.cpp:
(JSC::JSInternalPromiseDeferred::create):
* runtime/JSPromise.h:
* runtime/JSPromiseConstructor.cpp:
(JSC::constructPromise):
* runtime/JSPromiseDeferred.cpp:
(JSC::JSPromiseDeferred::createDeferredData):
(JSC::JSPromiseDeferred::create):
(JSC::JSPromiseDeferred::finishCreation):
(JSC::newPromiseCapability): Deleted.
* runtime/JSPromiseDeferred.h:
(JSC::JSPromiseDeferred::promise const):
(JSC::JSPromiseDeferred::resolve const):
(JSC::JSPromiseDeferred::reject const):
2018-09-21 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r236359.
Broke the Windows build.
Reverted changeset:
"Add Promise SPI"
https://bugs.webkit.org/show_bug.cgi?id=189809
https://trac.webkit.org/changeset/236359
2018-09-21 Mark Lam <mark.lam@apple.com>
JSRopeString::resolveRope() wrongly assumes that tryGetValue() passes it a valid ExecState.
https://bugs.webkit.org/show_bug.cgi?id=189855
<rdar://problem/44680181>
Reviewed by Filip Pizlo.
tryGetValue() always passes a nullptr to JSRopeString::resolveRope() for the
ExecState* argument. This is intentional so that resolveRope() does not throw
in the event of an OutOfMemory error. Hence, JSRopeString::resolveRope() should
get the VM from the cell instead of via the ExecState.
Also removed an obsolete and unused field in JSString.
* runtime/JSString.cpp:
(JSC::JSRopeString::resolveRope const):
(JSC::JSRopeString::outOfMemory const):
* runtime/JSString.h:
(JSC::JSString::tryGetValue const):
2018-09-21 Michael Saboff <msaboff@apple.com>
Add functions to measure memory footprint to JSC
https://bugs.webkit.org/show_bug.cgi?id=189768
Reviewed by Saam Barati.
Rolling this back in again.
Provide system memory metrics for the current process to aid in memory reduction measurement and
tuning using native JS tests.
* jsc.cpp:
(MemoryFootprint::now):
(MemoryFootprint::resetPeak):
(GlobalObject::finishCreation):
(JSCMemoryFootprint::JSCMemoryFootprint):
(JSCMemoryFootprint::createStructure):
(JSCMemoryFootprint::create):
(JSCMemoryFootprint::finishCreation):
(JSCMemoryFootprint::addProperty):
(functionResetMemoryPeak):
2018-09-21 Keith Miller <keith_miller@apple.com>
Add Promise SPI
https://bugs.webkit.org/show_bug.cgi?id=189809
Reviewed by Saam Barati.
The Patch adds new SPI to create promises. It's mostly SPI because
I want to see how internal users react to it before we make it
public.
This patch adds a couple of new Obj-C SPI methods. The first
creates a new promise using the same API that JS does where the
user provides an executor callback. If an exception is raised
in/to that callback the promise is automagically rejected. The
other methods create a pre-resolved or rejected promise as this
appears to be a common way to initialize a promise.
I was also considering adding a second version of executor API
where it would catch specific Obj-C exceptions. This would work by
taking a Class paramter and checking isKindOfClass: on the
exception. I decided against this as nothing else in our API
handles Obj-C exceptions. I'm pretty sure the VM will end up in a
corrupt state if an Obj-C exception unwinds through JS frames.
This patch adds a new C function that will create a "deferred"
promise. A deferred promise is a style of creating promise/futures
where the resolve and reject functions are passed as outputs of a
function. I went with this style for the C SPI because we don't have
any concept of forwarding exceptions in the C API.
In order to make the C API work I refactored a bit of the promise code
so that we can call a static method on JSDeferredPromise and just get
the components without allocating an extra cell wrapper.
* API/JSContext.mm:
(+[JSContext currentCallee]):
* API/JSObjectRef.cpp:
(JSObjectMakeDeferredPromise):
* API/JSObjectRefPrivate.h:
* API/JSValue.mm:
(+[JSValue valueWithNewPromiseInContext:fromExecutor:]):
(+[JSValue valueWithNewPromiseResolvedWithResult:inContext:]):
(+[JSValue valueWithNewPromiseRejectedWithReason:inContext:]):
* API/JSValuePrivate.h: Added.
* API/JSVirtualMachine.mm:
* API/JSVirtualMachinePrivate.h:
* API/tests/testapi.c:
(main):
* API/tests/testapi.cpp:
(APIContext::operator JSC::ExecState*):
(TestAPI::failed const):
(TestAPI::check):
(TestAPI::basicSymbol):
(TestAPI::symbolsTypeof):
(TestAPI::symbolsGetPropertyForKey):
(TestAPI::symbolsSetPropertyForKey):
(TestAPI::symbolsHasPropertyForKey):
(TestAPI::symbolsDeletePropertyForKey):
(TestAPI::promiseResolveTrue):
(TestAPI::promiseRejectTrue):
(testCAPIViaCpp):
(TestAPI::run): Deleted.
* API/tests/testapi.mm:
(testObjectiveCAPIMain):
(promiseWithExecutor):
(promiseRejectOnJSException):
(promiseCreateResolved):
(promiseCreateRejected):
(parallelPromiseResolveTest):
(testObjectiveCAPI):
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/JSInternalPromiseDeferred.cpp:
(JSC::JSInternalPromiseDeferred::create):
* runtime/JSPromise.h:
* runtime/JSPromiseConstructor.cpp:
(JSC::constructPromise):
* runtime/JSPromiseDeferred.cpp:
(JSC::JSPromiseDeferred::createDeferredData):
(JSC::JSPromiseDeferred::create):
(JSC::JSPromiseDeferred::finishCreation):
(JSC::newPromiseCapability): Deleted.
* runtime/JSPromiseDeferred.h:
(JSC::JSPromiseDeferred::promise const):
(JSC::JSPromiseDeferred::resolve const):
(JSC::JSPromiseDeferred::reject const):
2018-09-21 Truitt Savell <tsavell@apple.com>
Rebaseline tests after changes in https://trac.webkit.org/changeset/236321/webkit
https://bugs.webkit.org/show_bug.cgi?id=156674
Unreviewed Test Gardening
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
2018-09-21 Mike Gorse <mgorse@suse.com>
Build tools should work when the /usr/bin/python is python3
https://bugs.webkit.org/show_bug.cgi?id=156674
Reviewed by Michael Catanzaro.
* Scripts/cssmin.py:
* Scripts/generate-js-builtins.py:
(do_open):
(generate_bindings_for_builtins_files):
* Scripts/generateIntlCanonicalizeLanguage.py:
* Scripts/jsmin.py:
(JavascriptMinify.minify.write):
(JavascriptMinify):
(JavascriptMinify.minify):
* Scripts/make-js-file-arrays.py:
(chunk):
(main):
* Scripts/wkbuiltins/__init__.py:
* Scripts/wkbuiltins/builtins_generate_combined_header.py:
(generate_section_for_global_private_code_name_macro):
* Scripts/wkbuiltins/builtins_generate_internals_wrapper_header.py:
(BuiltinsInternalsWrapperHeaderGenerator.__init__):
* Scripts/wkbuiltins/builtins_generate_internals_wrapper_implementation.py:
(BuiltinsInternalsWrapperImplementationGenerator.__init__):
* Scripts/wkbuiltins/builtins_model.py:
(BuiltinFunction.__lt__):
(BuiltinsCollection.copyrights):
(BuiltinsCollection._parse_functions):
* disassembler/udis86/ud_opcode.py:
(UdOpcodeTables.pprint.printWalk):
* generate-bytecode-files:
* inspector/scripts/codegen/__init__.py:
* inspector/scripts/codegen/cpp_generator.py:
* inspector/scripts/codegen/generate_cpp_alternate_backend_dispatcher_header.py:
(CppAlternateBackendDispatcherHeaderGenerator.generate_output):
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
(CppBackendDispatcherHeaderGenerator.domains_to_generate):
(CppBackendDispatcherHeaderGenerator.generate_output):
(CppBackendDispatcherHeaderGenerator._generate_dispatcher_declarations_for_domain):
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
(CppBackendDispatcherImplementationGenerator.domains_to_generate):
(CppBackendDispatcherImplementationGenerator.generate_output):
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
(CppFrontendDispatcherHeaderGenerator.domains_to_generate):
(CppFrontendDispatcherHeaderGenerator.generate_output):
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
(CppFrontendDispatcherImplementationGenerator.domains_to_generate):
(CppFrontendDispatcherImplementationGenerator.generate_output):
* inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
(CppProtocolTypesHeaderGenerator.generate_output):
(CppProtocolTypesHeaderGenerator._generate_forward_declarations):
* inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
(CppProtocolTypesImplementationGenerator.generate_output):
(CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain):
(CppProtocolTypesImplementationGenerator._generate_enum_mapping_and_conversion_methods):
(CppProtocolTypesImplementationGenerator._generate_open_field_names):
(CppProtocolTypesImplementationGenerator._generate_builders_for_domain):
(CppProtocolTypesImplementationGenerator._generate_assertion_for_object_declaration):
* inspector/scripts/codegen/generate_js_backend_commands.py:
(JSBackendCommandsGenerator.should_generate_domain):
(JSBackendCommandsGenerator.domains_to_generate):
(JSBackendCommandsGenerator.generate_output):
(JSBackendCommandsGenerator.generate_domain):
* inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
(ObjCBackendDispatcherHeaderGenerator.domains_to_generate):
(ObjCBackendDispatcherHeaderGenerator.generate_output):
* inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
(ObjCBackendDispatcherImplementationGenerator.domains_to_generate):
(ObjCBackendDispatcherImplementationGenerator.generate_output):
(ObjCBackendDispatcherImplementationGenerator._generate_success_block_for_command):
* inspector/scripts/codegen/generate_objc_configuration_header.py:
* inspector/scripts/codegen/generate_objc_configuration_implementation.py:
* inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
(ObjCFrontendDispatcherImplementationGenerator.domains_to_generate):
(ObjCFrontendDispatcherImplementationGenerator.generate_output):
(ObjCFrontendDispatcherImplementationGenerator._generate_event):
* inspector/scripts/codegen/generate_objc_header.py:
(ObjCHeaderGenerator.generate_output):
(ObjCHeaderGenerator._generate_type_interface):
* inspector/scripts/codegen/generate_objc_internal_header.py:
(ObjCInternalHeaderGenerator.generate_output):
* inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py:
(ObjCProtocolTypeConversionsHeaderGenerator.domains_to_generate):
(ObjCProtocolTypeConversionsHeaderGenerator.generate_output):
* inspector/scripts/codegen/generate_objc_protocol_type_conversions_implementation.py:
(ObjCProtocolTypeConversionsImplementationGenerator.domains_to_generate):
* inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
(ObjCProtocolTypesImplementationGenerator.domains_to_generate):
(ObjCProtocolTypesImplementationGenerator.generate_output):
(ObjCProtocolTypesImplementationGenerator.generate_type_implementation):
(ObjCProtocolTypesImplementationGenerator._generate_init_method_for_required_members):
* inspector/scripts/codegen/generator.py:
(Generator.non_supplemental_domains):
(Generator.open_fields):
(Generator.calculate_types_requiring_shape_assertions):
(Generator._traverse_and_assign_enum_values):
(Generator.stylized_name_for_enum_value):
* inspector/scripts/codegen/models.py:
(find_duplicates):
* inspector/scripts/codegen/objc_generator.py:
* wasm/generateWasm.py:
(opcodeIterator):
* yarr/generateYarrCanonicalizeUnicode:
* yarr/generateYarrUnicodePropertyTables.py:
* yarr/hasher.py:
(stringHash):
2018-09-21 Tomas Popela <tpopela@redhat.com>
[ARM] Build broken on armv7hl after r235517
https://bugs.webkit.org/show_bug.cgi?id=189831
Reviewed by Yusuke Suzuki.
Add missing implementation of patchebleBranch8() for traditional ARM.
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::patchableBranch8):
2018-09-20 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r236293.
Internal build still broken.
Reverted changeset:
"Add functions to measure memory footprint to JSC"
https://bugs.webkit.org/show_bug.cgi?id=189768
https://trac.webkit.org/changeset/236293
2018-09-20 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Heap::reportExtraMemoryVisited shows contention if we have many JSString
https://bugs.webkit.org/show_bug.cgi?id=189558
Reviewed by Mark Lam.
When running web-tooling-benchmark postcss test on Linux JSCOnly port, we get the following result in `perf report`.
10.95% AutomaticThread libJavaScriptCore.so.1.0.0 [.] JSC::Heap::reportExtraMemoryVisited
This is because postcss produces bunch of JSString, which require reportExtraMemoryVisited calls in JSString::visitChildren.
And since reportExtraMemoryVisited attempts to update atomic counter, if we have bunch of marking threads, it becomes super contended.
This patch reduces the frequency of updating the atomic counter. Each SlotVisitor has per-SlotVisitor m_extraMemorySize counter.
And we propagate this value to the global atomic counter when rebalance happens.
We also reduce HeapCell::heap() access by using `vm.heap`.
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::didStartMarking):
(JSC::SlotVisitor::propagateExternalMemoryVisitedIfNecessary):
(JSC::SlotVisitor::drain):
(JSC::SlotVisitor::performIncrementOfDraining):
* heap/SlotVisitor.h:
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::reportExtraMemoryVisited):
* runtime/JSString.cpp:
(JSC::JSRopeString::resolveRopeToAtomicString const):
(JSC::JSRopeString::resolveRope const):
* runtime/JSString.h:
(JSC::JSString::finishCreation):
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::finishCreation):
* wasm/js/JSWebAssemblyMemory.cpp:
(JSC::JSWebAssemblyMemory::finishCreation):
2018-09-20 Michael Saboff <msaboff@apple.com>
Add functions to measure memory footprint to JSC
https://bugs.webkit.org/show_bug.cgi?id=189768
Reviewed by Saam Barati.
Rolling this back in.
Provide system memory metrics for the current process to aid in memory reduction measurement and
tuning using native JS tests.
* jsc.cpp:
(MemoryFootprint::now):
(MemoryFootprint::resetPeak):
(GlobalObject::finishCreation):
(JSCMemoryFootprint::JSCMemoryFootprint):
(JSCMemoryFootprint::createStructure):
(JSCMemoryFootprint::create):
(JSCMemoryFootprint::finishCreation):
(JSCMemoryFootprint::addProperty):
(functionResetMemoryPeak):
2018-09-20 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r236235.
Breaks internal builds.
Reverted changeset:
"Add functions to measure memory footprint to JSC"
https://bugs.webkit.org/show_bug.cgi?id=189768
https://trac.webkit.org/changeset/236235
2018-09-20 Fujii Hironori <Hironori.Fujii@sony.com>
[Win][Clang] JITMathIC.h: error: missing 'template' keyword prior to dependent template name 'retagged'
https://bugs.webkit.org/show_bug.cgi?id=189730
Reviewed by Saam Barati.
Clang for Windows can't compile the workaround for MSVC quirk in generateOutOfLine.
* jit/JITMathIC.h:
(generateOutOfLine): Append "&& !COMPILER(CLANG)" to "#if COMPILER(MSVC)".
2018-09-19 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] Optimize Array#indexOf in C++ runtime
https://bugs.webkit.org/show_bug.cgi?id=189507
Reviewed by Saam Barati.
C++ Array#indexOf runtime function takes so much time in babylon benchmark in
web-tooling-benchmark. While our DFG and FTL has Array#indexOf optimization
and actually it is working well, C++ Array#indexOf is called significant amount
of time before tiering up, and it takes 6.74% of jsc main thread samples according
to perf command in Linux. This is because C++ Array#indexOf is too generic and
misses the chance to optimize JSArray cases.
This patch adds JSArray fast path for Array#indexOf. If we know that indexed
access to the given JSArray is non-observable and indexing type is good for the fast
path, we go to the fast path. This makes sampling of Array#indexOf 3.83% in
babylon web-tooling-benchmark.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncIndexOf):
* runtime/JSArray.h:
* runtime/JSArrayInlines.h:
(JSC::JSArray::canDoFastIndexedAccess):
(JSC::toLength):
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::JSValue):
* runtime/JSGlobalObject.h:
* runtime/JSGlobalObjectInlines.h:
(JSC::JSGlobalObject::isArrayPrototypeIndexedAccessFastAndNonObservable):
(JSC::JSGlobalObject::isArrayPrototypeIteratorProtocolFastAndNonObservable):
* runtime/MathCommon.h:
(JSC::canBeStrictInt32):
(JSC::canBeInt32):
2018-09-19 Michael Saboff <msaboff@apple.com>
Add functions to measure memory footprint to JSC
https://bugs.webkit.org/show_bug.cgi?id=189768
Reviewed by Saam Barati.
Provide system memory metrics for the current process to aid in memory reduction measurement and
tuning using native JS tests.
* jsc.cpp:
(MemoryFootprint::now):
(MemoryFootprint::resetPeak):
(GlobalObject::finishCreation):
(JSCMemoryFootprint::JSCMemoryFootprint):
(JSCMemoryFootprint::createStructure):
(JSCMemoryFootprint::create):
(JSCMemoryFootprint::finishCreation):
(JSCMemoryFootprint::addProperty):
(functionResetMemoryPeak):
2018-09-19 Saam barati <sbarati@apple.com>
CheckStructureOrEmpty should pass in a tempGPR to emitStructureCheck since it may jump over that code
https://bugs.webkit.org/show_bug.cgi?id=189703
Reviewed by Mark Lam.
This fixes a crash that a TypeProfiler change revealed.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
2018-09-19 Saam barati <sbarati@apple.com>
AI rule for MultiPutByOffset executes its effects in the wrong order
https://bugs.webkit.org/show_bug.cgi?id=189757
<rdar://problem/43535257>
Reviewed by Michael Saboff.
The AI rule for MultiPutByOffset was executing effects in the wrong order.
It first executed the transition effects and the effects on the base, and
then executed the filtering effects on the value being stored. However, you
can end up with the wrong type when the base and the value being stored
are the same. E.g, in a program like `o.f = o`. These effects need to happen
in the opposite order, modeling what happens in the runtime executing of
MultiPutByOffset.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2018-09-18 Mark Lam <mark.lam@apple.com>
Ensure that ForInContexts are invalidated if their loop local is over-written.
https://bugs.webkit.org/show_bug.cgi?id=189571
<rdar://problem/44402277>
Reviewed by Saam Barati.
Instead of hunting down every place in the BytecodeGenerator that potentially
needs to invalidate an enclosing ForInContext (if one exists), we simply iterate
the bytecode range of the loop body when the ForInContext is popped, and
invalidate the context if we ever find the loop temp variable over-written.
This has 2 benefits:
1. It ensures that every type of opcode that can write to the loop temp will be
handled appropriately, not just the op_mov that we've hunted down.
2. It avoids us having to check the BytecodeGenerator's m_forInContextStack
every time we emit an op_mov (or other opcodes that can write to a local)
even when we're not inside a for-in loop.
JSC benchmarks show that that this change is performance neutral.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::pushIndexedForInScope):
(JSC::BytecodeGenerator::popIndexedForInScope):
(JSC::BytecodeGenerator::pushStructureForInScope):
(JSC::BytecodeGenerator::popStructureForInScope):
(JSC::ForInContext::finalize):
(JSC::StructureForInContext::finalize):
(JSC::IndexedForInContext::finalize):
(JSC::BytecodeGenerator::invalidateForInContextForLocal): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::ForInContext::ForInContext):
(JSC::ForInContext::bodyBytecodeStartOffset const):
(JSC::StructureForInContext::StructureForInContext):
(JSC::IndexedForInContext::IndexedForInContext):
* bytecompiler/NodesCodegen.cpp:
(JSC::PostfixNode::emitResolve):
(JSC::PrefixNode::emitResolve):
(JSC::ReadModifyResolveNode::emitBytecode):
(JSC::AssignResolveNode::emitBytecode):
(JSC::EmptyLetExpression::emitBytecode):
(JSC::ForInNode::emitLoopHeader):
(JSC::ForOfNode::emitBytecode):
(JSC::BindingNode::bindValue const):
(JSC::AssignmentElementNode::bindValue const):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
2018-09-17 Devin Rousso <drousso@apple.com>
Web Inspector: generate CSSKeywordCompletions from backend values
https://bugs.webkit.org/show_bug.cgi?id=189041
Reviewed by Joseph Pecoraro.
* inspector/protocol/CSS.json:
Include an optional `aliases` array and `inherited` boolean for `CSSPropertyInfo`.
2018-09-17 Saam barati <sbarati@apple.com>
We must convert ProfileType to CheckStructureOrEmpty instead of CheckStructure
https://bugs.webkit.org/show_bug.cgi?id=189676
<rdar://problem/39682897>
Reviewed by Michael Saboff.
Because the incoming value may be TDZ, CheckStructure may end up crashing.
Since the Type Profile does not currently record TDZ values in any of its
data structures, this is not a semantic change in how it will show you data.
It just fixes crashes when we emit a CheckStructure and the incoming value
is TDZ.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToCheckStructureOrEmpty):
2018-09-17 Darin Adler <darin@apple.com>
Use OpaqueJSString rather than JSRetainPtr inside WebKit
https://bugs.webkit.org/show_bug.cgi?id=189652
Reviewed by Saam Barati.
* API/JSCallbackObjectFunctions.h: Removed an uneeded include of
JSStringRef.h.
* API/JSContext.mm:
(-[JSContext evaluateScript:withSourceURL:]): Use OpaqueJSString::create rather
than JSStringCreateWithCFString, simplifying the code and also obviating the
need for explicit JSStringRelease.
(-[JSContext setName:]): Ditto.
* API/JSStringRef.cpp:
(JSStringIsEqualToUTF8CString): Use adoptRef rather than explicit JSStringRelease.
It seems that additional optimization is possible, obviating the need to allocate
an OpaqueJSString, but that's true almost everywhere else in this patch, too.
* API/JSValue.mm:
(+[JSValue valueWithNewRegularExpressionFromPattern:flags:inContext:]): Use
OpaqueJSString::create and adoptRef as appropriate.
(+[JSValue valueWithNewErrorFromMessage:inContext:]): Ditto.
(+[JSValue valueWithNewSymbolFromDescription:inContext:]): Ditto.
(performPropertyOperation): Ditto.
(-[JSValue invokeMethod:withArguments:]): Ditto.
(valueToObjectWithoutCopy): Ditto.
(containerValueToObject): Ditto.
(valueToString): Ditto.
(objectToValueWithoutCopy): Ditto.
(objectToValue): Ditto.
2018-09-08 Darin Adler <darin@apple.com>
Streamline JSRetainPtr, fix leaks of JSString and JSGlobalContext
https://bugs.webkit.org/show_bug.cgi?id=189455
Reviewed by Keith Miller.
* API/JSObjectRef.cpp:
(OpaqueJSPropertyNameArray): Use Ref<OpaqueJSString> instead of
JSRetainPtr<JSStringRef>.
(JSObjectCopyPropertyNames): Remove now-unneeded use of leakRef and
adopt constructor.
(JSPropertyNameArrayGetNameAtIndex): Use ptr() instead of get() since
the array elements are now Ref.
* API/JSRetainPtr.h: While JSRetainPtr is written as a template,
it only works for two specific unrelated types, JSStringRef and
JSGlobalContextRef. Simplified the default constructor using data
member initialization. Prepared to make the adopt constructor private
(got everything compiling that way, then made it public again so that
Apple internal software will still build). Got rid of unneeded
templated constructor and assignment operator, since it's not relevant
since there is no inheritance between JSRetainPtr template types.
Added WARN_UNUSED_RETURN to leakRef as in RefPtr and RetainPtr.
Added move constructor and move assignment operator for slightly better
performance. Simplified implementations of various member functions
so they are more obviously correct, by using leakPtr in more of them
and using std::exchange to make the flow of values more obvious.
* API/JSValue.mm:
(+[JSValue valueWithNewSymbolFromDescription:inContext:]): Added a
missing JSStringRelease to fix a leak.
* API/tests/CustomGlobalObjectClassTest.c:
(customGlobalObjectClassTest): Added a JSGlobalContextRelease to fix a leak.
(globalObjectSetPrototypeTest): Ditto.
(globalObjectPrivatePropertyTest): Ditto.
* API/tests/ExecutionTimeLimitTest.cpp:
(testResetAfterTimeout): Added a call to JSStringRelease to fix a leak.
(testExecutionTimeLimit): Ditto, lots more.
* API/tests/FunctionOverridesTest.cpp:
(testFunctionOverrides): Added a call to JSStringRelease to fix a leak.
* API/tests/JSObjectGetProxyTargetTest.cpp:
(testJSObjectGetProxyTarget): Added a call to JSGlobalContextRelease to fix
a leak.
* API/tests/PingPongStackOverflowTest.cpp:
(testPingPongStackOverflow): Added calls to JSGlobalContextRelease and
JSStringRelease to fix leaks.
* API/tests/testapi.c:
(throwException): Added. Helper function for repeated idiom where we want
to throw an exception, but with additional JSStringRelease calls so we don't
have to leak just to keep the code simpler to read.
(MyObject_getProperty): Use throwException.
(MyObject_setProperty): Ditto.
(MyObject_deleteProperty): Ditto.
(isValueEqualToString): Added. Helper function for an idiom where we check
if something is a string and then if it's equal to a particular string
constant, but a version that has an additional JSStringRelease call so we
don't have to leak just to keep the code simpler to read.
(MyObject_callAsFunction): Use isValueEqualToString and throwException.
(MyObject_callAsConstructor): Ditto.
(MyObject_hasInstance): Ditto.
(globalContextNameTest): Added a JSGlobalContextRelease to fix a leak.
(testMarkingConstraintsAndHeapFinalizers): Ditto.
2018-09-14 Saam barati <sbarati@apple.com>
Don't dump OSRAvailabilityData in Graph::dump because a stale Availability may point to a Node that is already freed
https://bugs.webkit.org/show_bug.cgi?id=189628
<rdar://problem/39481690>
Reviewed by Mark Lam.
An Availability may point to a Node. And that Node may be removed from
the graph, e.g, it's freed and its memory is no longer owned by Graph.
This patch makes it so we no longer dump this metadata by default. If
this metadata is interesting to you, you'll need to go in and change
Graph::dump to dump the needed metadata.
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
2018-09-14 Mark Lam <mark.lam@apple.com>
Refactor some ForInContext code for better encapsulation.
https://bugs.webkit.org/show_bug.cgi?id=189626
<rdar://problem/44466415>
Reviewed by Keith Miller.
1. Add a ForInContext::m_type field to store the context type. This does not
increase the class size, but eliminates the need for a virtual call to get the
type.
Note: we still need a virtual destructor because we'll be mingling
IndexedForInContexts and StructureForInContexts in the BytecodeGenerator::m_forInContextStack.
2. Add ForInContext::isIndexedForInContext() and ForInContext::isStructureForInContext()
convenience methods.
3. Add ForInContext::asIndexedForInContext() and ForInContext::asStructureForInContext()
to do the casting to the subclass types. This ensures that we'll properly
assert that the casting is legal.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitGetByVal):
(JSC::BytecodeGenerator::popIndexedForInScope):
(JSC::BytecodeGenerator::popStructureForInScope):
* bytecompiler/BytecodeGenerator.h:
(JSC::ForInContext::type const):
(JSC::ForInContext::isIndexedForInContext const):
(JSC::ForInContext::isStructureForInContext const):
(JSC::ForInContext::asIndexedForInContext):
(JSC::ForInContext::asStructureForInContext):
(JSC::ForInContext::ForInContext):
(JSC::StructureForInContext::StructureForInContext):
(JSC::IndexedForInContext::IndexedForInContext):
(JSC::ForInContext::~ForInContext): Deleted.
2018-09-14 Devin Rousso <webkit@devinrousso.com>
Web Inspector: Record actions performed on ImageBitmapRenderingContext
https://bugs.webkit.org/show_bug.cgi?id=181341
Reviewed by Joseph Pecoraro.
* inspector/protocol/Recording.json:
* inspector/scripts/codegen/generator.py:
2018-09-14 Mike Gorse <mgorse@suse.com>
builtins directory causes name conflict on Python 3
https://bugs.webkit.org/show_bug.cgi?id=189552
Reviewed by Michael Catanzaro.
* CMakeLists.txt: builtins -> wkbuiltins.
* DerivedSources.make: builtins -> wkbuiltins.
* Scripts/generate-js-builtins.py: import wkbuiltins, rather than
builtins.
* Scripts/wkbuiltins/__init__.py: Renamed from Source/JavaScriptCore/Scripts/builtins/__init__.py.
* Scripts/wkbuiltins/builtins_generate_combined_header.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generate_combined_header.py.
* Scripts/wkbuiltins/builtins_generate_internals_wrapper_implementation.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generate_internals_wrapper_implementation.py.
* Scripts/wkbuiltins/builtins_generate_separate_header.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generate_separate_header.py.
* Scripts/wkbuiltins/builtins_generate_separate_implementation.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generate_separate_implementation.py.
* Scripts/wkbuiltins/builtins_generate_wrapper_header.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generate_wrapper_header.py.
* Scripts/wkbuiltins/builtins_generate_wrapper_implementation.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generate_wrapper_implementation.py.
* Scripts/wkbuiltins/builtins_generator.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generator.py.
* Scripts/wkbuiltins/builtins_model.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_model.py.
* Scripts/wkbuiltins/builtins_templates.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_templates.py.
* Scripts/wkbuiltins/wkbuiltins.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins.py.
* JavaScriptCore.xcodeproj/project.pbxproj: Update for the renaming.
2018-09-13 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[WebAssembly] Inline WasmContext accessor functions
https://bugs.webkit.org/show_bug.cgi?id=189416
Reviewed by Saam Barati.
WasmContext accessor functions are very small while it resides in the critical path of
JS to Wasm function call. This patch makes them inline to improve performance.
This change improves a small benchmark (calling JS to Wasm function 1e7 times) from 320ms to 270ms.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* interpreter/CallFrame.cpp:
* jit/AssemblyHelpers.cpp:
* wasm/WasmB3IRGenerator.cpp:
* wasm/WasmContextInlines.h: Renamed from Source/JavaScriptCore/wasm/WasmContext.cpp.
(JSC::Wasm::Context::useFastTLS):
(JSC::Wasm::Context::load const):
(JSC::Wasm::Context::store):
* wasm/WasmMemoryInformation.cpp:
* wasm/WasmModuleParser.cpp: Include <wtf/SHA1.h> due to changes of unified source combinations.
* wasm/js/JSToWasm.cpp:
* wasm/js/WebAssemblyFunction.cpp:
2018-09-12 David Kilzer <ddkilzer@apple.com>
Move JavaScriptCore files to match Xcode project hierarchy
<https://webkit.org/b/189574>
Reviewed by Filip Pizlo.
* API/JSAPIValueWrapper.cpp: Rename from Source/JavaScriptCore/runtime/JSAPIValueWrapper.cpp.
* API/JSAPIValueWrapper.h: Rename from Source/JavaScriptCore/runtime/JSAPIValueWrapper.h.
* CMakeLists.txt: Update for new path to
generateYarrUnicodePropertyTables.py, hasher.py and
JSAPIValueWrapper.h.
* DerivedSources.make: Ditto. Add missing dependency on
hasher.py captured by CMakeLists.txt.
* JavaScriptCore.xcodeproj/project.pbxproj: Update for new file
reference paths. Add hasher.py library to project.
* Sources.txt: Update for new path to
JSAPIValueWrapper.cpp.
* runtime/JSImmutableButterfly.h: Add missing includes
after changes to Sources.txt and regenerating unified
sources.
* runtime/RuntimeType.h: Ditto.
* yarr/generateYarrUnicodePropertyTables.py: Rename from Source/JavaScriptCore/Scripts/generateYarrUnicodePropertyTables.py.
* yarr/hasher.py: Rename from Source/JavaScriptCore/Scripts/hasher.py.
2018-09-12 David Kilzer <ddkilzer@apple.com>
Let Xcode have its way with the JavaScriptCore project
* JavaScriptCore.xcodeproj/project.pbxproj:
2018-09-12 Guillaume Emont <guijemont@igalia.com>
Add IGNORE_WARNING_.* macros
https://bugs.webkit.org/show_bug.cgi?id=188996
Reviewed by Michael Catanzaro.
* API/JSCallbackObject.h:
* API/tests/testapi.c:
* assembler/LinkBuffer.h:
(JSC::LinkBuffer::finalizeCodeWithDisassembly):
* b3/B3LowerToAir.cpp:
* b3/B3Opcode.cpp:
* b3/B3Type.h:
* b3/B3TypeMap.h:
* b3/B3Width.h:
* b3/air/AirArg.cpp:
* b3/air/AirArg.h:
* b3/air/AirCode.h:
* bytecode/Opcode.h:
(JSC::padOpcodeName):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::speculateNumber):
(JSC::DFG::SpeculativeJIT::speculateMisc):
* dfg/DFGSpeculativeJIT64.cpp:
* ftl/FTLOutput.h:
* jit/CCallHelpers.h:
(JSC::CCallHelpers::calculatePokeOffset):
* llint/LLIntData.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::slowPathLogF):
* runtime/ConfigFile.cpp:
(JSC::ConfigFile::canonicalizePaths):
* runtime/JSDataViewPrototype.cpp:
* runtime/JSGenericTypedArrayViewConstructor.h:
* runtime/JSGenericTypedArrayViewPrototype.h:
* runtime/Options.cpp:
(JSC::Options::setAliasedOption):
* tools/CodeProfiling.cpp:
* wasm/WasmSections.h:
* wasm/generateWasmValidateInlinesHeader.py:
== Rolled over to ChangeLog-2018-09-11 ==