Google Git
Sign in
webkit / WebKit / 3e02316f71e46ff13cd73ceeccefc77058ff8116 / . / Source / JavaScriptCore / ChangeLog
blob: b38f3ccfbe835ffc8d6e8af54dcda437747afb2d [file] [log] [blame]
2021-07-30 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use UCPURegister argument to remove zero extension in JIT code
https://bugs.webkit.org/show_bug.cgi?id=228625
Reviewed by Robin Morisset.
Yarr JIT code emits zeroExtend32ToWord for some arguments, but this is not necessary if
argument is defined as UCPURegister. In that case, caller guarantees that top 32bits are
cleared.
* yarr/YarrJIT.cpp:
* yarr/YarrJIT.h:
2021-07-29 Myles C. Maxfield <mmaxfield@apple.com>
Stop building WebGPU and the WHLSL compiler to decrease binary size
https://bugs.webkit.org/show_bug.cgi?id=228179
Reviewed by Dean Jackson, Robin Morisset, and Devin Rousso.
This patch deletes the existing implementation just to reduce binary size in releases of WebKit
which don't enable WebGPU by default. It doesn't represent a change in direction or policy or
anything regarding WebGPU. It's a (somewhat temporary) pragmatic change.
Our current implementation of WebGPU:
1. Is off by default on all platforms
2. Is extremely outdated
3. Has no notion of the GPU Process, and therefore needs to be redesigned and largely rewritten
4. Only implements a fraction of what is in the spec
Removing the code from the tree doesn't delete it from existence; it's still in source control.
The benefit of reducing binary size seems to outweigh having this code in the tree.
* inspector/protocol/Canvas.json:
* inspector/scripts/codegen/generator.py:
2021-07-29 Carlos Alberto Lopez Perez <clopez@igalia.com>
[WPE][GTK] build broken with python2 after r280382
https://bugs.webkit.org/show_bug.cgi?id=228629
Reviewed by Philippe Normand.
Call {PYTHON_EXECUTABLE} instead of python3.
* PlatformGTK.cmake:
2021-07-29 Tadeu Zagallo <tzagallo@apple.com>
definePropertyOnReceiver should check if receiver canPerformFastPutInline
https://bugs.webkit.org/show_bug.cgi?id=227963
<rdar://80259710>
Reviewed by Alexey Shvayka.
definePropertyOnReceiver has a fast path if the slot is not opaque and the receiver doesn't
have a custom defineOwnProperty implementation, in which case it calls putInlineFast (and
transitively putDirectInternal<PutModePut>). The issue is that putDirectInternal does not
handle customValues correctly: it just overwrites the property without changing the attributes.
To fix that, we should first check if the property might be a custom value, and if that's the case
we now call `definePropertyOnReceiverSlow`, which has been updated to handle custom values correctly.
I also added assertions to putInlineFastReplacingStaticPropertyIfNeeded and putDirectInternal
to make sure we don't accidentally overwrite custom values in the future.
* runtime/JSObject.cpp:
(JSC::definePropertyOnReceiverSlow):
(JSC::JSObject::definePropertyOnReceiver):
(JSC::JSObject::putInlineFastReplacingStaticPropertyIfNeeded):
* runtime/JSObjectInlines.h:
(JSC::JSObject::putDirectInternal):
2021-07-29 Yusuke Suzuki <ysuzuki@apple.com> and Alexey Shvayka <shvaikalesh@gmail.com>
[JSC] Legacy RegExp fields should be accessors
https://bugs.webkit.org/show_bug.cgi?id=220233
Reviewed by Tadeu Zagallo.
This patch implements a part of Legacy RegExp features proposal [1], replacing
custom values with custom accessors that require |this| value to be RegExp
constructor of the same realm.
Apart from fixing property descriptors, this change brings legacy RegExpConstructor
fields in compliance with invariants of internal methods [2] (described in #151348),
aligning JSC with V8 and SpiderMonkey.
It doesn't, however, implement [[LegacyFeaturesEnabled]] and RegExp.prototype.compile
changes.
[1]: https://github.com/tc39/proposal-regexp-legacy-features
[2]: https://tc39.es/ecma262/#sec-invariants-of-the-essential-internal-methods
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateImpl):
* runtime/RegExpConstructor.cpp:
(JSC::JSC_DEFINE_CUSTOM_GETTER):
(JSC::JSC_DEFINE_CUSTOM_SETTER):
(JSC::regExpConstructorDollarImpl): Deleted.
* tools/JSDollarVM.cpp:
2021-07-29 Myles C. Maxfield <mmaxfield@apple.com>
Add WebGPU to webkit.org/status
https://bugs.webkit.org/show_bug.cgi?id=228623
Reviewed by Robin Morisset.
* features.json:
2021-07-28 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Yarr should perform BoyerMoore search
https://bugs.webkit.org/show_bug.cgi?id=228301
Reviewed by Saam Barati.
This patch emits skipping fast-path at the beginning of body alternatives with a large stride. So we can quickly discard unrelated characters
and attempt to find possibly related sequence in the long sequence. The method is derived from V8's implementation (with some extensions).
If we have a searching pattern /abcdef/, then we can check the 6th character against a set of {a, b, c, d, e, f}.
If it does not match, we can shift 6 characters. We use this strategy since this way can be extended easily to support
disjunction, character-class, and ignore-cases. For example, in the case of /(?:abc|def)/, we can check 3rd character
against {a, b, c, d, e, f} and shift 3 characters if it does not match.
Then, the best way to perform the above shifting is that finding the longest character sequence which does not have
many candidates. In the case of /[a-z]aaaaaaa[a-z]/, we can extract "aaaaaaa" sequence and check 8th character against {a}.
If it does not match, then we can shift 7 characters (length of "aaaaaaa"). This shifting is better than using "[a-z]aaaaaaa[a-z]"
sequence and {a-z} set since {a-z} set will almost always match.
We first collect possible characters for each character position. Then, apply heuristics to extract good character sequence from
that and construct fast searching with long stride.
Microbenchmark which performs RegExp ops in Speedometer2/jQuery-TodoMVC shows 25% improvement.
ToT Patched
jquery-todomvc-regexp 723.9739+-1.3997 ^ 579.1698+-1.2505 ^ definitely 1.2500x faster
This improves Speedometer2/jQuery-TodoMVC by 3%.
----------------------------------------------------------------------------------------------------------------------------------
| subtest | ms | ms | b / a | pValue (significance using False Discovery Rate) |
----------------------------------------------------------------------------------------------------------------------------------
| Elm-TodoMVC |123.365625 |123.456250 |1.000735 | 0.804077 |
| VueJS-TodoMVC |26.912500 |26.925000 |1.000464 | 0.969603 |
| EmberJS-TodoMVC |127.540625 |127.562500 |1.000172 | 0.960474 |
| BackboneJS-TodoMVC |50.606250 |50.518750 |0.998271 | 0.670313 |
| Preact-TodoMVC |21.018750 |20.850000 |0.991971 | 0.563818 |
| AngularJS-TodoMVC |136.943750 |137.271875 |1.002396 | 0.531513 |
| Vanilla-ES2015-TodoMVC |68.521875 |68.593750 |1.001049 | 0.701376 |
| Inferno-TodoMVC |65.559375 |65.803125 |1.003718 | 0.414418 |
| Flight-TodoMVC |77.284375 |76.715625 |0.992641 | 0.219870 |
| Angular2-TypeScript-TodoMVC |40.725000 |40.318750 |0.990025 | 0.281212 |
| VanillaJS-TodoMVC |55.209375 |54.715625 |0.991057 | 0.056921 |
| jQuery-TodoMVC |266.396875 |258.471875 |0.970251 | 0.000000 (significant) |
| EmberJS-Debug-TodoMVC |341.550000 |341.856250 |1.000897 | 0.618140 |
| React-TodoMVC |88.731250 |88.871875 |1.001585 | 0.512407 |
| React-Redux-TodoMVC |150.340625 |150.065625 |0.998171 | 0.412940 |
| Vanilla-ES2015-Babel-Webpack-TodoMVC |65.390625 |65.362500 |0.999570 | 0.834760 |
----------------------------------------------------------------------------------------------------------------------------------
a mean = 245.96997
b mean = 246.86366
pValue = 0.0061448402
(Bigger means are better.)
1.004 times better
Results ARE significant
* runtime/OptionsList.h:
* yarr/YarrJIT.cpp:
(JSC::Yarr::BoyerMooreInfo::BoyerMooreInfo):
(JSC::Yarr::BoyerMooreInfo::length const):
(JSC::Yarr::BoyerMooreInfo::set):
(JSC::Yarr::BoyerMooreInfo::index const):
(JSC::Yarr::BoyerMooreInfo::setIndex):
(JSC::Yarr::BoyerMooreInfo::create):
(JSC::Yarr::BoyerMooreInfo::findBestCharacterSequence const):
(JSC::Yarr::BoyerMooreInfo::findWorthwhileCharacterSequenceForLookahead const):
(JSC::Yarr::BoyerMooreInfo::createCandidateBitmap const):
* yarr/YarrJIT.h:
(JSC::Yarr::BoyerMooreBitmap::count const):
(JSC::Yarr::BoyerMooreBitmap::map const):
(JSC::Yarr::BoyerMooreBitmap::isMaskEffective const):
(JSC::Yarr::BoyerMooreBitmap::add):
(JSC::Yarr::BoyerMooreByteVector::BoyerMooreByteVector):
(JSC::Yarr::YarrCodeBlock::set8BitCode):
(JSC::Yarr::YarrCodeBlock::set16BitCode):
(JSC::Yarr::YarrCodeBlock::set8BitCodeMatchOnly):
(JSC::Yarr::YarrCodeBlock::set16BitCodeMatchOnly):
(JSC::Yarr::YarrCodeBlock::clear):
(JSC::Yarr::YarrCodeBlock::findSameVector const):
2021-07-28 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] load/store with BaseIndex is inefficient in ARM64
https://bugs.webkit.org/show_bug.cgi?id=228543
Reviewed by Mark Lam.
While we are frequently using load + BaseIndex (with offset) in RegExp code,
we emit 3 instructions in ARM64. This can be represented in 2 instructions.
This patch adds that path to make generated code tight in ARM64 RegExp.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::load64):
(JSC::MacroAssemblerARM64::load32):
(JSC::MacroAssemblerARM64::load16):
(JSC::MacroAssemblerARM64::load16SignedExtendTo32):
(JSC::MacroAssemblerARM64::load8):
(JSC::MacroAssemblerARM64::load8SignedExtendTo32):
(JSC::MacroAssemblerARM64::store64):
(JSC::MacroAssemblerARM64::store32):
(JSC::MacroAssemblerARM64::store16):
(JSC::MacroAssemblerARM64::store8):
(JSC::MacroAssemblerARM64::loadDouble):
(JSC::MacroAssemblerARM64::loadFloat):
(JSC::MacroAssemblerARM64::storeDouble):
(JSC::MacroAssemblerARM64::storeFloat):
(JSC::MacroAssemblerARM64::tryFoldBaseAndOffsetPart):
* assembler/testmasm.cpp:
(JSC::testLoadBaseIndex):
(JSC::testStoreBaseIndex):
2021-07-28 Philippe Normand <pnormand@igalia.com>
[WPE][GTK] SVN_REVISION drifting away if bots don't re-run cmake
https://bugs.webkit.org/show_bug.cgi?id=228290
Reviewed by Michael Catanzaro.
* PlatformGTK.cmake: Expand ${BUILD_REVISION} with apply-build-revision-to-files.py for
non-tarball builds, or let CMake do it for tarball builds.
* javascriptcoregtk.pc.in: Switch revision var to ${} format, so that we can choose to
either let CMake expand it or do it ourselves.
2021-07-27 Patrick Angle <pangle@apple.com>
Web Inspector: [Cocoa] "RemoteInspector XPC connection to relay failed." messages are confusing in StdErr
https://bugs.webkit.org/show_bug.cgi?id=228303
Reviewed by Darin Adler.
Remove overly verbose and confusing `WTFLogAlways` messages added in r278413, which can confuse applications
listening to stderr of a process using JavaScriptCore.
* inspector/remote/cocoa/RemoteInspectorCocoa.mm:
(Inspector::RemoteInspector::xpcConnectionFailed):
2021-07-27 Alexey Shvayka <shvaikalesh@gmail.com>
ProxyObject callees should be skipped during Function.prototype.caller resolution
https://bugs.webkit.org/show_bug.cgi?id=228341
Reviewed by Yusuke Suzuki.
Just like a bound function, a Proxy with nullish "apply" handler merely forwards
[[Call]] to its target [1], without pushing onto the execution context stack.
This fact is also noted in Function.prototype.{caller,arguments} reflection proposal [2].
This patch aligns JSC with V8 and SpiderMonkey if Proxy's "apply" handler is userland
or nullish. However, since JSC implements proper tail calls, `Function.prototype.caller`
result is divergent from other engines if the handler is `Reflect.apply`, which performs
a tail call that gets optimized away [2] (unless called by another Proxy).
[1]: https://tc39.es/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-call-thisargument-argumentslist (step 8)
[2]: https://github.com/claudepache/es-legacy-function-reflection/blob/master/spec.md#get-functionprototypecaller (see notes)
* runtime/FunctionPrototype.cpp:
(JSC::RetrieveCallerFunctionFunctor::operator() const):
2021-07-26 Yusuke Suzuki <ysuzuki@apple.com>
Add Temporal to features.json
https://bugs.webkit.org/show_bug.cgi?id=228292
Reviewed by Myles C. Maxfield.
* features.json:
2021-07-25 Alexey Shvayka <shvaikalesh@gmail.com>
Partly implement Function.prototype.{caller,arguments} reflection proposal
https://bugs.webkit.org/show_bug.cgi?id=158116
Reviewed by Yusuke Suzuki.
To ensure web-compatibility, only the safe subset of Function.prototype.{caller,arguments}
reflection proposal [1] is implemented, which is currently shipped in SpiderMonkey.
Complete list of differences from the proposed spec:
1. Cross-realm receiver function is allowed instead of throwing a TypeError.
Throwing is likely safe to ship, but #225997 needs to be fixed first for
custom properties to receive correct global object.
2. Cross-realm caller function is returned instead of `null`.
Hiding cross-realm caller may break things: we currently have a test for
the opposite behavior.
3. Defines "caller" and "arguments" setters that throw for disallowed receivers,
instead failing silently in sloppy mode.
This is actually more restrictive than the spec, which is preferable,
and aligns with V8 and SM.
Most importantly, this patch removes own "caller" and "arguments" properties from
sloppy mode ES5 functions. They were non-configurable, making it harder to use
their holder as a [[ProxyTarget]]. They were also non-writable, with a constantly
changing [[Value]], which violated the invariants of internal methods [2].
As a result, JSFunction methods are greatly simplified, especially defineOwnProperty()
and getOwnSpecialPropertyNames(). The latter is now 2.1x faster according to the
provided microbenchmark. Also, removes double "prototype" lookup from [[Get]],
which is a 10% progression.
[1]: https://github.com/claudepache/es-legacy-function-reflection
[2]: https://tc39.es/ecma262/#sec-invariants-of-the-essential-internal-methods
* runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::getOwnPropertySlot):
(JSC::ClonedArguments::materializeSpecials):
* runtime/FunctionExecutable.h:
* runtime/FunctionPrototype.cpp:
(JSC::FunctionPrototype::addFunctionProperties):
(JSC::isAllowedReceiverFunctionForCallerAndArguments):
(JSC::RetrieveArgumentsFunctor::RetrieveArgumentsFunctor):
(JSC::RetrieveArgumentsFunctor::result const):
(JSC::RetrieveArgumentsFunctor::operator() const):
(JSC::retrieveArguments):
(JSC::JSC_DEFINE_CUSTOM_GETTER):
(JSC::RetrieveCallerFunctionFunctor::RetrieveCallerFunctionFunctor):
(JSC::RetrieveCallerFunctionFunctor::result const):
(JSC::RetrieveCallerFunctionFunctor::operator() const):
(JSC::retrieveCallerFunction):
(JSC::JSC_DEFINE_CUSTOM_SETTER):
(JSC::FunctionPrototype::initRestrictedProperties): Deleted.
* runtime/FunctionPrototype.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::getOwnPropertySlot):
(JSC::JSFunction::getOwnSpecialPropertyNames):
(JSC::JSFunction::put):
(JSC::JSFunction::deleteProperty):
(JSC::JSFunction::defineOwnProperty):
(JSC::RetrieveArgumentsFunctor::RetrieveArgumentsFunctor): Deleted.
(JSC::RetrieveArgumentsFunctor::result const): Deleted.
(JSC::RetrieveArgumentsFunctor::operator() const): Deleted.
(JSC::retrieveArguments): Deleted.
(JSC::JSC_DEFINE_CUSTOM_GETTER): Deleted.
(JSC::RetrieveCallerFunctionFunctor::RetrieveCallerFunctionFunctor): Deleted.
(JSC::RetrieveCallerFunctionFunctor::result const): Deleted.
(JSC::RetrieveCallerFunctionFunctor::operator() const): Deleted.
(JSC::retrieveCallerFunction): Deleted.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildrenImpl):
* runtime/JSGlobalObject.h:
Remove unused m_throwTypeErrorGetterSetter and make [[ThrowTypeError]] lazily-created.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/JSGlobalObjectFunctions.h:
* runtime/JSObject.cpp:
(JSC::JSObject::putDirectCustomGetterSetterWithoutTransition):
* runtime/JSObject.h:
2021-07-24 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Change most of enum in Yarr to enum-class
https://bugs.webkit.org/show_bug.cgi?id=228264
Reviewed by Mark Lam.
This patch simply changes most of enum to enum-class in Yarr.
We also remove YarrJIT YarrGenerator's template parameter since
it is not worth doubling code. We can just hold Yarr::JITCompileMode as m_compileMode.
* runtime/RegExp.cpp:
(JSC::RegExp::compile):
(JSC::RegExp::matchConcurrently):
(JSC::RegExp::compileMatchOnly):
* runtime/RegExp.h:
* runtime/RegExpInlines.h:
(JSC::RegExp::hasCodeFor):
(JSC::RegExp::compileIfNecessary):
(JSC::RegExp::matchInline):
(JSC::RegExp::hasMatchOnlyCodeFor):
(JSC::RegExp::compileIfNecessaryMatchOnly):
* yarr/Yarr.h:
(): Deleted.
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::Interpreter::backtrackPatternCharacter):
(JSC::Yarr::Interpreter::backtrackPatternCasedCharacter):
(JSC::Yarr::Interpreter::matchCharacterClass):
(JSC::Yarr::Interpreter::backtrackCharacterClass):
(JSC::Yarr::Interpreter::matchBackReference):
(JSC::Yarr::Interpreter::backtrackBackReference):
(JSC::Yarr::Interpreter::parenthesesDoBacktrack):
(JSC::Yarr::Interpreter::matchParenthesesOnceBegin):
(JSC::Yarr::Interpreter::matchParenthesesOnceEnd):
(JSC::Yarr::Interpreter::backtrackParenthesesOnceBegin):
(JSC::Yarr::Interpreter::backtrackParenthesesOnceEnd):
(JSC::Yarr::Interpreter::matchParenthesesTerminalBegin):
(JSC::Yarr::Interpreter::matchParenthesesTerminalEnd):
(JSC::Yarr::Interpreter::backtrackParenthesesTerminalBegin):
(JSC::Yarr::Interpreter::matchParentheticalAssertionBegin):
(JSC::Yarr::Interpreter::matchParentheticalAssertionEnd):
(JSC::Yarr::Interpreter::backtrackParentheticalAssertionBegin):
(JSC::Yarr::Interpreter::backtrackParentheticalAssertionEnd):
(JSC::Yarr::Interpreter::matchParentheses):
(JSC::Yarr::Interpreter::backtrackParentheses):
(JSC::Yarr::Interpreter::matchDisjunction):
(JSC::Yarr::Interpreter::matchNonZeroDisjunction):
(JSC::Yarr::ByteCompiler::atomParenthesesOnceBegin):
(JSC::Yarr::ByteCompiler::atomParenthesesTerminalBegin):
(JSC::Yarr::ByteCompiler::atomParenthesesSubpatternBegin):
(JSC::Yarr::ByteCompiler::atomParentheticalAssertionBegin):
(JSC::Yarr::ByteCompiler::atomParentheticalAssertionEnd):
(JSC::Yarr::ByteCompiler::closeAlternative):
(JSC::Yarr::ByteCompiler::closeBodyAlternative):
(JSC::Yarr::ByteCompiler::atomParenthesesSubpatternEnd):
(JSC::Yarr::ByteCompiler::atomParenthesesOnceEnd):
(JSC::Yarr::ByteCompiler::atomParenthesesTerminalEnd):
(JSC::Yarr::ByteCompiler::emitDisjunction):
(JSC::Yarr::ByteCompiler::dumpDisjunction):
* yarr/YarrInterpreter.h:
(JSC::Yarr::ByteTerm::ByteTerm):
(JSC::Yarr::ByteTerm::BOL):
(JSC::Yarr::ByteTerm::CheckInput):
(JSC::Yarr::ByteTerm::UncheckInput):
(JSC::Yarr::ByteTerm::EOL):
(JSC::Yarr::ByteTerm::WordBoundary):
(JSC::Yarr::ByteTerm::BackReference):
(JSC::Yarr::ByteTerm::BodyAlternativeBegin):
(JSC::Yarr::ByteTerm::BodyAlternativeDisjunction):
(JSC::Yarr::ByteTerm::BodyAlternativeEnd):
(JSC::Yarr::ByteTerm::AlternativeBegin):
(JSC::Yarr::ByteTerm::AlternativeDisjunction):
(JSC::Yarr::ByteTerm::AlternativeEnd):
(JSC::Yarr::ByteTerm::SubpatternBegin):
(JSC::Yarr::ByteTerm::SubpatternEnd):
(JSC::Yarr::ByteTerm::DotStarEnclosure):
* yarr/YarrJIT.cpp:
(JSC::Yarr::jitCompile):
* yarr/YarrJIT.h:
* yarr/YarrParser.h:
(JSC::Yarr::Parser::CharacterClassParserDelegate::CharacterClassParserDelegate):
(JSC::Yarr::Parser::CharacterClassParserDelegate::atomPatternCharacter):
(JSC::Yarr::Parser::CharacterClassParserDelegate::atomBuiltInCharacterClass):
(JSC::Yarr::Parser::CharacterClassParserDelegate::end):
* yarr/YarrPattern.cpp:
(JSC::Yarr::YarrPatternConstructor::atomParenthesesSubpatternBegin):
(JSC::Yarr::YarrPatternConstructor::atomParentheticalAssertionBegin):
(JSC::Yarr::YarrPatternConstructor::atomBackReference):
(JSC::Yarr::YarrPatternConstructor::copyTerm):
(JSC::Yarr::YarrPatternConstructor::quantifyAtom):
(JSC::Yarr::YarrPatternConstructor::checkForTerminalParentheses):
(JSC::Yarr::YarrPatternConstructor::containsCapturingTerms):
(JSC::Yarr::YarrPatternConstructor::optimizeDotStarWrappedExpressions):
(JSC::Yarr::PatternTerm::dumpQuantifier):
(JSC::Yarr::PatternTerm::dump):
* yarr/YarrPattern.h:
(JSC::Yarr::PatternTerm::PatternTerm):
(JSC::Yarr::PatternTerm::ForwardReference):
(JSC::Yarr::PatternTerm::BOL):
(JSC::Yarr::PatternTerm::EOL):
(JSC::Yarr::PatternTerm::WordBoundary):
(JSC::Yarr::PatternTerm::isFixedWidthCharacterClass const):
(JSC::Yarr::PatternTerm::containsAnyCaptures):
(JSC::Yarr::PatternTerm::quantify):
2021-07-23 Alexey Shvayka <shvaikalesh@gmail.com>
[WebIDL] Properly validate and merge descriptors in [Replaceable] setter
https://bugs.webkit.org/show_bug.cgi?id=227662
Reviewed by Sam Weinig.
Extracts createDataProperty() method to keep WebIDL code generator as simple as possible,
and also to emphasize a subtle difference between
{ [[Value]]: X } and
{ [[Value]]: X, [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true }.
* runtime/JSONObject.cpp:
(JSC::Walker::walk):
* runtime/JSObject.cpp:
(JSC::definePropertyOnReceiverSlow):
* runtime/JSObject.h:
* runtime/JSObjectInlines.h:
(JSC::JSObject::createDataProperty):
* runtime/Lookup.h:
(JSC::replaceStaticPropertySlot): Deleted.
2021-07-23 Alexey Shvayka <shvaikalesh@gmail.com>
[JSC] Call custom accessors / values with their holder's global object
https://bugs.webkit.org/show_bug.cgi?id=225997
Reviewed by Yusuke Suzuki.
Just like JS built-ins, getter / setter functions of WebIDL attributes are created in realm
of their holder interface [1][2], which is their _current_ realm for throwing an error [3].
With this patch, custom properties get correct global object instead of lexical, including
when inline cached, aligning them with functions and regular accessors.
The latter allowed switching JS built-ins to CustomAccessor (e.g. Symbol#description),
which is slightly more efficient to call from C++, doesn't need reification on first access,
and has nicer signature.
Also, renames WASM accessors to drop "func" and removes unused function length parameter.
[1]: https://heycam.github.io/webidl/#dfn-attribute-getter (step 2)
[2]: https://heycam.github.io/webidl/#dfn-attribute-setter (step 5)
[3]: https://heycam.github.io/webidl/#ecmascript-throw
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateImpl):
* create_hash_table:
* interpreter/CallFrame.cpp:
(JSC::CallFrame::globalObjectOfClosestCodeBlock):
* interpreter/CallFrame.h:
* runtime/IntlCollatorPrototype.cpp:
(JSC::JSC_DEFINE_CUSTOM_GETTER):
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::JSC_DEFINE_CUSTOM_GETTER):
* runtime/IntlLocalePrototype.cpp:
(JSC::JSC_DEFINE_CUSTOM_GETTER):
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::JSC_DEFINE_CUSTOM_GETTER):
* runtime/JSDataViewPrototype.cpp:
(JSC::JSC_DEFINE_CUSTOM_GETTER):
* runtime/JSObject.cpp:
(JSC::JSObject::putInlineSlow):
* runtime/PropertySlot.cpp:
(JSC::PropertySlot::customGetter const):
* runtime/PropertySlot.h:
(JSC::PropertySlot::getValue const):
* runtime/SymbolPrototype.cpp:
(JSC::JSC_DEFINE_CUSTOM_GETTER):
* tools/JSDollarVM.cpp:
* wasm/js/WebAssemblyInstancePrototype.cpp:
(JSC::JSC_DEFINE_CUSTOM_GETTER):
(JSC::JSC_DEFINE_HOST_FUNCTION): Deleted.
* wasm/js/WebAssemblyMemoryPrototype.cpp:
(JSC::JSC_DEFINE_CUSTOM_GETTER):
* wasm/js/WebAssemblyTablePrototype.cpp:
(JSC::JSC_DEFINE_CUSTOM_GETTER):
2021-07-22 Saam Barati <sbarati@apple.com>
AirStackSlot's uint16_t byte size is too small
https://bugs.webkit.org/show_bug.cgi?id=228193
<rdar://80888059>
Reviewed by Mark Lam.
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::addStackSlot):
* b3/B3Procedure.h:
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::addStackSlot):
* b3/air/AirCode.h:
* b3/air/AirStackSlot.cpp:
(JSC::B3::Air::StackSlot::StackSlot):
* b3/air/AirStackSlot.h:
(JSC::B3::Air::StackSlot::ensureSize):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::lower):
* ftl/FTLOutput.cpp:
(JSC::FTL::Output::lockedStackSlot):
* ftl/FTLOutput.h:
2021-07-22 Saam Barati <sbarati@apple.com>
Fix uses of Dependency::fence with respect to the compiler outsmarting us
https://bugs.webkit.org/show_bug.cgi?id=227757
<rdar://problem/80280931>
Reviewed by Robin Morisset.
We were running into issues on arm64 with respect to the memory model
ordering of loads, and how the compiler optimized code around Dependency::fence.
The issue manifested as calls to isMarked incorrectly returning true.
To see the issue, let's consider a program like this:
a = load(p1)
b = load(p2)
if (a != b) return;
d = Dependency::fence(b)
At the point of defining the dependency, the compiler has proven
a == b. So, instead of building the dependency on the register used
for b, we end up using the register for a. So the actual compiled
code ends up with a dependency on load(p1), not load(p2).
To fix this, we end up adding a new API, Dependency::loadEndFence(pointer,
result), which is defined as:
template<typename T>
static Dependency loadAndFence(T* pointer, T& output)
{
T value = *opaque(pointer);
Dependency dependency = Dependency::fence(value);
output = opaque(value);
return dependency;
}
The reason for this is that it split "b" in the above program into two values,
and the "b" the program compares against is not known to the compiler to be
the same value that we build a dependency on.
* heap/MarkedBlock.h:
(JSC::MarkedBlock::aboutToMark):
(JSC::MarkedBlock::isMarked):
* runtime/JSObject.cpp:
(JSC::JSObject::visitButterflyImpl):
* runtime/JSObject.h:
(JSC::JSObject::fencedButterfly):
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayEntry::getConcurrently):
(JSC::SparseArrayEntry::getConcurrently const): Deleted.
* runtime/SparseArrayValueMap.h:
* runtime/Structure.h:
(JSC::Structure::fencedIndexingMode):
* runtime/StructureIDBlob.h:
(JSC::StructureIDBlob::fencedIndexingModeIncludingHistory):
2021-07-22 Keith Miller <keith_miller@apple.com>
useProfiler option should automatically disable concurrent JIT
https://bugs.webkit.org/show_bug.cgi?id=228152
Reviewed by Saam Barati.
The bytecode profiler is not thread safe so we should have
recomputeDependentOptions() disable concurrent JIT. Also, fix the
jsc CLI to set the useProfiler option rather than have its own
state. Note, we call Options::setOption() rather than setting the
Options::useProfiler() option directly as setOption calls
recomputeDependentOptions() for us.
* jsc.cpp:
(CommandLine::parseArguments):
(runJSC):
* runtime/Options.cpp:
(JSC::Options::recomputeDependentOptions):
(JSC::Options::ensureOptionsAreCoherent):
2021-07-21 Yijia Huang <yijia_huang@apple.com>
Fix type check error in testb3
https://bugs.webkit.org/show_bug.cgi?id=228166
Reviewed by Saam Barati.
* b3/testb3_2.cpp:
(testXorNotWithLeftShift32):
(testXorNotWithRightShift32):
(testXorNotWithUnsignedRightShift32):
2021-07-21 Keith Miller <keith_miller@apple.com>
speculateNeitherDoubleNorStringNorHeapBigInt should only have a single JSType branch
https://bugs.webkit.org/show_bug.cgi?id=228146
Reviewed by Robin Morisset.
Since StringType and HeapBigIntType are adjacent JSTypes
we can do an integer range check rather than two separate
JSType checks.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::speculateNeitherDoubleNorHeapBigIntNorString):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
2021-07-20 Yijia Huang <yijia_huang@apple.com>
Add ARM64 EON opcode and select it in AIR
https://bugs.webkit.org/show_bug.cgi?id=228057
Reviewed by Saam Barati.
EON Rd Rn Rm <shift> #amount
Bitwise Exclusive OR NOT (shifted register) performs a bitwise Exclusive OR NOT
of a register value Rn and an optionally-shifted register value Rm, and writes the
result to the destination register. The instruction selector can utilize this to
lowering certain patterns in B3 IR before further Air optimization.
The equivalent pattern of EON Rd Rn Rm is d = n ^ (m ^ -1)
Given B3 IR:
Int @0 = ArgumentReg(%x0)
Int @1 = ArgumentReg(%x1)
Int @2 = -1
Int @3 = BitXor(@1, @2)
Int @4 = BitXor(@0, b@3)
Void@5 = Return(@4, Terminal)
// Old optimized AIR
Not %x1, %x1, @3
Xor %x0, %x1, %x0, @4
Ret %x0, @5
// New optimized AIR
XorNot %x0, %x1, %x0, @4
Ret %x0, @5
The equivalent pattern of EON-with-shift is d = n ^ ((m ShiftType amount) ^ -1)
Given B3 IR:
Int @0 = ArgumentReg(%x0)
Int @1 = ArgumentReg(%x1)
Int @2 = amount
Int @3 = -1
Int @4 = Shl(@1, @2)
Int @5 = BitXor(@4, @3)
Int @6 = BitXor(@0, @5)
Void b@7 = Return(b@6, Terminal)
// Old optimized AIR
Lshift %x1, amount, %x1, @4
Not %x1, %x1, @5
Xor %x0, %x1, %x0, @6
Ret %x0, @7
// New optimized AIR
XorNotLeftShift %x0, %x1, $63, %x0, @6
Ret %x0, @7
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::xorNot32):
(JSC::MacroAssemblerARM64::xorNot64):
(JSC::MacroAssemblerARM64::xorNotLeftShift32):
(JSC::MacroAssemblerARM64::xorNotRightShift32):
(JSC::MacroAssemblerARM64::xorNotUnsignedRightShift32):
(JSC::MacroAssemblerARM64::xorNotLeftShift64):
(JSC::MacroAssemblerARM64::xorNotRightShift64):
(JSC::MacroAssemblerARM64::xorNotUnsignedRightShift64):
* assembler/testmasm.cpp:
(JSC::testXorNot32):
(JSC::testXorNot64):
(JSC::testXorNotWithLeftShift32):
(JSC::testXorNotWithRightShift32):
(JSC::testXorNotWithUnsignedRightShift32):
(JSC::testXorNotWithLeftShift64):
(JSC::testXorNotWithRightShift64):
(JSC::testXorNotWithUnsignedRightShift64):
* b3/B3LowerToAir.cpp:
* b3/air/AirOpcode.opcodes:
* b3/testb3.h:
* b3/testb3_2.cpp:
(testXorNot32):
(testXorNot64):
(testXorNotWithLeftShift32):
(testXorNotWithRightShift32):
(testXorNotWithUnsignedRightShift32):
(testXorNotWithLeftShift64):
(testXorNotWithRightShift64):
(testXorNotWithUnsignedRightShift64):
(addBitTests):
2021-07-20 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] invalidParameterInstanceofSourceAppender should care direct call of Symbol.hasInstance
https://bugs.webkit.org/show_bug.cgi?id=228075
rdar://80762879
Reviewed by Frédéric Wang.
invalidParameterInstanceofSourceAppender can be invoked without `instanceof` expression since we can call
`[Symbol.hasInstance]` function directly, but the implementation did not assume that. This patch fixes
it to handle this direct call.
* runtime/ExceptionHelpers.cpp:
(JSC::invalidParameterInstanceofSourceAppender):
2021-07-19 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] StructureStubInfo's m_identifier should follow to the same protocol of inlineAccessBaseStructure
https://bugs.webkit.org/show_bug.cgi?id=228092
Reviewed by Saam Barati.
In r279813, we fixed a race condition related to inlineAccessBaseStructure: while we clear inlineAccessBaseStructure,
we still run code relying on this field's value until stub version of the code is generated. As a result,
we run the code which relies on the cells that are already collected. And we have the same problem with
m_identifier field too. This patch makes m_identifier follow to the same protocol of inlineAccessBaseStructure
so that we fix this race issue too: both fields will be alive until we switch to the code that are not relying on these
fields.
We also make inlineAccessBaseStructure to m_inlineAccessBaseStructure to easily find that this is member field.
And we also use setWithoutWriteBarrier for m_inlineAccessBaseStructure since we emit codeBlock->vm().heap.writeBarrier(codeBlock)
immediately after that.
* bytecode/AccessCase.cpp:
(JSC::AccessCase::fromStructureStubInfo):
* bytecode/GetByStatus.cpp:
(JSC::GetByStatus::computeForStubInfoWithoutExitSiteFeedback):
* bytecode/InByStatus.cpp:
(JSC::InByStatus::computeForStubInfoWithoutExitSiteFeedback):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeForStubInfo):
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::initGetByIdSelf):
(JSC::StructureStubInfo::initArrayLength):
(JSC::StructureStubInfo::initStringLength):
(JSC::StructureStubInfo::initPutByIdReplace):
(JSC::StructureStubInfo::initInByIdSelf):
(JSC::StructureStubInfo::addAccessCase):
(JSC::StructureStubInfo::reset):
(JSC::StructureStubInfo::visitAggregateImpl):
(JSC::StructureStubInfo::visitWeakReferences):
(JSC::StructureStubInfo::propagateTransitions):
(JSC::StructureStubInfo::setCacheType): Deleted.
* bytecode/StructureStubInfo.h:
2021-07-19 Mark Lam <mark.lam@apple.com>
DFG's parseIntResult() should check for negative zero.
https://bugs.webkit.org/show_bug.cgi?id=228068
rdar://80788603
Reviewed by Yusuke Suzuki.
We have to check for negative zero explicitly because C++ evaluates 0.0 == -0.0
as true.
* dfg/DFGOperations.cpp:
(JSC::DFG::parseIntResult):
2021-07-19 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] InByStatus / InByVariant should visit CacheableIdentifier
https://bugs.webkit.org/show_bug.cgi?id=228088
rdar://80794604
Reviewed by Mark Lam.
After r278445, InByVariant holds CacheableIdentifier. And this can have
String/Symbol cells if this variant is generated by in_by_val. In that
case, we must visit this cell as GetByStatus / GetByVariant are doing.
* bytecode/InByStatus.cpp:
(JSC::InByStatus::visitAggregateImpl):
* bytecode/InByStatus.h:
* bytecode/InByVariant.cpp:
(JSC::InByVariant::visitAggregateImpl):
* bytecode/InByVariant.h:
* bytecode/RecordedStatuses.cpp:
(JSC::RecordedStatuses::visitAggregateImpl):
2021-07-16 Yijia Huang <yijia_huang@apple.com>
Add ExtendType to Air::Arg Index to fully utilize address computation in memory instruction for ARM64
https://bugs.webkit.org/show_bug.cgi?id=227970
Reviewed by Saam Barati.
The pattern recognition of address computation in the instructions, e.g., Load
Resistor (LDR), Store Register (STR), etc., can benefit the instruction selector.
Then, the Air operand BaseIndex containing base, index, and scale is introduced
to Air opcode. However, the <extend> option of index address is not fully leveraged
in the previous implementation.
To fill that gap, this patch adds a new member, MacroAssembler::Extend, to the current
design of BaseIndex to trigger zero/sign extension on the Index address. And this is
enabled for Store/Load with valid index address and shift amount.
Maybe, the ideal approach is to introduce a decorator (Index@EXT) to the Air operand
to provide an extension opportunity for the specific form of the Air opcode.
Load Register (LDR) calculates an address from a base register value and an
offset register value, loads a word from memory, and writes it to a register.
The offset register value can optionally be shifted and extended.
Given B3 IR:
Int @0 = ArgumentReg(%x0)
Int @1 = Z/SExt32(Trunc(ArgumentReg(%x1)))
Int @2 = scale
Int @3 = Shl(@1, @2)
Int @4 = Add(@0, @3)
Int @5 = Load(@4, ControlDependent|Reads:Top)
Void@6 = Return(@5, Terminal)
// Old optimized AIR
Move %x1, %x1, @1
Move (%x0,%x1,2^scale), %x0, @5
Ret %x0, @6
// New optimized AIR
Move (%x0,%x1,2^scale), %x0, @5
Ret %x0, @6
Store Register (STR) calculates an address from a base register value and an
offset register value, and stores a 32-bit word or a 64-bit doubleword to the
calculated address, from a register.
Given B3 IR:
Int @0 = value
Int @1 = ArgumentReg(%x0)
Int @2 = Z/SExt32(Trunc(ArgumentReg(%x1))
Int @3 = scale
Int @4 = Shl(@2, @3)
Int @5 = Add(@1, @4)
Void@6 = Store(@0, @5, ControlDependent|Writes:Top)
Void@7 = Return(@0, Terminal)
// Old optimized AIR
Move32 %x1, %x1, @2
Store32 %xzr, (%x0,%x1,2^scale), @6
Move $0, %x0, @7
Ret32 %x0, @7
// New optimized AIR
Store32 %xzr, (%x0,%x1,2^scale), @6
Move $0, %x0, @7
Ret32 %x0, @7
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::BaseIndex::BaseIndex):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::indexExtendType):
(JSC::MacroAssemblerARM64::load64):
(JSC::MacroAssemblerARM64::load32):
(JSC::MacroAssemblerARM64::load16):
(JSC::MacroAssemblerARM64::load16SignedExtendTo32):
(JSC::MacroAssemblerARM64::load8):
(JSC::MacroAssemblerARM64::load8SignedExtendTo32):
(JSC::MacroAssemblerARM64::store64):
(JSC::MacroAssemblerARM64::store32):
(JSC::MacroAssemblerARM64::store16):
(JSC::MacroAssemblerARM64::store8):
(JSC::MacroAssemblerARM64::loadDouble):
(JSC::MacroAssemblerARM64::loadFloat):
(JSC::MacroAssemblerARM64::storeDouble):
(JSC::MacroAssemblerARM64::storeFloat):
* b3/B3LowerToAir.cpp:
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::index):
(JSC::B3::Air::Arg::asBaseIndex const):
* b3/testb3.h:
* b3/testb3_2.cpp:
(testLoadZeroExtendIndexAddress):
(testLoadSignExtendIndexAddress):
(testStoreZeroExtendIndexAddress):
(testStoreSignExtendIndexAddress):
(addBitTests):
2021-07-16 Saam Barati <sbarati@apple.com>
Grab the lock in FTL::Thunks::keyForSlowPathCallThunk
https://bugs.webkit.org/show_bug.cgi?id=227988
<rdar://problem/80627901>
Reviewed by Mark Lam.
Both FTL::Thunks::keyForSlowPathCallThunk and FTL::Thunks::getSlowPathCallThunk
both touch the thunks hash map. In r278030, when I added the lock, I grabbed it
in getSlowPathCallThunk, but forgot to also grab it in keyForSlowPathCallThunk.
* ftl/FTLThunks.h:
(JSC::FTL::Thunks::keyForSlowPathCallThunk):
2021-07-16 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r279916.
https://bugs.webkit.org/show_bug.cgi?id=228037
some of tests are timing out
Reverted changeset:
"Convert small JIT pool tests into executable fuzzing"
https://bugs.webkit.org/show_bug.cgi?id=226279
https://commits.webkit.org/r279916
2021-07-16 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] RegExp::dumpToStream must not ref Strings since it is called concurrently
https://bugs.webkit.org/show_bug.cgi?id=228031
rdar://80686425
Reviewed by Mark Lam.
RegExp::dumpToStream's escapedPattern can return m_pattern. In that case, it is refed in the concurrent thread.
This is wrong since StringImpl must not be ref-ed concurrently. This patch just revert this function to the old behavior.
* runtime/RegExp.cpp:
(JSC::RegExp::dumpToStream):
2021-07-15 Keith Miller <keith_miller@apple.com>
Alias JSC graph dumping options
https://bugs.webkit.org/show_bug.cgi?id=228015
Reviewed by Yusuke Suzuki.
My brain seems to associate the phases with the tier we are compiling in
rather than the type of graph we are processing. At this point it's
probably easier to just add an alias rather than convince me otherwise.
* runtime/OptionsList.h:
2021-07-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] SamplingProfiler should recognize RegExp execution
https://bugs.webkit.org/show_bug.cgi?id=201702
Reviewed by Saam Barati.
This patch extends SamplingProfiler to recognize RegExp execution. We record
executing RegExp in VM via MatchingContextHolder so that SamplingProfiler can detect it.
We use MatchingContextHolder even if the RegExp is interpreter mode so that we can still
catch non-JIT RegExp in SamplingProfiler.
The example output is the following.
Sampling rate: 1000.000000 microseconds. Total samples: 1830
Top functions as <numSamples 'functionName#hash:sourceID'>
466 'Exec#<nil>:4'
225 '/(^|[^\\])\"\\\/Qngr\((-?[0-9]+)\)\\\/\"/g#<nil>:-1'
173 'runBlock1#<nil>:4'
88 '/NQ_VQ/g#<nil>:-1'
83 '/d2/g#<nil>:-1'
78 '/d1/g#<nil>:-1'
70 '/\s?;\s?/#<nil>:-1'
68 'replace#<nil>:3'
50 '/(((\w+):\/\/)([^\/:]*)(:(\d+))?)?([^#?]*)(\?([^#]*))?(#(.*))?/#<nil>:-1'
49 'runBlock0#<nil>:4'
46 '#<nil>:-1'
24 '/^\s*|\s*$/g#<nil>:-1'
Sampling rate: 1000.000000 microseconds. Total samples: 1830
Tier breakdown:
-----------------------------------
LLInt: 13 (0.710383%)
Baseline: 54 (2.950820%)
DFG: 187 (10.218579%)
FTL: 612 (33.442623%)
js builtin: 73 (3.989071%)
Wasm: 0 (0.000000%)
Host: 0 (0.000000%)
RegExp: 907 (49.562842%)
C/C++: 0 (0.000000%)
Unknown Executable: 57 (3.114754%)
Hottest bytecodes as <numSamples 'functionName#hash:JITType:bytecodeIndex'>
378 'Exec#<nil>:FTL:bc#27'
225 '/(^|[^\\])\"\\\/Qngr\((-?[0-9]+)\)\\\/\"/g#<nil>:RegExp:<nil>'
88 '/NQ_VQ/g#<nil>:RegExp:<nil>'
83 '/d2/g#<nil>:RegExp:<nil>'
78 '/d1/g#<nil>:RegExp:<nil>'
70 '/\s?;\s?/#<nil>:RegExp:<nil>'
62 'replace#<nil>:FTL:bc#63'
53 'Exec#<nil>:DFG:bc#27'
50 '/(((\w+):\/\/)([^\/:]*)(:(\d+))?)?([^#?]*)(\?([^#]*))?(#(.*))?/#<nil>:RegExp:<nil>'
46 '#<nil>:None:<nil>'
42 'runBlock1#<nil>:FTL:bc#1795'
29 'runBlock1#<nil>:FTL:bc#1849'
29 'runBlock1#<nil>:FTL:bc#1741'
24 '/^\s*|\s*$/g#<nil>:RegExp:<nil>'
17 'runBlock1#<nil>:DFG:bc#1741'
17 'runBlock1#<nil>:DFG:bc#1795'
16 '/\b\w+\b/g#<nil>:RegExp:<nil>'
14 '/TNQP=([^;]*)/i#<nil>:RegExp:<nil>'
13 '/%\w?$/#<nil>:RegExp:<nil>'
12 '/^ba/#<nil>:RegExp:<nil>'
11 '/^\s*(\S*(\s+\S+)*)\s*$/#<nil>:RegExp:<nil>'
10 'runBlock0#<nil>:FTL:bc#400'
10 'runBlock1#<nil>:DFG:bc#1849'
10 'Exec#<nil>:DFG:bc#16'
9 '/(?:ZFVR.(\d+\.\d+))|(?:(?:Sversbk|TenaCnenqvfb|Vprjrnfry).(\d+\.\d+))|(?:Bcren.(\d+\.\d+))|(?:NccyrJroXvg.(\d+(?:\.\d+)?))/#<nil>:RegExp:<nil>'
8 '/##yv18##/gi#<nil>:RegExp:<nil>'
8 '/([a-zA-Z]|\s)+/#<nil>:RegExp:<nil>'
7 '/JroXvg\/(\S+)/#<nil>:RegExp:<nil>'
7 'runBlock0#<nil>:FTL:bc#2671'
7 '/^([#.]?)((?:[\w\u0128-\uffff*_-]|\\.)*)/#<nil>:RegExp:<nil>'
6 '/##oe##/gi#<nil>:RegExp:<nil>'
6 'runBlock1#<nil>:FTL:bc#124'
6 '/[+, ]/#<nil>:RegExp:<nil>'
6 'runBlock1#<nil>:FTL:bc#1903'
6 'replace#<nil>:DFG:bc#63'
5 'runBlock0#<nil>:FTL:bc#3378'
5 '/'/g#<nil>:RegExp:<nil>'
5 '/##yv20##/gi#<nil>:RegExp:<nil>'
4 '/\?[\w\W]*(sevraqvq|punaaryvq|tebhcvq)=([^\&\?#]*)/i#<nil>:RegExp:<nil>'
4 'load#<nil>:None:<nil>'
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/RegExp.cpp:
(JSC::RegExp::matchCompareWithInterpreter):
(JSC::RegExp::dumpToStream):
(JSC::appendLineTerminatorEscape<LChar>):
(JSC::appendLineTerminatorEscape<UChar>):
(JSC::escapePattern):
(JSC::RegExp::escapedPattern const): Moved from RegExpPrototype.cpp to implement RegExp::toSourceString and RegExp::escapedPattern.
(JSC::RegExp::toSourceString const):
(JSC::regexpToSourceString): Deleted.
* runtime/RegExp.h:
* runtime/RegExpInlines.h:
(JSC::RegExp::matchInline):
* runtime/RegExpPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::appendLineTerminatorEscape<LChar>): Deleted.
(JSC::appendLineTerminatorEscape<UChar>): Deleted.
(JSC::regExpProtoGetterSourceInternal): Deleted.
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::takeSample):
(JSC::SamplingProfiler::processUnverifiedStackTraces):
(JSC::SamplingProfiler::StackFrame::nameFromCallee):
(JSC::SamplingProfiler::StackFrame::displayName):
(JSC::SamplingProfiler::StackFrame::displayNameForJSONTests):
(JSC::SamplingProfiler::StackFrame::functionStartLine):
(JSC::SamplingProfiler::StackFrame::functionStartColumn):
(JSC::SamplingProfiler::StackFrame::sourceID):
(JSC::SamplingProfiler::StackFrame::url):
(JSC::SamplingProfiler::reportTopBytecodes):
(WTF::printInternal):
* runtime/SamplingProfiler.h:
* runtime/VM.h:
* yarr/YarrJIT.cpp:
(JSC::Yarr::MatchingContextHolder::MatchingContextHolder): Deleted.
(JSC::Yarr::MatchingContextHolder::~MatchingContextHolder): Deleted.
* yarr/YarrJIT.h:
(JSC::Yarr::MatchingContextHolder::offsetOfStackLimit): Deleted.
(JSC::Yarr::MatchingContextHolder::offsetOfPatternContextBuffer): Deleted.
(JSC::Yarr::MatchingContextHolder::offsetOfPatternContextBufferSize): Deleted.
* yarr/YarrMatchingContextHolder.h: Added.
(JSC::Yarr::MatchingContextHolder::offsetOfStackLimit):
(JSC::Yarr::MatchingContextHolder::offsetOfPatternContextBuffer):
(JSC::Yarr::MatchingContextHolder::offsetOfPatternContextBufferSize):
(JSC::Yarr::MatchingContextHolder::MatchingContextHolder):
(JSC::Yarr::MatchingContextHolder::~MatchingContextHolder):
2021-07-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Harden defaultTimeZone retrieval
https://bugs.webkit.org/show_bug.cgi?id=227996
rdar://80540300
Reviewed by Mark Lam.
We received the report that "UTC" can appear in Intl.DateTimeFormat's default timezone.
While we cannot reproduce it, this patch attempts to avoid using TimeZone from UCalendar
so that the code gets the same to the old defaultTimeZone implementation.
* runtime/JSDateMath.cpp:
(JSC::DateCache::defaultTimeZone):
(JSC::DateCache::timeZoneCacheSlow):
2021-07-15 Mark Lam <mark.lam@apple.com>
JITWorklist::waitUntilAllPlansForVMAreReady() should also be notified when plans are cancelled.
https://bugs.webkit.org/show_bug.cgi?id=228003
rdar://78314543
Reviewed by Yusuke Suzuki.
Previously, it only gets notified when plans are done compiling. As a result, if
JITWorklist::waitUntilAllPlansForVMAreReady() found non-ready plans and started
waiting, and those plans were canceled, then JITWorklist::waitUntilAllPlansForVMAreReady()
can hang indefinitely.
This patch renames JITWorklist::::m_planCompiled to m_planCompiledOrCancelled,
and notifies it also when plans are cancelled.
* jit/JITWorklist.cpp:
(JSC::JITWorklist::waitUntilAllPlansForVMAreReady):
(JSC::JITWorklist::removeMatchingPlansForVM):
* jit/JITWorklist.h:
* jit/JITWorklistThread.cpp:
(JSC::JITWorklistThread::work):
2021-07-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add samplingProfilerIgnoreExternalSourceID option
https://bugs.webkit.org/show_bug.cgi?id=227985
Reviewed by Mark Lam.
We can ignore sourceID when aggregating samples. By doing so, we can open Speedometer2 style iframes
and still aggregate all the functions even though each script in iframe has different source ID.
* runtime/OptionsList.h:
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::StackFrame::sourceID):
(JSC::SamplingProfiler::reportTopFunctions):
* runtime/SamplingProfiler.h:
2021-07-15 Adrian Perez de Castro <aperez@igalia.com>
Non-unified build fixes, mid-July 2021 edition
https://bugs.webkit.org/show_bug.cgi?id=227981
Unreviewed non-unified build fixes.
* ftl/FTLState.cpp: Add missing B3ValueInlines.h header.
* runtime/TemporalNow.cpp: Add missing JSCJSValueInlines.h and JSObjectInlines.h headers.
* runtime/TemporalObject.cpp: Ditto.
2021-07-14 Devin Rousso <drousso@apple.com>
Implement Array.prototype.findLast and Array.prototype.findLastIndex
https://bugs.webkit.org/show_bug.cgi?id=227939
Reviewed by Yusuke Suzuki.
* builtins/ArrayPrototype.js:
(findLast): Added.
(findLastIndex): Added.
(JSC::ArrayPrototype::finishCreation):
* runtime/JSTypedArrayViewPrototype.cpp:
* builtins/TypedArrayPrototype.js:
(findLast): Added.
(findLastIndex): Added.
* runtime/ArrayPrototype.cpp:
(JSC::JSTypedArrayViewPrototype::finishCreation):
* runtime/OptionsList.h:
2021-07-14 Michael Saboff <msaboff@apple.com>
[macOS] Add new entitlement to limit process to a single JIT region
https://bugs.webkit.org/show_bug.cgi?id=227956
Reviewed by Mark Lam.
This macOS entitlement limits a process to a single JIT region.
This matches the behavior on iOS.
* Scripts/process-entitlements.sh:
* entitlements.plist:
2021-07-14 Mark Lam <mark.lam@apple.com>
Speculative fix for failed scope.releaseAssertNoException() after calls to JSMap::create().
https://bugs.webkit.org/show_bug.cgi?id=227964
rdar://78013960
Reviewed by Yusuke Suzuki.
There have been reports of flaky failures on the scope.releaseAssertNoException()
after the call to JSMap::create() in JSModuleLoader::finishCreation().
The scope.releaseAssertNoException() says that we don't expect the JSMap::create()
to ever throw an exception. If the assertion is true, the only way that we can
see an exception there is if we're throwing an asynchronous TerminationException.
Since JSModuleLoader::finishCreation() does not have any long running loops, we can
just DeferTerminationForAWhile and let the next exception check site throw the
asynchronous TerminationException. We don't want to just use DeferTermination
because it will throw the TerminationException right at the end of
JSModuleLoader::finishCreation(), and the caller of JSModuleLoader::finishCreation()
may be similarly not expecting an exception to be thrown there.
Also apply the same treatment to AbstractModuleRecord::finishCreation(), and
getBackingMap() in WebCore for the same reason. Other than those, other sites that
call JSMap::create() already check for exceptions. So, those sites do not need to
DeferTerminationForAWhile.
* runtime/AbstractModuleRecord.cpp:
(JSC::AbstractModuleRecord::finishCreation):
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::finishCreation):
2021-07-14 Keith Miller <keith_miller@apple.com>
Convert small JIT pool tests into executable fuzzing
https://bugs.webkit.org/show_bug.cgi?id=226279
Right now, we try to test our engine on a small JIT pool. This isn't a known configuration for any
actual ports and causes issues if we run out of JIT memory when we need to compile an OSR exit.
Instead of testing such a small pool we should just fuzz each executable allocation that says it
can fail.
The current fuzzing doesn't do a good job tracking the number of DFG/FTL compiles when allocations
fail, so when enabled those tests will just exit early. Also, right now we use a random seed picked
by the engine for these tests, which makes it hard to reproduce crashes on the bots. If we see
flakiness on the bots we can have the harness pass in a number so it gets logged in the repro command.
Reviewed by Michael Saboff.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::numberOfDFGCompiles):
* jit/ExecutableAllocationFuzz.cpp:
(JSC::doExecutableAllocationFuzzing):
* jsc.cpp:
(runJSC):
2021-07-14 Mark Lam <mark.lam@apple.com>
Check for out of memory in JSC::globalFuncEscape() and JSC::globalFuncUnescape().
https://bugs.webkit.org/show_bug.cgi?id=227962
rdar://78392251
Reviewed by Yusuke Suzuki.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
2021-07-14 Yusuke Suzuki <ysuzuki@apple.com>
libpas executable-allocator should reserve more than 256KB for non-fail region at least
https://bugs.webkit.org/show_bug.cgi?id=227927
Reviewed by Keith Miller.
libpas jit_heap has mediam allocator which allocates 128KB pages at once. However, our JSC stress tests are setting 100KB
for small executable memory tests. As a result, under this configuration, we fail immediately after using medium allocator.
But this test's "total size of executable memory is 100KB" is unrealistic: it is possible that only 100KB memory remains,
but it is impossible that we reserve only 25KB for non-fail reservation. In production, we are always reserving 128MB. So
this configuration is not realistic actually.
So, this patch changes,
1. If non-fail region is less than 256KB, then we add 256KB and keep this 256KB as non-fail executable allocation. If not,
use 0.25 ratio as we are doing. This means that Options::jitMemoryReservationSize configures failable region of
executable memory.
2. We also revive bytesReserved and bytesAllocated to make memoryPressureMultiplier and early-fail allocation (when there is
not enough memory and allocation can fail, then we should fail).
* jit/ExecutableAllocator.cpp:
(JSC::initializeJITPageReservation):
(JSC::ExecutableAllocator::underMemoryPressure):
(JSC::ExecutableAllocator::memoryPressureMultiplier):
(JSC::ExecutableAllocator::allocate):
(JSC::ExecutableMemoryHandle::createImpl):
(JSC::ExecutableMemoryHandle::~ExecutableMemoryHandle):
(JSC::ExecutableMemoryHandle::shrink):
(JSC::ExecutableMemoryHandle::sizeInBytes const): Deleted.
* jit/ExecutableMemoryHandle.h:
(JSC::ExecutableMemoryHandle::sizeInBytes const):
(JSC::ExecutableMemoryHandle::ExecutableMemoryHandle):
2021-07-14 Mark Lam <mark.lam@apple.com>
Placate exception checker validation in operationObjectAssignUntyped.
https://bugs.webkit.org/show_bug.cgi?id=227955
rdar://80503746
Reviewed by Michael Saboff.
* dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
2021-07-13 Robin Morisset <rmorisset@apple.com>
Invalid machine code emitted by SpeculativeJIT::emitObjectOrOtherBranch
https://bugs.webkit.org/show_bug.cgi?id=227869
<rdar://problem/80457566>
Reviewed by Mark Lam.
SpeculativeJIT::emitObjectOrOtherBranch used to check the validity of the masqueradesAsUndefined watchpoint twice, and assumed that it could not change in between.
That is clearly incorrect as the main thread is running concurrently with it, and so the watchpoint could fire at any time.
The fix is trivial: just check the validity once, and store the result in a boolean.
If the watchpoint triggers later that is fine: we'll notice and cancel the compilation (see WatchpointCollectionPhase, Plan::isStillValid() and Plan::finalize()).
The change only protects us from rare and hard-to-reproduce crashes on debug builds caused by an ASSERT firing.
I did not add a testcase, as I can only reproduce the bug by adding an extra wait in the middle of emitObjectOrOtherBranch.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
2021-07-13 Yijia Huang <yijia_huang@apple.com>
Add a new Air::Arg kind ZeroReg to let AIR recognise the new instructions/forms accepting zero register in ARM64
https://bugs.webkit.org/show_bug.cgi?id=227510
Reviewed by Saam Barati.
B3 is designed to be portable to many kinds of CPUs. However, to effectively
compile code to different CPUs, the compiler must eventually make explicit
instruction set details. Then, Air is introduced, and it is designed to target
individual CPU architectures and generate instructions specific to those CPUs.
Previously, Air don't recognize the zero register. This problem has been pointed
out in #174821, which was trying to introduce the new opcodes to handle the zero
register.
To solve this problem in a modular reasoning approach, a new Air operand ZeroReg
should be introduced. Its goal is to closely match the CPU instructions
accepting the zero register in ARM64. Another reason is that the new overloads
of the instructions taking the zero register can benefit instruction selection
with this implementation.
Here, the ZeroReg is added as a new kind for Air::Arg, which acts as a "high
level" operand to be emitted with the associative opcodes. In ARM64, the ZeroReg
would be emitted as a zero register.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::storeZero64): Deleted.
(JSC::MacroAssemblerARM64::storeZero32): Deleted.
(JSC::MacroAssemblerARM64::storeZero16): Deleted.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::storeZero32): Deleted.
(JSC::MacroAssemblerX86Common::storeZero16): Deleted.
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::storeZero64): Deleted.
* b3/B3LowerToAir.cpp:
* b3/air/AirArg.cpp:
(JSC::B3::Air::Arg::jsHash const):
(JSC::B3::Air::Arg::dump const):
(WTF::printInternal):
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::zeroReg):
(JSC::B3::Air::Arg::isZeroReg const):
(JSC::B3::Air::Arg::isGP const):
(JSC::B3::Air::Arg::isFP const):
(JSC::B3::Air::Arg::isValidForm const):
(JSC::B3::Air::Arg::asZeroReg const):
* b3/air/AirLowerStackArgs.cpp:
(JSC::B3::Air::lowerStackArgs):
* b3/air/AirOpcode.opcodes:
* b3/air/opcode_generator.rb:
* b3/testb3.h:
* b3/testb3_1.cpp:
(run):
* b3/testb3_3.cpp:
(testStoreZeroReg):
2021-07-12 Filip Pizlo <fpizlo@apple.com> and Yusuke Suzuki <ysuzuki@apple.com>
New malloc algorithm
https://bugs.webkit.org/show_bug.cgi?id=226404
Reviewed by Yusuke Suzuki.
Switch the ExecutableAllocator to the libpas jit_heap. The libpas jit_heap uses two size
categories of bitfit and a large heap, and is happy to do its approximate first-fit in any
ranges of memory you give it. Jit_heap never allocates metadata inside the memory it manages.
Allocations and deallocations take a constant-bounded amount of time except for unusual
situations, and are protected by fine-grained locking in most cases. Decommit follows libpas
scavenging policy. This alone is a speed-up on Speedometer (probably about 1% or more).
Also expose some libpas introspection via $vm.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/MacroAssemblerCodeRef.h:
* jit/ExecutableAllocator.cpp:
(JSC::ExecutableAllocator::underMemoryPressure):
(JSC::ExecutableAllocator::memoryPressureMultiplier):
(JSC::ExecutableAllocator::allocate):
(JSC::ExecutableAllocator::committedByteCount):
(JSC::ExecutableMemoryHandle::createImpl):
(JSC::ExecutableMemoryHandle::~ExecutableMemoryHandle):
(JSC::ExecutableMemoryHandle::sizeInBytes const):
(JSC::ExecutableMemoryHandle::shrink):
* jit/ExecutableAllocator.h:
* jit/ExecutableMemoryHandle.h: Added.
(JSC::ExecutableMemoryHandle::start const):
(JSC::ExecutableMemoryHandle::end const):
(JSC::ExecutableMemoryHandle::startAsInteger const):
(JSC::ExecutableMemoryHandle::endAsInteger const):
(JSC::ExecutableMemoryHandle::containsIntegerAddress const):
(JSC::ExecutableMemoryHandle::contains const):
(JSC::ExecutableMemoryHandle::key const):
(JSC::ExecutableMemoryHandle::dump const):
(JSC::ExecutableMemoryHandle::ExecutableMemoryHandle):
* tools/JSDollarVM.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::JSDollarVM::finishCreation):
2021-07-12 Mark Lam <mark.lam@apple.com>
Revert r277027: breaks GC.
https://bugs.webkit.org/show_bug.cgi?id=227888
Reviewed by Saam Barati.
The patch in r277027 to make deletion of GCAwareJITStubRoutines incremental has a
bug: the routine may not be deleted yet by the incremental sweeper before the next
GC cycle, and the GC will not be happy visiting dead cell pointers in that routine.
There is also another bug with the triggering of sweeping.
For now, we're reverting the patch, and will revisit this at a later time.
* CMakeLists.txt:
* heap/Heap.cpp:
(JSC::Heap::deleteUnmarkedCompiledCode):
(JSC::Heap::sweepSynchronously):
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::mayHaveJITStubRoutinesToDelete): Deleted.
(JSC::Heap::deleteDeadJITStubRoutines): Deleted.
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::doSweep):
* heap/JITStubRoutineSet.cpp:
(JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines):
* heap/JITStubRoutineSet.h:
(JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines):
(JSC::JITStubRoutineSet::traceMarkedStubRoutines):
(JSC::JITStubRoutineSet::mayHaveRoutinesToDelete): Deleted.
(JSC::JITStubRoutineSet::notifyHaveRoutinesToDelete): Deleted.
* jit/GCAwareJITStubRoutine.cpp:
(JSC::GCAwareJITStubRoutine::observeZeroRefCount):
* jit/JITStubRoutine.h:
(JSC::JITStubRoutine::createSelfManagedRoutine):
2021-07-12 Yijia Huang <yijia_huang@apple.com>
Add SMNEGL, UMNEGL, UMADDL, and UMSUBL for ARM64 and select this instruction in Air
https://bugs.webkit.org/show_bug.cgi?id=227857
Reviewed by Robin Morisset.
The previous patches have already added MNEG, MADD, MSUB, SMADDL, and SMSUBL.
This patch completes the corresponding signed or unsigned variants (SMNEGL,
UMNEGL, UMADDL, and UMSUBL) of them. In addition, this patch refactors
the implementation and the associative test cases of MADD, MSUB, and MNEG
to be more readable and maintainable w.r.t their variants.
------------------------------
### SMNEGL/UMNEGL Xd Wn Wm ###
------------------------------
Signed/Unsigned Multiply-Negate Long multiplies two 32-bit register values,
negates the product, and writes the result to the 64-bit destination register.
The equivalent patterns are
d = -(SExt32(n) * SExt32(m)) and d = -(ZExt32(n) * ZExt32(m)) respectively.
Given B3 IR:
Int @0 = S/ZExt32(Trunc(ArgumentReg(%x0)))
Int @1 = S/ZExt32(Trunc(ArgumentReg(%x1)))
Int @2 = Mul(@0, @1)
Int @3 = Neg(@2)
Void@4 = Return(@3, Terminal)
// Old optimized AIR
Move32 %x0, %x0, @0
Move32 %x1, %x1, @1
MultiplyNeg %x0, %x1, %x0, @3
Ret %x0, @4
// New optimized AIR
MultiplyNegSign/ZeroExtend %x0, %x1, %x0, @3
Ret %x0, @4
--------------------------
### UMADDL Xd Wn Wm Xa ###
--------------------------
Unsigned Multiply-Add Long multiplies two 32-bit register values, adds a 64-bit
register value, and writes the result to the 64-bit destination register. The
equivalent patterns are
d = ZExt32(n) * ZExt32(m) + a or d = a + ZExt32(n) * ZExt32(m)
Given B3 IR:
Int @0 = ZExt32(Trunc(ArgumentReg(%x0)))
Int @1 = ZExt32(Trunc(ArgumentReg(%x1)))
Int @2 = ArgumentReg(%x2)
Int @3 = Mul(@0, @1)
Int @4 = Add(@3, @2)
Void@5 = Return(@4, Terminal)
// Old optimized AIR
Move32 %x0, %x0, @1
Move32 %x1, %x1, @2
MultiplyAdd %x0, %x1, %x2, %x0, @4
Ret64 %x0, @5
// New optimized AIR
MultiplyAddZeroExtend %x0, %x1, %x2, %x0, @8
Ret %x0, @9
--------------------------
### UMSUBL Xd Wn Wm Xa ###
--------------------------
Unsigned Multiply-Subtract Long multiplies two 32-bit register values, subtracts
the product from a 64-bit register value, and writes the result to the 64-bit
destination register. The equivalent patterns are
d = a - ZExt32(n) * ZExt32(m)
Given B3 IR:
Int @0 = ZExt32(Trunc(ArgumentReg(%x0)))
Int @1 = ZExt32(Trunc(ArgumentReg(%x1)))
Int @2 = ArgumentReg(%x2)
Int @3 = Mul(@0, @1)
Int @4 = Sub(@2, @3)
Void@5 = Return(@4, Terminal)
// Old optimized AIR
Move32 %x0, %x0, @1
Move32 %x1, %x1, @2
MultiplySub %x0, %x1, %x2, %x0, @4
Ret64 %x0, @5
// New optimized AIR
MultiplySubZeroExtend %x0, %x1, %x2, %x0, @8
Ret %x0, @9
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::multiplyNeg32):
(JSC::MacroAssemblerARM64::multiplyAddZeroExtend32):
(JSC::MacroAssemblerARM64::multiplySubZeroExtend32):
(JSC::MacroAssemblerARM64::multiplyNeg64):
(JSC::MacroAssemblerARM64::multiplyNegSignExtend32):
(JSC::MacroAssemblerARM64::multiplyNegZeroExtend32):
* assembler/testmasm.cpp:
(JSC::testMultiplyAddSignExtend32):
(JSC::testMultiplyAddZeroExtend32):
(JSC::testMultiplySubSignExtend32):
(JSC::testMultiplySubZeroExtend32):
(JSC::testMultiplyNegSignExtend32):
(JSC::testMultiplyNegZeroExtend32):
(JSC::testMultiplyAddSignExtend32Left): Deleted.
(JSC::testMultiplyAddSignExtend32Right): Deleted.
* b3/B3LowerToAir.cpp:
* b3/air/AirOpcode.opcodes:
* b3/testb3.h:
* b3/testb3_2.cpp:
(testMulAddArgsLeft):
(testMulAddArgsRight):
(testMulAddSignExtend32ArgsLeft):
(testMulAddZeroExtend32ArgsLeft):
(testMulAddZeroExtend32ArgsRight):
(testMulSubArgsLeft):
(testMulSubArgsRight):
(testMulSubArgsRight32):
(testMulSubSignExtend32):
(testMulSubZeroExtend32):
(testMulNegArgArg):
(testMulNegArgs):
(testMulNegArgs32):
(testMulNegSignExtend32):
(testMulNegZeroExtend32):
(testMulSubSignExtend32Args): Deleted.
* b3/testb3_3.cpp:
(addArgTests):
2021-07-12 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] JITCage already includes guard pages
https://bugs.webkit.org/show_bug.cgi?id=227867
Reviewed by Mark Lam.
Since JITCage already includes guard pages, we do not need to allocate that additionally.
* jit/ExecutableAllocator.cpp:
(JSC::initializeJITPageReservation):
2021-07-10 Saam Barati <sbarati@apple.com>
Continue to consult InlineAccess's Structure even after switching to a stub IC
https://bugs.webkit.org/show_bug.cgi?id=227785
Reviewed by Yusuke Suzuki.
This patch fixes a crash in: stress/class-subclassing-function.js
The bug is this:
1. We initialize a StructureStubInfo to be an inline self access doing a load based on structure S.
2. We transition to being a PolymorphicAccess based StructureStubInfo. But, we haven't
generated code yet. We're in the buffered state. So we are still running the inline access
from (1). But the StructureStubInfo thinks it's a "Stub".
3. S is collected
4. We continue to run code from (1), because when we finalize the IC during GC, it
doesn't think it's an inline access.
The fix is to always track the structure S that we used when generating the inline
access, and to only stop tracking it once we've generated code for the Stub.
* bytecode/AccessCase.cpp:
(JSC::AccessCase::fromStructureStubInfo):
(JSC::AccessCase::propagateTransitions const):
* bytecode/AccessCase.h:
* bytecode/GetByStatus.cpp:
(JSC::GetByStatus::computeForStubInfoWithoutExitSiteFeedback):
* bytecode/InByStatus.cpp:
(JSC::InByStatus::computeForStubInfoWithoutExitSiteFeedback):
* bytecode/PolymorphicAccess.cpp:
(JSC::PolymorphicAccess::propagateTransitions const):
* bytecode/PolymorphicAccess.h:
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeForStubInfo):
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::initGetByIdSelf):
(JSC::StructureStubInfo::initPutByIdReplace):
(JSC::StructureStubInfo::initInByIdSelf):
(JSC::StructureStubInfo::addAccessCase):
(JSC::StructureStubInfo::reset):
(JSC::StructureStubInfo::visitWeakReferences):
(JSC::StructureStubInfo::propagateTransitions):
* bytecode/StructureStubInfo.h:
2021-07-10 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Workaround test262.report bug by making $ properties enumerable
https://bugs.webkit.org/show_bug.cgi?id=227855
Reviewed by Alexey Shvayka.
test262.report's harness has a bug and it reports incorrect results for JSC on tests using $262 properties.
This patch introduces a workaround which makes properties of $ enumerable.
* jsc.cpp:
2021-07-08 Yijia Huang <yijia_huang@apple.com>
Add Air opcode add/sub-and-shift for ARM64 and select this instruction in Air
https://bugs.webkit.org/show_bug.cgi?id=227509
Reviewed by Saam Barati.
This patch includes two modifications:
1. Add add/sub-with-shift to Air opcode and the corresponding pattern match for
instruction selection.
2. Minor fix in disassembler.
Given the operation:
add/sub Rd, Rn, Rm, ShiftType, amount
ADD/SUB (shifted register), adds/subs a register value Rn and an optionally-shifted register
value Rm, and writes the result to the destination register Rd. The instruction selector
can utilize this to lowering certain patterns in B3 IR before further Air optimization.
The equivalent pattern would be:
d = n +/- (m ShiftType amount)
Given B3 IR:
Int @0 = ArgumentReg(%x0)
Int @1 = ArgumentReg(%x1)
Int @2 = amount
Int @3 = ZShr(@1, @2)
Int @4 = Add/Sub(@0, @3)
Void@5 = Return(@4, Terminal)
// Old optimized AIR
Shift %x1, amount, %x1, @3
Add/Sub %x0, %x1, %x0, @4
Ret %x0, @5
// New optimized AIR
Add(Sub)Shift %x0, %x1, amount, %x0, @4
Ret %x0, @5
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::addLeftShift32):
(JSC::MacroAssemblerARM64::addRightShift32):
(JSC::MacroAssemblerARM64::addUnsignedRightShift32):
(JSC::MacroAssemblerARM64::addLeftShift64):
(JSC::MacroAssemblerARM64::addRightShift64):
(JSC::MacroAssemblerARM64::addUnsignedRightShift64):
(JSC::MacroAssemblerARM64::subLeftShift32):
(JSC::MacroAssemblerARM64::subRightShift32):
(JSC::MacroAssemblerARM64::subUnsignedRightShift32):
(JSC::MacroAssemblerARM64::subLeftShift64):
(JSC::MacroAssemblerARM64::subRightShift64):
(JSC::MacroAssemblerARM64::subUnsignedRightShift64):
* assembler/testmasm.cpp:
(JSC::testAddWithLeftShift32):
(JSC::testAddWithRightShift32):
(JSC::testAddWithUnsignedRightShift32):
(JSC::testAddWithLeftShift64):
(JSC::testAddWithRightShift64):
(JSC::testAddWithUnsignedRightShift64):
(JSC::testSubWithLeftShift32):
(JSC::testSubWithRightShift32):
(JSC::testSubWithUnsignedRightShift32):
(JSC::testSubWithLeftShift64):
(JSC::testSubWithRightShift64):
(JSC::testSubWithUnsignedRightShift64):
* b3/B3LowerToAir.cpp:
* b3/air/AirOpcode.opcodes:
* b3/testb3.h:
(checkUsesInstruction):
* b3/testb3_2.cpp:
(testAddWithLeftShift32):
(testAddWithRightShift32):
(testAddWithUnsignedRightShift32):
(testAddWithLeftShift64):
(testAddWithRightShift64):
(testAddWithUnsignedRightShift64):
(testSubWithLeftShift32):
(testSubWithRightShift32):
(testSubWithUnsignedRightShift32):
(testSubWithLeftShift64):
(testSubWithRightShift64):
(testSubWithUnsignedRightShift64):
(addBitTests):
* disassembler/ARM64/A64DOpcode.cpp:
* disassembler/ARM64/A64DOpcode.h:
(JSC::ARM64Disassembler::A64DOpcodeAddSubtractShiftedRegister::immediate6):
(JSC::ARM64Disassembler::A64DOpcodeLogicalShiftedRegister::immediate6):
2021-07-08 Keith Miller <keith_miller@apple.com>
display-profiler-output should be able to print disassembly for the FTL
https://bugs.webkit.org/show_bug.cgi?id=227798
Reviewed by Saam Barati.
Right now running JSC with the bytecode profiler will not print
disassembly for FTL code. This patch adds this support. In order to get
execution counts there is a callback at the transition between each
DFG node in the Air disassembler. Since B3 code move parts of
DFG nodes to different basic blocks we don't include execution
counts in the dump. However, the DFG-only graph printed before
the disassembly will still have the counts.
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLState.cpp:
(JSC::FTL::State::dumpDisassembly):
* ftl/FTLState.h:
(JSC::FTL::State::dumpDisassembly):
2021-07-08 Yusuke Suzuki <ysuzuki@apple.com>
Use JSC::Yarr::flagsString to get string representation of RegExp flags
https://bugs.webkit.org/show_bug.cgi?id=227790
Reviewed by Keith Miller.
* yarr/YarrFlags.h:
2021-07-07 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Clean up RegExp flag code
https://bugs.webkit.org/show_bug.cgi?id=227786
Reviewed by Filip Pizlo.
I found a bug in regexpToSourceString (used for RegExp's dump code), and it motivates me to clean up
all RegExp flag handling code. We define RegExp flags as a macro and updating that macro updates all
RegExp flag handling code too.
* runtime/RegExp.cpp:
(JSC::RegExpFunctionalTestCollector::outputOneTest):
(JSC::regexpToSourceString):
* runtime/RegExp.h:
* runtime/RegExpPrototype.cpp:
(JSC::flagsString):
* yarr/YarrFlags.cpp:
(JSC::Yarr::parseFlags):
(JSC::Yarr::flagsString):
* yarr/YarrFlags.h:
2021-07-07 Saam Barati <sbarati@apple.com>
JSArrayBufferView::byteOffsetConcurrently has a race when using PAC
https://bugs.webkit.org/show_bug.cgi?id=227765
Reviewed by Mark Lam.
We were calling JSArrayBufferView::vector(), which does PAC validation
using the length() of the array. However, this can race with JSArrayBufferView::detach,
which sets the length to zero, leading to sadness on the compiler thread.
* runtime/JSArrayBufferView.h:
(JSC::JSArrayBufferView::vectorWithoutPACValidation const):
* runtime/JSArrayBufferViewInlines.h:
(JSC::JSArrayBufferView::byteOffsetImpl):
2021-07-07 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Fix Object.assign fast path to accept undefined/null
https://bugs.webkit.org/show_bug.cgi?id=227769
rdar://80264271
Reviewed by Saam Barati.
Object.assign can accept undefined or null as a second (or latter) parameters.
If it is passed, the parameter is just ignored. Previous DFG / FTL optimization patch
does not handle this case.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileObjectAssign):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileObjectAssign):
* runtime/ObjectConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/ObjectConstructorInlines.h:
(JSC::objectAssignFast):
2021-07-07 Mark Lam <mark.lam@apple.com>
Heap::waitForCollector() needs to set m_mutatorDidRun.
https://bugs.webkit.org/show_bug.cgi?id=227782
rdar://78326474
Reviewed by Saam Barati.
Heap::waitForCollector() is one of 2 clients of Heap::stopIfNecessarySlow(unsigned oldState).
The other client, Heap::stopIfNecessarySlow() sets m_mutatorDidRun to true after
calling Heap::stopIfNecessarySlow(unsigned oldState). Heap::waitForCollector()
needs to do the same. Constraint solvers rely on this.
Without this, one fall out we've seen is that DOMGCOutputConstraint fails to
visitOutputConstraints, and as a result, opaqueRoots may not get updated. This
issue was caught by the GC verifier.
* heap/Heap.cpp:
(JSC::Heap::waitForCollector):
2021-07-07 Michael Saboff <msaboff@apple.com>
fitcored crashes at JavaScriptCore: JSC::Heap::releaseAccessSlow
https://bugs.webkit.org/show_bug.cgi?id=227767
Reviewed by Geoffrey Garen.
Speculative fix for this crash. We are crashing while destroying the VM as we are about to
release the JSLock. In JSLock::willReleaseLock(), we release heap access. Therefore we don't
need to release it again when undertaking the various shutdown steps in the VM destructor.
Added a new scope class that will only release and then acquire heap access if the caller
currently has heap access.
* heap/ReleaseHeapAccessScope.h:
(JSC::ReleaseHeapAccessIfNeededScope::ReleaseHeapAccessIfNeededScope):
(JSC::ReleaseHeapAccessIfNeededScope::~ReleaseHeapAccessIfNeededScope):
* jit/JITWorklist.cpp:
(JSC::JITWorklist::waitUntilAllPlansForVMAreReady):
2021-07-07 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Do not allocate JITWorklist if JIT is disabled
https://bugs.webkit.org/show_bug.cgi?id=227734
Reviewed by Mark Lam.
Previously, this code was doing,
if (Options::useJIT())
DFG::iterateCodeBlocksForGC(visitor, m_vm, func);
But r278082 changed it to
JITWorklist::ensureGlobalWorklist().iterateCodeBlocksForGC(visitor, m_vm, func);
As a result, we are always allocating JITWorklist even JIT is not enabled.
This patch fixes the behavior not to allocate JITWorklist.
* heap/Heap.cpp:
(JSC::Heap::iterateExecutingAndCompilingCodeBlocks):
2021-07-06 Yusuke Suzuki <ysuzuki@apple.com>
r270214 broke testb3 on arm64e
https://bugs.webkit.org/show_bug.cgi?id=227713
Reviewed by Saam Barati.
ARM64E CAS lacks isBranch case. This patch adds isBranch implementation.
We also adjust disasm scanning test to support CAS in ARM64E.
* assembler/testmasm.cpp:
(JSC::testAtomicStrongCASFill8):
(JSC::testAtomicStrongCASFill16):
* b3/B3LowerToAir.cpp:
* b3/testb3_8.cpp:
(testAtomicWeakCAS):
(testAtomicStrongCAS):
(testAtomicXchg):
2021-07-06 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, build fix after r279630
https://bugs.webkit.org/show_bug.cgi?id=223166
* DerivedSources-input.xcfilelist:
* DerivedSources-output.xcfilelist:
2021-07-06 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r279546, r279554, r279558 and r279567.
https://bugs.webkit.org/show_bug.cgi?id=227732
Speedometer/jQuery-TodoMVC 2-3% regression
Reverted changesets:
"[WebIDL] Rework runtime enabled properties leveraging
PropertyCallback"
https://bugs.webkit.org/show_bug.cgi?id=227275
https://commits.webkit.org/r279546
"[WebIDL] Generate constructor's hash table in
GenerateConstructorHelperMethods"
https://bugs.webkit.org/show_bug.cgi?id=227668
https://commits.webkit.org/r279554
"[WebIDL] Simplify generation of runtime conditionally read-
write attributes"
https://bugs.webkit.org/show_bug.cgi?id=227672
https://commits.webkit.org/r279558
"Use AbortSignal's [PrivateIdentifier] whenSignalAborted()
static method"
https://bugs.webkit.org/show_bug.cgi?id=227673
https://commits.webkit.org/r279567
2021-07-06 Philip Chimento <pchimento@igalia.com>
[JSC] Implement Temporal
https://bugs.webkit.org/show_bug.cgi?id=223166
Reviewed by Yusuke Suzuki.
Intended to be the first patch in a stack. Adds boilerplate for
Temporal in order to unblock further parallelizable work on this bug.
This patch adds a feature flag for Temporal, and a toplevel Temporal
global containing only Temporal.now, which is itself an empty object.
These objects will be further populated in later patches.
* CMakeLists.txt: Add TemporalObject and TemporalNow. Property lookup
table in TemporalObject.
* DerivedSources.make: Add TemporalObject property lookup table header.
* JavaScriptCore.xcodeproj/project.pbxproj: Add new files.
* Sources.txt: Add TemporalObject and TemporalNow.
* runtime/CommonIdentifiers.h: Add 'Temporal' property key.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init): Create the Temporal global if the feature
flag is enabled.
* runtime/OptionsList.h: Add useTemporal feature flag.
* runtime/TemporalNow.cpp: Added.
(JSC::TemporalNow::TemporalNow):
(JSC::TemporalNow::create):
(JSC::TemporalNow::createStructure):
(JSC::TemporalNow::finishCreation):
* runtime/TemporalNow.h: Added.
* runtime/TemporalObject.cpp: Added.
(JSC::createNowObject):
(JSC::TemporalObject::TemporalObject):
(JSC::TemporalObject::create):
(JSC::TemporalObject::createStructure):
(JSC::TemporalObject::finishCreation):
* runtime/TemporalObject.h: Added.
2021-07-06 Yijia Huang <yijia_huang@apple.com>
Fix type error in testb3
https://bugs.webkit.org/show_bug.cgi?id=227722
Reviewed by Mark Lam.
Fix type error in testb3. Shift amount should be 32-bit constant.
* b3/testb3_3.cpp:
(testInsertSignedBitfieldInZero64):
(testExtractSignedBitfield64):
2021-07-05 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Optimize Object.assign and putDirectInternal
https://bugs.webkit.org/show_bug.cgi?id=227677
Reviewed by Filip Pizlo.
This patch improves Object.assign performance (and this requires putDirectInternal improvement).
1. Object.assign is handled by DFG / FTL as ObjectAssign node
2. We found that putDirectInternal is suboptimal. This patch removes several bottlenecks. They are super critical from the measurement of
microbenchmarks.
2.1. Creating and destroying DeferredStructureTransitionWatchpointFire is not free. We should do that only when we need it.
2.2. Before r277620, we are checking m_replacementWatchpointSets's nullptr and that was fast. But after that, we are always
calling HashMap::get, and it is not inlined. This means that if we have StructureRareData, we are always calling HashMap::get
even though there is no m_replacementWatchpointSets set. This patch adds HashMap::isNullStorage to avoid this call by inlinely
check this via `LIKELY(m_replacementWatchpointSets.isNullStorage())`.
2.3. Structure::addPropertyTransitionToExistingStructure has very cheap fast path and we must inline them to get performance benefit
for major single-transition case.
Added microbenchmarks show significant performance improvements. And Speedometer2 shows 0.6 - 1.0% improvement.
ToT Patched
object-assign-transition 105.2539+-0.2970 ^ 88.8046+-0.2029 ^ definitely 1.1852x faster
object-assign-replace 116.1568+-0.0905 ^ 75.0673+-0.0658 ^ definitely 1.5474x faster
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/Watchpoint.cpp:
(JSC::DeferredWatchpointFire::fireAllSlow):
(JSC::DeferredWatchpointFire::DeferredWatchpointFire): Deleted.
(JSC::DeferredWatchpointFire::~DeferredWatchpointFire): Deleted.
(JSC::DeferredWatchpointFire::fireAll): Deleted.
* bytecode/Watchpoint.h:
(JSC::DeferredWatchpointFire::DeferredWatchpointFire):
(JSC::DeferredWatchpointFire::fireAll):
(JSC::FireDetail::FireDetail): Deleted.
(JSC::FireDetail::~FireDetail): Deleted.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGMayExit.cpp:
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileObjectAssign):
* 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::compileObjectAssign):
* runtime/Intrinsic.cpp:
(JSC::intrinsicName):
* runtime/Intrinsic.h:
* runtime/JSObject.cpp:
(JSC::JSObject::deleteProperty):
* runtime/JSObjectInlines.h:
(JSC::JSObject::putDirectInternal):
* runtime/ObjectConstructor.cpp:
(JSC::objectAssignGeneric):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/ObjectConstructor.h:
* runtime/ObjectConstructorInlines.h: Added.
(JSC::canPerformFastPropertyEnumerationForObjectAssign):
* runtime/Structure.cpp:
(JSC::StructureTransitionTable::singleTransition const): Deleted.
(JSC::StructureTransitionTable::get const): Deleted.
(JSC::Structure::addPropertyTransitionToExistingStructureImpl): Deleted.
(JSC::Structure::addPropertyTransitionToExistingStructure): Deleted.
(JSC::Structure::addPropertyTransitionToExistingStructureConcurrently): Deleted.
* runtime/Structure.h:
* runtime/StructureInlines.h:
(JSC::Structure::didReplaceProperty):
(JSC::Structure::propertyReplacementWatchpointSet):
(JSC::Structure::addPropertyTransitionToExistingStructureImpl):
(JSC::Structure::addPropertyTransitionToExistingStructure):
(JSC::Structure::addPropertyTransitionToExistingStructureConcurrently):
(JSC::StructureTransitionTable::singleTransition const):
(JSC::StructureTransitionTable::get const):
2021-07-06 Yijia Huang <yijia_huang@apple.com>
Fix instruction check failure of UBFX and SBFIZ in testb3 due to the speculative fix in bug 227554
https://bugs.webkit.org/show_bug.cgi?id=227563
Reviewed by Filip Pizlo.
This patch includes two modifications to resolve rdar://79978150:
1. Fix the bug caused by the patch introducing BFI.
2. Discard the corresponding speculative fix in https://bugs.webkit.org/show_bug.cgi?id=227554.
The previous patch, added bit field insert (BFI) to AIR opcode, causes the Gmail page
hanging issue on Safari. The root cause is the incorrect definition of register role in
BFI's AIR opcode. Since BFI inserts a bit field at the low end of the destination register
while keeping the high bit unchanged, the destination register should have both roles of
use and define simultaneously, which is not (missing use) in the previous patch.
This will result in the loss of preserving the value of the destination register,
which does happen when browsing the Gmail page on Safari.
// B3 IR snippets from Gmail
Int32 b@23 = Add(b@104, b@111, D@100)
...
Int32 b@55 = Const32(65535, D@50)
Int32 b@137 = BitAnd(b@118, $65535(b@55), D@160)
Int32 b@168 = Const32(16, D@40)
Int32 b@141 = Shl(b@137, $16(b@168), D@163)
Int32 b@143 = BitAnd(b@23, $65535(b@55), D@166)
Int32 b@144 = BitOr(b@141, b@143, D@169)
The pattern of BFI is d = ((n & mask1) << lsb) | (d & mask2). So, it is obvious that
BFI can be utilized in b@144 where the d is b@23.
// Incorrect AIR opcode of BFI
arm64: InsertBitField32 U:G:32, U:G:32, U:G:32, ZD:G:32
Tmp, Imm, Imm, Tmp
// Air w/o use role
Add32 %x3, %x7, %x7, b@23
...
InsertBitField32 %x3, $16, $16, %x4, b@144
// Generated code w/o use role
add w7, w3, w7
...
bfi w4, w3, #16, #16
In Air, the added value is stored in the w7. But the value is not preserved after
lowering with BFI. To fix this, the use role should be enabled for the destination
register.
// Correnct AIR opcode of BFI
arm64: InsertBitField32 U:G:32, U:G:32, U:G:32, UZD:G:32
Tmp, Imm, Imm, Tmp
// Air w/ use role
Add32 %x3, %x7, %x7, b@23
...
Move32 %x7, %x4, b@144
InsertBitField32 %x3, $16, $16, %x4, b@144
// Generated code w/ use role
add w7, w3, w7
...
ubfx x4, x7, #0, #32
bfi w4, w3, #16, #16
In addition, BFXIL, which has pattern d = ((n >> lsb) & mask1) | (d & mask2), also needs
the similar update.
* b3/B3LowerToAir.cpp:
* b3/air/AirOpcode.opcodes:
* b3/testb3_2.cpp:
(testInsertBitField32):
(testInsertBitField64):
(testExtractInsertBitfieldAtLowEnd32):
(testExtractInsertBitfieldAtLowEnd64):
* runtime/OptionsList.h:
2021-07-04 Robin Morisset <rmorisset@apple.com>
ActiveScratchBufferScope should take the buffer as argument
https://bugs.webkit.org/show_bug.cgi?id=227670
rdar://80011612
Reviewed by Mark Lam.
https://bugs.webkit.org/show_bug.cgi?id=227013 created ActiveScratchBufferScope.
It is used by operations that can cause the GC to run, to mark as roots the contents of the scratch buffer that is live during that time (if any).
The bug is that it simply asks the VM for a scratch buffer of the right size, but this will always return the last scratch buffer, and not necessarily the one that the operation is actually using.
A fairly simple fix is to pass it directly the scratch buffer, since the operation normally can get it easily enough.
In most cases the operation has access to the m_buffer field of the ScratchBuffer, but getting a pointer to the entire structure from that is fairly simple (I added ScratchBuffer::fromData() to do so).
* dfg/DFGOSRExit.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* dfg/DFGOSRExit.h:
* dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewArray):
* dfg/DFGThunks.cpp:
(JSC::DFG::osrExitGenerationThunkGenerator):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::haveABadTime):
* runtime/VM.h:
(JSC::ScratchBuffer::fromData):
* runtime/VMInlines.h:
(JSC::ActiveScratchBufferScope::ActiveScratchBufferScope):
(JSC::ActiveScratchBufferScope::~ActiveScratchBufferScope):
2021-07-04 Alexey Shvayka <shvaikalesh@gmail.com>
[WebIDL] Simplify generation of runtime conditionally read-write attributes
https://bugs.webkit.org/show_bug.cgi?id=227672
Reviewed by Sam Weinig.
* runtime/Lookup.h:
(JSC::HashTableValue::makeReadOnlyCopy const):
2021-07-03 Alexey Shvayka <shvaikalesh@gmail.com>
[WebIDL] Rework runtime enabled properties leveraging PropertyCallback
https://bugs.webkit.org/show_bug.cgi?id=227275
Reviewed by Saam Barati.
To make the implementation of WebIDL runtime enabled properties independent of eager
property reification, this change:
1. Introduces IsLazyPropertyEnabledCallback, which is needed separately from existing
value callback to maintain the invariant that reifyStaticProperty() always puts a
property, and to keep enumeration fast.
Calling disableCaching() isn't enough to achieve correct [[Get]] inline caching,
so isTaintedByOpaqueObject() is leveraged to prohibit caching of runtime disabled
properties, just like in operationTryGetByIdOptimize().
The only case that might seem weird is runtime disabled properties, which were
enabled after all static properties were reified via [[Delete]], are not appearing.
It's fixable, yet there is currently no demand for it.
2. Adds support for LazyPropertyCallback returning GetterSetter / CustomGetterSetter,
ensuring correct structure flags and slot initialization. Previously, the callback
was used to init only objects and constructors, using putDirect() unconditionally.
To avoid mixing other non-basic attributes with PropertyCallback, which would require
hoisting of checks against PropertyCallback and complicating attribute validation in
HashTableValue methods, this patch checks the type of callback's return value instead.
In the future, sticking to this approach will make returning CustomValue impossible
as it can't be distinguished from CustomAccessor. That's fine because all present
CustomValue usages merely do lazy init, which PropertyCallback is better suited for.
Also, this patch:
3. Expands setUpStaticFunctionSlot() to handle constant integers so the code using
`Node.ELEMENT_NODE` & friends doesn't regress (proven by attached microbenchmark).
4. Removes extra checks from setUpStaticPropertySlot(), which is called only on
non-reified properties.
5. Removes invariant that DOMJITAttribute property is read-only, which was broken
by `document.body` having a non-JIT custom setter. This aligns non-reified
properties with structure ones.
* jit/Repatch.cpp:
(JSC::tryCacheGetBy):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setupGetByIdPrototypeCache):
* runtime/HasOwnPropertyCache.h:
(JSC::HasOwnPropertyCache::tryAdd):
* runtime/JSObject.cpp:
(JSC::lookupPropertyForPut):
(JSC::JSObject::putInlineSlow):
(JSC::JSObject::reifyAllStaticProperties):
* runtime/JSObject.h:
(JSC::JSObject::getOwnNonIndexPropertySlot):
(JSC::JSObject::fillStructurePropertySlot):
* runtime/JSObjectInlines.h:
(JSC::JSObject::getNonReifiedStaticPropertyNames):
* runtime/Lookup.cpp:
(JSC::setUpStaticPropertySlot):
(JSC::setUpStaticFunctionSlot): Deleted.
* runtime/Lookup.h:
(JSC::HashTableValue::isLazyPropertyEnabled const):
(JSC::getStaticPropertySlotFromTable):
(JSC::reifyStaticProperty):
(JSC::reifyStaticProperties):
* tools/JSDollarVM.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::JSDollarVM::finishCreation):
2021-07-02 Keith Miller <keith_miller@apple.com>
Add 10 more unified source cpp files for JSC
https://bugs.webkit.org/show_bug.cgi?id=227643
Reviewed by Alex Christensen.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Scripts/generate-unified-sources.sh:
* UnifiedSources-output.xcfilelist:
2021-07-02 Philippe Normand <pnormand@igalia.com>
[GTK] Add new revision variable in pkgconfig file
https://bugs.webkit.org/show_bug.cgi?id=227629
Reviewed by Michael Catanzaro.
* javascriptcoregtk.pc.in: Include SVN_REVISION as revision variable, useful for apps to
know on which upstream SVN revision their WebKitGTK-based app is built on.
2021-07-01 Yijia Huang <yijia_huang@apple.com>
Remove unnecessary canBeInternal invocations to mitigate the cost of potential unmatched patterns in B3LowerToAir
https://bugs.webkit.org/show_bug.cgi?id=227508
Reviewed by Filip Pizlo.
The bit pattern doesn't cause worse code generation in the all-internals-are-captured
case. So, they don't need canBeInternal checks which might terminate potential matched
scenarios.
The equivalent pattern of SBFIZ is ((src << amount) >> amount) << lsb. Given the code:
a = x << C
b = a >> C
c = b << D
print(a)
print(b)
print(c)
The pattern won't match because of !canBeInternal for a and b (useCounts > 1).
So, this would emit three separate instructions. But if we removed canBeInternal,
it would still be just three separate instructions, and they wouldn't be any more
expensive. Suppose the print(b) is removed, above. Then, with the canBeInternal check,
it is emitting three instructions. Without the canBeInternal check, it would emit only
two (x << C and SBFIZ to compute c). And that would be less expensive.
* b3/B3LowerToAir.cpp:
2021-07-01 Yijia Huang <yijia_huang@apple.com>
Add a new pattern to instruction selector to use EXTR supported by ARM64
https://bugs.webkit.org/show_bug.cgi?id=227171
Reviewed by Robin Morisset.
This patch includes two modifications:
1. Introduce a strength reduction rule to zero extend bitfield.
2. Add Extract Register (EXTR) to Air opcode to serve instruction selector.
-------------------------------------------------------
### Part A zero extend bitfield ###
-------------------------------------------------------
A new strength reduction rule is added for the canonical form of the zero-extend
bitfield.
Turn this: ZShr(Shl(value, amount)), amount)
Into this: BitAnd(value, mask)
with constraints:
1. 0 <= amount < datasize
2. width = datasize - amount
3. mask is !(mask & (mask + 1)) where bitCount(mask) == width
-------------------
### Part B EXTR ###
-------------------
Given instruction:
extr Rd, Rn, Rm, lowWidth
Extract register (EXTR) extracts a register from a pair of registers, where
concat = Rn:Rm and Rd = concat<lowWidth + datasize - 1:lowWidth>.
The equivalent pattern of this instruction is:
d = ((n & mask) << highWidth) | (m >> lowWidth)
highWidth = datasize - lowWidth
mask = (1 << lowWidth) - 1
Given B3 IR:
Int @0 = ArgumentReg(%x0)
Int @1 = ArgumentReg(%x1)
Int @2 = mask
Int @3 = BitAnd(@0, @2)
Int @4 = highWidth
Int @5 = Shl(@3, @4)
Int @6 = lowWidth
Int @7 = ZShr(@1, @6)
Int @8 = BitOr(@7, @5)
Void@9 = Return(@10, Terminal)
Before Adding BIC:
// Old optimized AIR
InsertUnsignedBitfieldInZero %x0, highWidth, lowWidth, %x0, @5
Urshift %x1, lowWidth, %x1, @7
Or %x0, %x1, %x0, @8
Ret %x0, @9
After Adding BIC:
// New optimized AIR
ExtractRegister %x0, %x1, lowWidth, %x0, @8
Ret %x0, @9
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::extractRegister32):
(JSC::MacroAssemblerARM64::extractRegister64):
* assembler/testmasm.cpp:
(JSC::testExtractRegister32):
(JSC::testExtractRegister64):
* b3/B3LowerToAir.cpp:
* b3/B3ReduceStrength.cpp:
* b3/air/AirOpcode.opcodes:
* b3/testb3.h:
* b3/testb3_2.cpp:
(testBitfieldZeroExtend32):
(testBitfieldZeroExtend64):
(testExtractRegister32):
(testExtractRegister64):
(addBitTests):
2021-06-30 Saam Barati <sbarati@apple.com>
Turn off data ICs by default
https://bugs.webkit.org/show_bug.cgi?id=227334
<rdar://problem/79802812>
Reviewed by Yusuke Suzuki.
There are GC crashes that are caused by access data IC sharing. This
patch is both turning off data IC sharing by default, and turning off data
ICs by default.
We should re-enable this once we figure out the issue:
https://bugs.webkit.org/show_bug.cgi?id=227551
Some of our testing modes are still running with data ICs on, so the code doesn't
bit rot. And a select few tests are running with data IC sharing on, for
similar reasons, even though we know it has issues. If those tests start
crashing, we'll just disable sharing completely until the issue is resolved.
* bytecode/PolymorphicAccess.cpp:
(JSC::PolymorphicAccess::regenerate):
* runtime/OptionsList.h:
2021-06-30 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Stop generating default parameter code if class constructor is called without 'new'
https://bugs.webkit.org/show_bug.cgi?id=227547
rdar://78821453
Reviewed by Mark Lam.
We already do not generate body bytecode when class constructor is called without 'new' because many features including "super()" assume
that they generate bytecode only when it is called as a constructor. But we are not doing that for default parameters' bytecode generation.
This patch stops generating bytecode for default parameters if class constructor is called without 'new'.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::BytecodeGenerator):
* runtime/ConstructorKind.h:
2021-06-30 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Private names should be handled by usedVariables mechanism
https://bugs.webkit.org/show_bug.cgi?id=227476
rdar://76049469
Reviewed by Saam Barati.
Private name handling in the current parser has many problems.
1. The parser backtracks when it sees destructuring assignment, arrow function etc. In that case, the discarded code
must not have any effect on the outside of that code. However, private name handling is annotating "used" of the
upper scopes, which is wrong.
2. In class expression, private name lookup intentionally skips the class-scope when parsing class heritage. But this
is not correct since CodeBlock will perform lookup on the normal scope chain and this will look into the class-scope
inconsistently. This means that we could encounter different private name at runtime. (it is tested in the added test).
3. We skip inner function parsing when it is parsed previously. At that case, we must preserve private name annotation,
but restored function information does not preserve that.
This patch changes how private name is handled.
1. We were anyway defining #XXX variables which holds private symbols. So we track "use" information by the mechanism used
for usual variables. We remove Used / Declared bits from PrivateNameEntry since they are not necessary at runtime, and
these information is handled / tracked in Parser's Scope. For backtracking, we already have a mechanism to roll-back
m_usedVariables, so using variable mechanism automatically fixes the problem.
2. We define class-head-scope separately from class-scope. class-heritage expression can see class name, but it cannot use
private names. Previously, our implementation attempted to achieve that by hacky way: skipping this class-scope for private
names only while parsing class-heritage. But this was wrong since it does not consider CodeBlock's linking phase as described
in the problem (2). Instead, we just define class-head-scope which holds class constructor name.
3. We clean up popScopeInternal to populate lexical-variables and function-stack. Previously, we are stealing them before popping
the scope when necessary, but this is a hack and a bit wrong since scope's popping operation needs to access these information
in some cases. Instead, popScopeInternal populates them after popping the scope.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::pushClassHeadLexicalScope):
(JSC::BytecodeGenerator::popClassHeadLexicalScope):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ClassExprNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createClassExpr):
(JSC::ASTBuilder::createBlockStatement):
(JSC::ASTBuilder::createForLoop):
(JSC::ASTBuilder::createForInLoop):
(JSC::ASTBuilder::createForOfLoop):
(JSC::ASTBuilder::createTryStatement):
(JSC::ASTBuilder::createSwitchStatement):
* parser/NodeConstructors.h:
(JSC::ForNode::ForNode):
(JSC::TryNode::TryNode):
(JSC::ClassExprNode::ClassExprNode):
(JSC::SwitchNode::SwitchNode):
(JSC::BlockNode::BlockNode):
(JSC::EnumerationNode::EnumerationNode):
(JSC::ForInNode::ForInNode):
(JSC::ForOfNode::ForOfNode):
* parser/Nodes.cpp:
(JSC::ScopeNode::ScopeNode):
(JSC::ProgramNode::ProgramNode):
(JSC::ModuleProgramNode::ModuleProgramNode):
(JSC::EvalNode::EvalNode):
(JSC::FunctionNode::FunctionNode):
(JSC::VariableEnvironmentNode::VariableEnvironmentNode):
* parser/Nodes.h:
(JSC::VariableEnvironmentNode::VariableEnvironmentNode): Deleted.
* parser/Parser.cpp:
(JSC::isPrivateFieldName):
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseForStatement):
(JSC::Parser<LexerType>::parseSwitchStatement):
(JSC::Parser<LexerType>::parseTryStatement):
(JSC::Parser<LexerType>::parseBlockStatement):
(JSC::Parser<LexerType>::parseFunctionDeclarationStatement):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseBinaryExpression):
(JSC::Parser<LexerType>::parseMemberExpression):
(JSC::Parser<LexerType>::usePrivateName): Deleted.
* parser/Parser.h:
(JSC::Scope::finalizeLexicalEnvironment):
(JSC::Scope::takeLexicalEnvironment):
(JSC::Scope::takeDeclaredVariables):
(JSC::Scope::takeFunctionDeclarations):
(JSC::Scope::forEachUsedVariable):
(JSC::Scope::usePrivateName):
(JSC::Scope::currentUsedVariablesSize):
(JSC::Parser::popScopeInternal):
(JSC::Parser::popScope):
(JSC::Parser<LexerType>::parse):
(JSC::Scope::copyUndeclaredPrivateNamesTo): Deleted.
(JSC::Scope::hasUsedButUndeclaredPrivateNames const): Deleted.
(JSC::Parser::privateNameScope): Deleted.
(JSC::Parser::copyUndeclaredPrivateNamesToOuterScope): Deleted.
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createClassExpr):
(JSC::SyntaxChecker::createBlockStatement):
(JSC::SyntaxChecker::createForLoop):
(JSC::SyntaxChecker::createForInLoop):
(JSC::SyntaxChecker::createForOfLoop):
(JSC::SyntaxChecker::createTryStatement):
(JSC::SyntaxChecker::createSwitchStatement):
* parser/VariableEnvironment.cpp:
(JSC::VariableEnvironmentEntry::dump const):
(JSC::VariableEnvironment::declarePrivateField):
(JSC::VariableEnvironment::declarePrivateAccessor):
(JSC::VariableEnvironment::declarePrivateMethod):
(JSC::VariableEnvironment::dump const):
* parser/VariableEnvironment.h:
(JSC::VariableEnvironment::declarePrivateField):
(JSC::VariableEnvironment::privateNameEnvironment):
(JSC::VariableEnvironment::addPrivateNamesFrom):
(JSC::PrivateNameEntry::isUsed const): Deleted.
(JSC::PrivateNameEntry::isDeclared const): Deleted.
(JSC::PrivateNameEntry::setIsUsed): Deleted.
(JSC::PrivateNameEntry::setIsDeclared): Deleted.
(JSC::VariableEnvironment::usePrivateName): Deleted.
(JSC::VariableEnvironment::copyPrivateNamesTo const): Deleted.
(JSC::VariableEnvironment::copyUndeclaredPrivateNamesTo const): Deleted.
2021-06-30 Mark Lam <mark.lam@apple.com>
ARM64: Disable selection of BFI instruction variants by default.
https://bugs.webkit.org/show_bug.cgi?id=227554
rdar://79978150
Reviewed by Saam Barati.
We suspect that this may have caused some hangs. Disabling while we investigate.
* b3/B3LowerToAir.cpp:
* b3/testb3_2.cpp:
(testInsertBitField32):
(testInsertBitField64):
* runtime/OptionsList.h:
2021-06-29 Joonghun Park <jh718.park@samsung.com>
Remove "function declared ‘static’ but never defined" build warnings since r278971.
https://bugs.webkit.org/show_bug.cgi?id=227436
This patch removes the build warnings below.
warning: ‘bool JSC::cannotBeIdentPartOrEscapeStart(LChar)’ declared ‘static’ but never defined [-Wunused-function]
Reviewed by Michael Catanzaro.
* runtime/LiteralParser.cpp: Add definitions for cannotBeIdentPartOrEscapeStart.
(JSC::cannotBeIdentPartOrEscapeStart):
2021-06-29 Yijia Huang <yijia_huang@apple.com>
Add a new pattern to instruction selector to use SBX and SBFIZ supported by ARM64
https://bugs.webkit.org/show_bug.cgi?id=227203
Reviewed by Filip Pizlo.
This patch includes two modifications:
1. Introduce a strength reduction rule for sign extending bitfield.
2. Add Signed Bitfield Extract (SBFX) and Signed Bitfield Insert
in Zero (SBFIZ) to Air opcode to serve instruction selector.
-------------------------------------------------------
### Part A Sign extending from a variable bit-width ###
-------------------------------------------------------
According to Bit Twiddling Hacks, there are two ways to sign extend bitfield.
(https://graphics.stanford.edu/~seander/bithacks.html#VariableSignExtend)
int bf; // sign extend this width-bit number to bfsx
int width; // number of bits representing the number in bf
int bfsx; // resulting sign-extended number
Approach 1
mask1 = (1 << width) - 1
mask2 = 1 << (width - 1)
bf = bf & mask1 // zero bits in bf above position width
bfsx = (bf ^ mask2) - mask2
Approach 2
amount = CHAR_BIT * sizeof(bf) - width
bfsx = (bf << amount) >> amount
Then, a new strength reduction rule is introduced:
Turn this: ((bf & mask1) ^ mask2) - mask2
Into this: (bf << amount) >> amount
-------------------
### Part B SBFX ###
-------------------
Given instruction:
sbfx Rd, Rn, lsb, width
Signed Bitfield Extract (SBFX) extracts width number of adjacent bits at lsb position
from a register Rn, sign-extends them to the size of the register, and writes the
result to the destination register Rd.
The equivalent patterns of this instruction are:
Pattern 1:
bf = src >> lsb
dst = ((bf & mask1) ^ mask2) - mask2
mask1 = (1 << width) - 1
mask2 = 1 << (width - 1) // (mask2 << 1) - 1 = mask1
Pattern 2:
bf = src >> lsb
amount = CHAR_BIT * sizeof(bf) - width
dst = (bf << amount) >> amount
Then, (bf << amount) >> amount is selected as the canonical form with the strength reduction
rule introduced above.
Given B3 IR:
Int @0 = ArgumentReg(%x0)
Int @1 = lsb
Int @2 = amount
Int @3 = ZShr(@0, @1)
Int @4 = Shl(@3, @2)
Int @5 = SShr(@4, @2)
Void@6 = Return(@5, Terminal)
Before Adding BIC:
// Old optimized AIR
Urshift %x0, lsb, %x0, @3
Lshift %x0, amount, %x0, @4
Rshift %x0, amount, %x0, @5
Ret %x0, @6
After Adding BIC:
// New optimized AIR
ExtractSignedBitfield %x0, lsb, width, %x0, @5
Ret %x0, @6
--------------------
### Part B SBFIZ ###
--------------------
Given instruction:
sbfiz Rd, Rn, lsb, width
Signed Bitfield Insert in Zero (SBFIZ) zeroes the destination register Rd and copies
width number of contiguous bits from a source register Rn into lsb position in the
destination register, sign-extending the most significant bit of the transferred value.
The equivalent patterns of this instruction are:
Pattern 1:
bfsx = ((src & mask1) ^ mask2) - mask2
dst = bfsx << lsb
mask1 = (1 << width) - 1
mask2 = 1 << (width - 1) // (mask2 << 1) - 1 = mask1
Pattern 2:
amount = CHAR_BIT * sizeof(bf) - width
bfsx = (src << amount) >> amount
dst = bfsx << lsb
Then, ((src << amount) >> amount) << lsb is selected as the canonical form with the
strength reduction rule introduced above.
Given B3 IR:
Int @0 = ArgumentReg(%x0)
Int @1 = lsb
Int @2 = amount
Int @3 = Shl(@0, @2)
Int @4 = SShr(@3, @2)
Int @5 = Shl(@4, @1)
Void@6 = Return(@5, Terminal)
Before Adding BIC:
// Old optimized AIR
Lshift %x0, amount, %x0, @3
Rshift %x0, amount, %x0, @4
Lshift %x0, lsb, %x0, @5
Ret %x0, @6
After Adding BIC:
// New optimized AIR
InsertSignedBitfieldInZero %x0, lsb, width, %x0, @5
Ret %x0, @6
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::insertSignedBitfieldInZero32):
(JSC::MacroAssemblerARM64::insertSignedBitfieldInZero64):
(JSC::MacroAssemblerARM64::extractSignedBitfield32):
(JSC::MacroAssemblerARM64::extractSignedBitfield64):
* assembler/testmasm.cpp:
(JSC::testInsertSignedBitfieldInZero32):
(JSC::testInsertSignedBitfieldInZero64):
(JSC::testExtractSignedBitfield32):
(JSC::testExtractSignedBitfield64):
* b3/B3LowerToAir.cpp:
* b3/B3ReduceStrength.cpp:
* b3/air/AirOpcode.opcodes:
* b3/testb3.h:
* b3/testb3_2.cpp:
(addBitTests):
* b3/testb3_3.cpp:
(testInsertSignedBitfieldInZero32):
(testInsertSignedBitfieldInZero64):
(testExtractSignedBitfield32):
(testExtractSignedBitfield64):
2021-06-28 Yijia Huang <yijia_huang@apple.com>
Add a new pattern to instruction selector to use BIC supported by ARM64
https://bugs.webkit.org/show_bug.cgi?id=227202
Reviewed by Filip Pizlo.
This patch includes three modifications:
1. Add bit clear (BIC), or not (ORN), and extract and insert bitfield at the
lower end (BFXIL) to Air opcode to serve instruction selector.
2. Add bitfield clear (BFC) to MacroAssembler.
4. Do refactoring - rename Air opcodes added in the previous patches.
------------------
### Part A BIC ###
------------------
Given the operation:
bic Rd, Rn, Rm
The BIC (Bit Clear) instruction performs an AND operation on the bits in Rn with the
complements of the corresponding bits in the value of Rm. The instruction selector can
utilize this to lowering certain patterns in B3 IR before further Air optimization.
The equivalent patterns of this instruction are:
Pattern 1:
d = n & (-m - 1)
Pattern 2:
d = n & (m ^ -1)
In order to get benefits for complement operation, the current instruction selector uses
mvn instruction to lower the pattern value ^ -1. Then, a new strength reduction rule is
introduced:
Turn this: -value - 1
Into this: value ^ -1
So, d = n & (m ^ -1) is selected as the canonical form.
Given B3 IR:
Int @0 = ArgumentReg(%x0)
Int @1 = ArgumentReg(%x1)
Int @2 = -1
Int @3 = BitXor(@1, @2)
Int @4 = BitAnd(@0, @3)
Void@5 = Return(@4, Terminal)
Before Adding BIC:
// Old optimized AIR
Not %x1, %x1, @3
And %x0, %x1, %x0, @4
Ret %x0, @5
After Adding BIC:
// New optimized AIR
Bic %x0, %x1, %x0, @4
Ret %x0, @5
------------------
### Part A ORN ###
------------------
Given the operation:
orn Rd, Rn, Rm
Bitwise OR NOT (shifted register) performs a bitwise (inclusive) OR of a register value
Rn and the complement of an optionally-shifted register value Rm, and writes the result
to the destination register Rd.
The equivalent patterns of this instruction are:
Pattern 1:
d = n | (-m - 1)
Pattern 2:
d = n | (m ^ -1)
Then, d = n | (m ^ -1) is selected as the canonical form.
Given B3 IR:
Int @0 = ArgumentReg(%x0)
Int @1 = ArgumentReg(%x1)
Int @2 = -1
Int @3 = BitXor(@1, @2)
Int @4 = BitOr(@0, @3)
Void@5 = Return(@4, Terminal)
Before Adding BIC:
// Old optimized AIR
Not %x1, %x1, @3
Or %x0, %x1, %x0, @4
Ret %x0, @5
After Adding BIC:
// New optimized AIR
Orn %x0, %x1, %x0, @4
Ret %x0, @5
--------------------
### Part A BFXIL ###
--------------------
Given the operation:
bfxil Rd, Rn, lsb, width
Bitfield extract and insert at low end(BFXIL) copies any number of low-order bits
from a source register into the same number of adjacent bits at the low end in
the destination register, leaving other bits unchanged.
The equivalent patterns of this instruction are:
Pattern 1:
mask1 = (1 << width) - 1
mask2 = ~mask1
((n >> lsb) & mask1) | (d & mask2)
Pattern 2:
mask1 = ((1 << width) - 1) << lsb
mask2 = ~(mask1 >> lsb)
((n & mask1) >> lsb) | (d & mask2)
Then, introduce a strength reduction rule for easier recognization.
Turn this: (v & maskShift) >> shiftAmount
Into this: (v >> shiftAmount) & mask
with constraints:
1. maskShift = mask << lsb
2. mask = (1 << width) - 1
3. 0 <= shiftAmount < datasize
4. 0 < width < datasize
5. shiftAmount + width <= datasize
The canonical form to match BFXIL is d = ((n >> lsb) & mask1) | (d & mask2).
Given B3 IR:
Int @0 = ArgumentReg(%x0)
Int @1 = ArgumentReg(%x1)
Int @2 = lsb
Int @3 = mask1
Int @4 = mask2
Int @5 = BitAnd(@1, @3)
Int @6 = BitAnd(@0, @4))
Int @7 = ZShr(@5, @2)
Int @8 = BitOr(@7, @6)
Void@9 = Return(@8, Terminal)
Before Adding BIC:
// Old optimized AIR
And mask2, %x0, %x0, @6
ExtractUnsignedBitfield %x1, lsb, width, %x1, @7
Or %x0, %x1, %x0, @8
Ret %x0, @9
After Adding BIC:
// New optimized AIR
ExtractInsertBitfieldAtLowEnd %x1, lsb, width, %x0, @8
Ret64 %x0, @9
--------------
### Part B ###
--------------
The Bitfield Clear (BFC), leaving other bits unchanged, is similar to BFI which is an
alias of BFM. Given the operation:
bfc Rd, lsb, width
The equivalent pattern of this instruction is:
mask = ((1 << width) - 1) << lsb
d = d & ~mask
Since mask is a constant and B3 performs constant fold in the optimization phase, this
pattern will directly lower to the BitAnd binary operation. So, no need to match this pattern.
--------------
### Part C ###
--------------
At MacroAssembler level, the emitters are exepected to be expressed in english
(e.g. something like clearBitField for BFC). Do refactoring to rename Air opcode for
UBFX, UBFIZ, BFI, and BIC.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::bfc):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::extractUnsignedBitfield32):
(JSC::MacroAssemblerARM64::extractUnsignedBitfield64):
(JSC::MacroAssemblerARM64::insertUnsignedBitfieldInZero32):
(JSC::MacroAssemblerARM64::insertUnsignedBitfieldInZero64):
(JSC::MacroAssemblerARM64::insertBitField32):
(JSC::MacroAssemblerARM64::insertBitField64):
(JSC::MacroAssemblerARM64::clearBitField32):
(JSC::MacroAssemblerARM64::clearBitField64):
(JSC::MacroAssemblerARM64::clearBitsWithMask32):
(JSC::MacroAssemblerARM64::clearBitsWithMask64):
(JSC::MacroAssemblerARM64::orNot32):
(JSC::MacroAssemblerARM64::orNot64):
(JSC::MacroAssemblerARM64::ubfx32): Deleted.
(JSC::MacroAssemblerARM64::ubfx64): Deleted.
(JSC::MacroAssemblerARM64::ubfiz32): Deleted.
(JSC::MacroAssemblerARM64::ubfiz64): Deleted.
(JSC::MacroAssemblerARM64::bitFieldInsert32): Deleted.
(JSC::MacroAssemblerARM64::bitFieldInsert64): Deleted.
* assembler/testmasm.cpp:
(JSC::testMultiplySignExtend32):
(JSC::testMultiplySubSignExtend32):
(JSC::testExtractUnsignedBitfield32):
(JSC::testExtractUnsignedBitfield64):
(JSC::testInsertUnsignedBitfieldInZero32):
(JSC::testInsertUnsignedBitfieldInZero64):
(JSC::testInsertBitField32):
(JSC::testInsertBitField64):
(JSC::testClearBitField32):
(JSC::testClearBitField64):
(JSC::testClearBitsWithMask32):
(JSC::testClearBitsWithMask64):
(JSC::testOrNot32):
(JSC::testOrNot64):
(JSC::testMul32SignExtend): Deleted.
(JSC::testMulSubSignExtend32): Deleted.
(JSC::testUbfx32): Deleted.
(JSC::testUbfx64): Deleted.
(JSC::testUbfiz32): Deleted.
(JSC::testUbfiz64): Deleted.
(JSC::testBitFieldInsert32): Deleted.
(JSC::testBitFieldInsert64): Deleted.
* b3/B3LowerToAir.cpp:
* b3/B3ReduceStrength.cpp:
* b3/air/AirOpcode.opcodes:
* b3/testb3.h:
* b3/testb3_2.cpp:
(testInsertBitField32):
(testInsertBitField64):
(testBIC32):
(testBIC64):
(testOrNot32):
(testOrNot64):
(addBitTests):
(testBitFieldInsert32): Deleted.
(testBitFieldInsert64): Deleted.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::cageWithoutUntagging):
(JSC::AssemblyHelpers::cageConditionallyAndUntag):
2021-06-28 Mikhail R. Gadelha <mikhail@igalia.com>
Add LLInt fast path for less, lesseq, greater and greatereq
https://bugs.webkit.org/show_bug.cgi?id=226266
Reviewed by Tadeu Zagallo.
The motivation is to add fast path for integers and doubles
in LLInt, so we don't need to go to slow path for those cases.
This patch implements the less, lesseq, greater, greatereq
instruction for ARMv7, MIPS and CLoop.
Microbenchmarking results:
* x86_64: number-comparison-inline definitely 1.3520x faster
* ARMv7: number-comparison-inline definitely 1.3520x faster
JetStream2 results:
* x86_64 jit: 1.015 times better
* x86_64 no-jit: 1.018 times better
* ARMv7 no-jit: 1.004 times worse
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* offlineasm/arm.rb:
* offlineasm/cloop.rb:
* offlineasm/mips.rb:
2021-06-28 Mikhail R. Gadelha <mikhail@igalia.com>
Prevent sign-extended casts for 32 bits arch
https://bugs.webkit.org/show_bug.cgi?id=227170
Reviewed by Yusuke Suzuki.
In a number of places, addresses are reinterpreted as uint64, which can
lead to wrong addresses in 32 bits arch.
* assembler/testmasm.cpp:
(JSC::testBranchTruncateDoubleToInt32):
* disassembler/ARM64/A64DOpcode.h:
(JSC::ARM64Disassembler::A64DOpcode::appendPCRelativeOffset):
* runtime/JSCell.cpp:
(JSC::reportZappedCellAndCrash):
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::emitEntryTierUpCheck):
(JSC::Wasm::AirIRGenerator::emitLoopTierUpCheck):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::emitEntryTierUpCheck):
(JSC::Wasm::B3IRGenerator::emitLoopTierUpCheck):
2021-06-25 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r279266.
https://bugs.webkit.org/show_bug.cgi?id=227402
Causes crash loop
Reverted changeset:
"Remove references to order files"
https://bugs.webkit.org/show_bug.cgi?id=227377
https://trac.webkit.org/changeset/279266
2021-06-24 Sihui Liu <sihui_liu@apple.com>
Remove references to order files
https://bugs.webkit.org/show_bug.cgi?id=227377
rdar://76070556
Reviewed by Mark Lam.
* Configurations/JavaScriptCore.xcconfig:
2021-06-24 Asumu Takikawa <asumu@igalia.com>
[WASM-Function-References] Add support for (ref null? $t) type constructor
https://bugs.webkit.org/show_bug.cgi?id=226296
Reviewed by Yusuke Suzuki.
Adds the `ref` type constructor from the typed function references proposal:
https://github.com/WebAssembly/function-references/blob/master/proposals/function-references/Overview.md
It's also required for the type imports and GC proposals as well. Ref types represent
references to any heap type (including existing funcref and externref) with a specified
nullability.
This requires a new isNullable flag in the type representation. This flag also enables
non-null externref and funcrefs, and hence this commit also adds the necessary checks
at Wasm/JS boundaries.
Non-null reference types also generally cannot be used as function locals.
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::gTypeIdx):
(JSC::Wasm::AirIRGenerator::tmpForType):
(JSC::Wasm::AirIRGenerator::emitCCall):
(JSC::Wasm::AirIRGenerator::moveOpForValueType):
(JSC::Wasm::AirIRGenerator::AirIRGenerator):
(JSC::Wasm::AirIRGenerator::addLocal):
(JSC::Wasm::AirIRGenerator::addConstant):
(JSC::Wasm::AirIRGenerator::addRefFunc):
* wasm/WasmCallingConvention.h:
(JSC::Wasm::WasmCallingConvention::marshallLocation const):
(JSC::Wasm::JSCallingConvention::marshallLocation const):
* wasm/WasmFormat.h:
(JSC::Wasm::isSubtype):
(JSC::Wasm::isValidHeapTypeKind):
(JSC::Wasm::isDefaultableType):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parse):
(JSC::Wasm::FunctionParser<Context>::parseAnnotatedSelectImmediates):
(JSC::Wasm::FunctionParser<Context>::checkBranchTarget):
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/WasmGlobal.cpp:
(JSC::Wasm::Global::get const):
(JSC::Wasm::Global::set):
* wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::LLIntGenerator::callInformationForCaller):
(JSC::Wasm::LLIntGenerator::callInformationForCallee):
(JSC::Wasm::LLIntGenerator::addArguments):
* wasm/WasmParser.h:
(JSC::Wasm::Parser<SuccessType>::parseBlockSignature):
(JSC::Wasm::Parser<SuccessType>::parseValueType):
(JSC::Wasm::Parser<SuccessType>::parseRefType):
* wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseType):
(JSC::Wasm::SectionParser::parseElement):
(JSC::Wasm::SectionParser::parseInitExpr):
(JSC::Wasm::SectionParser::parseElementSegmentVectorOfExpressions):
(JSC::Wasm::SectionParser::parseGlobalType):
* wasm/WasmSignature.cpp:
(JSC::Wasm::computeHash):
* wasm/generateWasmOpsHeader.py:
* wasm/js/WasmToJS.cpp:
(JSC::Wasm::wasmToJS):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::WebAssemblyFunction::jsCallEntrypointSlow):
* wasm/js/WebAssemblyFunctionBase.h:
(JSC::WebAssemblyFunctionBase::offsetOfSignatureIndex):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::linkImpl):
* wasm/wasm.json:
2021-06-24 Mark Lam <mark.lam@apple.com>
Use ldp and stp more for saving / restoring registers on ARM64.
https://bugs.webkit.org/show_bug.cgi?id=227039
rdar://79354736
Reviewed by Saam Barati.
This patch introduces a spooler abstraction in AssemblyHelpers. The spooler
basically batches up load / store operations and emit them as pair instructions
if appropriate.
There are 4 spooler classes:
a. Spooler
- template base class for LoadRegSpooler and StoreRegSpooler.
- encapsulates the batching strategy for load / store pairs.
b. LoadRegSpooler - specializes Spooler to handle load pairs.
b. StoreRegSpooler - specializes Spooler to handle store pairs.
d. CopySpooler
- handles matching loads with stores.
- tries to emit loads as load pairs if possible.
- tries to emot stores as store pairs if possible.
- ensures that pre-requisite loads are emitted before stores are emitted.
- other than loads, also support constants and registers as sources of values
to be stored. This is useful in OSR exit ramps where we may materialize a
stack value to store from constants or registers in addition to values we
load from the old stack frame or from a scratch buffer.
In this patch, we also do the following:
1. Use spoolers in many places so that we can emit load / store pairs instead of
single load / stores. This helps shrink JIT code side, and also potentially
improves performance.
2. In DFG::OSRExit::compileExit(), we used to recover constants into a scratch
buffer, and then later, load from that scratch buffer to store into the
new stack frame(s).
This patch changes it so that we defer constant recovery until the final
loop where we store the recovered value directly into the new stack frame(s).
This saves us the work (and JIT code space) for storing into a scratch buffer
and then reloading from the scratch buffer.
There is one exception: tmp values used by active checkpoints. We need to call
operationMaterializeOSRExitSideState() to materialize the active checkpoint
side state before the final loop where we now recover constants. Hence, we
need these tmp values recovered before hand.
So, we check upfront if we have active checkpoint side state to materialize.
If so, we'll eagerly recover the constants for initializing those tmps.
We also use the CopySpooler in the final loop to emit load / store pairs for
filling in the new stack frame(s).
One more thing: it turns out that the vast majority of constants to be recovered
is simply the undefined value. So, as an optimization, the final loop keeps
the undefined value in a register, and has the spooler store directly from
that register when appropriate. This saves on JIT code to repeatedly materialize
the undefined JSValue constant.
3. In reifyInlinedCallFrames(), replace the use of GPRInfo::nonArgGPR0 with
GPRInfo::regT4. nonArgGPRs are sometimes map to certain regTXs on certain ports.
Replacing with regT4 makes it easier to ensure that we're not trashing the
register when we use more temp registers.
reifyInlinedCallFrames() will be using emitSaveOrCopyLLIntBaselineCalleeSavesFor()
later where we need more temp registers.
4. Move the following functions to AssemblyHelpers.cpp. They don't need to be
inline functions. Speedometer2 and JetStream2 shows that making these non
inline does not hurt performance:
AssemblyHelpers::emitSave(const RegisterAtOffsetList&);
AssemblyHelpers::emitRestore(const RegisterAtOffsetList&);
AssemblyHelpers::emitSaveCalleeSavesFor(const RegisterAtOffsetList*);
AssemblyHelpers::emitSaveOrCopyCalleeSavesFor(...);
AssemblyHelpers::emitRestoreCalleeSavesFor(const RegisterAtOffsetList*);
AssemblyHelpers::copyLLIntBaselineCalleeSavesFromFrameOrRegisterToEntryFrameCalleeSavesBuffer(...);
Also renamed emitSaveOrCopyCalleeSavesFor() to emitSaveOrCopyLLIntBaselineCalleeSavesFor()
because it is only used with baseline codeBlocks.
Results:
Cummulative LinkBuffer profile sizes shrunk by ~2M in aggregate:
base new
==== ===
BaselineJIT: 83827048 (79.943703 MB) => 83718736 (79.840408 MB)
DFG: 56594836 (53.973042 MB) => 56603508 (53.981312 MB)
InlineCache: 33923900 (32.352352 MB) => 33183156 (31.645924 MB)
FTL: 6770956 (6.457287 MB) => 6568964 (6.264652 MB)
DFGOSRExit: 5212096 (4.970642 MB) => 3728088 (3.555382 MB)
CSSJIT: 748428 (730.886719 KB) => 748428 (730.886719 KB)
FTLOSRExit: 692276 (676.050781 KB) => 656884 (641.488281 KB)
YarrJIT: 445280 (434.843750 KB) => 512988 (500.964844 KB)
FTLThunk: 22908 (22.371094 KB) => 22556 (22.027344 KB)
BoundFunctionThunk: 8400 (8.203125 KB) => 10088 (9.851562 KB)
ExtraCTIThunk: 6952 (6.789062 KB) => 6824 (6.664062 KB)
SpecializedThunk: 4508 (4.402344 KB) => 4508 (4.402344 KB)
Thunk: 3912 (3.820312 KB) => 3784 (3.695312 KB)
LLIntThunk: 2908 (2.839844 KB) => 2908 (2.839844 KB)
VirtualThunk: 1248 (1.218750 KB) => 1248 (1.218750 KB)
DFGThunk: 1084 (1.058594 KB) => 444
DFGOSREntry: 216 => 184
JumpIsland: 0
WasmThunk: 0
Wasm: 0
Uncategorized: 0
Total: 188266956 (179.545361 MB) => 185773296 (177.167221 MB)
Speedometer2 and JetStream2 results shows that performance is neutral for this
patch (as measured on an M1 Mac):
Speedometer2:
----------------------------------------------------------------------------------------------------------------------------------
| subtest | ms | ms | b / a | pValue (significance using False Discovery Rate) |
----------------------------------------------------------------------------------------------------------------------------------
| Elm-TodoMVC |129.037500 |127.212500 |0.985857 | 0.012706 |
| VueJS-TodoMVC |28.312500 |27.525000 |0.972185 | 0.240315 |
| EmberJS-TodoMVC |132.550000 |132.025000 |0.996039 | 0.538034 |
| Flight-TodoMVC |80.762500 |80.875000 |1.001393 | 0.914749 |
| BackboneJS-TodoMVC |51.637500 |51.175000 |0.991043 | 0.285427 |
| Preact-TodoMVC |21.025000 |22.075000 |1.049941 | 0.206140 |
| AngularJS-TodoMVC |142.900000 |142.887500 |0.999913 | 0.990681 |
| Inferno-TodoMVC |69.300000 |69.775000 |1.006854 | 0.505201 |
| Vanilla-ES2015-TodoMVC |71.500000 |71.225000 |0.996154 | 0.608650 |
| Angular2-TypeScript-TodoMVC |43.287500 |43.275000 |0.999711 | 0.987926 |
| VanillaJS-TodoMVC |57.212500 |57.812500 |1.010487 | 0.333357 |
| jQuery-TodoMVC |276.150000 |276.775000 |1.002263 | 0.614404 |
| EmberJS-Debug-TodoMVC |353.612500 |352.762500 |0.997596 | 0.518836 |
| React-TodoMVC |93.637500 |92.637500 |0.989321 | 0.036277 |
| React-Redux-TodoMVC |158.237500 |156.587500 |0.989573 | 0.042154 |
| Vanilla-ES2015-Babel-Webpack-TodoMVC |68.050000 |68.087500 |1.000551 | 0.897149 |
----------------------------------------------------------------------------------------------------------------------------------
a mean = 236.26950
b mean = 236.57964
pValue = 0.7830785938
(Bigger means are better.)
1.001 times better
Results ARE NOT significant
JetStream2:
-------------------------------------------------------------------------------------------------------------------------
| subtest | pts | pts | b / a | pValue (significance using False Discovery Rate) |
-------------------------------------------------------------------------------------------------------------------------
| gaussian-blur |542.570057 |542.671885 |1.000188 | 0.982573 |
| HashSet-wasm |57.710498 |64.406371 |1.116025 | 0.401424 |
| gcc-loops-wasm |44.516009 |44.453535 |0.998597 | 0.973651 |
| json-parse-inspector |241.275085 |240.720491 |0.997701 | 0.704732 |
| prepack-wtb |62.640114 |63.754878 |1.017796 | 0.205840 |
| date-format-xparb-SP |416.976817 |448.921409 |1.076610 | 0.052977 |
| WSL |1.555257 |1.570233 |1.009629 | 0.427924 |
| OfflineAssembler |177.052352 |179.746511 |1.015217 | 0.112114 |
| cdjs |192.517586 |194.598906 |1.010811 | 0.025807 |
| UniPoker |514.023694 |526.111500 |1.023516 | 0.269892 |
| json-stringify-inspector |227.584725 |223.619390 |0.982576 | 0.102714 |
| crypto-sha1-SP |980.728788 |984.192104 |1.003531 | 0.838618 |
| Basic |685.148483 |711.590247 |1.038593 | 0.142952 |
| chai-wtb |106.256376 |106.590318 |1.003143 | 0.865894 |
| crypto-aes-SP |722.308829 |728.702310 |1.008851 | 0.486766 |
| Babylon |655.857561 |654.204901 |0.997480 | 0.931520 |
| string-unpack-code-SP |407.837271 |405.710752 |0.994786 | 0.729122 |
| stanford-crypto-aes |456.906021 |449.993856 |0.984872 | 0.272994 |
| raytrace |883.911335 |902.887238 |1.021468 | 0.189785 |
| multi-inspector-code-load |409.997347 |405.643639 |0.989381 | 0.644447 |
| hash-map |593.590160 |601.576332 |1.013454 | 0.249414 |
| stanford-crypto-pbkdf2 |722.178638 |728.283532 |1.008453 | 0.661195 |
| coffeescript-wtb |42.393544 |41.869545 |0.987640 | 0.197441 |
| Box2D |452.034685 |454.104868 |1.004580 | 0.535342 |
| richards-wasm |140.873688 |148.394050 |1.053384 | 0.303651 |
| lebab-wtb |61.671318 |62.119403 |1.007266 | 0.620998 |
| tsf-wasm |108.592794 |119.498398 |1.100427 | 0.504710 |
| base64-SP |629.744643 |603.425565 |0.958207 | 0.049997 |
| navier-stokes |740.588523 |739.951662 |0.999140 | 0.871445 |
| jshint-wtb |51.938359 |52.651104 |1.013723 | 0.217137 |
| regex-dna-SP |459.251148 |463.492489 |1.009235 | 0.371891 |
| async-fs |235.853820 |236.031189 |1.000752 | 0.938459 |
| first-inspector-code-load |275.298325 |274.172125 |0.995909 | 0.623403 |
| segmentation |44.002842 |43.445960 |0.987344 | 0.207134 |
| typescript |26.360161 |26.458820 |1.003743 | 0.609942 |
| octane-code-load |1126.749036 |1087.132024 |0.964840 | 0.524171 |
| float-mm.c |16.691935 |16.721354 |1.001762 | 0.194425 |
| quicksort-wasm |461.630091 |450.161127 |0.975156 | 0.371394 |
| Air |392.442375 |412.201810 |1.050350 | 0.046887 |
| splay |510.111886 |475.131657 |0.931426 | 0.024732 |
| ai-astar |607.966974 |626.573181 |1.030604 | 0.468711 |
| acorn-wtb |67.510766 |68.143956 |1.009379 | 0.481663 |
| gbemu |144.133842 |145.620304 |1.010313 | 0.802154 |
| richards |963.475078 |946.658879 |0.982546 | 0.231189 |
| 3d-cube-SP |549.426784 |550.479154 |1.001915 | 0.831307 |
| espree-wtb |68.707483 |73.762202 |1.073569 | 0.033603 |
| bomb-workers |96.882596 |96.116121 |0.992089 | 0.687952 |
| tagcloud-SP |309.888767 |303.538511 |0.979508 | 0.187768 |
| mandreel |133.667031 |135.009929 |1.010047 | 0.075232 |
| 3d-raytrace-SP |491.967649 |492.528992 |1.001141 | 0.957842 |
| delta-blue |1066.718312 |1080.230772 |1.012667 | 0.549382 |
| ML |139.617293 |140.088630 |1.003376 | 0.661651 |
| regexp |351.773956 |351.075935 |0.998016 | 0.769250 |
| crypto |1510.474663 |1519.218842 |1.005789 | 0.638420 |
| crypto-md5-SP |795.447899 |774.082493 |0.973140 | 0.079728 |
| earley-boyer |812.574545 |870.678372 |1.071506 | 0.044081 |
| octane-zlib |25.162470 |25.660261 |1.019783 | 0.554591 |
| date-format-tofte-SP |395.296135 |398.008992 |1.006863 | 0.650475 |
| n-body-SP |1165.386611 |1150.525110 |0.987248 | 0.227908 |
| pdfjs |189.060252 |191.015628 |1.010343 | 0.633777 |
| FlightPlanner |908.426192 |903.636642 |0.994728 | 0.838821 |
| uglify-js-wtb |34.029399 |34.164342 |1.003965 | 0.655652 |
| babylon-wtb |81.329869 |80.855680 |0.994170 | 0.854393 |
| stanford-crypto-sha256 |826.850533 |838.494164 |1.014082 | 0.579636 |
-------------------------------------------------------------------------------------------------------------------------
a mean = 237.91084
b mean = 239.92670
pValue = 0.0657710897
(Bigger means are better.)
1.008 times better
Results ARE NOT significant
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::pushToSaveByteOffset):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::pushToSaveByteOffset):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::compileExit):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
* dfg/DFGThunks.cpp:
(JSC::DFG::osrExitGenerationThunkGenerator):
* ftl/FTLSaveRestore.cpp:
(JSC::FTL::saveAllRegisters):
(JSC::FTL::restoreAllRegisters):
* ftl/FTLSaveRestore.h:
* ftl/FTLThunks.cpp:
(JSC::FTL::genericGenerationThunkGenerator):
(JSC::FTL::slowPathCallThunkGenerator):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::restoreCalleeSavesFromEntryFrameCalleeSavesBuffer):
(JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBufferImpl):
(JSC::AssemblyHelpers::emitSave):
(JSC::AssemblyHelpers::emitRestore):
(JSC::AssemblyHelpers::emitSaveCalleeSavesFor):
(JSC::AssemblyHelpers::emitRestoreCalleeSavesFor):
(JSC::AssemblyHelpers::copyLLIntBaselineCalleeSavesFromFrameOrRegisterToEntryFrameCalleeSavesBuffer):
(JSC::AssemblyHelpers::emitSaveOrCopyLLIntBaselineCalleeSavesFor):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::copyLLIntBaselineCalleeSavesFromFrameOrRegisterToEntryFrameCalleeSavesBuffer):
(JSC::AssemblyHelpers::emitSave): Deleted.
(JSC::AssemblyHelpers::emitRestore): Deleted.
(JSC::AssemblyHelpers::emitSaveOrCopyCalleeSavesFor): Deleted.
* jit/AssemblyHelpersSpoolers.h: Added.
(JSC::AssemblyHelpers::Spooler::Spooler):
(JSC::AssemblyHelpers::Spooler::handleGPR):
(JSC::AssemblyHelpers::Spooler::finalizeGPR):
(JSC::AssemblyHelpers::Spooler::handleFPR):
(JSC::AssemblyHelpers::Spooler::finalizeFPR):
(JSC::AssemblyHelpers::Spooler::op):
(JSC::AssemblyHelpers::LoadRegSpooler::LoadRegSpooler):
(JSC::AssemblyHelpers::LoadRegSpooler::loadGPR):
(JSC::AssemblyHelpers::LoadRegSpooler::finalizeGPR):
(JSC::AssemblyHelpers::LoadRegSpooler::loadFPR):
(JSC::AssemblyHelpers::LoadRegSpooler::finalizeFPR):
(JSC::AssemblyHelpers::LoadRegSpooler::handlePair):
(JSC::AssemblyHelpers::LoadRegSpooler::handleSingle):
(JSC::AssemblyHelpers::StoreRegSpooler::StoreRegSpooler):
(JSC::AssemblyHelpers::StoreRegSpooler::storeGPR):
(JSC::AssemblyHelpers::StoreRegSpooler::finalizeGPR):
(JSC::AssemblyHelpers::StoreRegSpooler::storeFPR):
(JSC::AssemblyHelpers::StoreRegSpooler::finalizeFPR):
(JSC::AssemblyHelpers::StoreRegSpooler::handlePair):
(JSC::AssemblyHelpers::StoreRegSpooler::handleSingle):
(JSC::RegDispatch<GPRReg>::get):
(JSC::RegDispatch<GPRReg>::temp1):
(JSC::RegDispatch<GPRReg>::temp2):
(JSC::RegDispatch<GPRReg>::regToStore):
(JSC::RegDispatch<GPRReg>::invalid):
(JSC::RegDispatch<GPRReg>::regSize):
(JSC::RegDispatch<GPRReg>::isValidLoadPairImm):
(JSC::RegDispatch<GPRReg>::isValidStorePairImm):
(JSC::RegDispatch<FPRReg>::get):
(JSC::RegDispatch<FPRReg>::temp1):
(JSC::RegDispatch<FPRReg>::temp2):
(JSC::RegDispatch<FPRReg>::regToStore):
(JSC::RegDispatch<FPRReg>::invalid):
(JSC::RegDispatch<FPRReg>::regSize):
(JSC::RegDispatch<FPRReg>::isValidLoadPairImm):
(JSC::RegDispatch<FPRReg>::isValidStorePairImm):
(JSC::AssemblyHelpers::CopySpooler::Source::getReg):
(JSC::AssemblyHelpers::CopySpooler::CopySpooler):
(JSC::AssemblyHelpers::CopySpooler::temp1 const):
(JSC::AssemblyHelpers::CopySpooler::temp2 const):
(JSC::AssemblyHelpers::CopySpooler::regToStore):
(JSC::AssemblyHelpers::CopySpooler::invalid):
(JSC::AssemblyHelpers::CopySpooler::regSize):
(JSC::AssemblyHelpers::CopySpooler::isValidLoadPairImm):
(JSC::AssemblyHelpers::CopySpooler::isValidStorePairImm):
(JSC::AssemblyHelpers::CopySpooler::load):
(JSC::AssemblyHelpers::CopySpooler::move):
(JSC::AssemblyHelpers::CopySpooler::copy):
(JSC::AssemblyHelpers::CopySpooler::store):
(JSC::AssemblyHelpers::CopySpooler::flush):
(JSC::AssemblyHelpers::CopySpooler::loadGPR):
(JSC::AssemblyHelpers::CopySpooler::copyGPR):
(JSC::AssemblyHelpers::CopySpooler::moveConstant):
(JSC::AssemblyHelpers::CopySpooler::storeGPR):
(JSC::AssemblyHelpers::CopySpooler::finalizeGPR):
(JSC::AssemblyHelpers::CopySpooler::loadFPR):
(JSC::AssemblyHelpers::CopySpooler::copyFPR):
(JSC::AssemblyHelpers::CopySpooler::storeFPR):
(JSC::AssemblyHelpers::CopySpooler::finalizeFPR):
(JSC::AssemblyHelpers::CopySpooler::loadPair):
(JSC::AssemblyHelpers::CopySpooler::storePair):
* jit/ScratchRegisterAllocator.cpp:
(JSC::ScratchRegisterAllocator::preserveReusedRegistersByPushing):
(JSC::ScratchRegisterAllocator::restoreReusedRegistersByPopping):
(JSC::ScratchRegisterAllocator::preserveRegistersToStackForCall):
(JSC::ScratchRegisterAllocator::restoreRegistersFromStackForCall):
* jit/ScratchRegisterAllocator.h:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::addReturn):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addReturn):
2021-06-24 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, build fix for ARM64
https://bugs.webkit.org/show_bug.cgi?id=227201
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::cageWithoutUntagging):
(JSC::AssemblyHelpers::cageConditionallyAndUntag):
2021-06-24 Yijia Huang <yijia_huang@apple.com>
Add a new pattern to instruction selector to utilize BFI supported by ARM64
https://bugs.webkit.org/show_bug.cgi?id=227201
Reviewed by Filip Pizlo.
Bitfield insert(BFI), leaving other bits unchanged. The instruction selector
can utilize this to lowering certain patterns in B3 IR before further Air
optimization. Given the operation:
bfi d, n, lsb, width
The equivalent pattern would be:
Pattern 1:
mask1 = ((1 << width) - 1) << lsb
mask2 = ~mask1
d = ((n << lsb) & mask1) | (d & mask2);
Pattern 2:
mask1 = (1 << width) - 1
mask2 = ~(mask1 << lsb)
d = ((n & mask1) << lsb) | (d & mask2)
Current optimizer already has the strength reduction rule:
Turn This: (n << lsb) & mask1)
Into This: (n & mask1) << lsb)
Then, d = ((n & mask1) << lsb) | (d & mask2) is the canonical form.
With constraints:
1. 0 <= lsb < datasize
2. 0 < width < datasize
3. lsb + width <= dataszie
Given B3 IR:
Int @0 = ArgumentReg(%x0)
Int @1 = ArgumentReg(%x1)
Int @2 = lsb
Int @3 = mask
Int @4 = BitAnd(@1, @3)
Int @5 = Shl(@4, @2)
Int @6 = BitOr(@0, @5)
Int @7 = Return(@6, Terminal)
Before Adding BFI:
// Old optimized AIR
And mask, %x1, %x1, @4
Lshift %x1, lsb, %x1, @5
Or %x1, %x0, %x0, @6
Ret %x0, @7
After Adding BFI:
// New optimized AIR
BitFieldInsert %x1, lsb, width, %x0, @6
Ret %x0, @7
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::bitFieldInsert32):
(JSC::MacroAssemblerARM64::bitFieldInsert64):
* assembler/testmasm.cpp:
(JSC::testUbfx32):
(JSC::testUbfx64):
(JSC::testUbfiz32):
(JSC::testUbfiz64):
(JSC::testBitFieldInsert32):
(JSC::testBitFieldInsert64):
* b3/B3LowerToAir.cpp:
* b3/air/AirOpcode.opcodes:
* b3/testb3.h:
* b3/testb3_2.cpp:
(testBitFieldInsert32):
(testBitFieldInsert64):
(addBitTests):
2021-06-24 Xan López <xan@igalia.com>
[JSC] Implement returnEarlyFromInfiniteLoopsForFuzzing for 32bits
https://bugs.webkit.org/show_bug.cgi?id=227290
Reviewed by Mark Lam.
Mostly a matter of changing the counter type to uintptr_t and
making the baseline/dfg/ftl code generation work on both 32 and
64bits, most of it can be shared with minor tweaks.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileLoopHint):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_loop_hint):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter32_64.asm:
* runtime/VM.cpp:
(JSC::VM::addLoopHintExecutionCounter):
(JSC::VM::getLoopHintExecutionCounter):
* runtime/VM.h:
2021-06-23 Mark Lam <mark.lam@apple.com>
Base Options::useWebAssemblyFastMemory's default value on Gigacage::hasCapacityToUseLargeGigacage.
https://bugs.webkit.org/show_bug.cgi?id=227328
Reviewed by Saam Barati.
Gigacage::hasCapacityToUseLargeGigacage is determined based on EFFECTIVE_ADDRESS_WIDTH.
If we have enough address range to potentially use a large gigacage, then we have
enough address range to useWebAssemblyFastMemory.
* runtime/Options.cpp:
(JSC::canUseWebAssemblyFastMemory):
* runtime/OptionsList.h:
2021-06-23 Yijia Huang <yijia_huang@apple.com>
Add a new pattern to instruction selector to utilize UBFIZ supported by ARM64
https://bugs.webkit.org/show_bug.cgi?id=227204
Reviewed by Filip Pizlo.
This patch includes three parts:
A) Add UBFIZ to instruction selector.
B) Fix UBFX, introduced in https://bugs.webkit.org/show_bug.cgi?id=226984,
to match all patterns.
C) Fix error condition in one strength reduction rule introduced
in https://bugs.webkit.org/show_bug.cgi?id=227138.
Part A
Unsigned Bitfield Insert in Zero(UBFIZ), supported by ARM64, zeros the
destination register and copies any number of contiguous bits from a
source register into any position in the destination register. The
instruction selector can utilize this to lowering certain patterns in
B3 IR before further Air optimization.
Given the operation: ubfiz d, n, lsb, width
This is equivalent to "d = (n << lsb) & (((1 << width) - 1) << lsb)".
Since wasm introduces constant folding, then the matched patterns would be:
1.1 d = (n << lsb) & maskShift
1.2 d = maskShift & (n << lsb)
2.1 d = (n & mask) << lsb
2.2 d = (mask & n) << lsb
Where:
maskShift = mask << lsb
mask = (1 << width) - 1
To make the pattern matching in instruction selection beneficial to JIT, these
constraints should be introduced:
1. 0 <= lsb < datasize
2. 0 < width < datasize
3. lsb + width <= datasize
Choose (n & mask) << lsb as the canonical form and introduce a strength reduction.
Turn this: (n << lsb) & maskShift
Into this: (n & mask) << lsb
Given B3 IR:
Int @0 = ArgumentReg(%x0)
Int @1 = lsb
Int @2 = 0b0110
Int @3 = Shl(@0, @1)
Int @4 = BitAnd(@3, @2)
Void@5 = Return(@4, Terminal)
Before Adding UBFIZ Pattern:
// Old optimized AIR
Lshift %x0, $62, %x0, @3
And 0b0110, %x0, %x0, @4
Ret %x0, @5
After Adding UBFIZ Pattern:
// New optimized AIR
Ubfiz %x0, lsb, 2, %x0, @4
Ret %x0, @5
Part B
Fix UBFX to match both patterns:
dest = (src >> lsb) & mask
dest = mask & (src >> lsb)
Where:
1. mask = (1 << width) - 1
2. 0 <= lsb < datasize
3. 0 < width < datasize
4. lsb + width <= datasize
Part C
Fix one B3 strength reduction.
Turn this: (src >> shiftAmount) & mask
Into this: src >> shiftAmount
With updated constraints:
1. mask = (1 << width) - 1
2. 0 <= shiftAmount < datasize
3. 0 < width < datasize
4. shiftAmount + width >= datasize
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::ubfiz32):
(JSC::MacroAssemblerARM64::ubfiz64):
* assembler/testmasm.cpp:
(JSC::testUbfiz32):
(JSC::testUbfiz64):
* b3/B3LowerToAir.cpp:
* b3/air/AirOpcode.opcodes:
* b3/testb3.h:
* b3/testb3_2.cpp:
(testUbfx32ArgLeft):
(testUbfx32ArgRight):
(testUbfx64ArgLeft):
(testUbfx64ArgRight):
(testUbfiz32ArgLeft):
(testUbfiz32ArgRight):
(testUbfiz64ArgLeft):
(testUbfiz64ArgRight):
(addBitTests):
(testUbfx32): Deleted.
(testUbfx32PatternMatch): Deleted.
(testUbfx64): Deleted.
(testUbfx64PatternMatch): Deleted.
2021-06-23 Keith Miller <keith_miller@apple.com>
add/removeManagedReference:withOwner: should have autoreleasepools
https://bugs.webkit.org/show_bug.cgi?id=227308
Reviewed by Darin Adler.
Since these APIs create autoreleased objects as an implementation detail
but don't return any to the caller there's no indication such autoreleased
objects could be accumulating. Additionally, it's entirely reasonable to
call these methods in a loop an a large set of objects, which further
exacerbates the problem.
* API/JSVirtualMachine.mm:
(-[JSVirtualMachine addManagedReference:withOwner:]):
(-[JSVirtualMachine removeManagedReference:withOwner:]):
2021-06-23 Saam Barati <sbarati@apple.com>
Run lazy properties initializers under a DeferTerminationForAWhile scope
https://bugs.webkit.org/show_bug.cgi?id=227271
Reviewed by Mark Lam.
We don't expect that exceptions can be thrown when initializing
a lazy property. Termination exceptions were preventing this from
being true. The latest example found is inside JSModuleLoader when
it asserts that no exception is thrown when creating its JSMap field.
This patch makes it so termination exceptions can't be thrown when
running lazy property initializers.
* runtime/LazyPropertyInlines.h:
(JSC::ElementType>::initLater):
(JSC::ElementType>::callFunc):
2021-06-22 Yijia Huang <yijia_huang@apple.com>
Add a new pattern to instruction selector to utilize SMADDL supported by ARM64
https://bugs.webkit.org/show_bug.cgi?id=227188
Reviewed by Saam Barati.
Signed Multiply-Add Long(SMADDL), supported by ARM64, multiplies two 32-bit
register values, adds a 64-bit register value, and writes the result to the
64-bit destination register. The instruction selector can utilize this to
lowering certain patterns in B3 IR before further Air optimization.
Given the operation:
smaddl d, n, m, a
The equivalent patterns would be:
d = a + SExt32(n) * SExt32(m)
d = SExt32(n) * SExt32(m) + a
Given B3 IR:
Int @0 = ArgumentReg(%x0)
Int @1 = SExt32(Trunc(ArgumentReg(%x1)))
Int @2 = SExt32(Trunc(ArgumentReg(%x2)))
Int @3 = Mul(@1, @2)
Int @4 = Add(@0, @3)
Void@5 = Return(@4, Terminal)
Before Adding SMADDL:
// Old optimized AIR
SignExtend32ToPtr %x1, %x1, @1
SignExtend32ToPtr %x2, %x2, @2
MultiplyAdd64 %x1, %x2, %x0, %x0, @4
Ret64 %x0, @5
After Adding SMADDL:
// New optimized AIR
MultiplyAddSignExtend32 %x1, %x2, %x0, %x0, @8
Ret64 %x0, @9
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::multiplyAddSignExtend32):
* assembler/testmasm.cpp:
(JSC::testMultiplyAddSignExtend32Left):
(JSC::testMultiplyAddSignExtend32Right):
* b3/B3LowerToAir.cpp:
* b3/air/AirOpcode.opcodes:
* b3/testb3.h:
* b3/testb3_2.cpp:
(testMulAddArg):
(testMulAddArgsLeft):
(testMulAddArgsRight):
(testMulAddSignExtend32ArgsLeft):
(testMulAddSignExtend32ArgsRight):
(testMulAddArgsLeft32):
(testMulAddArgsRight32):
* b3/testb3_3.cpp:
(addArgTests):
2021-06-22 Saam Barati <sbarati@apple.com>
jitCompileAndSetHeuristics shouldn't return true when we fail to compile
https://bugs.webkit.org/show_bug.cgi?id=227155
Reviewed by Tadeu Zagallo.
jitCompileAndSetHeuristics should only return true when we've successfully
compiled a baseline JIT CodeBlock. However, with the rewrite to using a
unified JIT worklist, the code was changed to returning true when a
compilation finished, regardless of it being successful or not. This patch
fixes that error.
This bug was found by our existing executable allocation fuzzer, but at a low
hit rate. That fuzzer only ran a single test case. This patch also introduces
a new form of the executable fuzzer where we fail to allocate JIT code
randomly, and the crash manifests more reliably. And this patch also hooks
the new fuzzer into more JSC stress tests.
* dfg/DFGLICMPhase.cpp:
(JSC::DFG::LICMPhase::run):
* jit/ExecutableAllocationFuzz.cpp:
(JSC::doExecutableAllocationFuzzing):
* jsc.cpp:
(runJSC):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::jitCompileAndSetHeuristics):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/OptionsList.h:
2021-06-22 Angelos Oikonomopoulos <angelos@igalia.com>
Properly set numFPRs on ARM with NEON/VFP_V3_D32
https://bugs.webkit.org/show_bug.cgi?id=227212
Reviewed by Filip Pizlo.
Don't hardcode the number of FP regs on ARMv7 to 16; when targetting a
CPU with NEON or VFP_V3_d32, the number of FP regs is 32.
This also reverts the recent change to add an extra word to RegisterSet
which essentially covered up for this mismatch. The reason this bug only
manifested on certain compiler versions was that GCC 8.4/8.5 where built using
our buildroot infrastructure, whereas the other GCC versions we tested with
were debian system toolchains, targetting a lowest common denominator.
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::std::initializer_list<int>):
* jit/RegisterSet.h:
2021-06-21 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Add JIT ICs for `#x in obj` feature
https://bugs.webkit.org/show_bug.cgi?id=226146
Reviewed by Saam Barati.
This patch implements JIT ICs for the new `#x in obj` feature and turns the feature on by default.
Implementation closely follows InByVal, though HasPrivateBrand has a few subtleties
(namely, it cannot be viewed in terms of a PropertySlot and should not be converted to InById).
Microbenchmarks:
has-private-name 46.5777+-0.1374 ^ 6.0589+-0.0296 ^ definitely 7.6875x faster
has-private-brand 25.8823+-0.0561 ^ 19.1509+-0.0447 ^ definitely 1.3515x faster
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::reset):
* bytecode/StructureStubInfo.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleInByAsMatchStructure):
(JSC::DFG::ByteCodeParser::handleInById):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileInByVal):
(JSC::DFG::SpeculativeJIT::compileHasPrivate):
(JSC::DFG::SpeculativeJIT::compileHasPrivateName):
(JSC::DFG::SpeculativeJIT::compileHasPrivateBrand):
* dfg/DFGSpeculativeJIT.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JIT.h:
* jit/JITInlineCacheGenerator.cpp:
(JSC::JITInByValGenerator::JITInByValGenerator):
* jit/JITInlineCacheGenerator.h:
* jit/JITOperations.cpp:
(JSC::JSC_DEFINE_JIT_OPERATION):
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_in_by_val):
(JSC::JIT::emitHasPrivate):
(JSC::JIT::emitHasPrivateSlow):
(JSC::JIT::emit_op_has_private_name):
(JSC::JIT::emitSlow_op_has_private_name):
(JSC::JIT::emit_op_has_private_brand):
(JSC::JIT::emitSlow_op_has_private_brand):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_in_by_val):
(JSC::JIT::emitHasPrivate):
(JSC::JIT::emitHasPrivateSlow):
(JSC::JIT::emit_op_has_private_name):
(JSC::JIT::emitSlow_op_has_private_name):
(JSC::JIT::emit_op_has_private_brand):
(JSC::JIT::emitSlow_op_has_private_brand):
* jit/Repatch.cpp:
(JSC::appropriateOptimizingInByFunction):
(JSC::appropriateGenericInByFunction):
(JSC::tryCacheInBy):
(JSC::repatchInBy):
(JSC::tryCacheHasPrivateBrand):
(JSC::repatchHasPrivateBrand):
(JSC::resetInBy):
(JSC::resetHasPrivateBrand):
* jit/Repatch.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
* runtime/CommonSlowPaths.cpp:
* runtime/CommonSlowPaths.h:
* runtime/OptionsList.h:
2021-06-21 Don Olmstead <don.olmstead@sony.com>
Non-unified build fixes late June 2021 edition
https://bugs.webkit.org/show_bug.cgi?id=227241
Unreviewed non-unified build fixes.
* dfg/DFGDriver.h:
2021-06-21 Xan Lopez <xan@igalia.com>
[JSC] Fix consistency check during stack splitting in Wasm::LLIntGenerator::addLoop
https://bugs.webkit.org/show_bug.cgi?id=226012
Reviewed by Tadeu Zagallo.
It is possible for the wasm llint generator to call
checkConsistency() on a stack that is only halfway through being
properly setup. Specifically, when generating a loop block, we use
splitStack() to pop the arguments for the loop into a new stack,
and materializeConstantsAndLocals() to materialize the constants
and aliases in the loop arguments, but the arguments won't be
added back to the stack until the very end of the loop code
generation. Since materializeConstantsAndLocals() will check the
correctness of the expression stack, which isn't yet fully formed,
we'll fail its ASSERT. To workaround this, we create a variant of
materializeConstantsAndLocals() that does not check for
correctness (similar to what we do in push()), and manually check
the correctness of the new split stack in
Wasm::LLIntGenerator::addLoop(), which is the place that knows the
details of this intermediate state.
For more details, see: https://bugs.webkit.org/show_bug.cgi?id=226012#c8
* wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::LLIntGenerator::checkConsistencyOfExpressionStack):
(JSC::Wasm::LLIntGenerator::checkConsistency):
(JSC::Wasm::LLIntGenerator::materializeConstantsAndLocals):
(JSC::Wasm::LLIntGenerator::addLoop):
2021-06-21 Yusuke Suzuki <ysuzuki@apple.com>
Release assert memory in JSC::Wasm::Memory::growShared(JSC::Wasm::PageCount)::<lambda()>
https://bugs.webkit.org/show_bug.cgi?id=227180
Reviewed by Keith Miller.
When Wasm.Memory is shared, we should allocate bound growable memory even if initial size is 0 bytes,
since this range can be later extended by mprotect. If maximum size is also 0 byte, we already have
a path that does not allocate anything.
* wasm/WasmMemory.cpp:
(JSC::Wasm::Memory::tryCreate):
2021-06-21 Yijia Huang <yijia_huang@apple.com>
Add a new pattern to instruction selector to utilize SMSUBL supported by ARM64
https://bugs.webkit.org/show_bug.cgi?id=227195
Reviewed by Keith Miller.
Signed Multiply-Subtract Long(SMSUBL), supported by ARM64, multiplies two
32-bit register values, subtracts the product from a 64-bit register value,
and writes the result 64-bit destination register. The instruction selector
can utilize this to lowering certain patterns in B3 IR before further Air
optimization. Given the operation:
smsubl d, n, m, a
The equivalent pattern would be:
d = a - SExt32(n) * SExt32(m)
Given B3 IR:
Int @0 = ArgumentReg(%x0)
Int @1 = SExt32(Trunc(ArgumentReg(%x1)))
Int @2 = SExt32(Trunc(ArgumentReg(%x2)))
Int @3 = Mul(@1, @2)
Int @4 = Sub(@0, @3)
Void@5 = Return(@4, Terminal)
Before Adding SMSUBL:
// Old optimized AIR
SignExtend32ToPtr %x1, %x1, @1
SignExtend32ToPtr %x2, %x2, @2
MultiplySub64 %x1, %x2, %x0, %x0, @4
Ret64 %x0, @5
After Adding SMSUBL:
// New optimized AIR
MultiplySubSignExtend32 %x1, %x2, %x0, %x0, @4
Ret64 %x0, @5
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::multiplySubSignExtend32):
* assembler/testmasm.cpp:
(JSC::testMulSubSignExtend32):
* b3/B3LowerToAir.cpp:
* b3/air/AirOpcode.opcodes:
* b3/testb3.h:
* b3/testb3_2.cpp:
(testMulSubArgsLeft):
(testMulSubArgsRight):
(testMulSubArgsLeft32):
(testMulSubArgsRight32):
(testMulSubSignExtend32Args):
* b3/testb3_3.cpp:
(addArgTests):
2021-06-21 Kimmo Kinnunen <kkinnunen@apple.com>
makeUnique cannot be used to instantiate function-local classes
https://bugs.webkit.org/show_bug.cgi?id=227163
Reviewed by Antti Koivisto.
Make JSC_MAKE_PARSER_ARENA_DELETABLE_ALLOCATED
consistent with WTF_MAKE_FAST_ALLOCATED behavior
with respect to unused typedefs inside the macro.
* parser/Nodes.h:
2021-06-20 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add ValueOf fast path in toPrimitive
https://bugs.webkit.org/show_bug.cgi?id=226948
Reviewed by Ross Kirsling.
Add fast path for Object.prototype.valueOf function call since we
sometimes encounter this case in Speedometer2/EmberJS-Debug-TodoMVC.
ToT Patched
value-of-call 65.7169+-0.6192 ^ 45.0986+-0.0830 ^ definitely 1.4572x faster
* runtime/JSCJSValue.cpp:
(JSC::JSValue::toStringSlowCase const):
* runtime/JSObject.cpp:
(JSC::callToPrimitiveFunction):
2021-06-20 Robin Morisset <rmorisset@apple.com>
Fix speculated type in the one-argument overload of speculateNeitherDoubleNorHeapBigIntNorString
https://bugs.webkit.org/show_bug.cgi?id=227119
Reviewed by Yusuke Suzuki.
Same problem as bug 226786: a missing check for HeapBigInt in the speculateNeitherDoubleNorHeapBigIntNorString function introduced in 226676.
I also rewrote the SpeculatedType for NeitherDoubleNorHeapBigIntNorString in typeFilterFor for readability. The old and the new SpeculatedType are perfectly identical, it is just a different (and in my view more readable) way of writing it.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::speculateNeitherDoubleNorHeapBigIntNorString):
* dfg/DFGUseKind.h:
(JSC::DFG::typeFilterFor):
2021-06-19 Mark Lam <mark.lam@apple.com>
[Revert r278576] Put the Baseline JIT prologue and op_loop_hint code in JIT thunks.
https://bugs.webkit.org/show_bug.cgi?id=226375
Not reviewed.
Suspect regresses Speedometer2.
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::untagReturnAddress):
(JSC::AbstractMacroAssembler::untagReturnAddressWithoutExtraValidation): Deleted.
* assembler/MacroAssemblerARM64E.h:
(JSC::MacroAssemblerARM64E::untagReturnAddress):
(JSC::MacroAssemblerARM64E::untagReturnAddressWithoutExtraValidation): Deleted.
* assembler/MacroAssemblerARMv7.h:
* assembler/MacroAssemblerMIPS.h:
* bytecode/CodeBlock.h:
(JSC::CodeBlock::addressOfNumParameters):
(JSC::CodeBlock::offsetOfNumParameters):
(JSC::CodeBlock::offsetOfInstructionsRawPointer):
(JSC::CodeBlock::offsetOfNumCalleeLocals): Deleted.
(JSC::CodeBlock::offsetOfNumVars): Deleted.
(JSC::CodeBlock::offsetOfArgumentValueProfiles): Deleted.
(JSC::CodeBlock::offsetOfShouldAlwaysBeInlined): Deleted.
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitSaveCalleeSavesFor):
(JSC::AssemblyHelpers::emitSaveCalleeSavesForBaselineJIT): Deleted.
(JSC::AssemblyHelpers::emitRestoreCalleeSavesForBaselineJIT): Deleted.
* jit/JIT.cpp:
(JSC::JIT::compileAndLinkWithoutFinalizing):
(JSC::JIT::privateCompileExceptionHandlers):
(JSC::prologueGeneratorSelector): Deleted.
(JSC::JIT::prologueGenerator): Deleted.
(JSC::JIT::arityFixupPrologueGenerator): Deleted.
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::emitNakedNearCall):
* jit/JITOpcodes.cpp:
(JSC::JIT::op_ret_handlerGenerator):
(JSC::JIT::emit_op_enter):
(JSC::JIT::op_enter_handlerGenerator):
(JSC::JIT::emit_op_loop_hint):
(JSC::JIT::emitSlow_op_loop_hint):
(JSC::JIT::op_enter_Generator): Deleted.
(JSC::JIT::op_enter_canBeOptimized_Generator): Deleted.
(JSC::JIT::op_enter_cannotBeOptimized_Generator): Deleted.
(JSC::JIT::op_loop_hint_Generator): Deleted.
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_enter):
* jit/ThunkGenerators.cpp:
(JSC::popThunkStackPreservesAndHandleExceptionGenerator):
2021-06-19 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r278699.
https://bugs.webkit.org/show_bug.cgi?id=227174
Regressed JetStream2/WSL
Reverted changeset:
"[JSC] Remove useDataICInOptimizingJIT option"
https://bugs.webkit.org/show_bug.cgi?id=226862
https://trac.webkit.org/changeset/278699
2021-06-18 Yijia Huang <yijia_huang@apple.com>
Add a new pattern to B3ReduceStrength based on Bug 226984
https://bugs.webkit.org/show_bug.cgi?id=227138
Reviewed by Filip Pizlo.
In the previous patch bug 226984, a new pattern could be introduced to
B3ReduceStrength.cpp for further optimization, which is that:
dest = (src >> shiftAmount) & mask
is equivalent to
src >> shiftAmount
under these constraints:
1. shiftAmount >= 0
2. mask has a binary format in contiguous ones starting from the
least significant bit.
3. shiftAmount + bitCount(mask) == maxBitWidth
For instance (32-bit):
(src >> 12) & 0x000fffff == src >> 12
This reduction is more beneficial than UBFX in this case.
// B3 IR
Int @0 = ArgumentReg(%0)
Int @1 = 12
Int @2 = ZShr(@0, @1)
Int @3 = 0x000fffff
Int @4 = BitAnd(@2, @3))
Void@5 = Return(@4, Terminal)
w/o the pattern:
// Old optimized AIR
Ubfx %0, $12, $20, %0, @4
Ret %0, @5
w/ the pattern:
// New optimized AIR
Urshift %0, $12, %0, @3
Ret32 %0, @6
* b3/B3ReduceStrength.cpp:
* b3/testb3.h:
* b3/testb3_2.cpp:
(testBitAndZeroShiftRightImmMask32):
(testBitAndZeroShiftRightImmMask64):
(addBitTests):
2021-06-18 Robin Morisset <rmorisset@apple.com>
[DFG] Untyped branches should eliminate checks based on results from the AbstractInterpreter
https://bugs.webkit.org/show_bug.cgi?id=227159
Reviewed by Filip Pizlo.
We currently emit a ton of code for Untyped branches, as we use branchIfTruthy which does not know anything about the abstract interpreter.
Even worse: we call branchIfTruthy after emitting some fast paths, and branchIfTruthy replicates these fast paths (Int32 and Booleans).
While I plan to reduce the number of Untyped branches in some separate patches, there is a very long tail of predicted types visible in benchmarks, so I expect some of them to remain no matter what, justifying making the code emitted in that case more reasonable.
The implementation in this patch is fairly straightforward, as it follows very closely branchOnValue() from AssemblyHelpers (which was previously called through branchIfTruthy).
It was tested on the JSC stress tests, as well as on JetStream2.
On JetStream2, it reduced the average number of bytes emitted for Branch by the DFG from 30.1 to 27.5 (highly significant, it only changes by about 0.1 between runs).
Since only about 1.5k branches are untyped out of 34k in that benchmark, it means that this patch reduces the amount of code emitted for untyped branches by about 50 bytes on average.
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::branchDoubleZeroOrNaN):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitUntypedBranch):
(JSC::DFG::SpeculativeJIT::emitBranch):
2021-06-17 Mark Lam <mark.lam@apple.com>
Rename numberOfPACBits to maxNumberOfAllowedPACBits.
https://bugs.webkit.org/show_bug.cgi?id=227156
Reviewed by Saam Barati.
Just renaming the constant to better describe what it represents. There are no
behavior changes.
* assembler/MacroAssemblerARM64E.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::cageWithoutUntagging):
(JSC::AssemblyHelpers::cageConditionallyAndUntag):
* llint/LowLevelInterpreter64.asm:
2021-06-17 Mark Lam <mark.lam@apple.com>
Define MacroAssemblerARM64E::numberOfPACBits based on OS_CONSTANT(EFFECTIVE_ADDRESS_WIDTH).
https://bugs.webkit.org/show_bug.cgi?id=227147
rdar://78785309
Reviewed by Saam Barati.
* assembler/MacroAssemblerARM64E.h:
* bytecode/CodeOrigin.h:
* runtime/JSString.h:
* runtime/OptionsList.h:
2021-06-17 Fujii Hironori <Hironori.Fujii@sony.com>
Reimplement JSC::CachePayload without FileSystem::unmapViewOfFile and FileSystem::MappedFileData::leakHandle
https://bugs.webkit.org/show_bug.cgi?id=227014
Reviewed by Yusuke Suzuki.
r247542 (Bug 199759) added FileSystem::unmapViewOfFile and
FileSystem::MappedFileData::leakHandle for JSC::CachePayload to
get the mapped address and to free the address.
However, Bug 227011 is going to add a file mapping handle to
FileSystem::MappedFileData for Windows port to create a
SharedMemory from a MappedFileData. Destruction of MappedFileData
should be done only by MappedFileData dtor.
* runtime/CachePayload.cpp:
(JSC::CachePayload::makeMappedPayload):
(JSC::CachePayload::makeMallocPayload):
(JSC::CachePayload::makeEmptyPayload):
(JSC::CachePayload::CachePayload):
(JSC::CachePayload::data const):
(JSC::CachePayload::size const):
(JSC::CachePayload::~CachePayload): Deleted.
(JSC::CachePayload::operator=): Deleted.
(JSC::CachePayload::freeData): Deleted.
* runtime/CachePayload.h: Use Variant for data.
(JSC::CachePayload::data const): Deleted.
(JSC::CachePayload::size const): Deleted.
(JSC::CachePayload::CachePayload): Deleted.
2021-06-17 Yijia Huang <yijia_huang@apple.com>
Add a new pattern to instruction selector to utilize UBFX supported by ARM64
https://bugs.webkit.org/show_bug.cgi?id=226984
Reviewed by Filip Pizlo.
UBFX, supported by ARM64, copies adjacent bits from the source register into
the least significant bits of a destination register in zero extension. The
instruction selector can utilize this to lowering certain patterns in B3 IR
before further Air optimization.
ubfx dest, src, lsb, width
tmp, tmp, imm, imm
This is equivalent to "dest = (src >> lsb) & ((1 << width) - 1)". Since wasm
introduces constant folding, then the pattern would be:
dest = (src >> lsb) & mask
where the mask should have a binary format in contiguous ones starting from
the least significant bit. For example:
0b00111111
To make the pattern matching in instruction selection beneficial to JIT, these
constraints should be introduced:
1. lsb >= 0
2. width > 0
3. lsb + width <= bit field limit (32 or 64)
Given:
// B3 IR
Int @0 = ArgumentReg(%0)
Int @1 = lsb
Int @2 = 0b0011
Int @3 = ZShr(@0, @1)
Int @4 = BitAnd(@3, @2)
Void@5 = Return(@4, Terminal)
w/o UBFX Pattern:
// Old optimized AIR
Urshift %x0, lsb, %x0, @3
And 0b0011, %x0, %x0, @4
Ret %x0, @5
w/ UBFX Pattern:
// New optimized AIR
Ubfx %x0, lsb, 2, %x0, @4
Ret %x0, @5
Note:
Suppose a 32-bit version of (src >> 20) & 0x0FFF, it is equivalent to src >> 20.
In this case, Logical Shift Right should be utilized instead when:
lsb + width == bit field limit (32 or 64)
This case/pattern should be added and upadated in the future patch.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::ubfx32):
(JSC::MacroAssemblerARM64::ubfx64):
* assembler/testmasm.cpp:
(JSC::testUbfx32):
(JSC::testUbfx64):
* b3/B3LowerToAir.cpp:
* b3/air/AirOpcode.opcodes:
* b3/testb3.h:
* b3/testb3_2.cpp:
(testUbfx64PatternMatch):
(testUbfx32PatternMatch):
(addBitTests):
2021-06-17 Angelos Oikonomopoulos <angelos@igalia.com>
[JSC] Work around apparent miscompilation on ARM/GCC >=8.4
https://bugs.webkit.org/show_bug.cgi?id=227125
Reviewed by Filip Pizlo.
This seems to be a GCC miscompilation, revealed by
https://bugs.webkit.org/show_bug.cgi?id=227078. Introduce a
workaround for the GCC versions that seem to be affected.
* jit/RegisterSet.h:
2021-06-16 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Optimize JSON.parse with small data by changing Identifier pool mechanism
https://bugs.webkit.org/show_bug.cgi?id=227101
Reviewed by Mark Lam.
Found that std::array<Identifier, 128> pool in LiteralParser is too costly for construction and destruction
if JSON.parse is invoked for small data. This patch changes this pool mechanism so that we do not waste effort
allocating null Identifiers to pre-populate the recent identifiers pool. Instead, we now use a m_recentIdentifiersIndex
uint8_t array to indicate whether there's a cached recent identifier for each given first character.
We also use KeywordLookup.h's COMPARE_XCHARS to perform "true" / "false" / "null" lexing in JSON parser.
Roughly 20% improvement in microbenchmark. And roughly 2-3% improvement in Speedometer2/Flight-TodoMVC.
ToT Patched
flight-todomvc-json 67.8755+-1.1202 ^ 56.7114+-0.5048 ^ definitely 1.1969x faster
* runtime/Identifier.cpp:
(JSC::Identifier::add):
(JSC::Identifier::add8):
* runtime/Identifier.h:
(JSC::Identifier::Identifier):
(JSC::Identifier::add):
* runtime/IdentifierInlines.h:
(JSC::Identifier::add):
(JSC::Identifier::fromString):
* runtime/LiteralParser.cpp:
(JSC::compare3Chars):
(JSC::compare4Chars):
(JSC::LiteralParser<CharType>::makeIdentifier):
(JSC::LiteralParser<CharType>::Lexer::lex):
* runtime/LiteralParser.h:
2021-06-16 Mark Lam <mark.lam@apple.com>
Adopt com.apple.security.cs.jit-write-allowlist on internal builds.
https://bugs.webkit.org/show_bug.cgi?id=222148
rdar://74284026
Reviewed by Per Arne Vollan.
This will prevent various pthread permissions switching APIs from working.
We only want to adopt this for internal builds where we use the fast permission
switching macro instead. We can't adopt it for open source builds, where we
still rely on the pthread API.
* Scripts/process-entitlements.sh:
2021-06-16 Robin Morisset <rmorisset@apple.com>
Don't look at the (non-existent) child2 of DelById
https://bugs.webkit.org/show_bug.cgi?id=227095
Reviewed by Mark Lam.
Trivial fix to a broken rebase: while it is ok to share most code between DelById and DelByVal, only the latter has a child2(), so it should not be accessed if we are compiling the former.
No new test, as it was caught by one of our existing tests.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileDelBy):
2021-06-16 Yijia Huang <yijia_huang@apple.com>
Add Air opcode sub32/64(Reg, Imm, Reg) form for ARM64 and select this instruction in Air
https://bugs.webkit.org/show_bug.cgi?id=226937
Reviewed by Yusuke Suzuki.
Previously, Air arm64 sub32/64 utilize sub(Imm, Tmp) at optlevel = 0 and
add(Tmp, -Imm) at optlevel > 0 to perform and optimize sub(Tmp, Imm, Tmp).
The issue with this is that we were not eliding redundant operations.
For example:
// B3 IR
@0 = Trunc(ArgumentReg(0))
@1 = Const
@2 = Sub(@0, @1)
@3 = Return(@2)
// Old optimized Air IR
// OptLevel = 0
Move %x0, %tmp1, @0
Move $Const, %tmp2, @1
Move %tmp1, %tmp0, @2 // Redundant
Sub $Const, %tmp0, @2
Move %tmp0, %x0, @3
Ret32 %x0, @3
To remove those redundant instructions, Air arm64 sub32/64 opcode should
indicate a new form sub(Tmp, Imm, Tmp).
// New optimized Air IR
// OptLevel = 0
Move %x0, %tmp1, @0
Move $Const, %tmp2, @1
Sub %tmp1, $Const, %tmp0, @2
Move %tmp0, %x0, @3
Ret32 %x0, @3
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::sub32):
(JSC::MacroAssemblerARM64::sub64):
* assembler/testmasm.cpp:
(JSC::testSub32Args):
(JSC::testSub32Imm):
(JSC::testSub32ArgImm):
(JSC::testSub64Imm32):
(JSC::testSub64ArgImm32):
(JSC::testSub64Imm64):
(JSC::testSub64ArgImm64):
* b3/B3ReduceStrength.cpp:
* b3/air/AirOpcode.opcodes:
* b3/testb3.h:
* b3/testb3_2.cpp:
(testSubArgs32ZeroExtend):
* b3/testb3_3.cpp:
(addArgTests):
2021-06-16 Robin Morisset <rmorisset@apple.com>
Drop the FTL(DFG) graph after lowering to B3
https://bugs.webkit.org/show_bug.cgi?id=226556
Reviewed by Phil Pizlo.
This patch originally landed as r278463, was reverted in r278463.
I believe that the bug for which it was reverted actually comes from r278371, which was also reverted at the same time. So I am now relanding this.
The challenge in this patch was dealing with all of the Patchpoints created by FTLLowerDFGToB3: they get a lambda at that time, which they execute at the end of Air, and many of these lambdas were capturing a pointer to some parts of the DFG graph and reading through it when being executed.
In all cases but one it was easily fixed: they were only reading a few bits from a given node, so I just read these bits in FTLLowerDFGToB3, and captured them (by value) instead of the pointer to the node.
The exception was compileCallOrConstructVarargsSpread(): its patchpoint generator was walking through the graph, flattening a tree of PhantomSpread/PhantomNewArrayWithSpread/PhantomNewArrayBuffer/PhantomCreateRest, emitting some code along the way.
We now do this flattening of the tree in FTLLowerDFGToB3, store just enough information to later emit the required code in a vector, and capture that vector in the lambda (through a move capture, which is allowed since C++14). See `struct VarargsSpreadArgumentToEmit` for the information that we need to store in that vector.
I tested this change by completing a full run of JetStream2 with ASAN.
I also ran the stress tests with "spread" in their name in Debug mode.
* b3/B3SparseCollection.h:
(JSC::B3::SparseCollection::clearAll):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::freeDFGIRAfterLowering):
* dfg/DFGGraph.h:
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileUnaryMathIC):
(JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC):
(JSC::FTL::DFG::LowerDFGToB3::getPrivateName):
(JSC::FTL::DFG::LowerDFGToB3::compilePrivateBrandAccess):
(JSC::FTL::DFG::LowerDFGToB3::cachedPutById):
(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToB3::compileDelBy):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
(JSC::FTL::DFG::LowerDFGToB3::VarargsSpreadArgumentToEmit::VarargsSpreadArgumentToEmit):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
(JSC::FTL::DFG::LowerDFGToB3::compileCallEval):
(JSC::FTL::DFG::LowerDFGToB3::compileInById):
(JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
(JSC::FTL::DFG::LowerDFGToB3::getById):
(JSC::FTL::DFG::LowerDFGToB3::getByIdWithThis):
(JSC::FTL::DFG::LowerDFGToB3::emitBinarySnippet):
(JSC::FTL::DFG::LowerDFGToB3::emitBinaryBitOpSnippet):
(JSC::FTL::DFG::LowerDFGToB3::emitRightShiftSnippet):
(JSC::FTL::DFG::LowerDFGToB3::crash):
2021-06-16 Filip Pizlo <fpizlo@apple.com>
RegisterSet should be smaller
https://bugs.webkit.org/show_bug.cgi?id=227078
Reviewed by Geoff Garen.
Previously, every RegisterSet would have an extra 64-bit word in it just to hold state
relevant to hashtable keys.
But RegisterSet is almost never used as a hashtable key.
This patch moves the hashtable key support into a subclass, HashableRegisterSet. That class
ends up only being used in one place.
On ARM64, this makes RegisterSet use 64 bits instead of 128 bits.
On X86_64, this makes RegisterSet use 32 bits instead of 64 bits.
* JavaScriptCore.xcodeproj/project.pbxproj:
* ftl/FTLSlowPathCallKey.h:
(JSC::FTL::SlowPathCallKey::SlowPathCallKey):
* jit/HashableRegisterSet.h: Added.
(JSC::HashableRegisterSet::HashableRegisterSet):
(JSC::HashableRegisterSet::isEmptyValue const):
(JSC::HashableRegisterSet::isDeletedValue const):
(JSC::RegisterSetHash::hash):
(JSC::RegisterSetHash::equal):
* jit/RegisterSet.h:
(): Deleted.
(JSC::RegisterSet::isEmptyValue const): Deleted.
(JSC::RegisterSet::isDeletedValue const): Deleted.
(JSC::RegisterSetHash::hash): Deleted.
(JSC::RegisterSetHash::equal): Deleted.
2021-06-16 Tadeu Zagallo <tzagallo@apple.com>
AssemblyHelpers should save/restore callee save FPRs
https://bugs.webkit.org/show_bug.cgi?id=227052
<rdar://77080162>
Reviewed by Mark Lam.
We have 3 functions in AssemblyHelpers to save and restore callee save registers that were filtering
out any FPRs. This is an issue since we do have callee save FPRs in arm64 and these functions can be
called from the FTL, and FTL uses those callee saves. The test case shows how that's an issue with tail
calls on FTL: the callee saves are correctly stored in the prologue and restored in the epilogue, but
when emitting a tail call we use AssemblyHelpers::emitRestoreCalleeSaves to restore the callee saves,
which doesn't restore FPRs. This results in the callee save FPRs being trashed. To fix this we just need
to stop filtering out the FPRs, if they are listed as used by the code block they should be saved/restored
accordingly. I also changed DFGOSREntry to stop filtering out the callee save FPRs and instead assert
there aren't any, since they aren't currently used in the DFG, but it could help avoid the same issue in
the future.
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareOSREntry):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitSaveCalleeSavesFor):
(JSC::AssemblyHelpers::emitSaveOrCopyCalleeSavesFor):
(JSC::AssemblyHelpers::emitRestoreCalleeSavesFor):
2021-06-16 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r278846.
https://bugs.webkit.org/show_bug.cgi?id=227060
Speculative revert based on failure history of Speedometer2
Reverted changeset:
"Add Air opcode sub32/64(Reg, Imm, Reg) form for ARM64 and
select this instruction in Air"
https://bugs.webkit.org/show_bug.cgi?id=226937
https://trac.webkit.org/changeset/278846
2021-06-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Optimize JSON.parse with small content by dropping single character Identifier pool
https://bugs.webkit.org/show_bug.cgi?id=227057
Reviewed by Sam Weinig.
Profiler results and investigation suggest interesting things.
1. Sampling profiler says Flight-TodoMVC is mostly JSON.parse benchmark.
2. Each JSON data of Flight-TodoMVC is small. And JSON.parse is super frequently called.
3. In the case of JSON.parse with small data, LiteralParser's construction / destruction costs much since
it has large Identifier pool with std::array<>.
As a simple first step, this patch removes single character Identifier pool from LiteralParser since
the exact same Identifier data can be retrieved from VM's SmallStrings.
We created a microbenchmark from Flight-TodoMVC's data, and the result is roughly 20% better.
And we observed 0.6% improvement in Speedometer2.
ToT Patched
flight-todomvc-json 81.0552+-0.8403 ^ 67.5756+-0.6221 ^ definitely 1.1995x faster
----------------------------------------------------------------------------------------------------------------------------------
| subtest | ms | ms | b / a | pValue (significance using False Discovery Rate) |
----------------------------------------------------------------------------------------------------------------------------------
| Elm-TodoMVC |128.991667 |128.450000 |0.995801 | 0.278228 |
| VueJS-TodoMVC |28.487500 |27.925000 |0.980254 | 0.139315 |
| EmberJS-TodoMVC |133.950000 |134.175000 |1.001680 | 0.685021 |
| BackboneJS-TodoMVC |51.670833 |51.537500 |0.997420 | 0.628993 |
| Preact-TodoMVC |21.783333 |21.754167 |0.998661 | 0.944237 |
| AngularJS-TodoMVC |143.820833 |143.770833 |0.999652 | 0.933953 |
| Vanilla-ES2015-TodoMVC |71.608333 |71.416667 |0.997323 | 0.500591 |
| Inferno-TodoMVC |69.179167 |69.525000 |1.004999 | 0.412406 |
| Flight-TodoMVC |81.354167 |79.020833 |0.971319 | 0.000053 (significant) |
| Angular2-TypeScript-TodoMVC |42.654167 |41.887500 |0.982026 | 0.086053 |
| VanillaJS-TodoMVC |57.054167 |56.633333 |0.992624 | 0.176804 |
| jQuery-TodoMVC |274.595833 |275.670833 |1.003915 | 0.148812 |
| EmberJS-Debug-TodoMVC |358.387500 |357.595833 |0.997791 | 0.323387 |
| React-TodoMVC |93.804167 |93.329167 |0.994936 | 0.113410 |
| React-Redux-TodoMVC |157.954167 |157.266667 |0.995647 | 0.131298 |
| Vanilla-ES2015-Babel-Webpack-TodoMVC |68.687500 |68.054167 |0.990779 | 0.002155 (significant) |
----------------------------------------------------------------------------------------------------------------------------------
a mean = 235.28964
b mean = 236.72163
pValue = 0.0121265559
(Bigger means are better.)
1.006 times better
Results ARE significant
* runtime/Identifier.h:
(JSC::Identifier::canUseSingleCharacterString):
* runtime/LiteralParser.cpp:
(JSC::LiteralParser<CharType>::makeIdentifier):
* runtime/LiteralParser.h:
* runtime/SmallStrings.cpp:
(JSC::SmallStrings::singleCharacterStringRep):
* runtime/SmallStrings.h:
2021-06-15 Keith Miller <keith_miller@apple.com>
Shouldn't drain the micro task queue when calling out to ObjC
https://bugs.webkit.org/show_bug.cgi?id=161942
Unreviewed, relanding r278734.
* API/tests/testapi.cpp:
(TestAPI::promiseDrainDoesNotEatExceptions):
(testCAPIViaCpp):
* API/tests/testapi.mm:
(testMicrotaskWithFunction):
(testObjectiveCAPI):
* runtime/JSLock.cpp:
(JSC::JSLock::willReleaseLock):
* runtime/ObjectPrototype.cpp:
(JSC::isPokerBros):
* runtime/VM.cpp:
(JSC::VM::didExhaustMicrotaskQueue):
2021-06-15 Michael Catanzaro <mcatanzaro@gnome.org>
-Warray-bounds warning in Packed.h
https://bugs.webkit.org/show_bug.cgi?id=226557
<rdar://problem/79103658>
Reviewed by Darin Adler.
* b3/air/AirAllocateRegistersByGraphColoring.cpp:
* jit/JITCall.cpp:
(JSC::JIT::compileOpCall):
2021-06-15 Mark Lam <mark.lam@apple.com>
Move setting of scratch buffer active lengths to the runtime functions.
https://bugs.webkit.org/show_bug.cgi?id=227013
rdar://79325068
Reviewed by Keith Miller.
We previously emit JIT'ed code to set and unset the ScratchBuffer active length
around calls into C++ runtime functions. This was needed because the runtime
functions may allow GC to run, and GC needs to be able to scan the values stored
in the ScratchBuffer.
In this patch, we change it so that the runtime functions that need it will
declare an ActiveScratchBufferScope RAII object that will set the ScratchBuffer
active length, and unset it on exit. This allows us to:
1. Emit less JIT code. The runtime function can take care of it.
2. Elide setting the ScratchBuffer active length if not needed. The runtime
functions know whether they can GC or not. They only need to set the active
length if they can GC.
Note that scanning of the active ScratchBuffer is done synchronously on the
mutator thread via Heap::gatherScratchBufferRoots(), which is called as part of
the GC conservative root scan. This means there is no urgency / sequencing that
requires that the active length be set before calling into the runtime function.
Setting it in the runtime function itself is fine as long as it is done before
the function executes any operations that can GC.
This patch also made the following changes:
1. Introduce ActiveScratchBufferScope RAII object used to set/unset the
ScratchBuffer length in the runtime functions. ActiveScratchBufferScope takes
the active length in units of number of stack slots / Registers / JSValues
instead of bytes.
2. Deleted ScratchRegisterAllocator::preserveUsedRegistersToScratchBufferForCall()
and ScratchRegisterAllocator::restoreUsedRegistersFromScratchBufferForCall().
These functions are unused.
The reasoning behind what values to pass to ActiveScratchBufferScope, is any:
1. AssemblyHelpers::debugCall() in AssemblyHelpers.cpp:
The ScratchBuffer is only used for operationDebugPrintSpeculationFailure(),
which now declares an ActiveScratchBufferScope.
The active length is GPRInfo::numberOfRegisters + FPRInfo::numberOfRegisters.
See scratchSize in AssemblyHelpers::debugCall().
2. genericGenerationThunkGenerator() in FTLThunks.cpp:
The scratch buffer size for determining the active length is
requiredScratchMemorySizeInBytes().
However, genericGenerationThunkGenerator() generates code to call either
operationCompileFTLOSRExit() or operationCompileFTLLazySlowPath(). Both of
these functions will DeferGCForAWhile. Hence, GC cannot run, and we don't need
to set the active length here.
3. compileArrayPush() in FTLLowerDFGToB3.cpp:
Cases Array::Int32, Array::Contiguous, or Array::Double calls
operationArrayPushMultiple() or operationArrayPushDoubleMultiple().
For operationArrayPushMultiple(), the active length is elementCount. See
computation of scratchSize.
For operationArrayPushDoubleMultiple(), we don't need to set the active length
because the ScratchBuffer only contains double values. The GC does not need
to scan those.
Case Array::ArrayStorage calls operationArrayPushMultiple().
The active length is elementCount. See computation of scratchSize.
compileNewArray() in FTLLowerDFGToB3.cpp:
Calls operationNewArray(). Active length is m_node->numChildren(), which is
passed to operationNewArray() as the size parameter. See computation of
scratchSize.
compileNewArrayWithSpread() in FTLLowerDFGToB3.cpp:
Calls operationNewArrayWithSpreadSlow(). Active length is m_node->numChildren(),
which is passes to operationNewArrayWithSpreadSlow() as the numItems parameter.
See computation of scratchSize.
4. osrExitGenerationThunkGenerator() in DFGThunks.cpp:
Calls operationCompileOSRExit(). Active length is GPRInfo::numberOfRegisters +
FPRInfo::numberOfRegisters. See computation of scratchSize.
5. compileNewArray() in DFGSpeculativeJIT.cpp:
Calls operationNewArray(). Active length is node->numChildren(), which is
passed in as the size parameter.
compileNewArrayWithSpread() in DFGSpeculativeJIT.cpp:
Calls operationNewArrayWithSpreadSlow(). Active length is node->numChildren(),
which is passed in as the numItems parameter.
compileArrayPush() in DFGSpeculativeJIT.cpp:
Calls operationArrayPushMultiple(). Active length is elementCount, which is
passed in as the elementCount parameter.
Calls operationArrayPushDoubleMultiple(). Active length is elementCount, but
we don't need to set it because the ScratchBuffer only contains double values.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewArray):
(JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread):
(JSC::DFG::SpeculativeJIT::compileArrayPush):
* dfg/DFGThunks.cpp:
(JSC::DFG::osrExitGenerationThunkGenerator):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileArrayPush):
(JSC::FTL::DFG::LowerDFGToB3::compileNewArray):
(JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::JSC_DEFINE_JIT_OPERATION):
* ftl/FTLOperations.cpp:
(JSC::FTL::JSC_DEFINE_JIT_OPERATION):
* ftl/FTLThunks.cpp:
(JSC::FTL::genericGenerationThunkGenerator):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::debugCall):
* jit/ScratchRegisterAllocator.cpp:
(JSC::ScratchRegisterAllocator::preserveUsedRegistersToScratchBufferForCall): Deleted.
(JSC::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBufferForCall): Deleted.
* jit/ScratchRegisterAllocator.h:
* runtime/VM.h:
* runtime/VMInlines.h:
(JSC::ActiveScratchBufferScope::ActiveScratchBufferScope):
(JSC::ActiveScratchBufferScope::~ActiveScratchBufferScope):
2021-06-14 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Workaround ICU uloc_addLikelySubtags / uloc_minimizeSubtags bugs
https://bugs.webkit.org/show_bug.cgi?id=226996
rdar://79250513
Reviewed by Ross Kirsling.
ICU has bugs that uloc_addLikelySubtags / uloc_minimizeSubtags cannot handle very long locale ID that exceeds ULOC_FULLNAME_CAPACITY,
while these functions can take arbitrary sized buffer for output. This can be achieved simply by (1) attaching many unicode extensions,
or (2) having many variants.
In this patch, we add a workaround: if uloc_addLikelySubtags / uloc_minimizeSubtags failed, we perform them without having locale ID
keywords part. After performing the operations, we append these keywords back.
This is workaround, and still this workaround is not complete since we could have many variants. In that case, uloc_addLikelySubtags / uloc_minimizeSubtags
still fails, and in that case, for now, we give up performing uloc_addLikelySubtags / uloc_minimizeSubtags. Fixing this needs to be
done in ICU side: https://unicode-org.atlassian.net/browse/ICU-21639
* runtime/IntlLocale.cpp:
(JSC::IntlLocale::keywordValue const):
(JSC::IntlLocale::maximal):
(JSC::IntlLocale::minimal):
(JSC::IntlLocale::baseName):
2021-06-14 Mark Lam <mark.lam@apple.com>
Add ldp and stp support for FP registers, plus some bug fixes.
https://bugs.webkit.org/show_bug.cgi?id=226998
rdar://79313717
Reviewed by Robin Morisset.
This patch does the following:
1. Add ldp and stp support for FP registers.
This simply entails providing wrappers that take FPRegisterID and passing true
for the V bit to the underlying loadStoreRegisterPairXXX encoding function.
V is for vector (aka floating point). This will cause bit 26 in the instruction
to be set indicating that it's loading / storing floating point registers.
2. Add ARM64 disassembler support ldp and stp for FP registers.
This includes fixing A64DOpcodeLoadStoreRegisterPair::mask to not exclude the
FP versions of the instructions.
3. Add ARM64Assembler query methods for determining if an immediate is encodable
as the signed 12 bit immediate of ldp and stp instructions.
4. Fix ldp and stp offset form to take an int instead of an unsigned. The
immediate it takes is a 12-bit signed int, not unsigned.
5. In loadStoreRegisterPairXXX encoding functions used by the forms of ldp and stp,
RELEASE_ASSERT that the passed in immediate is encodable. Unlike ldur / stur,
there is no form of ldp / stp that takes the offset in a register that can be
used as a fail over. Hence, if the immediate is not encodable, this is a
non-recoverable event. The client is responsible for ensuring that the offset
is encodable.
6. Added some testmasm tests for testing the offset form (as opposed to PreIndex
and PostIndex forms) of ldp and stp. We currently only use the offset form
in our JITs.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::isValidLDPImm):
(JSC::ARM64Assembler::isValidLDPFPImm):
(JSC::ARM64Assembler::ldp):
(JSC::ARM64Assembler::ldnp):
(JSC::ARM64Assembler::isValidSTPImm):
(JSC::ARM64Assembler::isValidSTPFPImm):
(JSC::ARM64Assembler::stp):
(JSC::ARM64Assembler::stnp):
(JSC::ARM64Assembler::loadStoreRegisterPairPostIndex):
(JSC::ARM64Assembler::loadStoreRegisterPairPreIndex):
(JSC::ARM64Assembler::loadStoreRegisterPairOffset):
(JSC::ARM64Assembler::loadStoreRegisterPairNonTemporal):
* assembler/AssemblerCommon.h:
(JSC::isValidSignedImm7):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::loadPair64):
(JSC::MacroAssemblerARM64::storePair64):
* assembler/testmasm.cpp:
(JSC::testLoadStorePair64Int64):
(JSC::testLoadStorePair64Double):
* disassembler/ARM64/A64DOpcode.cpp:
(JSC::ARM64Disassembler::A64DOpcodeLoadStoreRegisterPair::format):
* disassembler/ARM64/A64DOpcode.h:
2021-06-14 Yijia Huang <yijia_huang@apple.com>
Add Air opcode sub32/64(Reg, Imm, Reg) form for ARM64 and select this instruction in Air
https://bugs.webkit.org/show_bug.cgi?id=226937
Reviewed by Saam Barati.
Previously, Air arm64 sub32/64 utilize sub(Imm, Tmp) at optlevel = 0 and
add(Tmp, -Imm) at optlevel > 0 to perform and optimize sub(Tmp, Imm, Tmp).
The issue with this is that we were not eliding redundant operations.
For example:
// B3 IR
@0 = Trunc(ArgumentReg(0))
@1 = Const
@2 = Sub(@0, @1)
@3 = Return(@2)
// Old optimized Air IR
// OptLevel = 0
Move %x0, %tmp1, @0
Move $Const, %tmp2, @1
Move %tmp1, %tmp0, @2 // Redundant
Sub $Const, %tmp0, @2
Move %tmp0, %x0, @3
Ret32 %x0, @3
To remove those redundant instructions, Air arm64 sub32/64 opcode should
indicate a new form sub(Tmp, Imm, Tmp).
// New optimized Air IR
// OptLevel = 0
Move %x0, %tmp1, @0
Move $Const, %tmp2, @1
Sub %tmp1, $Const, %tmp0, @2
Move %tmp0, %x0, @3
Ret32 %x0, @3
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::sub32):
(JSC::MacroAssemblerARM64::sub64):
* assembler/testmasm.cpp:
(JSC::testSub32Args):
(JSC::testSub32Imm):
(JSC::testSub32ArgImm):
(JSC::testSub64Imm32):
(JSC::testSub64ArgImm32):
(JSC::testSub64Imm64):
(JSC::testSub64ArgImm64):
* b3/B3ReduceStrength.cpp:
* b3/air/AirOpcode.opcodes:
* b3/testb3.h:
* b3/testb3_2.cpp:
(testSubArgs32ZeroExtend):
* b3/testb3_3.cpp:
(addArgTests):
2021-06-14 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r278734.
https://bugs.webkit.org/show_bug.cgi?id=226973
broke jsc testapi
Reverted changeset:
"Shouldn't drain the micro task queue when calling out to
ObjC"
https://bugs.webkit.org/show_bug.cgi?id=161942
https://trac.webkit.org/changeset/278734
2021-06-13 Saam Barati <sbarati@apple.com>
https://bugs.webkit.org/show_bug.cgi?id=226576
<rdar://problem/78810362>
Reviewed by Yusuke Suzuki.
ShortCircuitReadModifyResolveNode can't emit a value into
its result until after it emits a TDZ check. We were temporarily
storing the result of the get_from_scope into the dst. Then
we'd emit the TDZ check. The TDZ check can throw, and it could
lead to us returning TDZ from the eval itself. Instead, we need
to use a temporary to emit a TDZ check on. Only after the TDZ check
passes can we move the temporary into the result.
* bytecompiler/NodesCodegen.cpp:
(JSC::ShortCircuitReadModifyResolveNode::emitBytecode):
2021-06-12 Michael Catanzaro <mcatanzaro@gnome.org>
-Wnonnull warning in JITCall.cpp
https://bugs.webkit.org/show_bug.cgi?id=226643
<rdar://problem/79197261>
Reviewed by Darin Adler.
This is a false-positive, so suppress it using
IGNORE_ERRONEOUS_GCC_NULL_CHECK_WARNINGS_BEGIN.
* jit/JITCall.cpp:
(JSC::JIT::compileOpCall):
2021-06-12 Robin Morisset <rmorisset@apple.com>
We should drop B3 values while running Air
https://bugs.webkit.org/show_bug.cgi?id=226187
Reviewed by Saam Barati.
NB: this patch first landed as r278371, then was reverted in r278587 as it broke --dumpDisassembly().
I fixed the bug (a missing line setDisassembler()) and am now re-landing it. Below is a copy of the original Changelog.
We must keep the following values:
- WasmBoundsCheck, to know whether it is Pinned or Maximum, and if it is pinned find its argument.
- CCall/Patch/Check/CheckAdd/CheckSub/CheckMul and all of their children, because all of these are lowered to Air::Patchpoint, which needs to know the type of its arguments, and does so by looking at the children of its origin.
I intend to fix these in later patches if possible.
Finally we must preserve all B3 values in the following cases:
- if we dump the disassembly or the Air graph: because otherwise we cannot print the origins
- if we are using the sampling profiler, because it relies on PCToCodeOriginMap which we cannot accurately fill without these origins.
We must also keep m_tuples alive, as it is used by Patchpoints in Air to understand the types of their arguments.
We also don't touch StackSlots (in this patch), because one of them is captured by FTL::State.
Also now PCToOriginMap has a Vector with no inline capacity, since it is either quite large (if needed) or empty (otherwise).
The performance impact of this is a progression on various RAMification subtests on Mac, but is more mitigated on iPhone7, with various regressions.
I suspect these to be noise, and will monitor the performance bots post-landing to make sure of it.
* b3/B3LowerToAir.cpp:
(JSC::B3::lowerToAir):
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::freeUnneededB3ValuesAfterLowering):
* b3/B3Procedure.h:
(JSC::B3::Procedure::releasePCToOriginMap):
(JSC::B3::Procedure::setNeedsPCToOriginMap):
(JSC::B3::Procedure::needsPCToOriginMap):
* b3/B3SparseCollection.h:
(JSC::B3::SparseCollection::clearAll):
(JSC::B3::SparseCollection::filterAndTransfer):
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::Code):
* b3/air/AirCode.h:
(JSC::B3::Air::Code::shouldPreserveB3Origins const):
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::generateWithAlreadyAllocatedRegisters):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLState.cpp:
(JSC::FTL::State::State):
2021-06-11 Patrick Angle <pangle@apple.com>
Web Inspector: Add instrumentation to node destruction for InspectorDOMAgent
https://bugs.webkit.org/show_bug.cgi?id=226624
Reviewed by Devin Rousso.
Add new `DOM.willDestroyDOMNode` event to inform the frontend of DOM nodes that no longer exist, even if they
weren't in the DOM tree. This work serves as a prelude to <https://webkit.org/b/189687> (Web Inspector: preserve
DOM.NodeId if a node is removed and re-added) to eventually only forget about nodes upon destruction, instead of
removal from the DOM tree.
* inspector/protocol/DOM.json:
2021-06-11 Yijia Huang <yijia_huang@apple.com>
Air ARM64 sub32 opcode should indicate that it zero-extends its result
https://bugs.webkit.org/show_bug.cgi?id=226849
Reviewed by Saam Barati.
Sub32 was previously not saying that its result is zero defined. However,
sub32 on arm64 architectures zero defines its result, so the top 32 bits
are zeroed. The issue with this is what we were not eliding provably
redundant zero extend operations.
For example:
// B3 IR
@0 = Trunc(ArgumentReg(0))
@1 = Trunc(ArgumentReg(1))
@2 = Sub(@0, @1)
@3 = ZExt32(@2) // i64
@4 = Return(@3) or Store(@3, @x)
// Old optimized Air IR
Sub32 %x0, %x1, %x0, b@2
Move32 %x0, %x0, b@3
Ret64 %x0, b@4 or Move %x0, (%x), b@4
To remove that redundant zero extend instruction (Move32), Air arm64
sub32 opcode should indicate that it zero-extends its result.
// New optimized Air IR
Sub32 %x0, %x1, %x0, b@2
Ret64 %x0, b@6 or Move %x0, (%x), b@4
* b3/air/AirOpcode.opcodes:
2021-06-10 Keith Miller <keith_miller@apple.com>
Shouldn't drain the micro task queue when calling out to ObjC
https://bugs.webkit.org/show_bug.cgi?id=161942
Reviewed by Saam Barati.
It looks like the issue is that we aren't checking for the
presence of dropped locks when deciding to drain microtasks during
JSLock::unlock. This meant that when we drop all locks when
calling out to API clients we would drain our microtasks at that
point. An alternative would be to pass an extra parameter to the
unlock function that says not to drain microtasks. I chose not to
do that since it seemed a bit less robust.
This patch is very likely to break existing API users. So I'm adding
a linked on or after check to protect existing Apps.
Lastly, change our Poker Bros check to use applicationSDKVersion too
so others trying to add a linked on or after check don't use
the dyld function directly too.
* API/tests/testapi.cpp:
(TestAPI::promiseDrainDoesNotEatExceptions):
(testCAPIViaCpp):
* API/tests/testapi.mm:
(testMicrotaskWithFunction):
(testObjectiveCAPI):
* runtime/JSLock.cpp:
(JSC::JSLock::willReleaseLock):
* runtime/ObjectPrototype.cpp:
(JSC::isPokerBros):
* runtime/VM.cpp:
(JSC::VM::didExhaustMicrotaskQueue):
2021-06-10 Mark Lam <mark.lam@apple.com>
Another speculative build fix for Win32.
https://bugs.webkit.org/show_bug.cgi?id=226880
rdar://79124858
Reviewed by Keith Miller.
We're getting reports of "warning C4206: nonstandard extension used: translation
unit is empty" turning into a build error on Win32 ports. By design, we rely on
#define flags to make some translation units empty. Hence, we don't want this
warning to turn into an error.
* config.h:
2021-06-10 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Remove useDataICInOptimizingJIT option
https://bugs.webkit.org/show_bug.cgi?id=226862
Reviewed by Mark Lam.
Originally this option is added to fix performance problem when using DataIC in DFG / FTL.
But it turned out that that performance regression was caused due to disablement of InlineAccess when
using DataIC. With the configuration using DataIC and InlineAccess, we do not observe performance regression.
So, let's just drop this option.
* jit/JITCode.h:
(JSC::JITCode::useDataIC):
* runtime/Options.cpp:
(JSC::Options::recomputeDependentOptions):
* runtime/OptionsList.h:
2021-06-10 Adrian Perez de Castro <aperez@igalia.com>
Non-unified build fixes, early May 2021 edition
https://bugs.webkit.org/show_bug.cgi?id=226763
Unreviewed non-unified build fixes.
* bytecode/InlineAccess.h: Add missing forward declaration for the CodeBlock type.
* jit/JITInlineCacheGenerator.cpp: Add missing CCallHelpers.h header.
* runtime/Intrinsic.h: Add missing <optional> header.
* yarr/YarrUnicodeProperties.h: Ditto.
2021-06-10 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Ignore Intl.NumberFormat feature options when linked-ICU is old
https://bugs.webkit.org/show_bug.cgi?id=226861
rdar://77393100
Reviewed by Ross Kirsling.
Let's just ignore the option when Intl.NumberFormat features cannot be implemented since the linked ICU is old.
There is no way not to expose these features since Intl.NumberFormat's these changes are additional ones and Intl.NumberFormat existed before.
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::initializeNumberFormat):
2021-06-09 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Rename *ByIdVariant to *ByVariant and *ByKind::Normal to *ByKind::ById
https://bugs.webkit.org/show_bug.cgi?id=226750
Reviewed by Yusuke Suzuki.
Cleanup patch following r278445.
1. {Get, Delete, In}ByStatus (but not `Put`) have had `Id` removed from their names; likewise, remove `Id`
from the names of {Get, Delete, In}ByIdVariant. These are used *before* ByVal has been converted to ById.
2. The {Get, Del, In}ByKind enum classes shouldn't really call ById `Normal` -- let's say `ById` explicitly.
3. Bonus: In DFGBytecodeParser, move some *Status::computeFor calls inside the conditional that uses them.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/DeleteByStatus.cpp:
(JSC::DeleteByStatus::appendVariant):
(JSC::DeleteByStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::DeleteByStatus::visitAggregateImpl):
(JSC::DeleteByStatus::markIfCheap):
* bytecode/DeleteByStatus.h:
* bytecode/DeleteByVariant.cpp: Renamed from Source/JavaScriptCore/bytecode/DeleteByIdVariant.cpp.
(JSC::DeleteByVariant::DeleteByVariant):
(JSC::DeleteByVariant::~DeleteByVariant):
(JSC::DeleteByVariant::operator=):
(JSC::DeleteByVariant::attemptToMerge):
(JSC::DeleteByVariant::writesStructures const):
(JSC::DeleteByVariant::visitAggregateImpl):
(JSC::DeleteByVariant::markIfCheap):
(JSC::DeleteByVariant::dump const):
(JSC::DeleteByVariant::finalize):
(JSC::DeleteByVariant::dumpInContext const):
* bytecode/DeleteByVariant.h: Renamed from Source/JavaScriptCore/bytecode/DeleteByIdVariant.h.
(JSC::DeleteByVariant::overlaps):
* bytecode/GetByStatus.cpp:
(JSC::GetByStatus::appendVariant):
(JSC::GetByStatus::computeFromLLInt):
(JSC::GetByStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::GetByStatus::computeFor):
(JSC::GetByStatus::merge):
(JSC::GetByStatus::visitAggregateImpl):
(JSC::GetByStatus::markIfCheap):
(JSC::GetByStatus::finalize):
* bytecode/GetByStatus.h:
* bytecode/GetByVariant.cpp: Renamed from Source/JavaScriptCore/bytecode/GetByIdVariant.cpp.
(JSC::GetByVariant::GetByVariant):
(JSC::GetByVariant::~GetByVariant):
(JSC::GetByVariant::operator=):
(JSC::GetByVariant::canMergeIntrinsicStructures const):
(JSC::GetByVariant::attemptToMerge):
(JSC::GetByVariant::visitAggregateImpl):
(JSC::GetByVariant::markIfCheap):
(JSC::GetByVariant::finalize):
(JSC::GetByVariant::dump const):
(JSC::GetByVariant::dumpInContext const):
* bytecode/GetByVariant.h: Renamed from Source/JavaScriptCore/bytecode/GetByIdVariant.h.
(JSC::GetByVariant::overlaps):
* bytecode/InByStatus.cpp:
(JSC::InByStatus::appendVariant):
(JSC::InByStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::InByStatus::merge):
(JSC::InByStatus::markIfCheap):
(JSC::InByStatus::finalize):
* bytecode/InByStatus.h:
* bytecode/InByVariant.cpp: Renamed from Source/JavaScriptCore/bytecode/InByIdVariant.cpp.
(JSC::InByVariant::InByVariant):
(JSC::InByVariant::attemptToMerge):
(JSC::InByVariant::markIfCheap):
(JSC::InByVariant::finalize):
(JSC::InByVariant::dump const):
(JSC::InByVariant::dumpInContext const):
* bytecode/InByVariant.h: Renamed from Source/JavaScriptCore/bytecode/InByIdVariant.h.
(JSC::InByVariant::overlaps):
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::reset):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
(JSC::DFG::ByteCodeParser::handleDOMJITGetter):
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::handleGetPrivateNameById):
(JSC::DFG::ByteCodeParser::handleDeleteById):
(JSC::DFG::ByteCodeParser::handleInById):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
(JSC::DFG::ConstantFoldingPhase::emitGetByOffset):
(JSC::DFG::ConstantFoldingPhase::emitDeleteByOffset):
* dfg/DFGNode.h:
* dfg/DFGValidate.cpp:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileDelBy):
(JSC::FTL::DFG::LowerDFGToB3::compileDeleteById):
(JSC::FTL::DFG::LowerDFGToB3::compileDeleteByVal):
(JSC::FTL::DFG::LowerDFGToB3::compileMultiDeleteByOffset):
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
* jit/JITOperations.cpp:
(JSC::JSC_DEFINE_JIT_OPERATION):
* jit/Repatch.cpp:
(JSC::appropriateOptimizingGetByFunction):
(JSC::appropriateGetByFunction):
(JSC::tryCacheGetBy):
(JSC::repatchDeleteBy):
(JSC::tryCacheInBy):
(JSC::repatchInBy):
(JSC::resetGetBy):
(JSC::resetDelBy):
(JSC::resetInBy):
* jit/Repatch.h:
2021-06-09 Fujii Hironori <Hironori.Fujii@sony.com>
clang-cl: JIT.h(966,67): error: no viable conversion from 'JSC::AbstractMacroAssembler<JSC::X86Assembler>::Address' to 'FunctionPtr<CFunctionPtrTag>'
https://bugs.webkit.org/show_bug.cgi?id=226850
Reviewed by Yusuke Suzuki.
WinCairo clang-cl builds got broken since r278656 (Bug 226072).
* jit/JIT.h: Use the common callOperation(Address, Args...) for
x64 Windows. Added static_assert to check the return type.
2021-06-09 Mark Lam <mark.lam@apple.com>
Speculative build fix for Win32.
https://bugs.webkit.org/show_bug.cgi?id=226793
rdar://79032803
Reviewed by Saam Barati.
* API/JSCallbackObject.h:
2021-06-09 Xan Lopez <xan@igalia.com>
[JSC] Fix incorrect register reuse in 32bit after r278568
https://bugs.webkit.org/show_bug.cgi?id=226817
Reviewed by Caio Araujo Neponoceno de Lima.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNotDoubleNeitherDoubleNorHeapBigIntNorStringStrictEquality):
The JSVALUE32_64 branch potentially needs both the tag and payload
registers for both left/right nodes, so we cannot reuse any of
them for the result since the first thing the code does is set it
zero. Just remove the Reuse construction.
2021-06-09 Mikhail R. Gadelha <mikhail@igalia.com>
Fix inadvertent tag corruption in functionAddressOf
https://bugs.webkit.org/show_bug.cgi?id=226503
Reviewed by Darin Adler.
Original patch by Angelos Oikonomopoulos.
The cast was sign-extending the JSValue address in 32 bits, so that addresses
that had the most significant set gave us a sign-extended result in
asNumber which was then converted to an invalid NaN by the bitcast.
Instead, cast the address to uintptr_t, and the result will be promoted
uint64_t without sign-extending the address.
* jsc.cpp:
(JSC_DEFINE_HOST_FUNCTION):
2021-06-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use DataIC for AccessCase
https://bugs.webkit.org/show_bug.cgi?id=226072
Reviewed by Saam Barati and Filip Pizlo.
This patch adds non-repatching IC for Baseline JIT in ARM64.
This does not work in non-ARM64 architectures (including X64) due to the use of link-register.
1. We add non-repatching IC, which is enabled only in Baseline due to performance reason. We are using the
existing IC in DFG and FTL. Non-repatching includes fast-path, and slow-path's operation function.
2. We still keep InlineAccess in all tiers. Removing that causes 0.3 ~ 1.0% regression in Speedometer2. This
means that we still need some repatching when we first introduce stubs.
3. We add a mechanism to share generated code stubs in non-repatching IC. Currently, getter / setter / custom
accessors are excluded since their code relies on JSGlobalObject, CodeBlock etc. which are not included in
AccessCase's data structure.
4. This patch still relies on that CodeBlock will be destroyed synchronously since we need to ensure that sharing-hash-table
does not include already-dead JIT code stubs. We can fix it (e.g. annotating epoch to these stubs, bump them in
finalizeUnconditionally), but we avoid doing that to prevent from further enlarging this patch. This patch is already
significant in its size.
5. Added callOperation(Address) support in CCallHelpers, which can save the target in nonArgGPR0, and call it so that we can use
Address including GPR which is also used for arguments.
Performance is neutral in JetStream2 and Speedometer2. But it offers the way to remove some code generation in Baseline.
* assembler/MacroAssemblerARM64E.h:
(JSC::MacroAssemblerARM64E::call):
* bytecode/AccessCase.cpp:
(JSC::AccessCase::create):
(JSC::AccessCase::createTransition):
(JSC::AccessCase::createDelete):
(JSC::AccessCase::createCheckPrivateBrand):
(JSC::AccessCase::createSetPrivateBrand):
(JSC::AccessCase::fromStructureStubInfo):
(JSC::AccessCase::clone const):
(JSC::AccessCase::generateWithGuard):
(JSC::AccessCase::generateImpl):
(JSC::AccessCase::canBeShared):
* bytecode/AccessCase.h:
(JSC::AccessCase::hash const):
(JSC::AccessCase::AccessCase):
(JSC::SharedJITStubSet::Hash::Key::Key):
(JSC::SharedJITStubSet::Hash::Key::isHashTableDeletedValue const):
(JSC::SharedJITStubSet::Hash::Key::operator==):
(JSC::SharedJITStubSet::Hash::hash):
(JSC::SharedJITStubSet::Hash::equal):
(JSC::SharedJITStubSet::Searcher::Translator::hash):
(JSC::SharedJITStubSet::Searcher::Translator::equal):
(JSC::SharedJITStubSet::PointerTranslator::hash):
(JSC::SharedJITStubSet::PointerTranslator::equal):
(JSC::SharedJITStubSet::add):
(JSC::SharedJITStubSet::remove):
(JSC::SharedJITStubSet::find):
* bytecode/ByValInfo.h:
(JSC::ByValInfo::setUp):
(JSC::ByValInfo::offsetOfSlowOperation):
(JSC::ByValInfo::offsetOfNotIndexJumpTarget):
(JSC::ByValInfo::offsetOfBadTypeJumpTarget):
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::initializeDirectCall):
(JSC::CallLinkInfo::setDirectCallTarget):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::useDataIC const):
* bytecode/GetterSetterAccessCase.cpp:
(JSC::GetterSetterAccessCase::create):
(JSC::GetterSetterAccessCase::clone const):
(JSC::GetterSetterAccessCase::emitDOMJITGetter):
* bytecode/GetterSetterAccessCase.h:
* bytecode/InlineAccess.cpp:
(JSC::getScratchRegister):
(JSC::InlineAccess::rewireStubAsJumpInAccessNotUsingInlineAccess):
(JSC::InlineAccess::rewireStubAsJumpInAccess):
(JSC::InlineAccess::resetStubAsJumpInAccess):
(JSC::InlineAccess::resetStubAsJumpInAccessNotUsingInlineAccess):
(JSC::InlineAccess::rewireStubAsJump): Deleted.
* bytecode/InlineAccess.h:
* bytecode/InstanceOfAccessCase.cpp:
(JSC::InstanceOfAccessCase::create):
(JSC::InstanceOfAccessCase::clone const):
* bytecode/InstanceOfAccessCase.h:
* bytecode/IntrinsicGetterAccessCase.cpp:
(JSC::IntrinsicGetterAccessCase::create):
(JSC::IntrinsicGetterAccessCase::clone const):
* bytecode/IntrinsicGetterAccessCase.h:
* bytecode/ModuleNamespaceAccessCase.cpp:
(JSC::ModuleNamespaceAccessCase::create):
(JSC::ModuleNamespaceAccessCase::clone const):
* bytecode/ModuleNamespaceAccessCase.h:
* bytecode/ObjectPropertyConditionSet.h:
(JSC::ObjectPropertyConditionSet::hash const):
(JSC::ObjectPropertyConditionSet::operator==):
(JSC::ObjectPropertyConditionSet::operator!=):
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessGenerationState::installWatchpoint):
(JSC::AccessGenerationState::succeed):
(JSC::AccessGenerationState::preserveLiveRegistersToStackForCallWithoutExceptions):
(JSC::PolymorphicAccess::addCases):
(JSC::PolymorphicAccess::addCase):
(JSC::PolymorphicAccess::visitWeak const):
(JSC::PolymorphicAccess::regenerate):
* bytecode/PolymorphicAccess.h:
(JSC::AccessGenerationState::AccessGenerationState):
(JSC::AccessGenerationState::preserveLiveRegistersToStackForCallWithoutExceptions):
* bytecode/ProxyableAccessCase.cpp:
(JSC::ProxyableAccessCase::create):
(JSC::ProxyableAccessCase::clone const):
* bytecode/ProxyableAccessCase.h:
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::StructureStubInfo):
(JSC::StructureStubInfo::addAccessCase):
(JSC::StructureStubInfo::reset):
* bytecode/StructureStubInfo.h:
(JSC::StructureStubInfo::offsetOfCodePtr):
(JSC::StructureStubInfo::offsetOfSlowPathStartLocation):
(JSC::StructureStubInfo::offsetOfSlowOperation):
(JSC::StructureStubInfo::patchableJump): Deleted.
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::appendCall):
* dfg/DFGSlowPathGenerator.h:
(JSC::DFG::slowPathICCall):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetById):
(JSC::DFG::SpeculativeJIT::compileGetByIdFlush):
(JSC::DFG::SpeculativeJIT::compileDeleteById):
(JSC::DFG::SpeculativeJIT::compileDeleteByVal):
(JSC::DFG::SpeculativeJIT::compileInById):
(JSC::DFG::SpeculativeJIT::compileInByVal):
(JSC::DFG::SpeculativeJIT::compileGetPrivateNameByVal):
(JSC::DFG::SpeculativeJIT::compileGetPrivateNameById):
(JSC::DFG::SpeculativeJIT::compilePutPrivateNameById):
(JSC::DFG::SpeculativeJIT::compileCheckPrivateBrand):
(JSC::DFG::SpeculativeJIT::compileSetPrivateBrand):
(JSC::DFG::SpeculativeJIT::compileInstanceOfForCells):
(JSC::DFG::SpeculativeJIT::compileInstanceOf):
(JSC::DFG::SpeculativeJIT::compilePutByIdFlush):
(JSC::DFG::SpeculativeJIT::compilePutById):
(JSC::DFG::SpeculativeJIT::compilePutByIdDirect):
(JSC::DFG::SpeculativeJIT::cachedPutById):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
(JSC::DFG::SpeculativeJIT::appendCall):
(JSC::DFG::SpeculativeJIT::appendCallSetResult):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetById):
(JSC::DFG::SpeculativeJIT::cachedGetByIdWithThis):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetById):
(JSC::DFG::SpeculativeJIT::cachedGetByIdWithThis):
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::getPrivateName):
(JSC::FTL::DFG::LowerDFGToB3::compilePrivateBrandAccess):
(JSC::FTL::DFG::LowerDFGToB3::cachedPutById):
(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToB3::compileDelBy):
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
* ftl/FTLSlowPathCall.cpp:
(JSC::FTL::SlowPathCallContext::SlowPathCallContext):
(JSC::FTL::SlowPathCallContext::keyWithTarget const):
(JSC::FTL::SlowPathCallContext::makeCall):
* ftl/FTLSlowPathCall.h:
(JSC::FTL::callOperation):
* ftl/FTLSlowPathCallKey.cpp:
(JSC::FTL::SlowPathCallKey::dump const):
* ftl/FTLSlowPathCallKey.h:
(JSC::FTL::SlowPathCallKey::SlowPathCallKey):
(JSC::FTL::SlowPathCallKey::indirectOffset const):
(JSC::FTL::SlowPathCallKey::withCallTarget):
(JSC::FTL::SlowPathCallKey::operator== const):
(JSC::FTL::SlowPathCallKey::hash const):
* ftl/FTLThunks.cpp:
(JSC::FTL::genericGenerationThunkGenerator):
(JSC::FTL::slowPathCallThunkGenerator):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitVirtualCall):
* jit/CCallHelpers.cpp:
(JSC::CCallHelpers::emitJITCodeOver):
* jit/CCallHelpers.h:
(JSC::CCallHelpers::ArgCollection::ArgCollection):
(JSC::CCallHelpers::ArgCollection::pushRegArg):
(JSC::CCallHelpers::ArgCollection::pushExtraRegArg):
(JSC::CCallHelpers::ArgCollection::pushNonArg):
(JSC::CCallHelpers::ArgCollection::addGPRArg):
(JSC::CCallHelpers::ArgCollection::addGPRExtraArg):
(JSC::CCallHelpers::ArgCollection::addStackArg):
(JSC::CCallHelpers::ArgCollection::addPoke):
(JSC::CCallHelpers::calculatePokeOffset):
(JSC::CCallHelpers::pokeForArgument):
(JSC::CCallHelpers::stackAligned):
(JSC::CCallHelpers::marshallArgumentRegister):
(JSC::CCallHelpers::setupArgumentsImpl):
(JSC::CCallHelpers::pokeArgumentsAligned):
(JSC::CCallHelpers::std::is_integral<CURRENT_ARGUMENT_TYPE>::value):
(JSC::CCallHelpers::std::is_pointer<CURRENT_ARGUMENT_TYPE>::value):
(JSC::CCallHelpers::setupArgumentsEntryImpl):
(JSC::CCallHelpers::setupArguments):
(JSC::CCallHelpers::setupArgumentsForIndirectCall):
* jit/GCAwareJITStubRoutine.cpp:
(JSC::GCAwareJITStubRoutine::GCAwareJITStubRoutine):
(JSC::GCAwareJITStubRoutine::makeGCAware):
(JSC::GCAwareJITStubRoutine::observeZeroRefCount):
(JSC::PolymorphicAccessJITStubRoutine::PolymorphicAccessJITStubRoutine):
(JSC::PolymorphicAccessJITStubRoutine::observeZeroRefCount):
(JSC::PolymorphicAccessJITStubRoutine::computeHash):
(JSC::MarkingGCAwareJITStubRoutine::MarkingGCAwareJITStubRoutine):
(JSC::GCAwareJITStubRoutineWithExceptionHandler::GCAwareJITStubRoutineWithExceptionHandler):
(JSC::createICJITStubRoutine):
(JSC::createJITStubRoutine): Deleted.
* jit/GCAwareJITStubRoutine.h:
(JSC::GCAwareJITStubRoutine::create):
(JSC::PolymorphicAccessJITStubRoutine::cases const):
(JSC::PolymorphicAccessJITStubRoutine::weakStructures const):
(JSC::PolymorphicAccessJITStubRoutine::hash const):
* jit/GPRInfo.h:
* jit/JIT.cpp:
(JSC::JIT::link):
* jit/JIT.h:
* jit/JITCall.cpp:
(JSC::JIT::emit_op_iterator_open):
(JSC::JIT::emitSlow_op_iterator_open):
(JSC::JIT::emit_op_iterator_next):
(JSC::JIT::emitSlow_op_iterator_next):
* jit/JITCall32_64.cpp:
(JSC::JIT::emit_op_iterator_open):
(JSC::JIT::emit_op_iterator_next):
* jit/JITCode.h:
(JSC::JITCode::useDataIC):
* jit/JITInlineCacheGenerator.cpp:
(JSC::JITInlineCacheGenerator::JITInlineCacheGenerator):
(JSC::JITInlineCacheGenerator::finalize):
(JSC::JITByIdGenerator::JITByIdGenerator):
(JSC::JITByIdGenerator::finalize):
(JSC::JITByIdGenerator::generateFastCommon):
(JSC::JITGetByIdGenerator::JITGetByIdGenerator):
(JSC::JITGetByIdWithThisGenerator::JITGetByIdWithThisGenerator):
(JSC::JITPutByIdGenerator::JITPutByIdGenerator):
(JSC::JITDelByValGenerator::JITDelByValGenerator):
(JSC::JITDelByValGenerator::generateFastPath):
(JSC::JITDelByValGenerator::finalize):
(JSC::JITDelByIdGenerator::JITDelByIdGenerator):
(JSC::JITDelByIdGenerator::generateFastPath):
(JSC::JITDelByIdGenerator::finalize):
(JSC::JITInByValGenerator::JITInByValGenerator):
(JSC::JITInByValGenerator::generateFastPath):
(JSC::JITInByValGenerator::finalize):
(JSC::JITInByIdGenerator::JITInByIdGenerator):
(JSC::JITInstanceOfGenerator::JITInstanceOfGenerator):
(JSC::JITInstanceOfGenerator::generateFastPath):
(JSC::JITInstanceOfGenerator::finalize):
(JSC::JITGetByValGenerator::JITGetByValGenerator):
(JSC::JITGetByValGenerator::generateFastPath):
(JSC::JITGetByValGenerator::finalize):
(JSC::JITPrivateBrandAccessGenerator::JITPrivateBrandAccessGenerator):
(JSC::JITPrivateBrandAccessGenerator::generateFastPath):
(JSC::JITPrivateBrandAccessGenerator::finalize):
* jit/JITInlineCacheGenerator.h:
(JSC::JITGetByIdGenerator::JITGetByIdGenerator): Deleted.
(JSC::JITGetByIdWithThisGenerator::JITGetByIdWithThisGenerator): Deleted.
(JSC::JITPutByIdGenerator::JITPutByIdGenerator): Deleted.
(JSC::JITDelByValGenerator::JITDelByValGenerator): Deleted.
(JSC::JITDelByValGenerator::slowPathJump const): Deleted.
(JSC::JITDelByIdGenerator::JITDelByIdGenerator): Deleted.
(JSC::JITDelByIdGenerator::slowPathJump const): Deleted.
(JSC::JITInByIdGenerator::JITInByIdGenerator): Deleted.
(JSC::JITInstanceOfGenerator::JITInstanceOfGenerator): Deleted.
(JSC::JITGetByValGenerator::JITGetByValGenerator): Deleted.
(JSC::JITGetByValGenerator::slowPathJump const): Deleted.
(JSC::JITPrivateBrandAccessGenerator::JITPrivateBrandAccessGenerator): Deleted.
(JSC::JITPrivateBrandAccessGenerator::slowPathJump const): Deleted.
* jit/JITInlines.h:
(JSC::JIT::emitLoadForArrayMode):
(JSC::JIT::appendCallWithExceptionCheck):
(JSC::JIT::appendCallWithExceptionCheckSetJSValueResult):
(JSC::JIT::appendCallWithExceptionCheckSetJSValueResultWithProfile):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_instanceof):
(JSC::JIT::emitSlow_op_instanceof):
(JSC::JIT::privateCompileHasIndexedProperty):
(JSC::JIT::emit_op_has_enumerable_indexed_property):
(JSC::JIT::emitSlow_op_has_enumerable_indexed_property):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_instanceof):
(JSC::JIT::privateCompileHasIndexedProperty):
(JSC::JIT::emit_op_has_enumerable_indexed_property):
* jit/JITOperations.cpp:
(JSC::JSC_DEFINE_JIT_OPERATION):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::slow_op_get_by_val_prepareCallGenerator):
(JSC::JIT::emit_op_get_private_name):
(JSC::JIT::emitSlow_op_get_private_name):
(JSC::JIT::slow_op_get_private_name_prepareCallGenerator):
(JSC::JIT::emit_op_set_private_brand):
(JSC::JIT::emitSlow_op_set_private_brand):
(JSC::JIT::emit_op_check_private_brand):
(JSC::JIT::emitSlow_op_check_private_brand):
(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::slow_op_put_by_val_prepareCallGenerator):
(JSC::JIT::emit_op_put_private_name):
(JSC::JIT::emitSlow_op_put_private_name):
(JSC::JIT::slow_op_put_private_name_prepareCallGenerator):
(JSC::JIT::emit_op_del_by_id):
(JSC::JIT::emitSlow_op_del_by_id):
(JSC::JIT::slow_op_del_by_id_prepareCallGenerator):
(JSC::JIT::emit_op_del_by_val):
(JSC::JIT::emitSlow_op_del_by_val):
(JSC::JIT::slow_op_del_by_val_prepareCallGenerator):
(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::slow_op_get_by_id_prepareCallGenerator):
(JSC::JIT::emitSlow_op_get_by_id_with_this):
(JSC::JIT::slow_op_get_by_id_with_this_prepareCallGenerator):
(JSC::JIT::emit_op_put_by_id):
(JSC::JIT::emitSlow_op_put_by_id):
(JSC::JIT::slow_op_put_by_id_prepareCallGenerator):
(JSC::JIT::emit_op_in_by_id):
(JSC::JIT::emitSlow_op_in_by_id):
(JSC::JIT::emit_op_in_by_val):
(JSC::JIT::emitSlow_op_in_by_val):
(JSC::JIT::privateCompilePutByVal):
(JSC::JIT::privateCompilePutPrivateNameWithCachedId):
(JSC::JIT::privateCompilePutByValWithCachedId):
(JSC::JIT::emitDoubleLoad):
(JSC::JIT::emitContiguousLoad):
(JSC::JIT::emitArrayStorageLoad):
(JSC::JIT::emitIntTypedArrayPutByVal):
(JSC::JIT::emitFloatTypedArrayPutByVal):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_del_by_id):
(JSC::JIT::emit_op_del_by_val):
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emit_op_get_private_name):
(JSC::JIT::emit_op_set_private_brand):
(JSC::JIT::emit_op_check_private_brand):
(JSC::JIT::emit_op_put_by_val):
(JSC::JIT::emitGenericContiguousPutByVal):
(JSC::JIT::emitArrayStoragePutByVal):
(JSC::JIT::emit_op_try_get_by_id):
(JSC::JIT::emit_op_get_by_id_direct):
(JSC::JIT::emit_op_get_by_id):
(JSC::JIT::emit_op_get_by_id_with_this):
(JSC::JIT::emit_op_put_by_id):
(JSC::JIT::emit_op_in_by_id):
(JSC::JIT::emit_op_in_by_val):
* jit/JITStubRoutine.h:
* jit/PolymorphicCallStubRoutine.cpp:
(JSC::PolymorphicCallStubRoutine::PolymorphicCallStubRoutine):
* jit/Repatch.cpp:
(JSC::readPutICCallTarget):
(JSC::repatchSlowPathCall):
(JSC::tryCacheGetBy):
(JSC::repatchGetBy):
(JSC::tryCacheArrayGetByVal):
(JSC::repatchArrayGetByVal):
(JSC::tryCachePutByID):
(JSC::repatchPutByID):
(JSC::tryCacheDeleteBy):
(JSC::repatchDeleteBy):
(JSC::tryCacheInBy):
(JSC::repatchInBy):
(JSC::tryCacheCheckPrivateBrand):
(JSC::repatchCheckPrivateBrand):
(JSC::tryCacheSetPrivateBrand):
(JSC::repatchSetPrivateBrand):
(JSC::tryCacheInstanceOf):
(JSC::repatchInstanceOf):
(JSC::linkSlowFor):
(JSC::linkVirtualFor):
(JSC::resetGetBy):
(JSC::resetPutByID):
(JSC::resetDelBy):
(JSC::resetInBy):
(JSC::resetInstanceOf):
(JSC::resetCheckPrivateBrand):
(JSC::resetSetPrivateBrand):
(JSC::resetPatchableJump): Deleted.
* jit/Repatch.h:
* runtime/Options.cpp:
(JSC::Options::recomputeDependentOptions):
* runtime/OptionsList.h:
* runtime/StructureIDTable.h:
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::~VM):
* runtime/VM.h:
2021-06-08 Robin Morisset <rmorisset@apple.com>
Fix speculated type in speculateNeitherDoubleNorHeapBigIntNorString
https://bugs.webkit.org/show_bug.cgi?id=226786
Reviewed by Mark Lam.
I had forgotten the HeapBigInt part.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::speculateNeitherDoubleNorHeapBigIntNorString):
2021-06-06 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use ResolvedClosureVar to get brand from scope
https://bugs.webkit.org/show_bug.cgi?id=226677
rdar://78802869
Reviewed by Saam Barati.
Private brand lookup is doing wrong way to get scope.
1. op_resolve_scope with private name (e.g. #x)
2. then, doing op_get_from_scope with (1)'s scope with different name (e.g. @privateBrand)
This is wrong in JSC. We resolve scope at link-time in CodeBlock. So we need to ensure that both op_resolve_scope and op_get_from_scope
starts with the current scope-register. As a result, private-brand lookup is broken right now. Let's see the buggy case.
class D {
#x() {}
m() {
class C {
#yy;
#z() { }
a() {
this.#x(); // <===== This point.
}
}
let c = new C();
c.a();
}
}
In the above point, we first lookup the scope with #x, and we get the D's class-scope. But our get_from_scope is using privateBrand, and
privateBrand property exists too in C's class-scope too since C also has #yy and #z. As a result, CodeBlock linking configures the offset for
C's class-scope in get_from_scope. And this offset is different from D's class-scope's privateBrand.
Only allowed case for the above usage is ResolvedClosureVar. And generatorification uses it too. In this patch,
1. We ensure that class-scope (with private name) must have @privateBrand and @privateClassBrand with offset 1 and 0.
2. Use ResolvedClosureVar with the above pre-defined offset
Since CodeBlock's linking does not resolve the scope for get_from_scope if it is ResolvedClosureVar, we can just perform the desired ResolvedClosureVar lookup
with the given scope with the compiled offset.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::instantiateLexicalVariables):
(JSC::BytecodeGenerator::pushLexicalScope):
(JSC::BytecodeGenerator::pushLexicalScopeInternal):
(JSC::BytecodeGenerator::emitCreatePrivateBrand):
(JSC::BytecodeGenerator::emitGetPrivateBrand):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::BaseDotNode::emitGetPropertyValue):
(JSC::BaseDotNode::emitPutProperty):
(JSC::PostfixNode::emitDot):
(JSC::PrefixNode::emitDot):
(JSC::InNode::emitBytecode):
(JSC::BlockNode::emitBytecode):
(JSC::ForNode::emitBytecode):
(JSC::ForInNode::emitBytecode):
(JSC::ForOfNode::emitBytecode):
(JSC::SwitchNode::emitBytecode):
(JSC::ClassExprNode::emitBytecode):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
* parser/VariableEnvironment.h:
2021-06-07 Alexey Shvayka <shvaikalesh@gmail.com>
Unreviewed, reland r276592 with a fix for put() override in prototype chain of a JSProxy
https://bugs.webkit.org/show_bug.cgi?id=226185
The API test added in r278366 revealed a flaw in JSObject::definePropertyOnReceiver()
that caused putDirectInternal() to be performed on a JSProxy instead of it's target.
Remedies that via a type check, ensuring the test and iOS apps are functional.
The issue was originally missed because the prototype chain of a global object is immutable
and none of the global object's prototypes override put(). OpaqueJSClass::prototype() sets
the [[Prototype]] directly, ignoring the IsImmutablePrototypeExoticObject type info flag.
Also, excludes an invariant from the original patch that required put() to be overriden
when implementing custom [[DefineOwnProperty]]. It is now broken by WindowProperties object.
* API/JSCallbackObject.h:
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::put):
* API/tests/testapiScripts/testapi.js:
* debugger/DebuggerScope.h:
* runtime/ClassInfo.h:
* runtime/ClonedArguments.h:
* runtime/CustomGetterSetter.cpp:
(JSC::callCustomSetter): Deleted.
* runtime/CustomGetterSetter.h:
* runtime/ErrorConstructor.h:
* runtime/ErrorInstance.h:
* runtime/GenericArguments.h:
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments<Type>::put):
* runtime/GetterSetter.h:
* runtime/JSArray.cpp:
(JSC::JSArray::put):
* runtime/JSArray.h:
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::put): Deleted.
* runtime/JSArrayBufferView.h:
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive):
* runtime/JSCell.cpp:
(JSC::JSCell::doPutPropertySecurityCheck): Deleted.
* runtime/JSCell.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::put):
* runtime/JSFunction.h:
* runtime/JSGenericTypedArrayView.h:
* runtime/JSGlobalLexicalEnvironment.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::put):
* runtime/JSGlobalObject.h:
* runtime/JSLexicalEnvironment.h:
* runtime/JSModuleEnvironment.h:
* runtime/JSModuleNamespaceObject.h:
* runtime/JSObject.cpp:
(JSC::JSObject::getOwnPropertySlot):
(JSC::JSObject::putInlineSlow):
(JSC::definePropertyOnReceiverSlow):
(JSC::JSObject::definePropertyOnReceiver):
(JSC::JSObject::putInlineFastReplacingStaticPropertyIfNeeded):
(JSC::JSObject::doPutPropertySecurityCheck): Deleted.
(JSC::JSObject::prototypeChainMayInterceptStoreTo): Deleted.
* runtime/JSObject.h:
(JSC::JSObject::putByIndexInline):
(JSC::JSObject::hasNonReifiedStaticProperties):
(JSC::JSObject::getOwnPropertySlot):
(JSC::JSObject::putDirect):
(JSC::JSObject::doPutPropertySecurityCheck): Deleted.
* runtime/JSObjectInlines.h:
(JSC::JSObject::canPerformFastPutInlineExcludingProto):
(JSC::JSObject::putInlineForJSObject):
(JSC::JSObject::putInlineFast):
(JSC::JSObject::putDirectInternal):
* runtime/JSProxy.h:
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::hasStaticPropertyTable const):
(JSC::TypeInfo::overridesPut const):
(JSC::TypeInfo::getOwnPropertySlotMayBeWrongAboutDontEnum const):
(JSC::TypeInfo::hasPutPropertySecurityCheck const): Deleted.
* runtime/Lookup.h:
(JSC::putEntry): Deleted.
(JSC::lookupPut): Deleted.
* runtime/PropertySlot.h:
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::put):
* runtime/ProxyObject.h:
* runtime/PutPropertySlot.h:
(JSC::PutPropertySlot::PutPropertySlot):
(JSC::PutPropertySlot::context const):
(JSC::PutPropertySlot::isTaintedByOpaqueObject const):
(JSC::PutPropertySlot::setIsTaintedByOpaqueObject):
* runtime/ReflectObject.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::put):
* runtime/RegExpObject.h:
* runtime/StringObject.cpp:
(JSC::StringObject::put):
* runtime/StringObject.h:
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
(JSC::StringPrototype::create):
* runtime/StringPrototype.h:
* runtime/Structure.cpp:
(JSC::Structure::validateFlags):
* runtime/Structure.h:
(JSC::Structure::hasNonReifiedStaticProperties const):
* tools/JSDollarVM.cpp:
2021-06-07 Alexey Shvayka <shvaikalesh@gmail.com>
Introduce LexicalScopeFeatures to enable future bytecode optimizations
https://bugs.webkit.org/show_bug.cgi?id=224072
Reviewed by Keith Miller.
Before this patch, BytecodeGenerator was capable of reasoning about the presence of `with`
statements, direct `eval`, or any other code features only within the current executable:
```
with (foo) {
(function() {
// There was no way to detect WithScope during generation of this function.
})();
}
```
This change is required for op_to_this rewrite (#225397): if FunctionCallResolveNode and
friends knew there is no WithScope, op_call could be emitted with |this| value of
`undefined` as per spec [1], instead of resolved scope. This would:
- simplify op_to_this on all tiers, likely resulting in minor perf boost;
- save 1 instruction per strict function by removing op_to_this;
- remove toThis() from the method table and ~30 its call sites from built-ins;
- fix built-in methods that were observably lacking toThis();
- fix __proto__ getter / setter called on global scope;
- fix WebIDL accessors called with |this| value of `undefined` and `null`.
Also, if ResolveNode knew that unforgeable global properties are not shadowed and there
is no `with` statement or sloppy mode direct `eval`, then `undefined` / `Infinity` / `NaN`
lookups could be constant-folded. This would save up to 3 bytecode ops per each usage
and allow emitting op_is_undefined_or_null for `x === undefined || x === null`.
V8 performs this optimization [2].
This patch introduces LexicalScopeFeatures to allow passing such information from Parser
to BytecodeGenerator with a minimal code diff. These features are kept separate from
CodeFeature to simplify reasoning about feature's scope and because we need to propagate
lexical features from parent to child scope.
Strict mode is the first use case of LexicalScopeFeatures, which this change carefully
fits into existing abstractions without increasing their memory usage even by 1 byte.
[1]: https://tc39.es/ecma262/#sec-evaluatecall (step 2)
[2]: https://medium.com/@bmeurer/sometimes-undefined-is-defined-7701e1c9eff8
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createExecutable):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::lexicalScopeFeatures const):
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::generateUnlinkedFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::UnlinkedFunctionExecutable::setInvalidTypeProfilingOffsets):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitNewClassFieldInitializerFunction):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::lexicalScopeFeatures const):
(JSC::BytecodeGenerator::generate):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionMetadata):
* parser/Nodes.cpp:
(JSC::ScopeNode::ScopeNode):
(JSC::ProgramNode::ProgramNode):
(JSC::ModuleProgramNode::ModuleProgramNode):
(JSC::EvalNode::EvalNode):
(JSC::FunctionMetadataNode::FunctionMetadataNode):
(JSC::FunctionMetadataNode::operator== const):
(JSC::FunctionMetadataNode::dump const):
(JSC::FunctionNode::FunctionNode):
* parser/Nodes.h:
(JSC::ScopeNode::lexicalScopeFeatures):
(JSC::ScopeNode::isStrictMode const):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
(JSC::Parser<LexerType>::parseAsyncFunctionSourceElements):
(JSC::Parser<LexerType>::parseAsyncGeneratorFunctionSourceElements):
(JSC::Parser<LexerType>::parseFunctionBody):
(JSC::Parser<LexerType>::parseFunctionInfo):
* parser/Parser.h:
(JSC::Scope::Scope):
(JSC::Scope::lexicalScopeFeatures const):
(JSC::Scope::setStrictMode):
(JSC::Scope::strictMode const):
(JSC::Scope::fillParametersForSourceProviderCache):
(JSC::Scope::restoreFromSourceProviderCache):
(JSC::Parser::pushScope):
(JSC::Parser::lexicalScopeFeatures):
(JSC::Parser<LexerType>::parse):
* parser/ParserModes.h:
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::lexicalScopeFeatures const):
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionMetadata):
* runtime/CachedBytecode.cpp:
(JSC::CachedBytecode::addFunctionUpdate):
* runtime/CachedTypes.cpp:
(JSC::CachedFunctionExecutable::lexicalScopeFeatures const):
(JSC::CachedCodeBlock::lexicalScopeFeatures const):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
(JSC::CachedFunctionExecutable::encode):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::CachedCodeBlock<CodeBlockType>::encode):
(JSC::CachedFunctionExecutable::isInStrictContext const): Deleted.
* runtime/CachedTypes.h:
* runtime/CodeCache.cpp:
(JSC::generateUnlinkedCodeBlockImpl):
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
* runtime/ECMAMode.h:
(JSC::ECMAMode::fromBool):
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::FunctionExecutable):
* runtime/GlobalExecutable.h:
(JSC::GlobalExecutable::recordParse):
(JSC::GlobalExecutable::GlobalExecutable):
* runtime/ScriptExecutable.cpp:
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::ScriptExecutable::recordParse):
* runtime/ScriptExecutable.h:
(JSC::ScriptExecutable::isInStrictContext const):
(JSC::ScriptExecutable::recordParse):
2021-06-07 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r278371 and r278463.
https://bugs.webkit.org/show_bug.cgi?id=226749
Break dumpDisassembly in JetStream2
Reverted changesets:
"We should drop B3 values while running Air"
https://bugs.webkit.org/show_bug.cgi?id=226187
https://trac.webkit.org/changeset/278371
"Drop the FTL(DFG) graph after lowering to B3"
https://bugs.webkit.org/show_bug.cgi?id=226556
https://trac.webkit.org/changeset/278463
2021-06-07 Alexey Shvayka <shvaikalesh@gmail.com>
Window should behave like a legacy platform object without indexed setter
https://bugs.webkit.org/show_bug.cgi?id=225894
Reviewed by Darin Adler.
* runtime/TypeError.h:
(JSC::typeError):
2021-06-07 Saam Barati <sbarati@apple.com>
Short circuit read modify write nodes emit byte code that uses the wrong locals
https://bugs.webkit.org/show_bug.cgi?id=226576
<rdar://problem/78810362>
Reviewed by Yusuke Suzuki.
It's never a good idea to use the wrong local :-)
This patch also adds support for dumping predecessors of basic blocks
in the bytecode dump.
* bytecode/BytecodeDumper.cpp:
(JSC::CodeBlockBytecodeDumper<Block>::dumpGraph):
* bytecompiler/NodesCodegen.cpp:
(JSC::ShortCircuitReadModifyResolveNode::emitBytecode):
(JSC::ShortCircuitReadModifyDotNode::emitBytecode):
(JSC::ShortCircuitReadModifyBracketNode::emitBytecode):
2021-06-07 Mark Lam <mark.lam@apple.com>
Put the Baseline JIT prologue and op_loop_hint code in JIT thunks.
https://bugs.webkit.org/show_bug.cgi?id=226375
Reviewed by Keith Miller and Robin Morisset.
Baseline JIT prologue code varies in behavior based on several variables. These
variables include (1) whether the prologue does any arguments value profiling,
(2) whether the prologue is for a constructor, and (3) whether the compiled
CodeBlock will have such a large frame that it is greater than the stack reserved
zone (aka red zone) which would require additional stack check logic.
The pre-existing code would generate specialized code based on these (and other
variables). In converting to using thunks for the prologue, we opt not to
convert these specializations into runtime checks. Instead, the implementation
uses 1 of 8 possible specialized thunks to reduce the need to pass arguments for
runtime checks. The only needed argument passed to the prologue thunks is the
codeBlock pointer.
There are 8 possible thunks because we specialize based on 3 variables:
1. doesProfiling
2. isConstructor
3. hasHugeFrame
2**3 yields 8 permutations of prologue thunk specializations.
Similarly, there are also 8 analogous arity fixup prologues that work similarly.
The op_loop_hint thunk only takes 1 runtime argument: the bytecode offset.
We've tried doing the loop_hint optimization check in the thunk (in order to move
both the fast and slow path into the thunk for maximum space savings). However,
this seems to have some slight negative impact on benchmark performance. We ended
up just keeping the fast path and instead have the slow path call a thunk to do
its work. This realizes the bulk of the size savings without the perf impact.
This patch also optimizes op_enter a bit more by eliminating the need to pass any
arguments to the thunk. The thunk previously took 2 arguments: localsToInit and
canBeOptimized. localsToInit is now computed in the thunk at runtime, and
canBeOptimized is used as a specialization argument to generate 2 variants of the
op_enter thunk: op_enter_canBeOptimized_Generator and op_enter_cannotBeOptimized_Generator,
thereby removing the need to pass it as a runtime argument.
LinkBuffer size results (from a single run of Speedometer2):
BaselineJIT: 93319628 (88.996532 MB) => 83851824 (79.967331 MB) 0.90x
ExtraCTIThunk: 5992 (5.851562 KB) => 6984 (6.820312 KB) 1.17x
...
Total: 197530008 (188.379295 MB) => 188459444 (179.728931 MB) 0.95x
Speedometer2 and JetStream2 results (as measured on an M1 Mac) are neutral.
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::untagReturnAddressWithoutExtraValidation):
* assembler/MacroAssemblerARM64E.h:
(JSC::MacroAssemblerARM64E::untagReturnAddress):
(JSC::MacroAssemblerARM64E::untagReturnAddressWithoutExtraValidation):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::branchAdd32):
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::branchAdd32):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::offsetOfNumCalleeLocals):
(JSC::CodeBlock::offsetOfNumVars):
(JSC::CodeBlock::offsetOfArgumentValueProfiles):
(JSC::CodeBlock::offsetOfShouldAlwaysBeInlined):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitSaveCalleeSavesFor):
(JSC::AssemblyHelpers::emitSaveCalleeSavesForBaselineJIT):
(JSC::AssemblyHelpers::emitRestoreCalleeSavesForBaselineJIT):
* jit/JIT.cpp:
(JSC::JIT::compileAndLinkWithoutFinalizing):
(JSC::JIT::prologueGenerator):
(JSC::JIT::arityFixupPrologueGenerator):
(JSC::JIT::privateCompileExceptionHandlers):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::emitNakedNearCall):
* jit/JITOpcodes.cpp:
(JSC::JIT::op_ret_handlerGenerator):
(JSC::JIT::emit_op_enter):
(JSC::JIT::op_enter_Generator):
(JSC::JIT::op_enter_canBeOptimized_Generator):
(JSC::JIT::op_enter_cannotBeOptimized_Generator):
(JSC::JIT::emit_op_loop_hint):
(JSC::JIT::emitSlow_op_loop_hint):
(JSC::JIT::op_loop_hint_Generator):
(JSC::JIT::op_enter_handlerGenerator): Deleted.
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_enter):
* jit/ThunkGenerators.cpp:
(JSC::popThunkStackPreservesAndHandleExceptionGenerator):
2021-06-07 Robin Morisset <rmorisset@apple.com>
Optimize compareStrictEq when neither side is a double and at least one is neither a string nor a BigInt
https://bugs.webkit.org/show_bug.cgi?id=226676
Reviewed by Filip Pizlo.
There is exactly one case where x === y must return false despite x and y being JSValues with the same bits:
NaN === NaN
There are a few cases where x === y must return true despite x and y being JSValues with potentially different bits:
Double === Int32
String === String
HeapBigInt === HeapBigInt
HeapBigInt === BigInt32 (if they are enabled)
If we don't have a double on either side, at least one side has neither a String nor a HeapBigInt, and BigInt32 are disabled, we can clearly ignore all of these pathological cases.
This optimization was decided based on looking at DFG graphs of Speedometer2; here is a sample of the compareStrictEq(Untyped, Untyped), courtesy of Phil:
Final|Array|String|Bool, Final|Array|String|Bool
Array|String|Bool, String|Bool (twice)
Array|String|Bool, String|Int32 (once in DFG, once in FTL)
! Array|String|Bool, Array|Bool
! Final|Other, Final|Other
! Int32|Other, Int32
Final|StringIdent, Final|StringIdent (3 times)
Final|StringIdent|BoolInt32, StringIdent|BoolInt32 (twice)
String|Bool, String|Bool (4 times)
DoublePureNaN, String|Bool
! Other, Function|Other
! Final|Other, Final|Function|Other (twice)
Final|String|Bool|Other, Final|String|Bool|Other (3 times, two in the FTL)
Final|String|Int32, String|Int32 (four times)
String|Int32|Bool, Function|String|Int32|Bool (twice)
String|DoublePureNaN, String|Bool (twice)
! Final|Bool|Other, Final|Function|Other (four times, twice in FTL)
I marked with a ! those for which this optimization should apply.
The only slightly interesting part of this patch is DFG::SpeculativeJIT::speculateNeitherDoubleNorHeapBigIntNorString where I took care to skip every test whose result we can predict from the abstract interpreter.
Results on microbenchmarks:
poly-stricteq-not-double 45.5793+-0.5304 ? 46.0306+-0.5621 ?
poly-stricteq-not-double-nor-string 45.5829+-0.5750 ^ 16.9089+-0.3070 ^ definitely 2.6958x faster
poly-stricteq 49.9719+-0.6450 48.9855+-0.5227 might be 1.0201x faster
I also measured the amount of code that we generate in the DFG on JetStream2.
The results here are disappointing but still measurable. Before:
DFG_fast_CompareStrictEq totalBytes: 468425 count: 10951 avg: 42.774632
DFG_fast_CompareStrictEq totalBytes: 468020 count: 10917 avg: 42.870752
DFG_fast_CompareStrictEq totalBytes: 467424 count: 10888 avg: 42.930198
After:
DFG_fast_CompareStrictEq totalBytes: 463946 count: 10917 avg: 42.497573
DFG_fast_CompareStrictEq totalBytes: 474492 count: 11138 avg: 42.601185
DFG_fast_CompareStrictEq totalBytes: 467138 count: 10970 avg: 42.583227
* bytecode/SpeculatedType.h:
(JSC::isNeitherDoubleNorHeapBigIntNorStringSpeculation):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupCompareStrictEqAndSameValue):
* dfg/DFGNode.h:
(JSC::DFG::Node::shouldSpeculateNeitherDoubleNorHeapBigIntNorString):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::SafeToExecuteEdge::operator()):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileStrictEq):
(JSC::DFG::SpeculativeJIT::compileNotDoubleNeitherDoubleNorHeapBigIntNorStringStrictEquality):
(JSC::DFG::SpeculativeJIT::compilePeepHoleNotDoubleNeitherDoubleNorHeapBigIntNorStringStrictEquality):
(JSC::DFG::SpeculativeJIT::speculateNotDouble):
(JSC::DFG::SpeculativeJIT::speculateNeitherDoubleNorHeapBigIntNorString):
(JSC::DFG::SpeculativeJIT::speculate):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGUseKind.cpp:
(WTF::printInternal):
* dfg/DFGUseKind.h:
(JSC::DFG::typeFilterFor):
(JSC::DFG::checkMayCrashIfInputIsEmpty):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
(JSC::FTL::DFG::LowerDFGToB3::speculate):
(JSC::FTL::DFG::LowerDFGToB3::speculateNeitherDoubleNorHeapBigIntNorString):
2021-06-07 Tuomas Karkkainen <tuomas.webkit@apple.com>
$vm should have a function for checking if security assertions are enabled similar to $vm.assertEnabled
https://bugs.webkit.org/show_bug.cgi?id=226020
<rdar://problem/78567619>
Reviewed by Mark Lam.
Add method $vm.securityAssertEnabled() which parallels $vm.assertEnabled(), and allows
checking at runtime whether the current JavaScriptCore build has security assertions enabled.
* tools/JSDollarVM.cpp:
2021-06-04 Chris Dumez <cdumez@apple.com>
FileSystem::readFromFile() should return data as `void*`
https://bugs.webkit.org/show_bug.cgi?id=226671
Reviewed by Darin Adler.
FileSystem::readFromFile() should return data as `void*` instead of `char*`. This is more flexible and
consistent with FileSystem::writeToFile().
* inspector/remote/socket/RemoteInspectorSocket.cpp:
(Inspector::RemoteInspector::backendCommands const):
2021-06-04 Devin Rousso <drousso@apple.com>
Web Inspector: mark recently added protocol commands/events as page-only
https://bugs.webkit.org/show_bug.cgi?id=226661
Reviewed by Joseph Pecoraro.
* inspector/protocol/CSS.json:
* inspector/protocol/Network.json:
These commands are not implemented in ITML. By not specifying `"targetTypes": ["page"]` it's
implicitly saying that the command/event is supported by ITML since the command/event will
fall back to the domain's `"targetTypes"`, which includes ITML.
2021-06-04 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Private static method should define privateClassBrandIdentifier in class-scope
https://bugs.webkit.org/show_bug.cgi?id=226656
rdar://78313139
Reviewed by Keith Miller.
We accidentally made `declaresStaticPrivateMethod` always `false`.
This patch fixes that so that we properly define privateClassBrandIdentifier field in the class-scope if static-private-method is defined.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
2021-06-04 Filip Pizlo <fpizlo@apple.com>
Don't emit the NotDouble checks if we're already NotDouble.
Rubber stamped by Saam Barati.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::speculateNotDouble):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::speculateNotDouble):
2021-06-04 Mark Lam <mark.lam@apple.com>
Placate exception checker validation in objectPrototypeHasOwnProperty.
https://bugs.webkit.org/show_bug.cgi?id=226651
rdar://78861296
Reviewed by Keith Miller.
* runtime/ObjectPrototype.cpp:
(JSC::objectPrototypeHasOwnProperty):
2021-06-03 Filip Pizlo <fpizlo@apple.com>
DFG should speculate on CompareStrictEq(@x, @x)
https://bugs.webkit.org/show_bug.cgi?id=226621
Reviewed by Mark Lam.
Introduces a NotDouble: speculation. We use it to speculate on CompareStrictEq(@x, @x).
* bytecode/SpeculatedType.h:
(JSC::isNotDoubleSpeculation):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupCompareStrictEqAndSameValue):
* dfg/DFGNode.h:
(JSC::DFG::Node::shouldSpeculateNotDouble):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::SafeToExecuteEdge::operator()):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::speculateNotDouble):
(JSC::DFG::SpeculativeJIT::speculate):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGUseKind.cpp:
(WTF::printInternal):
* dfg/DFGUseKind.h:
(JSC::DFG::typeFilterFor):
(JSC::DFG::checkMayCrashIfInputIsEmpty):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::speculate):
(JSC::FTL::DFG::LowerDFGToB3::speculateNotDouble):
2021-06-04 Robin Morisset <rmorisset@apple.com>
Drop the FTL(DFG) graph after lowering to B3
https://bugs.webkit.org/show_bug.cgi?id=226556
Reviewed by Phil Pizlo.
The challenge in this patch was dealing with all of the Patchpoints created by FTLLowerDFGToB3: they get a lambda at that time, which they execute at the end of Air, and many of these lambdas were capturing a pointer to some parts of the DFG graph and reading through it when being executed.
In all cases but one it was easily fixed: they were only reading a few bits from a given node, so I just read these bits in FTLLowerDFGToB3, and captured them (by value) instead of the pointer to the node.
The exception was compileCallOrConstructVarargsSpread(): its patchpoint generator was walking through the graph, flattening a tree of PhantomSpread/PhantomNewArrayWithSpread/PhantomNewArrayBuffer/PhantomCreateRest, emitting some code along the way.
We now do this flattening of the tree in FTLLowerDFGToB3, store just enough information to later emit the required code in a vector, and capture that vector in the lambda (through a move capture, which is allowed since C++14). See `struct VarargsSpreadArgumentToEmit` for the information that we need to store in that vector.
I tested this change by completing a full run of JetStream2 with ASAN.
I also ran the stress tests with "spread" in their name in Debug mode.
* b3/B3SparseCollection.h:
(JSC::B3::SparseCollection::clearAll):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::freeDFGIRAfterLowering):
* dfg/DFGGraph.h:
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileUnaryMathIC):
(JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC):
(JSC::FTL::DFG::LowerDFGToB3::getPrivateName):
(JSC::FTL::DFG::LowerDFGToB3::compilePrivateBrandAccess):
(JSC::FTL::DFG::LowerDFGToB3::cachedPutById):
(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToB3::compileDelBy):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
(JSC::FTL::DFG::LowerDFGToB3::VarargsSpreadArgumentToEmit::VarargsSpreadArgumentToEmit):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
(JSC::FTL::DFG::LowerDFGToB3::compileCallEval):
(JSC::FTL::DFG::LowerDFGToB3::compileInById):
(JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
(JSC::FTL::DFG::LowerDFGToB3::getById):
(JSC::FTL::DFG::LowerDFGToB3::getByIdWithThis):
(JSC::FTL::DFG::LowerDFGToB3::emitBinarySnippet):
(JSC::FTL::DFG::LowerDFGToB3::emitBinaryBitOpSnippet):
(JSC::FTL::DFG::LowerDFGToB3::emitRightShiftSnippet):
(JSC::FTL::DFG::LowerDFGToB3::crash):
2021-06-04 Tadeu Zagallo <tzagallo@apple.com>
Optimize Function.prototype.toString
https://bugs.webkit.org/show_bug.cgi?id=226418
<rdar://77861846>
Reviewed by Saam Barati.
Add caching to Function.prototype.toString. This is used heavily in Speedometer2, and repeatedly recomputing a
string which is a constant is costly. We cache the results of toString in all cases except for bound functions.
To make this work for bound functions, we'd need to add a new field they can use for this cache. For other
functions, we cache it on the executable (either NativeExecutable or FunctionExecutable). The reason we can't
do this on the executable for bound functions is that all bound functions share the same executable, but
individual bound functions can have different names. The reason it's valid to cache the results in general is that a
function's name field can't be changed from JS code -- it's non-writable.
This patch also makes Function.prototype.toString an intrinsic in the DFG/FTL. We emit code on the fast path
which reads the cached value if it's present. If not, we call into the slow path, which will compute
the cached value for non bound functions, or compute the result for bound functions.
I added a new microbenchmark that speeds up by >35x:
function-to-string 2197.5952+-30.7118 ^ 59.9861+-2.5550 ^ definitely 36.6350x faster
* CMakeLists.txt:
* 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):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::getExecutable):
(JSC::DFG::SpeculativeJIT::compileFunctionToString):
(JSC::DFG::SpeculativeJIT::compileGetExecutable):
* 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::getExecutable):
(JSC::FTL::DFG::LowerDFGToB3::compileGetExecutable):
(JSC::FTL::DFG::LowerDFGToB3::compileFunctionToString):
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::visitChildrenImpl):
(JSC::FunctionExecutable::toStringSlow):
* runtime/FunctionExecutable.h:
* runtime/FunctionExecutableInlines.h:
(JSC::FunctionExecutable::toString):
* runtime/FunctionPrototype.cpp:
(JSC::FunctionPrototype::addFunctionProperties):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/Intrinsic.cpp:
(JSC::intrinsicName):
* runtime/Intrinsic.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::toString):
* runtime/JSFunction.h:
* runtime/JSFunctionInlines.h:
(JSC::JSFunction::asStringConcurrently const):
* runtime/JSStringInlines.h:
* runtime/NativeExecutable.cpp:
(JSC::NativeExecutable::toStringSlow):
(JSC::NativeExecutable::visitChildrenImpl):
* runtime/NativeExecutable.h:
2021-06-04 Michael Catanzaro <mcatanzaro@gnome.org>
Fix more GCC warnings
https://bugs.webkit.org/show_bug.cgi?id=226193
Reviewed by Adrian Perez de Castro.
Fix -Wreturn-type warnings due to missing RELEASE_ASSERT_NOT_REACHED() where expected.
* jit/JITPlan.cpp:
(JSC::JITPlan::tier const):
* jit/ThunkGenerators.cpp:
(JSC::virtualThunkFor):
2021-06-03 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Implement JIT ICs for InByVal
https://bugs.webkit.org/show_bug.cgi?id=226563
Reviewed by Saam Barati.
Until now, InByVal has had few optimizations implemented:
DFG would attempt to convert string index lookups to InById and int32 lookups to HasIndexedProperty,
but there has been no inline caching nor any special handling for symbol lookups.
This has become a more urgent problem now, as `#x in obj` (i.e. HasPrivateName / HasPrivateBrand)
will need to mimic InByVal's inline caching strategy in order to be deemed performant enough to ship.
This patch thus implements inline caching for InByVal at all JIT tiers.
The result is a night-and-day difference for symbols, a nice boost for string indices, and no change for int32s:
in-by-val-symbol 203.5572+-2.7647 ^ 19.1035+-0.7498 ^ definitely 10.6555x faster
in-by-val-string-index 87.0368+-44.7766 45.9971+-32.0007 might be 1.8922x faster
in-by-val-int32 110.9904+-1.7109 ? 111.3431+-1.7558 ?
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/CheckPrivateBrandStatus.cpp:
(JSC::CheckPrivateBrandStatus::singleIdentifier const):
* bytecode/DeleteByStatus.cpp:
(JSC::DeleteByStatus::singleIdentifier const):
* bytecode/GetByStatus.cpp:
(JSC::GetByStatus::singleIdentifier const):
* bytecode/ICStatusMap.h:
* bytecode/ICStatusUtils.h:
(JSC::singleIdentifierForICStatus):
* bytecode/InByIdVariant.cpp:
(JSC::InByIdVariant::InByIdVariant):
(JSC::InByIdVariant::attemptToMerge):
(JSC::InByIdVariant::dumpInContext const):
* bytecode/InByIdVariant.h:
(JSC::InByIdVariant::identifier const):
(JSC::InByIdVariant::overlaps):
* bytecode/InByStatus.cpp: Renamed from Source/JavaScriptCore/bytecode/InByIdStatus.cpp.
(JSC::InByStatus::appendVariant):
(JSC::InByStatus::shrinkToFit):
(JSC::InByStatus::computeFor):
(JSC::InByStatus::computeForStubInfo):
(JSC::InByStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::InByStatus::merge):
(JSC::InByStatus::filter):
(JSC::InByStatus::markIfCheap):
(JSC::InByStatus::finalize):
(JSC::InByStatus::singleIdentifier const):
(JSC::InByStatus::dump const):
* bytecode/InByStatus.h: Renamed from Source/JavaScriptCore/bytecode/InByIdStatus.h.
* bytecode/RecordedStatuses.cpp:
(JSC::RecordedStatuses::addInByStatus): Renamed from addInByIdStatus.
* bytecode/RecordedStatuses.h:
* bytecode/SetPrivateBrandStatus.cpp:
(JSC::SetPrivateBrandStatus::singleIdentifier const):
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::reset):
* bytecode/StructureStubInfo.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
(JSC::DFG::AbstractInterpreter<AbstractStateType>::filterICStatus):
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleInById):
(JSC::DFG::ByteCodeParser::parseBlock):
* 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/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::addInByVal):
* dfg/DFGMayExit.cpp:
* dfg/DFGNode.h:
(JSC::DFG::Node::hasInByStatus): Renamed from hasInByIdStatus.
(JSC::DFG::Node::inByStatus): Renamed from inByIdStatus.
* dfg/DFGNodeType.h:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileInByVal):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGVarargsForwardingPhase.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileInBy):
(JSC::FTL::DFG::LowerDFGToB3::compileInById):
(JSC::FTL::DFG::LowerDFGToB3::compileInByVal):
* jit/ICStats.h:
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
(JSC::JIT::link):
* jit/JIT.h:
* jit/JITInlineCacheGenerator.cpp:
(JSC::JITInByValGenerator::JITInByValGenerator):
(JSC::JITInByValGenerator::generateFastPath):
(JSC::JITInByValGenerator::finalize):
(JSC::JITInByIdGenerator::JITInByIdGenerator):
* jit/JITInlineCacheGenerator.h:
(JSC::JITDelByIdGenerator::slowPathJump const):
(JSC::JITInByValGenerator::JITInByValGenerator):
(JSC::JITInByValGenerator::slowPathJump const):
* jit/JITOperations.cpp:
(JSC::JSC_DEFINE_JIT_OPERATION):
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_in_by_val):
(JSC::JIT::emitSlow_op_in_by_val):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_in_by_val):
(JSC::JIT::emitSlow_op_in_by_val):
* jit/Repatch.cpp:
(JSC::tryCacheInBy): Renamed from tryCacheInByID.
(JSC::repatchInBy): Renamed from repatchInByID.
(JSC::resetInBy): Renamed from resetInByID.
* jit/Repatch.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
* runtime/CommonSlowPaths.cpp:
* runtime/CommonSlowPaths.h:
2021-06-03 Mark Lam <mark.lam@apple.com>
Fix an ASSERT in objectPrototypeHasOwnProperty() to account for TerminationException.
https://bugs.webkit.org/show_bug.cgi?id=226609
rdar://78465046
Reviewed by Robin Morisset.
* runtime/ObjectPrototype.cpp:
(JSC::objectPrototypeHasOwnProperty):
2021-06-03 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Make $vm's accessor test functions robust against primitive |this|
https://bugs.webkit.org/show_bug.cgi?id=226591
Reviewed by Saam Barati.
These functions are testing-purpose, and they are not robust against passing primitive as |this|.
This patch makes them robust so that we throw an error instead of crash.
* tools/JSDollarVM.cpp:
2021-06-03 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r278356.
https://bugs.webkit.org/show_bug.cgi?id=226606
"Breaks jsc tests".
Reverted changeset:
"Convert small JIT pool tests into executable fuzzing"
https://bugs.webkit.org/show_bug.cgi?id=226279
https://trac.webkit.org/changeset/278356
2021-06-03 Filip Pizlo <fpizlo@apple.com>
DFG should eliminate obvious store barriers
https://bugs.webkit.org/show_bug.cgi?id=226604
Reviewed by Mark Lam.
This has a couple changes:
- PutByOffset doesn't GC! So let's not say that it does.
- The store barrier clustering phase is no longer called the store barrier fencing phase in
dumps.
Small Speedometer2 speed-up. Definite speed-up for Elm.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGStoreBarrierClusteringPhase.cpp:
2021-06-03 Patrick Angle <pangle@apple.com>
Web Inspector: [Cocoa] `RemoteInspector` won't connect to a new relay if it hasn't yet failed to communicate with a previously connected relay
https://bugs.webkit.org/show_bug.cgi?id=226539
Reviewed by Devin Rousso.
`RemoteInspector` communicates with a relay daemon running on the same device in order to send updates like new
or removed inspectable targets and receive changes to settings like automatic debugging. The relay daemon then
communicates with a client that connects for debugging. Only one relay daemon should ever be running at a time,
and its lifecycle is managed separately from JavaScriptCore.
RemoteInspector holds a RefPtr to its connection to this relay, and only clears this pointer upon a failure to
communicate over the XPC connection or a known disconnection. However, it is possible, and in some cases likely
(for example the relay restarting from a brief client disconnection and reconnection), that we can be informed
of a newly launched relay being available while still thinking we are connected to the old relay, as we have not
yet sent a message and triggered a failure in the interim period of time.
To correct this we now send a simple message any time `setupXPCConnectionIfNeeded` is called if we have an
existing RefPtr to a relay connection in order to verify the connection is still functional. We now also retry
to connect to a relay upon failure in order to create a new connection to the current relay.
In order to prevent entering a retry loop where every subsequent retry's failure results in another retry
forever, a flag to retry connecting is set when a call to setupXPCConnectionIfNeeded is made while we already
have a RefPtr to a relay connection. On failure if we are in this special state we will retry once to connect
but subsequent failures will not automatically reattempt a connection.
* inspector/remote/RemoteInspector.h:
* inspector/remote/cocoa/RemoteInspectorCocoa.mm:
(Inspector::RemoteInspector::stopInternal):
- Clear the retry connection flag when stopping in an orderly fashion.
(Inspector::RemoteInspector::setupXPCConnectionIfNeeded):
- Set the retry connection flag and send a simple message if we already have a relay connection in order to make
sure the connection is either still valid or is torn down properly on failure.
(Inspector::RemoteInspector::xpcConnectionFailed):
- If the retry flag is set, schedule a retry and clear the retry flag.
2021-06-02 Robin Morisset <rmorisset@apple.com>
B3MoveConstants should filter directly on Values, and only create ValueKeys when useful
https://bugs.webkit.org/show_bug.cgi?id=226420
Reviewed by Phil Pizlo.
I did a few runs of JetStream2 to measure results, the time spent in B3MoveConstants goes from 160-180ms to 100-110ms.
The total time spent in B3+Air is in the 6 to 8s range, so this is approximately a 1% speedup.
* b3/B3MoveConstants.cpp:
2021-06-02 Robin Morisset <rmorisset@apple.com>
Merge B3::StackSlot and Air::StackSlot
https://bugs.webkit.org/show_bug.cgi?id=226362
Reviewed by Filip Pizlo.
This is a very simple and safe (although small) memory saving, since every B3StackSlot eventually becomes an AirStackSlot with an exact copy of all the same information.
Simply dropping the B3StackSlot past that point is tricky, because one of them might be retained by FTLState (and modified by Air).
It is much simpler to just use Air::StackSlot throughout. It saves us:
- 16 bytes per B3StackSlot (for the structure itself)
- another 8 bytes per B3StackSlot (for the pointer in the SparseCollection)
- 8 bytes per AirStackSlot (for the pointer to the B3::StackSlot)
I also took the opportunity to save an extra 8 bytes per AirStackSlot, by shrinking the bytesize field to a uint16_t (with a RELEASE_ASSERT that we never overflow it) and moving the StackSlotKind in the hole this creates.
Total savings: 16 bytes per spill slot and 40 bytes per locked (by B3) slot.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* b3/B3LowerToAir.cpp:
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::addStackSlot):
(JSC::B3::Procedure::dump const):
* b3/B3Procedure.h:
* b3/B3ProcedureInlines.h:
(JSC::B3::Procedure::stackSlots):
(JSC::B3::Procedure::stackSlots const):
* b3/B3SlotBaseValue.cpp:
* b3/B3SlotBaseValue.h:
* b3/B3StackSlot.cpp: Removed.
* b3/B3StackSlot.h: Removed.
* b3/B3Value.cpp:
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::addStackSlot):
* b3/air/AirCode.h:
* b3/air/AirStackSlot.cpp:
(JSC::B3::Air::StackSlot::setOffsetFromFP):
(JSC::B3::Air::StackSlot::deepDump const):
(JSC::B3::Air::StackSlot::StackSlot):
* b3/air/AirStackSlot.h:
(JSC::B3::Air::StackSlot::ensureSize):
* b3/testb3.h:
* ftl/FTLCompile.cpp:
* ftl/FTLState.h:
2021-06-02 Pablo Saavedra <psaavedra@igalia.com>
Fix build error with ENABLE_DFG_JIT=OFF
https://bugs.webkit.org/show_bug.cgi?id=226550
Reviewed by Mark Lam.
* jit/JITPlan.cpp:
(JSC::JITPlan::compileInThread):
2021-06-02 Robin Morisset <rmorisset@apple.com>
We should drop B3 values while running Air
https://bugs.webkit.org/show_bug.cgi?id=226187
Reviewed by Saam Barati.
We must keep the following values:
- WasmBoundsCheck, to know whether it is Pinned or Maximum, and if it is pinned find its argument.
- CCall/Patch/Check/CheckAdd/CheckSub/CheckMul and all of their children, because all of these are lowered to Air::Patchpoint, which needs to know the type of its arguments, and does so by looking at the children of its origin.
I intend to fix these in later patches if possible.
Finally we must preserve all B3 values in the following cases:
- if we dump the disassembly or the Air graph: because otherwise we cannot print the origins
- if we are using the sampling profiler, because it relies on PCToCodeOriginMap which we cannot accurately fill without these origins.
We must also keep m_tuples alive, as it is used by Patchpoints in Air to understand the types of their arguments.
We also don't touch StackSlots (in this patch), because one of them is captured by FTL::State.
Also now PCToOriginMap has a Vector with no inline capacity, since it is either quite large (if needed) or empty (otherwise).
The performance impact of this is a progression on various RAMification subtests on Mac, but is more mitigated on iPhone7, with various regressions.
I suspect these to be noise, and will monitor the performance bots post-landing to make sure of it.
* b3/B3LowerToAir.cpp:
(JSC::B3::lowerToAir):
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::freeUnneededB3ValuesAfterLowering):
* b3/B3Procedure.h:
(JSC::B3::Procedure::releasePCToOriginMap):
(JSC::B3::Procedure::setNeedsPCToOriginMap):
(JSC::B3::Procedure::needsPCToOriginMap):
* b3/B3SparseCollection.h:
(JSC::B3::SparseCollection::clearAll):
(JSC::B3::SparseCollection::filterAndTransfer):
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::Code):
* b3/air/AirCode.h:
(JSC::B3::Air::Code::shouldPreserveB3Origins const):
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::generateWithAlreadyAllocatedRegisters):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLState.cpp:
(JSC::FTL::State::State):
2021-06-02 Chris Dumez <cdumez@apple.com>
Drop Checked::safeGet()
https://bugs.webkit.org/show_bug.cgi?id=226537
Reviewed by Geoffrey Garen.
Drop Checked::safeGet() and replace with uses of Checked::operator T() or Checked::value().
safeGet() is a bit akward, having both a return value and an out-parameter.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* runtime/JSArray.cpp:
(JSC::JSArray::appendMemcpy):
(JSC::JSArray::unshiftCountWithAnyIndexingType):
* runtime/JSStringJoiner.cpp:
(JSC::JSStringJoiner::joinedLength const):
* wasm/WasmFormat.cpp:
(JSC::Wasm::Segment::create):
* wasm/WasmOperations.cpp:
(JSC::Wasm::JSC_DEFINE_JIT_OPERATION):
* wasm/WasmTable.cpp:
(JSC::Wasm::Table::grow):
2021-06-02 Keith Miller <keith_miller@apple.com>
Add globalObject API set property test
https://bugs.webkit.org/show_bug.cgi?id=226542
<rdar://78287979>
Reviewed by Alexey Shvayka.
* API/tests/testapi.cpp:
(TestAPI::testJSObjectSetOnGlobalObjectSubclassDefinition):
(testCAPIViaCpp):
2021-06-02 Keith Miller <keith_miller@apple.com>
Convert small JIT pool tests into executable fuzzing
https://bugs.webkit.org/show_bug.cgi?id=226279
Right now, we try to test our engine on a small JIT pool. This isn't a known configuration for any
actual ports and causes issues if we run out of JIT memory when we need to compile an OSR exit.
Instead of testing such a small pool we should just fuzz each executable allocation that says it
can fail.
The current fuzzing doesn't do a good job tracking the number of DFG/FTL compiles when allocations
fail, so when enabled those tests will just exit early. Also, right now we use a random seed picked
by the engine for these tests, which makes it hard to reproduce crashes on the bots. If we see
flakiness on the bots we can have the harness pass in a number so it gets logged in the repro command.
Reviewed by Michael Saboff.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::numberOfDFGCompiles):
* jit/ExecutableAllocationFuzz.cpp:
(JSC::doExecutableAllocationFuzzing):
* jsc.cpp:
(runJSC):
2021-06-02 Chris Dumez <cdumez@apple.com>
Use Checked aliases instead of Checked<T, RecordOverflow>
https://bugs.webkit.org/show_bug.cgi?id=226535
Reviewed by Keith Miller.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* ftl/FTLOperations.cpp:
(JSC::FTL::JSC_DEFINE_JIT_OPERATION):
* runtime/JSArray.cpp:
(JSC::JSArray::appendMemcpy):
(JSC::JSArray::unshiftCountWithAnyIndexingType):
* runtime/JSStringJoiner.cpp:
(JSC::JSStringJoiner::joinedLength const):
* runtime/JSStringJoiner.h:
* runtime/StringPrototype.cpp:
(JSC::jsSpliceSubstringsWithSeparators):
* wasm/WasmFormat.cpp:
(JSC::Wasm::Segment::create):
* wasm/WasmOperations.cpp:
(JSC::Wasm::JSC_DEFINE_JIT_OPERATION):
* wasm/WasmTable.cpp:
(JSC::Wasm::Table::grow):
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::ByteCompiler::emitDisjunction):
* yarr/YarrParser.h:
(JSC::Yarr::Parser::consumeNumber):
* yarr/YarrPattern.cpp:
2021-06-01 Darin Adler <darin@apple.com>
Remove <wtf/Optional.h>
https://bugs.webkit.org/show_bug.cgi?id=226437
Reviewed by Chris Dumez.
* <many files>: Remove include of <wtf/Optional.h>.
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
(CppBackendDispatcherHeaderGenerator._generate_secondary_header_includes): Don't generate
an include of wtf/Optional.h; including WTFString.h takes care of this anyway.
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
(CppFrontendDispatcherHeaderGenerator._generate_secondary_header_includes): Ditto.
* inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
(CppProtocolTypesHeaderGenerator._generate_secondary_header_includes): Ditto.
* inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
(CppProtocolTypesImplementationGenerator.generate_output): Generate an include of <optional>
instead of <wtf/Optional.h>.
* inspector/scripts/tests/expected/*: Regenerate.
2021-06-01 Chris Dumez <cdumez@apple.com>
Rename Checked::unsafeGet() to Checked::value()
https://bugs.webkit.org/show_bug.cgi?id=226514
Reviewed by Darin Adler.
Rename Checked::unsafeGet() to Checked::value(). The "unsafeGet" naming is confusing as this
function isn't really unsafe since it will crash if the value has overflowed. Also add an
`operator T()` to implicitly convert a Checked to its underlying type without needing to
call value().
* b3/B3Const32Value.cpp:
(JSC::B3::Const32Value::checkAddConstant const):
(JSC::B3::Const32Value::checkSubConstant const):
(JSC::B3::Const32Value::checkMulConstant const):
* b3/B3Const64Value.cpp:
(JSC::B3::Const64Value::checkAddConstant const):
(JSC::B3::Const64Value::checkSubConstant const):
(JSC::B3::Const64Value::checkMulConstant const):
* bytecompiler/BytecodeGenerator.h:
(JSC::FinallyContext::numberOfBreaksOrContinues const):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargsWithSpread):
* ftl/FTLOperations.cpp:
(JSC::FTL::JSC_DEFINE_JIT_OPERATION):
* heap/Heap.cpp:
(JSC::Heap::deprecatedReportExtraMemorySlowCase):
(JSC::Heap::extraMemorySize):
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::reportExtraMemoryVisited):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::propagateExternalMemoryVisitedIfNecessary):
* runtime/ArgList.cpp:
(JSC::MarkedArgumentBuffer::slowEnsureCapacity):
(JSC::MarkedArgumentBuffer::expandCapacity):
* runtime/ArrayPrototype.cpp:
(JSC::concatAppendOne):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/CommonSlowPaths.cpp:
(JSC::JSC_DEFINE_COMMON_SLOW_PATH):
* runtime/DirectArguments.h:
* runtime/HashMapImpl.h:
(JSC::HashMapBuffer::allocationSize):
(JSC::HashMapImpl::HashMapImpl):
* runtime/HashMapImplInlines.h:
(JSC::nextCapacity):
(JSC::HashMapImpl<HashMapBucketType>::finishCreation):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::parseInt):
* runtime/JSImmutableButterfly.h:
(JSC::JSImmutableButterfly::tryCreate):
* runtime/JSLexicalEnvironment.h:
(JSC::JSLexicalEnvironment::offsetOfVariable):
(JSC::JSLexicalEnvironment::allocationSizeForScopeSize):
* runtime/JSObject.h:
* runtime/JSPropertyNameEnumerator.cpp:
(JSC::JSPropertyNameEnumerator::create):
* runtime/JSString.h:
* runtime/ScopedArguments.cpp:
(JSC::ScopedArguments::createUninitialized):
* runtime/StringPrototype.cpp:
(JSC::jsSpliceSubstrings):
(JSC::jsSpliceSubstringsWithSeparators):
* runtime/StructureChain.cpp:
(JSC::StructureChain::create):
* runtime/VM.h:
(JSC::ScratchBuffer::allocationSize):
* runtime/WeakMapImpl.h:
(JSC::WeakMapBuffer::allocationSize):
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::AirIRGenerator):
(JSC::Wasm::AirIRGenerator::emitCallPatchpoint):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
* wasm/WasmInstance.cpp:
* wasm/WasmInstance.h:
(JSC::Wasm::Instance::allocationSize):
* wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::LLIntGenerator::push):
(JSC::Wasm::LLIntGenerator::getDropKeepCount):
(JSC::Wasm::LLIntGenerator::walkExpressionStack):
(JSC::Wasm::LLIntGenerator::finalize):
(JSC::Wasm::LLIntGenerator::callInformationForCaller):
(JSC::Wasm::LLIntGenerator::addLoop):
(JSC::Wasm::LLIntGenerator::addTopLevel):
(JSC::Wasm::LLIntGenerator::addBlock):
(JSC::Wasm::LLIntGenerator::addIf):
(JSC::Wasm::LLIntGenerator::addElseToUnreachable):
* wasm/WasmSignature.h:
(JSC::Wasm::Signature::allocatedSize):
* wasm/WasmStreamingParser.cpp:
(JSC::Wasm::StreamingParser::addBytes):
* wasm/WasmTable.cpp:
(JSC::Wasm::Table::Table):
(JSC::Wasm::Table::grow):
(JSC::Wasm::FuncRefTable::FuncRefTable):
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::Interpreter::DisjunctionContext::allocationSize):
(JSC::Yarr::Interpreter::ParenthesesDisjunctionContext::allocationSize):
(JSC::Yarr::Interpreter::allocParenthesesDisjunctionContext):
(JSC::Yarr::ByteCompiler::atomCharacterClass):
(JSC::Yarr::ByteCompiler::atomBackReference):
(JSC::Yarr::ByteCompiler::atomParentheticalAssertionEnd):
(JSC::Yarr::ByteCompiler::atomParenthesesSubpatternEnd):
(JSC::Yarr::ByteCompiler::atomParenthesesOnceEnd):
(JSC::Yarr::ByteCompiler::atomParenthesesTerminalEnd):
(JSC::Yarr::ByteCompiler::emitDisjunction):
* yarr/YarrInterpreter.h:
(JSC::Yarr::ByteTerm::ByteTerm):
(JSC::Yarr::ByteTerm::CheckInput):
(JSC::Yarr::ByteTerm::UncheckInput):
* yarr/YarrJIT.cpp:
* yarr/YarrParser.h:
(JSC::Yarr::Parser::consumeNumber):
* yarr/YarrPattern.cpp:
(JSC::Yarr::PatternTerm::dumpQuantifier):
2021-06-01 Adrian Perez de Castro <aperez@igalia.com>
[WPE][GTK] Support building against uClibc
https://bugs.webkit.org/show_bug.cgi?id=226244
Reviewed by Michael Catanzaro.
* assembler/MacroAssemblerARM64.cpp:
(getauxval): Provide a fallback implementation of getauxval() for
systems which do not provide <sys/auxv.h>, like those using uClibc
as their C library.
2021-05-30 Chris Dumez <cdumez@apple.com>
Drop UncheckedCondition / UncheckedLock
https://bugs.webkit.org/show_bug.cgi?id=226432
Reviewed by Darin Adler.
Drop one remaining use of UncheckedLock in favor of Lock.
* jit/JITSafepoint.cpp:
* jit/JITWorklistThread.h:
2021-05-30 Darin Adler <darin@apple.com>
Remove WTF::Optional synonym for std::optional, using that class template directly instead
https://bugs.webkit.org/show_bug.cgi?id=226433
Reviewed by Chris Dumez.
* <many files>: Let the do-webcore-rename script rename Optional<> to std::optional<>.
* inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
(ObjCProtocolTypesImplementationGenerator._generate_init_method_for_payload): Use auto instead
of Optional<>. Also use * instead of value() and nest the definition of the local inside an if
statement in the case where it's an optional.
* inspector/scripts/tests/expected/*: Regenerated these results.
2021-05-29 Chris Dumez <cdumez@apple.com>
Stop using UncheckedLock in JSC::VMInspector
https://bugs.webkit.org/show_bug.cgi?id=226427
Reviewed by Mark Lam.
Stop using UncheckedLock in JSC::VMInspector, as it is being phased out in favor
of Lock, which supports Clang thread safety analysis.
* tools/HeapVerifier.cpp:
(JSC::HeapVerifier::checkIfRecorded):
* tools/SigillCrashAnalyzer.cpp:
(JSC::SigillCrashAnalyzer::analyze):
* tools/VMInspector.cpp:
(JSC::VMInspector::isValidExecutableMemory):
(JSC::VMInspector::codeBlockForMachinePC):
(JSC::VMInspector::lock): Deleted.
* tools/VMInspector.h:
(JSC::VMInspector::WTF_RETURNS_LOCK):
(JSC::VMInspector::WTF_REQUIRES_LOCK):
(JSC::VMInspector::getLock): Deleted.
(JSC::VMInspector::iterate): Deleted.
2021-05-29 Chris Dumez <cdumez@apple.com>
Stop using UncheckedLock in JSC::ConcurrentJSLock
https://bugs.webkit.org/show_bug.cgi?id=226428
Reviewed by Darin Adler.
Stop using UncheckedLock in JSC::ConcurrentJSLock as it is being phased out in
favor of Lock, which supports Clang thread safety analysis.
* runtime/ConcurrentJSLock.h:
(JSC::ConcurrentJSLockerBase::ConcurrentJSLockerBase):
* runtime/Structure.cpp:
(JSC::Structure::findStructuresAndMapForMaterialization):
(JSC::Structure::materializePropertyTable):
* runtime/Structure.h:
* runtime/StructureInlines.h:
(JSC::Structure::forEachPropertyConcurrently):
* yarr/YarrInterpreter.cpp:
2021-05-28 Darin Adler <darin@apple.com>
Clients of optional should use has_value instead of relying on hasValue macro
https://bugs.webkit.org/show_bug.cgi?id=226395
Reviewed by Chris Dumez.
* bytecompiler/NodesCodegen.cpp:
(JSC::RegExpNode::emitBytecode): Don't use hasValue.
2021-05-29 Chris Dumez <cdumez@apple.com>
Stop using UncheckedLock in JSC::SamplingProfiler
https://bugs.webkit.org/show_bug.cgi?id=226414
Reviewed by Darin Adler.
Stop using UncheckedLock in JSC::SamplingProfiler as it is being phased out in favor of Lock,
which supports clang thread safety analysis.
* heap/Heap.cpp:
(JSC::visitSamplingProfiler):
* inspector/agents/InspectorScriptProfilerAgent.cpp:
(Inspector::InspectorScriptProfilerAgent::startTracking):
(Inspector::InspectorScriptProfilerAgent::trackingComplete):
(Inspector::InspectorScriptProfilerAgent::stopSamplingWhenDisconnecting):
* runtime/JSGlobalObject.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::createThreadIfNecessary):
(JSC::SamplingProfiler::timerLoop):
(JSC::SamplingProfiler::takeSample):
(JSC::SamplingProfiler::processUnverifiedStackTraces):
(JSC::SamplingProfiler::start):
(JSC::SamplingProfiler::startWithLock):
(JSC::SamplingProfiler::pause):
(JSC::SamplingProfiler::noticeCurrentThreadAsJSCExecutionThreadWithLock):
(JSC::SamplingProfiler::noticeCurrentThreadAsJSCExecutionThread):
(JSC::SamplingProfiler::noticeJSLockAcquisition):
(JSC::SamplingProfiler::noticeVMEntry):
(JSC::SamplingProfiler::clearData):
(JSC::SamplingProfiler::releaseStackTraces):
(JSC::SamplingProfiler::stackTracesAsJSON):
(JSC::SamplingProfiler::reportTopFunctions):
(JSC::SamplingProfiler::reportTopBytecodes):
* runtime/SamplingProfiler.h:
(JSC::SamplingProfiler::WTF_RETURNS_LOCK):
(JSC::SamplingProfiler::WTF_REQUIRES_LOCK):
2021-05-29 Chris Dumez <cdumez@apple.com>
Stop using UncheckedLock in JSC::dumpJITMemory()
https://bugs.webkit.org/show_bug.cgi?id=226413
Reviewed by Darin Adler.
Stop using UncheckedLock in JSC::dumpJITMemory() as it is being phased out in favor of Lock,
which supports Clang thread safety analysis.
* jit/ExecutableAllocator.cpp:
(JSC::dumpJITMemory):
2021-05-29 Chris Dumez <cdumez@apple.com>
Stop using UncheckedLock in JSC::WasmCalleeRegistry
https://bugs.webkit.org/show_bug.cgi?id=226412
Reviewed by Darin Adler.
Stop using UncheckedLock in JSC::WasmCalleeRegistry, as it is being phased out in favor of
Lock, which supports Clang thread safety analysis.
* runtime/SamplingProfiler.cpp:
(JSC::FrameWalker::FrameWalker):
(JSC::FrameWalker::recordJITFrame):
(JSC::CFrameWalker::CFrameWalker):
(JSC::SamplingProfiler::takeSample):
* wasm/WasmCalleeRegistry.h:
(JSC::Wasm::CalleeRegistry::WTF_RETURNS_LOCK):
(JSC::Wasm::CalleeRegistry::WTF_REQUIRES_LOCK):
(JSC::Wasm::CalleeRegistry::getLock): Deleted.
(JSC::Wasm::CalleeRegistry::isValidCallee): Deleted.
* wasm/WasmFaultSignalHandler.cpp:
(JSC::Wasm::trapHandler):
2021-05-29 Mark Lam <mark.lam@apple.com>
VM::isTerminationException() should only be run on a non-null exception value.
https://bugs.webkit.org/show_bug.cgi?id=226417
rdar://78646170
Reviewed by Filip Pizlo.
* jsc.cpp:
(runInteractive):
2021-05-29 Adrian Perez de Castro <aperez@igalia.com>
Non-unified build fixes, late-ish May 2021 edition redux
https://bugs.webkit.org/show_bug.cgi?id=226401
Unreviewed non-unified build fixes.
* jit/JITSizeStatistics.cpp: Add missing LinkBuffer.h header.
* jit/JITSizeStatistics.h: Add missing CCallHelpers.h and wtf/text/WTFString.h headers;
remove unneeded CCallHelpers forward declaration.
2021-05-28 Chris Dumez <cdumez@apple.com>
Stop using UncheckedLock in WTF::MetaAllocator
https://bugs.webkit.org/show_bug.cgi?id=226396
Reviewed by Darin Adler.
Stop using UncheckedLock in WTF::MetaAllocator, as it is being phased out in favor on Lock,
which supports Clang thread safety analysis.
* jit/ExecutableAllocator.cpp:
(JSC::ExecutableAllocator::getLock const):
* jit/ExecutableAllocator.h:
(JSC::ExecutableAllocatorBase::WTF_RETURNS_LOCK):
* tools/VMInspector.cpp:
(JSC::VMInspector::isValidExecutableMemory):
2021-05-28 Chris Dumez <cdumez@apple.com>
Stop using UncheckedLock in JSDOMGlobalObject
https://bugs.webkit.org/show_bug.cgi?id=226281
Reviewed by Darin Adler.
Drop JSC::lockDuringMarking() and its now empty header given that it does conditional
locking and it is not compatible with Clang thread safety analysis.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/UnlinkedCodeBlock.h:
* heap/LockDuringMarking.h: Removed.
2021-05-28 Saam Barati <sbarati@apple.com>
Add the ability to dump statistics about cumulative counts and code sizes of Baseline JIT opcodes and DFG nodes
https://bugs.webkit.org/show_bug.cgi?id=226200
Reviewed by Robin Morisset.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* dfg/DFGSlowPathGenerator.h:
(JSC::DFG::SlowPathGenerator::currentNode const):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
(JSC::DFG::SpeculativeJIT::compileCurrentBlock):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
(JSC::JIT::compileAndLinkWithoutFinalizing):
* jit/JITSizeStatistics.cpp: Added.
(JSC::JITSizeStatistics::markStart):
(JSC::JITSizeStatistics::markEnd):
(JSC::JITSizeStatistics::dump const):
* jit/JITSizeStatistics.h: Added.
(JSC::JITSizeStatistics::reset):
* jsc.cpp:
(runJSC):
* runtime/OptionsList.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
* tools/JSDollarVM.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::JSDollarVM::finishCreation):
2021-05-28 Saam Barati <sbarati@apple.com>
Don't sink arguments past the context of the inline call frame they were created in
https://bugs.webkit.org/show_bug.cgi?id=226363
<rdar://78392801>
Reviewed by Filip Pizlo.
DFG OSR exit isn't set up to allow materializing phantom arguments objects
when the inline call frame is no longer present in the exit metadata. There
may be multiple reasons for this, but there's at least one I discovered:
We don't analyze any locals when reconstructing the variable event stream
if that local is past the extent of the inline call frame.
This patch makes it so we treat it as an escape if between the definition and
the last use of a sink candidate (either via an IR use or bytecode liveness)
there is an exit to a place in the graph where the inline call frame of the
definition is no longer present.
* dfg/DFGVarargsForwardingPhase.cpp:
2021-05-28 Stephan Szabo <stephan.szabo@sony.com>
Regenerate builtins generator expectations after optional changes
https://bugs.webkit.org/show_bug.cgi?id=226381
Reviewed by Chris Dumez.
* 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:
2021-05-28 Mark Lam <mark.lam@apple.com>
The jsc shell should not continue executing after a termination has been received.
https://bugs.webkit.org/show_bug.cgi?id=226368
rdar://78013374
Reviewed by Saam Barati.
This patch makes the jsc shell forbid execution in all the places that it has
caught and seen a TerminationException.
* jsc.cpp:
(JSC_DEFINE_HOST_FUNCTION):
(checkException):
(runWithOptions):
(runInteractive):
2021-05-27 Robin Morisset <rmorisset@apple.com>
AirAllocateStackByGraphColoring should use the optimized interference graphs from AirAllocateRegistersByGraphColoring
https://bugs.webkit.org/show_bug.cgi?id=226258
Reviewed by Phil Pizlo.
The main change in this patch is that AirAllocateStackByGraphColoring is now using the optimized datastructures in wtf/InterferenceGraph.h.
This required templating most of it over the interference graph used (Small/Large/Huge), but I tried keeping some common parts out of the templated class to minimize the impact on compile times and binary size.
A consequence of that change is that coalescableMoves and remappedStackSlots now store indices instead of direct pointers to StackSlots, resulting in a memory reduction of about 3x as well.
Another consequence is that I had to slightly alter the way that coalescing works: instead of carefully removing the interference edges of the killed slot, we simply use mayClear() which is not guaranteed to remove anything.
I believe that this is sound, because every subsequent access to m_interference checks whether a slot has been coalesced first, so dropping these edges is purely a memory saving, but has no logical effect.
The new code was tested in a few ways:
- running on JetStream2 with asan
- running on JetStream2 with TEST_OPTIMIZED_INTERFERENCE_GRAPH
- running on JetStream2 and logging the frame sizes at the end of this phase, and comparing to the results of doing the same on ToT (same average frame size)
The two functions where this code had the largest memory footprint in JetStream2 were both in tsf-wasm.
One has 751 stack slots, and had an interference graph of 2.1MB and a coalescableMoves vector of 440kB
The other has 673 stack slots, and had an interference graph of 1.9MB and a coalescableMoves vector of 421kB.
With this patch, they respectively use 79kB+146kB and 67kB+140kB
The effect on the rest of JetStream2 is less likely to matter as few functions used more than a few dozens of kB in this phase, but in percentages are just as huge.
More importantly (and the reason I wrote this patch in the first place), I checked mruby-wasm.aotoki.dev which with a few other pages forced us to lower Options::maximumTmpsForGraphColoring because of jetsams.
It has two massive functions that reach this phase if I increase Options::maximumTmpsForGraphColoring:
- about 6k stack slots -> 215MB + 6MB (interference graph + coalescableMoves)
- about 9k stack slots -> 395MB + 4MB
After this patch, they respectively use 4.5MB+2MB and 9MB+1.5MB, or roughly a 40x improvement.
Combined with the recent improvements to the register allocator, I hope to be able to increase Options::maximumTmpsForGraphColoring soon (in a different patch for easier bisection if either cause a perf regression).
This would be helpful, since its lowering cratered our performance on some other wasm application by 8x.
In terms of compile times, this patch lowered the time spent in AllocateStackByGraphColoring over the course of a run of JetStream2 from roughly 350ms to roughly 270ms.
This is almost certainly negligible, but at least it guarantees that it did not regress.
* b3/air/AirAllocateRegistersByGraphColoring.cpp:
* b3/air/AirAllocateStackByGraphColoring.cpp:
(JSC::B3::Air::allocateStackByGraphColoring):
2021-05-27 Darin Adler <darin@apple.com>
Next step toward using std::optional directly instead of through WTF::Optional typedef
https://bugs.webkit.org/show_bug.cgi?id=226280
Reviewed by Chris Dumez.
* <many files>: Accept the renaming done by do-webcore-rename.
* yarr/YarrSyntaxChecker.cpp: Since the style checker complained about this file,
tweaked style to make it happy after the renaming done by do-webcore-rename, and
also hand-updated Optional to std::optional as long as we were touching it.
2021-05-27 Adrian Perez de Castro <aperez@igalia.com>
Non-unified build fixes, late May 2021 edition
https://bugs.webkit.org/show_bug.cgi?id=226322
Unreviewed non-unified build fixes.
* jit/JITPlan.cpp: Add missing HeapInlines.h and VMInlines.h headers.
* jit/JITWorklist.cpp: Add missing HeapInlines.h and SlotVisitorInlines.h headers,
remove SlotVisitor.h which is now unneeded.
* jit/JITWorklistThread.cpp: Add missing HeapInlines.h header.
2021-05-27 Daniel Kolesa <dkolesa@igalia.com>
[JSC] Fix crash on 32-bit big endian systems.
https://bugs.webkit.org/show_bug.cgi?id=226264
Reviewed by Caio Araujo Neponoceno de Lima.
This is an instance where properly offsetting was missed since
the issue was not present in 2.30 series and therefore not fixed
by r273104.
* llint/LowLevelInterpreter32_64.asm:
2021-05-26 Chris Dumez <cdumez@apple.com>
Leverage the new Vector(const T*, size_t) constructor
https://bugs.webkit.org/show_bug.cgi?id=226304
Reviewed by Darin Adler.
Leverage the new Vector(const T*, size_t) constructor in existing code.
* wasm/WasmStreamingParser.cpp:
(JSC::Wasm::StreamingParser::consume):
2021-05-26 Tadeu Zagallo <tzagallo@apple.com>
REGRESSION: ASSERTION FAILED: !isCompilationThread() in JSC::Profiler::Database::addCompilation()
https://bugs.webkit.org/show_bug.cgi?id=226302
<rdar://78537378>
Reviewed by Saam Barati.
We started linking the JIT code in the compiler thread, which now triggers this assertion.
The assertion was introduce before a lock was held to modify the data structures in the
profiler database, but it's safe to remove it now.
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::addCompilation):
2021-05-26 Chris Dumez <cdumez@apple.com>
Use UncheckedLock even less in JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=226278
Reviewed by Darin Adler.
Use UncheckedLock even less in JavaScriptCore as it is being phased out in
favor of Lock, which supports Clang thread safety analysis.
* heap/BlockDirectory.h:
(JSC::BlockDirectory::WTF_RETURNS_LOCK):
* heap/CodeBlockSet.h:
(JSC::CodeBlockSet::WTF_RETURNS_LOCK):
* heap/Heap.h:
* heap/MarkedSpace.h:
(JSC::MarkedSpace::directoryLock):
* heap/MarkingConstraintSolver.h:
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::donateKnownParallel):
* heap/SlotVisitor.h:
* jit/JITWorklist.cpp:
* jit/JITWorklist.h:
* jsc.cpp:
* profiler/ProfilerDatabase.h:
* runtime/DeferredWorkTimer.h:
* runtime/VMTraps.cpp:
(JSC::VMTraps::invalidateCodeBlocksOnStack):
* runtime/VMTraps.h:
* tools/FunctionOverrides.cpp:
(JSC::FunctionOverrides::FunctionOverrides):
(JSC::FunctionOverrides::reinstallOverrides):
(JSC::FunctionOverrides::parseOverridesInFile):
* tools/FunctionOverrides.h:
(JSC::FunctionOverrides::WTF_REQUIRES_LOCK):
* tools/VMInspector.cpp:
(JSC::ensureIsSafeToLock):
(JSC::VMInspector::codeBlockForMachinePC):
* wasm/WasmBBQPlan.cpp:
(JSC::Wasm::BBQPlan::work):
(JSC::Wasm::BBQPlan::compileFunction):
(JSC::Wasm::BBQPlan::didCompleteCompilation):
* wasm/WasmBBQPlan.h:
* wasm/WasmEntryPlan.cpp:
(JSC::Wasm::EntryPlan::parseAndValidateModule):
(JSC::Wasm::EntryPlan::prepare):
(JSC::Wasm::EntryPlan::ThreadCountHolder::~ThreadCountHolder):
(JSC::Wasm::EntryPlan::complete):
* wasm/WasmEntryPlan.h:
(JSC::Wasm::EntryPlan::tryReserveCapacity):
* wasm/WasmLLIntPlan.cpp:
(JSC::Wasm::LLIntPlan::compileFunction):
(JSC::Wasm::LLIntPlan::didCompleteCompilation):
(JSC::Wasm::LLIntPlan::completeInStreaming):
(JSC::Wasm::LLIntPlan::didFailInStreaming):
* wasm/WasmLLIntPlan.h:
* wasm/WasmOMGForOSREntryPlan.cpp:
(JSC::Wasm::OMGForOSREntryPlan::work):
* wasm/WasmOMGForOSREntryPlan.h:
* wasm/WasmOMGPlan.cpp:
(JSC::Wasm::OMGPlan::work):
* wasm/WasmOMGPlan.h:
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::runCompletionTasks):
(JSC::Wasm::Plan::tryRemoveContextAndCancelIfLast):
(JSC::Wasm::Plan::fail):
* wasm/WasmPlan.h:
* wasm/WasmStreamingCompiler.cpp:
(JSC::Wasm::StreamingCompiler::didCompileFunction):
(JSC::Wasm::StreamingCompiler::completeIfNecessary):
(JSC::Wasm::StreamingCompiler::didComplete):
(JSC::Wasm::StreamingCompiler::finalize):
* wasm/WasmStreamingCompiler.h:
* wasm/WasmStreamingPlan.cpp:
(JSC::Wasm::StreamingPlan::work):
* wasm/WasmStreamingPlan.h:
* wasm/WasmThunks.h:
2021-05-26 Chris Dumez <cdumez@apple.com>
Stop using UncheckedLock in WTF::AutomaticThread
https://bugs.webkit.org/show_bug.cgi?id=226255
Reviewed by Keith Miller.
Some code in JSC had to be ported from UncheckedLock to Lock as a result of
WTF::AutomaticThread using the Lock type.
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::Worklist):
* dfg/DFGWorklist.h:
* heap/Heap.cpp:
(JSC::Heap::Heap):
* heap/Heap.h:
* jit/JITWorklist.cpp:
(JSC::JITWorklist::JITWorklist):
* jit/JITWorklist.h:
* runtime/VMTraps.cpp:
(JSC::VMTraps::VMTraps):
* runtime/VMTraps.h:
* wasm/WasmWorklist.cpp:
(JSC::Wasm::Worklist::Worklist):
* wasm/WasmWorklist.h:
2021-05-26 Tadeu Zagallo <tzagallo@apple.com>
Merge all the JIT worklists into a shared worklist
https://bugs.webkit.org/show_bug.cgi?id=226207
Reviewed by Saam Barati.
Delete the DFG and FTL worklists and refactor JITWorklist to handle the compilation
for all tiers. This reduces the total number of compiler threads while allowing each
tier to use more threads whenever necessary. The default configuration is for the
worklist to have 3 threads, baseline can use up to all 3 threads and DFG and FTL follow
the previous limits set through JSC::Options. Right now, the worklist will only do work
on upper tiers when all lower tiers have no pending tasks or have exceeded the maximum
number of concurrent compilations. i.e. by default we only DFG compile when there are
no baseline tasks in the queue and we only FTL compile when we either have no DFG tasks
in the queue OR there are already 2 DFG compilations in progress.
* API/JSVirtualMachine.mm:
(+[JSVirtualMachine setNumberOfDFGCompilerThreads:]):
(+[JSVirtualMachine setNumberOfFTLCompilerThreads:]):
* API/tests/testapi.mm:
(runJITThreadLimitTests):
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::checkIfOptimizationThresholdReached):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCommon.h:
(JSC::DFG::verboseCompilationEnabled):
(JSC::DFG::logCompilationChanges):
(JSC::DFG::shouldDumpGraphAtEachPhase):
(JSC::DFG::shouldDumpDisassembly):
* dfg/DFGDriver.cpp:
(JSC::DFG::compileImpl):
(JSC::DFG::compile):
* dfg/DFGDriver.h:
* dfg/DFGGraph.h:
* dfg/DFGGraphSafepoint.h:
* dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
(JSC::DFG::OSRAvailabilityAnalysisPhase::run):
* dfg/DFGOSREntrypointCreationPhase.cpp:
(JSC::DFG::OSREntrypointCreationPhase::run):
* dfg/DFGOperations.cpp:
(JSC::DFG::triggerFTLReplacementCompile):
(JSC::DFG::tierUpCommon):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::Plan):
(JSC::DFG::Plan::codeSize const):
(JSC::DFG::Plan::finalizeInGC):
(JSC::DFG::Plan::notifyReady):
(JSC::DFG::Plan::cancel):
(JSC::DFG::Plan::compileInThreadImpl):
(JSC::DFG::Plan::finalize):
(JSC::DFG::Plan::iterateCodeBlocksForGC):
(JSC::DFG::Plan::checkLivenessAndVisitChildren):
(JSC::DFG::Plan::isKnownToBeLiveDuringGC):
(JSC::DFG::Plan::isKnownToBeLiveAfterGC):
* dfg/DFGPlan.h:
* dfg/DFGPlanInlines.h: Removed.
* dfg/DFGTierUpCheckInjectionPhase.cpp:
(JSC::DFG::TierUpCheckInjectionPhase::run):
* dfg/DFGWorklist.cpp: Removed.
* dfg/DFGWorklist.h: Removed.
* dfg/DFGWorklistInlines.h: Removed.
* ftl/FTLCompile.h:
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::lower):
(JSC::FTL::DFG::LowerDFGToB3::buildExitArguments):
* ftl/FTLState.cpp:
(JSC::FTL::State::State):
* ftl/FTLState.h:
(JSC::FTL::verboseCompilationEnabled):
(JSC::FTL::shouldDumpDisassembly):
* heap/Heap.cpp:
(JSC::Heap::completeAllJITPlans):
(JSC::Heap::iterateExecutingAndCompilingCodeBlocks):
(JSC::Heap::removeDeadCompilerWorklistEntries):
(JSC::Heap::stopThePeriphery):
(JSC::Heap::suspendCompilerThreads):
(JSC::Heap::resumeCompilerThreads):
(JSC::Heap::addCoreConstraints):
* heap/Heap.h:
* heap/RootMarkReason.h:
* jit/JIT.cpp:
(JSC::JIT::compileAndLinkWithoutFinalizing):
(JSC::JIT::codeSize const):
(JSC::JIT::compileTimeStats):
* jit/JIT.h:
* jit/JITBaselinePlan.cpp: Copied from Source/JavaScriptCore/ftl/FTLState.cpp.
(JSC::JITBaselinePlan::JITBaselinePlan):
(JSC::JITBaselinePlan::compileInThreadImpl):
(JSC::JITBaselinePlan::codeSize const):
(JSC::JITBaselinePlan::finalize):
* jit/JITBaselinePlan.h: Copied from Source/JavaScriptCore/dfg/DFGScannable.h.
* jit/JITCompilationKey.cpp: Renamed from Source/JavaScriptCore/dfg/DFGCompilationKey.cpp.
(JSC::JITCompilationKey::dump const):
* jit/JITCompilationKey.h: Renamed from Source/JavaScriptCore/dfg/DFGCompilationKey.h.
(JSC::JITCompilationKey::JITCompilationKey):
(JSC::JITCompilationKey::operator! const):
(JSC::JITCompilationKey::isHashTableDeletedValue const):
(JSC::JITCompilationKey::mode const):
(JSC::JITCompilationKey::operator== const):
(JSC::JITCompilationKey::hash const):
(JSC::JITCompilationKeyHash::hash):
(JSC::JITCompilationKeyHash::equal):
* jit/JITCompilationMode.cpp: Renamed from Source/JavaScriptCore/dfg/DFGCompilationMode.cpp.
(WTF::printInternal):
* jit/JITCompilationMode.h: Renamed from Source/JavaScriptCore/dfg/DFGCompilationMode.h.
(JSC::isFTL):
* jit/JITOperations.cpp:
(JSC::JSC_DEFINE_JIT_OPERATION):
* jit/JITPlan.cpp: Added.
(JSC::JITPlan::JITPlan):
(JSC::JITPlan::cancel):
(JSC::JITPlan::notifyCompiling):
(JSC::JITPlan::notifyReady):
(JSC::JITPlan::tier const):
(JSC::JITPlan::key):
(JSC::JITPlan::isKnownToBeLiveAfterGC):
(JSC::JITPlan::isKnownToBeLiveDuringGC):
(JSC::JITPlan::iterateCodeBlocksForGC):
(JSC::JITPlan::checkLivenessAndVisitChildren):
(JSC::JITPlan::computeCompileTimes const):
(JSC::JITPlan::reportCompileTimes const):
(JSC::JITPlan::compileInThread):
* jit/JITPlan.h: Added.
(JSC::JITPlan::~JITPlan):
(JSC::JITPlan::vm const):
(JSC::JITPlan::codeBlock const):
(JSC::JITPlan::thread const):
(JSC::JITPlan::mode const):
(JSC::JITPlan::stage const):
(JSC::JITPlan::isFTL const):
(JSC::JITPlan::finalizeInGC):
* jit/JITPlanStage.h: Renamed from Source/JavaScriptCore/dfg/DFGThreadData.cpp.
* jit/JITSafepoint.cpp: Renamed from Source/JavaScriptCore/dfg/DFGSafepoint.cpp.
(JSC::Safepoint::Safepoint):
(JSC::Safepoint::~Safepoint):
(JSC::Safepoint::begin):
(JSC::Safepoint::cancel):
* jit/JITSafepoint.h: Renamed from Source/JavaScriptCore/dfg/DFGSafepoint.h.
* jit/JITScannable.h: Copied from Source/JavaScriptCore/dfg/DFGScannable.h.
* jit/JITWorklist.cpp:
(JSC::JITWorklist::JITWorklist):
(JSC::JITWorklist::~JITWorklist):
(JSC::JITWorklist::existingGlobalWorklistOrNull):
(JSC::JITWorklist::ensureGlobalWorklist):
(JSC::JITWorklist::enqueue):
(JSC::JITWorklist::queueLength const):
(JSC::JITWorklist::suspendAllThreads):
(JSC::JITWorklist::resumeAllThreads):
(JSC::JITWorklist::compilationState):
(JSC::JITWorklist::completeAllReadyPlansForVM):
(JSC::JITWorklist::waitUntilAllPlansForVMAreReady):
(JSC::JITWorklist::completeAllPlansForVM):
(JSC::JITWorklist::cancelAllPlansForVM):
(JSC::JITWorklist::removeDeadPlans):
(JSC::JITWorklist::setMaximumNumberOfConcurrentDFGCompilations):
(JSC::JITWorklist::setMaximumNumberOfConcurrentFTLCompilations):
(JSC::JITWorklist::visitWeakReferences):
(JSC::JITWorklist::dump const):
(JSC::JITWorklist::removeAllReadyPlansForVM):
(JSC::JITWorklist::removeMatchingPlansForVM):
* jit/JITWorklist.h:
(JSC::JITWorklist::static_cast<size_t>):
* jit/JITWorklistInlines.h: Renamed from Source/JavaScriptCore/dfg/DFGScannable.h.
(JSC::JITWorklist::iterateCodeBlocksForGC):
* jit/JITWorklistThread.cpp: Added.
(JSC::JITWorklistThread::JITWorklistThread):
(JSC::JITWorklistThread::name const):
(JSC::JITWorklistThread::poll):
(JSC::JITWorklistThread::work):
(JSC::JITWorklistThread::threadDidStart):
(JSC::JITWorklistThread::threadIsStopping):
* jit/JITWorklistThread.h: Renamed from Source/JavaScriptCore/dfg/DFGThreadData.h.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::jitCompileAndSetHeuristics):
* runtime/OptionsList.h:
* runtime/VM.cpp:
(JSC::VM::~VM):
2021-05-25 Fujii Hironori <Hironori.Fujii@sony.com>
Clang can't compile Optional<GPRTemporary> since r278035 because GPRTemporary has non-const copy constructor
https://bugs.webkit.org/show_bug.cgi?id=226251
Reviewed by Chris Dumez.
WinCairo clang-cl builds reported a compilation error since r278035.
> include\optional(95,5): error: the parameter for this explicitly-defaulted copy constructor is const, but a member or base requires it to be non-const
* dfg/DFGSpeculativeJIT.h: Deleted the const copy ctor instead of the non-const copy ctor.
2021-05-25 Chris Dumez <cdumez@apple.com>
Use UncheckedLock less in JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=226212
Reviewed by Saam Barati.
Use UncheckedLock less in JavaScriptCore as it is being phased out in favor of Lock, which
enables Clang thread safety analysis.
* assembler/testmasm.cpp:
* dfg/DFGCommon.cpp:
* dynbench.cpp:
* heap/Heap.cpp:
* heap/Heap.h:
* inspector/remote/socket/RemoteInspectorSocketEndpoint.h:
* runtime/JSLock.cpp:
* runtime/JSLock.h:
* runtime/VM.h:
2021-05-25 Devin Rousso <drousso@apple.com>
[Modern Media Controls] REGRESSION(r254389) media controls needs the full list of language preferences for ordering tracks
https://bugs.webkit.org/show_bug.cgi?id=226038
Reviewed by Myles C. Maxfield and Eric Carlson.
Media controls need access to the full list of language preferences in order to properly
sort/order the list of tracks in the controls UI. For example, if a `<video>` has subtitles
for English, Spanish, and French, and the user has English (default) and French (alternate)
configured in the Language & Region view of System Preferences on macOS, WebKit should order
the subtitles list English, French, and then Spanish.
* shell/playstation/TestShell.cpp:
(preTest):
Instead of propagating the override, just clear it out.
2021-05-25 Chris Dumez <cdumez@apple.com>
Stop using UncheckedLock in JSC::PerfLog
https://bugs.webkit.org/show_bug.cgi?id=226209
Reviewed by Saam Barati.
Stop using UncheckedLock in JSC::PerfLog and use Lock instead to benefit from Clang thread
safety analysis.
* assembler/PerfLog.cpp:
(JSC::PerfLog::PerfLog):
(JSC::PerfLog::write):
(JSC::PerfLog::flush):
(JSC::PerfLog::log):
* assembler/PerfLog.h:
2021-05-24 Darin Adler <darin@apple.com>
Switch from WTF::Optional to std::optional
https://bugs.webkit.org/show_bug.cgi?id=211674
Reviewed by Chris Dumez.
* runtime/IntlCollator.cpp:
(JSC::IntlCollator::initializeCollator): Use JSObject* instead of
Optional<JSObject&>.
* runtime/IntlDateTimeFormat.cpp:
(JSC::toDateTimeOptionsAnyDate): Ditto.
(JSC::IntlDateTimeFormat::initializeDateTimeFormat): Ditto.
* runtime/IntlDisplayNames.cpp:
(JSC::IntlDisplayNames::initializeDisplayNames): Ditto.
* runtime/IntlListFormat.cpp:
(JSC::IntlListFormat::initializeListFormat): Ditto.
* runtime/IntlLocale.cpp:
(JSC::IntlLocale::initializeLocale): Ditto.
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::initializeNumberFormat): Ditto.
* runtime/IntlNumberFormat.h: Ditto.
* runtime/IntlNumberFormatInlines.h:
(JSC::setNumberFormatDigitOptions): Ditto.
* runtime/IntlObject.cpp:
(JSC::intlBooleanOption): Ditto.
(JSC::intlStringOption): Ditto.
(JSC::intlNumberOption): Ditto.
(JSC::supportedLocales): Ditto.
* runtime/IntlObject.h: Ditto.
* runtime/IntlObjectInlines.h:
(JSC::intlOption): Ditto.
(JSC::intlGetOptionsObject): Ditto.
(JSC::intlCoerceOptionsToObject): Ditto.
* runtime/IntlPluralRules.cpp:
(JSC::IntlPluralRules::initializePluralRules): Ditto.
* runtime/IntlPluralRules.h: Ditto.
* runtime/IntlRelativeTimeFormat.cpp:
(JSC::IntlRelativeTimeFormat::initializeRelativeTimeFormat): Ditto.
* runtime/IntlSegmenter.cpp:
(JSC::IntlSegmenter::initializeSegmenter): Ditto.
2021-05-25 Saam Barati <sbarati@apple.com>
Finalize DFG/FTL code refs on the compiler threads
https://bugs.webkit.org/show_bug.cgi?id=226096
Reviewed by Mark Lam.
Previously, link tasks that ran via the addLinkTask API were guaranteed to be
called on the main thread. This is no longer the case. Most link tasks are
happy running on a background thread, since all they're really doing is
linking branches/calls or grabbing labels. However, a few users of addLinkTask were
relying on it running on the main thread. For those users, there is a new
addMainThreadFinalizationTask API, which is now used instead.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::~LinkBuffer):
(JSC::LinkBuffer::runMainThreadFinalizationTasks):
* assembler/LinkBuffer.h:
(JSC::LinkBuffer::cancel):
(JSC::LinkBuffer::addMainThreadFinalizationTask):
(JSC::LinkBuffer::~LinkBuffer): Deleted.
* dfg/DFGFailedFinalizer.cpp:
(JSC::DFG::FailedFinalizer::finalizeFunction): Deleted.
* dfg/DFGFailedFinalizer.h:
* dfg/DFGFinalizer.h:
(JSC::DFG::Finalizer::cancel):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
* dfg/DFGJITFinalizer.cpp:
(JSC::DFG::JITFinalizer::cancel):
(JSC::DFG::JITFinalizer::finalize):
(JSC::DFG::JITFinalizer::finalizeFunction): Deleted.
(JSC::DFG::JITFinalizer::finalizeCommon): Deleted.
* dfg/DFGJITFinalizer.h:
* dfg/DFGLazyJSValue.cpp:
(JSC::DFG::LazyJSValue::emit const):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
(JSC::DFG::Plan::cancel):
* ftl/FTLJITFinalizer.cpp:
(JSC::FTL::JITFinalizer::finalize):
(JSC::FTL::JITFinalizer::cancel):
(JSC::FTL::JITFinalizer::finalizeFunction): Deleted.
(JSC::FTL::JITFinalizer::finalizeCommon): Deleted.
* ftl/FTLJITFinalizer.h:
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLPatchpointExceptionHandle.cpp:
(JSC::FTL::PatchpointExceptionHandle::scheduleExitCreationForUnwind):
* ftl/FTLThunks.h:
(JSC::FTL::Thunks::getSlowPathCallThunk):
Add a lock to FTLThunks since we now may be calling into it from more than
one thread at a time.
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitVirtualCall):
(JSC::AssemblyHelpers::emitUnlinkedVirtualCall): Deleted.
* jit/AssemblyHelpers.h:
* jit/JIT.cpp:
(JSC::JIT::finalizeOnMainThread):
* jit/JIT.h:
* jit/JITCall.cpp:
(JSC::JIT::compileCallEvalSlowCase):
* jit/JITCall32_64.cpp:
(JSC::JIT::compileCallEvalSlowCase):
2021-05-25 Mark Lam <mark.lam@apple.com>
Reduce Baseline JIT emitted code size for op_jfalse, op_jtrue, op_get_from_scope, op_resolve_scope.
https://bugs.webkit.org/show_bug.cgi?id=226107
Reviewed by Saam Barati.
Benchmarking with JetStream2 and Speedometer2 on M1 Mac shows that performance is
neutral.
This patch reduces Baseline JIT emitted code side on a run of JetStream2 CLI by
another ~6.6M:
Base New Diff
BaselineJIT: 64955116 (61.946026 MB) 57991704 (55.305199 MB) 0.89x (reduction)
DFG: 36382012 (34.696590 MB) 36540652 (34.847881 MB) 1.00x
Thunk: 23217692 (22.142117 MB) 23115852 (22.044994 MB) 1.00x
InlineCache: 22228140 (21.198406 MB) 22262572 (21.231243 MB) 1.00x
FTL: 6025320 (5.746193 MB) 6164332 (5.878765 MB) 1.02x
Wasm: 2327604 (2.219776 MB) 2297036 (2.190624 MB) 0.99x
YarrJIT: 1547172 (1.475498 MB) 1522584 (1.452049 MB) 0.98x
CSSJIT: 0 0
Uncategorized: 0 0
Cumulative diff since the start of this effort to reduce Baseline JIT code size:
Base New Diff
BaselineJIT: 89089964 (84.962811 MB) 57991704 (55.305199 MB) 0.65x (reduction)
DFG: 39117360 (37.305222 MB) 36540652 (34.847881 MB) 0.93x (reduction)
Thunk: 23230968 (22.154778 MB) 23115852 (22.044994 MB) 1.00x
InlineCache: 22027416 (21.006981 MB) 22262572 (21.231243 MB) 1.01x
FTL: 6575772 (6.271145 MB) 6164332 (5.878765 MB) 0.94x (reduction)
Wasm: 2302724 (2.196049 MB) 2297036 (2.190624 MB) 1.00x
YarrJIT: 1538956 (1.467663 MB) 1522584 (1.452049 MB) 0.99x
CSSJIT: 0 0
Uncategorized: 0 0
* bytecode/CodeBlock.h:
(JSC::CodeBlock::offsetInMetadataTable):
(JSC::CodeBlock::offsetOfMetadataTable):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::branchIfValue):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::branchIfTruthy):
(JSC::AssemblyHelpers::branchIfFalsey):
* jit/JIT.cpp:
(JSC::JIT::privateCompileSlowCases):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_jfalse):
(JSC::JIT::valueIsFalseyGenerator):
(JSC::JIT::emit_op_jtrue):
(JSC::JIT::valueIsTruthyGenerator):
* jit/JITOperations.cpp:
(JSC::JSC_DEFINE_JIT_OPERATION):
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_resolve_scope):
(JSC::JIT::generateOpResolveScopeThunk):
(JSC::JIT::slow_op_resolve_scopeGenerator):
(JSC::JIT::emitSlow_op_get_from_scope):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::generateOpGetFromScopeThunk):
(JSC::JIT::slow_op_get_from_scopeGenerator):
* jit/ThunkGenerators.cpp:
(JSC::popThunkStackPreservesAndHandleExceptionGenerator):
* runtime/GetPutInfo.h:
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::offsetOfGlobalLexicalEnvironment):
(JSC::JSGlobalObject::offsetOfGlobalLexicalBindingEpoch):
2021-05-24 Robin Morisset <rmorisset@apple.com>
When running with --reportTotalPhaseTimes=1, we should also log the max time in a phase
https://bugs.webkit.org/show_bug.cgi?id=226196
Reviewed by Saam Barati.
It is especially useful when looking at DFG phases, since the GC may have to wait for them to finish.
* tools/CompilerTimingScope.cpp:
2021-05-24 Saam Barati <sbarati@apple.com>
Allow CTI stubs to be generated off the main thread
https://bugs.webkit.org/show_bug.cgi?id=226180
Reviewed by Mark Lam.
We make this work by tracking if we're a compiler thread when generating
the CTI stub. If so, it means that the main thread needs to issue a
crossModifyingCodeFence when it's going to run the CTI stub for the first
time.
This patch also does away with pre-generating thunks. Thunks can now generate
other thunks while they're running. To do this, we make JITThunks lock a
recursive lock. The reason this is ok is that we don't have any recursive
thunks in the thunk graph. It's a DAG.
* dfg/DFGDriver.cpp:
(JSC::DFG::compileImpl):
* jit/JITOpcodes.cpp:
(JSC::JIT::op_check_traps_handlerGenerator):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::slow_op_get_from_scopeGenerator):
(JSC::JIT::slow_op_put_to_scopeGenerator):
* jit/JITThunks.cpp:
(JSC::JITThunks::ctiInternalFunctionCall):
(JSC::JITThunks::ctiInternalFunctionConstruct):
(JSC::JITThunks::ctiStubImpl):
(JSC::JITThunks::ctiStub):
(JSC::JITThunks::ctiSlowPathFunctionStub):
(JSC::JITThunks::existingCTIStub): Deleted.
(JSC::JITThunks::preinitializeCTIThunks): Deleted.
* jit/JITThunks.h:
* jit/SlowPathCall.cpp:
(JSC::JITSlowPathCall::generateThunk):
* jit/ThunkGenerators.cpp:
(JSC::popThunkStackPreservesAndHandleExceptionGenerator):
(JSC::checkExceptionGenerator):
(JSC::virtualThunkFor):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::getCTIInternalFunctionTrampolineFor):
* runtime/VM.h:
2021-05-24 Darin Adler <darin@apple.com>
Remove StringBuilder::appendLiteral
https://bugs.webkit.org/show_bug.cgi?id=226137
Reviewed by Chris Dumez.
* API/tests/PingPongStackOverflowTest.cpp:
(PingPongStackOverflowObject_hasInstance): Use append instead of appendLiteral.
* bindings/ScriptFunctionCall.cpp:
(Deprecated::ScriptCallArgumentHandler::appendArgument): Remove unnecessary cast
from const char* to String, which defeats optimization and has no benefit.
* bytecompiler/NodesCodegen.cpp:
(JSC::ArrayPatternNode::toString const): Use append instead of appendLiteral.
(JSC::RestParameterNode::toString const): Ditto.
* heap/HeapSnapshotBuilder.cpp:
(JSC::HeapSnapshotBuilder::json): Use append instead of appendLiteral.
Removed unnecesary use of appendQuotedJSONString to append the result of
snapshotTypeToString and edgeTypeToString, which return a const char* that
never contains characters that require special quoting consideration, so
can be appended efficiently with the normal append function.
* inspector/agents/InspectorAuditAgent.cpp:
(Inspector::InspectorAuditAgent::run): Use makeString instead of StringBuilder.
* inspector/agents/InspectorConsoleAgent.cpp: Use auto for the result of makeString.
* jsc.cpp: Use appned instead of appendLiteral.
* parser/ParserArena.cpp:
(JSC::IdentifierArena::makePrivateIdentifier): Use auto for the result of makeString.
* runtime/ConsoleClient.cpp:
(JSC::ConsoleClient::printConsoleMessage): Use append instead of appendLiteral.
Also use variadic append when practical for better efficiency.
(JSC::ConsoleClient::printConsoleMessageWithArguments): Ditto.
* runtime/DateConversion.cpp:
(JSC::formatDateTime): Ditto.
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::sanitizedToString): Use makeString instead of StringBuilder.
* runtime/ExceptionHelpers.cpp:
(JSC::notAFunctionSourceAppender): Use append instead of appendLiteral.
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::initializeDateTimeFormat): Ditto.
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::initializeNumberFormat): Ditto.
* runtime/JSCustomGetterFunction.cpp:
(JSC::JSCustomGetterFunction::create): Use auto and cut down on reference count
churn by using passing the StringImpl to makeString.
* runtime/JSCustomSetterFunction.cpp:
(JSC::JSCustomSetterFunction::create): Ditto.
* runtime/JSGlobalObjectFunctions.cpp: Use more const and use variadic
append for better efficiency.
* runtime/JSONObject.cpp:
(JSC::Stringifier::appendStringifiedValue): Use append instead of appendLiteral.
(JSC::Stringifier::Holder::appendNextProperty): Ditto.
* runtime/JSStringJoiner.h: Deleted unused appendLiteral function.
Unrelated to StringBuilder::appendLiteral, but dead code.
* runtime/Options.cpp:
(JSC::Options::dumpOption): Use append instead of appendLiteral.
* runtime/RegExpPrototype.cpp:
(JSC::appendLineTerminatorEscape<UChar>): Ditto.
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::reportTopFunctions): Use auto for the result of makeString.
(JSC::SamplingProfiler::reportTopBytecodes): Ditto.
* runtime/TypeProfiler.cpp:
(JSC::TypeProfiler::typeInformationForExpressionAtOffset): Use append instead of
appendLiteral.
* runtime/TypeSet.cpp:
(JSC::TypeSet::dumpTypes const): Use append instead of appendLiteral.
(JSC::TypeSet::toJSONString const): Ditto.
(JSC::StructureShape::propertyHash): Ditto.
(JSC::StructureShape::toJSONString const): Ditto.
2021-05-24 Keith Miller <keith_miller@apple.com>
Unreviewed, revert r276610 because it causes a 1% PLT regression.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::visitChildren):
(JSC::CodeBlock::JITData::size const): Deleted.
* bytecode/CodeBlock.h:
* jit/JITCodeMap.h:
(JSC::JITCodeMap::memorySize const): Deleted.
2021-05-24 Chris Dumez <cdumez@apple.com>
Drop CheckedLock / CheckedCondition aliases
https://bugs.webkit.org/show_bug.cgi?id=226176
Reviewed by Kate Cheney.
Drop CheckedLock / CheckedCondition aliases now that they are the default.
* API/JSVirtualMachine.mm:
* API/glib/JSCVirtualMachine.cpp:
* assembler/PerfLog.h:
* assembler/testmasm.cpp:
* bytecode/StructureStubInfo.h:
* bytecode/SuperSampler.cpp:
* dfg/DFGCommon.cpp:
* dfg/DFGCommonData.cpp:
* dfg/DFGPlan.h:
* dfg/DFGThreadData.h:
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::Worklist):
* dfg/DFGWorklist.h:
* disassembler/Disassembler.cpp:
* dynbench.cpp:
* heap/BlockDirectory.cpp:
(JSC::BlockDirectory::parallelNotEmptyBlockSource):
* heap/BlockDirectory.h:
(JSC::BlockDirectory::bitvectorLock):
* heap/CodeBlockSet.h:
(JSC::CodeBlockSet::getLock):
* heap/Heap.cpp:
(JSC::Heap::Heap):
* heap/Heap.h:
* heap/IsoSubspacePerVM.h:
* heap/MarkedSpace.h:
(JSC::MarkedSpace::directoryLock):
* heap/MarkingConstraintSolver.h:
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::donateKnownParallel):
* heap/SlotVisitor.h:
* inspector/remote/socket/RemoteInspectorConnectionClient.h:
* inspector/remote/socket/RemoteInspectorSocketEndpoint.h:
* jit/ExecutableAllocator.cpp:
(JSC::ExecutableAllocator::getLock const):
(JSC::dumpJITMemory):
* jit/ExecutableAllocator.h:
(JSC::ExecutableAllocatorBase::getLock const):
* jit/JITWorklist.cpp:
(JSC::JITWorklist::JITWorklist):
* jit/JITWorklist.h:
* jsc.cpp:
* profiler/ProfilerDatabase.h:
* runtime/ConcurrentJSLock.h:
* runtime/DeferredWorkTimer.h:
* runtime/JSLock.h:
* runtime/SamplingProfiler.cpp:
(JSC::FrameWalker::FrameWalker):
(JSC::CFrameWalker::CFrameWalker):
(JSC::SamplingProfiler::takeSample):
* runtime/SamplingProfiler.h:
(JSC::SamplingProfiler::getLock):
* runtime/VM.h:
* runtime/VMTraps.cpp:
(JSC::VMTraps::invalidateCodeBlocksOnStack):
(JSC::VMTraps::VMTraps):
* runtime/VMTraps.h:
* tools/FunctionOverrides.h:
* tools/VMInspector.cpp:
(JSC::ensureIsSafeToLock):
* tools/VMInspector.h:
(JSC::VMInspector::getLock):
* wasm/WasmCalleeRegistry.h:
(JSC::Wasm::CalleeRegistry::getLock):
* wasm/WasmPlan.h:
* wasm/WasmStreamingCompiler.h:
* wasm/WasmThunks.h:
* wasm/WasmWorklist.cpp:
(JSC::Wasm::Worklist::Worklist):
* wasm/WasmWorklist.h:
2021-05-23 Chris Dumez <cdumez@apple.com>
Make CheckedLock the default Lock
https://bugs.webkit.org/show_bug.cgi?id=226157
Reviewed by Darin Adler.
Make CheckedLock the default Lock so that we get more benefits from Clang
Thread Safety Analysis. Note that CheckedLock 100% relies on the existing
Lock implementation and merely adds the clang anotations for thread
safety.
That this patch does is:
1. Rename the Lock class to UncheckedLock
2. Rename the CheckedLock class to Lock
3. Rename the Condition class to UncheckedCondition
4. Rename the CheckedCondition class to Condition
5. Update the types of certain variables from Lock / Condition to
UncheckedLock / UncheckedCondition if I got a build failure. Build
failures are usually caused by the following facts:
- Locker<CheckedLock> doesn't subclass AbstractLocker which a lot of
JSC code passes as argument
- Locker<CheckedLock> has no move constructor
- Locker<CheckedLock> cannot be constructed from a lock pointer, only
a reference
For now, CheckedLock and CheckedCondition remain as aliases to Lock and
Condition, in their respective CheckedLock.h / CheckedCondition.h headers.
I will drop them in a follow-up to reduce patch size.
I will also follow-up to try and get rid of as much usage of UncheckedLock
and UncheckedCondition as possible. I did not try very hard in this patch
to reduce patch size.
* assembler/testmasm.cpp:
* dfg/DFGCommon.cpp:
* dfg/DFGThreadData.h:
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::Worklist):
* dfg/DFGWorklist.h:
* dynbench.cpp:
* heap/BlockDirectory.h:
(JSC::BlockDirectory::bitvectorLock):
* heap/CodeBlockSet.h:
(JSC::CodeBlockSet::getLock):
* heap/Heap.cpp:
(JSC::Heap::Heap):
* heap/Heap.h:
* heap/MarkedSpace.h:
(JSC::MarkedSpace::directoryLock):
* heap/MarkingConstraintSolver.h:
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::donateKnownParallel):
* heap/SlotVisitor.h:
* jit/ExecutableAllocator.cpp:
(JSC::ExecutableAllocator::getLock const):
(JSC::dumpJITMemory):
* jit/ExecutableAllocator.h:
(JSC::ExecutableAllocatorBase::getLock const):
* jit/JITWorklist.cpp:
(JSC::JITWorklist::JITWorklist):
* jit/JITWorklist.h:
* jsc.cpp:
* profiler/ProfilerDatabase.h:
* runtime/ConcurrentJSLock.h:
* runtime/DeferredWorkTimer.h:
* runtime/JSLock.h:
* runtime/SamplingProfiler.cpp:
(JSC::FrameWalker::FrameWalker):
(JSC::CFrameWalker::CFrameWalker):
(JSC::SamplingProfiler::takeSample):
* runtime/SamplingProfiler.h:
(JSC::SamplingProfiler::getLock):
* runtime/VM.h:
* runtime/VMTraps.cpp:
(JSC::VMTraps::invalidateCodeBlocksOnStack):
(JSC::VMTraps::VMTraps):
* runtime/VMTraps.h:
* tools/FunctionOverrides.h:
* tools/VMInspector.cpp:
(JSC::ensureIsSafeToLock):
* tools/VMInspector.h:
(JSC::VMInspector::getLock):
* wasm/WasmCalleeRegistry.h:
(JSC::Wasm::CalleeRegistry::getLock):
* wasm/WasmPlan.h:
* wasm/WasmStreamingCompiler.h:
* wasm/WasmThunks.h:
* wasm/WasmWorklist.cpp:
(JSC::Wasm::Worklist::Worklist):
* wasm/WasmWorklist.h:
2021-05-23 Mark Lam <mark.lam@apple.com>
Remove some now invalid tests in testmasm.
https://bugs.webkit.org/show_bug.cgi?id=226155
Reviewed by Yusuke Suzuki.
The ARM64E tests were checking that cageConditionallyAndUntag() would fail to
produce a caged pointer if fed invalid values. These tests are no longer feasible
because on ARM64E, feeding cageConditionallyAndUntag() invalid values will now
result in a crash. This patch removes these tests.
* assembler/testmasm.cpp:
(JSC::testCagePreservesPACFailureBit):
2021-05-23 Mark Lam <mark.lam@apple.com>
Remove ENABLE(MASM_PROBE) flag.
https://bugs.webkit.org/show_bug.cgi?id=226154
Reviewed by Yusuke Suzuki.
* assembler/MacroAssembler.cpp:
* assembler/MacroAssembler.h:
* assembler/MacroAssemblerARM64.cpp:
* assembler/MacroAssemblerARMv7.cpp:
(JSC::MacroAssembler::probe):
* assembler/MacroAssemblerMIPS.cpp:
(JSC::MacroAssembler::probe):
* assembler/MacroAssemblerPrinter.cpp:
* assembler/MacroAssemblerPrinter.h:
* assembler/MacroAssemblerX86Common.cpp:
(JSC::MacroAssembler::probe):
* assembler/ProbeContext.cpp:
* assembler/ProbeContext.h:
* assembler/ProbeFrame.h:
* assembler/ProbeStack.cpp:
* assembler/ProbeStack.h:
* assembler/testmasm.cpp:
(JSC::isSpecialGPR):
(JSC::testClearBits64WithMask):
(JSC::testClearBits64WithMaskTernary):
(JSC::testShiftAndAdd):
(JSC::testProbeModifiesStackValues):
(JSC::run):
* b3/B3LowerToAir.cpp:
* b3/air/AirPrintSpecial.cpp:
* b3/air/AirPrintSpecial.h:
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* tools/JSDollarVM.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION_WITH_ATTRIBUTES):
2021-05-23 Chris Dumez <cdumez@apple.com>
Use CheckedLock in even more places
https://bugs.webkit.org/show_bug.cgi?id=226152
Reviewed by Darin Adler.
Use CheckedLock in even more places to benefit from Clang Thread Safety Analysis.
* API/JSVirtualMachine.mm:
(WTF_REQUIRES_LOCK):
* API/glib/JSCVirtualMachine.cpp:
* bytecode/StructureStubInfo.h:
* bytecode/SuperSampler.cpp:
* dfg/DFGCommonData.cpp:
(JSC::DFG::CommonData::invalidate):
(JSC::DFG::CommonData::~CommonData):
(JSC::DFG::CommonData::installVMTrapBreakpoints):
(JSC::DFG::codeBlockForVMTrapPC):
* dfg/DFGPlan.h:
(JSC::DFG::Plan::WTF_GUARDED_BY_LOCK):
* disassembler/Disassembler.cpp:
* heap/BlockDirectory.cpp:
(JSC::BlockDirectory::parallelNotEmptyBlockSource):
* heap/Heap.h:
* heap/IsoSubspacePerVM.h:
* inspector/remote/socket/RemoteInspectorConnectionClient.h:
2021-05-23 Ross Kirsling <ross.kirsling@sony.com>
Unreviewed. Fix JSC Debug tests for r277926.
* jit/JITThunks.cpp:
(JSC::JITThunks::preinitializeCTIThunks):
Address oversight, made visible by the assertion added in r277850.
2021-05-23 Chris Dumez <cdumez@apple.com>
Drop WTF::tryHoldLock() as it is incompatible with Clang Thread Safety Analysis
https://bugs.webkit.org/show_bug.cgi?id=226145
Reviewed by Darin Adler.
Drop WTF::tryHoldLock() as it is incompatible with Clang Thread Safety Analysis.
Instead, use the following pattern which is supported:
```
if (lock.tryLock()) {
Locker locker { AdoptLock, lock };
// ...
}
```
* heap/Heap.cpp:
(JSC::Heap::resumeThePeriphery):
* runtime/VMTraps.cpp:
(JSC::VMTraps::tryInstallTrapBreakpoints):
2021-05-22 Mark Lam <mark.lam@apple.com>
Use singleton thunks for virtual calls.
https://bugs.webkit.org/show_bug.cgi?id=226149
rdar://problem/78357604
Reviewed by Yusuke Suzuki.
Change virtualThunkFor() to return 1 of 6 possible singleton thunks.
These thunks are cached via vm.jitStubs->ctiStubs().
This change saves us ~16M of executable JIT memory (for the unique thunks) on a
single run of Speedometer2. On an M1 Mac, switching to singleton thunks here also
appears to be a 1.012x speed up on Speedometer2. Performance is neutral on
JetStream2.
* jit/JITThunks.cpp:
(JSC::JITThunks::ctiInternalFunctionCall):
(JSC::JITThunks::ctiInternalFunctionConstruct):
* jit/JITThunks.h:
* jit/ThunkGenerators.cpp:
(JSC::virtualThunkFor):
(JSC::virtualThunkForRegularCall):
(JSC::virtualThunkForRegularConstruct):
(JSC::virtualThunkForTailCall):
(JSC::virtualThunkForTailConstruct):
(JSC::virtualThunkForConstructCall):
(JSC::virtualThunkForConstructConstruct):
* runtime/VM.cpp:
(JSC::VM::getCTIInternalFunctionTrampolineFor):
* runtime/VM.h:
2021-05-22 Mark Lam <mark.lam@apple.com>
Enhance Link Buffer stats to have more fine grain profiles, and to collect count information.
https://bugs.webkit.org/show_bug.cgi?id=226151
rdar://problem/78359436
Reviewed by Yusuke Suzuki.
And also add a total of the sizes.
Also added $vm.clearLinkBufferStats() which resets all the stats to 0.
Here's an example of that the new stats look like:
Cummulative LinkBuffer profile sizes:
BaselineJIT: 61092032 (58.261902 MB) count 11621 avg size 5257
DFG: 35387904 (33.748535 MB) count 11143 avg size 3175
InlineCache: 19639155 (18.729358 MB) count 283890 avg size 69
VirtualThunk: 14256800 (13.596344 MB) count 43900 avg size 324
DFGOSRExit: 7636736 (7.282959 MB) count 5235 avg size 1458
FTL: 4927616 (4.699341 MB) count 5269 avg size 935
Wasm: 2134688 (2.035797 MB) count 847 avg size 2520
YarrJIT: 1320928 (1.259735 MB) count 2075 avg size 636
FTLOSRExit: 1084096 (1.033875 MB) count 417 avg size 2599
WasmThunk: 41408 (40.437500 KB) count 252 avg size 164
FTLThunk: 25088 (24.500000 KB) count 426 avg size 58
ExtraCTIThunk: 5984 (5.843750 KB) count 95 avg size 62
SpecializedThunk: 3456 (3.375000 KB) count 19 avg size 181
Thunk: 1760 (1.718750 KB) count 10 avg size 176
BoundFunctionThunk: 864 count 3 avg size 288
LLIntThunk: 608 count 18 avg size 33
DFGThunk: 608 count 1 avg size 608
DFGOSREntry: 160 count 1 avg size 160
JumpIsland: 0
CSSJIT: 0
Uncategorized: 0
Total: 147559891 (140.724078 MB)
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::performFinalization):
(JSC::LinkBuffer::clearProfileStatistics):
(JSC::LinkBuffer::dumpProfileStatistics):
* assembler/LinkBuffer.h:
* dfg/DFGOSRExit.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* dfg/DFGThunks.cpp:
(JSC::DFG::osrExitGenerationThunkGenerator):
(JSC::DFG::osrEntryThunkGenerator):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* ftl/FTLThunks.cpp:
(JSC::FTL::genericGenerationThunkGenerator):
(JSC::FTL::slowPathCallThunkGenerator):
* jit/ExecutableAllocator.cpp:
* jit/JITOpcodes.cpp:
(JSC::JIT::op_ret_handlerGenerator):
(JSC::JIT::op_throw_handlerGenerator):
(JSC::JIT::op_enter_handlerGenerator):
(JSC::JIT::op_check_traps_handlerGenerator):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::slow_op_get_by_val_prepareCallGenerator):
(JSC::JIT::slow_op_get_private_name_prepareCallGenerator):
(JSC::JIT::slow_op_put_by_val_prepareCallGenerator):
(JSC::JIT::slow_op_put_private_name_prepareCallGenerator):
(JSC::JIT::slow_op_del_by_id_prepareCallGenerator):
(JSC::JIT::slow_op_del_by_val_prepareCallGenerator):
(JSC::JIT::slow_op_get_by_id_prepareCallGenerator):
(JSC::JIT::slow_op_get_by_id_with_this_prepareCallGenerator):
(JSC::JIT::slow_op_put_by_id_prepareCallGenerator):
(JSC::JIT::slow_op_get_from_scopeGenerator):
(JSC::JIT::slow_op_put_to_scopeGenerator):
* jit/SlowPathCall.cpp:
(JSC::JITSlowPathCall::generateThunk):
* jit/SpecializedThunkJIT.h:
(JSC::SpecializedThunkJIT::finalize):
* jit/ThunkGenerators.cpp:
(JSC::handleExceptionGenerator):
(JSC::handleExceptionWithCallFrameRollbackGenerator):
(JSC::popThunkStackPreservesAndHandleExceptionGenerator):
(JSC::checkExceptionGenerator):
(JSC::virtualThunkFor):
(JSC::boundFunctionCallGenerator):
* llint/LLIntThunks.cpp:
(JSC::LLInt::generateThunkWithJumpTo):
(JSC::LLInt::generateThunkWithJumpToPrologue):
(JSC::LLInt::generateThunkWithJumpToLLIntReturnPoint):
(JSC::LLInt::getHostCallReturnValueThunk):
(JSC::LLInt::createJSGateThunk):
(JSC::LLInt::createWasmGateThunk):
(JSC::LLInt::createTailCallGate):
(JSC::LLInt::loopOSREntryGateThunk):
(JSC::LLInt::entryOSREntryGateThunk):
(JSC::LLInt::wasmOSREntryGateThunk):
(JSC::LLInt::exceptionHandlerGateThunk):
(JSC::LLInt::returnFromLLIntGateThunk):
(JSC::LLInt::tagGateThunk):
(JSC::LLInt::untagGateThunk):
(JSC::LLInt::jitCagePtrThunk):
* tools/JSDollarVM.cpp:
(JSC::JSDollarVM::finishCreation):
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToWasm):
* wasm/WasmThunks.cpp:
(JSC::Wasm::throwExceptionFromWasmThunkGenerator):
(JSC::Wasm::throwStackOverflowFromWasmThunkGenerator):
(JSC::Wasm::triggerOMGEntryTierUpThunkGenerator):
* wasm/js/WasmToJS.cpp:
(JSC::Wasm::wasmToJS):
2021-05-22 Ross Kirsling <ross.kirsling@sony.com>
Support Ergonomic Brand Checks proposal (`#x in obj`)
https://bugs.webkit.org/show_bug.cgi?id=221093
Reviewed by Caio Araujo Neponoceno de Lima.
This patch implements the following Stage 3 proposal (behind a runtime option):
https://github.com/tc39/proposal-private-fields-in-in
Specifically, it extends the `in` keyword to allow the LHS to be a private name,
thereby allowing users to implement Array.isArray-esque brand checks for their own classes
*without* having to wrap a private member get in a try-catch.
For example:
```
class C {
#x;
static isC(obj) { return #x in obj; }
}
```
This is done by adding two new bytecode ops, HasPrivateName and HasPrivateBrand. For the moment,
these are implemented without fast paths, as we should do so for InByVal first and then have these follow suit.
* bytecode/BytecodeList.rb:
* bytecode/BytecodeUseDef.cpp:
(JSC::computeUsesForBytecodeIndexImpl):
(JSC::computeDefsForBytecodeIndexImpl):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitHasPrivateName):
(JSC::BytecodeGenerator::emitHasPrivateBrand):
(JSC::BytecodeGenerator::emitCheckPrivateBrand):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::InNode::emitBytecode):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileHasPrivateName):
(JSC::DFG::SpeculativeJIT::compileHasPrivateBrand):
* 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::compileHasPrivateName):
(JSC::FTL::DFG::LowerDFGToB3::compileHasPrivateBrand):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JITOperations.cpp:
(JSC::JSC_DEFINE_JIT_OPERATION):
* jit/JITOperations.h:
* llint/LowLevelInterpreter.asm:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createPrivateIdentifierNode):
* parser/NodeConstructors.h:
(JSC::PrivateIdentifierNode::PrivateIdentifierNode):
* parser/Nodes.h:
(JSC::ExpressionNode::isPrivateIdentifier const):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseBinaryExpression):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createPrivateIdentifierNode):
* parser/VariableEnvironment.h:
* runtime/CommonSlowPaths.cpp:
(JSC::JSC_DEFINE_COMMON_SLOW_PATH):
* runtime/CommonSlowPaths.h:
* runtime/JSObject.h:
* runtime/JSObjectInlines.h:
(JSC::JSObject::hasPrivateField):
(JSC::JSObject::hasPrivateBrand):
(JSC::JSObject::checkPrivateBrand):
* runtime/OptionsList.h:
2021-05-22 Chris Dumez <cdumez@apple.com>
Replace LockHolder with Locker in local variables
https://bugs.webkit.org/show_bug.cgi?id=226133
Reviewed by Darin Adler.
Replace LockHolder with Locker in local variables. It is shorter and it allows switching the lock
type more easily since the compiler with deduce the lock type T for Locker<T>.
* API/JSCallbackObject.h:
(JSC::JSCallbackObjectData::JSPrivatePropertyMap::setPrivateProperty):
(JSC::JSCallbackObjectData::JSPrivatePropertyMap::deletePrivateProperty):
(JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren):
* API/JSValue.mm:
(handerForStructTag):
* API/tests/testapi.cpp:
(testCAPIViaCpp):
* assembler/testmasm.cpp:
(JSC::run):
* b3/air/testair.cpp:
* b3/testb3_1.cpp:
(run):
* bytecode/DirectEvalCodeCache.cpp:
(JSC::DirectEvalCodeCache::setSlow):
(JSC::DirectEvalCodeCache::clear):
(JSC::DirectEvalCodeCache::visitAggregateImpl):
* bytecode/SuperSampler.cpp:
(JSC::initializeSuperSampler):
(JSC::resetSuperSamplerState):
(JSC::printSuperSamplerState):
(JSC::enableSuperSampler):
(JSC::disableSuperSampler):
* dfg/DFGCommonData.cpp:
(JSC::DFG::CommonData::invalidate):
(JSC::DFG::CommonData::~CommonData):
(JSC::DFG::CommonData::installVMTrapBreakpoints):
(JSC::DFG::codeBlockForVMTrapPC):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::cleanMustHandleValuesIfNecessary):
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::~Worklist):
(JSC::DFG::Worklist::finishCreation):
(JSC::DFG::Worklist::isActiveForVM const):
(JSC::DFG::Worklist::enqueue):
(JSC::DFG::Worklist::compilationState):
(JSC::DFG::Worklist::waitUntilAllPlansForVMAreReady):
(JSC::DFG::Worklist::removeAllReadyPlansForVM):
(JSC::DFG::Worklist::completeAllReadyPlansForVM):
(JSC::DFG::Worklist::visitWeakReferences):
(JSC::DFG::Worklist::removeDeadPlans):
(JSC::DFG::Worklist::removeNonCompilingPlansForVM):
(JSC::DFG::Worklist::queueLength):
(JSC::DFG::Worklist::dump const):
(JSC::DFG::Worklist::setNumberOfThreads):
* dfg/DFGWorklistInlines.h:
(JSC::DFG::Worklist::iterateCodeBlocksForGC):
* disassembler/Disassembler.cpp:
* heap/BlockDirectory.cpp:
(JSC::BlockDirectory::addBlock):
* heap/CodeBlockSetInlines.h:
(JSC::CodeBlockSet::iterateCurrentlyExecuting):
* heap/ConservativeRoots.cpp:
(JSC::ConservativeRoots::add):
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::collectAsync):
(JSC::Heap::runBeginPhase):
(JSC::Heap::waitForCollector):
(JSC::Heap::requestCollection):
(JSC::Heap::notifyIsSafeToCollect):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::didReachTermination):
* inspector/agents/InspectorScriptProfilerAgent.cpp:
(Inspector::InspectorScriptProfilerAgent::startTracking):
(Inspector::InspectorScriptProfilerAgent::trackingComplete):
(Inspector::InspectorScriptProfilerAgent::stopSamplingWhenDisconnecting):
* inspector/remote/RemoteConnectionToTarget.cpp:
(Inspector::RemoteConnectionToTarget::setup):
(Inspector::RemoteConnectionToTarget::sendMessageToTarget):
(Inspector::RemoteConnectionToTarget::close):
(Inspector::RemoteConnectionToTarget::targetClosed):
* inspector/remote/RemoteInspector.cpp:
(Inspector::RemoteInspector::registerTarget):
(Inspector::RemoteInspector::unregisterTarget):
(Inspector::RemoteInspector::updateTarget):
(Inspector::RemoteInspector::updateClientCapabilities):
(Inspector::RemoteInspector::setClient):
(Inspector::RemoteInspector::setupFailed):
(Inspector::RemoteInspector::setupCompleted):
(Inspector::RemoteInspector::stop):
* inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
(Inspector::RemoteTargetHandleRunSourceGlobal):
(Inspector::RemoteTargetQueueTaskOnGlobalQueue):
(Inspector::RemoteTargetHandleRunSourceWithInfo):
(Inspector::RemoteConnectionToTarget::setup):
(Inspector::RemoteConnectionToTarget::targetClosed):
(Inspector::RemoteConnectionToTarget::close):
(Inspector::RemoteConnectionToTarget::sendMessageToTarget):
(Inspector::RemoteConnectionToTarget::queueTaskOnPrivateRunLoop):
* inspector/remote/cocoa/RemoteInspectorCocoa.mm:
(Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
(Inspector::RemoteInspector::sendMessageToRemote):
(Inspector::RemoteInspector::start):
(Inspector::RemoteInspector::setupXPCConnectionIfNeeded):
(Inspector::RemoteInspector::setParentProcessInformation):
(Inspector::RemoteInspector::xpcConnectionReceivedMessage):
(Inspector::RemoteInspector::xpcConnectionFailed):
(Inspector::RemoteInspector::pushListingsSoon):
(Inspector::RemoteInspector::receivedIndicateMessage):
(Inspector::RemoteInspector::receivedProxyApplicationSetupMessage):
* inspector/remote/cocoa/RemoteInspectorXPCConnection.mm:
(Inspector::RemoteInspectorXPCConnection::close):
(Inspector::RemoteInspectorXPCConnection::closeFromMessage):
(Inspector::RemoteInspectorXPCConnection::deserializeMessage):
(Inspector::RemoteInspectorXPCConnection::handleEvent):
* inspector/remote/glib/RemoteInspectorGlib.cpp:
(Inspector::RemoteInspector::start):
(Inspector::RemoteInspector::setupConnection):
(Inspector::RemoteInspector::pushListingsSoon):
(Inspector::RemoteInspector::sendMessageToRemote):
(Inspector::RemoteInspector::receivedGetTargetListMessage):
(Inspector::RemoteInspector::receivedDataMessage):
(Inspector::RemoteInspector::receivedCloseMessage):
(Inspector::RemoteInspector::setup):
* inspector/remote/socket/RemoteInspectorConnectionClient.cpp:
(Inspector::RemoteInspectorConnectionClient::didReceive):
* inspector/remote/socket/RemoteInspectorSocket.cpp:
(Inspector::RemoteInspector::didClose):
(Inspector::RemoteInspector::start):
(Inspector::RemoteInspector::pushListingsSoon):
(Inspector::RemoteInspector::setup):
(Inspector::RemoteInspector::setupInspectorClient):
(Inspector::RemoteInspector::frontendDidClose):
(Inspector::RemoteInspector::sendMessageToBackend):
(Inspector::RemoteInspector::startAutomationSession):
* inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp:
(Inspector::RemoteInspectorSocketEndpoint::listenInet):
(Inspector::RemoteInspectorSocketEndpoint::isListening):
(Inspector::RemoteInspectorSocketEndpoint::workerThread):
(Inspector::RemoteInspectorSocketEndpoint::createClient):
(Inspector::RemoteInspectorSocketEndpoint::disconnect):
(Inspector::RemoteInspectorSocketEndpoint::invalidateClient):
(Inspector::RemoteInspectorSocketEndpoint::invalidateListener):
(Inspector::RemoteInspectorSocketEndpoint::getPort const):
(Inspector::RemoteInspectorSocketEndpoint::recvIfEnabled):
(Inspector::RemoteInspectorSocketEndpoint::sendIfEnabled):
(Inspector::RemoteInspectorSocketEndpoint::send):
(Inspector::RemoteInspectorSocketEndpoint::acceptInetSocketIfEnabled):
* interpreter/CLoopStack.cpp:
(JSC::CLoopStack::addToCommittedByteCount):
(JSC::CLoopStack::committedByteCount):
* jit/ExecutableAllocator.cpp:
(JSC::dumpJITMemory):
* jit/ICStats.cpp:
(JSC::ICStats::ICStats):
(JSC::ICStats::~ICStats):
* jit/JITThunks.cpp:
(JSC::JITThunks::ctiStub):
(JSC::JITThunks::existingCTIStub):
(JSC::JITThunks::ctiSlowPathFunctionStub):
* jit/JITWorklist.cpp:
(JSC::JITWorklist::Plan::compileInThread):
(JSC::JITWorklist::Plan::isFinishedCompiling):
(JSC::JITWorklist::JITWorklist):
(JSC::JITWorklist::completeAllForVM):
(JSC::JITWorklist::poll):
(JSC::JITWorklist::compileLater):
(JSC::JITWorklist::finalizePlans):
* parser/SourceProvider.cpp:
(JSC::SourceProvider::getID):
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::ensureBytecodesFor):
(JSC::Profiler::Database::notifyDestruction):
(JSC::Profiler::Database::addCompilation):
(JSC::Profiler::Database::logEvent):
(JSC::Profiler::Database::addDatabaseToAtExit):
(JSC::Profiler::Database::removeDatabaseFromAtExit):
(JSC::Profiler::Database::removeFirstAtExitDatabase):
* profiler/ProfilerUID.cpp:
(JSC::Profiler::UID::create):
* runtime/DeferredWorkTimer.cpp:
(JSC::DeferredWorkTimer::scheduleWorkSoon):
(JSC::DeferredWorkTimer::didResumeScriptExecutionOwner):
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::timerLoop):
(JSC::SamplingProfiler::shutdown):
(JSC::SamplingProfiler::start):
(JSC::SamplingProfiler::noticeCurrentThreadAsJSCExecutionThread):
(JSC::SamplingProfiler::noticeJSLockAcquisition):
(JSC::SamplingProfiler::noticeVMEntry):
(JSC::SamplingProfiler::registerForReportAtExit):
* runtime/Watchdog.cpp:
(JSC::Watchdog::startTimer):
(JSC::Watchdog::willDestroyVM):
* tools/VMInspector.cpp:
(JSC::VMInspector::isValidExecutableMemory):
* wasm/WasmBBQPlan.cpp:
(JSC::Wasm::BBQPlan::work):
* wasm/WasmEntryPlan.cpp:
(JSC::Wasm::EntryPlan::ThreadCountHolder::ThreadCountHolder):
(JSC::Wasm::EntryPlan::ThreadCountHolder::~ThreadCountHolder):
* wasm/WasmOMGPlan.cpp:
(JSC::Wasm::OMGPlan::work):
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::addCompletionTask):
(JSC::Wasm::Plan::waitForCompletion):
(JSC::Wasm::Plan::tryRemoveContextAndCancelIfLast):
* wasm/WasmSignature.cpp:
(JSC::Wasm::SignatureInformation::signatureFor):
(JSC::Wasm::SignatureInformation::tryCleanup):
* wasm/WasmWorklist.cpp:
(JSC::Wasm::Worklist::enqueue):
(JSC::Wasm::Worklist::completePlanSynchronously):
(JSC::Wasm::Worklist::stopAllPlansForContext):
(JSC::Wasm::Worklist::Worklist):
(JSC::Wasm::Worklist::~Worklist):
2021-05-22 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r277913.
https://bugs.webkit.org/show_bug.cgi?id=226140
Caused multiple layout-test crash on mac debug queues
Reverted changeset:
"Replace LockHolder with Locker in local variables"
https://bugs.webkit.org/show_bug.cgi?id=226133
https://trac.webkit.org/changeset/277913
2021-05-21 Chris Dumez <cdumez@apple.com>
Remove WTF::holdLock() / WTF::holdLockIf()
https://bugs.webkit.org/show_bug.cgi?id=226135
Reviewed by Darin Adler.
Remove WTF::holdLock() / WTF::holdLockIf() because they are not compatible with
Clang Thread Safety Analysis. All call sites have been converted to use the Locker
constructor directly.
* heap/LockDuringMarking.h:
(JSC::lockDuringMarking):
2021-05-21 Chris Dumez <cdumez@apple.com>
Replace LockHolder with Locker in local variables
https://bugs.webkit.org/show_bug.cgi?id=226133
Reviewed by Darin Adler.
Replace LockHolder with Locker in local variables. It is shorter and it allows switching the lock
type more easily since the compiler with deduce the lock type T for Locker<T>.
* API/JSCallbackObject.h:
(JSC::JSCallbackObjectData::JSPrivatePropertyMap::setPrivateProperty):
(JSC::JSCallbackObjectData::JSPrivatePropertyMap::deletePrivateProperty):
(JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren):
* API/JSValue.mm:
(handerForStructTag):
* API/tests/testapi.cpp:
(testCAPIViaCpp):
* assembler/testmasm.cpp:
(JSC::run):
* b3/air/testair.cpp:
* b3/testb3_1.cpp:
(run):
* bytecode/DirectEvalCodeCache.cpp:
(JSC::DirectEvalCodeCache::setSlow):
(JSC::DirectEvalCodeCache::clear):
(JSC::DirectEvalCodeCache::visitAggregateImpl):
* bytecode/SuperSampler.cpp:
(JSC::initializeSuperSampler):
(JSC::resetSuperSamplerState):
(JSC::printSuperSamplerState):
(JSC::enableSuperSampler):
(JSC::disableSuperSampler):
* dfg/DFGCommonData.cpp:
(JSC::DFG::CommonData::invalidate):
(JSC::DFG::CommonData::~CommonData):
(JSC::DFG::CommonData::installVMTrapBreakpoints):
(JSC::DFG::codeBlockForVMTrapPC):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::cleanMustHandleValuesIfNecessary):
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::~Worklist):
(JSC::DFG::Worklist::finishCreation):
(JSC::DFG::Worklist::isActiveForVM const):
(JSC::DFG::Worklist::enqueue):
(JSC::DFG::Worklist::compilationState):
(JSC::DFG::Worklist::waitUntilAllPlansForVMAreReady):
(JSC::DFG::Worklist::removeAllReadyPlansForVM):
(JSC::DFG::Worklist::completeAllReadyPlansForVM):
(JSC::DFG::Worklist::visitWeakReferences):
(JSC::DFG::Worklist::removeDeadPlans):
(JSC::DFG::Worklist::removeNonCompilingPlansForVM):
(JSC::DFG::Worklist::queueLength):
(JSC::DFG::Worklist::dump const):
(JSC::DFG::Worklist::setNumberOfThreads):
* dfg/DFGWorklistInlines.h:
(JSC::DFG::Worklist::iterateCodeBlocksForGC):
* disassembler/Disassembler.cpp:
* heap/BlockDirectory.cpp:
(JSC::BlockDirectory::addBlock):
* heap/CodeBlockSetInlines.h:
(JSC::CodeBlockSet::iterateCurrentlyExecuting):
* heap/ConservativeRoots.cpp:
(JSC::ConservativeRoots::add):
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::collectAsync):
(JSC::Heap::runBeginPhase):
(JSC::Heap::waitForCollector):
(JSC::Heap::requestCollection):
(JSC::Heap::notifyIsSafeToCollect):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::didReachTermination):
* inspector/agents/InspectorScriptProfilerAgent.cpp:
(Inspector::InspectorScriptProfilerAgent::startTracking):
(Inspector::InspectorScriptProfilerAgent::trackingComplete):
(Inspector::InspectorScriptProfilerAgent::stopSamplingWhenDisconnecting):
* inspector/remote/RemoteConnectionToTarget.cpp:
(Inspector::RemoteConnectionToTarget::setup):
(Inspector::RemoteConnectionToTarget::sendMessageToTarget):
(Inspector::RemoteConnectionToTarget::close):
(Inspector::RemoteConnectionToTarget::targetClosed):
* inspector/remote/RemoteInspector.cpp:
(Inspector::RemoteInspector::registerTarget):
(Inspector::RemoteInspector::unregisterTarget):
(Inspector::RemoteInspector::updateTarget):
(Inspector::RemoteInspector::updateClientCapabilities):
(Inspector::RemoteInspector::setClient):
(Inspector::RemoteInspector::setupFailed):
(Inspector::RemoteInspector::setupCompleted):
(Inspector::RemoteInspector::stop):
* inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
(Inspector::RemoteTargetHandleRunSourceGlobal):
(Inspector::RemoteTargetQueueTaskOnGlobalQueue):
(Inspector::RemoteTargetHandleRunSourceWithInfo):
(Inspector::RemoteConnectionToTarget::setup):
(Inspector::RemoteConnectionToTarget::targetClosed):
(Inspector::RemoteConnectionToTarget::close):
(Inspector::RemoteConnectionToTarget::sendMessageToTarget):
(Inspector::RemoteConnectionToTarget::queueTaskOnPrivateRunLoop):
* inspector/remote/cocoa/RemoteInspectorCocoa.mm:
(Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
(Inspector::RemoteInspector::sendMessageToRemote):
(Inspector::RemoteInspector::start):
(Inspector::RemoteInspector::setupXPCConnectionIfNeeded):
(Inspector::RemoteInspector::setParentProcessInformation):
(Inspector::RemoteInspector::xpcConnectionReceivedMessage):
(Inspector::RemoteInspector::xpcConnectionFailed):
(Inspector::RemoteInspector::pushListingsSoon):
(Inspector::RemoteInspector::receivedIndicateMessage):
(Inspector::RemoteInspector::receivedProxyApplicationSetupMessage):
* inspector/remote/cocoa/RemoteInspectorXPCConnection.mm:
(Inspector::RemoteInspectorXPCConnection::close):
(Inspector::RemoteInspectorXPCConnection::closeFromMessage):
(Inspector::RemoteInspectorXPCConnection::deserializeMessage):
(Inspector::RemoteInspectorXPCConnection::handleEvent):
* inspector/remote/glib/RemoteInspectorGlib.cpp:
(Inspector::RemoteInspector::start):
(Inspector::RemoteInspector::setupConnection):
(Inspector::RemoteInspector::pushListingsSoon):
(Inspector::RemoteInspector::sendMessageToRemote):
(Inspector::RemoteInspector::receivedGetTargetListMessage):
(Inspector::RemoteInspector::receivedDataMessage):
(Inspector::RemoteInspector::receivedCloseMessage):
(Inspector::RemoteInspector::setup):
* inspector/remote/socket/RemoteInspectorConnectionClient.cpp:
(Inspector::RemoteInspectorConnectionClient::didReceive):
* inspector/remote/socket/RemoteInspectorSocket.cpp:
(Inspector::RemoteInspector::didClose):
(Inspector::RemoteInspector::start):
(Inspector::RemoteInspector::pushListingsSoon):
(Inspector::RemoteInspector::setup):
(Inspector::RemoteInspector::setupInspectorClient):
(Inspector::RemoteInspector::frontendDidClose):
(Inspector::RemoteInspector::sendMessageToBackend):
(Inspector::RemoteInspector::startAutomationSession):
* inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp:
(Inspector::RemoteInspectorSocketEndpoint::listenInet):
(Inspector::RemoteInspectorSocketEndpoint::isListening):
(Inspector::RemoteInspectorSocketEndpoint::workerThread):
(Inspector::RemoteInspectorSocketEndpoint::createClient):
(Inspector::RemoteInspectorSocketEndpoint::disconnect):
(Inspector::RemoteInspectorSocketEndpoint::invalidateClient):
(Inspector::RemoteInspectorSocketEndpoint::invalidateListener):
(Inspector::RemoteInspectorSocketEndpoint::getPort const):
(Inspector::RemoteInspectorSocketEndpoint::recvIfEnabled):
(Inspector::RemoteInspectorSocketEndpoint::sendIfEnabled):
(Inspector::RemoteInspectorSocketEndpoint::send):
(Inspector::RemoteInspectorSocketEndpoint::acceptInetSocketIfEnabled):
* interpreter/CLoopStack.cpp:
(JSC::CLoopStack::addToCommittedByteCount):
(JSC::CLoopStack::committedByteCount):
* jit/ExecutableAllocator.cpp:
(JSC::dumpJITMemory):
* jit/ICStats.cpp:
(JSC::ICStats::ICStats):
(JSC::ICStats::~ICStats):
* jit/JITThunks.cpp:
(JSC::JITThunks::ctiStub):
(JSC::JITThunks::existingCTIStub):
(JSC::JITThunks::ctiSlowPathFunctionStub):
* jit/JITWorklist.cpp:
(JSC::JITWorklist::Plan::compileInThread):
(JSC::JITWorklist::Plan::isFinishedCompiling):
(JSC::JITWorklist::JITWorklist):
(JSC::JITWorklist::completeAllForVM):
(JSC::JITWorklist::poll):
(JSC::JITWorklist::compileLater):
(JSC::JITWorklist::finalizePlans):
* parser/SourceProvider.cpp:
(JSC::SourceProvider::getID):
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::ensureBytecodesFor):
(JSC::Profiler::Database::notifyDestruction):
(JSC::Profiler::Database::addCompilation):
(JSC::Profiler::Database::logEvent):
(JSC::Profiler::Database::addDatabaseToAtExit):
(JSC::Profiler::Database::removeDatabaseFromAtExit):
(JSC::Profiler::Database::removeFirstAtExitDatabase):
* profiler/ProfilerUID.cpp:
(JSC::Profiler::UID::create):
* runtime/DeferredWorkTimer.cpp:
(JSC::DeferredWorkTimer::scheduleWorkSoon):
(JSC::DeferredWorkTimer::didResumeScriptExecutionOwner):
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::timerLoop):
(JSC::SamplingProfiler::shutdown):
(JSC::SamplingProfiler::start):
(JSC::SamplingProfiler::noticeCurrentThreadAsJSCExecutionThread):
(JSC::SamplingProfiler::noticeJSLockAcquisition):
(JSC::SamplingProfiler::noticeVMEntry):
(JSC::SamplingProfiler::registerForReportAtExit):
* runtime/Watchdog.cpp:
(JSC::Watchdog::startTimer):
(JSC::Watchdog::willDestroyVM):
* tools/VMInspector.cpp:
(JSC::VMInspector::isValidExecutableMemory):
* wasm/WasmBBQPlan.cpp:
(JSC::Wasm::BBQPlan::work):
* wasm/WasmEntryPlan.cpp:
(JSC::Wasm::EntryPlan::ThreadCountHolder::ThreadCountHolder):
(JSC::Wasm::EntryPlan::ThreadCountHolder::~ThreadCountHolder):
* wasm/WasmOMGPlan.cpp:
(JSC::Wasm::OMGPlan::work):
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::addCompletionTask):
(JSC::Wasm::Plan::waitForCompletion):
(JSC::Wasm::Plan::tryRemoveContextAndCancelIfLast):
* wasm/WasmSignature.cpp:
(JSC::Wasm::SignatureInformation::signatureFor):
(JSC::Wasm::SignatureInformation::tryCleanup):
* wasm/WasmWorklist.cpp:
(JSC::Wasm::Worklist::enqueue):
(JSC::Wasm::Worklist::completePlanSynchronously):
(JSC::Wasm::Worklist::stopAllPlansForContext):
(JSC::Wasm::Worklist::Worklist):
(JSC::Wasm::Worklist::~Worklist):
2021-05-21 Chris Dumez <cdumez@apple.com>
Stop using holdLock() in JSC as it is not compatible with Clang thread safety analysis
https://bugs.webkit.org/show_bug.cgi?id=226116
Reviewed by Mark Lam.
Stop using holdLock() in JSC as it is not compatible with Clang thread safety analysis
(WTF::CheckedLock). Use the Locker constructor instead.
I'll eventually get rid of the holdLock() definition once I have managed to get rid of
all its usages.
* API/JSVirtualMachine.mm:
(+[JSVMWrapperCache addWrapper:forJSContextGroupRef:]):
(+[JSVMWrapperCache wrapperForJSContextGroupRef:]):
(-[JSVirtualMachine addExternalRememberedObject:]):
(-[JSVirtualMachine addManagedReference:withOwner:]):
(-[JSVirtualMachine removeManagedReference:withOwner:]):
(scanExternalObjectGraph):
(scanExternalRememberedSet):
* API/glib/JSCVirtualMachine.cpp:
(addWrapper):
(removeWrapper):
* API/tests/ExecutionTimeLimitTest.cpp:
(testExecutionTimeLimit):
* assembler/PerfLog.cpp:
(JSC::PerfLog::PerfLog):
(JSC::PerfLog::log):
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::visitAggregateImpl):
(JSC::StructureStubInfo::visitWeakReferences):
* bytecode/StructureStubInfo.h:
(JSC::StructureStubInfo::considerCaching):
(JSC::StructureStubInfo::clearBufferedStructures):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
(JSC::UnlinkedCodeBlock::visitChildrenImpl):
* bytecode/UnlinkedCodeBlockGenerator.cpp:
(JSC::UnlinkedCodeBlockGenerator::finalize):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* heap/BlockDirectory.cpp:
(JSC::BlockDirectory::~BlockDirectory):
(JSC::BlockDirectory::removeBlock):
(JSC::BlockDirectory::stopAllocatingForGood):
(JSC::BlockDirectory::parallelNotEmptyBlockSource):
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::add):
(JSC::CodeBlockSet::remove):
* heap/CodeBlockSetInlines.h:
(JSC::CodeBlockSet::iterate):
* heap/CompleteSubspace.cpp:
(JSC::CompleteSubspace::allocatorForSlow):
* heap/Heap.cpp:
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::runNotRunningPhase):
(JSC::Heap::runEndPhase):
(JSC::Heap::finishRelinquishingConn):
(JSC::visitSamplingProfiler):
(JSC::Heap::setBonusVisitorTask):
(JSC::Heap::runTaskInParallel):
* heap/HeapSnapshotBuilder.cpp:
(JSC::HeapSnapshotBuilder::buildSnapshot):
(JSC::HeapSnapshotBuilder::analyzeNode):
(JSC::HeapSnapshotBuilder::analyzeEdge):
(JSC::HeapSnapshotBuilder::analyzePropertyNameEdge):
(JSC::HeapSnapshotBuilder::analyzeVariableNameEdge):
(JSC::HeapSnapshotBuilder::analyzeIndexEdge):
(JSC::HeapSnapshotBuilder::setOpaqueRootReachabilityReasonForCell):
* heap/IsoAlignedMemoryAllocator.cpp:
(JSC::IsoAlignedMemoryAllocator::tryAllocateAlignedMemory):
(JSC::IsoAlignedMemoryAllocator::freeAlignedMemory):
* heap/IsoCellSet.cpp:
(JSC::IsoCellSet::parallelNotEmptyMarkedBlockSource):
(JSC::IsoCellSet::addSlow):
(JSC::IsoCellSet::didRemoveBlock):
(JSC::IsoCellSet::sweepToFreeList):
* heap/IsoCellSetInlines.h:
(JSC::IsoCellSet::forEachMarkedCellInParallel):
* heap/IsoSubspace.cpp:
(JSC::IsoSubspace::IsoSubspace):
* heap/IsoSubspacePerVM.cpp:
(JSC::IsoSubspacePerVM::forVM):
* heap/LocalAllocator.cpp:
(JSC::LocalAllocator::LocalAllocator):
(JSC::LocalAllocator::~LocalAllocator):
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::tryCopyOtherThreadStacks):
(JSC::MachineThreads::gatherConservativeRoots):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::stopAllocating):
(JSC::MarkedBlock::Handle::resumeAllocating):
(JSC::MarkedBlock::aboutToMarkSlow):
(JSC::MarkedBlock::Handle::didConsumeFreeList):
(JSC::MarkedBlock::noteMarkedSlow):
(JSC::MarkedBlock::Handle::dumpState):
* heap/MarkedBlockInlines.h:
(JSC::MarkedBlock::Handle::isLive):
* heap/MarkingConstraint.cpp:
(JSC::MarkingConstraint::doParallelWork):
* heap/MarkingConstraintSolver.cpp:
(JSC::MarkingConstraintSolver::addParallelTask):
(JSC::MarkingConstraintSolver::runExecutionThread):
* heap/ParallelSourceAdapter.h:
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::updateMutatorIsStopped):
(JSC::SlotVisitor::drain):
(JSC::SlotVisitor::performIncrementOfDraining):
(JSC::SlotVisitor::drainFromShared):
(JSC::SlotVisitor::drainInParallelPassively):
(JSC::SlotVisitor::waitForTermination):
(JSC::SlotVisitor::donateAll):
(JSC::SlotVisitor::didRace):
* heap/Subspace.cpp:
(JSC::Subspace::parallelDirectorySource):
* heap/SubspaceInlines.h:
(JSC::Subspace::forEachMarkedCellInParallel):
* inspector/JSInjectedScriptHost.cpp:
* jit/ExecutableAllocator.cpp:
* jsc.cpp:
(Worker::Worker):
(Worker::~Worker):
(Worker::dequeue):
(Workers::broadcast):
(Workers::report):
(Workers::tryGetReport):
(Workers::getReport):
(JSC_DEFINE_HOST_FUNCTION):
* runtime/DeferredWorkTimer.cpp:
(JSC::DeferredWorkTimer::doWork):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::finishCreation):
* runtime/EvalExecutable.cpp:
(JSC::EvalExecutable::visitChildrenImpl):
* runtime/FileBasedFuzzerAgentBase.cpp:
(JSC::FileBasedFuzzerAgentBase::getPrediction):
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::visitChildrenImpl):
* runtime/JSArray.cpp:
(JSC::JSArray::shiftCountWithArrayStorage):
(JSC::JSArray::unshiftCountWithArrayStorage):
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::detach):
(JSC::JSArrayBufferView::slowDownAndWasteMemory):
* runtime/JSCell.h:
* runtime/JSFinalizationRegistry.cpp:
(JSC::JSFinalizationRegistry::visitChildrenImpl):
(JSC::JSFinalizationRegistry::finalizeUnconditionally):
(JSC::JSFinalizationRegistry::takeDeadHoldingsValue):
(JSC::JSFinalizationRegistry::registerTarget):
(JSC::JSFinalizationRegistry::unregister):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::visitChildrenImpl):
* runtime/JSGlobalObject.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::finishCreation):
(JSC::JSModuleNamespaceObject::visitChildrenImpl):
* runtime/JSObject.cpp:
(JSC::JSObject::visitButterflyImpl):
* runtime/JSRunLoopTimer.cpp:
(JSC::JSRunLoopTimer::Manager::timerDidFire):
(JSC::JSRunLoopTimer::Manager::registerVM):
(JSC::JSRunLoopTimer::Manager::unregisterVM):
(JSC::JSRunLoopTimer::Manager::scheduleTimer):
(JSC::JSRunLoopTimer::Manager::cancelTimer):
(JSC::JSRunLoopTimer::Manager::timeUntilFire):
(JSC::JSRunLoopTimer::timerDidFire):
(JSC::JSRunLoopTimer::setTimeUntilFire):
(JSC::JSRunLoopTimer::cancelTimer):
(JSC::JSRunLoopTimer::addTimerSetNotification):
(JSC::JSRunLoopTimer::removeTimerSetNotification):
* runtime/JSSegmentedVariableObject.cpp:
(JSC::JSSegmentedVariableObject::findVariableIndex):
(JSC::JSSegmentedVariableObject::addVariables):
(JSC::JSSegmentedVariableObject::visitChildrenImpl):
* runtime/ModuleProgramExecutable.cpp:
(JSC::ModuleProgramExecutable::visitChildrenImpl):
* runtime/NarrowingNumberPredictionFuzzerAgent.cpp:
(JSC::NarrowingNumberPredictionFuzzerAgent::getPrediction):
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::visitChildrenImpl):
* runtime/RandomizingFuzzerAgent.cpp:
(JSC::RandomizingFuzzerAgent::getPrediction):
* runtime/RegExp.cpp:
(JSC::RegExp::compile):
(JSC::RegExp::matchConcurrently):
(JSC::RegExp::compileMatchOnly):
(JSC::RegExp::deleteCode):
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::takeSample):
(JSC::SamplingProfiler::stackTracesAsJSON):
(JSC::SamplingProfiler::reportTopFunctions):
(JSC::SamplingProfiler::reportTopBytecodes):
* runtime/ScriptExecutable.cpp:
(JSC::ScriptExecutable::createTemplateObject):
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::add):
(JSC::SparseArrayValueMap::remove):
(JSC::SparseArrayValueMap::getConcurrently):
(JSC::SparseArrayValueMap::visitChildrenImpl):
* runtime/Structure.cpp:
(JSC::Structure::changePrototypeTransition):
(JSC::Structure::toDictionaryTransition):
(JSC::Structure::nonPropertyTransitionSlow):
(JSC::Structure::setBrandTransition):
* runtime/StructureCache.cpp:
(JSC::StructureCache::createEmptyStructure):
(JSC::StructureCache::emptyObjectStructureConcurrently):
* runtime/VM.cpp:
(JSC::waitForVMDestruction):
(JSC::VM::~VM):
(JSC::VM::gatherScratchBufferRoots):
(JSC::VM::scratchBufferForSize):
(JSC::VM::clearScratchBuffers):
(JSC::VM::addLoopHintExecutionCounter):
(JSC::VM::getLoopHintExecutionCounter):
(JSC::VM::removeLoopHintExecutionCounter):
* runtime/VMTraps.cpp:
(JSC::VMTraps::tryInstallTrapBreakpoints):
(JSC::VMTraps::invalidateCodeBlocksOnStack):
(JSC::VMTraps::willDestroyVM):
(JSC::VMTraps::fireTrap):
(JSC::VMTraps::handleTraps):
(JSC::VMTraps::takeTopPriorityTrap):
* runtime/WeakMapImpl.cpp:
(JSC::WeakMapImpl<BucketType>::visitOutputConstraints):
* runtime/WeakMapImpl.h:
(JSC::WeakMapImpl::finishCreation):
* runtime/WeakMapImplInlines.h:
(JSC::WeakMapImpl<WeakMapBucket>::rehash):
* runtime/WideningNumberPredictionFuzzerAgent.cpp:
(JSC::WideningNumberPredictionFuzzerAgent::getPrediction):
* tools/CompilerTimingScope.cpp:
* tools/FunctionOverrides.cpp:
(JSC::FunctionOverrides::FunctionOverrides):
(JSC::FunctionOverrides::reinstallOverrides):
(JSC::FunctionOverrides::initializeOverrideFor):
* tools/Integrity.cpp:
(JSC::Integrity::Random::reloadAndCheckShouldAuditSlow):
* tools/VMInspector.cpp:
(JSC::VMInspector::add):
(JSC::VMInspector::remove):
(JSC::VMInspector::codeBlockForMachinePC):
* wasm/WasmBBQPlan.cpp:
(JSC::Wasm::BBQPlan::work):
(JSC::Wasm::BBQPlan::compileFunction):
* wasm/WasmCalleeRegistry.h:
(JSC::Wasm::CalleeRegistry::registerCallee):
(JSC::Wasm::CalleeRegistry::unregisterCallee):
* wasm/WasmCodeBlock.cpp:
(JSC::Wasm::CodeBlock::CodeBlock):
(JSC::Wasm::CodeBlock::waitUntilFinished):
(JSC::Wasm::CodeBlock::compileAsync):
* wasm/WasmContext.cpp:
(JSC::Wasm::Context::scratchBufferForSize):
* wasm/WasmEntryPlan.cpp:
(JSC::Wasm::EntryPlan::parseAndValidateModule):
(JSC::Wasm::EntryPlan::prepare):
(JSC::Wasm::EntryPlan::compileFunctions):
* wasm/WasmEntryPlan.h:
(JSC::Wasm::EntryPlan::tryReserveCapacity):
* wasm/WasmFaultSignalHandler.cpp:
(JSC::Wasm::trapHandler):
* wasm/WasmInstance.cpp:
(JSC::Wasm::Instance::setFunctionWrapper):
* wasm/WasmLLIntPlan.cpp:
(JSC::Wasm::LLIntPlan::compileFunction):
(JSC::Wasm::LLIntPlan::completeInStreaming):
(JSC::Wasm::LLIntPlan::didCompileFunctionInStreaming):
(JSC::Wasm::LLIntPlan::didFailInStreaming):
* wasm/WasmMachineThreads.cpp:
(JSC::Wasm::resetInstructionCacheOnAllThreads):
* wasm/WasmMemory.cpp:
(JSC::Wasm::Memory::growShared):
* wasm/WasmModule.cpp:
(JSC::Wasm::Module::getOrCreateCodeBlock):
* wasm/WasmOMGForOSREntryPlan.cpp:
(JSC::Wasm::OMGForOSREntryPlan::work):
* wasm/WasmOMGPlan.cpp:
(JSC::Wasm::OMGPlan::work):
* wasm/WasmOperations.cpp:
(JSC::Wasm::triggerOMGReplacementCompile):
(JSC::Wasm::JSC_DEFINE_JIT_OPERATION):
* wasm/WasmSignatureInlines.h:
(JSC::Wasm::SignatureInformation::get):
* wasm/WasmSlowPaths.cpp:
(JSC::LLInt::jitCompileAndSetHeuristics):
(JSC::LLInt::WASM_SLOW_PATH_DECL):
* wasm/WasmStreamingCompiler.cpp:
(JSC::Wasm::StreamingCompiler::didCompileFunction):
(JSC::Wasm::StreamingCompiler::finalize):
(JSC::Wasm::StreamingCompiler::fail):
(JSC::Wasm::StreamingCompiler::cancel):
* wasm/WasmStreamingPlan.cpp:
(JSC::Wasm::StreamingPlan::work):
* wasm/WasmTable.cpp:
(JSC::Wasm::Table::grow):
(JSC::Wasm::Table::visitAggregateImpl):
* wasm/WasmThunks.cpp:
(JSC::Wasm::Thunks::stub):
(JSC::Wasm::Thunks::existingStub):
* wasm/WasmWorklist.cpp:
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::visitChildrenImpl):
2021-05-21 Mark Lam <mark.lam@apple.com>
Remove the unnecessary use of CompileOpStrictEqType.
https://bugs.webkit.org/show_bug.cgi?id=226121
Reviewed by Saam Barati and Robin Morisset.
We're already emitting template code. Might as well make the relevant condition
checks a build time check on the opcode type the template is specializing on
instead of a runtime check on a passed in CompileOpStrictEqType.
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(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):
* jit/JITOpcodes32_64.cpp:
(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):
2021-05-21 Mark Lam <mark.lam@apple.com>
Introducing JITThunks::preinitializeCTIThunks().
https://bugs.webkit.org/show_bug.cgi?id=226105
Reviewed by Geoffrey Garen.
We're basically renaming JITThunks::preinitializeExtraCTIThunks() to
JITThunks::preinitializeCTIThunks() and making it not conditional on
#if ENABLE(EXTRA_CTI_THUNKS). Some thunks need to be initialized independent of
#if ENABLE(EXTRA_CTI_THUNKS).
* jit/JITThunks.cpp:
(JSC::JITThunks::preinitializeCTIThunks):
(JSC::JITThunks::preinitializeExtraCTIThunks): Deleted.
* jit/JITThunks.h:
* runtime/VM.cpp:
(JSC::VM::VM):
2021-05-21 Adrian Perez de Castro <aperez@igalia.com>
Non-unified build fixes, late-ish May 2021 edition
https://bugs.webkit.org/show_bug.cgi?id=225990
Unreviewed non-unified build fixes.
* jit/CCallHelpers.cpp: Add missing LinkBuffer.h header.
2021-05-21 Sam Sneddon <gsnedders@apple.com>
Fix Python 3.6+ DeprecationWarnings about unknown escapes
https://bugs.webkit.org/show_bug.cgi?id=226018
Reviewed by Jonathan Bedard.
Fix Python 3.6+ DeprecationWarnings about unknown escapes
* wasm/generateWasmB3IRGeneratorInlinesHeader.py:
2021-05-20 Saam Barati <sbarati@apple.com>
[ Catalina Release JSC] A large number of JSC test appear to be flaky failing
https://bugs.webkit.org/show_bug.cgi?id=225998
<rdar://problem/78235001>
Reviewed by Yusuke Suzuki.
This patch is fixing some fallout from moving JIT::link() to a background
thread:
1. We can't shrink the CodeBlock's constant pool on a background thread
since we read from it without grabbing a lock on the main thread (when
reading things off the stack in slow path calls).
2. We can't create GCAwareJITStubRoutines on the compilation thread, since
creating a GCAwareJITStubRoutines adds to a global hash table inside Heap. This
means that we have to do that step of emitting virtual calls for eval when
we're finalizing code on the main thread.
This patch also makes it so that a baseline JIT compilation thread is
correctly marked as such.
* heap/JITStubRoutineSet.cpp:
(JSC::JITStubRoutineSet::add):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitUnlinkedVirtualCall):
(JSC::AssemblyHelpers::emitVirtualCall):
* jit/AssemblyHelpers.h:
* jit/JIT.cpp:
(JSC::JIT::link):
(JSC::JIT::finalizeOnMainThread):
* jit/JIT.h:
* jit/JITCall.cpp:
(JSC::JIT::compileCallEvalSlowCase):
* jit/JITCall32_64.cpp:
(JSC::JIT::compileCallEvalSlowCase):
* jit/JITWorklist.cpp:
2021-05-20 Saam Barati <sbarati@apple.com>
Make polymorphic calls play nice with Data Call ICs
https://bugs.webkit.org/show_bug.cgi?id=225793
Reviewed by Robin Morisset.
This patch makes it so that Polymorphic stubs don't repatch when using
Data Call ICs. We add a branch to the Data IC fast path to see if we're
polymorphic. If we are, then we either call or tail call the polymorphic
stub, depending on the CallLinkInfo's call type. This patch also changes
the polymorphic stub to handle being called instead of jumped to, since that
will now happen for Data ICs of non tail calls.
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::setMonomorphicCallee):
(JSC::CallLinkInfo::callee):
(JSC::CallLinkInfo::visitWeak):
(JSC::CallLinkInfo::emitFastPathImpl):
(JSC::CallLinkInfo::revertCallToStub):
(JSC::CallLinkInfo::setStub):
(JSC::CallLinkInfo::emitFirstInstructionForDataIC): Deleted.
* bytecode/CallLinkInfo.h:
* jit/Repatch.cpp:
(JSC::linkPolymorphicCall):
2021-05-20 Tuomas Karkkainen <tuomas.webkit@apple.com>
$vm should have a function for checking if ASan is enabled similar to $vm.assertEnabled
https://bugs.webkit.org/show_bug.cgi?id=226019
Reviewed by Mark Lam.
Add method $vm.asanEnabled(), which parallels $vm.assertEnabled(), and allows checking at
runtime whether the current JavaScriptCore build is instrumented with AddressSanitizer.
* tools/JSDollarVM.cpp:
2021-05-19 Mark Lam <mark.lam@apple.com>
AbstractSlotVisitor::containsOpaqueRoot() should only declare didFindOpaqueRoot if the root is actually found.
https://bugs.webkit.org/show_bug.cgi?id=226000
rdar://78208014
Reviewed by Robin Morisset.
It was erroneously calling didFindOpaqueRoot() all the time even when the root is
not found. This only affects the GC verifier tool. It has no effect on production
code.
* heap/AbstractSlotVisitorInlines.h:
(JSC::AbstractSlotVisitor::containsOpaqueRoot const):
2021-05-19 Mark Lam <mark.lam@apple.com>
Speed up debug validation in CacheableIdentifier::createFromIdentifierOwnedByCodeBlock().
https://bugs.webkit.org/show_bug.cgi?id=225948
Not reviewed.
Build fix after r277727.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::hasIdentifier):
2021-05-19 Mark Lam <mark.lam@apple.com>
Ripping out broken Baseline JIT rare case profiling.
https://bugs.webkit.org/show_bug.cgi?id=225983
Reviewed by Saam Barati and Robin Morisset.
The profiling has been broken in recent times. Fixing it to work does not appear
to improve performance. Ripping out the profiling appears to not hurt performance.
However, ripping out the profiling appears to save on code size generated for the
Baseline JIT.
Base New Diff
BaselineJIT: 73299112 (69.903481 MB) 65910128 (62.856796 MB) 0.90x (reduction)
DFG: 36850540 (35.143414 MB) 36374400 (34.689331 MB) 0.99x
Thunk: 23128652 (22.057201 MB) 22892292 (21.831791 MB) 0.99x
InlineCache: 22210972 (21.182034 MB) 22083508 (21.060474 MB) 0.99x
FTL: 6065064 (5.784096 MB) 6128080 (5.844193 MB) 1.01x
Wasm: 2305124 (2.198338 MB) 2309732 (2.202732 MB) 1.00x
YarrJIT: 1522712 (1.452171 MB) 1536104 (1.464943 MB) 1.01x
CSSJIT: 0 0
Uncategorized: 0 0
Cumulative diff since the start of this effort to put more code in JIT thunks:
Base New Diff
BaselineJIT: 89089964 (84.962811 MB) 65910128 (62.856796 MB) 0.74x (reduction)
DFG: 39117360 (37.305222 MB) 36374400 (34.689331 MB) 0.93x (reduction)
Thunk: 23230968 (22.154778 MB) 22892292 (21.831791 MB) 0.99x
InlineCache: 22027416 (21.006981 MB) 22083508 (21.060474 MB) 1.00x
FTL: 6575772 (6.271145 MB) 6128080 (5.844193 MB) 0.93x (reduction)
Wasm: 2302724 (2.196049 MB) 2309732 (2.202732 MB) 1.00x
YarrJIT: 1538956 (1.467663 MB) 1536104 (1.464943 MB) 1.00x
CSSJIT: 0 0
Uncategorized: 0 0
Benchmarking was done with Speedometer2 and JetSteam2 on an M1 Mac.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::JITData::size const):
(JSC::CodeBlock::dumpValueProfiles):
(JSC::CodeBlock::setRareCaseProfiles): Deleted.
(JSC::CodeBlock::rareCaseProfileForBytecodeIndex): Deleted.
(JSC::CodeBlock::rareCaseProfileCountForBytecodeIndex): Deleted.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::likelyToTakeSlowCase): Deleted.
(JSC::CodeBlock::couldTakeSlowCase): Deleted.
* bytecode/ValueProfile.h:
(JSC::RareCaseProfile::RareCaseProfile): Deleted.
(JSC::getRareCaseProfileBytecodeIndex): Deleted.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::makeSafe):
(JSC::DFG::ByteCodeParser::parseBlock):
* jit/JIT.cpp:
(JSC::JIT::privateCompileSlowCases):
2021-05-19 Yusuke Suzuki <ysuzuki@apple.com>
[JSC} Remove exception checks from non-throwing function calls in Baseline JIT
https://bugs.webkit.org/show_bug.cgi?id=224920
Reviewed by Tadeu Zagallo.
These functions are not taking JSGlobalObject and will not throw an error.
Use callOperationNoExceptionCheck instead to avoid emitting unnecessary exception checks.
* jit/JIT.cpp:
(JSC::JIT::emitEnterOptimizationCheck):
* jit/JITOpcodes.cpp:
(JSC::JIT::emitSlow_op_new_object):
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emitSlow_op_loop_hint):
(JSC::JIT::emit_op_profile_type):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emitSlow_op_new_object):
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emit_op_profile_type):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitWriteBarrier):
2021-05-19 Robin Morisset <rmorisset@apple.com>
Fix typo in AirUseCounts
https://bugs.webkit.org/show_bug.cgi?id=225977
rdar://78210501
Reviewed by Mark Lam.
I had just messed up a copy-and-paste, using "gp" instead of "fp" in code that deals with floating point values.
This did not show in my tests, probably because few functions have more floating point temporaries than non-floating-point.
* b3/air/AirUseCounts.h:
(JSC::B3::Air::UseCounts::UseCounts):
2021-05-18 Darin Adler <darin@apple.com>
Move CFStringRef and NSString support from StringBuilder into StringConcatenateCF
https://bugs.webkit.org/show_bug.cgi?id=225839
Reviewed by Sam Weinig.
* inspector/ConsoleMessage.cpp:
(Inspector::ConsoleMessage::ConsoleMessage): Use StringBuilder::clear instead of
StringBuilder::resize; no advantage to the latter after calling StringBuilder::toString.
* runtime/JSONObject.cpp:
(JSC::Stringifier::Holder::appendNextProperty): Update for name change of
StringBuilder::resize to StringBuilder::shrink.
* runtime/TypeSet.cpp:
(JSC::StructureShape::stringRepresentation): Ditto.
2021-05-19 Mark Lam <mark.lam@apple.com>
Speed up debug validation in CacheableIdentifier::createFromIdentifierOwnedByCodeBlock().
https://bugs.webkit.org/show_bug.cgi?id=225948
rdar://78175542
Reviewed by Yusuke Suzuki.
1. Introduce CodeBlock::hasIdentifier() so that we can encapsulate the identifier
search better. Change CacheableIdentifier::createFromIdentifierOwnedByCodeBlock()
to call this method instead of rolling its own identifier search.
2. If the CodeBlock is pathological and has a ridiculous number of identifiers
to search, create a cached hash set of the identifiers, and use that for
doing the search instead.
Apparently, YouTube can have a single JS function with 2177689 bytecodes, where
a large portion of those are put_by_ids. The function also has some 17k+
identifiers. With that may bytecodes doing a validation search on 17k+
identifiers in a Debug build, the site can become un-useable. This optimization
brings it back from un-useable to barely tolerable on the Debug build.
3. Also fetch the UnlinkedCodeBlock from the WriteBarrier field just once in
CodeBlock::identifier() and CodeBlock::hasIdentifier(). This may not matter
on a Release build, but it can add up on a Debug build, which is already slow.
We should try to avoid doing redundant validation via the WriteBarrier access.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::identifier const):
(JSC::CodeBlock::hasIdentifier):
* bytecode/CodeBlock.h:
* runtime/CacheableIdentifierInlines.h:
(JSC::CacheableIdentifier::createFromIdentifierOwnedByCodeBlock):
2021-05-19 Saam Barati <sbarati@apple.com>
Link Baseline JIT code off the main thread
https://bugs.webkit.org/show_bug.cgi?id=225940
Reviewed by Yusuke Suzuki.
This patch makes JIT::link() able to run on compiler threads.
Most of what the function was already doing happily remains the
same. This patch moves a few operations to JIT::finalizeOnMainThread
for things that can't happen on the compiler thread:
- Adding data to some global hash tables which aren't synchronized.
- Setting the JITCode.
- Setting the code pointer for exception handlers.
- Some other metadata the Sampling Profiler looks at.
* jit/JIT.cpp:
(JSC::JIT::compileAndLinkWithoutFinalizing):
(JSC::JIT::link):
(JSC::JIT::finalizeOnMainThread):
(JSC::JIT::privateCompile):
(JSC::JIT::compileWithoutLinking): Deleted.
* jit/JIT.h:
* jit/JITWorklist.cpp:
(JSC::JITWorklist::Plan::compileInThread):
(JSC::JITWorklist::Plan::finalize):
(JSC::JITWorklist::Plan::compileOnMainThreadNow):
(JSC::JITWorklist::compileLater):
(JSC::JITWorklist::compileOnMainThreadNow):
(JSC::JITWorklist::finalizePlans):
(JSC::JITWorklist::Plan::compileNow): Deleted.
(JSC::JITWorklist::compileNow): Deleted.
* jit/JITWorklist.h:
2021-05-18 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Prune CommonSlowPaths of JITPropertyAccess functions
https://bugs.webkit.org/show_bug.cgi?id=225953
Reviewed by Mark Lam.
A few bytecode operations with slow paths in JITPropertyAccess appear to have either redundant or unnecessary
"common" slow paths; namely, get_private_name and del_by_val already have LLInt slow paths, while in_by_id
and get_by_id_with_this can have their "common" slow path moved to be LLInt-specific.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
* runtime/CommonSlowPaths.cpp:
* runtime/CommonSlowPaths.h:
2021-05-18 Robin Morisset <rmorisset@apple.com>
Make AirAllocateRegistersByGraphColoring use less memory
https://bugs.webkit.org/show_bug.cgi?id=225848
Reviewed by Filip Pizlo.
We've had some jetsam problems caused by the main Air register allocator, which caused us to lower Options::maximumTmpsForGraphColoring.
Hence this patch tries to improve the memory usage of the allocator. It includes several changes:
- Change the datastructure used for representing the interference graph. Before it was effectively a HashSet<std::pair<uint16_t, uint16_t>. Now, it is either a Bitvector (for n < 400 for now, can be tweaked easily), or a Vector<LikelyDenseUnsignedIntegerSet<uint16_t>> otherwise.
LikelyDenseUnsignedIntegerSet is a new datastructure introduced by this patch, it is either a HashSet if very sparse, or a BitVector + an amount to shift it by.
This is by far the largest memory reduction in this patch, it reduces the maximum memory used for an interference graph in tsf-wasm in JetStream2 from 16MB to 700kB, and in mruby-wasm.aotoki.dev from 262MB to 20MB (the later only happen when we increase Options::maximumTmpsForGraphColoring.. this is the exact function which caused us to lower it).
Its effect on smaller functions in JetStream2 is rarely as dramatic but always an improvement, and improvements between 2x and 5x are extremely common (10x to 30x are significantly rarer but do occur).
- In order to easily test this change and any further change to this datastructure, the old approach was preserved as InterferenceHashSet, and a template to run two such datastructures in parallel, checking their equivalence was added: InstrumentedInterferenceGraph. Running with it and reportInterferenceGraphMemoryUse set to true was used to compute the numbers given above.
- There was already some template parameter to change the size of the tmp indices from unsigned to uint16_t but the code failed to compile unless it was unsigned. I fixed this, made more consistent use of it, and switched to uint16_t in the very common case that we have less than 65k Tmps (we can have more despite the option because of spilling). This halved the memory usage of various other datastructures in the register allocator
- unspillableTmps was a HashSet<unsigned>. Since it is often quite dense (often around 20% on JetStream2), I replaced it by a Bitvector instead
- m_biases was a HashMap<IndexType, HashSet<IndexType>>. Since it is extremely rare that the sets have more than 8 elements (from looking at some instrumented run of JetStream2), I replaced it by HashMap<IndexType, SmallSet<IndexType>>. This not only significantly reduces memory, but nearly halves the time spent in assignColors(around 80ms -> 40ms in JetStream 2)
- UseCounts was needlessly general: it is only used by the register allocator (all other references to UseCounts refer to the completely different B3::UseCounts), so there is no point in it computing, and then storing lots of irrelevant data. A float is also more than enough precision (especially since it is pretty much always 1, 10, 100, or 1000 in practice…). Also, since we only need it indexed by Tmps, we can use a Vector with AbsoluteTmpMapper instead of its HashMap. These changes are not just memory savings, they also make selectSpill way faster (570ms -> 250ms on my machine on JetStream2)
- While I was at it, I did a couple of other tweaks to the logic of selectSpill. In particular, instead of having to check for isFastTmp every time, I just put the fast tmps directly in unspillableTmps, which prevents them from getting added to m_spillWorklist in the first place. This + a bit of clean-up (for example putting an early exit instead of setting score to infinity in the case of dead tmps) resulted in a further perf win (to roughly 200ms spent in selectSpill() on JetStream2)
All together, this patch reduces the time spent in the register allocator by roughly 15 to 20% in JetStream2 (tested both with the Briggs and the IRC allocators on my MBP 2019).
I do not yet have precise performance numbers for this exact patch, but benchmarking a previous version of it (with a less optimized interference graph) resulted in significant RAMification improvements (around 1%), and more surprisingly some JetStream2 improvements on weaker machines (e.g. an iPhone 7 gained > 1%). I believe these gains come either from less trashing of the caches, or less contention caused by the memory traffic.
I will try to update the bugzilla with more up-to-date thorough results when I get them.
This patch does not increase Options::maximumTmpsForGraphColoring, I intend to do that in a separate patch to make it easier to revert in case of a problem.
* b3/B3ReduceLoopStrength.cpp:
(JSC::B3::ReduceLoopStrength::reduceByteCopyLoopsToMemcpy):
* b3/air/AirAllocateRegistersAndStackByLinearScan.cpp:
* b3/air/AirAllocateRegistersByGraphColoring.cpp:
(JSC::B3::Air::allocateRegistersByGraphColoring):
* b3/air/AirCode.h:
(JSC::B3::Air::Code::forEachFastTmp const):
* b3/air/AirUseCounts.h:
(JSC::B3::Air::UseCounts::UseCounts):
(JSC::B3::Air::UseCounts::isConstDef const):
(JSC::B3::Air::UseCounts::numWarmUsesAndDefs const):
(JSC::B3::Air::UseCounts::dump const):
* parser/Nodes.h:
2021-05-18 Saam Barati <sbarati@apple.com>
Add Data Call ICs that don't repatch and use them in the baseline JIT
https://bugs.webkit.org/show_bug.cgi?id=225321
<rdar://problem/77773796>
Reviewed by Michael Saboff.
This patch adds Data ICs for calls. Data ICs for calls work by loading a code
pointer from CallLinkInfo, and indirect calling that pointer. This means that
to repatch such an IC, all we need to do is replace a code pointer inside
CallLinkInfo. No need to repatch the JIT code.
The current implementation only does this for monomorphic calls. We still
repatch the JIT code for polymorphic calls. In a followup, we will also
opt polymorphic call ICs into data-based calls:
https://bugs.webkit.org/show_bug.cgi?id=225793
This patch only uses Data Call ICs for the Baseline JIT. Even with that, it
reduces the number of calls to cacheFlush by ~45% on JetStream2.
Performance is neutral on AS Macs, but it paves the way towards doing
unlinked JITting in JSC.
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::addLateLinkTask):
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::linkCode):
(JSC::LinkBuffer::performFinalization):
* assembler/LinkBuffer.h:
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateImpl):
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::CallLinkInfo):
(JSC::CallLinkInfo::unlink):
(JSC::CallLinkInfo::fastPathStart):
(JSC::CallLinkInfo::slowPathStart):
(JSC::CallLinkInfo::doneLocation):
(JSC::CallLinkInfo::setMonomorphicCallee):
(JSC::CallLinkInfo::clearCallee):
(JSC::CallLinkInfo::emitFirstInstructionForDataIC):
(JSC::CallLinkInfo::emitFastPathImpl):
(JSC::CallLinkInfo::emitFastPath):
(JSC::CallLinkInfo::emitTailCallFastPath):
(JSC::CallLinkInfo::emitSlowPath):
(JSC::CallLinkInfo::emitDirectFastPath):
(JSC::CallLinkInfo::emitDirectTailCallFastPath):
(JSC::CallLinkInfo::initializeDirectCall):
(JSC::CallLinkInfo::setDirectCallTarget):
(JSC::CallLinkInfo::setSlowPathCallDestination):
(JSC::CallLinkInfo::revertCallToStub):
(JSC::CallLinkInfo::setStub):
(JSC::CallLinkInfo::callReturnLocation): Deleted.
(JSC::CallLinkInfo::patchableJump): Deleted.
(JSC::CallLinkInfo::hotPathBegin): Deleted.
(JSC::CallLinkInfo::setCallee): Deleted.
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::calleeGPR const):
(JSC::CallLinkInfo::isDataIC const):
(JSC::CallLinkInfo::setUsesDataICs):
(JSC::CallLinkInfo::setCodeLocations):
(JSC::CallLinkInfo::offsetOfCallee):
(JSC::CallLinkInfo::offsetOfMonomorphicCallDestination):
(JSC::CallLinkInfo::offsetOfSlowPathCallDestination):
(JSC::CallLinkInfo::setCallLocations): Deleted.
(JSC::CallLinkInfo::hotPathOther): Deleted.
(JSC::CallLinkInfo::setStub): Deleted.
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::addJSCall):
(JSC::DFG::JITCompiler::addJSDirectCall):
(JSC::DFG::JITCompiler::JSCallRecord::JSCallRecord):
(JSC::DFG::JITCompiler::JSDirectCallRecord::JSDirectCallRecord):
(JSC::DFG::JITCompiler::addJSDirectTailCall): Deleted.
(JSC::DFG::JITCompiler::JSDirectTailCallRecord::JSDirectTailCallRecord): Deleted.
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::callerReturnPC):
* dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
* jit/CCallHelpers.cpp:
(JSC::CCallHelpers::emitJITCodeOver):
* jit/CCallHelpers.h:
* jit/JIT.cpp:
(JSC::JIT::link):
* jit/JIT.h:
* jit/JITCall.cpp:
(JSC::JIT::compileTailCall):
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
* jit/JITCall32_64.cpp:
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
* jit/JITOperations.cpp:
(JSC::JSC_DEFINE_JIT_OPERATION):
* jit/PolymorphicCallStubRoutine.cpp:
(JSC::PolymorphicCallNode::unlink):
* jit/Repatch.cpp:
(JSC::linkSlowPathTo):
(JSC::linkSlowFor):
(JSC::linkMonomorphicCall):
(JSC::linkDirectCall):
(JSC::revertCall):
(JSC::unlinkCall):
(JSC::linkPolymorphicCall):
(JSC::linkFor): Deleted.
(JSC::linkDirectFor): Deleted.
(JSC::unlinkFor): Deleted.
* jit/Repatch.h:
* wasm/js/WasmToJS.cpp:
(JSC::Wasm::wasmToJS):
2021-05-18 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r276655.
https://bugs.webkit.org/show_bug.cgi?id=225930
caused a 2% PLT regression
Reverted changeset:
"StructureStubInfo and PolymorphicAccess should account for
their non-GC memory"
https://bugs.webkit.org/show_bug.cgi?id=225113
https://trac.webkit.org/changeset/276655
2021-05-18 Keith Miller <keith_miller@apple.com>
Temporarily revert r276592 as it breaks some native apps
https://bugs.webkit.org/show_bug.cgi?id=225917
Unreviewed, revert.
* API/JSCallbackObject.h:
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::put):
* debugger/DebuggerScope.h:
* runtime/ClassInfo.h:
* runtime/ClonedArguments.h:
* runtime/CustomGetterSetter.cpp:
(JSC::callCustomSetter):
* runtime/CustomGetterSetter.h:
* runtime/ErrorConstructor.h:
* runtime/ErrorInstance.h:
* runtime/GenericArguments.h:
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments<Type>::put):
* runtime/GetterSetter.h:
* runtime/JSArray.cpp:
(JSC::JSArray::put):
* runtime/JSArray.h:
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::put):
* runtime/JSArrayBufferView.h:
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive):
* runtime/JSCell.cpp:
(JSC::JSCell::doPutPropertySecurityCheck):
* runtime/JSCell.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::put):
* runtime/JSFunction.h:
* runtime/JSGenericTypedArrayView.h:
* runtime/JSGlobalLexicalEnvironment.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::put):
* runtime/JSGlobalObject.h:
* runtime/JSLexicalEnvironment.h:
* runtime/JSModuleEnvironment.h:
* runtime/JSModuleNamespaceObject.h:
* runtime/JSObject.cpp:
(JSC::JSObject::doPutPropertySecurityCheck):
(JSC::JSObject::putInlineSlow):
(JSC::JSObject::prototypeChainMayInterceptStoreTo):
(JSC::definePropertyOnReceiverSlow): Deleted.
(JSC::JSObject::definePropertyOnReceiver): Deleted.
(JSC::JSObject::putInlineFastReplacingStaticPropertyIfNeeded): Deleted.
* runtime/JSObject.h:
(JSC::JSObject::putByIndexInline):
(JSC::JSObject::doPutPropertySecurityCheck):
(JSC::JSObject::hasNonReifiedStaticProperties): Deleted.
* runtime/JSObjectInlines.h:
(JSC::JSObject::canPerformFastPutInlineExcludingProto):
(JSC::JSObject::putInlineForJSObject):
(JSC::JSObject::putDirectInternal):
(JSC::JSObject::putInlineFast): Deleted.
* runtime/JSProxy.h:
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::overridesGetOwnPropertySlot const):
(JSC::TypeInfo::overridesAnyFormOfGetOwnPropertyNames const):
(JSC::TypeInfo::hasPutPropertySecurityCheck const):
(JSC::TypeInfo::hasStaticPropertyTable const): Deleted.
(JSC::TypeInfo::overridesPut const): Deleted.
* runtime/Lookup.h:
(JSC::putEntry):
(JSC::lookupPut):
* runtime/PropertySlot.h:
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::put):
* runtime/ProxyObject.h:
* runtime/PutPropertySlot.h:
(JSC::PutPropertySlot::PutPropertySlot):
(JSC::PutPropertySlot::context const):
(JSC::PutPropertySlot::type const):
(JSC::PutPropertySlot::isInitialization const):
(JSC::PutPropertySlot::isTaintedByOpaqueObject const): Deleted.
(JSC::PutPropertySlot::setIsTaintedByOpaqueObject): Deleted.
* runtime/ReflectObject.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::put):
* runtime/RegExpObject.h:
* runtime/StringObject.cpp:
(JSC::StringObject::put):
* runtime/StringObject.h:
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
(JSC::StringPrototype::create):
* runtime/StringPrototype.h:
* runtime/Structure.cpp:
(JSC::Structure::validateFlags):
* runtime/Structure.h:
(JSC::Structure::takesSlowPathInDFGForImpureProperty):
(JSC::Structure::hasNonReifiedStaticProperties const): Deleted.
* tools/JSDollarVM.cpp:
2021-05-18 Yoshiaki Jitsukawa <yoshiaki.jitsukawa@sony.com>
[PlayStation] Fix PlayStation port
https://bugs.webkit.org/show_bug.cgi?id=225913
Reviewed by Don Olmstead.
Fix PlayStation port
* jsc.cpp: Include LinkBuffer.h.
2021-05-18 Adrian Perez de Castro <aperez@igalia.com>
[JSCOnly] Non unified build fixes
https://bugs.webkit.org/show_bug.cgi?id=225872
Unreviewed non-unified build fixes.
* jit/JITPropertyAccess.cpp: Add missing ThunkGenerators.h header.
* jit/SlowPathCall.cpp: Add missing JITInlines.h and ThunkGenerators.h headers.
* wasm/js/WebAssemblyFunctionBase.h: Add missing WasmFormat.h header.
2021-05-17 Saam Barati <sbarati@apple.com>
Enable JS to emit sign posts and trace points under Options::exposeProfilersOnGlobalObject
https://bugs.webkit.org/show_bug.cgi?id=225895
Reviewed by Yusuke Suzuki.
* runtime/JSGlobalObject.cpp:
(JSC::asTracePointInt):
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::asSignpostString):
(JSC::JSGlobalObject::init):
2021-05-17 Geoffrey Garen <ggaren@apple.com>
StructureRareData::m_replacementWatchpointSets should not be a pointer to a pointer
https://bugs.webkit.org/show_bug.cgi?id=225840
Reviewed by Mark Lam.
HashMap is already just one pointer. Making it a pointer to a pointer
causes heap fragmentation. Worth about 1MB on GMail.
* runtime/Structure.cpp:
(JSC::Structure::ensurePropertyReplacementWatchpointSet):
* runtime/StructureInlines.h:
(JSC::Structure::didReplaceProperty):
(JSC::Structure::propertyReplacementWatchpointSet):
* runtime/StructureRareData.h:
2021-05-17 Alexey Shvayka <shvaikalesh@gmail.com>
REGRESSION (r271119): Object methods defined with shorthand notation cannot access "caller" in non-strict mode
https://bugs.webkit.org/show_bug.cgi?id=225277
Reviewed by Darin Adler.
This patch loosens `function.caller` to allow non-strict getters, setters, arrow functions,
and ES6 methods to be returned as callers, fixing web compatibility.
The intent of r230662 is preserved: generator / async functions are never exposed. There is
no good way to acquire wrapper function from the internal body one, nor from its arguments.
Also, this behavior is on standards track [1] (seems to be considered desirable).
[1]: https://github.com/claudepache/es-legacy-function-reflection/blob/master/spec.md#get-functionprototypecaller (step 14)
* runtime/JSFunction.cpp:
(JSC::JSC_DEFINE_CUSTOM_GETTER):
2021-05-16 Mark Lam <mark.lam@apple.com>
Implement baseline op_enter, op_ret, op_check_traps, op_throw using JIT thunks.
https://bugs.webkit.org/show_bug.cgi?id=225846
Reviewed by Filip Pizlo.
op_enter, op_ret, op_check_traps are 3 of the most common opcodes. Throwing in
op_throw because it's easy.
In this patch, the following changes were also made:
1. Renamed copyCalleeSavesFromFrameOrRegisterToEntryFrameCalleeSavesBuffer() to
copyLLIntBaselineCalleeSavesFromFrameOrRegisterToEntryFrameCalleeSavesBuffer().
It is only used by the baseline JIT. Changed it to always operate on
RegisterAtOffsetList::llintBaselineCalleeSaveRegisters(). This removes the
dependency on a current codeBlock being compiled, and allows us to use it
for a JIT thunk.
2. Added JIT::emitNakedNearJump() to make it easy to emit direct jumps to JIT thunks.
Currently, it is only used by op_ret and op_throw.
3. Changed some thunks to use emitNonPatchableExceptionCheck() instead
emitExceptionCheck() to make it explicit that these are not intended to be
patchable.
With this patch, --dumpLinkBufferStats shows the following changes in emitted
JIT code size (using a single run of the CLI version of JetStream2 on AS Mac)
comparing to current tip of tree:
Base New Diff
BaselineJIT: 77429400 (73.842430 MB) 72407904 (69.053558 MB) 0.94x (reduction)
DFG: 36160880 (34.485703 MB) 36622176 (34.925629 MB) 1.01x
Thunk: 23159024 (22.086166 MB) 23295448 (22.216270 MB) 1.01x
InlineCache: 22068348 (21.046017 MB) 22157236 (21.130787 MB) 1.00x
FTL: 6004736 (5.726562 MB) 6030536 (5.751167 MB) 1.00x
Wasm: 2429204 (2.316669 MB) 2300872 (2.194283 MB) 0.95x (probably noise)
YarrJIT: 1522488 (1.451958 MB) 1522616 (1.452080 MB) 1.00x
CSSJIT: 0 0
Uncategorized: 0 0
Cumulative diff since the start of this effort to put more code in JIT thunks:
Base New Diff
BaselineJIT: 89089964 (84.962811 MB) 72407904 (69.053558 MB) 0.81x (reduction)
DFG: 39117360 (37.305222 MB) 36622176 (34.925629 MB) 0.94x (reduction)
Thunk: 23230968 (22.154778 MB) 23295448 (22.216270 MB) 1.00x
InlineCache: 22027416 (21.006981 MB) 22157236 (21.130787 MB) 1.01x
FTL: 6575772 (6.271145 MB) 6030536 (5.751167 MB) 0.92x (reduction)
Wasm: 2302724 (2.196049 MB) 2300872 (2.194283 MB) 1.00x
YarrJIT: 1538956 (1.467663 MB) 1522616 (1.452080 MB) 0.99x
CSSJIT: 0 0
Uncategorized: 0 0
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::sub64):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitRestoreCalleeSavesFor):
(JSC::AssemblyHelpers::copyLLIntBaselineCalleeSavesFromFrameOrRegisterToEntryFrameCalleeSavesBuffer):
(JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToEntryFrameCalleeSavesBuffer): Deleted.
* jit/JIT.cpp:
(JSC::JIT::emitEnterOptimizationCheck):
(JSC::JIT::link):
* jit/JIT.h:
(JSC::NearJumpRecord::NearJumpRecord):
* jit/JITInlines.h:
(JSC::JIT::emitNakedNearJump):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_ret):
(JSC::JIT::op_ret_handlerGenerator):
(JSC::JIT::emit_op_throw):
(JSC::JIT::op_throw_handlerGenerator):
(JSC::JIT::emit_op_enter):
(JSC::JIT::op_enter_handlerGenerator):
(JSC::JIT::emitSlow_op_loop_hint):
(JSC::JIT::emitSlow_op_check_traps):
(JSC::JIT::op_check_traps_handlerGenerator):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::slow_op_get_from_scopeGenerator):
(JSC::JIT::slow_op_put_to_scopeGenerator):
* jit/JITThunks.cpp:
(JSC::JITThunks::preinitializeExtraCTIThunks):
* jit/SlowPathCall.cpp:
(JSC::JITSlowPathCall::generateThunk):
2021-05-16 Keith Miller <keith_miller@apple.com>
IsoAlignedMemoryAllocator should use BitVector
https://bugs.webkit.org/show_bug.cgi?id=225852
Reviewed by Mark Lam.
Right now IsoAlignedMemoryAllocator uses FastBitVector, which does
not have inline storage for small sizes. However, it's not
uncommon for IsoAlignedMemoryAllocator to be holding onto only a
few blocks. Those blocks may exist for a long time, which some
data indicates causes IsoAlignedMemoryAllocator's FastBitVector to
pin a full physical page for one 8 byte allocation. Since
accessing the commited blocks list is not a particularly hot
operation, we should just use a BitVector instead.
This seems to be perf neutral on benchmarks.
* heap/IsoAlignedMemoryAllocator.cpp:
(JSC::IsoAlignedMemoryAllocator::~IsoAlignedMemoryAllocator):
(JSC::IsoAlignedMemoryAllocator::tryAllocateAlignedMemory):
(JSC::IsoAlignedMemoryAllocator::freeAlignedMemory):
* heap/IsoAlignedMemoryAllocator.h:
2021-05-16 Saam Barati <sbarati@apple.com>
DFGVarargsForwardingPhase shouldn't consult Flush
https://bugs.webkit.org/show_bug.cgi?id=225824
Reviewed by Filip Pizlo and Yusuke Suzuki.
In the Varargs Forwarding Phase, we were treating Flush as if it
were any other form of node that interferes with an argument
via clobbering a stack location.
This isn't how Flush works though. It doesn't have execution
semantics at the node's graph location. Instead, Flush means that
any variable it's linked to in CPS should be flushed to the stack
between it and the Flush.
The semantics of arguments is that they're already flushed to the
stack, and they've always been. Seeing a Flush node doesn't prevent
arguments elimination, we already know the arguments are on the stack,
and all we're searching for is if there is an interference operation
that says it'll clobber that stack slot. Flush isn't an interference operation.
This is a 0.5% Speedometer progression.
* dfg/DFGVarargsForwardingPhase.cpp:
2021-05-15 Alexey Shvayka <shvaikalesh@gmail.com>
Turn callGetter() / callSetter() into instance methods
https://bugs.webkit.org/show_bug.cgi?id=225831
Reviewed by Ross Kirsling.
1. Turn callGetter() / callSetter() into instance methods to simplify their signatures.
2. Rename `base` parameter to `thisValue`, avoiding similarity with slotBase().
3. Accept `bool shouldThrow` in callSetter() since ECMAMode is cumbersome to construct.
4. Replace isSetterNull(), which does LIKELY(inherits), with direct JSType check.
5. Introduce getCallData(VM&, JSCell*) overload to avoid extra checks / casts.
6. Move isValidCallee() to JSCell and handle primitives gracefully.
No behavior change. Advances provided callSetter() microbenchmark by 2%.
* runtime/GetterSetter.cpp:
(JSC::GetterSetter::callGetter):
(JSC::GetterSetter::callSetter):
(JSC::callGetter): Deleted.
(JSC::callSetter): Deleted.
* runtime/GetterSetter.h:
* runtime/JSCJSValue.cpp:
(JSC::JSValue::isValidCallee): Deleted.
* runtime/JSCJSValue.h:
* runtime/JSCell.cpp:
(JSC::JSCell::isValidCallee const):
* runtime/JSCell.h:
* runtime/JSObject.cpp:
(JSC::JSObject::putInlineSlow):
* runtime/JSObjectInlines.h:
(JSC::getCallData):
(JSC::getConstructData):
* runtime/PropertySlot.cpp:
(JSC::PropertySlot::functionGetter const):
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayEntry::put):
2021-05-14 Chris Dumez <cdumez@apple.com>
Drop FileSystem::fileMetadata() / fileMetadataFollowingSymlinks()
https://bugs.webkit.org/show_bug.cgi?id=225820
Reviewed by Darin Adler.
Update our code base because of the FileSystem API changes.
* API/JSScript.mm:
(validateBytecodeCachePath):
2021-05-14 Ross Kirsling <ross.kirsling@sony.com>
REGRESSION (r277221): 2 test262 tests failing
https://bugs.webkit.org/show_bug.cgi?id=225819
Reviewed by Alexey Shvayka.
Undo the other part of r277221's code consolidation --
I'd forgotten that this exists to enforce a evaluation order on AggregateError's arguments.
* runtime/AggregateError.cpp:
(JSC::createAggregateError):
2021-05-14 Mark Lam <mark.lam@apple.com>
Implement Baseline JIT property access slow paths using JIT thunks.
https://bugs.webkit.org/show_bug.cgi?id=225771
Reviewed by Yusuke Suzuki and Saam Barati.
This patch applies the following strategy to Baseline JIT property access slow paths:
1. If the slow path operation call is not patchable, emit a near call to a JIT
thunk to do the entire operation call.
2. If the slow path operation call is patachable, emit a near call to a prepare
call JIT thunk before the patchable operation call, and a near call to an exception
check JIT thunk after.
This strategy reduces the amount of instructions emitted for all the slow paths.
Performance is expected to be neutral or slightly improved due to the reduced
compile times and better cache locality.
With this patch, --dumpLinkBufferStats shows the following changes in emitted
JIT code size (using a single run of the CLI version of JetStream2 on AS Mac)
comparing to current tip of tree:
Base New Diff
BaselineJIT: 84624776 (80.704475 MB) 77429400 (73.842430 MB) 0.91x (reduction)
DFG: 36415264 (34.728302 MB) 36160880 (34.485703 MB) 0.99x
Thunk: 23130336 (22.058807 MB) 23159024 (22.086166 MB) 1.00x
InlineCache: 21969728 (20.951965 MB) 22068348 (21.046017 MB) 1.00x
FTL: 6097336 (5.814873 MB) 6004736 (5.726562 MB) 0.98x
Wasm: 2301956 (2.195316 MB) 2429204 (2.316669 MB) 1.06x (probably noise)
YarrJIT: 1522488 (1.451958 MB) 1522488 (1.451958 MB) 1.00x
CSSJIT: 0
Uncategorized: 0
Comparing to tip of tree at the start of this effort to move put slow paths in
JIT thunks:
Base New Diff
BaselineJIT: 89089964 (84.962811 MB) 77429400 (73.842430 MB) 0.87x (reduction)
DFG: 39117360 (37.305222 MB) 36160880 (34.485703 MB) 0.92x (reduction)
Thunk: 23230968 (22.154778 MB) 23159024 (22.086166 MB) 1.00x
InlineCache: 22027416 (21.006981 MB) 22068348 (21.046017 MB) 1.00x
FTL: 6575772 (6.271145 MB) 6004736 (5.726562 MB) 0.91x (reduction)
Wasm: 2302724 (2.196049 MB) 2429204 (2.316669 MB) 1.05x (probably noise)
YarrJIT: 1538956 (1.467663 MB) 1522488 (1.451958 MB) 0.99x
CSSJIT: 0 0
Uncategorized: 0 0
This patch has passed the JSC tests on AS Mac, and also a subset of the JSC tests
(as a smoke test) on x86_64.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::offsetOfGlobalObject):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::callExceptionFuzz):
(JSC::AssemblyHelpers::emitExceptionCheck):
(JSC::AssemblyHelpers::emitNonPatchableExceptionCheck):
* jit/JIT.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::slow_op_get_by_val_prepareCallGenerator):
(JSC::JIT::emitSlow_op_get_private_name):
(JSC::JIT::slow_op_get_private_name_prepareCallGenerator):
(JSC::JIT::emitSlow_op_set_private_brand):
(JSC::JIT::emitSlow_op_check_private_brand):
(JSC::JIT::emitSlow_op_put_by_val):
(JSC::JIT::slow_op_put_by_val_prepareCallGenerator):
(JSC::JIT::emitSlow_op_put_private_name):
(JSC::JIT::slow_op_put_private_name_prepareCallGenerator):
(JSC::JIT::emitSlow_op_del_by_id):
(JSC::JIT::slow_op_del_by_id_prepareCallGenerator):
(JSC::JIT::emitSlow_op_del_by_val):
(JSC::JIT::slow_op_del_by_val_prepareCallGenerator):
(JSC::JIT::emitSlow_op_try_get_by_id):
(JSC::JIT::emitSlow_op_get_by_id_direct):
(JSC::JIT::emitSlow_op_get_by_id):
(JSC::JIT::slow_op_get_by_id_prepareCallGenerator):
(JSC::JIT::emitSlow_op_get_by_id_with_this):
(JSC::JIT::slow_op_get_by_id_with_this_prepareCallGenerator):
(JSC::JIT::emitSlow_op_put_by_id):
(JSC::JIT::slow_op_put_by_id_prepareCallGenerator):
(JSC::JIT::emitSlow_op_in_by_id):
(JSC::JIT::emitSlow_op_get_from_scope):
(JSC::JIT::slow_op_get_from_scopeGenerator):
(JSC::JIT::emitSlow_op_put_to_scope):
(JSC::JIT::slow_op_put_to_scopeGenerator):
* jit/JITThunks.cpp:
(JSC::JITThunks::preinitializeExtraCTIThunks):
* jit/SlowPathCall.cpp:
(JSC::JITSlowPathCall::call):
* jit/ThunkGenerators.cpp:
(JSC::checkExceptionGenerator):
* jit/ThunkGenerators.h:
2021-05-14 Chris Dumez <cdumez@apple.com>
Rename FileSystem::getFileSize() to FileSystem::fileSize()
https://bugs.webkit.org/show_bug.cgi?id=225798
Reviewed by Alex Christensen.
Update code path to due to the API change.
* inspector/remote/socket/RemoteInspectorSocket.cpp:
(Inspector::RemoteInspector::backendCommands const):
* jsc.cpp:
2021-05-13 Darin Adler <darin@apple.com>
Follow-up fix for: Remove StringBuilder::appendNumber
https://bugs.webkit.org/show_bug.cgi?id=225732
rdar://78000283
* heap/HeapSnapshotBuilder.cpp:
(JSC::HeapSnapshotBuilder::json): Removed a stray single quote mark that
meant we produced a JSON file that could not be parsed.
2021-05-13 Patrick Angle <pangle@apple.com>
[REGRESSION: r271876] Web Inspector: [Cocoa] Remote inspection crashes when using WEB_THREAD
https://bugs.webkit.org/show_bug.cgi?id=225794
Reviewed by Devin Rousso.
For WEB_THREAD, move `callback` in `dispatchAsyncOnTarget` to `block` scope to ensure it is available for the
lifetime of the block.
* inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
(Inspector::RemoteConnectionToTarget::dispatchAsyncOnTarget):
2021-05-13 Geoffrey Garen <ggaren@apple.com>
m_calleeSaveRegisters should not be a pointer to a pointer
https://bugs.webkit.org/show_bug.cgi?id=225787
Reviewed by Keith Miller.
Ben found this through memory stress testing.
RegisterAtOffsetList is effectively just a pointer. unique_ptr<RegisterAtOffsetList>
is a pointer to a pointer. RegisterAtOffsetList is long-lived, so it
creates heap page fragmentation.
Worth 3MB on Ben's test.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::setCalleeSaveRegisters):
(JSC::CodeBlock::calleeSaveRegisters const): Use a fence before setting
m_hasCalleeSaveRegisters to ensure that all writes have completed before
the struct becomes visible.
* bytecode/CodeBlock.h: Use RegisterAtOffsetList directly instead of
unique_ptr<RegisterAtOffsetList> to avoid a long-lived lonely 8 byte
allocation.
* ftl/FTLCompile.cpp:
(JSC::FTL::compile): Updated for type change.
2021-05-13 Chris Dumez <cdumez@apple.com>
Rename FileSystem::directoryName() to FileSystem::parentPath()
https://bugs.webkit.org/show_bug.cgi?id=225768
Reviewed by Darin Adler.
Rename FileSystem::directoryName() to FileSystem::parentPath() for clarity and
consistency with std::filesystem::parent_path() which is used internally.
* API/JSScript.mm:
(validateBytecodeCachePath):
2021-05-13 Chris Dumez <cdumez@apple.com>
Rename FileSystem::fileIsDirectory(path, followSymlinks) to isDirectory(path) / isDirectoryFollowingSymlinks(path)
https://bugs.webkit.org/show_bug.cgi?id=225772
Reviewed by Darin Adler.
Update code base due to API naming change.
* API/JSScript.mm:
(validateBytecodeCachePath):
2021-05-13 Darin Adler <darin@apple.com>
Remove StringBuilder::appendNumber
https://bugs.webkit.org/show_bug.cgi?id=225732
Reviewed by Sam Weinig.
* API/JSContextRef.cpp:
(BacktraceFunctor::operator() const): Use append instead of appendNumber.
* API/tests/PingPongStackOverflowTest.cpp:
(PingPongStackOverflowObject_hasInstance): Ditto.
* heap/HeapSnapshotBuilder.cpp:
(JSC::HeapSnapshotBuilder::json): Ditto.
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::toString const): Use makeString instead of StringBuilder.
* runtime/ConsoleClient.cpp:
(JSC::appendURLAndPosition): Ditto.
(JSC::ConsoleClient::printConsoleMessageWithArguments): Use append instead of appendNumber.
* runtime/JSONObject.cpp:
(JSC::Stringifier::appendStringifiedValue): Ditto.
* runtime/Options.cpp:
(JSC::OptionReader::Option::dump const): Ditto.
* runtime/StackFrame.cpp:
(JSC::StackFrame::toString const): Use makeString instead of StringBuilder.
2021-05-12 Geoffrey Garen <ggaren@apple.com>
ConservativeRoots triggers page demand on Speedometer
https://bugs.webkit.org/show_bug.cgi?id=225676
Reviewed by Filip Pizlo.
Use a 2048 item / 16kB inline buffer. That's about 10% bigger than the
max capacity observed on Speedometer, and small enough to reasonably fit
on the stack.
Removed the separate out of line capacity because it was smaller than
the new inline capacity.
* heap/ConservativeRoots.cpp:
(JSC::ConservativeRoots::grow):
* heap/ConservativeRoots.h:
2021-05-12 Mark Lam <mark.lam@apple.com>
Implement some common Baseline JIT slow paths using JIT thunks.
https://bugs.webkit.org/show_bug.cgi?id=225682
Reviewed by Filip Pizlo.
This patch implements the following changes:
1. Implement exception handling thunks:
a. handleExceptionGenerator, which calls operationLookupExceptionHandler().
b. handleExceptionWithCallFrameRollbackGenerator, which calls
operationLookupExceptionHandlerFromCallerFrame().
All the JIT tiers were emitting their own copy of these routines to call these
operation, one per CodeBlock. We now emit 2 thunks for these and have all the
tiers just jump to them.
PolymorphicAccess also now uses the handleExceptionGenerator thunk.
DFG::JITCompiler::compileExceptionHandlers() has one small behavior difference
before it calls operationLookupExceptionHandlerFromCallerFrame(): it first
re-sets the top of stack for the function where we are about to throw a
StackOverflowError from. This re-setting of top of stack is useless because
we're imminently unwinding out of at least this frame for the StackOverflowError.
Hence, it is ok to use the handleExceptionWithCallFrameRollbackGenerator thunk
here as well. Note that no other tiers does this re-setting of top of stack.
FTLLowerDFGToB3 has one case using operationLookupExceptionHandlerFromCallerFrame()
which cannot be refactored to use these thunks because it does additional
work to throw a StackOverflowError. A different thunk will be needed. I left
it alone for now.
2. Introduce JITThunks::existingCTIStub(ThunkGenerator, NoLockingNecessaryTag) so
that a thunk can get a pointer to another thunk without locking the JITThunks
lock. Otherwise, deadlock ensues.
3. Change SlowPathCall to emit and use thunks instead of emitting a blob of code
to call a slow path function for every bytecode in a CodeBlock.
4. Introduce JITThunks::ctiSlowPathFunctionStub() to manage these SlowPathFunction
thunks.
5. Introduce JITThunks::preinitializeAggressiveCTIThunks() to initialize these
thunks at VM initialization time. Pre-initializing them has multiple benefits:
a. the thunks are not scattered through out JIT memory, thereby reducing
fragmentation.
b. we don't spend time at runtime compiling them when the user is interacting
with the VM. Conceptually, these thunks can be VM independent and can be
shared by VMs process-wide. However, it will require some additional work.
For now, the thunks remain bound to a specific VM instance.
These changes are only enabled when ENABLE(EXTRA_CTI_THUNKS), which is currently
only available for ARM64 and non-Windows x86_64.
This patch has passed JSC tests on AS Mac.
With this patch, --dumpLinkBufferStats shows the following changes in emitted
JIT code size (using a single run of the CLI version of JetStream2 on AS Mac):
Base New Diff
BaselineJIT: 89089964 (84.962811 MB) 84624776 (80.704475 MB) 0.95x (reduction)
DFG: 39117360 (37.305222 MB) 36415264 (34.728302 MB) 0.93x (reduction)
Thunk: 23230968 (22.154778 MB) 23130336 (22.058807 MB) 1.00x
InlineCache: 22027416 (21.006981 MB) 21969728 (20.951965 MB) 1.00x
FTL: 6575772 (6.271145 MB) 6097336 (5.814873 MB) 0.93x (reduction)
Wasm: 2302724 (2.196049 MB) 2301956 (2.195316 MB) 1.00x
YarrJIT: 1538956 (1.467663 MB) 1522488 (1.451958 MB) 0.99x
CSSJIT: 0 0
Uncategorized: 0 0
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/CodeBlock.h:
(JSC::CodeBlock::offsetOfInstructionsRawPointer):
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessGenerationState::emitExplicitExceptionHandler):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compileExceptionHandlers):
(JSC::DFG::JITCompiler::link):
* dfg/DFGJITCompiler.h:
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* jit/JIT.cpp:
(JSC::JIT::link):
(JSC::JIT::privateCompileExceptionHandlers):
* jit/JIT.h:
* jit/JITThunks.cpp:
(JSC::JITThunks::existingCTIStub):
(JSC::JITThunks::ctiSlowPathFunctionStub):
(JSC::JITThunks::preinitializeExtraCTIThunks):
* jit/JITThunks.h:
* jit/SlowPathCall.cpp: Added.
(JSC::JITSlowPathCall::call):
(JSC::JITSlowPathCall::generateThunk):
* jit/SlowPathCall.h:
* jit/ThunkGenerators.cpp:
(JSC::handleExceptionGenerator):
(JSC::handleExceptionWithCallFrameRollbackGenerator):
(JSC::popThunkStackPreservesAndHandleExceptionGenerator):
* jit/ThunkGenerators.h:
* runtime/CommonSlowPaths.h:
* runtime/SlowPathFunction.h: Added.
* runtime/VM.cpp:
(JSC::VM::VM):
2021-05-12 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r277346.
https://bugs.webkit.org/show_bug.cgi?id=225705
Introduced a (rare) deadlock
Reverted changeset:
"ConservativeRoots triggers page demand on Speedometer"
https://bugs.webkit.org/show_bug.cgi?id=225676
https://trac.webkit.org/changeset/277346
2021-05-12 Mark Lam <mark.lam@apple.com>
Remove dead code around ENABLE(OPCODE_SAMPLING) and ENABLE(CODEBLOCK_SAMPLING).
https://bugs.webkit.org/show_bug.cgi?id=225699
Reviewed by Tadeu Zagallo.
This code revolves around an Interpreter::sampler() method which returns a
SamplingTool*. Neither the Interpreter method nor the SamplingTool class exists
anymore.
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::compileWithoutLinking):
* jit/JIT.h:
* jit/JITCall.cpp:
(JSC::JIT::compileCallEval):
(JSC::JIT::compileCallEvalSlowCase):
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
* jit/JITCall32_64.cpp:
(JSC::JIT::compileCallEval):
(JSC::JIT::compileCallEvalSlowCase):
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
* jit/JITInlines.h:
(JSC::JIT::sampleInstruction): Deleted.
(JSC::JIT::sampleCodeBlock): Deleted.
* jit/JITOperations.cpp:
* jit/SlowPathCall.h:
(JSC::JITSlowPathCall::call):
* runtime/ScriptExecutable.h:
(JSC::ScriptExecutable::finishCreation): Deleted.
2021-05-11 Geoffrey Garen <ggaren@apple.com>
ConservativeRoots triggers page demand on Speedometer
https://bugs.webkit.org/show_bug.cgi?id=225676
Reviewed by Saam Barati.
Use a Vector instead of OSAllocator to avoid mmap() and page fault --
and, like, come on.
Bump default inlineCapacity up to 1024 because we seem to overflow
frequently.
* heap/ConservativeRoots.cpp:
(JSC::ConservativeRoots::ConservativeRoots):
(JSC::ConservativeRoots::~ConservativeRoots):
(JSC::ConservativeRoots::genericAddPointer):
(JSC::ConservativeRoots::grow): Deleted.
* heap/ConservativeRoots.h:
(JSC::ConservativeRoots::roots const):
(JSC::ConservativeRoots::size const): Deleted.
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::append):
* heap/VerifierSlotVisitor.cpp:
(JSC::VerifierSlotVisitor::append):
2021-05-10 Filip Pizlo <fpizlo@apple.com>
Tune number of threads for AS
https://bugs.webkit.org/show_bug.cgi?id=225635
Reviewed by Mark Lam.
Using 4 GC markers (which really means 3 parallel GC worker threads -- the mutator thread is
the 4th), 2 DFG threads, and 2 FTL threads seems to be more optimal than going off ncpu.
~1% JetStream2 speed-up, ~1% Speedometer2 speed-up.
* runtime/Options.cpp:
(JSC::overrideDefaults):
2021-05-10 Mark Lam <mark.lam@apple.com>
Removed unused CallRecord::bytecodeIndex field.
https://bugs.webkit.org/show_bug.cgi?id=225627
Reviewed by Yusuke Suzuki.
* jit/JIT.cpp:
(JSC::JIT::privateCompileExceptionHandlers):
* jit/JIT.h:
(JSC::CallRecord::CallRecord):
* jit/JITInlines.h:
(JSC::JIT::emitNakedNearCall):
(JSC::JIT::emitNakedNearTailCall):
2021-05-10 Mark Lam <mark.lam@apple.com>
Add support to collect stats on cumulative LinkBuffer linked sizes based on profiles.
https://bugs.webkit.org/show_bug.cgi?id=225617
Reviewed by Saam Barati.
There are 2 ways to dump the stats:
1. Specify --dumpLinkBufferStats as an argument to the jsc shell.
2. Call $vm.dumpLinkBufferStats() from your JS script to get the stats as a string.
e.g.
$vm.print($vm.dumpLinkBufferStats());
Here's an example of what the dump looks like:
Cummulative LinkBuffer profile sizes:
BaselineJIT: 79480320 (75.798340 MB)
DFG: 36108672 (34.435913 MB)
Thunk: 22495360 (21.453247 MB)
InlineCache: 19538521 (18.633386 MB)
FTL: 5186240 (4.945984 MB)
Wasm: 1998272 (1.905701 MB)
YarrJIT: 1331072 (1.269409 MB)
CSSJIT: 0
Uncategorized: 0
The stats are currently grouped into some coarse profiles. If needed, we can
break these down into more fine grain profiles later.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::performFinalization):
(JSC::LinkBuffer::dumpProfileStatistics):
* assembler/LinkBuffer.h:
(JSC::LinkBuffer::LinkBuffer):
* bytecode/InlineAccess.cpp:
(JSC::linkCodeInline):
(JSC::InlineAccess::rewireStubAsJump):
* bytecode/PolymorphicAccess.cpp:
(JSC::PolymorphicAccess::regenerate):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* dfg/DFGThunks.cpp:
(JSC::DFG::osrExitGenerationThunkGenerator):
(JSC::DFG::osrEntryThunkGenerator):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLLazySlowPath.cpp:
(JSC::FTL::LazySlowPath::generate):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* ftl/FTLThunks.cpp:
(JSC::FTL::genericGenerationThunkGenerator):
(JSC::FTL::slowPathCallThunkGenerator):
* jit/ExecutableAllocator.cpp:
(JSC::jitWriteThunkGenerator):
* jit/JIT.cpp:
(JSC::JIT::compileWithoutLinking):
* jit/JITMathIC.h:
(JSC::JITMathIC::generateOutOfLine):
* jit/JITOpcodes.cpp:
(JSC::JIT::privateCompileHasIndexedProperty):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::privateCompileHasIndexedProperty):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::privateCompilePutByVal):
(JSC::JIT::privateCompilePutPrivateNameWithCachedId):
(JSC::JIT::privateCompilePutByValWithCachedId):
* jit/Repatch.cpp:
(JSC::linkPolymorphicCall):
* jit/SpecializedThunkJIT.h:
(JSC::SpecializedThunkJIT::finalize):
* jit/ThunkGenerators.cpp:
(JSC::throwExceptionFromCallSlowPathGenerator):
(JSC::linkCallThunkGenerator):
(JSC::linkPolymorphicCallThunkGenerator):
(JSC::virtualThunkFor):
(JSC::nativeForGenerator):
(JSC::arityFixupGenerator):
(JSC::unreachableGenerator):
(JSC::stringGetByValGenerator):
(JSC::boundFunctionCallGenerator):
* jsc.cpp:
(CommandLine::parseArguments):
(jscmain):
* llint/LLIntThunks.cpp:
(JSC::LLInt::generateThunkWithJumpTo):
(JSC::LLInt::generateThunkWithJumpToPrologue):
(JSC::LLInt::generateThunkWithJumpToLLIntReturnPoint):
(JSC::LLInt::getHostCallReturnValueThunk):
(JSC::LLInt::createJSGateThunk):
(JSC::LLInt::createWasmGateThunk):
(JSC::LLInt::createTailCallGate):
(JSC::LLInt::loopOSREntryGateThunk):
(JSC::LLInt::entryOSREntryGateThunk):
(JSC::LLInt::wasmOSREntryGateThunk):
(JSC::LLInt::exceptionHandlerGateThunk):
(JSC::LLInt::returnFromLLIntGateThunk):
(JSC::LLInt::tagGateThunk):
(JSC::LLInt::untagGateThunk):
(JSC::LLInt::jitCagePtrThunk):
* tools/JSDollarVM.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::JSDollarVM::finishCreation):
* wasm/WasmBBQPlan.cpp:
(JSC::Wasm::BBQPlan::work):
(JSC::Wasm::BBQPlan::didCompleteCompilation):
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToWasm):
* wasm/WasmLLIntPlan.cpp:
(JSC::Wasm::LLIntPlan::didCompleteCompilation):
* wasm/WasmOMGForOSREntryPlan.cpp:
(JSC::Wasm::OMGForOSREntryPlan::work):
* wasm/WasmOMGPlan.cpp:
(JSC::Wasm::OMGPlan::work):
* wasm/WasmThunks.cpp:
(JSC::Wasm::throwExceptionFromWasmThunkGenerator):
(JSC::Wasm::throwStackOverflowFromWasmThunkGenerator):
(JSC::Wasm::triggerOMGEntryTierUpThunkGenerator):
* wasm/js/WasmToJS.cpp:
(JSC::Wasm::wasmToJS):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::jsCallEntrypointSlow):
* yarr/YarrJIT.cpp:
2021-05-08 Darin Adler <darin@apple.com>
Remove calls to the String::toInt family of functions from JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=225571
Reviewed by Sam Weinig.
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::parseLocation): Use parseIntegerAllowingTrailingJunk<JSC::SourceID>
instead of String::toIntPtr. There was no reason to parse the source ID as a
signed integer, and it's more elegant to parse the type we intend to store and
process, not a different but similar type.
(Inspector::InspectorDebuggerAgent::searchInContent): Ditto.
(Inspector::InspectorDebuggerAgent::getScriptSource): Ditto.
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets): Use
parseInteger<uintptr_t> instead of String::toIntPtrStrict.
(Inspector::InspectorRuntimeAgent::getBasicBlocks): Use
parseIntegerAllowingTrailingJunk<uintptr_t> instead of String::toIntPtr.
* runtime/FuzzerPredictions.cpp:
(JSC::FuzzerPredictions::FuzzerPredictions): Use parseInteger<uint64_t>
instead of String::toUInt64Strict.
2021-05-08 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Fix invalid exception checks after recent ErrorInstance changes
https://bugs.webkit.org/show_bug.cgi?id=225565
Reviewed by Alexey Shvayka.
r277221 and r277224 each introduced issues under validateExceptionChecks=1; this patch fixes them.
Of particular note:
The earlier patch sought to consolidate Error#cause logic under ErrorInstance::finishCreation.
This part must be undone as it is crucial that non-user-thrown errors be able to bypass that logic
(otherwise throwException itself would need to be exception-checked).
* runtime/AggregateError.cpp:
(JSC::createAggregateError):
* runtime/ArrayPrototype.cpp:
(JSC::getProperty):
* runtime/Error.cpp:
(JSC::createError):
(JSC::createEvalError):
(JSC::createRangeError):
(JSC::createReferenceError):
(JSC::createSyntaxError):
(JSC::createTypeError):
(JSC::createURIError):
(JSC::createGetterTypeError):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::create):
(JSC::ErrorInstance::finishCreation):
* runtime/ErrorInstance.h:
(JSC::ErrorInstance::create):
* runtime/JSObject.h:
* runtime/JSObjectInlines.h:
(JSC::JSObject::getIfPropertyExists):
* runtime/NullSetterFunction.cpp:
(JSC::NullSetterFunctionInternal::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/JSWebAssemblyCompileError.cpp:
(JSC::createJSWebAssemblyCompileError):
* wasm/js/JSWebAssemblyLinkError.cpp:
(JSC::createJSWebAssemblyLinkError):
* wasm/js/JSWebAssemblyRuntimeError.cpp:
(JSC::createJSWebAssemblyRuntimeError):
2021-05-08 Chris Dumez <cdumez@apple.com>
Port Filesystem::pathByAppendingComponent() & Filesystem:: pathByAppendingComponents() to std::filesystem
https://bugs.webkit.org/show_bug.cgi?id=225550
Reviewed by Darin Adler.
Build fix.
* Configurations/JavaScriptCore.xcconfig:
2021-05-08 Ross Kirsling <ross.kirsling@sony.com>
Introduce JSObject::getIfPropertyExists helper
https://bugs.webkit.org/show_bug.cgi?id=225553
Reviewed by Alexey Shvayka.
Suggested by Alexey during review of r277221.
ArrayPrototype also has a "Has-guarded Get", so it's helpful for JSObject to house this functionality.
* runtime/ArrayPrototype.cpp:
(JSC::getProperty):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::finishCreation):
* runtime/JSObject.h:
* runtime/JSObjectInlines.h:
(JSC::JSObject::getIfPropertyExists):
2021-05-07 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Error#cause must recognize explicit undefined
https://bugs.webkit.org/show_bug.cgi?id=225535
Reviewed by Alexey Shvayka.
Error#cause is specified such that `new Error(message, {})` and `new Error(message, { cause: undefined })`
are not the same -- namely, the latter should create a property descriptor with an undefined `value`.
This would seem absurd, but the reason is because the `cause` field is meant to store a thrown object,
and `throw undefined;` is valid code.
In aligning our implementation with the spec, this patch also consolidates the relevant logic in one place
(ErrorInstance::finishCreation) to minimize confusion.
* runtime/AggregateError.cpp:
(JSC::createAggregateError):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::create):
(JSC::ErrorInstance::finishCreation):
* runtime/ErrorInstance.h:
(JSC::ErrorInstance::create):
2021-05-06 Chris Dumez <cdumez@apple.com>
Port Filesystem::fileMetadata() & Filesystem::getFileModificationTime() to std::filesystem
https://bugs.webkit.org/show_bug.cgi?id=225362
Reviewed by Darin Adler.
Build fix.
* Configurations/JavaScriptCore.xcconfig:
2021-05-06 Eleni Maria Stea <estea@igalia.com>
Removed the assertion m_numParameters >= 0, it is always true as
m_numParameters is unsigned.
https://bugs.webkit.org/show_bug.cgi?id=225457
Reviewed by Yusuke Suzuki.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::numberOfArgumentValueProfiles):
2021-05-06 Filip Pizlo <fpizlo@apple.com>
Make some things easier to dataLog in wasm
https://bugs.webkit.org/show_bug.cgi?id=225472
Reviewed by Yusuke Suzuki.
* wasm/WasmMemoryMode.cpp:
(WTF::printInternal):
* wasm/WasmMemoryMode.h:
* wasm/WasmWorklist.cpp:
(JSC::Wasm::Worklist::dump const):
* wasm/WasmWorklist.h:
2021-05-06 Filip Pizlo <fpizlo@apple.com>
Reduce use of dmb ish on ARM64
https://bugs.webkit.org/show_bug.cgi?id=225465
Reviewed by Keith Miller.
We use loadLoadFence a lot, often in situations like:
Foo* ptr = loadStuff;
loadLoadFence();
use ptr
On ARM64, we don't need a dmb ish here. This introduces a dependentLoadLoadFence() for these
cases; it's just a compiler fence on ARM64 and Intel.
We also used loadLoadFence in some places where I couldn't think of any good reason for the
fence other than paranoia. I got rid of those.
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFromCallLinkInfo):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::jitType const):
* bytecode/ObjectAllocationProfile.h:
(JSC::ObjectAllocationProfileBase::structure):
(JSC::ObjectAllocationProfileWithPrototype::prototype):
* bytecode/Watchpoint.h:
(JSC::WatchpointSet::state const):
(JSC::InlineWatchpointSet::state const):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::handlePutByVal):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByValOnString):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
* runtime/GetterSetter.h:
* runtime/InferredValue.h:
(JSC::InferredValue::state const):
* runtime/Structure.h:
(JSC::Structure::tryRareData):
* runtime/StructureInlines.h:
(JSC::Structure::propertyReplacementWatchpointSet):
2021-05-06 Filip Pizlo <fpizlo@apple.com>
It should be possible to --logJIT=true
https://bugs.webkit.org/show_bug.cgi?id=225464
Reviewed by Mark Lam.
This makes it easy to just log when JITing happens. It's like --dumpDisassembly=true but
without the disassembly.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::finalizeCodeWithDisassemblyImpl):
* assembler/LinkBuffer.h:
* runtime/Options.cpp:
(JSC::Options::recomputeDependentOptions):
* runtime/OptionsList.h:
2021-05-06 Mark Lam <mark.lam@apple.com>
Forbid further execution in jsc shell if execution is terminated.
https://bugs.webkit.org/show_bug.cgi?id=225410
rdar://77548608
Reviewed by Michael Saboff.
1. Introduce a VM::m_executionForbidden flag.
2. In the jsc shell, forbid further execution if termination was encountered.
* jsc.cpp:
(runWithOptions):
* runtime/VM.cpp:
(JSC::VM::drainMicrotasks):
* runtime/VM.h:
(JSC::VM::executionForbidden const):
(JSC::VM::setExecutionForbidden):
2021-05-06 Mark Lam <mark.lam@apple.com>
Fix missing exception check in objectConstructorGetOwnPropertyDescriptors().
https://bugs.webkit.org/show_bug.cgi?id=225413
rdar://77551530
Reviewed by Michael Saboff.
Need to handle TerminationException.
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorGetOwnPropertyDescriptors):
2021-05-05 Mark Lam <mark.lam@apple.com>
Introduce VM::hasPendingTerminationException() to make code a little more terse.
https://bugs.webkit.org/show_bug.cgi?id=225412
Reviewed by Michael Saboff.
This is purely a refactoring patch. There is no behavior change.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::executeProgram):
* jit/JITOperations.cpp:
* runtime/ExceptionScope.h:
(JSC::ExceptionScope::assertNoExceptionExceptTermination):
(JSC::ExceptionScope::releaseAssertNoExceptionExceptTermination):
* runtime/JSObject.h:
(JSC::JSObject::get const):
* runtime/LazyPropertyInlines.h:
(JSC::ElementType>::callFunc):
* runtime/VM.cpp:
(JSC::VM::throwException):
* runtime/VM.h:
(JSC::VM::hasPendingTerminationException const):
* runtime/VMTraps.cpp:
(JSC::VMTraps::deferTerminationSlow):
2021-05-05 Mark Lam <mark.lam@apple.com>
Enable incremental sweeping of GCAwareJITStubRoutines.
https://bugs.webkit.org/show_bug.cgi?id=225376
Reviewed by Filip Pizlo.
This patch makes the following changes:
1. Enhance JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines() to be able to
run in an incremental time slice.
2. Added JITStubRoutineSet::notifyHaveRoutinesToDelete() so that
GCAwareJITStubRoutine::observeZeroRefCount() can flag that the GC may have
some dead GCAwareJITStubRoutines to delete.
3. Added JITStubRoutineSet::mayHaveRoutinesToDelete() so that clients can do
a cheap check ahead of time to determine if there's work to do, and avoid
calling JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines() altogether
if not needed.
4. Added Heap::mayHaveJITStubRoutinesToDelete() and Heap::deleteDeadJITStubRoutines()
as wrappers around JITStubRoutineSet::mayHaveRoutinesToDelete() and
JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines() because the use of
the JITStubRoutineSet is a heap internal implementation detail.
5. Enhanced the IncrementalSweeper to also call Heap::deleteDeadJITStubRoutines()
if needed.
6. Enhanced Heap::sweepSynchronously() to also call Heap::deleteDeadJITStubRoutines()
if needed.
7. Time slices for Heap::deleteDeadJITStubRoutines() is currently set at the
current values:
a. max of 1 ms (1/10 of the IncreamentalSweeper's time slice) when invoked from
the IncreamentalSweeper.
b. max of 5 ms when invoked from Heap::deleteUnmarkedCompiledCode().
c. unlimited time (with a sanity check) when called from Heap::sweepSynchronously().
The choices of 1ms and 5ms were picked to not be too long, but would still delete
the bulk of the dead GCAwareJITStubRoutines quickly enough based on data from my
instrumented runs the CLI version of JetStream2.
I think these hardcoded values will do for now. If need be, we can try something
more sophisticated later.
* CMakeLists.txt:
* heap/Heap.cpp:
(JSC::Heap::deleteUnmarkedCompiledCode):
(JSC::Heap::sweepSynchronously):
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::mayHaveJITStubRoutinesToDelete):
(JSC::Heap::deleteDeadJITStubRoutines):
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::doSweep):
* heap/JITStubRoutineSet.cpp:
(JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines):
* heap/JITStubRoutineSet.h:
(JSC::JITStubRoutineSet::mayHaveRoutinesToDelete):
(JSC::JITStubRoutineSet::notifyHaveRoutinesToDelete):
(JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines):
* jit/GCAwareJITStubRoutine.cpp:
(JSC::GCAwareJITStubRoutine::observeZeroRefCount):
* jit/JITStubRoutine.h:
(JSC::JITStubRoutine::createSelfManagedRoutine): Deleted.
2021-05-03 Mark Lam <mark.lam@apple.com>
Fix syntax error message for AUTOPLUSPLUS token.
https://bugs.webkit.org/show_bug.cgi?id=225308
rdar://76830934
Reviewed by Saam Barati.
For the record, it's not easy to tell from the code why AUTOPLUSPLUS is needed.
It's needed to distinguish this:
```
statement ++ stuff // ++ is a postfix operator applied to `statement`.
```
from this:
```
statement
++stuff // The `\n` before the ++ makes it a prefix operator applied to `stuff``.
```
If we merely tokenize the ++ as a PLUSPLUS token, then it's unclear whether it acts
as a postfix or prefix token in the 2nd case above.
This is why the correct fix is not to get rid of the AUTOPLUSPLUS token, but to
teach the syntax error message to be aware of the AUTOPLUSPLUS token.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseUnaryExpression):
2021-05-03 Chris Dumez <cdumez@apple.com>
Restore pre-r276879 behavior for FileSystem::deleteFile() and FileSystem::deleteEmptyDirectory()
https://bugs.webkit.org/show_bug.cgi?id=225289
Reviewed by Darin Adler.
Fix build.
* Configurations/JavaScriptCore.xcconfig:
2021-05-03 Mark Lam <mark.lam@apple.com>
Add some missing exception checks before some jsCasts.
https://bugs.webkit.org/show_bug.cgi?id=225264
rdar://77381608
Reviewed by Saam Barati.
Introducing JSObject::getAs() and JSValue::getAs() convenience methods that will
check for an exception before doing a jsCast on the get result. We only need this
to placate the assertion in jsCast in the event a pending exception exists at the
time of the jsCast. If ASSERTs are not enabled, this will be a no-op. All clients
that use jsCast this way (and now use getAs instead) will already be doing an
exception check immediately after. Hence, they are already doing the right thing
in terms of handling exceptions. We're only placating the jsCast assertion here.
* runtime/AbstractModuleRecord.cpp:
(JSC::AbstractModuleRecord::hostResolveImportedModule):
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::getAs const):
* runtime/JSInternalPromise.cpp:
(JSC::JSInternalPromise::then):
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::dependencyKeysIfEvaluated):
(JSC::JSModuleLoader::provideFetch):
(JSC::JSModuleLoader::loadAndEvaluateModule):
(JSC::JSModuleLoader::loadModule):
(JSC::JSModuleLoader::linkAndEvaluateModule):
(JSC::JSModuleLoader::requestImportModule):
* runtime/JSObject.h:
(JSC::JSObject::getAs const):
* runtime/JSPromise.cpp:
(JSC::JSPromise::createDeferredData):
* runtime/VM.h:
2021-05-03 Dmitry Bezhetskov <dbezhetskov@igalia.com>
[WASM-Function-References] Add call_ref instruction
https://bugs.webkit.org/show_bug.cgi?id=222903
Reviewed by Yusuke Suzuki.
Add support for call_ref instruction from the typed function
references proposal: https://github.com/WebAssembly/function-references/blob/master/proposals/function-references/Overview.md.
call_ref calls the given function references from the stack
and it does almost the same stuff as call_indirect but
it doesn't check signatures because wasm types system guaranties
correctness.
* bytecode/BytecodeList.rb:
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* llint/LowLevelInterpreter.asm:
* llint/WebAssembly.asm:
* runtime/Gate.h:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::addCallIndirect):
(JSC::Wasm::AirIRGenerator::addCallRef):
(JSC::Wasm::AirIRGenerator::emitIndirectCall):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::emitIndirectCall):
(JSC::Wasm::B3IRGenerator::addCallIndirect):
(JSC::Wasm::B3IRGenerator::addCallRef):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
(JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
* wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::LLIntGenerator::addCallRef):
* wasm/WasmSlowPaths.cpp:
(JSC::LLInt::doWasmCallRef):
(JSC::LLInt::WASM_SLOW_PATH_DECL):
* wasm/WasmSlowPaths.h:
* wasm/js/JSWebAssemblyTable.cpp:
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::WebAssemblyFunction):
* wasm/js/WebAssemblyFunction.h:
* wasm/js/WebAssemblyFunctionBase.cpp:
(JSC::WebAssemblyFunctionBase::WebAssemblyFunctionBase):
* wasm/js/WebAssemblyFunctionBase.h:
(JSC::WebAssemblyFunctionBase::offsetOfEntrypointLoadLocation):
* wasm/js/WebAssemblyWrapperFunction.cpp:
(JSC::WebAssemblyWrapperFunction::WebAssemblyWrapperFunction):
* wasm/js/WebAssemblyWrapperFunction.h:
* wasm/wasm.json:
2021-05-01 Chris Dumez <cdumez@apple.com>
Start leveraging std::filesystem in WTF::FileSystem
https://bugs.webkit.org/show_bug.cgi?id=225255
Reviewed by Sam Weinig.
Unexport some symbols to fix build.
* Configurations/JavaScriptCore.xcconfig:
2021-04-30 Filip Pizlo <fpizlo@apple.com>
Make small JIT pool tests pass on AS
https://bugs.webkit.org/show_bug.cgi?id=225256
Reviewed by Mark Lam.
If we ask for a JIT pool that is smaller than the smallest possible "region" (thing with jump
island) that we can create -- i.e. smaller than a jump region, then assume that the user is
asking us to create a pool that has that much usable space plus a jump region.
I think that this makes the option easier to use when you're testing ridiculously small JIT
pools, which we happen to do in our test suite.
Also remove some dead options I didn't mean to commit.
* jit/ExecutableAllocator.cpp:
(JSC::initializeJITPageReservation):
* runtime/OptionsList.h:
2021-04-30 Filip Pizlo <fpizlo@apple.com>
Make the JIT pool smaller on AS
https://bugs.webkit.org/show_bug.cgi?id=225249
Reviewed by Saam Barati.
This adds three related features:
- Makes it easy to dump where the JIT pool was allocated.
- Makes it possible to override the JIT pool size with Options even with jump islands.
- Changes the default JIT pool size on AS to 512MB.
Estimated 2% speed-up on JetStream2, 1.5% speed-up on Speedometer2.
* jit/ExecutableAllocator.cpp:
(JSC::initializeJITPageReservation):
* runtime/OptionsList.h:
2021-04-29 Saam Barati <sbarati@apple.com>
Inlining property accesses inside constant folding should check Options::useAccessInlining
https://bugs.webkit.org/show_bug.cgi?id=225194
Reviewed by Mark Lam.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
(JSC::DFG::ConstantFoldingPhase::tryFoldAsPutByOffset):
2021-04-29 Saam Barati <sbarati@apple.com>
Sampling profiler should dump a tier breakdown, and add ability to see time spent in C code with sampleCCode=0, and fix bugs with frames having the wrong jitType if they're inlined
https://bugs.webkit.org/show_bug.cgi?id=225116
Reviewed by Yusuke Suzuki.
This patch makes it so we also dump time spent in each tier when dumping top
bytecodes. This can be helpful info when analyzing benchmarks.
This patch also makes it so we know when we're in C/C++ code when we're not
using the sampleCCode=true option. I found some weird performance pathologies
with that option that cause us to not sample code at all. I was seeing ~50
samples taken for ~7 seconds of code running time. It's worth figuring out
what's going on there eventually. But for now, I've made it so that we
recognize that the top frame is C/C++ when using the collectExtraSamplingProfilerData=1
option.
This patch also fixes a bug where we mis-attribute JITTypes for inline
frames. We'd attribute it to whatever the CodeBlock was compiled as, instead
of using the machine frame's JITType.
* jsc.cpp:
(CommandLine::parseArguments):
* runtime/OptionsList.h:
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::takeSample):
(JSC::SamplingProfiler::processUnverifiedStackTraces):
(JSC::SamplingProfiler::StackFrame::displayName):
(JSC::SamplingProfiler::reportTopBytecodes):
2021-04-28 Mark Lam <mark.lam@apple.com>
Fix exception assertions in light of the TerminationException.
https://bugs.webkit.org/show_bug.cgi?id=225128
rdar://76694909
Reviewed by Robin Morisset.
Some pre-existing functions assertNoException() or releaseAssertNoException().
These assertion may not be valid anymore in light of the TerminationException, and
require some fix up:
1. If it makes sense to convert the assertion into an exception check, then do so.
For example, see objectPrototypeToString(), slow_path_create_this().
2. If the assertion is at the end of a function just before it returns, or if the
remaining code in the function will not be affected by the pending exception,
then we can replace the assertion as follows:
assertNoException() => assertNoExceptionExceptTermination()
releaseAssertNoException() => releaseAssertNoExceptionExceptTermination()
For example, see objectPrototypeHasOwnProperty(), JSObject::getOwnNonIndexPropertyNames().
3. If the assertion is in a function where perf is not absolutely critical, and the
function isn't calling any other functions that will re-enter the VM or potentially
get stuck in an infinite loop, then we can use a DeferTermination scope to defer
termination.
For example, see Debugger::pauseIfNeeded(), SamplingProfiler::StackFrame::nameFromCallee().
4. If the assertion is in an initializer function is only run once and adding
exception checks would complicate the code more than it's worth (an engineering
judgement), then use a DeferTermination scope.
For example, see ProgramExecutable::initializeGlobalProperties(), setupAdaptiveWatchpoint().
Some leaf (or near-leaf) functions that currently DECLARE_CATCH_SCOPE() may also
fall under this category.
For example, see JSFunction::prototypeForConstruction().
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::addBigIntConstant):
* debugger/Debugger.cpp:
(JSC::Debugger::pauseIfNeeded):
* dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* interpreter/Interpreter.cpp:
(JSC::notifyDebuggerOfUnwinding):
(JSC::Interpreter::executeProgram):
(JSC::Interpreter::debug):
* interpreter/ShadowChicken.cpp:
(JSC::ShadowChicken::functionsOnStack):
* jsc.cpp:
(runWithOptions):
* parser/ParserArena.cpp:
(JSC::IdentifierArena::makeBigIntDecimalIdentifier):
* runtime/AbstractModuleRecord.cpp:
(JSC::AbstractModuleRecord::finishCreation):
* runtime/CommonSlowPaths.cpp:
(JSC::JSC_DEFINE_COMMON_SLOW_PATH):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::sanitizedMessageString):
(JSC::ErrorInstance::sanitizedNameString):
* runtime/ExceptionScope.h:
(JSC::ExceptionScope::assertNoExceptionExceptTermination):
(JSC::ExceptionScope::releaseAssertNoExceptionExceptTermination):
* runtime/JSFunction.cpp:
(JSC::JSFunction::prototypeForConstruction):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewProtoFuncIncludes):
(JSC::genericTypedArrayViewProtoFuncIndexOf):
(JSC::genericTypedArrayViewProtoFuncLastIndexOf):
(JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
* runtime/JSGlobalObject.cpp:
(JSC::setupAdaptiveWatchpoint):
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::defineOwnProperty):
(JSC::JSGlobalObject::tryInstallSpeciesWatchpoint):
* runtime/JSModuleLoader.cpp:
(JSC::printableModuleKey):
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::finishCreation):
* runtime/JSObject.cpp:
(JSC::JSObject::ordinaryToPrimitive const):
(JSC::JSObject::getOwnNonIndexPropertyNames):
* runtime/JSTemplateObjectDescriptor.cpp:
(JSC::JSTemplateObjectDescriptor::createTemplateObject):
* runtime/JSTypedArrayViewPrototype.cpp:
* runtime/ObjectPrototype.cpp:
(JSC::objectPrototypeHasOwnProperty):
(JSC::objectPrototypeToString):
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties):
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::StackFrame::nameFromCallee):
* tools/JSDollarVM.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
2021-04-28 Daniel Kolesa <dkolesa@igalia.com>
[WPE][GTK] More correct fixes for stack size issues on musl libc
https://bugs.webkit.org/show_bug.cgi?id=225099
Reviewed by Adrian Perez de Castro.
Partial revert https://bugs.webkit.org/show_bug.cgi?id=210068
After fixing the thread stack issues in WTF properly, we can revert
the JSC options changes, which are actually harmful since they result
in JSC being unstable. Previously, softReservedZoneSize was causing a
crash when set to 128K because of the main thread stack bounds, and
this is now fixed. We can keep the maxPerThreadStackUsage at 5M as
well; there is no fundamental difference from how things are done on
glibc anymore.
* runtime/OptionsList.h:
2021-04-27 Filip Pizlo <fpizlo@apple.com>
Get the bytecode profiler working again
https://bugs.webkit.org/show_bug.cgi?id=225129
Reviewed by Saam Barati.
The bytecode profiler was broken because it was trying to look at unset labels. This patch
improves our label discipline a bit so we don't try to look at unset labels.
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::linkOSRExits):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitInvalidationPoint):
2021-04-27 Mark Lam <mark.lam@apple.com>
Move ExceptionExpectation into its own .h file.
https://bugs.webkit.org/show_bug.cgi?id=225124
Reviewed by Robin Morisset.
Also fixed some compiler warnings.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/ExceptionExpectation.h: Added.
* runtime/ExceptionHelpers.h:
* runtime/HashMapImplInlines.h:
(JSC::jsMapHashImpl):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::setWithSpecificType):
(JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
2021-04-27 Alexey Shvayka <shvaikalesh@gmail.com>
[JSC] Remove defaultValue() from the method table
https://bugs.webkit.org/show_bug.cgi?id=225032
Reviewed by Darin Adler.
This patch not only removes the unnecessary method table entry, but also makes
the presence of custom ToPrimitive behavior observable to userland code.
To maintain object identity and (possibly) enable caching, Symbol.toPrimitive
method is stored on a structure. To avoid any potential breakage, it's made
replaceable and configurable, covering the case when its holder is a [[ProxyTarget]].
For JSCallbackObject, Symbol.toPrimitive method is created only if ConvertToType
callback is present, before initialization is performed.
Also, this change adds additional ordinaryToPrimitive() cast to fix the invariant
that toPrimitive() returns a primitive value, which was broken if ConvertToType
callback returned an object. The invariant is enforced by the spec [1][2] and is
validated via assertion in JSValue::toStringSlowCase().
[1]: https://tc39.es/ecma262/#sec-toprimitive (step 2.b.vi)
[2]: https://tc39.es/ecma262/#sec-ordinarytoprimitive (step 6)
* API/JSCallbackObject.h:
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::init):
(JSC::JSCallbackObject<Parent>::customToPrimitive):
(JSC::JSCallbackObject<Parent>::defaultValue): Deleted.
* API/tests/testapiScripts/testapi.js:
* runtime/ClassInfo.h:
* runtime/JSCell.cpp:
(JSC::JSCell::defaultValue): Deleted.
* runtime/JSCell.h:
* runtime/JSObject.cpp:
(JSC::JSObject::toPrimitive const):
(JSC::JSObject::defaultValue): Deleted.
* runtime/JSObject.h:
* runtime/Operations.cpp:
(JSC::jsAddSlowCase):
2021-04-27 Keith Miller <keith_miller@apple.com>
StructureStubInfo and PolymorphicAccess should account for their non-GC memory
https://bugs.webkit.org/show_bug.cgi?id=225113
Reviewed by Mark Lam.
We don't pass the ConcurrentJSLocker to the helper methods here since the
DECLARE_VISIT_AGGREGATE macro does not allow for extra parameters to be passed.
I filed https://bugs.webkit.org/show_bug.cgi?id=225114 to track that.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::JITData::size const):
* bytecode/PolymorphicAccess.cpp:
(JSC::PolymorphicAccess::extraMemoryInBytes const):
* bytecode/PolymorphicAccess.h:
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::extraMemoryInBytes):
* bytecode/StructureStubInfo.h:
2021-04-26 Keith Miller <keith_miller@apple.com>
UnlinkedCodeBlock should have better accounting for extra memory
https://bugs.webkit.org/show_bug.cgi?id=225080
Reviewed by Mark Lam.
Right now we aren't telling the JS GC about the extra memory
attached to UnlinkedCodeBlocks. It looks like on at least some sites this
can be a fairly large percentage of the total memory retained by
the JS object graph. This is very similar to the change we made for
CodeBlocks in r276610.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::visitChildrenImpl):
(JSC::UnlinkedCodeBlock::RareData::sizeInBytes const):
* bytecode/UnlinkedCodeBlock.h:
2021-04-26 Alex Christensen <achristensen@webkit.org>
Update Mac-specific CMake files
https://bugs.webkit.org/show_bug.cgi?id=225064
Rubber-stamped by Tim Horton.
* PlatformMac.cmake:
2021-04-26 Mark Lam <mark.lam@apple.com>
%TypedArray%.prototype.sort() should not use a regular array as a temp buffer.
https://bugs.webkit.org/show_bug.cgi?id=225062
rdar://77021547
Reviewed by Yusuke Suzuki.
%TypedArray%.prototype.sort() should not be affected by property changes in
Array.prototype.
References:
[1] https://tc39.es/ecma262/#sec-%typedarray%.prototype.sort
[2] https://tc39.es/ecma262/#sec-array.prototype.sort
[3] https://tc39.es/ecma262/#sec-sortcompare
* builtins/TypedArrayPrototype.js:
(globalPrivate.typedArrayMergeSort):
2021-04-26 Keith Miller <keith_miller@apple.com>
CodeBlock should do a better job accounting for extra memory it allocates.
https://bugs.webkit.org/show_bug.cgi?id=225068
Reviewed by Mark Lam.
Right now we aren't telling the JS GC about the extra memory
attached to CodeBlocks. It looks like on at least some sites this
can be a fairly large percentage of the total memory retained by
the JS object graph.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::visitChildren):
(JSC::CodeBlock::JITData::size const):
* bytecode/CodeBlock.h:
* jit/JITCodeMap.h:
(JSC::JITCodeMap::memorySize const):
2021-04-26 Keith Miller <keith_miller@apple.com>
numCalleeLocals, numParameters, and numVars should be unsigned
https://bugs.webkit.org/show_bug.cgi?id=224995
Reviewed by Mark Lam.
All of the various CodeBlock classes currently have the
numCalleeLocals and numVars marked as ints. I believe this is just
a historical artifact or because VirtualRegister's offset is an
int to make handling constants easier. Regardless, it's a bit
strange to not handle the sign conversion at the point of
comparison between a VirtualRegister offset and the local/var
count. This doesn't completely fix every place we use ints for
these values but starts on the right track. Lastly, I also added
some Check<unsigned>s to the wasm parser for sanity checking.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::setNumParameters):
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeIndexSlow):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::numParameters const):
(JSC::CodeBlock::numberOfArgumentsToSkip const):
(JSC::CodeBlock::numCalleeLocals const):
(JSC::CodeBlock::numVars const):
(JSC::CodeBlock::numTmps const):
(JSC::CodeBlock::addressOfNumParameters):
(JSC::CodeBlock::isTemporaryRegister):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::numCalleeLocals const):
(JSC::UnlinkedCodeBlock::numVars const):
* bytecode/UnlinkedCodeBlockGenerator.h:
(JSC::UnlinkedCodeBlockGenerator::numCalleeLocals const):
(JSC::UnlinkedCodeBlockGenerator::numVars const):
(JSC::UnlinkedCodeBlockGenerator::setNumCalleeLocals):
(JSC::UnlinkedCodeBlockGenerator::setNumVars):
(JSC::UnlinkedCodeBlockGenerator::setNumParameters):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::emitPushFunctionNameScope):
* bytecompiler/BytecodeGeneratorBaseInlines.h:
(JSC::BytecodeGeneratorBase<Traits>::newRegister):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
(JSC::DFG::ByteCodeParser::inliningCost):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGOSREntrypointCreationPhase.cpp:
(JSC::DFG::OSREntrypointCreationPhase::run):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::checkArgumentTypes):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::lower):
* ftl/FTLOSREntry.cpp:
(JSC::FTL::prepareOSREntry):
* interpreter/CallFrameClosure.h:
* interpreter/ProtoCallFrameInlines.h:
(JSC::ProtoCallFrame::init):
* jit/JIT.cpp:
(JSC::JIT::compileWithoutLinking):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::numberOfStackPaddingSlots):
(JSC::CommonSlowPaths::numberOfStackPaddingSlotsWithExtraSlots):
* wasm/WasmFunctionCodeBlock.h:
(JSC::Wasm::FunctionCodeBlock::numVars const):
(JSC::Wasm::FunctionCodeBlock::numCalleeLocals const):
(JSC::Wasm::FunctionCodeBlock::setNumVars):
(JSC::Wasm::FunctionCodeBlock::setNumCalleeLocals):
* wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::LLIntGenerator::push):
(JSC::Wasm::LLIntGenerator::getDropKeepCount):
(JSC::Wasm::LLIntGenerator::walkExpressionStack):
(JSC::Wasm::LLIntGenerator::checkConsistency):
(JSC::Wasm::LLIntGenerator::materializeConstantsAndLocals):
(JSC::Wasm::LLIntGenerator::splitStack):
(JSC::Wasm::LLIntGenerator::finalize):
(JSC::Wasm::LLIntGenerator::callInformationForCaller):
(JSC::Wasm::LLIntGenerator::addLoop):
(JSC::Wasm::LLIntGenerator::addTopLevel):
(JSC::Wasm::LLIntGenerator::addBlock):
(JSC::Wasm::LLIntGenerator::addIf):
(JSC::Wasm::LLIntGenerator::addElseToUnreachable):
2021-04-26 Alexey Shvayka <shvaikalesh@gmail.com>
[JSC] OrdinarySet should invoke custom [[Set]] methods
https://bugs.webkit.org/show_bug.cgi?id=217916
Reviewed by Yusuke Suzuki.
This patch fixes putInlineSlow() to handle special properties (like JSFunction's "name"
and JSArray's "length") in prototype chain. When such property is encountered, prototype
chain traversal is stopped; if it's read-only, a TypeError is thrown in strict mode.
This change adds OverridesPut out of line type info flag, and utilizes it in putInlineSlow()
to invoke overriden methods. While this approach requires put() methods to be aware of
altered receivers, it renders several benefits:
1. put() method can be used for both "real" [[Set]] overrides and special properties,
with its return value remaining `bool`;
2. it is simpler, faster, and more predictable than calling [[GetOwnProperty]] in
putInlineSlow() or adding defineOwnPropertyViaPut() to the method table.
Removes ordinarySetSlow() for non-index properties, which didn't invoke some [[Set]]
methods as well. Instead, definePropertyOnReceiver() is introduced for altered receivers,
which performs correctly when reached because:
1. all special properties were already handled (unless it's Reflect.set);
2. performing putDirectInternal() is unobservable (unless ProxyObject was seen);
3. putDirectInternal() now fully implements property definition of OrdinarySet [1];
4. put() override is required if a spec defines custom [[DefineOwnProperty]].
Since indexed puts handle overrides / altered receivers quite differently, they will
be fixed in a follow-up, completely removing ordinarySetSlow().
Also, by merging putEntry() / putToPrimitive() into putInlineSlow() and introducing
putInlineFastReplacingStaticPropertyIfNeeded() helper, this patch fixes a few bugs:
1. Direct [[Set]] to non-reified static property now preserves its attributes when replacing [[Value]].
2. Prototype chain [[Set]] to non-reified static property now throws if receiver is non-extensible.
3. Non-reified static writable property now shadows read-only one that is further in prototype chain.
4. Non-reified static properties in prototype chain of a primitive are now considered.
Fixes a few issues that were previously unobservable:
1. PropertyAttribute::CustomValue is now unset when a setter-less property is reassigned.
2. uint64_t putByIndexInline() now calls put() via method table like uint32_t counterpart.
Other notable refactors:
1. Inlines callCustomSetter(), dropping weird TriState return value.
2. Simplifies initialization of StringPrototype.
3. Simplifies isThisValueAltered() to pointer comparisons at non-JSProxy call sites.
4. Removes doPutPropertySecurityCheck() methods as the same checks are performed by put() methods.
5. Removes prototypeChainMayInterceptStoreTo(), which pretty much duplicated canPerformFastPutInline().
6. Removes dummy JSArrayBufferView::put() method.
7. Removes now unused lookupPut().
Aligns JSC with V8 and SpiderMonkey.
This patch carefully preserves the current behavior of Reflect.set with CustomValue
and prototype chain [[Set]] to a JSCallbackObject / legacy platform object.
This change is performance-neutral on /put/ microbenchmarks as it doesn't affect
caching, only the slow path. Reflect.set with JSFinalObject receiver is 130% faster.
putInlineSlow() microbenchmarks progress by 4-18%.
[1]: https://tc39.es/ecma262/#sec-ordinarysetwithowndescriptor (step 3)
* API/JSCallbackObject.h:
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::put):
* API/tests/testapiScripts/testapi.js:
* debugger/DebuggerScope.h:
* runtime/ClassInfo.h:
* runtime/ClonedArguments.h:
* runtime/CustomGetterSetter.cpp:
(JSC::callCustomSetter): Deleted.
* runtime/CustomGetterSetter.h:
* runtime/ErrorConstructor.h:
* runtime/ErrorInstance.h:
* runtime/GenericArguments.h:
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments<Type>::put):
* runtime/GetterSetter.h:
* runtime/JSArray.cpp:
(JSC::JSArray::put):
* runtime/JSArray.h:
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::put): Deleted.
* runtime/JSArrayBufferView.h:
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive):
* runtime/JSCell.cpp:
(JSC::JSCell::doPutPropertySecurityCheck): Deleted.
* runtime/JSCell.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::put):
* runtime/JSFunction.h:
* runtime/JSGenericTypedArrayView.h:
* runtime/JSGlobalLexicalEnvironment.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::put):
* runtime/JSGlobalObject.h:
* runtime/JSLexicalEnvironment.h:
* runtime/JSModuleEnvironment.h:
* runtime/JSModuleNamespaceObject.h:
* runtime/JSObject.cpp:
(JSC::JSObject::getOwnPropertySlot):
(JSC::JSObject::putInlineSlow):
(JSC::definePropertyOnReceiverSlow):
(JSC::JSObject::definePropertyOnReceiver):
(JSC::JSObject::putInlineFastReplacingStaticPropertyIfNeeded):
(JSC::JSObject::doPutPropertySecurityCheck): Deleted.
(JSC::JSObject::prototypeChainMayInterceptStoreTo): Deleted.
* runtime/JSObject.h:
(JSC::JSObject::putByIndexInline):
(JSC::JSObject::hasNonReifiedStaticProperties):
(JSC::JSObject::getOwnPropertySlot):
(JSC::JSObject::putDirect):
(JSC::JSObject::doPutPropertySecurityCheck): Deleted.
* runtime/JSObjectInlines.h:
(JSC::JSObject::canPerformFastPutInlineExcludingProto):
(JSC::JSObject::putInlineForJSObject):
(JSC::JSObject::putInlineFast):
(JSC::JSObject::putDirectInternal):
* runtime/JSProxy.h:
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::hasStaticPropertyTable const):
(JSC::TypeInfo::overridesPut const):
(JSC::TypeInfo::getOwnPropertySlotMayBeWrongAboutDontEnum const):
(JSC::TypeInfo::hasPutPropertySecurityCheck const): Deleted.
* runtime/Lookup.h:
(JSC::putEntry): Deleted.
(JSC::lookupPut): Deleted.
* runtime/PropertySlot.h:
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::put):
* runtime/ProxyObject.h:
* runtime/PutPropertySlot.h:
(JSC::PutPropertySlot::PutPropertySlot):
(JSC::PutPropertySlot::context const):
(JSC::PutPropertySlot::isTaintedByOpaqueObject const):
(JSC::PutPropertySlot::setIsTaintedByOpaqueObject):
* runtime/ReflectObject.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::put):
* runtime/RegExpObject.h:
* runtime/StringObject.cpp:
(JSC::StringObject::put):
* runtime/StringObject.h:
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
(JSC::StringPrototype::create):
* runtime/StringPrototype.h:
* runtime/Structure.cpp:
(JSC::Structure::validateFlags):
* runtime/Structure.h:
(JSC::Structure::hasNonReifiedStaticProperties const):
* tools/JSDollarVM.cpp:
2021-04-23 Michael Saboff <msaboff@apple.com>
[YARR Interpreter] Improper backtrack of parentheses with non-zero based greedy quantifiers
https://bugs.webkit.org/show_bug.cgi?id=224983
Reviewed by Mark Lam.
When we backtrack a parentheses with a greedy non zero based quantifier,
we don't properly restore for the case where we hadn't reached the minimum count.
We now save the input position on entry and restore it when we backtrack for
this case. We also properly release the allocated ParenthesesDisjunctionContext's.
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::Interpreter::matchParentheses):
(JSC::Yarr::Interpreter::backtrackParentheses):
2021-04-23 Mark Lam <mark.lam@apple.com>
Fix B3 strength reduction for shl.
https://bugs.webkit.org/show_bug.cgi?id=224913
rdar://76978874
Reviewed by Michael Saboff.
If the operation can potentially either underflow or overflow, then the result
can be any value.
* b3/B3ReduceStrength.cpp:
2021-04-23 Fujii Hironori <Hironori.Fujii@sony.com>
[JSC][Win] callOperationNoExceptionCheck() also needs to support operations that return SlowPathReturnType
https://bugs.webkit.org/show_bug.cgi?id=224964
Reviewed by Yusuke Suzuki.
r229989 (Bug 183655) added the x64 Windows support only for
callOperation(), but for callOperationNoExceptionCheck().
callOperationNoExceptionCheck() also needs the x64 Windows
support.
This change is a preparation for Bug 224920 that is going to use
callOperationNoExceptionCheck instead of callOperation.
* jit/JIT.h:
(callOperation): Rewrote by using 'if constexpr' instead of SFINAE.
(callOperationNoExceptionCheck): Added a new implementation for
x64 Windows based on callOperation.
2021-04-23 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r276486.
https://bugs.webkit.org/show_bug.cgi?id=224973
broke windows build
Reverted changeset:
"[JSC][Win] callOperationNoExceptionCheck() also needs to
support operations that return SlowPathReturnType"
https://bugs.webkit.org/show_bug.cgi?id=224964
https://trac.webkit.org/changeset/276486
2021-04-22 Fujii Hironori <Hironori.Fujii@sony.com>
[JSC][Win] callOperationNoExceptionCheck() also needs to support operations that return SlowPathReturnType
https://bugs.webkit.org/show_bug.cgi?id=224964
Reviewed by Yusuke Suzuki.
r229989 (Bug 183655) added the x64 Windows support only for
callOperation(), but for callOperationNoExceptionCheck().
callOperationNoExceptionCheck() also needs the x64 Windows
support.
This change is a preparation for Bug 224920 that is going to use
callOperationNoExceptionCheck instead of callOperation.
* jit/JIT.h:
(callOperation): Rewrote by using 'if constexpr' instead of SFINAE.
(callOperationNoExceptionCheck): Added a new implementation for
x64 Windows based on callOperation.
2021-04-22 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r276456.
https://bugs.webkit.org/show_bug.cgi?id=224952
Windows specific crash
Reverted changeset:
"[JSC} Remove exception checks from non-throwing function
calls in Baseline JIT"
https://bugs.webkit.org/show_bug.cgi?id=224920
https://trac.webkit.org/changeset/276456
2021-04-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC} Remove exception checks from non-throwing function calls in Baseline JIT
https://bugs.webkit.org/show_bug.cgi?id=224920
Reviewed by Tadeu Zagallo.
These functions are not taking JSGlobalObject and will not throw an error.
Use callOperationNoExceptionCheck instead to avoid emitting unnecessary exception checks.
* jit/JIT.cpp:
(JSC::JIT::emitEnterOptimizationCheck):
* jit/JITOpcodes.cpp:
(JSC::JIT::emitSlow_op_new_object):
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emitSlow_op_loop_hint):
(JSC::JIT::emit_op_profile_type):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emitSlow_op_new_object):
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emit_op_profile_type):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitWriteBarrier):
2021-04-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Baseline should have fast path for switch_imm
https://bugs.webkit.org/show_bug.cgi?id=224521
Reviewed by Tadeu Zagallo.
This patch implements op_switch_imm fast path in Baseline.
We have this fast path in LLInt, DFG, and FTL. So only Baseline lacks this.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_switch_imm):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_switch_imm):
2021-04-21 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] DFG / FTL should inline switch_string
https://bugs.webkit.org/show_bug.cgi?id=224578
Reviewed by Mark Lam.
Because of r275840 change, we no longer copy StringJumpTable when compiling DFG / FTL code.
Instead we are using a pointer to UnlinkedStringTable stored in UnlinkedCodeBlock.
This allows DFG / FTL to inline CodeBlock which includes op_switch_string. We were previously not able
to do that because we cannot copy StringImpl in DFG / FTL concurrent compiler thread.
1. We handle StringJumpTable / UnlinkedStringJumpTable in the same way as SimpleJumpTable / UnlinkedSimpleJumpTable.
2. We put m_ctiDefault of StringJumpTable in the last element of m_ctiOffsets vector of StringJumpTable to make
sizeof(StringJumpTable) small.
3. We use m_indexInTable instead of m_branchOffset in FTL switch generation to make switch table dense.
The microbenchmark shows 30% improvement because of unlocking inlining feature.
ToT Patched
switch-inlining 27.1238+-0.2708 ^ 20.2630+-0.1477 ^ definitely 1.3386x faster
<geometric> 27.1238+-0.2708 ^ 20.2630+-0.1477 ^ definitely 1.3386x faster
* bytecode/JumpTable.h:
(JSC::StringJumpTable::ensureCTITable):
(JSC::StringJumpTable::ctiForValue const):
(JSC::StringJumpTable::ctiDefault const):
(JSC::StringJumpTable::isEmpty const):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedStringJumpTable::indexForValue const):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGGraph.h:
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
* dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::switchStringSlow):
* ftl/FTLOperations.cpp:
(JSC::FTL::JSC_DEFINE_JIT_OPERATION):
* ftl/FTLOperations.h:
* jit/JIT.cpp:
(JSC::JIT::link):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_switch_string):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_switch_string):
* jit/JITOperations.cpp:
(JSC::JSC_DEFINE_JIT_OPERATION):
2021-04-21 Adrian Perez de Castro <aperez@igalia.com>
Non-unified build fixes, mid April 2021 edition
https://bugs.webkit.org/show_bug.cgi?id=222652
<rdar://problem/75262285>
Unreviewed non-unified build fixes.
* bytecode/JumpTable.cpp: Remove inclusion of wtf/text/StringHash.h
* bytecode/JumpTable.h: Add missing inclusions of wtf/FixedVector.h and
wtf/text/StringHash.h
* bytecode/SpeculatedType.cpp: Add missing includes JSCJSValueInlines.h and
JSCellInlines.h
* bytecompiler/BytecodeGenerator.cpp: Move template method to header, remove now uneeded
LinkTimeConstant.h include.
* bytecompiler/BytecodeGenerator.h: Add include for LinkTimeConstant.h
(JSC::BytecodeGenerator::emitDirectSetPrototypeOf): Template method moved here from
BytecodeGenerator.cpp to avoid compile errors due to usage of missing template body
definition.
* dfg/DFGDesiredGlobalProperties.cpp: Add missing DFGDesiredWatchpoints.h include.
* ftl/FTLAbstractHeap.cpp: Add missing JSCJSValueInlines.h include.
* runtime/JSCustomGetterFunction.cpp: Add missing IdentifierInlines.h include.
* runtime/JSCustomSetterFunction.cpp: Ditto.
* runtime/SetPrototype.cpp: Add missing HashMapImplInlines.h include.
* runtime/VMTraps.cpp: Add missing VMEntryScope.h include.
* runtime/WeakSetConstructor.cpp: Add missing WeakMapImplInlines.h include.
* runtime/WeakSetPrototype.cpp: Add missing includes for HashMapImplInlines.h and
WeakMapImplInlines.h
* wasm/js/JSWebAssemblyTable.cpp: Add missing ObjectConstructor.h include.
2021-04-20 Michael Catanzaro <mcatanzaro@gnome.org>
Static asserts in WasmAirIRGenerator.cpp and WasmB3IRGenerator.cpp trigger -Wnonnull warnings with GCC 11
https://bugs.webkit.org/show_bug.cgi?id=224826
Reviewed by Yusuke Suzuki.
Rewrite these static asserts to avoid warnings when built with GCC 11. Credit to Jonathan
Wakely for providing this mind-bending solution.
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
(JSC::Wasm::AirIRGenerator::addCurrentMemory):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addCurrentMemory):
2021-04-20 Michael Catanzaro <mcatanzaro@gnome.org>
-Warray-bounds warning in AirAllocateRegistersByGraphColoring.cpp with GCC 11
https://bugs.webkit.org/show_bug.cgi?id=224782
Reviewed by Darin Adler.
These warnings don't make any sense to me. Suppress them.
* b3/air/AirAllocateRegistersByGraphColoring.cpp:
2021-04-20 Keith Miller <keith_miller@apple.com>
FullGCActivityCallback should use the percentage of pages uncompressed in RAM to determine deferral.
https://bugs.webkit.org/show_bug.cgi?id=224817
Reviewed by Filip Pizlo.
Right now we try to determine if too many pages are paged out by
dereferencing them and bailing out of the GC if we go over a
deadline. While this works if the only goal is to avoid causing
extensive thrashing on spinny disks (HDD), it doesn't prevent
thrashing when access to disk is fast (e.g. SSD). This is because
on fast disks the proportional time to load the memory from disk
is much lower. Additionally, on SSDs in particular we don't want
to load the pages into RAM then bail as that will force a
different page onto disk, increasing wear.
This patch switches to asking the OS if each MarkedBlock is paged
out. Then if we are over a threshold we wait until we would have
GC'd anyway. This patch uses the (maxVMGrowthFactor - 1) as the
percentage of "slow" pages (paged out or compressed) needed to
defer the GC. The idea behind that threshold is that if we add
that many pages then the same number of pages would be forced
out of RAM for us to do a GC anyway (in the limit).
* heap/BlockDirectory.cpp:
(JSC::BlockDirectory::updatePercentageOfPagedOutPages):
(JSC::BlockDirectory::isPagedOut): Deleted.
* heap/BlockDirectory.h:
* heap/FullGCActivityCallback.cpp:
(JSC::FullGCActivityCallback::doCollection):
* heap/Heap.cpp:
(JSC::Heap::isPagedOut):
* heap/Heap.h:
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::isPagedOut):
* heap/MarkedSpace.h:
* runtime/OptionsList.h:
2021-04-20 Don Olmstead <don.olmstead@sony.com>
[CMake] Don't use FORWARDING_HEADERS_DIR for JSC GLib headers
https://bugs.webkit.org/show_bug.cgi?id=224821
Reviewed by Michael Catanzaro.
Use JavaScriptCoreGLib_FRAMEWORK_HEADERS_DIR and JavaScriptCoreGLib_DERIVED_SOURCES_DIR
for GLib JSC headers instead of FORWARDING_HEADERS_DIR and DERIVED_SOURCES_DIR.
* GLib.cmake:
* PlatformGTK.cmake:
2021-04-20 Ben Nham <nham@apple.com>
LinkBuffer fails to build when MALLOC_HEAP_BREAKDOWN is enabled
https://bugs.webkit.org/show_bug.cgi?id=224722
Reviewed by Yusuke Suzuki.
When ENABLE_MALLOC_HEAP_BREAKDOWN is set, LinkBuffer causes a build failure at link time
since it never defines its debugHeap. Fix that.
* assembler/LinkBuffer.cpp:
2021-04-20 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use FixedVector for LLIntPrototypeLoadAdaptiveStructureWatchpoint vector
https://bugs.webkit.org/show_bug.cgi?id=224729
Reviewed by Darin Adler.
Replace Vector<LLIntPrototypeLoadAdaptiveStructureWatchpoint> with FixedVector.
* bytecode/CodeBlock.h:
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::initialize):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setupGetByIdPrototypeCache):
2021-04-19 Mark Lam <mark.lam@apple.com>
Build fix for Debug -O3 after r276162.
https://bugs.webkit.org/show_bug.cgi?id=224681
rdar://76698113
Not reviewed.
* runtime/JSObject.cpp:
2021-04-19 Kimmo Kinnunen <kkinnunen@apple.com>
Enable -Wthread-safety, add attributes to custom lock classes, and provide macros to declare guards
https://bugs.webkit.org/show_bug.cgi?id=221614
<rdar://problem/74396781>
Reviewed by David Kilzer.
Add -Wthread-safety to compile flags.
* Configurations/Base.xcconfig:
2021-04-18 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, build fix
https://bugs.webkit.org/show_bug.cgi?id=224715
* dfg/DFGDesiredWatchpoints.h:
2021-04-18 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Do not use Bag<> for DFG / FTL watchpoints
https://bugs.webkit.org/show_bug.cgi?id=224715
Reviewed by Darin Adler.
While Bag<> is useful since its allocated memory will not be moved,
this is really memory-inefficient data structure. Each entry gets a
tail pointer (so adding 8 bytes) and we allocate each entry separately.
In DFG and FTL, we are using Bag<> for watchpoints. But this is not necessary actually: thanks to
concurrent compilers, our watchpoint registration is batched at the end of compilation. This means
that we have a way to know how many watchpoints we should register at that point.
In this patch, we introduce WatchpointCollector. In DesiredGlobalProperties, we run reallyAdd twice
with WatchpointCollector. First time, we just count # of watchpoints. Then we allocate FixedVector<XXXWatchpoint>
and install them. Since we do not (cannot) grow this fixed vector, watchpoint's address will not be changed as required.
We also move DesiredGlobalProperties under DesiredWatchpoints since this basically registers watchpoints.
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
(JSC::AdaptiveInferredPropertyValueWatchpointBase::AdaptiveInferredPropertyValueWatchpointBase):
(JSC::AdaptiveInferredPropertyValueWatchpointBase::initialize):
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
* bytecode/CodeBlockJettisoningWatchpoint.h:
* dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::AdaptiveInferredPropertyValueWatchpoint):
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::initialize):
* dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h:
* dfg/DFGAdaptiveStructureWatchpoint.cpp:
(JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
(JSC::DFG::AdaptiveStructureWatchpoint::initialize):
* dfg/DFGAdaptiveStructureWatchpoint.h:
* dfg/DFGCommonData.cpp:
(JSC::DFG::CommonData::validateReferences):
(JSC::DFG::CommonData::clearWatchpoints):
* dfg/DFGCommonData.h:
* dfg/DFGDesiredGlobalProperties.cpp:
(JSC::DFG::DesiredGlobalProperties::reallyAdd):
* dfg/DFGDesiredGlobalProperties.h:
* dfg/DFGDesiredWatchpoints.cpp:
(JSC::DFG::ArrayBufferViewWatchpointAdaptor::add):
(JSC::DFG::SymbolTableAdaptor::add):
(JSC::DFG::FunctionExecutableAdaptor::add):
(JSC::DFG::AdaptiveStructureWatchpointAdaptor::add):
(JSC::DFG::DesiredWatchpoints::addLazily):
(JSC::DFG::DesiredWatchpoints::reallyAdd):
(JSC::DFG::DesiredWatchpoints::areStillValidOnMainThread):
(JSC::DFG::WatchpointCollector::finalize):
* dfg/DFGDesiredWatchpoints.h:
(JSC::DFG::SetPointerAdaptor::add):
(JSC::DFG::GenericDesiredWatchpoints::reallyAdd):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::watchGlobalProperty):
* dfg/DFGGraph.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::reallyAdd):
(JSC::DFG::Plan::isStillValidOnMainThread):
(JSC::DFG::Plan::cancel):
* dfg/DFGPlan.h:
(JSC::DFG::Plan::transitions):
(JSC::DFG::Plan::globalProperties): Deleted.
2021-04-18 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Make more DFG/FTL data FixedVector/Vector
https://bugs.webkit.org/show_bug.cgi?id=224713
Reviewed by Darin Adler.
1. DFG::JITCode::m_osrEntry / DFG::JITCode::m_osrExit / DFG::JITCode::m_speculationRecovery are changed to FixedVector.
They are added at compiling time, and after that, these vectors are not modified. So when finalizing, we can easily make it FixedVector.
We also change OSREntry::{m_reshufflings,m_expectedValues} to FixedVector and FixedOperands.
2. FTL::JITCode::m_osrExit is changed from SegmentedVector to Vector. We are still using Vector since it also involves osrExitDescriptor.
But later, we should merge m_osrExit to osrExitDescriptor. Vector is still better than SegmentedVector since it wastes several entries
per segment. SegmentedVector was used to use a direct pointer of OSRExit (this is not possible in Vector since this pointer can be invalidated
after growing), but usage of that is fairly limited so that we can just replace them with m_index + osrExit vector.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::tallyFrequentExitSites):
* bytecode/Operands.h:
(JSC::Operands::Operands):
* dfg/DFGJITCode.cpp:
(JSC::DFG::JITCode::shrinkToFit):
(JSC::DFG::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
(JSC::DFG::JITCode::validateReferences):
(JSC::DFG::JITCode::findPC):
(JSC::DFG::JITCode::finalizeOSREntrypoints):
* dfg/DFGJITCode.h:
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::linkOSRExits):
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::noticeOSREntry):
(JSC::DFG::JITCompiler::appendExceptionHandlingOSRExit):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::appendOSRExit):
(JSC::DFG::JITCompiler::appendSpeculationRecovery):
* dfg/DFGOSREntry.h:
* dfg/DFGOSRExit.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::speculationCheck):
(JSC::DFG::SpeculativeJIT::emitInvalidationPoint):
(JSC::DFG::SpeculativeJIT::linkOSREntries):
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::shrinkToFit):
(JSC::FTL::JITCode::validateReferences):
(JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
(JSC::FTL::JITCode::findPC):
* ftl/FTLJITCode.h:
* ftl/FTLOSRExit.cpp:
(JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
(JSC::FTL::OSRExit::OSRExit):
* ftl/FTLOSRExit.h:
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::JSC_DEFINE_JIT_OPERATION):
* ftl/FTLOSRExitHandle.cpp:
(JSC::FTL::OSRExitHandle::emitExitThunk):
* ftl/FTLOSRExitHandle.h:
(JSC::FTL::OSRExitHandle::OSRExitHandle):
* ftl/FTLPatchpointExceptionHandle.cpp:
(JSC::FTL::PatchpointExceptionHandle::scheduleExitCreationForUnwind):
2021-04-17 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, suppress warnings
https://bugs.webkit.org/show_bug.cgi?id=224616
* runtime/HashMapImpl.h:
* runtime/HashMapImplInlines.h:
(JSC::areKeysEqual):
(JSC::wangsInt64Hash):
2021-04-16 Mark Lam <mark.lam@apple.com>
More changes to support the TerminationException.
https://bugs.webkit.org/show_bug.cgi?id=224681
rdar://76698113
Reviewed by Keith Miller.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::executeProgram):
- ProgramExecutable::initializeGlobalProperties() can throw the TerminationException.
Add handling for that.
* runtime/JSObject.cpp:
(JSC::JSObject::defineOwnIndexedProperty):
- JSObject::defineOwnIndexedProperty() has a blob of assertion code that it verifying
that getOwnPropertyDescriptor() should succeed without throwing any exceptions if
the fast path is allowed. However, this is assertion is only true if there isn't
a termination being requested. So, use the DeferTermination scope to allow this
assertion to be tested without the complication of a TerminationException.
2021-04-16 Keith Miller <keith_miller@apple.com>
Before deleting a MarkedBlock we do not need to clear its m_directory pointer.
https://bugs.webkit.org/show_bug.cgi?id=224677
Reviewed by Yusuke Suzuki.
Right now when we are about to free a MarkedBlock we clear the
m_directory pointer in the MarkedBlock's Handle. This has the
downside, however, of potentially paging in the footer from disk /
the compressor, which some data we have seen shows is happening.
This patch prevents this uncessary store to hopefully reduce the
number of pageins/decompressions caused by Safari web content.
* heap/BlockDirectory.cpp:
(JSC::BlockDirectory::removeBlock):
(JSC::BlockDirectory::removeBlockForDeletion):
* heap/BlockDirectory.h:
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::~Handle):
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::freeBlock):
2021-04-16 Mark Lam <mark.lam@apple.com>
Build fix for Debug -O3 after r276069.
https://bugs.webkit.org/show_bug.cgi?id=224619
Not reviewed.
* runtime/HashMapImplInlines.h:
2021-04-15 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r276112.
https://bugs.webkit.org/show_bug.cgi?id=224646
.h files should not #include *Inlines.h files.
Reverted changeset:
"REGRESSION(r276039) [GTK] Build failures on Ubuntu 18.04"
https://bugs.webkit.org/show_bug.cgi?id=224644
https://trac.webkit.org/changeset/276112
2021-04-15 Lauro Moura <lmoura@igalia.com>
REGRESSION(r276039) [GTK] Build failures on Ubuntu 18.04
https://bugs.webkit.org/show_bug.cgi?id=224644
Unreviewed build fix.
* runtime/JSSet.h: Use HashMapImplInlines to include the base
finishCreation implementation. Somehow GCC 7.5 wasn't picking it up.
2021-04-15 Mark Lam <mark.lam@apple.com>
HashMapImpl::rehash() should use a version of jsMapHash that cannot throw.
https://bugs.webkit.org/show_bug.cgi?id=224610
rdar://76698910
Reviewed by Yusuke Suzuki.
For context, HashMapImpl::rehash()'s rehash operation relies on jsMapHash().
jsMapHash() can be interrupted by a TerminationException, and as a result, may
not return the string hash we are expecting. This in turn can lead to the
rehash operation hashing with wrong keys.
However, all the keys should have already been hashed. Hence, rehash() should
never see an exception thrown there. We can avoid this complication with the
TerminationException by simply calling an alternate version of jsMapHash() that
is guaranteed to never throw e.g. a jsMapHashForAlreadyHashedValue() function.
* runtime/ExceptionHelpers.h:
* runtime/HashMapImplInlines.h:
(JSC::jsMapHashImpl):
(JSC::jsMapHash):
(JSC::jsMapHashForAlreadyHashedValue):
(JSC::HashMapImpl<HashMapBucketType>::rehash):
2021-04-14 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Remove CodeBlock::RareData::m_catchProfiles
https://bugs.webkit.org/show_bug.cgi?id=224593
Reviewed by Mark Lam.
We are having this Vector just because we would like to destroy them when destroying the owner Baseline / LLInt CodeBlock.
But we are setting a pointer in OpCatch's metadata in Baseline / LLInt.
So we should just iterate metadata for that and destroy them in the destructor. No need to keep them separately.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::~CodeBlock):
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeIndex):
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeIndexSlow):
(JSC::CodeBlock::updateAllValueProfilePredictionsAndCountLiveness):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::createRareDataIfNecessary):
* bytecode/ValueProfile.h:
(JSC::ValueProfileAndVirtualRegisterBuffer::ValueProfileAndVirtualRegisterBuffer): Deleted.
(JSC::ValueProfileAndVirtualRegisterBuffer::~ValueProfileAndVirtualRegisterBuffer): Deleted.
(JSC::ValueProfileAndVirtualRegisterBuffer::forEach): Deleted.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
2021-04-15 Mark Lam <mark.lam@apple.com>
Optimize the DeferTermination scope to be more efficient.
https://bugs.webkit.org/show_bug.cgi?id=224619
Reviewed by Saam Barati.
This can be beneficial since we may be using DeferTermination in more places in
the code.
1. Added a VMTrapsInlines.h to hold the inline functions.
2. Split deferTermination() and undoDeferTermination() into fast and slow functions.
The fast functions are inlineable.
3. Remove the locking of VMTraps::m_lock in these functions. These functions only
modify the following:
a. VMTraps::m_deferTerminationCount
b. VMTraps::m_suspendedTerminationException
c. VMTraps::m_trapBits for setting the NeedTermination bit if needed.
d. VM::m_exception
Except for VMTraps::m_trapBits, all of these are only written to from the mutator
thread. VMTraps::m_trapBits is always written to using Atomics. There isn't
anything that needs to be guarded by VMTraps::m_lock.
4. Fix VMTraps::deferTermination() to only set m_suspendedTerminationException
and clear an existing TerminationException if it's being called from the
outermost DeferTermination (i.e. m_deferTerminationCount is 1 after incrementing).
These conditional operations are not done in VMTraps::deferTerminationSlow().
In practice, it wouldn't have mattered anyway because we would never throw a
TerminationException while a DeferTermination scope is in effect. The
the vm.isTerminationException() in the original deferTermination() would
always have prevented the slow path operations from being executed anyway.
However, for the purpose of this patch, we want to avoid as much unnecessary
work as possible in the fast path. Hence, it is good to skip the slow path
if deferTermination() isn't called from the outermost scope.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* jit/JITOperations.cpp:
* jsc.cpp:
* runtime/JSGlobalObject.cpp:
* runtime/VMTraps.cpp:
(JSC::VMTraps::deferTerminationSlow):
(JSC::VMTraps::undoDeferTerminationSlow):
(JSC::VMTraps::vm const): Deleted.
(JSC::VMTraps::deferTermination): Deleted.
(JSC::VMTraps::undoDeferTermination): Deleted.
* runtime/VMTraps.h:
* runtime/VMTrapsInlines.h: Added.
(JSC::VMTraps::vm const):
(JSC::VMTraps::deferTermination):
(JSC::VMTraps::undoDeferTermination):
2021-04-15 Mark Lam <mark.lam@apple.com>
Refactor inline functions out of HashMapImpl.h into HashMapImplInlines.h.
https://bugs.webkit.org/show_bug.cgi?id=224616
rdar://76713709
Reviewed by Yusuke Suzuki.
Also do the same for clients of HashMapImpl that require similar refactoring.
This fixes the #include of JSCJSValueInlines.h in HashMapImpl.h, as well as makes
it easier to use other inline functions from other classes in the implementation
of HashMapImpl's inline functions in the future.
This patch only moves inline functions out to their respective *Inlines.h.
There are no behavior changes.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAbstractInterpreterInlines.h:
* dfg/DFGOperations.cpp:
* runtime/AbstractModuleRecord.cpp:
* runtime/HashMapImpl.cpp:
* runtime/HashMapImpl.h:
(JSC::areKeysEqual): Deleted.
(JSC::normalizeMapKey): Deleted.
(JSC::wangsInt64Hash): Deleted.
(JSC::jsMapHash): Deleted.
(JSC::concurrentJSMapHash): Deleted.
(JSC::shouldShrink): Deleted.
(JSC::shouldRehashAfterAdd): Deleted.
(JSC::nextCapacity): Deleted.
(JSC::HashMapImpl::finishCreation): Deleted.
(JSC::HashMapImpl::findBucket): Deleted.
(JSC::HashMapImpl::get): Deleted.
(JSC::HashMapImpl::has): Deleted.
(JSC::HashMapImpl::add): Deleted.
(JSC::HashMapImpl::addNormalized): Deleted.
(JSC::HashMapImpl::remove): Deleted.
(JSC::HashMapImpl::clear): Deleted.
(JSC::HashMapImpl::setUpHeadAndTail): Deleted.
(JSC::HashMapImpl::addNormalizedNonExistingForCloning): Deleted.
(JSC::HashMapImpl::addNormalizedInternal): Deleted.
(JSC::HashMapImpl::findBucketAlreadyHashedAndNormalized): Deleted.
(JSC::HashMapImpl::rehash): Deleted.
(JSC::HashMapImpl::checkConsistency const): Deleted.
(JSC::HashMapImpl::makeAndSetNewBuffer): Deleted.
(JSC::HashMapImpl::assertBufferIsEmpty const): Deleted.
* runtime/HashMapImplInlines.h: Added.
(JSC::areKeysEqual):
(JSC::normalizeMapKey):
(JSC::wangsInt64Hash):
(JSC::jsMapHash):
(JSC::concurrentJSMapHash):
(JSC::shouldShrink):
(JSC::shouldRehashAfterAdd):
(JSC::nextCapacity):
(JSC::HashMapImpl<HashMapBucketType>::finishCreation):
(JSC::HashMapImpl<HashMapBucketType>::findBucket):
(JSC::HashMapImpl<HashMapBucketType>::get):
(JSC::HashMapImpl<HashMapBucketType>::has):
(JSC::HashMapImpl<HashMapBucketType>::add):
(JSC::HashMapImpl<HashMapBucketType>::addNormalized):
(JSC::HashMapImpl<HashMapBucketType>::remove):
(JSC::HashMapImpl<HashMapBucketType>::clear):
(JSC::HashMapImpl<HashMapBucketType>::setUpHeadAndTail):
(JSC::HashMapImpl<HashMapBucketType>::addNormalizedNonExistingForCloning):
(JSC::HashMapImpl<HashMapBucketType>::addNormalizedInternal):
(JSC::HashMapImpl<HashMapBucketType>::findBucketAlreadyHashedAndNormalized):
(JSC::HashMapImpl<HashMapBucketType>::rehash):
(JSC::HashMapImpl<HashMapBucketType>::checkConsistency const):
(JSC::HashMapImpl<HashMapBucketType>::makeAndSetNewBuffer):
(JSC::HashMapImpl<HashMapBucketType>::assertBufferIsEmpty const):
* runtime/JSMap.h:
* runtime/JSMapInlines.h: Added.
(JSC::JSMap::set):
* runtime/JSSetInlines.h: Added.
* runtime/JSWeakMap.h:
* runtime/JSWeakMapInlines.h: Added.
(JSC::JSWeakMap::set):
* runtime/MapConstructor.cpp:
* runtime/MapPrototype.cpp:
* runtime/SetConstructor.cpp:
* runtime/WeakMapConstructor.cpp:
* runtime/WeakMapImpl.h:
(JSC::jsWeakMapHash): Deleted.
(JSC::nextCapacityAfterBatchRemoval): Deleted.
(JSC::WeakMapImpl::add): Deleted.
(JSC::WeakMapImpl::shouldRehashAfterAdd const): Deleted.
(JSC::WeakMapImpl::rehash): Deleted.
* runtime/WeakMapImplInlines.h:
(JSC::jsWeakMapHash):
(JSC::nextCapacityAfterBatchRemoval):
(JSC::WeakMapImpl<WeakMapBucket>::add):
(JSC::WeakMapImpl<WeakMapBucket>::rehash):
(JSC::WeakMapImpl<WeakMapBucket>::shouldRehashAfterAdd const):
* runtime/WeakMapPrototype.cpp:
2021-04-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Change Vector<> to FixedVector<> in DFG::CommonData if possible
https://bugs.webkit.org/show_bug.cgi?id=224588
Reviewed by Mark Lam.
DFG::CommonData is kept alive so long as DFG code exists. It includes a lot of Vectors while they are not mutable after the DFG code compilation.
This patch changes Vector<> to FixedVector<> if possible to shrink sizeof(DFG::CommonData). And this also removes the need of calling shrinkToFit
explicitly for them.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::determineLiveness):
(JSC::CodeBlock::stronglyVisitWeakReferences):
(JSC::CodeBlock::jettison):
(JSC::CodeBlock::numberOfDFGIdentifiers const):
(JSC::CodeBlock::identifier const):
* bytecode/CodeBlock.h:
* dfg/DFGCommonData.cpp:
(JSC::DFG::CommonData::shrinkToFit):
(JSC::DFG::CommonData::invalidate):
(JSC::DFG::CommonData::~CommonData):
(JSC::DFG::CommonData::installVMTrapBreakpoints):
(JSC::DFG::CommonData::isVMTrapBreakpoint):
(JSC::DFG::CommonData::finalizeCatchEntrypoints):
(JSC::DFG::CommonData::notifyCompilingStructureTransition): Deleted.
* dfg/DFGCommonData.h:
(JSC::DFG::CommonData::catchOSREntryDataForBytecodeIndex):
(JSC::DFG::CommonData::appendCatchEntrypoint): Deleted.
* dfg/DFGDesiredIdentifiers.cpp:
(JSC::DFG::DesiredIdentifiers::reallyAdd):
* dfg/DFGDesiredTransitions.cpp:
(JSC::DFG::DesiredTransition::DesiredTransition):
(JSC::DFG::DesiredTransitions::DesiredTransitions):
(JSC::DFG::DesiredTransitions::addLazily):
(JSC::DFG::DesiredTransitions::reallyAdd):
(JSC::DFG::DesiredTransition::reallyAdd): Deleted.
* dfg/DFGDesiredTransitions.h:
* dfg/DFGDesiredWeakReferences.cpp:
(JSC::DFG::DesiredWeakReferences::reallyAdd):
* dfg/DFGGraph.h:
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::noticeCatchEntrypoint):
* dfg/DFGOSREntry.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::Plan):
(JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::linkOSREntries):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compilePutStructure):
(JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset):
(JSC::FTL::DFG::LowerDFGToB3::compileInvalidationPoint):
2021-04-14 Mark Lam <mark.lam@apple.com>
Add missing exception check in operationGetPrivateNameOptimize().
https://bugs.webkit.org/show_bug.cgi?id=224592
rdar://76645873
Reviewed by Yusuke Suzuki.
Though the fieldNameValue.toPropertyKey() call in operationGetPrivateNameOptimize()
would not normally throw an exception, it still can throw a TerminationException
because it contains RETURN_IF_EXCEPTION checks.
* jit/JITOperations.cpp:
2021-04-14 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Do not copy SimpleJumpTable
https://bugs.webkit.org/show_bug.cgi?id=224472
Reviewed by Mark Lam.
This patch avoids copying UnlinkedSimpleJumpTable to SimpleJumpTable by decoupling CTI addresses from jump offset in SimpleJumpTable.
SimpleJumpTable and UnlinkedSimpleJumpTable are almost identical. SimpleJumpTable adds JIT jump target for each branch.
We should use data from UnlinkedSimpleJumpTable and jump via SimpleJumpTable. Do not need to have copy of branches from UnlinkedSimpleJumpTable.
This way removes Vector<SimpleJumpTable> from CodeBlock::RareData. And this is moved to CodeBlock::JITData. And it only includes jump target addresses,
and branch offset information is kept in UnlinkedSimpleJumpTable side. We no longer need to carefully copy these vectors in CodeBlock including DFG / FTL ones.
In LLInt, we instead use UnlinkedSimpleJumpTable for jumping.
In Baseline, we first allocate enough FixedVector<SimpleJumpTable> and fill content via SimpleJumpTable::ensureCTITable() call when compiling corresponding
switch opcode. Finally we fill these data structures with actual code locations in JIT::link function.
In DFG, we first collect UnlinkedSimpleJumpTable without copying. This is OK since it is kept by UnlinkedCodeBlock, and UnlinkedCodeBlock is kept by baseline CodeBlocks that
are handled by this DFG compilation. We hold Vector<const UnlinkedSimpleJumpTable*> in DFG::Graph and we materialize Vector<SimpleJumpTable> in DFG::Graph.
During DFG compilation, we touch this DFG::Graph's jump tables, and JIT compiler generates code via these tables. And when linking, we move the content to CodeBlock.
In FTL, while we use UnlinkedSimpleJumpTable in FTL code generation, FTL do not use SimpleJumpTable and instead FTL uses Switch in B3.
* bytecode/BytecodeDumper.cpp:
(JSC::CodeBlockBytecodeDumper<Block>::dumpSwitchJumpTables):
* bytecode/BytecodeDumper.h:
* bytecode/BytecodeGeneratorification.cpp:
(JSC::BytecodeGeneratorification::run):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::shrinkToFit):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::switchJumpTable):
(JSC::CodeBlock::numberOfUnlinkedSwitchJumpTables const):
(JSC::CodeBlock::unlinkedSwitchJumpTable):
(JSC::CodeBlock::numberOfSwitchJumpTables const): Deleted.
(JSC::CodeBlock::clearSwitchJumpTables): Deleted.
(JSC::CodeBlock::addSwitchJumpTableFromProfiledCodeBlock): Deleted.
* bytecode/JumpTable.cpp:
(JSC::SimpleJumpTable::offsetForValue): Deleted.
* bytecode/JumpTable.h:
(JSC::SimpleJumpTable::ensureCTITable):
(JSC::SimpleJumpTable::ctiForValue const):
(JSC::SimpleJumpTable::isEmpty const):
(): Deleted.
(JSC::SimpleJumpTable::cloneNonJITPart const): Deleted.
(JSC::SimpleJumpTable::ctiForValue): Deleted.
(JSC::SimpleJumpTable::clear): Deleted.
* bytecode/PreciseJumpTargetsInlines.h:
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedSimpleJumpTable::offsetForValue const):
(JSC::UnlinkedSimpleJumpTable::add):
(JSC::UnlinkedCodeBlock::numberOfUnlinkedSwitchJumpTables const):
(JSC::UnlinkedCodeBlock::unlinkedSwitchJumpTable const):
(JSC::UnlinkedCodeBlock::unlinkedStringSwitchJumpTable const):
(JSC::UnlinkedCodeBlock::numberOfSwitchJumpTables const): Deleted.
(JSC::UnlinkedCodeBlock::switchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::unlinkedStringSwitchJumpTable): Deleted.
* bytecode/UnlinkedCodeBlockGenerator.cpp:
(JSC::UnlinkedCodeBlockGenerator::finalize):
* bytecode/UnlinkedCodeBlockGenerator.h:
(JSC::UnlinkedCodeBlockGenerator::numberOfUnlinkedSwitchJumpTables const):
(JSC::UnlinkedCodeBlockGenerator::addUnlinkedSwitchJumpTable):
(JSC::UnlinkedCodeBlockGenerator::unlinkedSwitchJumpTable):
(JSC::UnlinkedCodeBlockGenerator::numberOfSwitchJumpTables const): Deleted.
(JSC::UnlinkedCodeBlockGenerator::addSwitchJumpTable): Deleted.
(JSC::UnlinkedCodeBlockGenerator::switchJumpTable): Deleted.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::beginSwitch):
(JSC::prepareJumpTableForSwitch):
(JSC::BytecodeGenerator::endSwitch):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGGraph.h:
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
* dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
(JSC::DFG::SpeculativeJIT::emitSwitchImm):
(JSC::DFG::SpeculativeJIT::emitSwitchChar):
(JSC::DFG::SpeculativeJIT::emitSwitchString):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* jit/JIT.cpp:
(JSC::JIT::compileWithoutLinking):
(JSC::JIT::link):
* jit/JIT.h:
(JSC::SwitchRecord::SwitchRecord):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emit_op_switch_char):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emit_op_switch_char):
* jit/JITOperations.cpp:
(JSC::JSC_DEFINE_JIT_OPERATION):
* jit/JITOperations.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CachedTypes.cpp:
(JSC::CachedSimpleJumpTable::encode):
(JSC::CachedSimpleJumpTable::decode const):
(JSC::CachedCodeBlockRareData::encode):
(JSC::CachedCodeBlockRareData::decode const):
2021-04-14 Alex Christensen <achristensen@webkit.org>
Keep UniqueRef<MathICGenerationState> instead of MathICGenerationState in HashTables
https://bugs.webkit.org/show_bug.cgi?id=224569
Reviewed by Geoffrey Garen.
sizeof(KeyValuePair<const Instruction*, MathICGenerationState>) is 136 on some platforms.
That's on the big side for sparse HashTable entries. I think using UniqueRef will help performance.
* jit/JIT.h:
* jit/JITArithmetic.cpp:
(JSC::JIT::emitMathICFast):
(JSC::JIT::emitMathICSlow):
* jit/JITMathIC.h:
2021-04-14 Mark Lam <mark.lam@apple.com>
Apply DeferTermination in some utility functions in the jsc shell.
https://bugs.webkit.org/show_bug.cgi?id=224572
rdar://76646089
Reviewed by Yusuke Suzuki.
This is to make sure that these functions don't get in the way of testing with
the watchdog. Since these are only test utility functions, just doing the simple
thing of using a DeferTermination scope is the right thing to do here.
* jsc.cpp:
2021-04-14 Mark Lam <mark.lam@apple.com>
Defer TerminationExceptions when evaluating ASSERT in HashMapIml::addNormalized().
https://bugs.webkit.org/show_bug.cgi?id=224565
rdar://76645980
Reviewed by Yusuke Suzuki.
HashMapImpl::addNormalized() has an ASSERT that calls jsMapHash(), which can
potentially throw exceptions. As a result, it has a RETURN_IF_EXCEPTION which
provides an opportunity to handle traps and throw a TerminationException. This
in turn causes the ASSERT to fail.
To fix this, we do:
1. Introduce VMTraps::DeferAction, which gives us DeferForAWhile and DeferUntilEndOfScope.
2. Templatize the DeferTermination RAII object on VMTraps::DeferAction.
Introduce DeferTerrminationForAWhile, which is DeferTermination<VMTraps::DeferAction::DeferForAWhile>.
DeferForAWhile means that the deferScope will not throw the TerminationException
on exit. Instead, it will re-set the NeedTermination bit in the traps, and let
the next trap check handle it.
3. Introduce DEFER_TERMINATION_AND_ASSERT_WITH_MESSAGE (and friends) which creates
a DeferTerrminationForAWhile scope before doing an ASSERT_WITH_MESSAGE.
4. Use DEFER_TERMINATION_AND_ASSERT_WITH_MESSAGE instead in HashMapImpl::addNormalized().
* runtime/DeferTermination.h:
(JSC::DeferTermination::DeferTermination):
(JSC::DeferTermination::~DeferTermination):
* runtime/ExceptionHelpers.h:
* runtime/HashMapImpl.h:
(JSC::HashMapImpl::addNormalized):
* runtime/VMTraps.cpp:
(JSC::VMTraps::deferTermination):
(JSC::VMTraps::undoDeferTermination):
* runtime/VMTraps.h:
2021-04-13 Mark Lam <mark.lam@apple.com>
The watchdog should not fire when it's not active.
https://bugs.webkit.org/show_bug.cgi?id=224494
rdar://76581259
Reviewed by Saam Barati and Yusuke Suzuki.
The watchdog is only active when we have entered the VM. If we haven't entered
the VM, we postpone starting the watchdog. For example, see Watchdog::enteredVM()
and Watchdog::exitedVM().
The underlying timer may still fire the NeedWatchdogCheck event after
Watchdog::stopTimer() is called. So, we need to just ignore the event if the
watchdog isn't active.
* runtime/VMTraps.cpp:
(JSC::VMTraps::handleTraps):
* runtime/Watchdog.h:
(JSC::Watchdog::isActive const):
2021-04-13 Ross Kirsling <ross.kirsling@sony.com>
Move cloneUBreakIterator declaration to IntlWorkaround.h
https://bugs.webkit.org/show_bug.cgi?id=224511
Reviewed by Yusuke Suzuki.
Follow up to r275856. There's ultimately no reason IntlWorkaround.cpp needs to be headerless;
this was tied to some confusion about how to successfully include ubrk.h in two different ways.
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/IntlSegmenter.cpp:
* runtime/IntlSegmenter.h:
* runtime/IntlSegments.cpp:
* runtime/IntlWorkaround.cpp:
* runtime/IntlWorkaround.h: Added.
2021-04-13 Mark Lam <mark.lam@apple.com>
Use a JSString for the TerminationException value instead of a Symbol.
https://bugs.webkit.org/show_bug.cgi?id=224490
Reviewed by Yusuke Suzuki.
This makes it convertible to a String for clients that wish to report the exception.
Clients, in this case, does not apply to JS code, only C++ code that catches the
exception at the outermost point to handle the termination. The TerminationException
value is not visible to JS code because the TerminationException cannot be caught.
So, this change is transparent to JS code.
* runtime/VM.cpp:
(JSC::VM::ensureTerminationException):
2021-04-13 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r275867.
https://bugs.webkit.org/show_bug.cgi?id=224495
Need alternate fix.
Reverted changeset:
"Reduce functionWithHellaArguments3()'s number of arguments
from 5000 to 500."
https://bugs.webkit.org/show_bug.cgi?id=224474
https://trac.webkit.org/changeset/275867
2021-04-13 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, casting to unsigned long long to suppress warning
https://bugs.webkit.org/show_bug.cgi?id=224473
* b3/B3ConstDoubleValue.cpp:
(JSC::B3::ConstDoubleValue::dumpMeta const):
2021-04-13 Mark Lam <mark.lam@apple.com>
Reduce functionWithHellaArguments3()'s number of arguments from 5000 to 500.
https://bugs.webkit.org/show_bug.cgi?id=224474
rdar://73614896
Reviewed by Yusuke Suzuki.
Using 5000 arguments seems excessive, and may blow out the stack on more resource
constrained devices. 500 should be high enough.
* b3/testb3_5.cpp:
(JSC_DEFINE_JIT_OPERATION):
(testCallFunctionWithHellaArguments3):
2021-04-12 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Remove CodeBlock::m_constantsSourceCodeRepresentation
https://bugs.webkit.org/show_bug.cgi?id=224473
Reviewed by Mark Lam.
CodeBlock::m_constantsSourceCodeRepresentation is identical to UnlinkedCodeBlock::m_constantsSourceCodeRepresentation.
1. For all constants existing at bytecode compile time, elements of the above vectors are identical.
2. For lazily added constants from DFG, it is always SourceCodeRepresentation::Other.
And the array is effectively accessed only when compiling DFG code. So we should remove copy of that in CodeBlock, and
get SourceCodeRepresentation from UnlinkedCodeBlock.
* bytecode/BytecodeDumper.cpp:
(JSC::CodeBlockBytecodeDumper<Block>::dumpConstants):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::setConstantRegisters):
(JSC::CodeBlock::shrinkToFit):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::constants):
(JSC::CodeBlock::addConstant):
(JSC::CodeBlock::addConstantLazily):
(JSC::CodeBlock::constantSourceCodeRepresentation const):
(JSC::CodeBlock::constantsSourceCodeRepresentation): Deleted.
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::constantSourceCodeRepresentation const):
* bytecode/UnlinkedCodeBlockGenerator.h:
(JSC::UnlinkedCodeBlockGenerator::constantSourceCodeRepresentation const):
(JSC::UnlinkedCodeBlockGenerator::constantsSourceCodeRepresentation): Deleted.
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::registerFrozenValues):
2021-04-12 Mark Lam <mark.lam@apple.com>
Interpreter::executeProgram() should install its VMEntryScope at the top.
https://bugs.webkit.org/show_bug.cgi?id=224450
rdar://76530841
Reviewed by Yusuke Suzuki.
"top" includes before any VM code that can throw exceptions is run.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::executeProgram):
2021-04-12 Ross Kirsling <ross.kirsling@sony.com>
ICU 69 deprecates ubrk_safeClone in favor of ubrk_clone
https://bugs.webkit.org/show_bug.cgi?id=224093
Reviewed by Yusuke Suzuki.
In a shining example of "disappointing library practices", ICU 69 deprecates ubrk_safeClone in favor of
a new *draft* API ubrk_clone, meaning that no function with this functionality is exposed by default.
This patch introduces a function cloneUBreakIterator to abstract over this change; however, since we need to:
1. confine the effects of disabling U_HIDE_DRAFT_API to a non-unified implementation file
2. still be able to include ubrk.h from IntlSegmenter.h to instantiate ICUDeleter<ubrk_close> (*not* `clone`!)
...the new helper function is introduced in a *headerless* implementation file, IntlWorkaround.cpp.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* runtime/IntlSegmenter.cpp:
(JSC::IntlSegmenter::segment const):
* runtime/IntlSegmenter.h:
* runtime/IntlSegments.cpp:
(JSC::IntlSegments::createSegmentIterator):
* runtime/IntlWorkaround.cpp: Added.
(JSC::cloneUBreakIterator):
2021-04-12 Don Olmstead <don.olmstead@sony.com>
Inspector code is wrongly including some private headers
https://bugs.webkit.org/show_bug.cgi?id=224456
Reviewed by Alex Christensen.
These files were including some headers using #include <JavaScriptCore/Foo.h> style instead
of "Foo.h" style. This caused a build error when attempting to revive the Mac CMake build
since those headers were private and private headers are generated after the JavaScriptCore
build. No other ports were have ENABLE_INSPECTOR_ALTERNATE_DISPATCHERS turned on so the
issue hadn't manifested until now.
* API/JSContextRefInspectorSupport.h:
* inspector/augmentable/AlternateDispatchableAgent.h:
* inspector/augmentable/AugmentableInspectorController.h:
2021-04-12 BJ Burg <bburg@apple.com>
Modernize uses of ConsoleClient
https://bugs.webkit.org/show_bug.cgi?id=224398
Reviewed by David Kilzer.
ConsoleClient acts like a delegate, so its callers
should be using weak references to it.
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::consoleClient const):
* inspector/JSGlobalObjectInspectorController.h:
* runtime/ConsoleClient.h:
* runtime/ConsoleObject.cpp:
(JSC::consoleLogWithLevel):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::setConsoleClient):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::consoleClient const):
(JSC::JSGlobalObject::setConsoleClient): Deleted.
2021-04-11 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Do not copy StringSwitchJumpTable
https://bugs.webkit.org/show_bug.cgi?id=224414
Reviewed by Keith Miller.
Previously, we were copying UnlinkedStringJumpTable to CodeBlock's StringJumpTable because we embed CodeLocation pointer
inside CodeBlock's StringJumpTable. This is copying a mostly identical hashtable to each CodeBlock even in DFG and FTL. This
even prevents us from inlining op_switch_string in DFG and FTL because (1) we don't want to copy this string tables collected from
each inlined CodeBlock into a new DFG / FTL CodeBlock and (2) we cannot ref/deref StringImpl inside DFG / FTL compilers so copying
these tables in the compiler threads need additional "DesiredStringSwitchJumpTable" etc.
In this patch, we stop copying StringSwitchJumpTable. We decouple CodeLocation pointers from the hashtable so that we can use
UnlinkedStringJumpTable in UnlinkedCodeBlock. UnlinkedStringJumpTable's hashtable inclues m_indexInTable in each entry so that
we can have array of CodeLocation pointers in CodeBlock's JITData to have JIT jump targets separately. This design prevents us
from copying unnecessary hashtables, and even this paves the way to inlining switch_string in DFG and FTL.
* bytecode/BytecodeDumper.cpp:
(JSC::CodeBlockBytecodeDumper<Block>::dumpStringSwitchJumpTables):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::shrinkToFit):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::stringSwitchJumpTable):
(JSC::CodeBlock::numberOfUnlinkedStringSwitchJumpTables const):
(JSC::CodeBlock::unlinkedStringSwitchJumpTable):
(JSC::CodeBlock::numberOfStringSwitchJumpTables const): Deleted.
* bytecode/JumpTable.h:
(JSC::StringJumpTable::ctiForValue const):
(JSC::StringJumpTable::offsetForValue): Deleted.
(JSC::StringJumpTable::ctiForValue): Deleted.
(JSC::StringJumpTable::clear): Deleted.
* bytecode/PreciseJumpTargetsInlines.h:
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedStringJumpTable::offsetForValue const):
(JSC::UnlinkedCodeBlock::numberOfUnlinkedStringSwitchJumpTables const):
(JSC::UnlinkedCodeBlock::unlinkedStringSwitchJumpTable):
(JSC::UnlinkedStringJumpTable::offsetForValue): Deleted.
(JSC::UnlinkedCodeBlock::numberOfStringSwitchJumpTables const): Deleted.
(JSC::UnlinkedCodeBlock::stringSwitchJumpTable): Deleted.
* bytecode/UnlinkedCodeBlockGenerator.cpp:
(JSC::UnlinkedCodeBlockGenerator::finalize):
* bytecode/UnlinkedCodeBlockGenerator.h:
(JSC::UnlinkedCodeBlockGenerator::numberOfUnlinkedStringSwitchJumpTables const):
(JSC::UnlinkedCodeBlockGenerator::addUnlinkedStringSwitchJumpTable):
(JSC::UnlinkedCodeBlockGenerator::unlinkedStringSwitchJumpTable):
(JSC::UnlinkedCodeBlockGenerator::numberOfStringSwitchJumpTables const): Deleted.
(JSC::UnlinkedCodeBlockGenerator::addStringSwitchJumpTable): Deleted.
(JSC::UnlinkedCodeBlockGenerator::stringSwitchJumpTable): Deleted.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::beginSwitch):
(JSC::prepareJumpTableForStringSwitch):
(JSC::BytecodeGenerator::endSwitch):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
* dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::switchStringSlow):
* ftl/FTLOperations.cpp:
(JSC::FTL::JSC_DEFINE_JIT_OPERATION):
* jit/JIT.cpp:
(JSC::JIT::link):
* jit/JIT.h:
(JSC::SwitchRecord::SwitchRecord):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_switch_string):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_switch_string):
* jit/JITOperations.cpp:
(JSC::JSC_DEFINE_JIT_OPERATION):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/CachedTypes.cpp:
(JSC::CachedStringJumpTable::encode):
(JSC::CachedStringJumpTable::decode const):
(JSC::CachedCodeBlockRareData::encode):
(JSC::CachedCodeBlockRareData::decode const):
2021-04-10 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] B3 reduce-double-to-float should reduce only when constant double is canonical one to reduced float value
https://bugs.webkit.org/show_bug.cgi?id=224403
<rdar://problem/76259599>
Reviewed by Mark Lam.
When reducing double-constant value to float in B3, we should check whether the double value is a canonical one
which can be converted back from the reduced float value. For example, double 1.1 is not the one since it is truncated
into float 1.1 by removing some bits.
static_cast<double>(static_cast<float>(1.1)) != 1.1
Reducing such a double to float changes the semantics.
* b3/B3ConstDoubleValue.cpp:
(JSC::B3::ConstDoubleValue::dumpMeta const):
* b3/B3ConstFloatValue.cpp:
(JSC::B3::ConstFloatValue::dumpMeta const):
* b3/B3ReduceDoubleToFloat.cpp:
* b3/B3ReduceStrength.cpp:
* b3/testb3.h:
(populateWithInterestingValues):
* b3/testb3_1.cpp:
(run):
* b3/testb3_3.cpp:
(testConvertDoubleToFloatToDouble):
(testConvertDoubleToFloatEqual):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::JSC_DEFINE_JIT_OPERATION_WITH_ATTRIBUTES):
(JSC::FTL::DFG::LowerDFGToB3::crash):
(JSC::FTL::DFG::ftlUnreachable): Deleted.
2021-04-10 Mark Lam <mark.lam@apple.com>
Enable VMTraps checks in RETURN_IF_EXCEPTION.
https://bugs.webkit.org/show_bug.cgi?id=224078
rdar://75037057
Reviewed by Keith Miller.
In pre-existing code, termination of a VM's execution can already be requested
asynchronously (with respect to the mutator thread). For example, sources of such
a request can be a watchdog timer firing, or a request to stop execution issued
from a main web thread to a worker thread.
This request is made by firing the VMTraps::NeedTermination event on VMTraps.
Firing the event here only means setting a flag to indicate the presence of the
request. We still have to wait till the mutator thread reaches one of the
pre-designated polling check points to call VMTraps::handleTraps() in order to
service the request. As a result of this need to wait for a polling check point,
if the mutator is executing in a long running C++ loop, then a termination request
may not be serviced for a long time.
However, we observed that a lot of our C++ loops already have RETURN_IF_EXCEPTION
checks. Hence, if we can check VMTraps::needHandling() there, we can service the
VMTraps events more frequently even in a lot of C++ loops, and get a better response.
Full details of what this patch changes:
1. Shorten some type and methods names in the VMTraps class to make code easier to
read e.g. EventType => Event, needTrapHandling => needHandling.
2. Remove the VMTraps::Mask class. Mask was introduced so that we can express a
concatenation of multiple VMTraps events to form a bit mask in a simple way.
In the end, it isn't flexible enough but makes the code more complicated than
necessary. It is now replaced by the simpler solution of using macros to define
the Events as bit fields. Having Events as bit fields intrinsically make them
easy to concatenate (bitwise or) or filter (bitwise and).
Also removed the unused VMTraps::Error class.
3. Make VMTraps::BitField a uint32_t. There was always unused padding in VMTraps
to allow for this. So, we'll just extend it to a full 32-bit to make it easier
to add more events in the future for other uses.
4. Add NeedExceptionHandling as a VMTrap::Event.
5. Make VMTraps::m_trapBits Atomic. This makes it easier to set and clear the
NeedExceptionHandling bit from the mutator without a lock.
6. RETURN_IF_EXCEPTION now checks VMTraps::m_trapBits (via VMTraps::needHandling())
instead of checking VM::m_exception. If the VMTraps::m_trapBits is non-null,
the macro will call VM:hasExceptionsAfterHandlingTraps() to service VMTraps
events as appropriate before returning whether an exception is being thrown.
The result of VM:hasExceptionsAfterHandlingTraps() will determine if
RETURN_IF_EXCEPTION returns or not.
VM:hasExceptionsAfterHandlingTraps() is intentionally designed to take a minimum
of arguments (just the VM as this pointer). This is because RETURN_IF_EXCEPTION
is called from many places, and we would like to minimize code size bloating
from this change.
7. Simplify paramaters of VMTraps::handleTraps().
NeedDebuggerBreak's callFrame argument was always vm.topCallFrame anyway.
So, the patch makes it explicit, and removes the callFrame parameter.
NeedWatchdogCheck's globalObject argument should have always been
vm.entryScope->globalObject(), and we can remove the globalObject parameter.
Before this, we pass in whichever globalObject was convenient to grab hold of.
However, the idea of the watchdog is to time out the current script executing
on the stack. Hence, it makes sense to identify thay script by the globalObject
in use at VM entry.
So far, the only clients that uses the watchdog mechanism only operates in
scenarios with only one globalObject anyway. So this formalization to use
VMEntryScope's globalObject does not change the expected behavior.
8. Make the execution of termination more robust. Before reading this, please
read the description of the Events in VMTraps.h first, especially the section
on NeedTermination.
Here's the life cycle of a termination:
a. a client requests termination of the current execution stack by calling
VM::notifyNeedTermination(). notifyNeedTermination() does 2 things:
i. fire the NeedTermination event on VMTraps.
ii. set the VM::m_terminationInProgress flag.
b. Firing the NeedTermination event on VMTraps means setting the NeedTermination
bit on VMTraps::m_trapBits. This bit will be polled by the mutator thread
later at various designated points (including RETURN_IF_EXCEPTION, which we
added in this patch).
Once the mutator sees the NeedTermination bit is set, it will clear the bit
and throw the TerminationException (see VMTraps::handleTraps()). This is
unless the mutator thread is currently in a DeferTermination scope (see (8)
below). If in a DeferTermination scope, then it will not throw the
TerminationException.
Since the NeedTermination bit is cleared, the VM will no longer call
VMTraps::handleTraps() to service the event. If the mutator thread is in
a DeferTermination scope, then on exiting the scope (at scope destruction),
the scope will see that VM::m_terminationInProgress is set, and throw the
deferred TerminationException then.
c. The TerminationException will trigger unwinding out of the current stack
until we get to the outermost VMEntryScope.
d. At the the outermost VMEntryScope, we will clear VM::m_terminationInProgress
if the NeedTermination bit in VMtraps::m_trapBits is cleared.
If the NeedTermination bit is set, then that means we haven't thrown the
TerminationException yet. Currently, clients expect that we must throw the
TerminationException if NeedTermination was requested (again, read comments
at the top of VMTraps.h).
If the NeedTermination bit is set, we'll leave VM::m_terminationInProgress
set until the next time we re-enter the VM and exit to the outermost
VMEntryScope.
e. The purpose of VM::m_terminationInProgress is to provide a summary of the
fact that the VM is in a state of trying to terminate the current stack.
Note that this state is first indicated by the NeedTermination bit being set
in VMTraps::m_trapBits. Then, in VMTraps::handleTraps(), the state is
handed of with the NeedTermination bit being cleared, and the
TerminationException being thrown.
While the VM is in this termination state, we need to prevent new DFG/FTL
JIT code from being compiled and run. The reason is the firing of the
NeedTermination event has invalidated DFG/FTL code on the stack, thereby
allowing their baseline / LLInt versions which have VMTraps polling checks
to run. We don't want to compile new DFG / FTL code and possibly get stuck
in loops in there before the termination is complete.
In operationOptimize(), we check if VM::m_terminationInProgress is set, and
prevent new DFG (and therefore FTL) code from being compiled if needed.
Note: it is easier to check a single flag, VM::m_terminationInProgress,
then to check both if the NeedTermination bit is set or if the
TerminationException is being being thrown.
9. One complication of being able to service VMTraps in RETURN_IF_EXCEPTION checks
is that some of our code (usually for lengthier initializations and bootstrapping)
currently does not handle exceptions well, e.g. JSGlobalObject::init(). They
rely on the code crashing if an exception is thrown while still initializing.
However, for a worker thread, a TerminationException (requested by the main
thread) may arrive before the initialization is complete. This can lead to
crashes because part of the initialization may be aborted in the presence of
an exception, while other parts still expect everything prior to have been
initialized correctly. For resource exhaustion cases (which is abnormal), it
is OK to crash. For the TerminationException (which can be part of normal
operation), we should not be crashing.
To work around this, we introduce a DeferTermination RAII scope object that we
deploy in this type of initialization code. With the scope in effect,
a. if a TerminationException arrives but hasn't been thrown yet, it will be
deferred till the scope ends before being thrown.
b. if a TerminationException has already been thrown, the scope will stash
the exception, clear it from the VM so that the initialization code can
run to completion, and then re-throw the exception when the scope ends.
Currently, we only need to use the DeferTermination scope in a few places
where we know that initialization code will only run for a short period of time.
DeferTermination should not be used for code that can block waiting on an
external event for a long time. Obviously, doing so will prevent the VM
termination mechanism from working.
10. Replaced llint_slow_path_check_if_exception_is_uncatchable_and_notify_profiler
and operationCheckIfExceptionIsUncatchableAndNotifyProfiler with
llint_slow_path_retrieve_and_clear_exception_if_catchable and
operationRetrieveAndClearExceptionIfCatchable.
The 2 runtime functions doesn't actually do anything to notify a profiler.
So, we drop that part of the name.
After returning from these runtime functions respectively, the previous LLInt
and JIT code, which calls these runtimes functions, would go on to load
VM::m_exception, and then store a nullptr there to clear it. This is wasteful.
This patch changes the runtime function to clear and return the Exception
instead. As a result, the calling LLInt and JIT code is simplified a bit.
Note also that clearing an exception now also entails clearing the
NeedExceptionHandling bit in VMTraps::m_trapBits in an atomic way. The above
change makes it easy to do this clearing with C++ code.
11. Fix ScriptFunctionCall::call() to handle exceptions correctly. Previously,
it had one case where it propagates an exception, while another eats it.
Change this function to eat the exception in both cases. This is approproiate
because ScriptFunctionCall is only used to execute some Inspector instrumentation
calls. It doesn't make sense to propagate the exception back to user code.
12. Fix the lazy initialization of JSGlobalObject::m_defaultCollator to be able to
handle the TerminationException.
13. Not related to TerminationException, but this patch also fixes
MarkedArgumentBuffer::expandCapacity() to use Gigacage::tryMalloc() instead of
Gigacage::malloc(). This is needed as one of the fixes to make the
accompanying test case work.
This patch increases code size by 320K (144K for JSC, 176K for WebCore) measured
on x86_64.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::branchTest32):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::branchTest32):
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::branchTest32):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::branchTest32):
* bindings/ScriptFunctionCall.cpp:
(Deprecated::ScriptFunctionCall::call):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCheckTraps):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCheckTraps):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::executeProgram):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
(JSC::Interpreter::execute):
(JSC::Interpreter::executeModuleProgram):
* interpreter/InterpreterInlines.h:
(JSC::Interpreter::execute):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_check_traps):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_catch):
* jit/JITOperations.cpp:
(JSC::JSC_DEFINE_JIT_OPERATION):
* jit/JITOperations.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/ArgList.cpp:
(JSC::MarkedArgumentBuffer::expandCapacity):
* runtime/DeferTermination.h: Added.
(JSC::DeferTermination::DeferTermination):
(JSC::DeferTermination::~DeferTermination):
* runtime/ExceptionScope.h:
(JSC::ExceptionScope::exception const):
(JSC::ExceptionScope::exception): Deleted.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::finishCreation):
* runtime/LazyPropertyInlines.h:
(JSC::ElementType>::callFunc):
* runtime/StringPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/VM.cpp:
(JSC::VM::hasExceptionsAfterHandlingTraps):
(JSC::VM::clearException):
(JSC::VM::setException):
(JSC::VM::throwTerminationException):
(JSC::VM::throwException):
* runtime/VM.h:
(JSC::VM::terminationInProgress const):
(JSC::VM::setTerminationInProgress):
(JSC::VM::notifyNeedTermination):
(JSC::VM::DeferExceptionScope::DeferExceptionScope):
(JSC::VM::DeferExceptionScope::~DeferExceptionScope):
(JSC::VM::handleTraps): Deleted.
(JSC::VM::needTrapHandling): Deleted.
(JSC::VM::needTrapHandlingAddress): Deleted.
(JSC::VM::setException): Deleted.
(JSC::VM::clearException): Deleted.
* runtime/VMEntryScope.cpp:
(JSC::VMEntryScope::~VMEntryScope):
* runtime/VMTraps.cpp:
(JSC::VMTraps::tryInstallTrapBreakpoints):
(JSC::VMTraps::fireTrap):
(JSC::VMTraps::handleTraps):
(JSC::VMTraps::takeTopPriorityTrap):
(JSC::VMTraps::deferTermination):
(JSC::VMTraps::undoDeferTermination):
* runtime/VMTraps.h:
(JSC::VMTraps::onlyContainsAsyncEvents):
(JSC::VMTraps::needHandling const):
(JSC::VMTraps::trapBitsAddress):
(JSC::VMTraps::isDeferringTermination const):
(JSC::VMTraps::notifyGrabAllLocks):
(JSC::VMTraps::hasTrapBit):
(JSC::VMTraps::clearTrapBit):
(JSC::VMTraps::setTrapBit):
(JSC::VMTraps::Mask::Mask): Deleted.
(JSC::VMTraps::Mask::allEventTypes): Deleted.
(JSC::VMTraps::Mask::bits const): Deleted.
(JSC::VMTraps::Mask::init): Deleted.
(JSC::VMTraps::interruptingTraps): Deleted.
(JSC::VMTraps::needTrapHandling): Deleted.
(JSC::VMTraps::needTrapHandlingAddress): Deleted.
(JSC::VMTraps::hasTrapForEvent): Deleted.
(JSC::VMTraps::setTrapForEvent): Deleted.
(JSC::VMTraps::clearTrapForEvent): Deleted.
2021-04-09 Alexey Shvayka <shvaikalesh@gmail.com>
Remove className() and toStringName() from the method table
https://bugs.webkit.org/show_bug.cgi?id=224247
Reviewed by Darin Adler.
ES6 introduced Symbol.toStringTag to customize Object.prototype.toString return value.
It was adopted by WebIDL spec, Chrome's DevTools, Node.js etc. There is no reason to
keep 2 method table methods, each with only 1 call site, instead of using the symbol.
Also, it's a bit confusing that for some objects, method table's className() returns
different result than JSCell::className(VM&).
This change:
1. Removes JSProxy's className() / toStringName() methods because its target() is a
global object that never has these overrides and uses Symbol.toStringTag instead.
2. Removes DebuggerScope's className() / toStringName() overrides because its objectAtScope()
has these methods extremely rarely (e.g. `with (new Date) {}`), and its not displayed
by Web Inspector.
3. Merges JSCallbackObject's className() / toStringName() methods into Symbol.toStringTag
branch of getOwnPropertySlot(), with permissive property attributes. To avoid any possible
breakage, we make sure that it will be shadowed by a structure property.
4. Reworks JSObject::calculatedClassName() to rely on Symbol.toStringTag, matching Chrome's
DevTools behavior. On its own, it's a nice change for Web Inspector. We make sure to
lookup Symbol.toStringTag if `constructor.name` inference fails to avoid confusion when
extending builtins.
5. Removes now unused className() from the method table.
6. Removes toStringName() override from JSFinalizationRegistry because its builtin tag [1]
is already "Object".
7. Introduces BooleanObjectType for Boolean wrapper object, and Boolean.prototype as it's
also required to have a [[BooleanData]] internal slot [2].
8. Reworks Object.prototype.toString to determine builtin tag [1] based on JSType rather than
performing method table call. It's guaranteed that a) the set of types we are checking
against won't be expanded, and b) objects with these types have correct `className`.
9. Removes now unused toStringTag() from the method table.
This patch is performance-neutral and carefully preserves current behavior for API objects,
including isPokerBros() hack.
[1]: https://tc39.es/ecma262/#sec-object.prototype.tostring (steps 5-14)
[2]: https://tc39.es/ecma262/#sec-properties-of-the-boolean-prototype-object
* API/JSCallbackObject.h:
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::getOwnPropertySlot):
(JSC::JSCallbackObject<Parent>::className): Deleted.
(JSC::JSCallbackObject<Parent>::toStringName): Deleted.
* API/tests/testapiScripts/testapi.js:
* debugger/DebuggerScope.cpp:
(JSC::DebuggerScope::className): Deleted.
(JSC::DebuggerScope::toStringName): Deleted.
* debugger/DebuggerScope.h:
* runtime/BooleanObject.cpp:
(JSC::BooleanObject::toStringName): Deleted.
* runtime/BooleanObject.h:
(JSC::BooleanObject::createStructure):
* runtime/BooleanPrototype.h:
* runtime/ClassInfo.h:
* runtime/DateInstance.cpp:
(JSC::DateInstance::toStringName): Deleted.
* runtime/DateInstance.h:
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::toStringName): Deleted.
* runtime/ErrorInstance.h:
* runtime/JSCell.cpp:
(JSC::JSCell::className): Deleted.
(JSC::JSCell::toStringName): Deleted.
* runtime/JSCell.h:
* runtime/JSFinalizationRegistry.cpp:
(JSC::JSFinalizationRegistry::toStringName): Deleted.
* runtime/JSFinalizationRegistry.h:
* runtime/JSObject.cpp:
(JSC::JSObject::calculatedClassName):
(JSC::JSObject::className): Deleted.
(JSC::isPokerBros): Deleted.
(JSC::JSObject::toStringName): Deleted.
* runtime/JSObject.h:
* runtime/JSProxy.cpp:
(JSC::JSProxy::className): Deleted.
(JSC::JSProxy::toStringName): Deleted.
* runtime/JSProxy.h:
* runtime/JSType.cpp:
(WTF::printInternal):
* runtime/JSType.h:
* runtime/NumberObject.cpp:
(JSC::NumberObject::toStringName): Deleted.
* runtime/NumberObject.h:
(JSC::NumberObject::createStructure):
* runtime/ObjectPrototype.cpp:
(JSC::isPokerBros):
(JSC::inferBuiltinTag):
(JSC::objectPrototypeToString):
1. Removes jsNontrivialString() because it's assertion may fail in case of iOS hack.
2. Utilizes AtomStringImpl to avoid allocating StringImpl for a small fixed set of strings.
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::toStringName): Deleted.
* runtime/RegExpObject.h:
* runtime/StringObject.cpp:
(JSC::StringObject::toStringName): Deleted.
* runtime/StringObject.h:
2021-04-08 Khem Raj <raj.khem@gmail.com>
[WPE] Build fixes for musl C library on Linux
https://bugs.webkit.org/show_bug.cgi?id=210068
Reviewed by Carlos Alberto Lopez Perez.
Use OS(LINUX) to include musl in platform test
for linux and consolidate all linux platfrom
under same test. Use smaller limits for JSC
stack size per thread and reserved zone size.
* runtime/MachineContext.h:
(JSC::MachineContext::stackPointerImpl):
(JSC::MachineContext::framePointerImpl):
(JSC::MachineContext::instructionPointerImpl):
(JSC::MachineContext::argumentPointer<1>):
(JSC::MachineContext::llintInstructionPointer):
* runtime/OptionsList.h:
2021-04-07 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] DUCET level-1 weighs are equal if characters are alphabets
https://bugs.webkit.org/show_bug.cgi?id=224047
Reviewed by Saam Barati and Mark Lam.
ASCII comparison optimization was based on that DUCET level-1 weights are all different (except for 0000 case), but this was wrong.
If we have the same latin letters with different capitalization, then they have the same level-1 weight ('A' v.s. 'a').
In this patch,
1. If we found that the result of level-1 weight comparison is equal, and characters are not equal, then we do level-3 weight comparison.
We do not perform level-2 since they are all the same weight in ASCII (excluding control characters) region.
2. We do not perform level-4 weight comparison since level-1 and level-3 comparison must distinguish the strings. Level-1 weights are equal
only when characters are the same latin letters. And level-3 weight puts different weights for capital latin letters. Since we already know
that these strings are different while they are equal in level-1 weight comparison, the only case is that they have same latin letters in
the same position. In that case, level-3 weight must say different results for these characters so that we never meet "equal" status in
level-3 weight comparison if characters are different.
* runtime/IntlObject.cpp:
* runtime/IntlObject.h:
* runtime/IntlObjectInlines.h:
(JSC::canUseASCIIUCADUCETComparison):
(JSC::compareASCIIWithUCADUCETLevel3):
(JSC::compareASCIIWithUCADUCET):
2021-04-02 Darin Adler <darin@apple.com>
Use Hasher more, remove IntegerHasher, fix hashing-related mistakes
https://bugs.webkit.org/show_bug.cgi?id=224138
Reviewed by Chris Dumez.
* bytecode/BytecodeIndex.h:
(JSC::BytecodeIndex::hash const): Remove unneeded WTF prefix on call
to intHash.
* ftl/FTLAbstractHeap.h: Use HashTraits instead of WTF::GenericHashTraits.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::validateAIState): Remove unneeded WTF
prefix on call to intHash.
* wasm/WasmLLIntGenerator.cpp: Use HashTraits instead of WTF::GenericHashTraits.
2021-04-07 Mark Lam <mark.lam@apple.com>
Rename and make the TerminationException a singleton.
https://bugs.webkit.org/show_bug.cgi?id=224295
Reviewed by Keith Miller.
We previously call it the TerminatedExecutionException, which is a mouthful but
adds no meaningful information. It's now renamed to TerminationException.
We can make it a singleton because the TerminationException is just a VM internal
mechanism for implementing the termination of the current execution stack. It
should never be exposed to user JS code, and therefore, there is no value in
making it a JS object. Making it a singleton simplifies the code.
A TerminationException is now implemented as an Exception cell which holds a
Symbol with the name "TerminationError". The TerminationException is only created
if needed e.g. if the JSC watchdog is created, or if the VM is for a Worker thread
which needs to be able to handle termination requests.
We'll also stop notifying the debugger when we throw the TerminationException.
This is because the TerminationException is not like ordinary exceptions that
should be reported to the debugger. The fact that the TerminationException uses
the exception handling mechanism is just a VM internal implementation detail.
It is not meaningful to report it to the debugger as an exception.
* API/JSContext.mm:
(-[JSContext evaluateJSScript:]):
* API/tests/ExecutionTimeLimitTest.cpp:
(testExecutionTimeLimit):
* bindings/ScriptFunctionCall.cpp:
(Deprecated::ScriptFunctionCall::call):
* heap/Heap.cpp:
(JSC::Heap::addCoreConstraints):
* inspector/InjectedScriptManager.cpp:
(Inspector::InjectedScriptManager::injectedScriptFor):
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::reportAPIException):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::unwind):
(JSC::Interpreter::notifyDebuggerOfExceptionToBeThrown):
* jit/JITOperations.cpp:
(JSC::JSC_DEFINE_JIT_OPERATION):
* jsc.cpp:
(checkException):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/ExceptionHelpers.cpp:
(JSC::TerminatedExecutionError::defaultValue): Deleted.
(JSC::createTerminatedExecutionException): Deleted.
(JSC::isTerminatedExecutionException): Deleted.
(JSC::throwTerminatedExecutionException): Deleted.
* runtime/ExceptionHelpers.h:
(): Deleted.
* runtime/JSObject.h:
(JSC::JSObject::get const):
* runtime/JSPromise.cpp:
(JSC::JSPromise::rejectWithCaughtException):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::ensureWatchdog):
(JSC::VM::ensureTerminationException):
(JSC::VM::throwTerminationException):
(JSC::VM::throwException):
* runtime/VM.h:
(JSC::VM::terminationException const):
(JSC::VM::isTerminationException const):
* runtime/VMTraps.cpp:
(JSC::VMTraps::handleTraps):
2021-04-07 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use FixedVector more in bytecode dir and JumpTable
https://bugs.webkit.org/show_bug.cgi?id=224275
Reviewed by Michael Saboff and Mark Lam.
1. Use FixedVector more in bytecode/ directory's long-living data structures.
2. Use FixedVector in SimpleJumpTable. This involves LLInt changes because we need to access FixedVector data from LLInt.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* bytecode/InlineCallFrame.cpp:
(JSC::InlineCallFrame::dumpInContext const):
* bytecode/InlineCallFrame.h:
* bytecode/JumpTable.h:
(JSC::SimpleJumpTable::clear):
* bytecode/ObjectPropertyConditionSet.cpp:
(JSC::ObjectPropertyConditionSet::mergedWith const):
(JSC::ObjectPropertyConditionSet::dumpInContext const):
(JSC::ObjectPropertyConditionSet::isValidAndWatchable const):
* bytecode/ObjectPropertyConditionSet.h:
(JSC::ObjectPropertyConditionSet::create):
(JSC::ObjectPropertyConditionSet::isValid const):
(JSC::ObjectPropertyConditionSet::size const):
(JSC::ObjectPropertyConditionSet::begin const):
(JSC::ObjectPropertyConditionSet::end const):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::findArgumentPositionForLocal):
(JSC::DFG::ByteCodeParser::flushImpl):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGCommonData.cpp:
(JSC::DFG::CommonData::validateReferences):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::isLiveInBytecode):
* dfg/DFGGraph.h:
* dfg/DFGPreciseLocalClobberize.h:
(JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
* dfg/DFGStackLayoutPhase.cpp:
(JSC::DFG::StackLayoutPhase::run):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::argumentsStart):
* jit/SetupVarargsFrame.cpp:
(JSC::emitSetupVarargsFrameFastCase):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::createWithInlineFrame):
2021-04-07 Mark Lam <mark.lam@apple.com>
Fix a typo in JITUncoughtExceptionAfterCall.
https://bugs.webkit.org/show_bug.cgi?id=224290
Reviewed by Keith Miller.
* assembler/AbortReason.h:
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::jitReleaseAssertNoException):
2021-04-06 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] WasmMemory caging should care about nullptr
https://bugs.webkit.org/show_bug.cgi?id=224268
<rdar://problem/74654838>
Reviewed by Mark Lam.
1. Fix Wasm::MemoryHandle::boundsCheckingSize. We should just return m_mappedCapacity here since UINT32_MAX is not 4GB.
This checking size can include redzone for fast-memory, but this is OK: bounds-check pass in LLInt (in upper tiers, we
do not use bounds-check for fast-memory), and access to redzone, then fault occurs and signal handler can make it error
since signal handler is checking whether the access is within Memory::fastMappedBytes which includes redzone.
2. Fix caging of wasm memory-base pointer in LLInt. We should use pointer sized length since it can be larger than 4GB.
And we should handle nullptr case correctly: Wasm::MemoryHandle's memory can be nullptr when mapped size is zero.
caging needs to handle this case as we do in CagedPtr::getMayBeNull.
* assembler/MacroAssemblerARM64E.h:
(JSC::MacroAssemblerARM64E::untagArrayPtrLength32):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
* llint/LowLevelInterpreter64.asm:
* llint/WebAssembly.asm:
* offlineasm/arm64e.rb:
* offlineasm/ast.rb:
* offlineasm/instructions.rb:
* runtime/CagedBarrierPtr.h:
(JSC::CagedBarrierPtr::CagedBarrierPtr):
(JSC::CagedBarrierPtr::set):
(JSC::CagedBarrierPtr::get const):
(JSC::CagedBarrierPtr::getMayBeNull const):
(JSC::CagedBarrierPtr::at const):
(JSC::CagedBarrierPtr::setWithoutBarrier):
* wasm/WasmInstance.h:
(JSC::Wasm::Instance::updateCachedMemory):
* wasm/WasmMemory.cpp:
(JSC::Wasm::MemoryHandle::MemoryHandle):
* wasm/WasmMemory.h:
2021-04-06 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use FixedVector more in JSC
https://bugs.webkit.org/show_bug.cgi?id=224255
Reviewed by Mark Lam.
Use FixedVector more aggressively. This reduces sizeof(Holder) since sizeof(FixedVector) is 8
while sizeof(Vector) is 16. And since this allocates just-fit size, this does not waste memory.
* bytecode/BytecodeLivenessAnalysis.cpp:
(JSC::BytecodeLivenessAnalysis::computeFullLiveness):
* bytecode/BytecodeLivenessAnalysis.h:
* bytecode/FullBytecodeLiveness.h:
(JSC::FullBytecodeLiveness::FullBytecodeLiveness):
* bytecode/UnlinkedEvalCodeBlock.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::livenessFor):
* ftl/FTLForOSREntryJITCode.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::lower):
* ftl/FTLOSRExit.cpp:
(JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
* ftl/FTLOSRExit.h:
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileRecovery):
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::sweepPreciseAllocations):
* jit/RegisterAtOffsetList.cpp:
(JSC::RegisterAtOffsetList::RegisterAtOffsetList):
* jit/RegisterAtOffsetList.h:
(JSC::RegisterAtOffsetList::begin const):
(JSC::RegisterAtOffsetList::end const):
(JSC::RegisterAtOffsetList::clear): Deleted.
* runtime/JSGlobalObject.h:
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::finishCreation):
* runtime/JSModuleNamespaceObject.h:
* yarr/YarrPattern.h:
(JSC::Yarr::YarrPattern::resetForReparsing):
2021-04-06 Alexey Shvayka <shvaikalesh@gmail.com>
Symbol and BigInt wrapper objects should perform OrdinaryToPrimitive
https://bugs.webkit.org/show_bug.cgi?id=224208
Reviewed by Yusuke Suzuki.
ES6 introduced Symbol.toPrimitive as the only way to override ToPrimitive;
if it's nullish, OrdinaryToPrimitive [1] is performed unconditionally.
This patch removes two redundant defaultValue() overrides, fixing JSC to call
(possibly userland) toString() / valueOf() methods of a) Symbol objects whose
Symbol.toPrimitive was removed, and b) BigInt wrapper objects.
Aligns JSC with V8 and SpiderMonkey. Coercion of primitives is unaffected.
Also, removes dummy BigIntObject::internalValue() override.
[1]: https://tc39.es/ecma262/#sec-toprimitive (step 2.d)
* runtime/BigIntObject.cpp:
(JSC::BigIntObject::defaultValue): Deleted.
* runtime/BigIntObject.h:
* runtime/SymbolObject.cpp:
(JSC::SymbolObject::defaultValue): Deleted.
* runtime/SymbolObject.h:
2021-04-06 Alexey Shvayka <shvaikalesh@gmail.com>
Array's toString() is incorrect if join() is non-callable
https://bugs.webkit.org/show_bug.cgi?id=224215
Reviewed by Yusuke Suzuki.
This patch exposes objectPrototypeToString() to be used by Array.prototype.toString
if "join" lookup doesn't return a callable value [1].
Fixes Array's toString() to return the correct tag instead of internal `className`,
perform Symbol.toStringTag lookup, and throw for revoked Proxy objects.
Aligns JSC with V8 and SpiderMonkey.
Also, a few objectPrototypeToString() tweaks: a bit nicer `undefined` / `null`
checks and simpler toObject() exception handling.
[1]: https://tc39.es/ecma262/#sec-array.prototype.tostring (step 3)
* runtime/ArrayPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/ObjectPrototype.cpp:
(JSC::objectPrototypeToString):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/ObjectPrototype.h:
2021-04-06 Yusuke Suzuki <ysuzuki@apple.com>
[WTF] Introduce FixedVector and use it for FixedOperands
https://bugs.webkit.org/show_bug.cgi?id=224171
Reviewed by Mark Lam.
Define FixedOperands<T> which uses FixedVector for its storage. We use FixedOperands in FTL::OSRExitDescriptor.
We also replace RefCountedArray<T> with FixedVector<T> if they are not requiring RefCountedArray<T>'s ref-counting
semantics.
* bytecode/BytecodeGeneratorification.cpp:
(JSC::BytecodeGeneratorification::run):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::setConstantRegisters):
(JSC::CodeBlock::setNumParameters):
(JSC::CodeBlock::setRareCaseProfiles):
(JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
* bytecode/CodeBlock.h:
* bytecode/Operands.h:
(JSC::Operands::Operands):
* bytecode/OperandsInlines.h:
(JSC::U>::dumpInContext const):
(JSC::U>::dump const):
(JSC::Operands<T>::dumpInContext const): Deleted.
(JSC::Operands<T>::dump const): Deleted.
* bytecode/PolyProtoAccessChain.h:
* bytecode/PolymorphicAccess.cpp:
(JSC::PolymorphicAccess::regenerate):
* bytecode/PolymorphicAccess.h:
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::dumpExpressionRangeInfo):
(JSC::UnlinkedCodeBlock::expressionRangeForBytecodeIndex const):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::expressionInfo):
(JSC::UnlinkedCodeBlock::identifiers const):
(JSC::UnlinkedCodeBlock::constantRegisters):
(JSC::UnlinkedCodeBlock::constantsSourceCodeRepresentation):
(JSC::UnlinkedCodeBlock::constantIdentifierSets):
(JSC::UnlinkedCodeBlock::opProfileControlFlowBytecodeOffsets const):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::prepareJumpTableForSwitch):
* dfg/DFGJITCode.h:
* dfg/DFGPlan.h:
(JSC::DFG::Plan::tierUpInLoopHierarchy):
* ftl/FTLOSRExit.h:
* jit/GCAwareJITStubRoutine.h:
* jit/JIT.cpp:
(JSC::JIT::privateCompileSlowCases):
* jit/PolymorphicCallStubRoutine.h:
* llint/LLIntOffsetsExtractor.cpp:
* llint/LowLevelInterpreter.asm:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseClassFieldInitializerSourceElements):
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
(JSC::parse):
* runtime/CachedTypes.cpp:
(JSC::CachedVector::encode):
(JSC::CachedVector::decode const):
* wasm/js/JSWebAssemblyInstance.h:
2021-04-05 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Shrink some of Vectors in JSC
https://bugs.webkit.org/show_bug.cgi?id=224162
Reviewed by Simon Fraser.
1. Add XXXStatus::shrinkToFit to shrink underlying dynamic Vectors.
2. Replace tierUpInLoopHierarchy's Vector with RefCountedArray since it is constructed-once-lookup-only data.
3. Use MemoryCompactLookupOnlyRobinHoodHashSet for StringTables since this is constructed-once-lookup-only data. We also add
MemoryCompactLookupOnlyRobinHoodHashSet support for CachedTypes.
4. Use resizeToFit for StringSwitchJumpTables and SwitchJumpTables.
5. JITStubRoutineSet's Vector should be shrunk.
6. BlockDirectoryBits's Vector's initial size should be small.
7. Make PolyProtoAccessChain RefCounted, and use RefCountedArray for its Vector<StructureID>. And remove PolyProtoAccessChain::clone.
Just having Ref is enough since this is immutable data.
8. Use RefCountedArray for UnlinkedFunctionExecutable's m_classFieldLocations.
9. Use RefCountedArray for JSWebAssemblyInstance.
* bytecode/AccessCase.cpp:
(JSC::AccessCase::AccessCase):
(JSC::AccessCase::create):
(JSC::AccessCase::createTransition):
* bytecode/AccessCase.h:
(JSC::AccessCase::AccessCase): Deleted.
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::setFrameShuffleData):
* bytecode/CheckPrivateBrandStatus.cpp:
(JSC::CheckPrivateBrandStatus::shrinkToFit):
(JSC::CheckPrivateBrandStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::CheckPrivateBrandStatus::merge):
* bytecode/CheckPrivateBrandStatus.h:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* bytecode/DeleteByStatus.cpp:
(JSC::DeleteByStatus::shrinkToFit):
(JSC::DeleteByStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::DeleteByStatus::merge):
* bytecode/DeleteByStatus.h:
* bytecode/GetByStatus.cpp:
(JSC::GetByStatus::shrinkToFit):
(JSC::GetByStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::GetByStatus::computeFor):
(JSC::GetByStatus::merge):
* bytecode/GetByStatus.h:
* bytecode/GetterSetterAccessCase.cpp:
(JSC::GetterSetterAccessCase::GetterSetterAccessCase):
(JSC::GetterSetterAccessCase::create):
* bytecode/GetterSetterAccessCase.h:
* bytecode/InByIdStatus.cpp:
(JSC::InByIdStatus::shrinkToFit):
(JSC::InByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::InByIdStatus::merge):
* bytecode/InByIdStatus.h:
* bytecode/InstanceOfStatus.cpp:
(JSC::InstanceOfStatus::shrinkToFit):
(JSC::InstanceOfStatus::computeForStubInfo):
* bytecode/InstanceOfStatus.h:
* bytecode/IntrinsicGetterAccessCase.cpp:
(JSC::IntrinsicGetterAccessCase::IntrinsicGetterAccessCase):
(JSC::IntrinsicGetterAccessCase::create):
* bytecode/IntrinsicGetterAccessCase.h:
* bytecode/JumpTable.h:
* bytecode/PolyProtoAccessChain.cpp:
(JSC::PolyProtoAccessChain::tryCreate):
(JSC::PolyProtoAccessChain::create): Deleted.
* bytecode/PolyProtoAccessChain.h:
(JSC::PolyProtoAccessChain::clone): Deleted.
(JSC::PolyProtoAccessChain::chain const): Deleted.
(JSC::PolyProtoAccessChain::operator!= const): Deleted.
(JSC::PolyProtoAccessChain::forEach const): Deleted.
(JSC::PolyProtoAccessChain::slotBaseStructure const): Deleted.
* bytecode/PolymorphicAccess.cpp:
(JSC::PolymorphicAccess::visitWeak const):
(JSC::PolymorphicAccess::regenerate):
* bytecode/PolymorphicAccess.h:
* bytecode/ProxyableAccessCase.cpp:
(JSC::ProxyableAccessCase::ProxyableAccessCase):
(JSC::ProxyableAccessCase::create):
* bytecode/ProxyableAccessCase.h:
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::shrinkToFit):
(JSC::PutByIdStatus::computeForStubInfo):
(JSC::PutByIdStatus::computeFor):
(JSC::PutByIdStatus::merge):
* bytecode/PutByIdStatus.h:
* bytecode/SetPrivateBrandStatus.cpp:
(JSC::SetPrivateBrandStatus::shrinkToFit):
(JSC::SetPrivateBrandStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::SetPrivateBrandStatus::merge):
* bytecode/SetPrivateBrandStatus.h:
* bytecode/UnlinkedCodeBlock.h:
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::generateUnlinkedFunctionCodeBlock):
* bytecode/UnlinkedFunctionExecutable.h:
* dfg/DFGJITCode.h:
* dfg/DFGPlan.h:
(JSC::DFG::Plan::tierUpInLoopHierarchy):
* dfg/DFGTierUpCheckInjectionPhase.cpp:
(JSC::DFG::TierUpCheckInjectionPhase::run):
* heap/BlockDirectoryBits.h:
* heap/JITStubRoutineSet.cpp:
(JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines):
* jit/CallFrameShuffleData.h:
(JSC::CallFrameShuffleData::shrinkToFit):
* jit/GCAwareJITStubRoutine.h:
* jit/PolymorphicCallStubRoutine.h:
* jit/Repatch.cpp:
(JSC::tryCacheGetBy):
(JSC::tryCachePutByID):
(JSC::tryCacheInByID):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseClassFieldInitializerSourceElements):
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
(JSC::parse):
* runtime/CachedTypes.cpp:
(JSC::CachedFunctionExecutableRareData::encode):
(JSC::CachedFunctionExecutableRareData::decode const):
* runtime/VM.cpp:
(JSC::VM::popAllCheckpointOSRSideStateUntil):
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::visitChildrenImpl):
* wasm/js/JSWebAssemblyInstance.h:
2021-04-05 Alex Christensen <achristensen@webkit.org>
Resurrect Mac CMake build
https://bugs.webkit.org/show_bug.cgi?id=224084
Reviewed by Tim Horton.
* PlatformMac.cmake:
2021-04-05 Keith Miller <keith_miller@apple.com>
DFG arity fixup nodes should exit to the caller's call opcode
https://bugs.webkit.org/show_bug.cgi?id=223278
Reviewed by Saam Barati.
Right now when we do arity fixup in the DFG we model it in the
same way that it executes, which means all the nodes are part of
the callee. Unfortunately, this causes PhantomInsertionPhase to
think those nodes could be replacing previously defined
VirtualRegisters as they are part of the callee's header (always
alive). When PhantomInsertionPhase then inserts a Phantom it will
put that node in the caller's frame as that's the first ExitOK
node. The caller however may have no knowledge of that
VirtualRegister though. For example:
--> foo: loc10 is a local in foo.
...
1: MovHint(loc10)
2: SetLocal(loc10)
<-- foo // loc10 ten is now out of scope for the InlineCallFrame of the caller.
...
// Phantom will be inserted here refering to loc10, which doesn't make sense.
--> bar // loc10 is an argument to bar and needs arity fixup.
... // All of these nodes are ExitInvalid
3: MovHint(loc10, ExitInvalid)
4: SetLocal(loc10, ExitInvalid)
...
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::currentNodeOrigin):
(JSC::DFG::ByteCodeParser::inlineCall):
2021-04-02 Alexey Shvayka <shvaikalesh@gmail.com>
Reduce bytecode instruction count emitted for `class extends`
https://bugs.webkit.org/show_bug.cgi?id=223884
Reviewed by Yusuke Suzuki.
This patch adds a variant of globalFuncSetPrototypeDirect() that throws on
invalid [[Prototype]] values (instead of ignoring them) and utilizes it in
ClassExprNode::emitBytecode(), removing equivalent checks.
Throwing for invalid `superclass.prototype` value after setting the [[Prototype]]
of `constructor` is unobservable because it's a newly created extensible object
and `superclass` is a proven object.
The fact that [[Prototype]] set can throw only in case of `superclass.prototype`
allows keeping descriptive error message via custom appender. To find "extends"
in a source code, ClassExprNode is made an instance of ThrowableExpressionData.
This change reduces the number of emitted bytecodes by 4, and fixes IsConstructor's
error [1] to point to correct source code location.
[1]: https://tc39.es/ecma262/#sec-runtime-semantics-classdefinitionevaluation (step 5.f)
* builtins/BuiltinNames.h:
* bytecode/LinkTimeConstant.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitDirectSetPrototypeOf):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::PropertyListNode::emitPutConstantProperty):
(JSC::ClassExprNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createClassExpr):
* parser/Nodes.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createClassExpr):
* runtime/ExceptionHelpers.cpp:
(JSC::invalidPrototypeSourceAppender):
(JSC::createInvalidPrototypeError):
* runtime/ExceptionHelpers.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/JSGlobalObjectFunctions.h:
2021-04-02 Jessica Tallon <jtallon@igalia.com>
Add type method to WebAssembly.Memory, WebAssembly.Table & WebAssembly.Global objects
https://bugs.webkit.org/show_bug.cgi?id=222412
Reviewed by Yusuke Suzuki.
This adds a type method to several WASM objects as part of the work to add WASM
type reflections to the JS-API. The methods return a JSON object which describes
the type of the object and can be passed to the constructor to create a new wasm
object of that type.
* wasm/js/JSWebAssemblyGlobal.cpp:
(JSC::JSWebAssemblyGlobal::type):
* wasm/js/JSWebAssemblyGlobal.h:
* wasm/js/JSWebAssemblyMemory.cpp:
(JSC::JSWebAssemblyMemory::type):
* wasm/js/JSWebAssemblyMemory.h:
* wasm/js/JSWebAssemblyTable.cpp:
(JSC::JSWebAssemblyTable::type):
* wasm/js/JSWebAssemblyTable.h:
* wasm/js/WebAssemblyGlobalPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyGlobalPrototype.h:
* wasm/js/WebAssemblyMemoryPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyTablePrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
2021-04-01 Yusuke Suzuki <ysuzuki@apple.com>
[WTF] Introduce RobinHoodHashTable
https://bugs.webkit.org/show_bug.cgi?id=223895
Reviewed by Fil Pizlo.
* builtins/BuiltinNames.cpp:
(JSC::lookUpPrivateNameImpl):
(JSC::lookUpWellKnownSymbolImpl):
* builtins/BuiltinNames.h:
* bytecode/BytecodeIntrinsicRegistry.h:
* runtime/Identifier.h:
* runtime/IntlCollator.cpp:
(JSC::IntlCollator::initializeCollator):
(JSC::IntlCollator::checkICULocaleInvariants):
* runtime/IntlCollator.h:
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/IntlDisplayNames.cpp:
(JSC::IntlDisplayNames::initializeDisplayNames):
* runtime/IntlDisplayNamesConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/IntlListFormat.cpp:
(JSC::IntlListFormat::initializeListFormat):
* runtime/IntlListFormatConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::initializeNumberFormat):
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/IntlObject.cpp:
(JSC::addScriptlessLocaleIfNeeded):
(JSC::intlAvailableLocales):
(JSC::intlCollatorAvailableLocales):
(JSC::intlSegmenterAvailableLocales):
(JSC::bestAvailableLocale):
(JSC::lookupMatcher):
(JSC::bestFitMatcher):
(JSC::resolveLocale):
(JSC::lookupSupportedLocales):
(JSC::bestFitSupportedLocales):
(JSC::supportedLocales):
* runtime/IntlObject.h:
(JSC::intlDateTimeFormatAvailableLocales):
(JSC::intlDisplayNamesAvailableLocales):
(JSC::intlNumberFormatAvailableLocales):
(JSC::intlPluralRulesAvailableLocales):
(JSC::intlRelativeTimeFormatAvailableLocales):
(JSC::intlListFormatAvailableLocales):
* runtime/IntlPluralRules.cpp:
(JSC::IntlPluralRules::initializePluralRules):
* runtime/IntlPluralRulesConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/IntlRelativeTimeFormat.cpp:
(JSC::IntlRelativeTimeFormat::initializeRelativeTimeFormat):
* runtime/IntlRelativeTimeFormatConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/IntlSegmenter.cpp:
(JSC::IntlSegmenter::initializeSegmenter):
* runtime/IntlSegmenterConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/RegExpCache.h:
* runtime/RegExpKey.h:
2021-04-01 Yusuke Suzuki <ysuzuki@apple.com>
REGRESSION(r274724): JITCage trampoline needs to be adjusted
https://bugs.webkit.org/show_bug.cgi?id=224065
Reviewed by Saam Barati.
r274724 introduced a new parameter to custom setters, but it didn't change the parameter recognization of JITCage trampolines for custom accessors.
As a result, we are jumping with the wrong pointer, and crash when custom setter is called with JITCage.
This patch fixes the above bug.
1. Now, custom getter and custom setter have different number of parameters. We should have two different trampolines to invoke it. We remove vmEntryCustomAccessor, and
add vmEntryCustomGetter/vmEntryCustomSetter.
2. vmEntryCustomSetter should use a4 parameter as a executable address for trampoline.
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateImpl):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCallDOMGetter):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCallDOMGetter):
* llint/LLIntThunks.cpp:
* llint/LLIntThunks.h:
* llint/LowLevelInterpreter.asm:
* offlineasm/arm64.rb:
* offlineasm/registers.rb:
* runtime/PropertySlot.h:
2021-04-01 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Use ucal_getTimeZoneOffsetFromLocal if ICU 69 is present
https://bugs.webkit.org/show_bug.cgi?id=224075
Reviewed by Yusuke Suzuki.
Apple ICU 68 cherry picked ucal_getTimeZoneOffsetFromLocal (see r223783),
but now that ICU 69 is in RC, we can go ahead and update the #if for non-Apple platforms.
* runtime/JSDateMath.cpp:
2021-04-01 Tadeu Zagallo <tzagallo@apple.com>
Remove use of ENABLE from API header
https://bugs.webkit.org/show_bug.cgi?id=224060
<rdar://76111678>
Reviewed by Mark Lam.
The use of the ENABLE macro in these API headers has caused build failures. Instead of
conditionally exposing these API methods we make them into no-ops if DFG is disabled.
* API/JSVirtualMachine.mm:
(+[JSVirtualMachine setNumberOfDFGCompilerThreads:]):
(+[JSVirtualMachine setNumberOfFTLCompilerThreads:]):
* API/JSVirtualMachinePrivate.h:
2021-04-01 Alexey Shvayka <shvaikalesh@gmail.com>
Optimize createListFromArrayLike() and Proxy's [[OwnPropertyKeys]] method
https://bugs.webkit.org/show_bug.cgi?id=223928
Reviewed by Yusuke Suzuki.
createListFromArrayLike() changes:
1. Use toLength() / getIndex() methods that have fast paths.
2. Remove RuntimeTypeMask and error messages from its signature: type checks are better
performed in advance / inside a functor to keep the helper more versatile.
3. Invert functor's return value to align with Structure::forEachProperty() and friends.
4. Rename it to forEachInArrayLike() as no list is actually returned.
ProxyObject::performGetOwnPropertyNames() changes:
1. Remove RuntimeTypeMask filtering as it's already performed by PropertyNameArray::add().
2. Store target's keys in a HashSet for faster insertion / search.
3. Don't populate `targetConfigurableKeys` for extensible target as it won't be used [1].
4. Leverage return value of HashSet::remove() instead of using a helper.
This patch advances Proxy's [[OwnPropertyKeys]] microbenchmarks by 20-30%,
mainly due to createListFromArrayLike() changes. No behavior changes.
Also, utilizes forEachInArrayLike() for allow list of JSON.stringify().
[1]: https://tc39.es/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-ownpropertykeys (step 20)
* runtime/JSONObject.cpp:
(JSC::Stringifier::Stringifier):
* runtime/JSObject.h:
(JSC::JSObject::getIndex const):
* runtime/JSObjectInlines.h:
(JSC::forEachInArrayLike):
(JSC::createListFromArrayLike): Deleted.
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::performGetOwnPropertyNames):
* runtime/ReflectObject.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
2021-03-31 David Kilzer <ddkilzer@apple.com>
UBSan: JSC::Parser<LexerType>::parseProperty(): runtime error: load of value nnn, which is not a valid value for type 'bool'
<https://webkit.org/b/223896>
<rdar://problem/75970132>
Reviewed by Darin Adler.
Based on a suggestion by Darin Adler.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseProperty):
- Change 'escaped' to 'wasUnescapedIdent' to avoid the undefined
behavior since m_token.m_data.escaped is only set in the case
when an identifer is parsed (in Lexer<>::parseIdentifer()),
not a string (in Lexer<>::parseString()). This simplifies the
logic later in the method.
2021-03-31 Mark Lam <mark.lam@apple.com>
Missing exception check in HashMapImpl::add().
https://bugs.webkit.org/show_bug.cgi?id=224007
rdar://76053163
Reviewed by Saam Barati.
* runtime/HashMapImpl.h:
(JSC::HashMapImpl::add):
2021-03-31 Xan Lopez <xan@igalia.com>
[JSC] Remove warnings about unnecessary operator= for ARMv7Assembler LinkRecord
https://bugs.webkit.org/show_bug.cgi?id=223916
Reviewed by Darin Adler.
Many years ago we defined an assignment operator for LinkRecord in
order to speed up build times (see #90930). Recent GCC versions
tell us that if we do that we almost certainly want to define a
copy constructor too. The ARM64Assembler file already does it, so
do it too for ARMv7 to remove the warnings.
* assembler/ARM64Assembler.h:
* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::LinkRecord::LinkRecord):
(JSC::ARMv7Assembler::LinkRecord::operator=):
2021-03-31 Alexey Shvayka <shvaikalesh@gmail.com>
Optimize constructors of ES6 collections
https://bugs.webkit.org/show_bug.cgi?id=223953
Reviewed by Yusuke Suzuki.
This patch speeds up the constructors by avoiding call() for non-observable
"set" / "add" methods and using getIndex() for Map / WeakMap collections.
For Map / Set, this change leverages existing cloning helpers, which rely on
watchpoints, to avoid even a method lookup. However, slower path is used for
subclasses. Results in 1.9x speed-up for common case.
For WeakMap / WeakSet, adder function is checked by C++ pointer, which enables
fast path even for cross-realm subclasses. Results in 2.3x progression.
Both approaches require special handling of a cross-realm NewTarget to ensure
that raised exceptions (OOM / TypeError) belong to realm of the adder function,
and not to constructor's or NewTarget's.
Also, adds descriptve error messages for non-callable "set" / "add" properties.
* runtime/JSMap.cpp:
(JSC::JSMap::isSetFastAndNonObservable):
(JSC::JSMap::canCloneFastAndNonObservable): Deleted.
* runtime/JSMap.h:
* runtime/JSSet.cpp:
(JSC::JSSet::isAddFastAndNonObservable):
(JSC::JSSet::canCloneFastAndNonObservable): Deleted.
* runtime/JSSet.h:
* runtime/MapConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/SetConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/WeakMapConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/WeakMapPrototype.cpp:
(JSC::WeakMapPrototype::finishCreation):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/WeakMapPrototype.h:
* runtime/WeakSetConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/WeakSetPrototype.cpp:
(JSC::WeakSetPrototype::finishCreation):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/WeakSetPrototype.h:
2021-03-30 Devin Rousso <drousso@apple.com>
REGRESSION(r274607): media controls script is visible in Web Inspector even without the engineering "Show WebKit-internal scripts" enabled
https://bugs.webkit.org/show_bug.cgi?id=223961
Reviewed by Yusuke Suzuki.
It turns out that Web Inspector will only ignore scripts that have a source URL directive
that matches `__InjectedScript_*.js`, not those that have a (source) URL matching that.
In addition to Web Inspector ignoring these scripts in the UI, it will also cause the
`Debugger` to not pause in scripts with a matching source URL directive (unless the
local build engineering only "Pause in WebKit-internal scripts" is enabled).
* Scripts/make-js-file-arrays.py:
(main):
Add a `//# sourceURL=__InjectedScript_*.js` to the contents before it's encoded.
2021-03-30 Sam Weinig <weinig@apple.com>
JSGlobalObject's m_customGetterFunctionMap and m_customSetterFunctionMap should be sets, not maps, and should use both the identifier and function pointer as the key
https://bugs.webkit.org/show_bug.cgi?id=223613
Reviewed by Saam Barati.
- Adds a generic WeakGCSet class to go with the existing WeakGCMap.
- Renames WeakGCMapBase to WeakGCHashTable, moves it to its own file
and now uses it as the base class of both WeakGCSet and WeakGCMap.
- Replaces JSGlobalObject's customGetterFunctionMap/customSetterFunctionMap
with customGetterFunctionSet/customSetterFunctionSet, using the new
WeakGCSet, and updates them to use both the function pointer and
property name for the key, rather than just the function pointer which
is what the previous code did. This allows multiple custom functions
to use the same underlying function pointer as long as they have distinct
property names, which is going to be used to optimize the bindings for
CSSStyleDeclaration.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
Add new files.
* heap/Heap.cpp:
(JSC::Heap::runEndPhase):
(JSC::Heap::pruneStaleEntriesFromWeakGCHashTables):
(JSC::Heap::registerWeakGCHashTable):
(JSC::Heap::unregisterWeakGCHashTable):
(JSC::Heap::pruneStaleEntriesFromWeakGCMaps): Deleted.
(JSC::Heap::registerWeakGCMap): Deleted.
(JSC::Heap::unregisterWeakGCMap): Deleted.
* heap/Heap.h:
Update for new name. WeakGCMapBase -> WeakGCHashTable.
* runtime/JSCInlines.h:
Add WeakGCSetInlines.h
* runtime/JSCustomGetterFunction.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::JSCustomGetterFunction::JSCustomGetterFunction):
(JSC::JSCustomGetterFunction::create):
* runtime/JSCustomGetterFunction.h:
* runtime/JSCustomSetterFunction.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::JSCustomSetterFunction::JSCustomSetterFunction):
(JSC::JSCustomSetterFunction::create):
* runtime/JSCustomSetterFunction.h:
Add helper type CustomFunctionPointer and helper function customFunctionPointer()
to allow some generic hashing code to run on either JSCustomGetterFunction
or JSCustomSetterFunction.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::JSGlobalObject):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::WeakCustomGetterOrSetterHash::hash):
(JSC::JSGlobalObject::WeakCustomGetterOrSetterHash::equal):
(JSC::JSGlobalObject::customGetterFunctionSet):
(JSC::JSGlobalObject::customSetterFunctionSet):
(JSC::JSGlobalObject::customGetterFunctionMap): Deleted.
(JSC::JSGlobalObject::customSetterFunctionMap): Deleted.
Replace m_customGetterFunctionMap/m_customSetterFunctionMap with
m_customGetterFunctionSet/m_customSetterFunctionSet. As the key is included
in the value, it saves space to use a set rather than a map. We now also
hash and compare both the function pointer and the property name to allow
sharing implementations.
* runtime/JSObject.cpp:
(JSC::WeakCustomGetterOrSetterHashTranslator::hash):
(JSC::WeakCustomGetterOrSetterHashTranslator::equal):
(JSC::createCustomGetterFunction):
(JSC::createCustomSetterFunction):
Update creation functions to use the new sets, making use of the
ensureValue function and a HashTranslator allowing the use of a
std::pair<PropertyName, FunctionPointer> as an alternative lookup
key. This allows us to avoid creating the JSCustomGetterFunction/JSCustomSetterFunction
pointer if one with the same property name and function pointer are
already in the set.
* runtime/WeakGCHashTable.h: Added.
(JSC::WeakGCHashTable::~WeakGCHashTable):
Moved from WeakGCMap and renamed as it is now the base of both
WeakGCMap and WeakGCSet.
* runtime/WeakGCMap.h:
Update to use new WeakGCHashTable base class.
* runtime/WeakGCMapInlines.h:
(JSC::KeyTraitsArg>::WeakGCMap):
(JSC::KeyTraitsArg>::~WeakGCMap):
Update for new Heap function names for WeakGCHashTable.
* runtime/WeakGCSet.h: Added.
* runtime/WeakGCSetInlines.h: Added.
(JSC::TraitsArg>::WeakGCSet):
(JSC::TraitsArg>::~WeakGCSet):
(JSC::TraitsArg>::find):
(JSC::TraitsArg>::find const):
(JSC::TraitsArg>::contains const):
(JSC::TraitsArg>::pruneStaleEntries):
Added a minimal WeakGCSet based on WeakGCMap.
2021-03-30 Mark Lam <mark.lam@apple.com>
Add disableForwardingVPrintfStdErrToOSLog() and use it in the jsc shell.
https://bugs.webkit.org/show_bug.cgi?id=223963
Reviewed by Saam Barati.
This prevents automatic forwarding of vprintf_stderr_common() to os_log_with_args(),
which results in duplicate output when using the jsc shell. As a result, ASSERT
fail messages and crash stack traces will be more readable.
* jsc.cpp:
(main):
2021-03-30 Mark Lam <mark.lam@apple.com>
Add Options::exitOnResourceExhaustion() to enable exiting instead of crashing on resource exhaustion.
https://bugs.webkit.org/show_bug.cgi?id=223959
rdar://63934158
Reviewed by Tadeu Zagallo.
This is useful to unblock fuzzers from false positive crashes due to resource
exhaustion. Currently, this is only applied to StructureID exhaustion.
Since we're adding this facility, we might as well implement it in such a way that
it can be easily deployed for other types of resource exhaustion as well.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* runtime/OptionsList.h:
* runtime/ResourceExhaustion.cpp: Added.
(JSC::handleResourceExhaustion):
* runtime/ResourceExhaustion.h: Added.
* runtime/StructureIDTable.cpp:
(JSC::StructureIDTable::resize):
2021-03-30 Ryan Haddad <ryanhaddad@apple.com>
Ensure that GlobalPropertyInfo is allocated on the stack.
https://bugs.webkit.org/show_bug.cgi?id=223911
Unreviewed test gardening.
Rebaseline builtins generator tests after r275212.
* Scripts/tests/builtins/expected/WebCoreJSBuiltins.h-result:
2021-03-30 Mark Lam <mark.lam@apple.com>
Add more information to GC verifier verbose dumps.
https://bugs.webkit.org/show_bug.cgi?id=223951
Reviewed by Yusuke Suzuki.
* heap/VerifierSlotVisitor.cpp:
(JSC::VerifierSlotVisitor::dumpMarkerData):
2021-03-30 Mark Lam <mark.lam@apple.com>
Ensure that GlobalPropertyInfo is allocated on the stack.
https://bugs.webkit.org/show_bug.cgi?id=223911
rdar://75865742
Reviewed by Yusuke Suzuki.
We rely on GlobalPropertyInfo being allocated on the stack to allow its JSValue
value to be scanned by the GC. Unfortunately, an ASAN compilation would choose
to allocate the GlobalPropertyInfo on a side buffer instead of directly on the
stack. This prevents the GC from doing the needed scan.
We'll fix this by suppressing ASAN on the functions that allocated GlobalPropertyInfo
arrays. Also added an ASSERT in the GlobalPropertyInfo constructor to assert that
it is allocated on the stack.
* Scripts/wkbuiltins/builtins_generate_internals_wrapper_implementation.py:
(BuiltinsInternalsWrapperImplementationGenerator.generate_initialize_method):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::initStaticGlobals):
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::exposeDollarVM):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::GlobalPropertyInfo::GlobalPropertyInfo):
2021-03-29 Xan López <xan@igalia.com>
[JSC] Use helper method when possible to store data in the callframe header
https://bugs.webkit.org/show_bug.cgi?id=223432
Reviewed by Yusuke Suzuki.
A bunch of the direct stores to the callframe header are zeroing
out the codeblock slot. Create a helper method to do that and use
it accordingly. For the rest, use emitPutToCallFrameHeader, which
already does the right thing. Also, remove a lot of unused helper
methods in AssemblyHelpers (which have been updated for no reason
throughout the years).
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitPutToCallFrameHeaderBeforePrologue): Deleted.
(JSC::AssemblyHelpers::emitPutPayloadToCallFrameHeaderBeforePrologue): Deleted.
(JSC::AssemblyHelpers::emitPutTagToCallFrameHeaderBeforePrologue): Deleted.
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::createJSToWasmWrapper):
* wasm/js/WasmToJS.cpp:
(JSC::Wasm::wasmToJS):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::jsCallEntrypointSlow):
2021-03-28 Sam Weinig <weinig@apple.com>
Remove ENABLE_INDEXED_DATABASE & ENABLE_INDEXED_DATABASE_IN_WORKERS, it seems like it is on for all ports
https://bugs.webkit.org/show_bug.cgi?id=223810
Reviewed by Simon Fraser.
* inspector/protocol/IndexedDB.json:
Update for remove ENABLE_INDEXED_DATABASE conditional.
2021-03-26 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use AppleICU SPI for canonicalization
https://bugs.webkit.org/show_bug.cgi?id=223552
Reviewed by Ryosuke Niwa.
uloc_canonicalize does not perform alias mapping. This is different from ECMA402's canonicalization requirement.
ICU C++ icu::Locale can canonicalize locale ID with alias mapping, but this is not exposed to C API.
In this patch, we adopt AppleICU SPI "ualoc_canonicalForm" added in rdar://74314220. This canonicalization can perform
alias mapping too. We do not extend uloc_canonicalize since this API explicitly says "It does NOT map aliased names in any way."[1].
In [2], we are tracking upstreaming of this new SPI. Once it is upstreamed to the mainline ICU, we will switch to that.
[1]: https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/uloc_8h.html#a69b148194cf57ac40d4bb15c5b905260
[2]: https://unicode-org.atlassian.net/browse/ICU-21506
* runtime/IntlLocale.cpp:
(JSC::LocaleIDBuilder::initialize):
(JSC::LocaleIDBuilder::toCanonical):
* runtime/IntlObject.cpp:
(JSC::localeIDBufferForLanguageTagWithNullTerminator):
(JSC::canonicalizeLanguageTag):
(JSC::canonicalizeLocaleIDWithoutNullTerminator):
(JSC::localeIDBufferForLanguageTag): Deleted.
* runtime/IntlObject.h:
2021-03-26 Don Olmstead <don.olmstead@sony.com>
[CMake] Deprecate using DERIVED_SOURCES_DIR/FOWARDING_HEADERS_DIR directly
https://bugs.webkit.org/show_bug.cgi?id=223763
Reviewed by Michael Catanzaro.
Remove any usages of DERIVED_SOURCES_DIR and FOWARDING_HEADERS_DIR.
* CMakeLists.txt:
* PlatformMac.cmake:
2021-03-26 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use new Apple ICU APIs to avoid C++ ICU API usage
https://bugs.webkit.org/show_bug.cgi?id=223783
<rdar://problem/75060240>
Reviewed by Mark Lam.
This patch adopts ICU 69's draft APIs to avoid using ICU C++ APIs in newer macOS build.
AppleICU adopts these draft APIs so that we can use it even in ICU 68 if ICU is AppleICU.
The API is ucal_getTimeZoneOffsetFromLocal, which is back-ported from ICU 69[1].
The purpose of this API is that calculating timezone offset and dst offset from *local* time.
[1]: https://github.com/unicode-org/icu/commit/53aa0505c5f95a8cebbd7b4421d474fd2a790b80
* runtime/IntlDateTimeFormat.cpp:
* runtime/JSDateMath.cpp:
(JSC::OpaqueICUTimeZoneDeleter::operator()):
(JSC::DateCache::calculateLocalTimeOffset):
(JSC::DateCache::defaultTimeZone):
(JSC::DateCache::timeZoneCacheSlow):
* runtime/JSDateMath.h:
2021-03-26 Jessie Berlin <jberlin@webkit.org>
Update the BEFORE/SINCE, SYSTEM_VERSION_PREFIX, and MACOSX_DEPLOYMENT_TARGET flags
https://bugs.webkit.org/show_bug.cgi?id=223779
Reviewed by Tim Horton.
* Configurations/DebugRelease.xcconfig:
* Configurations/Version.xcconfig:
* Configurations/WebKitTargetConditionals.xcconfig:
2021-03-25 Saam Barati <sbarati@apple.com>
validate untagArrayPtr
https://bugs.webkit.org/show_bug.cgi?id=214953
<rdar://problem/66391434>
Reviewed by Mark Lam.
This patch adds validation to untagArrayPtr along paths where we don't
immediately store/load from the result.
This patch also changes the removeArrayPtrTag macro assembler function to
use a bitwise and instead of xpacd to strip the tag, because it's faster.
* assembler/MacroAssemblerARM64E.h:
(JSC::MacroAssemblerARM64E::untagArrayPtr):
(JSC::MacroAssemblerARM64E::removeArrayPtrTag):
* assembler/testmasm.cpp:
(JSC::testCagePreservesPACFailureBit):
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateWithGuard):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::untagArrayPtr):
(JSC::FTL::DFG::LowerDFGToB3::caged):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::cageWithoutUntagging):
(JSC::AssemblyHelpers::cageConditionallyAndUntag):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::cageWithoutUntagging): Deleted.
(JSC::AssemblyHelpers::cageConditionally): Deleted.
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitIntTypedArrayPutByVal):
(JSC::JIT::emitFloatTypedArrayPutByVal):
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
(JSC::Wasm::AirIRGenerator::addCallIndirect):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
(JSC::Wasm::B3IRGenerator::addCallIndirect):
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToWasm):
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::createJSToWasmWrapper):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::jsCallEntrypointSlow):
2021-03-25 Jessie Berlin <jberlin@webkit.org>
Remove 10.13 DEPLOYMENT_TARGETs and SYSTEM_VERSION_PREFIXs
https://bugs.webkit.org/show_bug.cgi?id=223765
Reviewed by Tim Horton.
* Configurations/Base.xcconfig:
* Configurations/DebugRelease.xcconfig:
* Configurations/Version.xcconfig:
2021-03-25 Carlos Garcia Campos <cgarcia@igalia.com>
[GTK][WPE] JSC crashes if a function expects a parameter but doesn't receive any
https://bugs.webkit.org/show_bug.cgi?id=223646
Reviewed by Adrian Perez de Castro.
Handle the case of receiving fewer argumens than expected in function calls and constructors. We pass undefined
for the expected arguments that are missing. We were not correctly handling the case of converting undefined and
null values to JSCValue, so this patch fixes that case too.
* API/glib/JSCCallbackFunction.cpp:
(JSC::JSCCallbackFunction::call):
(JSC::JSCCallbackFunction::construct):
* API/glib/JSCContext.cpp:
(jscContextJSValueToWrappedObject):
(jscContextJSValueToGValue):
2021-03-24 Michael Saboff <msaboff@apple.com>
[YARR] Interpreter incorrectly matches non-BMP characters with multiple . w/dotAll flag
https://bugs.webkit.org/show_bug.cgi?id=223666
Reviewed by Mark Lam.
In checkCharacterClassDontAdvanceInputForNonBMP(), we need to check for input.readChecked() returning -1
and return that the character class didn't match.
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::Interpreter::checkCharacterClassDontAdvanceInputForNonBMP):
2021-03-24 Saam Barati <sbarati@apple.com>
r271034 added code in constant folding phase that's unreachable given current invariants of our ICs and PutByIdStatus
https://bugs.webkit.org/show_bug.cgi?id=223625
Reviewed by Yusuke Suzuki.
The code was doing a lot of wrong things by making bad assumptions about the
invariants of PutByIdVariants. Replace PutByIdVariants never have object
property condition sets, since we always replace on the self object (and don't
look at the prototype chain). This patch clears up the code to make it
clearer what the invariants are.
With respect to the original fix about not emitting a PutByOffset for a
Replace on a Structure that has an unfired replacement watchpoint set,
that was already handled by the PutByIdStatus::computeFor variant we're
calling inside of constant folding. It will return TakesSlowPathif it
encounters a Replace where the Structure still has an unfired watchpoint.
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::tryFoldAsPutByOffset):
2021-03-24 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Rope string equal operation should first check length
https://bugs.webkit.org/show_bug.cgi?id=223678
Reviewed by Mark Lam.
This can avoid eagerly resolving rope strings if it is not necessary.
* runtime/JSString.cpp:
(JSC::JSString::equalSlowCase const):
2021-03-23 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Functor for WeakGCMap::ensureValue must not invoke GC
https://bugs.webkit.org/show_bug.cgi?id=223629
<rdar://problem/75619217>
Reviewed by Mark Lam.
The functor for WeakGCMap::ensureValue must not invoke GC. GC can prune entries in WeakGCMap.
So we can modify underlying HashMap while we are just touching it for HashMap::ensure. This
can corrupt HashMap. To ensure this invariant, we put DisallowGC for WeakGCMap::ensureValue.
So we cannot invoke GC in the functor of that function (otherwise, assertion hits).
And we use DeferGC in createCustomGetterFunction / createCustomSetterFunction to avoid invoking
GC in WeakGCMap::ensureValue. This defers GC invocation until this DeferGC scope is destroyed,
and ensures that functor invoked by WeakGCMap::ensureValue will not cause GC.
* runtime/JSObject.cpp:
(JSC::createCustomGetterFunction):
(JSC::createCustomSetterFunction):
(JSC::JSObject::getOwnPropertyDescriptor):
* runtime/WeakGCMap.h:
2021-03-23 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use ErrorInstance for AggregateError
https://bugs.webkit.org/show_bug.cgi?id=223626
Reviewed by Darin Adler.
From r274609, WebAssembly errors start using normal ErrorInstance. We apply the same thing to AggregateError too.
This patch removes AggregateError class, and just generating ErrorInstance.
* runtime/AggregateError.cpp:
(JSC::createAggregateError):
(JSC::AggregateError::AggregateError): Deleted.
(JSC::AggregateError::finishCreation): Deleted.
(JSC::AggregateError::create): Deleted.
* runtime/AggregateError.h:
(): Deleted.
* runtime/AggregateErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::initializeAggregateErrorConstructor):
2021-03-23 Robin Morisset <rmorisset@apple.com>
Object.freeze(this) at the global scope can lose a reference to a WatchpointSet
https://bugs.webkit.org/show_bug.cgi?id=223608
Reviewed by Yusuke Suzuki.
When freezing the global object, we should make a proper copy of symbol table entries, to keep any outstanding reference to the WatchpointSet.
We cannot use pack(), because it does not support FatEntries.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::defineOwnProperty):
* runtime/JSSymbolTableObject.h:
(JSC::symbolTableGet):
* runtime/SymbolTable.h:
(JSC::SymbolTableEntry::setReadOnly):
2021-03-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] JSCustomGetterFunction/JSCustomSetterFunction should use Identifier for their field
https://bugs.webkit.org/show_bug.cgi?id=223588
Reviewed by Mark Lam and Saam Barati.
PropertyName is the holder for passing it as an argument, and it does not ref/deref underlying UniqueStringImpl.
We should use Identifier to keep it strongly ref-ed in JSCustomGetterFunction/JSCustomSetterFunction.
And we should make JSCustomGetterFunction/JSCustomSetterFunction destructible objects since Identifier needs to
deref underlying UniqueStringImpl when destroying these functions.
* runtime/JSCustomGetterFunction.cpp:
(JSC::JSCustomGetterFunction::JSCustomGetterFunction):
(JSC::JSCustomGetterFunction::destroy):
* runtime/JSCustomGetterFunction.h:
* runtime/JSCustomSetterFunction.cpp:
(JSC::JSCustomSetterFunction::JSCustomSetterFunction):
(JSC::JSCustomSetterFunction::destroy):
* runtime/JSCustomSetterFunction.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2021-03-22 Saam Barati <sbarati@apple.com>
LiteralParser shouldn't make error messages of length ~2^31
https://bugs.webkit.org/show_bug.cgi?id=223483
<rdar://75572255>
Reviewed by Robin Morisset.
* runtime/LiteralParser.cpp:
(JSC::LiteralParser<CharType>::parse):
2021-03-22 Michael Saboff <msaboff@apple.com>
[YARR] Interpreter incorrectly matches non-BMP characters with multiple .
https://bugs.webkit.org/show_bug.cgi?id=223498
Reviewed by Yusuke Suzuki.
We need to check that we read an actual character before seeing if it is part of a character class.
In the case where we are checking that a character is not in a character class, like .,
the failed to read result from input.readChecked(), -1, is not part of the newline character class.
This will allow regular expressions that require more than the number of characters in a string
to match.
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::Interpreter::checkCharacterClass):
2021-03-22 Ross Kirsling <ross.kirsling@sony.com>
Unreviewed, fix Mac and non-unified JSCOnly builds
https://bugs.webkit.org/show_bug.cgi?id=223546
* wasm/WasmGlobal.h:
* wasm/WasmTable.h:
* wasm/js/JSWebAssemblyCompileError.cpp:
* wasm/js/JSWebAssemblyLinkError.cpp:
* wasm/js/JSWebAssemblyRuntimeError.cpp:
Add missing includes for non-unified JSC build.
2021-03-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Intl.Locale should not assume is8Bit
https://bugs.webkit.org/show_bug.cgi?id=223553
Reviewed by Ross Kirsling.
is8Bit or not is not guaranteed if it is an user-input. For example, "test日本語".substring(0, 3) should be non 8Bit string.
Intl.Locale has several places that assumed that input should be 8Bit if they are ASCII. This patch fixes it.
* runtime/IntlLocale.cpp:
(JSC::LocaleIDBuilder::overrideLanguageScriptRegion):
(JSC::LocaleIDBuilder::setKeywordValue):
2021-03-22 Sam Weinig <weinig@apple.com>
Use the PropertyName parameter passed to custom getters/setters rather than a redundant const char* in DOM attribute prologues
https://bugs.webkit.org/show_bug.cgi?id=223542
Reviewed by Alexey Shvayka.
Add throwVMDOMAttributeSetterTypeError to match existing throwVMDOMAttributeGetterTypeError and move
additional helpers used by WebCore here to avoid redundant work.
Removes some now unused functions.
* runtime/Error.cpp:
(JSC::createGetterTypeError):
(JSC::makeDOMAttributeGetterTypeErrorMessage):
(JSC::makeDOMAttributeSetterTypeErrorMessage):
(JSC::throwDOMAttributeGetterTypeError):
(JSC::throwDOMAttributeSetterTypeError):
(JSC::throwGetterTypeError): Deleted.
* runtime/Error.h:
(JSC::throwVMRangeError):
(JSC::throwVMDOMAttributeSetterTypeError):
(JSC::throwVMGetterTypeError): Deleted.
2021-03-22 Tyler Wilcock <twilco.o@protonmail.com>
AppleWin can't start due to "Failed to determine path to AAS directory." because iTunes changed the registry key
https://bugs.webkit.org/show_bug.cgi?id=219015
Reviewed by Alex Christensen.
It appears that iTunes no longer sets the Apple Application Support
registry entry. Fall back to trying to find the iTunes installation
directory if the AAS directory is not present.
* shell/DLLLauncherMain.cpp:
(iTunesDirectory): Added.
(modifyPath):
2021-03-19 Darin Adler <darin@apple.com>
[Cocoa] Make it possible to release a WKWebView on a non-main thread without a crash due to WKScriptMessage race
https://bugs.webkit.org/show_bug.cgi?id=222336
Reviewed by Chris Dumez.
* API/ObjcRuntimeExtras.h: Removed declarations of objc_initWeak and objc_destroyWeak, since
these are already in <wtf/spi/cocoa/objcSPI.h>.
2021-03-19 Mark Lam <mark.lam@apple.com>
BrandedStructure should keep its members alive.
https://bugs.webkit.org/show_bug.cgi?id=223495
rdar://75565765
Reviewed by Saam Barati.
Normally, each type of JSCell would have its own structure (and therefore, its own
ClassInfo, MethodTable, etc), which would have handled visiting m_parentBrand.
Similarly, it would have its own destructor, which would deref m_brand.
However, the design of BrandedStructure is not like other JSCells. As present,
we have chosen to go with having BrandedStructure look exactly like a regular
Structure, except that its isBrandedStructure flag is set to true.
This design has advantages because we do checks all over the system for whether
a cell is a Structure by simply comparing its structureID to structureStructure's
structureID. By virtue of BrandedStructure having the same structure as Structure,
none of this code need to change.
The downside is that we need to enhance Structure's methods to check if it is
actually working on an instance of BrandedStructure, and do some additional work.
This patch fixes 2 bugs:
1. m_parentBrand was not visited by visitChildren().
Structure::visitChildrenImpl() now calls BrandedStructure::visitAdditionalChildren()
to handle this.
2. m_brand needs to be ref'ed.
In Structure::setBrandTransition(), if the BrandedStructure is a dictionary,
then its m_transitionPropertyName will be cleared. m_transitionPropertyName
was the only means by which the UniqueStringImpl pointed to by m_brand was
ref'ed. The fix is to make m_brand a RefPtr.
Hence, it follows that we also need to deref m_brand on destruction.
Structure's destructor now calls BrandedStructure::destruct() to handle this.
* runtime/BrandedStructure.h:
* runtime/Structure.cpp:
(JSC::Structure::~Structure):
(JSC::Structure::visitChildrenImpl):
2021-03-19 Sam Weinig <weinig@apple.com>
Add PropertyName parameter to custom setters to allow shared implementations to do late name lookup
https://bugs.webkit.org/show_bug.cgi?id=223413
Reviewed by Alexey Shvayka.
Make custom setters match custom getters by adding a PropertyName parameter.
This will be used by the CSSStyleDeclaration bindings to avoid > 1000 copies
of the same getter/setter code, which will instead be able to differentiate
using the name.
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateImpl):
* jsc.cpp:
(JSC_DEFINE_CUSTOM_SETTER):
* runtime/CustomGetterSetter.cpp:
(JSC::callCustomSetter):
* runtime/CustomGetterSetter.h:
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive):
* runtime/JSCustomSetterFunction.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::JSCustomSetterFunction::JSCustomSetterFunction):
(JSC::JSCustomSetterFunction::create):
* runtime/JSCustomSetterFunction.h:
* runtime/JSObject.cpp:
(JSC::JSObject::putInlineSlow):
* runtime/Lookup.h:
(JSC::putEntry):
* runtime/PropertySlot.h:
* runtime/RegExpConstructor.cpp:
(JSC::JSC_DEFINE_CUSTOM_SETTER):
* runtime/RegExpObject.cpp:
(JSC::JSC_DEFINE_CUSTOM_SETTER):
* tools/JSDollarVM.cpp:
== Rolled over to ChangeLog-2021-03-18 ==