Google Git
Sign in
webkit / WebKit / 8851929603964a534545345e3fc7ac5ad4904dee / . / Source / JavaScriptCore / ChangeLog
blob: 00606b938245d408c86092ef281ff46bce224db5 [file] [log] [blame]
2016-10-27 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Introduce Page WorkerAgent and Worker InspectorController
https://bugs.webkit.org/show_bug.cgi?id=163817
<rdar://problem/28899063>
Reviewed by Brian Burg.
* CMakeLists.txt:
* DerivedSources.make:
* inspector/protocol/Worker.json: Added.
New Worker domain.
2016-10-26 JF Bastien <jfbastien@apple.com>
WebAssembly API: implement Instance
As described in: https://github.com/WebAssembly/design/blob/master/JS.md#webassemblyinstance-objects
- Take ownership of Wasm::Plan's compilation result when successfully creating a JSWebAssemblyModule object.
- Construct a basic Instance with a Module.
- Handle second argument (importObject) of WebAssembly.Instance.
- Add reference text from the spec to WebAssembly.Module's code.
- Expose and test an empty 'exports' ModuleNamespaceObject on WebAssembly.Instance.
The implementation isn't complete yet: it relies on further work for which I've filed bugs.
WebAssembly API: implement Instance
https://bugs.webkit.org/show_bug.cgi?id=163998
Reviewed by Keith Miller.
* wasm/WasmPlan.h:
(JSC::Wasm::Plan::getFunctions): allow transfering state out
(JSC::Wasm::Plan::getMemory): allow transfering state out
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::create):
(JSC::JSWebAssemblyInstance::finishCreation): set the ModuleNamespaceObject, and expose it as "exports"
(JSC::JSWebAssemblyInstance::visitChildren): visit the ModuleNamespaceObject child
* wasm/js/JSWebAssemblyInstance.h:
* wasm/js/JSWebAssemblyModule.cpp:
(JSC::JSWebAssemblyModule::create):
(JSC::JSWebAssemblyModule::JSWebAssemblyModule): move in the compiled functions and the memory
* wasm/js/JSWebAssemblyModule.h:
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance): take the Module, extract the Plan's results, and create the (empty for now) ModuleNamespaceObject
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::constructJSWebAssemblyModule): add a few comments from the spec, and pass out the Plan's results
2016-10-26 Brian Burg <bburg@apple.com>
Web Inspector: remove unused bool return value from FrontendChannel::sendMessageToFrontend
https://bugs.webkit.org/show_bug.cgi?id=164046
Reviewed by Joseph Pecoraro.
* inspector/InspectorFrontendChannel.h:
* inspector/remote/RemoteConnectionToTarget.h:
* inspector/remote/RemoteConnectionToTarget.mm:
(Inspector::RemoteConnectionToTarget::sendMessageToFrontend):
2016-10-26 JF Bastien <jfbastien@apple.com>
WebAssembly: remove now-dead JSWasmModule
https://bugs.webkit.org/show_bug.cgi?id=164044
Reviewed by Keith Miller.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/Executable.cpp:
(JSC::WebAssemblyExecutable::WebAssemblyExecutable):
(JSC::WebAssemblyExecutable::visitChildren):
* runtime/Executable.h:
* wasm/JSWasmModule.cpp: Removed.
* wasm/JSWasmModule.h: Removed.
* wasm/WasmModuleParser.cpp:
2016-10-26 Mark Lam <mark.lam@apple.com>
JSGenericTypedArrayView::set() should check for exceptions.
https://bugs.webkit.org/show_bug.cgi?id=164007
<rdar://problem/28853775>
Reviewed by Filip Pizlo.
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::set):
2016-10-25 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT] Tell IDL result type to DFG to drop type checks in AI
https://bugs.webkit.org/show_bug.cgi?id=163900
Reviewed by Sam Weinig.
The IDL tells the conservative result type. While we use the heap prediction
for prediction propagation phase in DOMJIT getter (it is offered by get_by_id!),
we leverage the type told by IDL to produce the abstract value with the proven type
in AI. It effectively drops unnecessary type checks followed by CallDOM operations.
For example, when you write the code like,
if (node.nodeType === 9) {
// document.
}
Previously, we inserted a Int32 check for the result of node.nodeType.
It is dropped now.
We annotate the DOMJIT getter in jsc.cpp to ensure that the unnecessary type checks
are correctly dropped when executing JSTests/stress/domjit-getter.js.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* domjit/DOMJITGetterSetter.h:
(JSC::DOMJIT::GetterSetter::GetterSetter):
(JSC::DOMJIT::GetterSetter::resultType):
* jsc.cpp:
(WTF::DOMJITGetter::DOMJITNodeDOMJIT::DOMJITNodeDOMJIT):
(WTF::DOMJITGetterComplex::DOMJITNodeDOMJIT::DOMJITNodeDOMJIT):
2016-10-25 Mark Lam <mark.lam@apple.com>
String.prototype.replace() should throw an OutOfMemoryError when using too much memory.
https://bugs.webkit.org/show_bug.cgi?id=163996
<rdar://problem/28263117>
Reviewed by Geoffrey Garen.
String.prototype.replace() uses a Vector internally for bookkeeping work.
Currently, if this vector gets too big, we just crash on allocation failure.
While this is correct behavior, it is not too friendly.
We now detect the imminent failure, and throw a OutOfMemoryError instead.
* runtime/StringPrototype.cpp:
(JSC::removeUsingRegExpSearch):
(JSC::replaceUsingRegExpSearch):
(JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
(JSC::stringProtoFuncReplaceUsingRegExp):
2016-10-25 Mark Lam <mark.lam@apple.com>
Rename the reject() helper function to something more meaningful.
https://bugs.webkit.org/show_bug.cgi?id=163549
Reviewed by Saam Barati.
We'll rename reject() to typeError(). The intuition behind this is that all the
clients that uses this function will return typeError(..., shouldThrow, ...).
In a sense, they are returning a "type" of TypeError (which happened to be the
value false). In addition, it may also throw a JS TypeError if the shouldThrow
parameter is true.
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/GetterSetter.cpp:
(JSC::callSetter):
* runtime/JSArray.cpp:
(JSC::JSArray::defineOwnProperty):
(JSC::JSArray::setLengthWithArrayStorage):
* runtime/JSArrayBuffer.cpp:
(JSC::JSArrayBuffer::put):
(JSC::JSArrayBuffer::defineOwnProperty):
* runtime/JSArrayBufferView.cpp:
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive):
(JSC::JSValue::putToPrimitiveByIndex):
* runtime/JSDataView.cpp:
(JSC::JSDataView::put):
(JSC::JSDataView::defineOwnProperty):
* runtime/JSFunction.cpp:
(JSC::JSFunction::put):
(JSC::JSFunction::defineOwnProperty):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
(JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
* runtime/JSObject.cpp:
(JSC::ordinarySetSlow):
(JSC::JSObject::putInlineSlow):
(JSC::JSObject::setPrototypeWithCycleCheck):
(JSC::JSObject::defineOwnIndexedProperty):
(JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
(JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
(JSC::validateAndApplyPropertyDescriptor):
* runtime/JSObjectInlines.h:
(JSC::JSObject::putInline):
* runtime/JSProxy.cpp:
(JSC::JSProxy::setPrototype):
* runtime/Lookup.h:
(JSC::putEntry):
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::defineOwnProperty):
* runtime/RegExpObject.h:
(JSC::RegExpObject::setLastIndex):
* runtime/Reject.h: Removed.
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::putEntry):
(JSC::SparseArrayValueMap::putDirect):
(JSC::SparseArrayEntry::put):
* runtime/StringObject.cpp:
(JSC::StringObject::put):
(JSC::StringObject::putByIndex):
* runtime/TypeError.h: Copied from Source/JavaScriptCore/runtime/Reject.h.
(JSC::typeError):
(JSC::reject): Deleted.
2016-10-25 Filip Pizlo <fpizlo@apple.com>
HeapTimer should not hardcode all of its subclasses and USE(CF) shouldn't be a bizarre special case
https://bugs.webkit.org/show_bug.cgi?id=163947
Reviewed by Geoffrey Garen.
I want to introduce another HeapTimer. Prior to this change, that would have meant writing
exact copies of that timer's logic for each platform that has a HeapTimer (CF, GLIB, and
EFL). That logic would in turn be a duplicate of the logic already present in
IncrementalSweeper and GCActivityCallback: all of the subclasses of HeapTimer have their
own code for scheduling timers, so a new subclass would have to duplicate that code. Then,
to add insult to injury, the USE(CF) version of HeapTimer would have to have an extra case
for that new subclass since it doesn't use virtual methods effectively.
This changes HeapTimer on USE(CF) to know to get its runloop from Heap and to use virtual
methods effectively so that it doesn't have to know about all of its subclasses.
This also moves IncrementalSweeper's code for scheduling timers into HeapTimer. This means
that future subclasses of HeapTimer could simply use that logic.
This keeps changes to GCActivityCallback to a minimum. It still has a lot of
platform-specific code and I'm not sure that this code can be trivially deduplicated since
that code has more quirks. That's fine for now, since I mainly just need a sane way of
creating new timers that use IncrementalSweeper-like scheduling logic.
* heap/EdenGCActivityCallback.cpp:
* heap/EdenGCActivityCallback.h:
* heap/FullGCActivityCallback.cpp:
* heap/FullGCActivityCallback.h:
* heap/GCActivityCallback.cpp:
(JSC::GCActivityCallback::GCActivityCallback):
* heap/GCActivityCallback.h:
* heap/Heap.cpp:
(JSC::Heap::Heap):
* heap/Heap.h:
(JSC::Heap::runLoop):
* heap/HeapTimer.cpp:
(JSC::HeapTimer::HeapTimer):
(JSC::HeapTimer::setRunLoop):
(JSC::HeapTimer::~HeapTimer):
(JSC::HeapTimer::timerDidFire):
(JSC::HeapTimer::scheduleTimer):
(JSC::HeapTimer::cancelTimer):
(JSC::retainAPILock): Deleted.
(JSC::releaseAPILock): Deleted.
* heap/HeapTimer.h:
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::scheduleTimer):
(JSC::IncrementalSweeper::cancelTimer): Deleted.
* heap/IncrementalSweeper.h:
2016-10-25 JF Bastien <jfbastien@apple.com>
Remove redundant argument count check
Indexing argument out of bounds already returns jsUndefined().
Remove redundant argument count check
https://bugs.webkit.org/show_bug.cgi?id=163957
Reviewed by Keith Miller.
* runtime/ErrorConstructor.cpp:
(JSC::Interpreter::constructWithErrorConstructor):
(JSC::Interpreter::callErrorConstructor):
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
(JSC::constructJSWebAssemblyRuntimeError):
2016-10-25 Mark Lam <mark.lam@apple.com>
Add ThrowScope::release() calls at all call sites of jsMakeNontrivialString().
https://bugs.webkit.org/show_bug.cgi?id=163990
Reviewed by Geoffrey Garen.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncToString):
* runtime/ErrorPrototype.cpp:
(JSC::errorProtoFuncToString):
* runtime/FunctionPrototype.cpp:
(JSC::functionProtoFuncToString):
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoFuncToString):
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncBig):
(JSC::stringProtoFuncSmall):
(JSC::stringProtoFuncBlink):
(JSC::stringProtoFuncBold):
(JSC::stringProtoFuncFixed):
(JSC::stringProtoFuncItalics):
(JSC::stringProtoFuncStrike):
(JSC::stringProtoFuncSub):
(JSC::stringProtoFuncSup):
(JSC::stringProtoFuncFontcolor):
(JSC::stringProtoFuncFontsize):
(JSC::stringProtoFuncAnchor):
2016-10-25 Mark Lam <mark.lam@apple.com>
JSStringJoiner::joinedLength() should limit joined string lengths to INT_MAX.
https://bugs.webkit.org/show_bug.cgi?id=163937
<rdar://problem/28642990>
Reviewed by Geoffrey Garen.
JSStringJoiner::joinedLength() was previously limiting it to UINT_MAX. This is
inconsistent with other parts of string code which expects a max length of INT_MAX.
This is now fixed.
Also fixed jsMakeNontrivialString() to ensure that the resultant string length
is valid. It was previously allowing lengths greater than INT_MAX. This was
caught by the new assertion in JSString::setLength().
There are already pre-existing assertions in various JSString::finishCreation()
which do RELEASE_ASSERTs on the string length. To be consistent, I'm making the
assertion in JSString::setLength() a RELEASE_ASSERT. If this proves to be a
performance issue, I'll change this to a debug ASSERT later.
* runtime/JSString.cpp:
(JSC::JSRopeString::resolveRopeInternal8):
(JSC::JSRopeString::resolveRopeInternal8NoSubstring):
(JSC::JSRopeString::resolveRopeInternal16):
(JSC::JSRopeString::resolveRopeInternal16NoSubstring):
(JSC::JSRopeString::resolveRopeToAtomicString):
(JSC::JSRopeString::resolveRopeToExistingAtomicString):
(JSC::JSRopeString::resolveRope):
(JSC::JSRopeString::resolveRopeSlowCase8):
(JSC::JSRopeString::resolveRopeSlowCase):
(JSC::JSString::getStringPropertyDescriptor):
* runtime/JSString.h:
(JSC::JSString::finishCreation):
(JSC::JSString::length):
(JSC::JSString::isValidLength):
(JSC::JSString::toBoolean):
(JSC::JSString::canGetIndex):
(JSC::JSString::setLength):
(JSC::JSString::getStringPropertySlot):
(JSC::JSRopeString::unsafeView):
(JSC::JSRopeString::viewWithUnderlyingString):
* runtime/JSStringBuilder.h:
(JSC::jsMakeNontrivialString):
* runtime/JSStringJoiner.cpp:
(JSC::JSStringJoiner::joinedLength):
2016-10-25 JF Bastien <jfbastien@apple.com>
WebAssembly: fix unknown section name handling, and check for section size overflow
https://bugs.webkit.org/show_bug.cgi?id=163959
See: https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md#high-level-structure
Name length and name are already included in the payload length.
Reviewed by Filip Pizlo.
* wasm/WasmModuleParser.cpp:
(JSC::Wasm::ModuleParser::parse):
2016-10-25 Christopher Reid <Christopher.Reid@am.sony.com>
jsc.cpp is leaking memory allocated by readline in runInteractive
https://bugs.webkit.org/show_bug.cgi?id=163958
According to http://web.mit.edu/gnu/doc/html/rlman_2.html,
"The line readline returns is allocated with malloc ();
you should free () the line when you are done with it."
The memory allocated by readline is not being freed when it should.
Reviewed by Mark Lam.
* jsc.cpp:
2016-10-25 Konstantin Tokarev <annulen@yandex.ru>
[cmake] Check if jscLib and WebKitGUID targets exist before using them
https://bugs.webkit.org/show_bug.cgi?id=163945
Reviewed by Alex Christensen.
Currently these targets are used under WIN32 condition, however they
are defined in PlatformWin.cmake, causing CMake warnings if port
supports WIN32 but does not use PlatformWin.cmake
* shell/CMakeLists.txt:
2016-10-25 JF Bastien <jfbastien@apple.com>
WebAssembly JS API: implement Module
This implementation allows us to:
- Syncrhonously create a WebAssembly.Module with a typed array.
- Creates a compilation plan.
- Parse the Module and creates corresponding code.
- Throw WebAssembly.CompileError with mildly helpful [*] error messages on
failure.
Consult the API documentation for expected behavior: https://github.com/WebAssembly/design/blob/master/JS.md#webassemblymodule-constructor
For now the implementation discards the generated code.
The next steps will be:
- Expose a Module's exports.
- Implement WebAssembly.Instance, which allows instantiating and running a
compiled Module.
- Beef up the testing infrastructure under JSTests/wasm so that more complex
modules can be created and tested (instead of writing the bits by hand).
This patch also:
- Adds assert.instanceof in assert.js.
- Refactors Wasm::Parser and friends to accept const uint8_t* as well as a
Vector, to avoid copying when invoked synchronously.
- Remove useless Structure from some of the wasm constructors: they're already
on the JSGlobalObject, visited properly and all.
- Fix off-by-one error in parsing: Parser::parseUInt32 failed if the integer
was exactly at end of file.
[*] On error messages while parsing: I filed https://bugs.webkit.org/show_bug.cgi?id=163919
WebAssembly JS API: implement Module
https://bugs.webkit.org/show_bug.cgi?id=163903
Reviewed by Keith Miller.
* runtime/ExceptionHelpers.cpp:
(JSC::defaultSourceAppender): make this public so that WebAssembly can use it: it generates those fancy (evaluating '...') messages at the end
* runtime/ExceptionHelpers.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init): remove the useless Structure from the WebAssembly objects (it's already in this file, no need to hold two references and visit them twice)
* testWasm.cpp:
(runWasmTests): update API
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::parseAndCompile): use updated API
* wasm/WasmB3IRGenerator.h:
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::FunctionParser): use updated API
(JSC::Wasm::FunctionParser<Context>::parseExpression): use updated API
* wasm/WasmModuleParser.cpp:
(JSC::Wasm::ModuleParser::parse): generate error messages
* wasm/WasmModuleParser.h:
(JSC::Wasm::ModuleParser::ModuleParser):
(JSC::Wasm::ModuleParser::failed):
(JSC::Wasm::ModuleParser::errorMessage):
(JSC::Wasm::ModuleParser::functionInformation):
(JSC::Wasm::ModuleParser::memory):
* wasm/WasmParser.h: use update non-public API
(JSC::Wasm::Parser::parseVarUInt32):
(JSC::Wasm::Parser::parseVarUInt64):
(JSC::Wasm::Parser::source):
(JSC::Wasm::Parser::length):
(JSC::Wasm::Parser::Parser):
(JSC::Wasm::Parser::consumeCharacter):
(JSC::Wasm::Parser::consumeString):
(JSC::Wasm::Parser::parseUInt32):
(JSC::Wasm::Parser::parseUInt7):
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::Plan):
(JSC::Wasm::Plan::~Plan):
* wasm/WasmPlan.h:
(JSC::Wasm::Plan::failed):
(JSC::Wasm::Plan::errorMessage):
(JSC::Wasm::Plan::resultSize):
(JSC::Wasm::Plan::result):
(JSC::Wasm::Plan::memory):
* wasm/js/JSWebAssemblyCompileError.cpp:
(JSC::createWebAssemblyCompileError): makes it easier to throw a WebAssembly.CompileError from Module
* wasm/js/JSWebAssemblyCompileError.h:
* wasm/js/WebAssemblyCompileErrorConstructor.cpp:
(JSC::WebAssemblyCompileErrorConstructor::create):
(JSC::WebAssemblyCompileErrorConstructor::finishCreation):
* wasm/js/WebAssemblyCompileErrorConstructor.h:
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::WebAssemblyInstanceConstructor::create):
(JSC::WebAssemblyInstanceConstructor::finishCreation):
(JSC::WebAssemblyInstanceConstructor::visitChildren):
* wasm/js/WebAssemblyInstanceConstructor.h:
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::WebAssemblyMemoryConstructor::create):
(JSC::WebAssemblyMemoryConstructor::finishCreation):
(JSC::WebAssemblyMemoryConstructor::visitChildren):
* wasm/js/WebAssemblyMemoryConstructor.h:
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::constructJSWebAssemblyModule):
(JSC::WebAssemblyModuleConstructor::create):
(JSC::WebAssemblyModuleConstructor::finishCreation):
(JSC::WebAssemblyModuleConstructor::visitChildren):
* wasm/js/WebAssemblyModuleConstructor.h:
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
(JSC::WebAssemblyRuntimeErrorConstructor::create):
(JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):
* wasm/js/WebAssemblyRuntimeErrorConstructor.h:
* wasm/js/WebAssemblyTableConstructor.cpp:
(JSC::WebAssemblyTableConstructor::create):
(JSC::WebAssemblyTableConstructor::finishCreation):
(JSC::WebAssemblyTableConstructor::visitChildren):
* wasm/js/WebAssemblyTableConstructor.h:
2016-10-25 Keith Miller <keith_miller@apple.com>
Add trivial Wasm conversion opcodes
https://bugs.webkit.org/show_bug.cgi?id=163950
Reviewed by Filip Pizlo.
This patch differentiates between Wasm opcodes that are trivially mapped to a B3 opcode and
those that are not. Some of the Wasm opcodes that are currently a non-simple opcode will
become simple as we add B3 opcodes for Wasm operations. The remaining opcodes will need to
be added via patchpoints in a later patch.
* wasm/WasmB3IRGenerator.cpp:
* wasm/WasmOps.h:
(JSC::Wasm::isSimple):
2016-10-24 Yusuke Suzuki <utatane.tea@gmail.com>
Arrow functions with concise bodies cannot return regular expressions
https://bugs.webkit.org/show_bug.cgi?id=163162
Reviewed by Filip Pizlo.
When we encounter the RegExp in the parser, we first scan it as / or /=.
And if / or /= is parsed under the primary expression context, we rescan it
as RegExp. However, we did not update the token record information. So the
token record still says "I'm / or /=".
When we parse the string "() => /hello/", the last token becomes "/", which is
the first character of the RegExp, instead of "/hello/". Since the arrow
function parsing utilizes the end offset of the last token, we accidentally
recognize the range of the above arrow function as "() => /".
In this patch, we update the token when rescanning under the RegExp context.
This logic is similar to parsing Tail Template Literal token.
We also refine the error message for regular expression literals. And since
the REGEXP token is now introduced, the other error messages using that token
are improved too.
Currently, unterminated error messages can be seen in Parser.cpp. However,
these messages cannot be shown to users if the lexer has m_error. So these
code is meaningless. I'll move these tokenizing errors to the lexer in the
subsequent patch[1].
[1]: https://bugs.webkit.org/show_bug.cgi?id=163928
* parser/Lexer.cpp:
(JSC::Lexer<T>::fillTokenInfo):
(JSC::Lexer<T>::lex):
(JSC::Lexer<T>::scanRegExp):
(JSC::Lexer<T>::scanTrailingTemplateString):
(JSC::Lexer<T>::skipRegExp): Deleted.
* parser/Lexer.h:
(JSC::Lexer::getToken):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseAssignmentExpression):
* parser/Parser.h:
(JSC::Parser::getToken):
* parser/ParserTokens.h:
2016-10-24 Per Arne Vollan <pvollan@apple.com>
[Win] CMake build type is not set.
https://bugs.webkit.org/show_bug.cgi?id=163917
Reviewed by Alex Christensen.
The CMAKE_BUILD_TYPE variable should be set to Debug or Release.
* JavaScriptCore.vcxproj/JavaScriptCore.proj:
2016-10-24 Chris Dumez <cdumez@apple.com>
Reduce special handling for typed arrays in JSDOMConvert.h
https://bugs.webkit.org/show_bug.cgi?id=163907
Reviewed by Sam Weinig.
Reduce special handling for typed arrays in JSDOMConvert.h by adding a toWrapped() static
function on JSGenericTypedArrayView, similarly to other wrapper types.
* runtime/JSGenericTypedArrayView.h:
(JSC::JSGenericTypedArrayView::typedImpl):
(JSC::JSGenericTypedArrayView<Adaptor>::toWrapped):
2016-10-24 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT][DFG] CallDOM never writes Stack
https://bugs.webkit.org/show_bug.cgi?id=163926
Reviewed by Filip Pizlo and Saam Barati.
There is no way to write(Stack) in CallDOM.
This worst case (the most clobbering case) scenario
should be aligned to the one of Call, read(World) and write(Heap).
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
2016-10-23 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT] Add a way for DOMJIT::Patchpoint to express effects
https://bugs.webkit.org/show_bug.cgi?id=163657
Reviewed by Saam Barati.
This patch introduces DOMJIT::Effect. It describes the side effects of
the DOMJIT::CallDOMPatchpoint. DOMJIT::CallDOMPatchpoint can use this
feature to teach the compilers about the effects. And the compilers
will perform CSE based on the reported effects.
As the same to B3's HeapRange, the effects are represented as a pair of
integers. [begin, end) pair will represents the range of the abstract
heap. We encode the abstract heap hierarchy into these pairs. Like,
Root: [0, 32)
Child1: [0, 20) Child2: [20, 32)
Child11: [0, 4) Child12: [4, 20)
This simplifies the representation of the abstract heap. And WebCore
just tells pairs of integers and it does not tell any detailed hierarchy.
So, DFG and FTL can optimize DOM operations without deep knowledge of
the DOM abstract heap hierarchy. For example, WebCore will tell that
firstChild will read Node_firstChild abstract heap. But this information
is encoded to the pair and DFG does not know the details. But still
DFG can understand the abstract heap hierarchy and can query whether the
given abstract heap overlaps with some abstract heap.
The heap range told by the WebCore is represented as DOMJIT::HeapRange.
DFG will handle this under the DOMState abstract heap. DOMJIT::HeapRange
is stored in DFG::AbstractHeap's Payload. We maintain the hierarchy by
DOMJIT::HeapRange in the DOMState abstract heap. We add a necessary
handling in DFG's AbstractHeap and ClobberSet.
And we also introduce DOMStateLoc for HeapLocation. It is combined with
DOMState AbstractHeap with DOMJIT::HeapRange. For example, we can
represent Node.firstChild as `read(DOMState:Node_firstChild)` and
`def(HeapLocation(node, DOMState:Node_firstChild))` thingy. This allows us
to perform CSE onto DOM getters that will read some of DOM heap!
For simplicity, we convert CallDOM from NodeVarArgs to the normal one.
CallDOM is now just used for DOMJIT getter. So its children is at most 2.
It may have either 1 or 2 children. If the global object is required
by CallDOMPatchpoint, it has 2 children. And we changed the order of
the children to further simplify the code. Before this change, the order
is 1: globalObject 2: base. After this patch, the order becomes 1: base,
and 2: globalObject. And the child2 may not exists if the global object
is not required. We changed all the existing DOMJIT patchpoint to this
form.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::emitDOMJITGetter):
* dfg/DFGAbstractHeap.cpp:
(JSC::DFG::AbstractHeap::dump):
* dfg/DFGAbstractHeap.h:
(JSC::DFG::AbstractHeap::isStrictSubtypeOf):
(JSC::DFG::AbstractHeap::overlaps):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::blessCallDOM):
(JSC::DFG::ByteCodeParser::handleDOMJITGetter):
* dfg/DFGClobberSet.cpp:
(JSC::DFG::ClobberSet::overlaps):
* dfg/DFGClobberSet.h:
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.h:
* dfg/DFGHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGHeapLocation.h:
* dfg/DFGNode.h:
(JSC::DFG::Node::hasCallDOMData):
(JSC::DFG::Node::callDOMData):
(JSC::DFG::Node::hasCallDOMPatchpoint): Deleted.
(JSC::DFG::Node::callDOMPatchpoint): Deleted.
* dfg/DFGNodeType.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCallDOM):
* domjit/DOMJITAbstractHeap.cpp: Copied from Source/JavaScriptCore/domjit/DOMJITCallDOMPatchpoint.h.
(JSC::DOMJIT::AbstractHeap::compute):
(JSC::DOMJIT::AbstractHeap::dump):
(JSC::DOMJIT::AbstractHeap::shallowDump):
(JSC::DOMJIT::AbstractHeap::deepDump):
* domjit/DOMJITAbstractHeap.h: Copied from Source/JavaScriptCore/domjit/DOMJITCallDOMPatchpoint.h.
(JSC::DOMJIT::AbstractHeap::AbstractHeap):
(JSC::DOMJIT::AbstractHeap::setParent):
(JSC::DOMJIT::AbstractHeap::isRoot):
(JSC::DOMJIT::AbstractHeap::isComputed):
(JSC::DOMJIT::AbstractHeap::range):
* domjit/DOMJITCallDOMPatchpoint.h:
* domjit/DOMJITEffect.h: Copied from Source/JavaScriptCore/domjit/DOMJITCallDOMPatchpoint.h.
(JSC::DOMJIT::Effect::forReadWrite):
(JSC::DOMJIT::Effect::forPure):
(JSC::DOMJIT::Effect::forDef):
(JSC::DOMJIT::Effect::mustGenerate):
* domjit/DOMJITHeapRange.cpp: Copied from Source/JavaScriptCore/domjit/DOMJITCallDOMPatchpoint.h.
(JSC::DOMJIT::HeapRange::dump):
* domjit/DOMJITHeapRange.h: Added.
(JSC::DOMJIT::HeapRange::HeapRange):
(JSC::DOMJIT::HeapRange::fromRaw):
(JSC::DOMJIT::HeapRange::begin):
(JSC::DOMJIT::HeapRange::end):
(JSC::DOMJIT::HeapRange::rawRepresentation):
(JSC::DOMJIT::HeapRange::operator bool):
(JSC::DOMJIT::HeapRange::operator==):
(JSC::DOMJIT::HeapRange::top):
(JSC::DOMJIT::HeapRange::none):
(JSC::DOMJIT::HeapRange::isStrictSubtypeOf):
(JSC::DOMJIT::HeapRange::isSubtypeOf):
(JSC::DOMJIT::HeapRange::overlaps):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
* jsc.cpp:
2016-10-24 Alex Christensen <achristensen@webkit.org>
JSONParse should not crash with null Strings
https://bugs.webkit.org/show_bug.cgi?id=163918
<rdar://problem/28834095>
Reviewed by Michael Saboff.
When JSONParse is called with a null String, it calls String::is8bit, which dereferences a null pointer.
This is happening with new work in the Fetch API, but callers of JSONParse should not have to check
if the String is null.
* API/tests/JSONParseTest.cpp: Added.
(testJSONParse):
* API/tests/JSONParseTest.h: Added.
* API/tests/testapi.c:
(main):
Test parsing null Strings. They should have the same result as parsing empty Strings.
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/JSONObject.cpp:
(JSC::JSONParse):
Check for null Strings.
* shell/PlatformWin.cmake:
2016-10-24 Devin Rousso <dcrousso+webkit@gmail.com>
Web Inspector: Scope chain shouldn't show empty Closure sections
https://bugs.webkit.org/show_bug.cgi?id=152348
Reviewed by Joseph Pecoraro.
* inspector/InjectedScriptSource.js:
(isEmptyObject):
(InjectedScript.CallFrameProxy._createScopeJson):
If the scope object has no properties, set empty to true.
* inspector/protocol/Debugger.json:
Added empty property to Scope type.
2016-10-24 Keith Miller <keith_miller@apple.com>
Wasm should support floating point operations.
https://bugs.webkit.org/show_bug.cgi?id=163770
Reviewed by Michael Saboff.
Since we now have a Double => Float Trunc in B3, we can now support calls in Wasm
that take floating point arguments. This patch also enables most of the Wasm
floating point operations, as the associated B3 opcode has been linked via wasm.json.
If there is no direct mapping to a B3 opcode the Wasm is not yet implemented. This
patch also fixes a bug in calls where the arguments would be reversed.
* testWasm.cpp:
(cast):
(invoke):
(boxf):
(boxd):
(runWasmTests):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::createJSWrapper):
* wasm/WasmCallingConvention.h:
(JSC::Wasm::CallingConvention::loadArguments):
(JSC::Wasm::CallingConvention::setupCall):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
(JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
* wasm/WasmOps.h:
2016-10-24 Mark Lam <mark.lam@apple.com>
Dumping of op_negate bytecode is broken.
https://bugs.webkit.org/show_bug.cgi?id=163896
Reviewed by Darin Adler.
It thinks the bytecode consists of only 3 machine words, when it consists of 4.
This is now fixed.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
2016-10-24 Youenn Fablet <youenn@apple.com>
Activate WEB_RTC compilation flags for Mac bots
https://bugs.webkit.org/show_bug.cgi?id=163886
Reviewed by Eric Carlson.
* Configurations/FeatureDefines.xcconfig:
2016-10-23 Zan Dobersek <zdobersek@igalia.com>
Unreviewed. Build fix for Clang and libstdc++ configurations.
* b3/testb3.cpp:
(JSC::B3::testAbsArgWithEffectfulDoubleConversion): Explicitly cast the
float-typed return value of fabs(float) to double in order to avoid
ambiguous calls to isIdentical().
(JSC::B3::testSqrtArgWithEffectfulDoubleConversion): Ditto for sqrt(float).
2016-10-22 Chris Dumez <cdumez@apple.com>
WebGLRenderingContextBase.bufferData() should use a union instead of overloading
https://bugs.webkit.org/show_bug.cgi?id=163795
Reviewed by Darin Adler.
* runtime/ArrayBufferView.h:
(JSC::ArrayBufferView::data):
Add a data() method which aliases baseAddress() to align the API with
ArrayBuffer and reduce special handling at call sites.
* runtime/JSArrayBuffer.h:
(JSC::toArrayBuffer):
(JSC::JSArrayBuffer::toWrapped):
Add toWrapped() method similarly with WebCore wrapper types to
reduce special handling of JSArrayBuffer type.
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::toWrapped):
* runtime/JSArrayBufferView.h:
Add toWrapped() method similarly with WebCore wrapper types to
reduce special handling of JSArrayBufferView type.
2016-10-21 Filip Pizlo <fpizlo@apple.com>
Slow and big Heap methods should not be inline
https://bugs.webkit.org/show_bug.cgi?id=163802
Reviewed by Keith Miller.
JSC often suffers from the inline cargo cult, and Heap is a prime example. This outlines a
bunch of Heap methods that are either already very big, or call out-of-line methods, or call
very big methods, or are not called often enough for inlining to matter.
This simplifies concurrent GC work because I'm so tired of recompiling the world when I touch
one of these methods.
This looks to be perf-neutral.
* heap/Heap.cpp:
(JSC::Heap::shouldCollect):
(JSC::Heap::isCurrentThreadBusy):
(JSC::Heap::reportExtraMemoryVisited):
(JSC::Heap::reportExternalMemoryVisited):
(JSC::Heap::collectIfNecessaryOrDefer):
(JSC::Heap::collectAccordingToDeferGCProbability):
(JSC::Heap::decrementDeferralDepthAndGCIfNeeded):
(JSC::Heap::registerWeakGCMap):
(JSC::Heap::unregisterWeakGCMap):
(JSC::Heap::didAllocateBlock):
(JSC::Heap::didFreeBlock):
* heap/HeapInlines.h:
(JSC::Heap::shouldCollect): Deleted.
(JSC::Heap::isCurrentThreadBusy): Deleted.
(JSC::Heap::reportExtraMemoryVisited): Deleted.
(JSC::Heap::reportExternalMemoryVisited): Deleted.
(JSC::Heap::collectIfNecessaryOrDefer): Deleted.
(JSC::Heap::collectAccordingToDeferGCProbability): Deleted.
(JSC::Heap::decrementDeferralDepthAndGCIfNeeded): Deleted.
(JSC::Heap::registerWeakGCMap): Deleted.
(JSC::Heap::unregisterWeakGCMap): Deleted.
(JSC::Heap::didAllocateBlock): Deleted.
(JSC::Heap::didFreeBlock): Deleted.
2016-10-21 Saam Barati <sbarati@apple.com>
SpeculativeJIT::compileTryGetById needs to pass in NeedsToSpill along both the cell speculation and untyped speculation path
https://bugs.webkit.org/show_bug.cgi?id=163622
Reviewed by Yusuke Suzuki.
We were passing in DontSpill in the Untyped:child1() case, which caused us
not to spill the base register. This is obviously wrong because the
DFG's register allocator expected the base to still be in the register
that it allocated for it after the TryGetById node executed.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileTryGetById):
2016-10-21 Keith Miller <keith_miller@apple.com>
Expand Trunc in B3 to support Double to Float
https://bugs.webkit.org/show_bug.cgi?id=163809
Reviewed by Geoffrey Garen.
This feature is useful for passing floating point arguments via registers.
Currently, ArgumentRegValue returns a the full 64-bit register. Thus, we
need a way to indicate to B3 that we only want the low 32-bits.
* b3/B3Common.h:
(JSC::B3::isIdentical):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Opcode.h:
* b3/B3ReduceStrength.cpp:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::typeFor):
* b3/testb3.cpp:
(JSC::B3::testAddFPRArgsFloat):
(JSC::B3::testCeilArgWithEffectfulDoubleConversion):
(JSC::B3::testFloorArgWithEffectfulDoubleConversion):
(JSC::B3::testDoubleProducerPhiToFloatConversionWithDoubleConsumer):
(JSC::B3::run):
2016-10-21 Keith Miller <keith_miller@apple.com>
Rename WASM to Wasm
https://bugs.webkit.org/show_bug.cgi?id=163796
Rubber stamped by Filip Pizlo.
* CMakeLists.txt:
* Configurations/ToolExecutable.xcconfig:
* JavaScriptCore.xcodeproj/project.pbxproj:
* llint/LLIntThunks.cpp:
(JSC::vmEntryToWasm):
(JSC::vmEntryToWASM): Deleted.
* llint/LLIntThunks.h:
* runtime/Executable.cpp:
(JSC::WebAssemblyExecutable::WebAssemblyExecutable):
* runtime/Executable.h:
* shell/CMakeLists.txt:
* testWASM.cpp:
(runWASMTests): Deleted.
* testWasm.cpp: Renamed from Source/JavaScriptCore/testWASM.cpp.
(CommandLine::CommandLine):
(printUsageStatement):
(CommandLine::parseArguments):
(runLEBTests):
(invoke):
(box):
(runWasmTests):
(main):
* wasm/JSWASMModule.cpp:
(JSC::JSWASMModule::JSWASMModule): Deleted.
(JSC::JSWASMModule::destroy): Deleted.
(JSC::JSWASMModule::visitChildren): Deleted.
* wasm/JSWASMModule.h:
(JSC::JSWASMModule::create): Deleted.
(JSC::JSWASMModule::createStructure): Deleted.
(JSC::JSWASMModule::i32Constants): Deleted.
(JSC::JSWASMModule::f32Constants): Deleted.
(JSC::JSWASMModule::f64Constants): Deleted.
(JSC::JSWASMModule::signatures): Deleted.
(JSC::JSWASMModule::functionImports): Deleted.
(JSC::JSWASMModule::functionImportSignatures): Deleted.
(JSC::JSWASMModule::globalVariableTypes): Deleted.
(JSC::JSWASMModule::functionDeclarations): Deleted.
(JSC::JSWASMModule::functionPointerTables): Deleted.
(JSC::JSWASMModule::arrayBuffer): Deleted.
(JSC::JSWASMModule::functions): Deleted.
(JSC::JSWASMModule::functionStartOffsetsInSource): Deleted.
(JSC::JSWASMModule::functionStackHeights): Deleted.
(JSC::JSWASMModule::globalVariables): Deleted.
(JSC::JSWASMModule::importedFunctions): Deleted.
* wasm/JSWasmModule.cpp: Renamed from Source/JavaScriptCore/wasm/JSWASMModule.cpp.
(JSC::JSWasmModule::JSWasmModule):
(JSC::JSWasmModule::destroy):
(JSC::JSWasmModule::visitChildren):
* wasm/JSWasmModule.h: Renamed from Source/JavaScriptCore/wasm/JSWASMModule.h.
(JSC::JSWasmModule::create):
(JSC::JSWasmModule::createStructure):
(JSC::JSWasmModule::i32Constants):
(JSC::JSWasmModule::f32Constants):
(JSC::JSWasmModule::f64Constants):
(JSC::JSWasmModule::signatures):
(JSC::JSWasmModule::functionImports):
(JSC::JSWasmModule::functionImportSignatures):
(JSC::JSWasmModule::globalVariableTypes):
(JSC::JSWasmModule::functionDeclarations):
(JSC::JSWasmModule::functionPointerTables):
(JSC::JSWasmModule::arrayBuffer):
(JSC::JSWasmModule::functions):
(JSC::JSWasmModule::functionStartOffsetsInSource):
(JSC::JSWasmModule::functionStackHeights):
(JSC::JSWasmModule::globalVariables):
(JSC::JSWasmModule::importedFunctions):
* wasm/WASMB3IRGenerator.cpp:
(JSC::WASM::createJSWrapper): Deleted.
(JSC::WASM::parseAndCompile): Deleted.
* wasm/WASMCallingConvention.cpp:
(JSC::WASM::jscCallingConvention): Deleted.
(JSC::WASM::wasmCallingConvention): Deleted.
* wasm/WASMCallingConvention.h:
(JSC::WASM::CallingConvention::CallingConvention): Deleted.
(JSC::WASM::CallingConvention::marshallArgumentImpl): Deleted.
(JSC::WASM::CallingConvention::marshallArgument): Deleted.
(JSC::WASM::CallingConvention::loadArguments): Deleted.
(JSC::WASM::CallingConvention::setupCall): Deleted.
(JSC::WASM::nextJSCOffset): Deleted.
* wasm/WASMFormat.h:
(JSC::WASM::toB3Type): Deleted.
(JSC::WASM::isValueType): Deleted.
* wasm/WASMFunctionParser.h:
(JSC::WASM::FunctionParser<Context>::FunctionParser): Deleted.
(JSC::WASM::FunctionParser<Context>::parse): Deleted.
(JSC::WASM::FunctionParser<Context>::parseBlock): Deleted.
(JSC::WASM::FunctionParser<Context>::parseExpression): Deleted.
(JSC::WASM::FunctionParser<Context>::parseUnreachableExpression): Deleted.
* wasm/WASMMemory.cpp:
(JSC::WASM::Memory::Memory): Deleted.
* wasm/WASMMemory.h:
(JSC::WASM::Memory::~Memory): Deleted.
(JSC::WASM::Memory::memory): Deleted.
(JSC::WASM::Memory::size): Deleted.
(JSC::WASM::Memory::pinnedRegisters): Deleted.
(JSC::WASM::Memory::mode): Deleted.
(JSC::WASM::Memory::grow): Deleted.
(JSC::WASM::Memory::offsetOfSize): Deleted.
* wasm/WASMModuleParser.cpp:
(JSC::WASM::ModuleParser::parse): Deleted.
(JSC::WASM::ModuleParser::parseMemory): Deleted.
(JSC::WASM::ModuleParser::parseFunctionTypes): Deleted.
(JSC::WASM::ModuleParser::parseFunctionSignatures): Deleted.
(JSC::WASM::ModuleParser::parseFunctionDefinitions): Deleted.
* wasm/WASMModuleParser.h:
(JSC::WASM::ModuleParser::ModuleParser): Deleted.
(JSC::WASM::ModuleParser::functionInformation): Deleted.
(JSC::WASM::ModuleParser::memory): Deleted.
* wasm/WASMOps.h:
(JSC::WASM::isValidOpType): Deleted.
(JSC::WASM::isControlOp): Deleted.
* wasm/WASMParser.h:
(JSC::WASM::Parser::parseVarUInt32): Deleted.
(JSC::WASM::Parser::parseVarUInt64): Deleted.
(JSC::WASM::Parser::Parser): Deleted.
(JSC::WASM::Parser::consumeCharacter): Deleted.
(JSC::WASM::Parser::consumeString): Deleted.
(JSC::WASM::Parser::parseUInt32): Deleted.
(JSC::WASM::Parser::parseUInt7): Deleted.
(JSC::WASM::Parser::parseVarUInt1): Deleted.
(JSC::WASM::Parser::parseValueType): Deleted.
* wasm/WASMPlan.cpp:
(JSC::WASM::Plan::Plan): Deleted.
* wasm/WASMSections.h:
(JSC::WASM::Sections::validateOrder): Deleted.
* wasm/WasmB3IRGenerator.cpp: Renamed from Source/JavaScriptCore/wasm/WASMB3IRGenerator.cpp.
(dumpProcedure):
(JSC::Wasm::createJSWrapper):
(JSC::Wasm::parseAndCompile):
* wasm/WasmB3IRGenerator.h: Renamed from Source/JavaScriptCore/wasm/WASMB3IRGenerator.h.
* wasm/WasmCallingConvention.cpp: Renamed from Source/JavaScriptCore/wasm/WASMCallingConvention.cpp.
(JSC::Wasm::jscCallingConvention):
(JSC::Wasm::wasmCallingConvention):
* wasm/WasmCallingConvention.h: Renamed from Source/JavaScriptCore/wasm/WASMCallingConvention.h.
(JSC::Wasm::CallingConvention::CallingConvention):
(JSC::Wasm::CallingConvention::marshallArgumentImpl):
(JSC::Wasm::CallingConvention::marshallArgument):
(JSC::Wasm::CallingConvention::loadArguments):
(JSC::Wasm::CallingConvention::setupCall):
(JSC::Wasm::nextJSCOffset):
* wasm/WasmFormat.h: Renamed from Source/JavaScriptCore/wasm/WASMFormat.h.
(JSC::Wasm::toB3Type):
(JSC::Wasm::isValueType):
* wasm/WasmFunctionParser.h: Renamed from Source/JavaScriptCore/wasm/WASMFunctionParser.h.
(JSC::Wasm::FunctionParser<Context>::FunctionParser):
(JSC::Wasm::FunctionParser<Context>::parse):
(JSC::Wasm::FunctionParser<Context>::parseBlock):
(JSC::Wasm::FunctionParser<Context>::parseExpression):
(JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
* wasm/WasmMemory.cpp: Renamed from Source/JavaScriptCore/wasm/WASMMemory.cpp.
(JSC::Wasm::Memory::Memory):
* wasm/WasmMemory.h: Renamed from Source/JavaScriptCore/wasm/WASMMemory.h.
(JSC::Wasm::Memory::~Memory):
(JSC::Wasm::Memory::memory):
(JSC::Wasm::Memory::size):
(JSC::Wasm::Memory::pinnedRegisters):
(JSC::Wasm::Memory::mode):
(JSC::Wasm::Memory::grow):
(JSC::Wasm::Memory::offsetOfSize):
* wasm/WasmModuleParser.cpp: Renamed from Source/JavaScriptCore/wasm/WASMModuleParser.cpp.
(JSC::Wasm::ModuleParser::parse):
(JSC::Wasm::ModuleParser::parseMemory):
(JSC::Wasm::ModuleParser::parseFunctionTypes):
(JSC::Wasm::ModuleParser::parseFunctionSignatures):
(JSC::Wasm::ModuleParser::parseFunctionDefinitions):
* wasm/WasmModuleParser.h: Renamed from Source/JavaScriptCore/wasm/WASMModuleParser.h.
(JSC::Wasm::ModuleParser::ModuleParser):
(JSC::Wasm::ModuleParser::functionInformation):
(JSC::Wasm::ModuleParser::memory):
* wasm/WasmOps.h: Renamed from Source/JavaScriptCore/wasm/WASMOps.h.
(JSC::Wasm::isValidOpType):
(JSC::Wasm::isControlOp):
* wasm/WasmParser.h: Renamed from Source/JavaScriptCore/wasm/WASMParser.h.
(JSC::Wasm::Parser::parseVarUInt32):
(JSC::Wasm::Parser::parseVarUInt64):
(JSC::Wasm::Parser::Parser):
(JSC::Wasm::Parser::consumeCharacter):
(JSC::Wasm::Parser::consumeString):
(JSC::Wasm::Parser::parseUInt32):
(JSC::Wasm::Parser::parseUInt7):
(JSC::Wasm::Parser::parseVarUInt1):
(JSC::Wasm::Parser::parseValueType):
* wasm/WasmPlan.cpp: Renamed from Source/JavaScriptCore/wasm/WASMPlan.cpp.
(JSC::Wasm::Plan::Plan):
* wasm/WasmPlan.h: Renamed from Source/JavaScriptCore/wasm/WASMPlan.h.
* wasm/WasmSections.h: Renamed from Source/JavaScriptCore/wasm/WASMSections.h.
(JSC::Wasm::Sections::validateOrder):
2016-10-21 Caitlin Potter <caitp@igalia.com>
[JSC] don't crash when arguments to `new Function()` produce unexpected AST
https://bugs.webkit.org/show_bug.cgi?id=163748
Reviewed by Mark Lam.
The ASSERT(statement); and ASSERT(funcDecl); lines are removed, replaced with blocks
to report a generic Parser error message. These lines are only possible to be reached
if the input string produced an unexpected AST, which previously could be used to crash
the process via ASSERT failure.
The node type assertions are left in the tree, as it should be impossible for a top-level
`{` to produce anything other than a Block node. If the node turns out not to be a Block,
it indicates that the (C++) caller of this function (E.g in FunctionConstructor.cpp), is
doing something incorrect. Similarly, it should be impossible for the `funcDecl` node to
be anything other than a function declaration given the conventions of the caller of this
function.
* runtime/CodeCache.cpp:
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
2016-10-20 Keith Miller <keith_miller@apple.com>
Add support for WASM calls
https://bugs.webkit.org/show_bug.cgi?id=161727
Reviewed by Filip Pizlo and Michael Saboff.
Add support for WASM calls. Since most of the work for this was already done when we added
WASM Memory, this is mostly just cleanup work. The main interesting part of this patch is
how we link calls to other WASM functions in the same module. Since a WASM callee may not
have been compiled by the time the current function has started compilation we don't know
what address we need to call to. For each callsite in the compiling function, WASM
remembers the CodeLocationCall and the target function index. Once all WASM functions are
compiled, each callsite is linked to the appropriate entrypoint.
* testWASM.cpp:
(runWASMTests):
* wasm/WASMB3IRGenerator.cpp:
(JSC::WASM::createJSWrapper):
(JSC::WASM::parseAndCompile):
* wasm/WASMB3IRGenerator.h:
* wasm/WASMCallingConvention.cpp:
(JSC::WASM::jscCallingConvention):
(JSC::WASM::wasmCallingConvention):
* wasm/WASMCallingConvention.h:
(JSC::WASM::CallingConvention::CallingConvention):
(JSC::WASM::CallingConvention::marshallArgumentImpl):
(JSC::WASM::CallingConvention::marshallArgument):
(JSC::WASM::CallingConvention::loadArguments):
(JSC::WASM::CallingConvention::setupCall):
(JSC::WASM::CallingConvention::iterate): Deleted.
* wasm/WASMFormat.h:
* wasm/WASMFunctionParser.h:
(JSC::WASM::FunctionParser<Context>::FunctionParser):
(JSC::WASM::FunctionParser<Context>::parseBlock):
(JSC::WASM::FunctionParser<Context>::parseExpression):
* wasm/WASMModuleParser.cpp:
(JSC::WASM::ModuleParser::parse):
* wasm/WASMOps.h:
* wasm/WASMParser.h:
(JSC::WASM::Parser::parseVarUInt32):
(JSC::WASM::Parser::parseVarUInt64):
* wasm/WASMPlan.cpp:
(JSC::WASM::Plan::Plan):
2016-10-21 Wenson Hsieh <wenson_hsieh@apple.com>
Implement InputEvent.getTargetRanges() for the input events spec
https://bugs.webkit.org/show_bug.cgi?id=162947
<rdar://problem/28853079>
Reviewed by Darin Adler.
Boilerplate change to add a runtime guard for InputEvents-related IDL interfaces. See WebCore ChangeLog entry
for more details.
* runtime/CommonIdentifiers.h:
2016-10-20 Zan Dobersek <zdobersek@igalia.com>
Fix JSC cast-align compiler warnings on ARMv7
https://bugs.webkit.org/show_bug.cgi?id=163744
Reviewed by Mark Lam.
Use the reinterpret_cast_ptr workaround in a few places where
the cast alignment warning is being thrown by the GCC compiler
when compiling for the ARMv7 architecture.
* heap/Heap.cpp:
(JSC::Zombify::visit):
* heap/HeapCell.h:
(JSC::HeapCell::zap):
(JSC::HeapCell::isZapped):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::specializedSweep):
2016-10-20 Filip Pizlo <fpizlo@apple.com>
The tracking of the coarse-grain Heap state (allocating or not, collector or not, eden vs full) should respect the orthogonality between allocating and collecting
https://bugs.webkit.org/show_bug.cgi?id=163738
Reviewed by Geoffrey Garen.
We need to know if we're currently in an allocation slow path, so that code can assert that
it's not being used from inside a destructor that runs during a sweep. We need to know if
we're currently collecting, because some code behaves differently during collection, and
other code wants to assert that it's not being used from inside a visitChildren method that
runs during marking. If we are collecting, we need to know if it's an eden collection or a
full collection. If we are requesting a collection, we need to know if we're requesting an
eden collection, a full collection, or any kind of collection.
Prior to this change, you would reason about all of these things using the HeapOperation. It
had the following states: NoOperation, Allocation, FullCollection, EdenCollection, and
AnyCollection. NoOperation versus Allocation was primarily for asserting that sweep didn't
call arbitrary JS. FullCollection versus EdenCollection was about describing generations. We
would even use HeapOperation in places where we knew that it could only be either Full or
Eden, because we just needed a variable to tell us which generation we were talking about.
It was all very confusing.
Where it completely breaks down is the fact that a concurrent GC has two logical threads, the
mutator and the collector, which can change state independently. The mutator can be
allocating. It can also be doing some work to help the GC. That's three states: running,
allocating, or helping GC. At the same time, the GC thread could either be running or not,
and if it's running, it could be a full collection or an eden collection. Because the mutator
and collector can run at the same time, it means that if we used one enum, we would need nine
states: every combination of mutator running, allocating, or helping GC, crossed with
collector not running, running eden, or running full. So, this change decouples mutator state
from collector state and uses two separate fields with two different types.
Mutator state is described using MutatorState, which can be either MutatorState::Running,
MutatorState::Allocating, or MutatorState::HelpingGC.
Collector state is described using Optional<CollectionScope>. CollectionScope describes how
big the scope of the collection is, and it can be either CollectionScope::Eden or
CollectionScope::Full. If the Optional is Nullopt, it means that we are not collecting. This
way, you can treat collectionScope as a boolean (an Optional is true iff it's engaged). You
can pass around just a CollectionScope if you know that you must be collecting and you just
want to know about the generation. Also, we can use Nullopt in methods that request
collection, which those methods take to mean that they can run any kind of collection (the
old AnyCollection).
Another use of HeapOperation was to answer questions about whether the caller is running as
part of the GC or as part of the mutator. Optional<CollectionScope> does not answer this,
since code that runs in the mutator while the mutator is not HelpingGC at the same time as
the collector is running should run as if it was part of the mutator not as if it was part of
the GC. MutatorState is needed to answer this question, but it doesn't tell the whole story
since code that runs in the collector thread at the same time as the mutator is running
should run as if it was part of the GC not as if it was part of the mutator. So, we need to
know if we're on the collector thread or the mutator thread. We already have a WTF facility
for this, which answers if a thread is a GC thread. But we already use this to answer a
stronger question: are we part of the parallel GC helpers? Some functions in the GC, like
mark bit queries, will work fine in a concurrent collector thread so long as there is no
parallel marking. So, this change also changes WTF's mayBeGCThread to tell what kind of GC
thread we may be: either GCThreadType::Main or GCThreadType::Helper. The parallel GC safety
checks look for GCThreadType::Helper. The "should I run as mutator" query can now be answered
by checking with mayBeGCThread, which returns Optional<GCThreadType>; if engaged, then run as
GC, else run as GC if MutatorState is HelpingGC, else run as mutator.
This doesn't change the way that the GC behaves, but it does change how the GC represents a
fundamental piece of state. So, it's a big change. It should be perf-neutral (still testing).
* API/JSBase.cpp:
(JSSynchronousEdenCollectForDebugging):
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::jettison):
* dfg/DFGWorklist.cpp:
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* heap/AllocatingScope.h: Added.
(JSC::AllocatingScope::AllocatingScope):
(JSC::AllocatingScope::~AllocatingScope):
* heap/AllocationScope.h: Removed.
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
* heap/CodeBlockSet.h:
* heap/CollectionScope.cpp: Added.
(JSC::collectionScopeName):
(WTF::printInternal):
* heap/CollectionScope.h: Added.
* heap/EdenGCActivityCallback.cpp:
(JSC::EdenGCActivityCallback::doCollection):
* heap/FullGCActivityCallback.cpp:
(JSC::FullGCActivityCallback::doCollection):
* heap/GCTypeMap.h:
(JSC::GCTypeMap::operator[]):
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::markRoots):
(JSC::Heap::beginMarking):
(JSC::Heap::visitSmallStrings):
(JSC::Heap::updateObjectCounts):
(JSC::Heap::deleteAllCodeBlocks):
(JSC::Heap::deleteUnmarkedCompiledCode):
(JSC::Heap::collectAllGarbage):
(JSC::Heap::collect):
(JSC::Heap::collectWithoutAnySweep):
(JSC::Heap::collectImpl):
(JSC::Heap::willStartCollection):
(JSC::Heap::flushWriteBarrierBuffer):
(JSC::Heap::pruneStaleEntriesFromWeakGCMaps):
(JSC::Heap::notifyIncrementalSweeper):
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::didFinishCollection):
(JSC::Heap::isValidAllocation):
(JSC::Heap::shouldDoFullCollection):
* heap/Heap.h:
(JSC::Heap::mutatorState):
(JSC::Heap::collectionScope):
(JSC::Heap::operationInProgress): Deleted.
* heap/HeapInlines.h:
(JSC::Heap::shouldCollect):
(JSC::Heap::isCurrentThreadBusy):
(JSC::Heap::isMarked):
(JSC::Heap::reportExtraMemoryVisited):
(JSC::Heap::reportExternalMemoryVisited):
(JSC::Heap::collectAccordingToDeferGCProbability):
(JSC::Heap::isBusy): Deleted.
(JSC::Heap::isCollecting): Deleted.
* heap/HeapObserver.h:
* heap/HeapOperation.cpp: Removed.
* heap/HeapOperation.h: Removed.
* heap/HeapVerifier.cpp:
(JSC::HeapVerifier::initializeGCCycle):
(JSC::HeapVerifier::reportObject):
(JSC::HeapVerifier::collectionTypeName): Deleted.
* heap/HeapVerifier.h:
(JSC::HeapVerifier::GCCycle::collectionTypeName): Deleted.
* heap/HelpingGCScope.h: Added.
(JSC::HelpingGCScope::HelpingGCScope):
(JSC::HelpingGCScope::~HelpingGCScope):
* heap/LargeAllocation.cpp:
(JSC::LargeAllocation::flip):
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::doTestCollectionsIfNeeded):
(JSC::MarkedAllocator::allocateSlowCaseImpl):
* heap/MarkedBlock.h:
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::prepareForAllocation):
(JSC::MarkedSpace::visitWeakSets):
(JSC::MarkedSpace::reapWeakSets):
(JSC::MarkedSpace::prepareForMarking):
(JSC::MarkedSpace::beginMarking):
(JSC::MarkedSpace::snapshotUnswept):
* heap/MutatorState.cpp: Added.
(WTF::printInternal):
* heap/MutatorState.h: Added.
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::didStartMarking):
* inspector/agents/InspectorHeapAgent.cpp:
(Inspector::protocolTypeForHeapOperation):
(Inspector::InspectorHeapAgent::didGarbageCollect):
* inspector/agents/InspectorHeapAgent.h:
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
(JSC::Interpreter::prepareForRepeatCall):
* jsc.cpp:
(functionFullGC):
(functionEdenGC):
* runtime/Completion.cpp:
(JSC::evaluate):
(JSC::loadAndEvaluateModule):
(JSC::loadModule):
(JSC::linkAndEvaluateModule):
* runtime/JSLock.cpp:
(JSC::JSLock::DropAllLocks::DropAllLocks):
* runtime/SmallStrings.h:
(JSC::SmallStrings::needsToBeVisited):
* runtime/VM.h:
(JSC::VM::isCollectorBusyOnCurrentThread):
(JSC::VM::isCollectorBusy): Deleted.
* tools/JSDollarVMPrototype.cpp:
(JSC::JSDollarVMPrototype::edenGC):
2016-10-20 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Drop isEnvironmentRecord type info flag and use JSType information instead
https://bugs.webkit.org/show_bug.cgi?id=163761
Reviewed by Keith Miller.
When we call a function in the following form,
var charAt = String.prototype.charAt;
charAt(); // |this| becomes the global object.
we should see |this| as undefined/null. In StringPrototype.cpp,
we use IsEnvironmentRecord type info flag to check whther the
given |this| is an environment record.
However, type info flag is precious thing and only StringPrototype.cpp
uses IsEnvironmentRecord. In addition to that, JSType should
already knows whether the given object is an environment record.
So IsEnvironmentRecord type info flag should be dropped.
This patch adds a new JSType, StrictEvalActivation. And we add a new
method JSObject::isEnvironmentRecord(). This method uses JSType to
return the result. And we drop IsEnvironmentRecord type info flag.
This patch makes a room for putting one bit flag to the out of line
type info flag. Previously, it is already exhausted.
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LowLevelInterpreter.asm:
* runtime/JSObject.h:
(JSC::JSObject::isStrictEvalActivation):
(JSC::JSObject::isEnvironmentRecord):
* runtime/JSSymbolTableObject.h:
* runtime/JSType.h:
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::newImpurePropertyFiresWatchpoints):
(JSC::TypeInfo::isEnvironmentRecord): Deleted.
* runtime/StrictEvalActivation.h:
(JSC::StrictEvalActivation::createStructure):
* runtime/StringPrototype.cpp:
(JSC::checkObjectCoercible):
2016-10-20 JF Bastien <jfbastien@apple.com>
WebAssembly API: implement exception constructors properly
- Rename WebAssemblyObject to JSWebAssembly for consistency.
- WebAssembly object now has its own prototype: add WebAssemblyPrototype, and
use it to register JSWebAssembly's function properties through auto-generated
.lut.h, instead of manually.
- The error constructors used to throw (e.g. `new WebAssembly.CompileError()`).
- Register WebAssembly's constructors from the global object, and hold a
reference to their structure and prototype so that invoking the constructor
can use the structure directly from the global object.
- Add a prototype base field to global object creation. Previous ones all had
Object's prototype as their base, but WebAssembly's error constructors have
Error as their base.
- Test for the error object's correctness.
- Add missing #if ENABLE(WEBASSEMBLY)
WebAssembly API: implement exception constructors properly
https://bugs.webkit.org/show_bug.cgi?id=163699
Reviewed by Keith Miller.
* CMakeLists.txt: rename WebAssemblyObject -> JSWebAssembly; add a .lut.h file
* DerivedSources.make: new .lut.h file
* JavaScriptCore.xcodeproj/project.pbxproj: ditto
* runtime/JSGlobalObject.cpp: new prototypeBase macro
(JSC::JSGlobalObject::init): register WebAssembly constructors here
(JSC::JSGlobalObject::visitChildren): use the macro to visit
* runtime/JSGlobalObject.h: declare the WebAssembly constructor macro
* wasm/JSWebAssembly.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::JSWebAssembly::create):
(JSC::JSWebAssembly::createStructure):
(JSC::JSWebAssembly::finishCreation):
(JSC::JSWebAssembly::JSWebAssembly):
* wasm/JSWebAssembly.h: Renamed from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
* wasm/WebAssemblyObject.cpp: Removed.
* wasm/js/JSWebAssemblyCompileError.cpp:
* wasm/js/JSWebAssemblyCompileError.h:
(JSC::JSWebAssemblyCompileError::create): string convenience
* wasm/js/JSWebAssemblyInstance.cpp:
* wasm/js/JSWebAssemblyInstance.h:
* wasm/js/JSWebAssemblyMemory.cpp:
* wasm/js/JSWebAssemblyMemory.h:
* wasm/js/JSWebAssemblyModule.cpp:
* wasm/js/JSWebAssemblyModule.h:
* wasm/js/JSWebAssemblyRuntimeError.cpp:
* wasm/js/JSWebAssemblyRuntimeError.h:
(JSC::JSWebAssemblyRuntimeError::create): string convenience
* wasm/js/JSWebAssemblyTable.cpp:
* wasm/js/JSWebAssemblyTable.h:
* wasm/js/WebAssemblyCompileErrorConstructor.cpp:
(JSC::constructJSWebAssemblyCompileError):don't throw, create the object
(JSC::WebAssemblyCompileErrorConstructor::finishCreation):no need for the structure, it's on the global object
* wasm/js/WebAssemblyCompileErrorConstructor.h:
* wasm/js/WebAssemblyCompileErrorPrototype.cpp:
* wasm/js/WebAssemblyCompileErrorPrototype.h:
* wasm/js/WebAssemblyInstanceConstructor.cpp:
* wasm/js/WebAssemblyInstanceConstructor.h:
* wasm/js/WebAssemblyInstancePrototype.cpp:
* wasm/js/WebAssemblyInstancePrototype.h:
* wasm/js/WebAssemblyMemoryConstructor.cpp:
* wasm/js/WebAssemblyMemoryConstructor.h:
* wasm/js/WebAssemblyMemoryPrototype.cpp:
* wasm/js/WebAssemblyMemoryPrototype.h:
* wasm/js/WebAssemblyModuleConstructor.cpp:
* wasm/js/WebAssemblyModuleConstructor.h:
* wasm/js/WebAssemblyModulePrototype.cpp:
* wasm/js/WebAssemblyModulePrototype.h:
* wasm/js/WebAssemblyPrototype.cpp: Copied from Source/JavaScriptCore/wasm/js/WebAssemblyCompileErrorPrototype.cpp.
(JSC::webAssemblyFunctionValidate):
(JSC::webAssemblyFunctionCompile):
(JSC::WebAssemblyPrototype::create):
(JSC::WebAssemblyPrototype::createStructure):
(JSC::WebAssemblyPrototype::finishCreation):
(JSC::WebAssemblyPrototype::WebAssemblyPrototype):
* wasm/js/WebAssemblyPrototype.h: Copied from Source/JavaScriptCore/wasm/js/WebAssemblyMemoryPrototype.h.
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
(JSC::constructJSWebAssemblyRuntimeError):don't throw, create the object
(JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):no need for the structure, it's on the global object
* wasm/js/WebAssemblyRuntimeErrorConstructor.h:
* wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
* wasm/js/WebAssemblyRuntimeErrorPrototype.h:
* wasm/js/WebAssemblyTableConstructor.cpp:
* wasm/js/WebAssemblyTableConstructor.h:
* wasm/js/WebAssemblyTablePrototype.cpp:
* wasm/js/WebAssemblyTablePrototype.h:
2016-10-19 Myles C. Maxfield <mmaxfield@apple.com>
[macOS] [iOS] Disable variation fonts on macOS El Capitan and iOS 9
https://bugs.webkit.org/show_bug.cgi?id=163374
Reviewed by Darin Adler.
* Configurations/FeatureDefines.xcconfig:
2016-10-20 Caitlin Potter <caitp@igalia.com>
[JSC] disallow references to `await` in AsyncFunction formal parameters
https://bugs.webkit.org/show_bug.cgi?id=163694
Reviewed by Saam Barati.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseAssignmentExpression):
2016-10-19 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Move InterceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero to out of line type info flags
https://bugs.webkit.org/show_bug.cgi?id=163716
Reviewed by Saam Barati.
We found that all the accesses to the InterceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero flag is
done through the Structure. There is no user that accesses this flag in the cell inlined member. And JIT
code does not access it directly. That means that we can move this flag from inlined flags to out of line
flags. This patch moves it to the out of line flags. And make one bit empty in inlined flags. Later this
new empty flag will be used by megamorphic DOMJIT implementation.
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::hasStaticPropertyTable):
(JSC::TypeInfo::interceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero):
2016-10-20 Keith Miller <keith_miller@apple.com>
Invalid assertion in arguments elimination
https://bugs.webkit.org/show_bug.cgi?id=163740
<rdar://problem/27911462>
Reviewed by Michael Saboff.
The DFGFTL's arguments elimination phase incorrectly asserted that a GetFromArguments' first
child would always be a CreateDirectArguments. While we only create the
op_get_from_arguments bytecode pointing to a create_direct_arguments, its possible for a
number of reasons that a DFG GetFromArguments may not point to a CreateDirectArguments. For
example, if we are OSR entering in some function with direct arguments the
CreateDirectArguments node might become ExtractOSREntryLocals.
* dfg/DFGArgumentsEliminationPhase.cpp:
2016-10-20 Caitlin Potter <caitp@igalia.com>
[JSC] throw TypeError when constructing dynamically created JSGeneratorFunction
https://bugs.webkit.org/show_bug.cgi?id=163714
Reviewed by Mark Lam.
According to CreateDynamicFunction() (https://tc39.github.io/ecma262/#sec-createdynamicfunction),
non-normal functions are not constructors. Previously, dynamically created functions would always
be constructible, and so it was possible to evaluate `new (function*() {}.constructor())`,
and have it return an Iterator object.
This change selects a dynamically created function's ConstructAbility based on its parse mode instead.
* runtime/CodeCache.cpp:
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
2016-10-19 JF Bastien <jfbastien@apple.com>
create_hash_table: allow empty tables
The Windows build was broken by because I added empty tables and Windows insists that empty tables are horrible. Put in dummy entries in that case.
create_hash_table: allow empty tables
https://bugs.webkit.org/show_bug.cgi?id=163701
Reviewed by Keith Miller.
* create_hash_table:
2016-10-19 JF Bastien <jfbastien@apple.com>
JavaScript WebAssembly API: baby steps
- Expand WebAssembly constructors into their own files. This requires a lot of
boilerplate, as well as adding the .lut.h files. All of the
JSWebAssembly*.{h,cpp}, as well as Constructor and Prototype files, are
currently the same between the 4 specified WebAssembly constructors. It'll be
easy to implement individual functions on constructed objects as per the
spec, and have each of these files diverge. The error constructors are also
similar, except that their instance derives from ErrorInstance.
- Use constructor macro when initializing the global object.
- Dramatically improve testing of the WebAssembly API by checking for
properties specified in the spec [*].
- Clean up assert.js' exception testing.
- Fix a copy-paste bug in wasm.json: floating-point const return values were
swapped.
[*] https://github.com/WebAssembly/design/blob/master/JS.md
Implement more of the JavaScript WebAssembly API
https://bugs.webkit.org/show_bug.cgi?id=163571
Reviewed by Keith Miller.
* CMakeLists.txt: add .lut.h generation
* DerivedSources.make: ditto
* JavaScriptCore.xcodeproj/project.pbxproj: add .lut.h generation and all the new files
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init): use macro to list all constructors
* wasm/WebAssemblyObject.cpp: unboilerplate, all constructors into their own files
* wasm/WebAssemblyObject.h: ditto
* wasm/js/JSWebAssemblyCompileError.cpp: Added.
(JSC::JSWebAssemblyCompileError::create):
(JSC::JSWebAssemblyCompileError::createStructure):
(JSC::JSWebAssemblyCompileError::JSWebAssemblyCompileError):
(JSC::JSWebAssemblyCompileError::finishCreation):
(JSC::JSWebAssemblyCompileError::destroy):
(JSC::JSWebAssemblyCompileError::visitChildren):
* wasm/js/JSWebAssemblyCompileError.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
* wasm/js/JSWebAssemblyInstance.cpp: Added.
(JSC::JSWebAssemblyInstance::create):
(JSC::JSWebAssemblyInstance::createStructure):
(JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
(JSC::JSWebAssemblyInstance::finishCreation):
(JSC::JSWebAssemblyInstance::destroy):
(JSC::JSWebAssemblyInstance::visitChildren):
* wasm/js/JSWebAssemblyInstance.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
* wasm/js/JSWebAssemblyMemory.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::JSWebAssemblyMemory::create):
(JSC::JSWebAssemblyMemory::createStructure):
(JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
(JSC::JSWebAssemblyMemory::finishCreation):
(JSC::JSWebAssemblyMemory::destroy):
(JSC::JSWebAssemblyMemory::visitChildren):
* wasm/js/JSWebAssemblyMemory.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
* wasm/js/JSWebAssemblyModule.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::JSWebAssemblyModule::create):
(JSC::JSWebAssemblyModule::createStructure):
(JSC::JSWebAssemblyModule::JSWebAssemblyModule):
(JSC::JSWebAssemblyModule::finishCreation):
(JSC::JSWebAssemblyModule::destroy):
(JSC::JSWebAssemblyModule::visitChildren):
* wasm/js/JSWebAssemblyModule.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
* wasm/js/JSWebAssemblyRuntimeError.cpp: Added.
(JSC::JSWebAssemblyRuntimeError::create):
(JSC::JSWebAssemblyRuntimeError::createStructure):
(JSC::JSWebAssemblyRuntimeError::JSWebAssemblyRuntimeError):
(JSC::JSWebAssemblyRuntimeError::finishCreation):
(JSC::JSWebAssemblyRuntimeError::destroy):
(JSC::JSWebAssemblyRuntimeError::visitChildren):
* wasm/js/JSWebAssemblyRuntimeError.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
* wasm/js/JSWebAssemblyTable.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::JSWebAssemblyTable::create):
(JSC::JSWebAssemblyTable::createStructure):
(JSC::JSWebAssemblyTable::JSWebAssemblyTable):
(JSC::JSWebAssemblyTable::finishCreation):
(JSC::JSWebAssemblyTable::destroy):
(JSC::JSWebAssemblyTable::visitChildren):
* wasm/js/JSWebAssemblyTable.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
* wasm/js/WebAssemblyCompileErrorConstructor.cpp: Added.
(JSC::constructJSWebAssemblyCompileError):
(JSC::callJSWebAssemblyCompileError):
(JSC::WebAssemblyCompileErrorConstructor::create):
(JSC::WebAssemblyCompileErrorConstructor::createStructure):
(JSC::WebAssemblyCompileErrorConstructor::finishCreation):
(JSC::WebAssemblyCompileErrorConstructor::WebAssemblyCompileErrorConstructor):
(JSC::WebAssemblyCompileErrorConstructor::getConstructData):
(JSC::WebAssemblyCompileErrorConstructor::getCallData):
(JSC::WebAssemblyCompileErrorConstructor::visitChildren):
* wasm/js/WebAssemblyCompileErrorConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::WebAssemblyCompileErrorConstructor::CompileErrorStructure):
* wasm/js/WebAssemblyCompileErrorPrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::WebAssemblyCompileErrorPrototype::create):
(JSC::WebAssemblyCompileErrorPrototype::createStructure):
(JSC::WebAssemblyCompileErrorPrototype::finishCreation):
(JSC::WebAssemblyCompileErrorPrototype::WebAssemblyCompileErrorPrototype):
* wasm/js/WebAssemblyCompileErrorPrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
* wasm/js/WebAssemblyInstanceConstructor.cpp: Added.
(JSC::constructJSWebAssemblyInstance):
(JSC::callJSWebAssemblyInstance):
(JSC::WebAssemblyInstanceConstructor::create):
(JSC::WebAssemblyInstanceConstructor::createStructure):
(JSC::WebAssemblyInstanceConstructor::finishCreation):
(JSC::WebAssemblyInstanceConstructor::WebAssemblyInstanceConstructor):
(JSC::WebAssemblyInstanceConstructor::getConstructData):
(JSC::WebAssemblyInstanceConstructor::getCallData):
(JSC::WebAssemblyInstanceConstructor::visitChildren):
* wasm/js/WebAssemblyInstanceConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::WebAssemblyInstanceConstructor::InstanceStructure):
* wasm/js/WebAssemblyInstancePrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::WebAssemblyInstancePrototype::create):
(JSC::WebAssemblyInstancePrototype::createStructure):
(JSC::WebAssemblyInstancePrototype::finishCreation):
(JSC::WebAssemblyInstancePrototype::WebAssemblyInstancePrototype):
* wasm/js/WebAssemblyInstancePrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
* wasm/js/WebAssemblyMemoryConstructor.cpp: Added.
(JSC::constructJSWebAssemblyMemory):
(JSC::callJSWebAssemblyMemory):
(JSC::WebAssemblyMemoryConstructor::create):
(JSC::WebAssemblyMemoryConstructor::createStructure):
(JSC::WebAssemblyMemoryConstructor::finishCreation):
(JSC::WebAssemblyMemoryConstructor::WebAssemblyMemoryConstructor):
(JSC::WebAssemblyMemoryConstructor::getConstructData):
(JSC::WebAssemblyMemoryConstructor::getCallData):
(JSC::WebAssemblyMemoryConstructor::visitChildren):
* wasm/js/WebAssemblyMemoryConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::WebAssemblyMemoryConstructor::MemoryStructure):
* wasm/js/WebAssemblyMemoryPrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::WebAssemblyMemoryPrototype::create):
(JSC::WebAssemblyMemoryPrototype::createStructure):
(JSC::WebAssemblyMemoryPrototype::finishCreation):
(JSC::WebAssemblyMemoryPrototype::WebAssemblyMemoryPrototype):
* wasm/js/WebAssemblyMemoryPrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
* wasm/js/WebAssemblyModuleConstructor.cpp: Added.
(JSC::constructJSWebAssemblyModule):
(JSC::callJSWebAssemblyModule):
(JSC::WebAssemblyModuleConstructor::create):
(JSC::WebAssemblyModuleConstructor::createStructure):
(JSC::WebAssemblyModuleConstructor::finishCreation):
(JSC::WebAssemblyModuleConstructor::WebAssemblyModuleConstructor):
(JSC::WebAssemblyModuleConstructor::getConstructData):
(JSC::WebAssemblyModuleConstructor::getCallData):
(JSC::WebAssemblyModuleConstructor::visitChildren):
* wasm/js/WebAssemblyModuleConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::WebAssemblyModuleConstructor::ModuleStructure):
* wasm/js/WebAssemblyModulePrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::WebAssemblyModulePrototype::create):
(JSC::WebAssemblyModulePrototype::createStructure):
(JSC::WebAssemblyModulePrototype::finishCreation):
(JSC::WebAssemblyModulePrototype::WebAssemblyModulePrototype):
* wasm/js/WebAssemblyModulePrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp: Added.
(JSC::constructJSWebAssemblyRuntimeError):
(JSC::callJSWebAssemblyRuntimeError):
(JSC::WebAssemblyRuntimeErrorConstructor::create):
(JSC::WebAssemblyRuntimeErrorConstructor::createStructure):
(JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):
(JSC::WebAssemblyRuntimeErrorConstructor::WebAssemblyRuntimeErrorConstructor):
(JSC::WebAssemblyRuntimeErrorConstructor::getConstructData):
(JSC::WebAssemblyRuntimeErrorConstructor::getCallData):
(JSC::WebAssemblyRuntimeErrorConstructor::visitChildren):
* wasm/js/WebAssemblyRuntimeErrorConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::WebAssemblyRuntimeErrorConstructor::RuntimeErrorStructure):
* wasm/js/WebAssemblyRuntimeErrorPrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::WebAssemblyRuntimeErrorPrototype::create):
(JSC::WebAssemblyRuntimeErrorPrototype::createStructure):
(JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
(JSC::WebAssemblyRuntimeErrorPrototype::WebAssemblyRuntimeErrorPrototype):
* wasm/js/WebAssemblyRuntimeErrorPrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
* wasm/js/WebAssemblyTableConstructor.cpp: Added.
(JSC::constructJSWebAssemblyTable):
(JSC::callJSWebAssemblyTable):
(JSC::WebAssemblyTableConstructor::create):
(JSC::WebAssemblyTableConstructor::createStructure):
(JSC::WebAssemblyTableConstructor::finishCreation):
(JSC::WebAssemblyTableConstructor::WebAssemblyTableConstructor):
(JSC::WebAssemblyTableConstructor::getConstructData):
(JSC::WebAssemblyTableConstructor::getCallData):
(JSC::WebAssemblyTableConstructor::visitChildren):
* wasm/js/WebAssemblyTableConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::WebAssemblyTableConstructor::TableStructure):
* wasm/js/WebAssemblyTablePrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::WebAssemblyTablePrototype::create):
(JSC::WebAssemblyTablePrototype::createStructure):
(JSC::WebAssemblyTablePrototype::finishCreation):
(JSC::WebAssemblyTablePrototype::WebAssemblyTablePrototype):
* wasm/js/WebAssemblyTablePrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
2016-10-19 Caitlin Potter <caitp@igalia.com>
[JSC] forbid "use strict" directive in generator functions with non-simple parameters
https://bugs.webkit.org/show_bug.cgi?id=163683
Reviewed by Geoffrey Garen.
Because generator functions and async functions both have an implicit
inner function whose arguments are inherited from its parent, "use strict"
directives within these functions did not yield a SyntaxError.
Now, the correct syntax error is reported, fixing several test262 failures
for generators and async functions.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionInfo):
2016-10-19 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r207557.
This change caused animations/font-variations tests to time
out on pre-Sierra Macs.
Reverted changeset:
"[macOS] [iOS] Disable variation fonts on macOS El Capitan and
iOS 9"
https://bugs.webkit.org/show_bug.cgi?id=163374
http://trac.webkit.org/changeset/207557
2016-10-19 Filip Pizlo <fpizlo@apple.com>
Baseline JIT should use AutomaticThread
https://bugs.webkit.org/show_bug.cgi?id=163686
Reviewed by Geoffrey Garen.
Change the JITWorklist to use AutomaticThread, so that the Baseline JIT's concurrent
compiler thread shuts down automatically after inactivity.
With this change, all of JSC's threads shut down automatically. If you run splay for a few
seconds (which fires up all threads - compiler and GC) and then go to sleep for a second,
you'll see that the only threads left are the main thread and the bmalloc thread.
* jit/JITWorklist.cpp:
(JSC::JITWorklist::Thread::Thread):
(JSC::JITWorklist::JITWorklist):
(JSC::JITWorklist::completeAllForVM):
(JSC::JITWorklist::poll):
(JSC::JITWorklist::compileLater):
(JSC::JITWorklist::compileNow):
(JSC::JITWorklist::finalizePlans):
(JSC::JITWorklist::runThread): Deleted.
* jit/JITWorklist.h:
2016-10-19 Myles C. Maxfield <mmaxfield@apple.com>
[macOS] [iOS] Disable variation fonts on macOS El Capitan and iOS 9
https://bugs.webkit.org/show_bug.cgi?id=163374
Reviewed by Darin Adler.
* Configurations/FeatureDefines.xcconfig:
2016-10-19 Aaron Chu <aaron_chu@apple.com>
Web Inspector: AXI: expose computed tree node and heading level
https://bugs.webkit.org/show_bug.cgi?id=130825
<rdar://problem/16442349>
Reviewed by Joseph Pecoraro.
Exposing two new accessibility properties: Heading Level and Hierarchical Level.
* inspector/protocol/DOM.json:
2016-10-18 Filip Pizlo <fpizlo@apple.com>
DFG worklist should use AutomaticThread
https://bugs.webkit.org/show_bug.cgi?id=163615
Reviewed by Mark Lam.
AutomaticThread is a new feature in WTF that allows you to easily create worker threads that
shut down automatically. This changes DFG::Worklist to use AutomaticThread, so that its
threads shut down automatically, too. This has the potential to save a lot of memory.
This required some improvements to AutomaticThread: Worklist likes to be able to keep state
around for the whole lifetime of a thread, and so it likes knowing when threads are born and
when they die. I added virtual methods for that. Also, Worklist uses notifyOne() so I added
that, too.
This looks to be perf-neutral.
* dfg/DFGThreadData.cpp:
(JSC::DFG::ThreadData::ThreadData):
* dfg/DFGThreadData.h:
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::ThreadBody::ThreadBody):
(JSC::DFG::Worklist::Worklist):
(JSC::DFG::Worklist::~Worklist):
(JSC::DFG::Worklist::finishCreation):
(JSC::DFG::Worklist::isActiveForVM):
(JSC::DFG::Worklist::enqueue):
(JSC::DFG::Worklist::compilationState):
(JSC::DFG::Worklist::waitUntilAllPlansForVMAreReady):
(JSC::DFG::Worklist::removeAllReadyPlansForVM):
(JSC::DFG::Worklist::completeAllReadyPlansForVM):
(JSC::DFG::Worklist::rememberCodeBlocks):
(JSC::DFG::Worklist::visitWeakReferences):
(JSC::DFG::Worklist::removeDeadPlans):
(JSC::DFG::Worklist::removeNonCompilingPlansForVM):
(JSC::DFG::Worklist::queueLength):
(JSC::DFG::Worklist::dump):
(JSC::DFG::Worklist::runThread): Deleted.
(JSC::DFG::Worklist::threadFunction): Deleted.
* dfg/DFGWorklist.h:
2016-10-19 Dan Bernstein <mitz@apple.com>
[Xcode] JavaScriptCore fails to build when CLANG_WARN_DOCUMENTATION_COMMENTS is enabled
https://bugs.webkit.org/show_bug.cgi?id=163642
Reviewed by Darin Adler.
* API/JSClassRef.cpp: Removed a bad headerdoc comment inside an implementation file.
* API/JSContext.h: Changed @methodgroup to @functiongroup, because the compiler requires the
former to be followed by a method (and we have a property), but not the latter. Changed
a couple of instances of “method” to “@method”. Removed empty @param entries.
* API/JSContextRefInternal.h: Named a parameter referenced in a @param entry.
* API/JSContextRefPrivate.h: Ditto.
* API/JSManagedValue.h: Removed empty @param entries.
* API/JSObjectRef.h: Corrected parameter name in @param entry.
* API/JSTypedArray.h: Ditto.
* API/JSValue.h: Removed empty @param entries, changed @methodgroup to @functiongroup, and
changed @method to @property where appropriate. Removed empty @param entries.
* API/JSValueRef.h: Named a parameter referenced in a @param entry.
* API/JSWeakObjectMapRefPrivate.h: Ditto.
* Configurations/Base.xcconfig: Enabled CLANG_WARN_DOCUMENTATION_COMMENTS. Made the compiler
treat the icu headers as system headers, to stop it from emitting warnings about headers
we don’t want to change.
* Configurations/ToolExecutable.xcconfig: Made the compiler treat the icu headers as system
headers.
2016-10-19 Csaba Osztrogonác <ossy@webkit.org>
Unreviewed ARM buildfix after r207475.
* assembler/ARMAssembler.h:
(JSC::ARMAssembler::relinkJumpToNop):
2016-10-18 Mark Lam <mark.lam@apple.com>
Invoking Object.prototype.__proto__ accessors directly should throw a TypeError.
https://bugs.webkit.org/show_bug.cgi?id=154377
<rdar://problem/27330808>
Reviewed by Filip Pizlo and Saam Barati.
In a scenario where we cache the __proto__ accessors in global variables, and
later explicitly invoke those accessors as functions, the spec for Function Calls
(see https://tc39.github.io/ecma262/#sec-function-calls) states that the function
ref value is of type Reference, and base of ref is an Environment Record. Then,
it follows that the thisValue should be set to refEnv.WithBaseObject()
(see section 4.b.ii of 12.3.4.1 at
https://tc39.github.io/ecma262/#sec-function-calls-runtime-semantics-evaluation).
refEnv in this case is the environment record that the cached accessors were
found in i.e. the global object. The WithBaseObject() of the global object is
undefined (see details about WithBaseObject at
https://tc39.github.io/ecma262/#sec-environment-records).
Hence, the __proto__ accessors should see a thisValue of undefined, and throw
TypeErrors. See https://tc39.github.io/ecma262/#sec-get-object.prototype.__proto__,
https://tc39.github.io/ecma262/#sec-set-object.prototype.__proto__,
https://tc39.github.io/ecma262/#sec-toobject, and
https://tc39.github.io/ecma262/#sec-requireobjectcoercible.
In JSC's implementation, the callee needs to do a ToThis operation on the
incoming "this" argument in order to get the specified thisValue. The
implementations of the __proto__ accessors were not doing this correctly. This
has now been fixed.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncProtoGetter):
(JSC::globalFuncProtoSetter):
2016-10-18 Sam Weinig <sam@webkit.org>
Replace std::experimental::variant with WTF::Variant (or similar)
https://bugs.webkit.org/show_bug.cgi?id=163626
Reviewed by Chris Dumez.
Rename std::experimental::variant, Variant. Move helpers get/holds_alternative/etc.
into the WTF namespace.
* domjit/DOMJITReg.h:
(JSC::DOMJIT::Reg::gpr):
(JSC::DOMJIT::Reg::fpr):
(JSC::DOMJIT::Reg::jsValueRegs):
2016-10-18 Keith Miller <keith_miller@apple.com>
GetByVal to GetById conversion in the DFG is incorrect for getters with control flow
https://bugs.webkit.org/show_bug.cgi?id=163629
Reviewed by Yusuke Suzuki.
This patch fixes a bug in the DFG when attempt to convert a
GetByVal into a GetById. While converting the GetByVal, during
handleGetById in the Bytecode parser, we would mistakenly use the
opcode length of op_get_by_id rather than op_get_by_val. This causes
the new basic block we create to point to the wrong offset. In the
added test this will cause us to infinite loop.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::parseBlock):
2016-10-18 Dean Jackson <dino@apple.com>
Remove CSS_SHAPES feature definition. This should always be on.
https://bugs.webkit.org/show_bug.cgi?id=163628
<rdar://problem/28834613>
Reviewed by Tim Horton.
* Configurations/FeatureDefines.xcconfig:
2016-10-18 Michael Saboff <msaboff@apple.com>
Add JSC option to show time spent in each optimization phase
https://bugs.webkit.org/show_bug.cgi?id=163617
Reviewed by Saam Barati.
Added reportDFGPhaseTimes option. This outputs one line per phase similar to
Phase CPS rethreading took 0.2661 ms
One line is output for each phase run.
* dfg/DFGPhase.h:
(JSC::DFG::runAndLog):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThread):
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/Options.h:
2016-10-18 Filip Pizlo <fpizlo@apple.com>
WTF should make it easier to create threads that die automatically after inactivity
https://bugs.webkit.org/show_bug.cgi?id=163576
Reviewed by Andreas Kling.
Added a sleepSeconds() function, which made it easier for me to test this change.
The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
shut down automatically after 1 second of inactivity. Maybe this will save some memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionSleepSeconds):
2016-10-18 Keith Miller <keith_miller@apple.com>
Cleanup Wasm memory.
https://bugs.webkit.org/show_bug.cgi?id=163601
Reviewed by Saam Barati.
There were a couple of issues with the original Wasm memory patch.
This is a follow-up patch to fix those issues.
* wasm/WASMMemory.cpp:
(JSC::WASM::Memory::Memory):
* wasm/WASMMemory.h:
2016-10-15 Filip Pizlo <fpizlo@apple.com>
DFG and FTL should be able to use DirectCall ICs when they proved the callee or its executable
https://bugs.webkit.org/show_bug.cgi?id=163371
Reviewed by Geoffrey Garen and Saam Barati.
This adds a new kind of call inline cache for when the DFG can prove what the callee
executable is. In those cases, we can skip some of the things that the traditional call IC
would do:
- No need to check who the callee is.
- No need to do arity checks.
This case isn't as simple as just emitting a call instruction since the callee may not be
compiled at the time that the caller is compiled. So, we need lazy resolution. Also, the
callee may be jettisoned independently of the caller, so we need to be able to revert the
call to an unlinked state. This means that we need almost all of the things that
CallLinkInfo has. CallLinkInfo already knows about different kinds of calls. This patch
teaches it about new "Direct" call types.
The direct non-tail call IC looks like this:
set up arguments
FastPath:
call _SlowPath
lea -FrameSize(%rbp), %rsp
SlowPath:
pop
call operationLinkDirectCall
check exception
jmp FastPath
The job of operationLinkDirectCall is to link the fast path's call entrypoint of the callee.
This means that in steady state, a call is just that: a call. There are no extra branches or
checks.
The direct tail call IC is a bit more complicated because the act of setting up arguments
destroys our frame, which would prevent us from being able to throw an exception if we
failed to compile the callee. So, direct tail call ICs look like this:
jmp _SlowPath
FastPath:
set up arguments
jmp 0 // patch to jump to callee
SlowPath:
silent spill
call operationLinkDirectCall
silent fill
check exception
jmp FastPath
The jmp to the slow path is patched to be a fall-through jmp when we link the call.
Direct calls mean less code at call sites, fewer checks on the steady state call fast path,
and no need for arity fixup. This looks like a slight speed-up (~0.8%) on both Octane and
AsmBench.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::relinkJumpToNop):
* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::relinkJumpToNop):
(JSC::ARMv7Assembler::relinkJump): Deleted.
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::repatchJumpToNop):
(JSC::AbstractMacroAssembler::repatchJump): Deleted.
* assembler/X86Assembler.h:
(JSC::X86Assembler::relinkJumpToNop):
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::CallLinkInfo):
(JSC::CallLinkInfo::callReturnLocation):
(JSC::CallLinkInfo::patchableJump):
(JSC::CallLinkInfo::hotPathBegin):
(JSC::CallLinkInfo::slowPathStart):
(JSC::CallLinkInfo::setCallee):
(JSC::CallLinkInfo::clearCallee):
(JSC::CallLinkInfo::callee):
(JSC::CallLinkInfo::setCodeBlock):
(JSC::CallLinkInfo::clearCodeBlock):
(JSC::CallLinkInfo::codeBlock):
(JSC::CallLinkInfo::setLastSeenCallee):
(JSC::CallLinkInfo::clearLastSeenCallee):
(JSC::CallLinkInfo::lastSeenCallee):
(JSC::CallLinkInfo::haveLastSeenCallee):
(JSC::CallLinkInfo::setExecutableDuringCompilation):
(JSC::CallLinkInfo::executable):
(JSC::CallLinkInfo::setMaxNumArguments):
(JSC::CallLinkInfo::visitWeak):
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::specializationKindFor):
(JSC::CallLinkInfo::callModeFor):
(JSC::CallLinkInfo::isDirect):
(JSC::CallLinkInfo::nearCallMode):
(JSC::CallLinkInfo::isLinked):
(JSC::CallLinkInfo::setCallLocations):
(JSC::CallLinkInfo::addressOfMaxNumArguments):
(JSC::CallLinkInfo::maxNumArguments):
(JSC::CallLinkInfo::isTailCall): Deleted.
(JSC::CallLinkInfo::setUpCallFromFTL): Deleted.
(JSC::CallLinkInfo::callReturnLocation): Deleted.
(JSC::CallLinkInfo::hotPathBegin): Deleted.
(JSC::CallLinkInfo::callee): Deleted.
(JSC::CallLinkInfo::setLastSeenCallee): Deleted.
(JSC::CallLinkInfo::clearLastSeenCallee): Deleted.
(JSC::CallLinkInfo::lastSeenCallee): Deleted.
(JSC::CallLinkInfo::haveLastSeenCallee): Deleted.
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeDFGStatuses):
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generateImpl):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecode/ValueRecovery.h:
(JSC::ValueRecovery::forEachReg):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGBasicBlock.h:
(JSC::DFG::BasicBlock::findTerminal):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
(JSC::DFG::ByteCodeParser::handleCall):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::parameterSlotsForArgCount):
* dfg/DFGGraph.h:
* dfg/DFGInPlaceAbstractState.cpp:
(JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::addJSDirectCall):
(JSC::DFG::JITCompiler::addJSDirectTailCall):
(JSC::DFG::JITCompiler::JSCallRecord::JSCallRecord):
(JSC::DFG::JITCompiler::JSDirectCallRecord::JSDirectCallRecord):
(JSC::DFG::JITCompiler::JSDirectTailCallRecord::JSDirectTailCallRecord):
(JSC::DFG::JITCompiler::currentJSCallIndex): Deleted.
* dfg/DFGNode.cpp:
(JSC::DFG::Node::convertToDirectCall):
* dfg/DFGNode.h:
(JSC::DFG::Node::isTerminal):
(JSC::DFG::Node::hasHeapPrediction):
(JSC::DFG::Node::hasCellOperand):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
(JSC::Interpreter::prepareForRepeatCall):
* jit/JIT.cpp:
(JSC::JIT::link):
* jit/JITCall.cpp:
(JSC::JIT::compileSetupVarargsFrame):
* jit/JITCall32_64.cpp:
(JSC::JIT::compileSetupVarargsFrame):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/Repatch.cpp:
(JSC::linkDirectFor):
(JSC::revertCall):
* jit/Repatch.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setUpCall):
* runtime/Executable.cpp:
(JSC::ScriptExecutable::prepareForExecutionImpl):
* runtime/Executable.h:
(JSC::ScriptExecutable::prepareForExecution):
* runtime/Options.h:
2016-10-18 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT] Not emit exception case if it is not necessary
https://bugs.webkit.org/show_bug.cgi?id=163589
Reviewed by Sam Weinig.
We should not emit exception case if we do not use the slow path calls.
For example, nodeType accessor does not use the slow path calls.
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::emitDOMJITGetter):
2016-10-18 Caitlin Potter <caitp@igalia.com>
[JSC] ES6 Method functions should not have prototype
https://bugs.webkit.org/show_bug.cgi?id=162530
Reviewed by Saam Barati.
ECMA-262 only adds "prototype" properties to specific syntactic function forms.
Specific items which do not contain "prototype" include (most) built-in functions (such as Math.pow),
MethodDefinitions which are not either class "constructor" methods or GeneratorMethods, AsyncFunctions,
and ArrowFunctions.
For details, see the following spec text, and the difference between GeneratorMethod evaluation and
the evaluation of other MethodDefinition forms.
- https://tc39.github.io/ecma262/#sec-method-definitions-runtime-semantics-propertydefinitionevaluation
- https://tc39.github.io/ecma262/#sec-arrow-function-definitions-runtime-semantics-evaluation
- https://tc39.github.io/ecmascript-asyncawait/#async-function-instances
- https://tc39.github.io/ecma262/#sec-generator-function-definitions-runtime-semantics-propertydefinitionevaluation
* runtime/Executable.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::callerGetter):
(JSC::JSFunction::getOwnPropertySlot):
(JSC::JSFunction::deleteProperty):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::makeFunction):
* runtime/Executable.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::getOwnPropertySlot):
(JSC::JSFunction::getOwnNonIndexPropertyNames):
(JSC::JSFunction::put):
(JSC::JSFunction::deleteProperty):
(JSC::JSFunction::defineOwnProperty):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncThrowTypeErrorArgumentsCalleeAndCaller):
2016-10-17 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT] Use NativeCallFrameTracer for operations used for DOMJIT slow calls
https://bugs.webkit.org/show_bug.cgi?id=163586
Reviewed by Saam Barati.
C functions called from the DOMJIT slow path calls should use NativeCallFrameTracer.
This fixes the debug assertion caused in r207427.
* bytecode/DOMJITAccessCasePatchpointParams.cpp:
(JSC::SlowPathCallGeneratorWithArguments::generateImpl):
(JSC::DOMJITAccessCasePatchpointParams::emitSlowPathCalls):
* bytecode/DOMJITAccessCasePatchpointParams.h:
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::emitDOMJITGetter):
* jsc.cpp:
(WTF::DOMJITGetter::DOMJITNodeDOMJIT::slowCall):
(WTF::DOMJITGetterComplex::DOMJITNodeDOMJIT::slowCall):
2016-10-17 Keith Miller <keith_miller@apple.com>
Add support for WASM Memory.
https://bugs.webkit.org/show_bug.cgi?id=161710
Reviewed by Geoffrey Garen.
This patch add initial support for WASM memory operations. First,
it adds the concept of a WASM Module memory management object.
This object currently mmaps a 32-bit address space for WASM use,
although it marks all the memory outside the current breakpoint as
PROT_NONE. For now, we do a range check on each store and load. In
the future, we should change this to be an signal handler that
checks what module the program trapped in.
Additionally, this patch changes the way that our temporary tests
call into WASM code. There is now a true "thunk" that relocates
arguments and calls into WASM. This thunk does not tail call
because we use pinned values to memory base-pointer and
size. We use the new B3 pinned register api to pin the values.
* CMakeLists.txt:
* Configurations/ToolExecutable.xcconfig:
* JavaScriptCore.xcodeproj/project.pbxproj:
* testWASM.cpp:
(runWASMTests):
(main):
* wasm/WASMB3IRGenerator.cpp:
(JSC::WASM::createJSWrapper):
(JSC::WASM::parseAndCompile):
* wasm/WASMB3IRGenerator.h:
* wasm/WASMCallingConvention.h:
(JSC::WASM::CallingConvention::iterate):
(JSC::WASM::CallingConvention::setupCall):
(JSC::WASM::nextJSCOffset):
* wasm/WASMFormat.h:
* wasm/WASMFunctionParser.h:
(JSC::WASM::FunctionParser<Context>::parseExpression):
* wasm/WASMMemory.cpp: Copied from Source/JavaScriptCore/wasm/WASMPlan.cpp.
(JSC::WASM::Memory::Memory):
* wasm/WASMMemory.h: Copied from Source/JavaScriptCore/wasm/WASMModuleParser.h.
(JSC::WASM::Memory::~Memory):
(JSC::WASM::Memory::memory):
(JSC::WASM::Memory::size):
(JSC::WASM::Memory::pinnedRegisters):
(JSC::WASM::Memory::mode):
(JSC::WASM::Memory::growMemory):
(JSC::WASM::Memory::offsetOfSize):
* wasm/WASMModuleParser.cpp:
(JSC::WASM::ModuleParser::parse):
(JSC::WASM::ModuleParser::parseMemory):
* wasm/WASMModuleParser.h:
(JSC::WASM::ModuleParser::functionInformation):
(JSC::WASM::ModuleParser::memory):
* wasm/WASMOps.h:
* wasm/WASMPlan.cpp:
(JSC::WASM::Plan::Plan):
* wasm/WASMPlan.h:
* wasm/WASMSections.h:
2016-10-17 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Add toggles for debugger pauses at console.assert failures
https://bugs.webkit.org/show_bug.cgi?id=139542
<rdar://problem/19281600>
Reviewed by Timothy Hatcher.
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::disable):
(Inspector::InspectorDebuggerAgent::setPauseOnAssertions):
Toggle pause on assertions state. Default is disabled,
and disable it when frontends disconnect.
(Inspector::InspectorDebuggerAgent::handleConsoleAssert):
Instead of using the PauseOnAllExceptions state, use this
new state specific to assertions.
* inspector/protocol/Debugger.json:
New protocol method to toggle pausing on assertions.
2016-10-17 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT][JSC] Add Option::useDOMJIT
https://bugs.webkit.org/show_bug.cgi?id=163457
Reviewed by Saam Barati.
Add an option to switch the DOMJIT optimization.
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generateImpl):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleGetById):
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/Options.h:
2016-10-17 Filip Pizlo <fpizlo@apple.com>
Air::IRC doesn't need to have a special-case for uncolored Tmps since they all get colored
https://bugs.webkit.org/show_bug.cgi?id=163548
<rdar://problem/28804381>
Reviewed by Geoffrey Garen.
Before r207408, IRC had a mode where it would silently assign the first assignable register (so
%rax, %xmm0, etc) to any tmp that was not colorable due to a pathological interference fencepost.
We reason about interference at instruction boundaries. This means that if you have, for example,
an instruction that clobbers all registers late followed by an instruction that has an early def
in the same register file, then the early def will not be colorable because it interferes with
all registers. This already happens in our tests, but IRC silently returns the first assignable
register to such tmps. For some reason the resulting code works OK - probably because this tends
to only be hit by fuzzing, which may not then stress that code enough to shake out the register
corruption. Also, this can only happen for floating point registers, so it's hard to get an
exciting crash. The worst case is that your numbers get all messed up.
This change fixes the issue:
- IRC will now crash if it can't color a tmp.
- IRC doesn't crash on our tests anymore because I added a padInterference() utility that works
around the interference problem by inserting Nops to pad between those instructions where
conflating their early and late actions into one interference fencepost could create an
uncolorable graph.
See https://bugs.webkit.org/show_bug.cgi?id=163548#c2 for a detailed discussion of how the
problem can arise.
This problem almost made me want to abandon our use of interference at instruction boundaries,
and introduce something more comprehensive, like interference at various stages of an
instruction's execution. The reason why I didn't do this is that this problem only arises in well
confined corner cases: you need an instruction that does a late use or def followed by an
instruction that does an early def. Register clobbers count as defs for this equation.
Fortunately, early defs are rare, and even when they do happen, you still need the previous
instruction to have a late something. Late uses are rare and many instructions don't have defs at
all, which means that it's actually pretty common for an instruction to not have anything late.
This means that the padInterference() strategy is ideal: our algorithms stay simple because they
only have to worry about interference at boundaries, and we rarely insert any Nops in
padInterference() so the IR stays nice and compact. Those Nops get removed by any phase that does
DCE, which includes eliminateDeadCode(), allocateStack(), and reportUsedRegisters(). In practice
allocateStack() kills them.
This also finally refactors our passing of RegisterSet to pass it by value, since it's small
enough that we're not gaining anything by using references. On x86, RegisterSet ought to be
smaller than a pointer.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::extraClobberedRegs):
(JSC::B3::StackmapSpecial::extraEarlyClobberedRegs):
* b3/B3StackmapSpecial.h:
* b3/air/AirCCallSpecial.cpp:
(JSC::B3::Air::CCallSpecial::extraEarlyClobberedRegs):
(JSC::B3::Air::CCallSpecial::extraClobberedRegs):
* b3/air/AirCCallSpecial.h:
* b3/air/AirInst.h:
* b3/air/AirInstInlines.h:
(JSC::B3::Air::Inst::extraClobberedRegs):
(JSC::B3::Air::Inst::extraEarlyClobberedRegs):
* b3/air/AirIteratedRegisterCoalescing.cpp:
(JSC::B3::Air::iteratedRegisterCoalescing):
* b3/air/AirPadInterference.cpp: Added.
(JSC::B3::Air::padInterference):
* b3/air/AirPadInterference.h: Added.
* b3/air/AirSpecial.h:
* b3/air/AirSpillEverything.cpp:
(JSC::B3::Air::spillEverything):
* jit/RegisterSet.h:
(JSC::RegisterSet::isEmpty):
2016-10-17 JF Bastien <jfbastien@apple.com>
WebAssembly JS API: implement basic stub
Implement the global WebAssembly JavaScript object, and its constructor +
function properties as described in:
https://github.com/WebAssembly/design/blob/master/JS.md
These don't do anything at the moment, the parent bug will take care of adding
more functionality and associated tests.
WebAssembly JS API: implement basic stub
https://bugs.webkit.org/show_bug.cgi?id=163404
Reviewed by Keith Miller.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/BuiltinNames.h: register the new WebAssembly object's name and its constructor properties
* jsc.cpp: remove useless include
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init): add the WebAssembly global object and its constructor properties, but only if the JSC option enables it
* runtime/Options.h: add the useWebAssembly (alias: enableWebAssembly) option, defaulting to false
* wasm/WebAssemblyObject.cpp: Added.
(JSC::WebAssemblyObject::create): boilerplate
(JSC::WebAssemblyObject::createStructure): boilerplate
(JSC::WebAssemblyObject::finishCreation): boilerplate
(JSC::WebAssemblyObject::WebAssemblyObject): boilerplate
(JSC::wasmObjectFuncvalidate): auto-throws for now
(JSC::wasmObjectFunccompile): auto-throws for now
* wasm/WebAssemblyObject.h: Added.
2016-10-17 Yusuke Suzuki <utatane.tea@gmail.com>
Unreviewed, build fix after r207428
https://bugs.webkit.org/show_bug.cgi?id=163223
Previous build fix r207428 broke all the builds.
* bytecode/PolymorphicAccess.h:
2016-10-17 Yusuke Suzuki <utatane.tea@gmail.com>
Unreviewed, build fix for GTK and Windows
https://bugs.webkit.org/show_bug.cgi?id=163223
Attempt to fix build failures in GTK port and Windows port.
* bytecode/PolymorphicAccess.cpp:
* bytecode/PolymorphicAccess.h:
(JSC::AccessGenerationState::SpillState::SpillState):
2016-10-17 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT] Use DOMJIT::Patchpoint in IC
https://bugs.webkit.org/show_bug.cgi?id=163223
Reviewed by Saam Barati.
This patch uses DOMJIT::Patchpoint to inline DOM accesses even in IC!
It is useful for Baseline JIT cases and GetById cases in DFG and FTL.
In AccessCase, we construct the environment that allows DOMJIT::Patchpoint
to emit code and make DOMJIT accessors inlined in IC.
To allow DOMJIT::Patchpoint to emit code, we create a mechanism to emit calls
required in DOMJIT::Patchpoint. This system is useful when we create the super-
polymorphic support[1] later. And inlining mechanism is useful even after
introducing super-polymorphic support since it can work even after we fire the
watchpoint for super-polymorphic handling.
This patch improves Dromaeo dom-traverse 8% (263.95 runs/s v.s. 244.07 runs/s).
[1]: https://bugs.webkit.org/show_bug.cgi?id=163226
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/DOMJITAccessCasePatchpointParams.cpp: Added.
(JSC::SlowPathCallGeneratorWithArguments::SlowPathCallGeneratorWithArguments):
(JSC::SlowPathCallGeneratorWithArguments::generateImpl):
(JSC::DOMJITAccessCasePatchpointParams::emitSlowPathCalls):
* bytecode/DOMJITAccessCasePatchpointParams.h: Copied from Source/JavaScriptCore/ftl/FTLDOMJITPatchpointParams.h.
(JSC::DOMJITAccessCasePatchpointParams::DOMJITAccessCasePatchpointParams):
(JSC::DOMJITAccessCasePatchpointParams::SlowPathCallGenerator::~SlowPathCallGenerator):
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessGenerationState::liveRegistersForCall):
(JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite):
(JSC::calleeSaveRegisters):
(JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
(JSC::AccessGenerationState::restoreLiveRegistersFromStackForCallWithThrownException):
(JSC::AccessGenerationState::restoreLiveRegistersFromStackForCall):
(JSC::AccessGenerationState::callSiteIndexForExceptionHandlingOrOriginal):
(JSC::AccessGenerationState::originalExceptionHandler):
(JSC::AccessCase::generateImpl):
(JSC::AccessCase::emitDOMJITGetter):
(JSC::PolymorphicAccess::regenerate):
(JSC::AccessGenerationState::preserveLiveRegistersToStackForCall): Deleted.
* bytecode/PolymorphicAccess.h:
(JSC::AccessGenerationState::SpillState::isEmpty):
(JSC::AccessGenerationState::setSpillStateForJSGetterSetter):
(JSC::AccessGenerationState::spillStateForJSGetterSetter):
(JSC::AccessGenerationState::liveRegistersForCall): Deleted.
(JSC::AccessGenerationState::numberOfStackBytesUsedForRegisterPreservation): Deleted.
(JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite): Deleted.
* dfg/DFGDOMJITPatchpointParams.cpp:
* dfg/DFGDOMJITPatchpointParams.h:
* domjit/DOMJITPatchpoint.h:
* domjit/DOMJITPatchpointParams.h:
(JSC::DOMJIT::PatchpointParams::addSlowPathCall):
* ftl/FTLDOMJITPatchpointParams.cpp:
* ftl/FTLDOMJITPatchpointParams.h:
* jsc.cpp:
(WTF::DOMJITNode::checkDOMJITNode):
(WTF::DOMJITGetterComplex::DOMJITGetterComplex):
(WTF::DOMJITGetterComplex::createStructure):
(WTF::DOMJITGetterComplex::create):
(WTF::DOMJITGetterComplex::DOMJITNodeDOMJIT::DOMJITNodeDOMJIT):
(WTF::DOMJITGetterComplex::domJITNodeGetterSetter):
(WTF::DOMJITGetterComplex::finishCreation):
(WTF::DOMJITGetterComplex::functionEnableException):
(WTF::DOMJITGetterComplex::customGetter):
(GlobalObject::finishCreation):
(functionCreateDOMJITGetterComplexObject):
2016-10-17 Saam Barati <sbarati@apple.com>
Build fix for HasOwnPropertyCache::Entry caused slowdown by introducing a constructor that doesn't use move semantics for the RefPtr<UniquedStringImpl> parameter
https://bugs.webkit.org/show_bug.cgi?id=163490
Reviewed by Darin Adler.
* runtime/HasOwnPropertyCache.h:
(JSC::HasOwnPropertyCache::Entry::Entry):
(JSC::HasOwnPropertyCache::tryAdd):
2016-10-17 Mark Lam <mark.lam@apple.com>
Use the reject() helper function for conditionally throwing TypeErrors.
https://bugs.webkit.org/show_bug.cgi?id=163491
Reviewed by Filip Pizlo.
In some places where we may conditionally throw a TypeError (e.g. when in strict
mode), we already use the reject() helper function to conditionally throw the
TypeError. Doing so makes the code mode compact. This patch applies this idiom
consistently in all places that throws TypeError where appropriate.
This patch also does the following:
1. Make the reject() helper function take an ASCIILiteral instead of a const char*
because we always pass it a literal string anyway.
2. Change the reject helper() to take a ThrowScope&. This allows the thrown
error to be attributed to its caller.
3. When an error message string is instantiated repeatedly in more than 1 place,
create a common copy of that literal string in JSObject.cpp (if one doesn't
already exist) and use that common string in all those places.
4. Since I was auditing call sites of throwTypeError() to check if they should be
using the reject() helper instead, I also fixed those up to pass the error
message as an ASCIILiteral where appropriate.
5. In functions that I touched, change the code to not recompute the VM& when it
is already available.
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/ArrayPrototype.cpp:
(JSC::shift):
(JSC::unshift):
(JSC::arrayProtoFuncPop):
(JSC::arrayProtoFuncReverse):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/GetterSetter.cpp:
(JSC::callSetter):
* runtime/JSArray.cpp:
(JSC::JSArray::defineOwnProperty):
(JSC::JSArray::setLengthWithArrayStorage):
(JSC::JSArray::pop):
* runtime/JSArrayBuffer.cpp:
(JSC::JSArrayBuffer::put):
(JSC::JSArrayBuffer::defineOwnProperty):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive):
(JSC::JSValue::putToPrimitiveByIndex):
* runtime/JSDataView.cpp:
(JSC::JSDataView::put):
(JSC::JSDataView::defineOwnProperty):
* runtime/JSFunction.cpp:
(JSC::JSFunction::put):
(JSC::JSFunction::defineOwnProperty):
* runtime/JSGenericTypedArrayView.h:
(JSC::JSGenericTypedArrayView::setIndex):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
(JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::speciesConstruct):
(JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::defineOwnProperty):
* runtime/JSObject.cpp:
(JSC::ordinarySetSlow):
(JSC::JSObject::putInlineSlow):
(JSC::JSObject::setPrototypeWithCycleCheck):
(JSC::JSObject::defineOwnIndexedProperty):
(JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
(JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
(JSC::validateAndApplyPropertyDescriptor):
* runtime/JSObject.h:
* runtime/JSObjectInlines.h:
(JSC::JSObject::putInline):
* runtime/JSProxy.cpp:
(JSC::JSProxy::setPrototype):
* runtime/JSSymbolTableObject.h:
(JSC::symbolTablePut):
* runtime/Lookup.h:
(JSC::putEntry):
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::defineOwnProperty):
* runtime/RegExpObject.h:
(JSC::RegExpObject::setLastIndex):
* runtime/Reject.h:
(JSC::reject):
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::putEntry):
(JSC::SparseArrayValueMap::putDirect):
(JSC::SparseArrayEntry::put):
* runtime/StringObject.cpp:
(JSC::StringObject::put):
(JSC::StringObject::putByIndex):
* runtime/SymbolConstructor.cpp:
(JSC::symbolConstructorKeyFor):
2016-10-16 Filip Pizlo <fpizlo@apple.com>
Air::IRC needs to place all Tmps on some worklist, even if they have no interference edges
https://bugs.webkit.org/show_bug.cgi?id=163509
Reviewed by Mark Lam.
The worklist building function in IRC skips temporaries that have no degree. This doesn't appear
to be necessary. This has been there since the original IRC commit. It hasn't caused bugs because
ordinarily, the only way to have a tmp with no degree is to not have any mention of that tmp. But
while working on bug 163371, I hit a crazy corner case where a temporary would have no
interference edges (i.e. no degree). Here's how it happens:
A spill tmp from a previous iteration of IRC may have no degree: imagine a tmp that is live
everywhere and interferes with everyone, but has one use like:
Move %ourTmp, %someOtherTmp
Where there are no other tmps live. After spill conversion, this may look like:
Move (ourSpill), %newTmp
Move %newTmp, %someOtherTmp
Of course, we'd rather not get this kind of spill code but it's totally possible because we now
have a bunch of random conditions under which we won't slap the spill address directly into the
Move.
After this happens, assuming that the only thing live was %someOtherTmp, we will have zero degree
for %newTmp because the Move is coalescable and does not contribute to interference.
Then, we might coalesce %someOtherTmp with %newTmp. Once this happens, if we make the %newTmp be
the master, we're in deep trouble because %newTmp is not on any worklist.
I don't know how to reproduce this except through the patch in bug 163371. Removing the two lines
of code that skipped no-degree tmps causes no regressions, and resolves the problem I was having.
* b3/air/AirIteratedRegisterCoalescing.cpp:
2016-10-15 Mark Lam <mark.lam@apple.com>
Add a $vm.getpid() method.
https://bugs.webkit.org/show_bug.cgi?id=163493
Reviewed by Saam Barati.
This is especially useful when we need to know the pid of an instance of jsc in
the foreground that we're trying to attach a debugger to while the JSC tests are
running in the background with a gazillion other jsc processes live at the same
time.
Currently, $vm.getpid() is only supported on non-Windows platforms.
According to https://msdn.microsoft.com/en-us/library/ms235372.aspx, getpid() is
deprecated. According to https://msdn.microsoft.com/en-us/library/t2y34y40.aspx,
_getpid() cannot be used in applications that execute in the Windows Runtime.
Since this is only a debugging tool and is not a required feature, I'll defer
the Windows implementation of this function till the time when someone actually
needs it.
* tools/JSDollarVMPrototype.cpp:
(JSC::functionGetPID):
(JSC::JSDollarVMPrototype::finishCreation):
2016-10-15 Saam Barati <sbarati@apple.com>
Assertion failed under operationToLowerCase with a rope with zero length
https://bugs.webkit.org/show_bug.cgi?id=163314
Reviewed by Mark Lam.
There are some ways to get JSC to create empty rope strings. ToLowerCase
inside the DFG/FTL goes to the slow path when the argument is a rope.
operationToLowerCase was calling into a WTF string function that
assumed we are passing it a this value that has non-zero length.
However, we were calling it with a string that did have zero length.
To fix this, we make operationToLowerCase return the empty JSString
if it is going to make a string with zero length.
* dfg/DFGOperations.cpp:
* jsc.cpp:
(GlobalObject::finishCreation):
(functionIsRope):
2016-10-14 Benjamin Poulain <bpoulain@apple.com>
[JSC] op_negate should with any type
https://bugs.webkit.org/show_bug.cgi?id=162587
Reviewed by Saam Barati.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
ArithNegate is quite simple. If the input is double, the output
is double. The other cases are set from the LLInt slow case.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::makeSafe):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
Tweak a bit the IntegerRangeOptimizationPhase when simplifying
ArithAbs to ArithNegate.
We should not do the conversion if the target nodes OSR Exits
on different input than the source node.
In particular, Checked ArithNegate exits on zero while
ArithAbs has not problem with it.
Unchecked ArithAbs() do not OSR Exit on INT_MIN, ArithNeg
should not either.
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithNegate):
(JSC::DFG::SpeculativeJIT::compileMathIC):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileMathIC):
(JSC::FTL::DFG::LowerDFGToB3::compileArithNegate):
* jit/JITNegGenerator.cpp:
(JSC::JITNegGenerator::generateFastPath):
* jit/JITOperations.cpp:
Add result profiling in baseline to have types we can use
in DFG and FTL.
2016-10-14 Keith Miller <keith_miller@apple.com>
B3 needs a special WasmAddress Opcode
https://bugs.webkit.org/show_bug.cgi?id=163394
Reviewed by Filip Pizlo.
This patch adds support for WasmAddress. WasmAddress will be used by
Wasm to compute the address of a memory operation from the pinned
base pointer. WasmAddress takes an IntPtr so we can avoid emitting
unnecessary Move32s in Air. This could happen in the following case:
@ptr = Trunc(...)
WasmAddress(@ptr, pinnedGPR)
...
PatchPoint(...) // Do Wasm call
WasmAddress(@ptr, pinnedGPR)
...
In this case we will not be able to CSE the WasmAddresses since the
call writes to pinnedGPR. Thus if WasmAddress took an Int32 we would need
to emit an extra Move32 at the second WasmAddress to ensure it saw a proper
32-bit value. If Wasm ensures that there there is a leading ZExt32 then
the duplicated moves become unnecessary.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::effectiveAddr):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Opcode.cpp:
(WTF::printInternal):
* b3/B3Opcode.h:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::effects):
* b3/B3WasmAddressValue.cpp: Added.
(JSC::B3::WasmAddressValue::~WasmAddressValue):
(JSC::B3::WasmAddressValue::dumpMeta):
(JSC::B3::WasmAddressValue::cloneImpl):
(JSC::B3::WasmAddressValue::WasmAddressValue):
* b3/B3WasmAddressValue.h: Added.
* b3/testb3.cpp:
(JSC::B3::testWasmAddress):
(JSC::B3::run):
2016-10-14 Joseph Pecoraro <pecoraro@apple.com>
test262: @isConstructor incorrectly thinks Math.cos is a constructor
https://bugs.webkit.org/show_bug.cgi?id=163437
Reviewed by Saam Barati.
* runtime/JSFunction.cpp:
(JSC::JSFunction::getConstructData):
By default, Host JSFunctions are not constructable. They get
the default callHostFunctionAsConstructor native constructor.
When getting construct data we can return ConstructType::None
in these cases instead of indicating it might be constructable
and later throwing an exception when construction is attempted.
2016-10-14 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r207322.
This change caused JSC test failures
Reverted changeset:
"Fix Array.prototype.splice ES6 compliance."
https://bugs.webkit.org/show_bug.cgi?id=163372
http://trac.webkit.org/changeset/207322
2016-10-14 Mark Lam <mark.lam@apple.com>
JSON.parse should not modify frozen objects.
https://bugs.webkit.org/show_bug.cgi?id=163430
Reviewed by Saam Barati.
The ES6 spec for JSON.parse (https://tc39.github.io/ecma262/#sec-json.parse and
https://tc39.github.io/ecma262/#sec-internalizejsonproperty) states that it uses
CreateDataProperty() (https://tc39.github.io/ecma262/#sec-createdataproperty) to
set values returned by a reviver. The spec for CreateDataPropertyOrThrow states:
"This abstract operation creates a property whose attributes are set to the same
defaults used for properties created by the ECMAScript language assignment
operator. Normally, the property will not already exist. If it does exist and is
not configurable or if O is not extensible, [[DefineOwnProperty]] will return
false."
Note: CreateDataProperty() will not throw a TypeError.
Since the properties of frozen objects are not extensible, not configurable, and
not writeable, JSON.parse should fail to write to any frozen objects. Similarly,
JSON.parse should fail to delete properties in frozen objects.
In JSON.parse(), we previously write to array elements using the form of
putDirectIndex() that uses mode PutDirectIndexLikePutDirect. This makes it so
that the write (i.e. put) is always successful. We've now fixed this to use
PutDirectIndexShouldNotThrow mode instead, which will fail to put the element if
the array is not writeable.
Also changed Walker::walk() to use the version of methodTable() that takes a VM&
since the VM& is already available.
* runtime/JSONObject.cpp:
(JSC::Walker::walk):
2016-10-14 Joseph Pecoraro <pecoraro@apple.com>
test262: Failure with RegExp.prototype.compile when pattern is undefined
https://bugs.webkit.org/show_bug.cgi?id=163431
Reviewed by Yusuke Suzuki.
If pattern is undefined let P be the empty String.
https://tc39.github.io/ecma262/#sec-regexpinitialize
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoFuncCompile):
2016-10-13 Joseph Pecoraro <pecoraro@apple.com>
Exception message for expressions with multiple bracket accesses is inconsistent / incorrect
https://bugs.webkit.org/show_bug.cgi?id=163426
Reviewed by Geoffrey Garen.
* bytecompiler/NodesCodegen.cpp:
(JSC::BracketAccessorNode::emitBytecode):
It matters where emitExpressionInfo is called since it gathers
info about where we are in the instruction stream. We need to
emit it before the bytecode that we want to associate the data
with. In this case, before the getById / getByVal.
2016-10-13 Mark Lam <mark.lam@apple.com>
Fix Array.prototype.splice ES6 compliance.
https://bugs.webkit.org/show_bug.cgi?id=163372
Reviewed by Geoffrey Garen and Yusuke Suzuki.
Our Array.prototype.splice implementation neglected to set length on the result
array (step 12 of https://tc39.github.io/ecma262/#sec-array.prototype.splice) in
a certain code path. This is now fixed.
I'm deferring the implementation of step 8 till later because it requires more
careful consideration and the fix is of a lesser value (and therefore, of less
urgency). See https://bugs.webkit.org/show_bug.cgi?id=163417
Also added some needed exception checks and assertions.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncSplice):
2016-10-13 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Stepping highlight for dot/bracket expressions in if statements highlights subset of the expression
https://bugs.webkit.org/show_bug.cgi?id=163378
<rdar://problem/28749376>
Reviewed by Saam Barati.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseAssignmentExpression):
Since each expression builds on the previous, always keep the starting
location the first location.
2016-10-13 Per Arne Vollan <pvollan@apple.com>
[Win64] Compile fix.
https://bugs.webkit.org/show_bug.cgi?id=163384
Reviewed by Brent Fulgham.
Fix use of potentially uninitialized variable.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
2016-10-12 Chris Dumez <cdumez@apple.com>
[Web IDL] Drop support for legacy [ConstructorConditional=*]
https://bugs.webkit.org/show_bug.cgi?id=163368
Reviewed by Ryosuke Niwa.
Drop ENABLE_DOM4_EVENTS_CONSTRUCTOR compiler flag.
* Configurations/FeatureDefines.xcconfig:
2016-10-12 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: step-into `console.log(o)` should not step through inspector javascript
https://bugs.webkit.org/show_bug.cgi?id=161656
<rdar://problem/28181123>
Reviewed by Timothy Hatcher.
* debugger/Debugger.h:
* debugger/Debugger.cpp:
(JSC::Debugger::pauseIfNeeded):
If the Script is blacklisted skip checking if we need to pause.
(JSC::Debugger::isBlacklisted):
(JSC::Debugger::addToBlacklist):
(JSC::Debugger::clearBlacklist):
Add the ability to add a Script to a blacklist. Currently the blacklist
only prevents pausing in the Script.
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::isWebKitInjectedScript):
(Inspector::InspectorDebuggerAgent::didParseSource):
Always add Internal InjectedScripts to the Debugger's blacklist.
(Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
Clear blacklists when clearing debugger state.
2016-10-12 Keith Miller <keith_miller@apple.com>
B3 needs a special WasmBoundsCheck Opcode
https://bugs.webkit.org/show_bug.cgi?id=163246
Reviewed by Filip Pizlo.
This patch adds a new Opcode, WasmBoundsCheck, as well as a B3::Value subclass for it,
WasmBoundsCheckValue. WasmBoundsCheckValue takes three pieces of information. The first is
the Int32 pointer value used to be used by the Load. Next is the pinned register. The
pinned register must be pinned by calling proc.setPinned() prior to compiling the
Procedure. Lastly, the WasmBoundsCheckValue takes an offset. The WasmBoundsCheckValue is
will then emit code that side-exits if the Int64 sum of the offset and pointer is greater
than or equal to the value in the pinnedRegister. Instead of taking a generator for each
value like Check/Patchpoint, WasmBoundsCheck gets its generator directly off Air::Code. In
Air this patch adds a new Custom opcode, WasmBoundsCheck.
In the future we should add WasmBoundsCheck to CSE so it can eliminate redundant bounds
checks. At the first cut, we can remove any WasmBoundsCheck dominated by another
WasmBoundsCheck with the same pointer and pinnedGPR, and a larger offset.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::imm):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Opcode.cpp:
(WTF::printInternal):
* b3/B3Opcode.h:
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::setWasmBoundsCheckGenerator):
* b3/B3Procedure.h:
(JSC::B3::Procedure::setWasmBoundsCheckGenerator):
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::effects):
(JSC::B3::Value::typeFor):
* b3/B3WasmBoundsCheckValue.cpp: Added.
(JSC::B3::WasmBoundsCheckValue::~WasmBoundsCheckValue):
(JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
(JSC::B3::WasmBoundsCheckValue::dumpMeta):
* b3/B3WasmBoundsCheckValue.h: Added.
(JSC::B3::WasmBoundsCheckValue::accepts):
(JSC::B3::WasmBoundsCheckValue::pinnedGPR):
(JSC::B3::WasmBoundsCheckValue::offset):
* b3/air/AirCode.h:
(JSC::B3::Air::Code::setWasmBoundsCheckGenerator):
(JSC::B3::Air::Code::wasmBoundsCheckGenerator):
* b3/air/AirCustom.cpp:
(JSC::B3::Air::WasmBoundsCheckCustom::isValidForm):
* b3/air/AirCustom.h:
(JSC::B3::Air::WasmBoundsCheckCustom::forEachArg):
(JSC::B3::Air::WasmBoundsCheckCustom::isValidFormStatic):
(JSC::B3::Air::WasmBoundsCheckCustom::admitsStack):
(JSC::B3::Air::WasmBoundsCheckCustom::isTerminal):
(JSC::B3::Air::WasmBoundsCheckCustom::hasNonArgNonControlEffects):
(JSC::B3::Air::WasmBoundsCheckCustom::generate):
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testWasmBoundsCheck):
(JSC::B3::run):
2016-10-12 Filip Pizlo <fpizlo@apple.com>
The blackening of CellState is a bad way of tracking if the object is being marked for the first time
https://bugs.webkit.org/show_bug.cgi?id=163343
Reviewed by Mark Lam.
When I first added the concept of NewGrey/OldGrey, I had the SlotVisitor store the old cell
state in itself, so that it could use it to decide what to do for reportExtraMemoryVisited().
Then I changed it in a recent commit, because I wanted the freedom to have SlotVisitor visit
multiple objects in tandem. But I never ended up using this capability. Still, I liked the
new way better: instead of the SlotVisitor rembemering the state-before-blackening, we would
make the object's state reflect whether it was black for the first time or not. That seemed
convenient.
Unfortunately it's wrong. After we blacken the object, a concurrent barrier could instantly
grey it. Then we would forget that we are visiting this object for the first time.
Subsequent visits will think that they are not the first. So, we will fail to do the right
thing in reportExtraMemoryVisited().
So, this reverts that change. This is a little more than just a revert, though. I've changed
the terminology a bit. For example, I got tired of reading Black and having to remind myself
that it really means that the object has begun being visited, instead of the more strict
meaning that implies that it has already been visited. We want to say that it's Black or
currently being scanned. I'm going to adopt Siebert's term for this: Anthracite [1]. So, our
black CellState is now called AnthraciteOrBlack.
[1] https://pdfs.semanticscholar.org/7ae4/633265aead1f8835cf7966e179d02c2c8a4b.pdf
* heap/CellState.h:
(JSC::isBlack): Deleted.
(JSC::blacken): Deleted.
* heap/Heap.cpp:
(JSC::Heap::addToRememberedSet):
(JSC::Heap::writeBarrierSlowPath):
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::reportExtraMemoryVisited):
(JSC::Heap::reportExternalMemoryVisited):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::appendToMarkStack):
(JSC::SlotVisitor::visitChildren):
* heap/SlotVisitor.h:
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::reportExtraMemoryVisited):
(JSC::SlotVisitor::reportExternalMemoryVisited):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LowLevelInterpreter.asm:
2016-10-12 Mark Lam <mark.lam@apple.com>
Rename variables in arrayProtoFuncSplice() to match names in the spec.
https://bugs.webkit.org/show_bug.cgi?id=163354
Reviewed by Saam Barati.
This will make it easier to see whether the code matches the spec or not.
Ref: https://tc39.github.io/ecma262/#sec-array.prototype.splice
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncSplice):
2016-10-12 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT][JSC] Explore the way to embed nodeType into JSC::JSType in WebCore
https://bugs.webkit.org/show_bug.cgi?id=163245
Reviewed by Filip Pizlo.
We reserve the highest bit of JSC::JSType for extensions outside JSC.
JSC does not use JSType bits so many: only 52 types are defined.
And we extend CallDOM patchpoint to claim that it does not require a global object.
This global object is used to generate a DOM wrapper. However, nodeType does not require
it since it just returns integer. In the future, we will extend CallDOM to claim
its result type. And we can decide this `requireGlobalObject` condition automatically
according to the result type.
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleDOMJITGetter):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.h:
* dfg/DFGNode.h:
(JSC::DFG::Node::hasCheckDOMPatchpoint):
(JSC::DFG::Node::checkDOMPatchpoint):
(JSC::DFG::Node::hasCallDOMPatchpoint):
(JSC::DFG::Node::callDOMPatchpoint):
(JSC::DFG::Node::hasDOMJIT): Deleted.
(JSC::DFG::Node::domJIT): Deleted.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCallDOM):
(JSC::DFG::SpeculativeJIT::compileCheckDOM):
* domjit/DOMJITCallDOMPatchpoint.h: Copied from Source/JavaScriptCore/domjit/DOMJITGetterSetter.h.
(JSC::DOMJIT::CallDOMPatchpoint::create):
* domjit/DOMJITGetterSetter.h:
* domjit/DOMJITPatchpoint.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
(JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
* jsc.cpp:
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LowLevelInterpreter.asm:
* runtime/JSType.h:
2016-10-12 Keith Miller <keith_miller@apple.com>
Handle non-function, non-undefined comparator in Array.prototype.sort
https://bugs.webkit.org/show_bug.cgi?id=163085
Reviewed by Yusuke Suzuki.
* builtins/ArrayPrototype.js:
(sort.comparatorSort):
(sort.stringSort):
(sort):
2016-10-12 Filip Pizlo <fpizlo@apple.com>
REGRESSION (r207179): ASSERTION FAILED: node.cell != previousCell
https://bugs.webkit.org/show_bug.cgi?id=163337
Reviewed by Mark Lam.
It turns out that HeapSnapshot was not down with revisiting. The concurrent GC is going to be
built around the idea that we can revisit objects many times. This means that any action that
should only take place once per object must check the object's state. This fixes the snapshot
code to do this.
While writing this code, I realized that we're actually doing this check incorrectly, so I
filed bug 163343. That bug requires a race, so we aren't going to see it yet.
* heap/HeapSnapshot.cpp:
(JSC::HeapSnapshot::finalize):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::appendToMarkStack):
(JSC::SlotVisitor::visitChildren):
2016-10-12 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Improve support for logging Proxy objects in console
https://bugs.webkit.org/show_bug.cgi?id=163323
<rdar://problem/28432553>
Reviewed by Timothy Hatcher.
This is based off of similiar patches in Blink for Proxy handling.
* bindings/ScriptValue.cpp:
(Deprecated::ScriptValue::isEqual):
Use strict equality. This is the intent, and it prevents the possibility of triggering
primitive conversion on objects in previous ConsoleMessage argument lists.
* inspector/InjectedScriptSource.js:
(InjectedScript.prototype._propertyDescriptors):
Bail if the object is a Proxy.
(InjectedScript.prototype._describe):
Provide a friendlier name, "Proxy" instead of "ProxyObject".
(InjectedScript.RemoteObject):
When generating a preview for a Proxy object, generate it from the final target
and mark it as lossy so that the object can always be expanded to get the internal
target/handler properties.
* inspector/JSInjectedScriptHost.h:
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::subtype):
New subtype for Proxy objects.
(Inspector::JSInjectedScriptHost::proxyTargetValue):
Resolve the final target value for a Proxy.
* inspector/JSInjectedScriptHostPrototype.cpp:
(Inspector::JSInjectedScriptHostPrototype::finishCreation):
(Inspector::jsInjectedScriptHostPrototypeFunctionProxyTargetValue):
Add the new method.
* inspector/ScriptArguments.cpp:
(Inspector::ScriptArguments::getFirstArgumentAsString):
Avoid triggering Proxy traps on a Proxy object when getting a quick
string description for ConsoleMessages.
* inspector/protocol/Runtime.json:
Add new "proxy" subtype.
2016-10-12 Joseph Pecoraro <pecoraro@apple.com>
Emit DebugHooks uniformly with pause locations instead of having separate pause locations and op_debug emits
https://bugs.webkit.org/show_bug.cgi?id=162809
Reviewed by Geoffrey Garen.
Change how BytecodeGeneration emits debug hooks to be more consistent.
Previously most nodes individually generated their own debug hook
and we asserted that it matched a breakpoint location identified
by the parser. This could get out of sync, or nodes could forget to
emit debug hooks expected by the parser.
With this change, we always check and emit a debug hook for any
node. The default behavior is for BytecodeGenerator::emitNode
to emit the debug hook when emitting the node itself. This covers
the majority of cases (statements).
There are a few exceptions where we continue to need to customize
emitting debug hooks:
1. Nodes with emitBytecodeInConditionContext
- non-Expression nodes customize how they emit their children
- constants conditions may emit nothing, but we had recorded a breakpoint location so emit a debug hook
- always emit one debug hook in case we recorded a breakpoint location, but avoid emitting multiple
in nodes which may call up to the ExpressionNode::emitBytecodeInConditionContext base impl.
2. Specialized Debug Hooks
- such as hooks for Program start/end, debugger statements, etc.
3. Debug Hooks in for..of / for..in that don't correspond to re-emitting nodes
- such as pausing on the assignment expression inside these loops
The majority of nodes no longer have custom emits.
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::emitNodeInTailPosition):
(JSC::BytecodeGenerator::emitNodeInConditionContext):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitDebugHook):
(JSC::BytecodeGenerator::emitEnumeration):
By default, when emitting a node check if we should also emit an op_debug for it.
This default DebugHook is WillExecuteStatement, which is a normal pause point.
* bytecompiler/NodesCodegen.cpp:
(JSC::ConstantNode::emitBytecodeInConditionContext):
(JSC::LogicalNotNode::emitBytecodeInConditionContext):
(JSC::BinaryOpNode::emitBytecodeInConditionContext):
(JSC::LogicalOpNode::emitBytecodeInConditionContext):
The parser would have generated a pause location for these conditions
no matter what constant folding and re-writing these nodes may perform.
So, when emitting these nodes in condition context check if they need
emit their own debug hook.
(JSC::EmptyStatementNode::emitBytecode):
(JSC::ExprStatementNode::emitBytecode):
(JSC::DeclarationStatement::emitBytecode):
(JSC::IfElseNode::emitBytecode):
(JSC::DoWhileNode::emitBytecode):
(JSC::WhileNode::emitBytecode):
(JSC::ForNode::emitBytecode):
(JSC::ContinueNode::emitBytecode):
(JSC::BreakNode::emitBytecode):
(JSC::ReturnNode::emitBytecode):
(JSC::WithNode::emitBytecode):
(JSC::SwitchNode::emitBytecode):
(JSC::ThrowNode::emitBytecode):
No longer need to custom emit debug hooks. The default emitNode will handle these.
(JSC::ForInNode::emitBytecode):
Include extra debug hooks the user expects to return back to the assignment
expression in the loop header before starting the body again. The same is done
for for..of with emitEnumeration.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createExportDefaultDeclaration):
(JSC::ASTBuilder::createExportLocalDeclaration):
These are no longer needed to fake-satisfy assertions. We never wanted to
emit debug hooks for these inner statements because the export statement
will already have the debug hooks.
(JSC::ASTBuilder::createForInLoop):
(JSC::ASTBuilder::createForOfLoop):
Include the correct location where the declaration starts.
(JSC::ASTBuilder::breakpointLocation):
Simplify to a general implementation for Node.
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createForInLoop):
(JSC::SyntaxChecker::createForOfLoop):
Ignore the new extra parameter.
* parser/Nodes.h:
(JSC::Node::needsDebugHook):
(JSC::Node::setNeedsDebugHook):
(JSC::ExpressionNode::needsDebugHook): Deleted.
(JSC::ExpressionNode::setNeedsDebugHook): Deleted.
(JSC::StatementNode::isEmptyStatement): Deleted.
(JSC::StatementNode::needsDebugHook): Deleted.
(JSC::StatementNode::setNeedsDebugHook): Deleted.
Move debug hook logic into the base Node class.
(JSC::StatementNode::isDebuggerStatement):
Provide a way to distinguish a debugger statement.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseForStatement):
Provide the location before the declaration starts.
2016-10-12 Mark Lam <mark.lam@apple.com>
Array.prototype.slice should not modify frozen objects.
https://bugs.webkit.org/show_bug.cgi?id=163338
Reviewed by Filip Pizlo.
1. The ES6 spec for Array.prototype.slice
(https://tc39.github.io/ecma262/#sec-array.prototype.slice) states that it uses
the CreateDataPropertyOrThrow()
(https://tc39.github.io/ecma262/#sec-createdatapropertyorthrow) to add items to
the result array. The spec for CreateDataPropertyOrThrow states:
"This abstract operation creates a property whose attributes are set to the
same defaults used for properties created by the ECMAScript language assignment
operator. Normally, the property will not already exist. If it does exist and
is not configurable or if O is not extensible, [[DefineOwnProperty]] will
return false causing this operation to throw a TypeError exception."
2. Array.prototype.slice also uses a Set function
(https://tc39.github.io/ecma262/#sec-set-o-p-v-throw) to set the "length"
property and passes true for the Throw argument. Ultimately, it ends up
calling the OrdinarySet function
(https://tc39.github.io/ecma262/#sec-ordinaryset) that will fail if the
property is not writable. This failure should result in a TypeError being
thrown in Set.
Since the properties of frozen objects are not extensible, not configurable,
and not writeable, Array.prototype.slice should fail to write to the result
array if it is frozen.
If the source array being sliced has 1 or more elements, (1) will take effect
when we try to set the element in the non-writeable result obj.
If the source array being sliced has 0 elements, we will not set any elements and
(1) will not trigger. Subsequently, (2) will take effect when we will try to
set the length of the result obj.
* runtime/ArrayPrototype.cpp:
(JSC::putLength):
(JSC::setLength):
(JSC::arrayProtoFuncSlice):
(JSC::arrayProtoFuncSplice):
2016-10-12 Filip Pizlo <fpizlo@apple.com>
Remove JITWriteBarrier.h
https://bugs.webkit.org/show_bug.cgi?id=163334
Reviewed by Mark Lam.
I guess that the idea of JITWriteBarrier was to make sure that if you slap some heap pointer
bits into machine code, then you better execute a barrier on the code block. But it's a
complicated piece of code, and I can never remember how it quite works. These days it looks
vestigial, particularly since only the CallLinkInfo patchable callee immediate uses it. It's
not really necessary to have something like this, since our convention is that any pointer
stored in machine code must always be shadowed in the GC heap. I think that convention has
won by overwhelming majority, so we should finally remove JITWriteBarrier.
A practical outcome of this change is that it makes it easier to implement DirectCall ICs,
which will have to store the callee in the CallLinkInfo but not in the machine code.
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/AbstractMacroAssembler.h:
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::setCallee):
(JSC::CallLinkInfo::clearCallee):
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::setCallee): Deleted.
(JSC::CallLinkInfo::clearCallee): Deleted.
* heap/SlotVisitor.h:
* jit/JITWriteBarrier.h: Removed.
2016-10-12 Csaba Osztrogonác <ossy@webkit.org>
Unreviewed buildfix for GCC 4.9 after r207186.
https://bugs.webkit.org/show_bug.cgi?id=163255
* runtime/HasOwnPropertyCache.h:
(JSC::HasOwnPropertyCache::Entry::Entry):
2016-10-11 Saam Barati <sbarati@apple.com>
HasOwnPropertyCache needs to ref the UniquedStringImpls it sees
https://bugs.webkit.org/show_bug.cgi?id=163255
Reviewed by Geoffrey Garen.
The cache needs to be responsible for ensuring that things
in the cache stay alive. Before, it wasn't doing this, and
that was wrong.
* runtime/HasOwnPropertyCache.h:
(JSC::HasOwnPropertyCache::Entry::operator=):
(JSC::HasOwnPropertyCache::operator delete):
(JSC::HasOwnPropertyCache::create):
(JSC::HasOwnPropertyCache::get):
(JSC::HasOwnPropertyCache::tryAdd):
(JSC::HasOwnPropertyCache::clear):
(JSC::HasOwnPropertyCache::zeroBuffer):
2016-10-06 Filip Pizlo <fpizlo@apple.com>
MarkedBlock should know what objects are live during marking
https://bugs.webkit.org/show_bug.cgi?id=162309
Reviewed by Geoffrey Garen.
It used to be that we would forget which objects are live the moment we started collection.
That's because the flip at the beginning clears all mark bits.
But we already have a facility for tracking objects that are live-but-not-marked. It's called
newlyAllocated. So, instead of clearing mark bits, we want to just transfer them to
newlyAllocated. Then we want to clear all newlyAllocated after GC.
This implements such an approach, along with a versioning optimization for newlyAllocated.
Instead of walking the whole heap to clear newlyAllocated bits at the end of the GC, we bump
the newlyAllocatedVersion, which causes MarkedBlock to treat newlyAllocated as if it was
clear.
We could have even avoided allocating newlyAllocated in most cases, since empirically most
blocks are either completely empty or completely full. An earlier version of this patch did
this, but it was not better than this patch. In fact, it seemed to actually be worse for PLT
and membuster.
To validate this change, we now run the conservative scan after the beginMarking flip. And it
totally works!
This is a huge step towards concurrent GC. It means that we ought to be able to run the
allocator while marking. Since we already separately made it possible to run the barrier
while marking, this means that we're pretty much ready for some serious concurrency action.
This appears to be perf-neutral and space-neutral.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
* bytecode/CodeBlock.h:
(JSC::CodeBlockSet::mark): Deleted.
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::writeBarrierCurrentlyExecuting):
(JSC::CodeBlockSet::clearCurrentlyExecuting):
(JSC::CodeBlockSet::writeBarrierCurrentlyExecutingCodeBlocks): Deleted.
* heap/CodeBlockSet.h:
* heap/CodeBlockSetInlines.h: Added.
(JSC::CodeBlockSet::mark):
* heap/ConservativeRoots.cpp:
* heap/Heap.cpp:
(JSC::Heap::markRoots):
(JSC::Heap::beginMarking):
(JSC::Heap::collectImpl):
(JSC::Heap::writeBarrierCurrentlyExecutingCodeBlocks):
(JSC::Heap::clearCurrentlyExecutingCodeBlocks):
* heap/Heap.h:
* heap/HeapUtil.h:
(JSC::HeapUtil::findGCObjectPointersForMarking):
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::isPagedOut):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::Handle):
(JSC::MarkedBlock::Handle::sweepHelperSelectHasNewlyAllocated):
(JSC::MarkedBlock::Handle::stopAllocating):
(JSC::MarkedBlock::Handle::lastChanceToFinalize):
(JSC::MarkedBlock::Handle::resumeAllocating):
(JSC::MarkedBlock::aboutToMarkSlow):
(JSC::MarkedBlock::Handle::resetAllocated):
(JSC::MarkedBlock::resetMarks):
(JSC::MarkedBlock::setNeedsDestruction):
(JSC::MarkedBlock::Handle::didAddToAllocator):
(JSC::MarkedBlock::Handle::isLive):
(JSC::MarkedBlock::Handle::isLiveCell):
(JSC::MarkedBlock::clearMarks): Deleted.
* heap/MarkedBlock.h:
(JSC::MarkedBlock::Handle::newlyAllocatedVersion):
(JSC::MarkedBlock::Handle::hasAnyNewlyAllocated): Deleted.
(JSC::MarkedBlock::Handle::clearNewlyAllocated): Deleted.
* heap/MarkedBlockInlines.h:
(JSC::MarkedBlock::Handle::cellsPerBlock):
(JSC::MarkedBlock::Handle::isLive):
(JSC::MarkedBlock::Handle::isLiveCell):
(JSC::MarkedBlock::Handle::isNewlyAllocatedStale):
(JSC::MarkedBlock::Handle::hasAnyNewlyAllocatedWithSweep):
(JSC::MarkedBlock::Handle::hasAnyNewlyAllocated):
(JSC::MarkedBlock::heap):
(JSC::MarkedBlock::space):
(JSC::MarkedBlock::Handle::space):
(JSC::MarkedBlock::resetMarkingVersion): Deleted.
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::beginMarking):
(JSC::MarkedSpace::endMarking):
(JSC::MarkedSpace::clearNewlyAllocated): Deleted.
* heap/MarkedSpace.h:
(JSC::MarkedSpace::nextVersion):
(JSC::MarkedSpace::newlyAllocatedVersion):
(JSC::MarkedSpace::markingVersion): Deleted.
* runtime/SamplingProfiler.cpp:
2016-10-11 Mark Lam <mark.lam@apple.com>
Array.prototype.concat should not modify frozen objects.
https://bugs.webkit.org/show_bug.cgi?id=163302
Reviewed by Filip Pizlo.
The ES6 spec for Array.prototype.concat states that it uses the
CreateDataPropertyOrThrow() to add items to the result array. The spec for
CreateDataPropertyOrThrow states:
"This abstract operation creates a property whose attributes are set to the same
defaults used for properties created by the ECMAScript language assignment
operator. Normally, the property will not already exist. If it does exist and is
not configurable or if O is not extensible, [[DefineOwnProperty]] will return
false causing this operation to throw a TypeError exception."
Since the properties of frozen objects are not extensible, not configurable, and
not writable, Array.prototype.concat should fail to write to the result array if
it is frozen.
Ref: https://tc39.github.io/ecma262/#sec-array.prototype.concat,
https://tc39.github.io/ecma262/#sec-createdatapropertyorthrow, and
https://tc39.github.io/ecma262/#sec-createdataproperty.
The fix consists of 2 parts:
1. moveElement() should use the PutDirectIndexShouldThrow mode when invoking
putDirectIndex(), and
2. SparseArrayValueMap::putDirect() should check for the case where the property
is read only.
(2) ensures that we don't write into a non-writable property.
(1) ensures that we throw a TypeError for attempts to write to a non-writeable
property.
* runtime/ArrayPrototype.cpp:
(JSC::moveElements):
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::putDirect):
2016-10-11 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT] DOMJIT::Patchpoint should have a way to receive constant folded arguments
https://bugs.webkit.org/show_bug.cgi?id=163224
Reviewed by Filip Pizlo.
We use the GetGlobalObject DFG node to retrieve a global object from a DOM node.
This global object is necessary to check whether the world is normal before entering
the fast path of looking up the DOM wrapper cache.
We can sometimes constant-fold this GetGlobalObject. For example, if we performed
CheckStructure, the structure can offer the information about the possible result
of GetGlobalObject. By using this constant-folded global object, we can drop some
checks.
This patch introduces the way to tell the constant-folded values to DOMJIT::Patchpoint.
We pass DOMJIT::Value instead of DOMJIT::Reg as a parameter of DOMJIT::PatchpointParams.
This DOMJIT::Value is a pair of DOMJIT::Reg and JSValue. If the given parameter has a
constant value, this JSValue is filled with it.
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGDOMJITPatchpointParams.h:
(JSC::DFG::DOMJITPatchpointParams::DOMJITPatchpointParams):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCallDOM):
(JSC::DFG::SpeculativeJIT::compileCheckDOM):
* domjit/DOMJITPatchpointParams.h:
(JSC::DOMJIT::PatchpointParams::at):
(JSC::DOMJIT::PatchpointParams::operator[]):
(JSC::DOMJIT::PatchpointParams::PatchpointParams):
* domjit/DOMJITValue.h: Copied from Source/JavaScriptCore/dfg/DFGDOMJITPatchpointParams.h.
(JSC::DOMJIT::Value::Value):
(JSC::DOMJIT::Value::isGPR):
(JSC::DOMJIT::Value::isFPR):
(JSC::DOMJIT::Value::isJSValueRegs):
(JSC::DOMJIT::Value::gpr):
(JSC::DOMJIT::Value::fpr):
(JSC::DOMJIT::Value::jsValueRegs):
(JSC::DOMJIT::Value::reg):
(JSC::DOMJIT::Value::value):
* ftl/FTLDOMJITPatchpointParams.h:
(JSC::FTL::DOMJITPatchpointParams::DOMJITPatchpointParams):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
(JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
2016-10-10 Filip Pizlo <fpizlo@apple.com>
Air should be able to replace constant materializations with adds
https://bugs.webkit.org/show_bug.cgi?id=162749
Reviewed by Yusuke Suzuki.
We have a lot of defenses against emitting code that materializes huge contants. But if we do
end up with such code in the backend, it's better to convert those materializations into add
instructions by checking if other registers are known to contain nearby constants. That's
what this patch does.
* b3/air/AirFixObviousSpills.cpp:
* b3/testb3.cpp:
2016-10-11 Filip Pizlo <fpizlo@apple.com>
B3->Air lowering needs the same defenses in effectiveAddr() that it has in tryAppendLea()
https://bugs.webkit.org/show_bug.cgi?id=163264
Reviewed by Mark Lam.
When writing the lea patch (r207039), I was very careful about how I convert a Shl into a
BaseIndex scale. But I forgot to check if the older code for creating BaseIndexes for
effectiveAddr() got this right. It turns out that the older code missed the <<32 corner
case.
It's sad that the two paths can't share all of their code, but it's somewhat inevitable due
to how matching an address and matching a lea have to do very different things. Matching a
lea means creating an instruction that is distinct from other instructions to do multiple
math operations at once. Matching an address means making some instruction do extra work
for free. Also, address matching can take advantage of the fact that the offset is already
associated with the memory operation by strength reduction - lea matching can't do this; it
has to figure out Add(@value, $const) on its own. This change makes the situation slightly
more sane by adding a scaleForShl() helper that handles this weird case. It's based on the
new Shl handling from r207039, and exposes it as an API for effectiveAddr() to use.
The testLoadBaseIndexShift32() used to crash. I don't think that this case affects JS
content, since <<32 is such a bizarre outlier. I don't think we even have a path along
which the FTL would emit a 64-bit <<32. It probably won't even affect WebAssembly since
that uses 32-bit pointers, so we won't see 64-bit <<32 in effectiveAddr() there.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::scaleForShl):
(JSC::B3::Air::LowerToAir::effectiveAddr):
(JSC::B3::Air::LowerToAir::tryAppendLea):
(JSC::B3::Air::LowerToAir::crossesInterference): Deleted.
* b3/testb3.cpp:
(JSC::B3::testLoadBaseIndexShift2):
(JSC::B3::testLoadBaseIndexShift32):
(JSC::B3::run):
2016-10-11 Saam Barati <sbarati@apple.com>
ValueAdd should be constant folded if the operands are constant String,Primitive or Primitive,String
https://bugs.webkit.org/show_bug.cgi?id=163182
Reviewed by Filip Pizlo.
This code pattern shows up in Dromaeo, so it's worth optimizing for.
This might also show up in real world JS code due to inlining and other
types of constant folding.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGLazyJSValue.cpp:
(JSC::DFG::LazyJSValue::getValue):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
2016-10-10 Zan Dobersek <zdobersek@igalia.com>
Add ENABLE_ENCRYPTED_MEDIA configuration option
https://bugs.webkit.org/show_bug.cgi?id=163219
Reviewed by Darin Adler.
* Configurations/FeatureDefines.xcconfig:
Add the ENABLE_ENCRYPTED_MEDIA configuration option. It will be used
to enable or disable the new EME implementation at build-time.
2016-10-10 Filip Pizlo <fpizlo@apple.com>
B3->Air lowering should be able to emit complex leas on x86
https://bugs.webkit.org/show_bug.cgi?id=163234
Reviewed by Saam Barati.
This adds comprehensive support for emitting lea on x86.
When adding this, I found that it was useful to also finally add more reassociation. That
reduces the amount of patterns that the instruction selector has to deal with.
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::lea32):
(JSC::MacroAssembler::lea64):
(JSC::MacroAssembler::lea): Deleted.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::commitInternal):
(JSC::B3::Air::LowerToAir::tryAppendLea):
(JSC::B3::Air::LowerToAir::lower):
(JSC::B3::Air::LowerToAir::createSelect): Deleted.
* b3/B3ReduceStrength.cpp:
* b3/B3Value.h:
* b3/B3ValueInlines.h:
(JSC::B3::Value::isRepresentableAs):
(JSC::B3::Value::representableAs): Deleted.
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp: Lots of tests for lea and reassociation.
2016-10-10 Mark Lam <mark.lam@apple.com>
Change ArrayPrototype.cpp's putLength() and setLength() to take a VM& so that we can use vm.propertyNames.
https://bugs.webkit.org/show_bug.cgi?id=163260
Reviewed by Saam Barati.
In all cases where we call these, we already have the VM& anyway.
* runtime/ArrayPrototype.cpp:
(JSC::putLength):
(JSC::setLength):
(JSC::arrayProtoFuncPop):
(JSC::arrayProtoFuncPush):
(JSC::arrayProtoFuncShift):
(JSC::arrayProtoFuncSlice):
(JSC::arrayProtoFuncSplice):
(JSC::arrayProtoFuncUnShift):
2016-10-10 Mark Lam <mark.lam@apple.com>
Rename the StrictModeReadonlyPropertyWriteError string to ReadonlyPropertyWriteError.
https://bugs.webkit.org/show_bug.cgi?id=163239
Reviewed by Filip Pizlo.
This string is also used for reporting the same error in cases which have nothing
to do with strict mode.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/GetterSetter.cpp:
(JSC::callSetter):
* runtime/JSArray.cpp:
(JSC::JSArray::setLengthWithArrayStorage):
(JSC::JSArray::pop):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive):
(JSC::JSValue::putToPrimitiveByIndex):
* runtime/JSFunction.cpp:
(JSC::JSFunction::put):
* runtime/JSModuleEnvironment.cpp:
(JSC::JSModuleEnvironment::put):
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::put):
(JSC::JSModuleNamespaceObject::putByIndex):
* runtime/JSObject.cpp:
(JSC::ordinarySetSlow):
(JSC::JSObject::putInlineSlow):
(JSC::JSObject::setPrototypeWithCycleCheck):
(JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
(JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
* runtime/JSObject.h:
* runtime/JSObjectInlines.h:
(JSC::JSObject::putInline):
* runtime/JSSymbolTableObject.h:
(JSC::symbolTablePut):
* runtime/Lookup.h:
(JSC::putEntry):
* runtime/RegExpObject.h:
(JSC::RegExpObject::setLastIndex):
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::putEntry):
(JSC::SparseArrayEntry::put):
* runtime/StringObject.cpp:
(JSC::StringObject::put):
(JSC::StringObject::putByIndex):
2016-10-10 Saam Barati <sbarati@apple.com>
compileCheckStringIdent in the FTL is wrong
https://bugs.webkit.org/show_bug.cgi?id=163215
Reviewed by Mark Lam and Filip Pizlo.
lowStringIdent() returns the StringImpl pointer. The compileCheckStringIdent()
was treating its return value as the actual JSString. This is wrong.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCheckStringIdent):
2016-10-10 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT] Implement Node accessors in DOMJIT
https://bugs.webkit.org/show_bug.cgi?id=163005
Reviewed by Filip Pizlo.
Add some helper methods and offsetOfXXX for JSC::Weak since it is used
for DOM wrapper caching.
And make DOMJIT::Patchpoint in FTL closer to one in DFG. We add resultConstraint
to avoid the situation that the same register is allocated to child and result.
We also extend DOMJIT::Patchpoint to tell useTagTypeNumberRegister / useTagMaskRegister.
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* domjit/DOMJITSlowPathCalls.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
(JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
* heap/WeakImpl.h:
(JSC::WeakImpl::offsetOfJSValue):
(JSC::WeakImpl::offsetOfWeakHandleOwner):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::boxCell):
(JSC::AssemblyHelpers::boxInt32): Deleted.
* jit/JITOperations.h:
2016-10-09 Filip Pizlo <fpizlo@apple.com>
Air should expose API for pinning registers
https://bugs.webkit.org/show_bug.cgi?id=163175
Reviewed by Keith Miller.
You can now call Procedure::pinRegister(), or Code::pinRegister(), and it will make this
register behave as follows:
- B3 and Air will emit no code that modifies the value in this register, except if that
happens via a Patchpoint or stackmap constraint (i.e. the user explicitly asked for it).
- B3 and Air will allow others to modify the register. For example, if the register is not
callee-save, then the compiler knows that the register's value will be trashed by any
C-style call.
- Air will be happy to emit code that reads from this register, including coalescing tmps
with it, so longer as there is no interference (i.e. no chance of the register's value
changing). For example, if we went back to having pinned tag registers, we would tell B3
to use them by (1) excluding them from any clobber set (easy, since they're callee save)
and (2) emitting ArgumentReg to grab their value. There's a test that does this.
This is accomplished by taking regsInPriorityOrder() and making it a method of Code. Air
already used this API when choosing registers in register allocation. Code now also vends a
mutableRegs() set, which is derived from regsInPriorityOrder(), that can quickly tell you if
a register can be mutated. Doing it this way means that most of this is a purely mechanical
change. The calls to mutableRegs() are the places where we had to change logic:
- The register allocators needs to know that coalescing with a precolored pinned tmp is free.
- The callee-save handler needs to know that we're not supposed to save/restore pinned
registers.
Note that in this scheme, pinned registers are simply registers that do not appear in
regsInPriorityOrder(). This means, for example, that we will now say that FP is pinned. So,
this means that you can also pin registers by calling setRegsInPriorityOrder() and passing a
vector that excludes some registers. More generally, this means that clients can now tweak
the register allocator's register preferences, since the ordering in that list reflects the
order in which the allocator will try registers.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::pinRegister):
* b3/B3Procedure.h:
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::Code):
(JSC::B3::Air::Code::setRegsInPriorityOrder):
(JSC::B3::Air::Code::pinRegister):
* b3/air/AirCode.h:
(JSC::B3::Air::Code::regsInPriorityOrder):
(JSC::B3::Air::Code::mutableRegs):
(JSC::B3::Air::Code::isPinned):
(JSC::B3::Air::Code::regsInPriorityOrderImpl):
(JSC::B3::Air::Code::proc): Deleted.
* b3/air/AirEmitShuffle.cpp:
(JSC::B3::Air::emitShuffle):
* b3/air/AirEmitShuffle.h:
* b3/air/AirHandleCalleeSaves.cpp:
(JSC::B3::Air::handleCalleeSaves):
* b3/air/AirIteratedRegisterCoalescing.cpp:
* b3/air/AirLowerAfterRegAlloc.cpp:
(JSC::B3::Air::lowerAfterRegAlloc):
* b3/air/AirRegisterPriority.cpp: Removed.
* b3/air/AirRegisterPriority.h: Removed.
* b3/air/AirSpillEverything.cpp:
(JSC::B3::Air::spillEverything):
* b3/air/testair.cpp:
(JSC::B3::Air::testShuffleBroadcastAllRegs):
(JSC::B3::Air::testShuffleShiftAllRegs):
(JSC::B3::Air::testShuffleRotateAllRegs):
(JSC::B3::Air::testShuffleShiftMemoryAllRegs):
(JSC::B3::Air::testShuffleShiftMemoryAllRegs64):
(JSC::B3::Air::testShuffleShiftMemoryAllRegsMixedWidth):
(JSC::B3::Air::testShuffleRotateMemoryAllRegs64):
(JSC::B3::Air::testShuffleRotateMemoryAllRegsMixedWidth):
* b3/testb3.cpp:
(JSC::B3::testPinRegisters):
(JSC::B3::run):
* jit/RegisterSet.h:
2016-10-08 Filip Pizlo <fpizlo@apple.com>
B3 should know about mutable pinned registers
https://bugs.webkit.org/show_bug.cgi?id=163172
Reviewed by Keith Miller.
If we have mutable pinned registers then we need to know which operations mutate them. At
first I considered making this into a heap range thing, but I think that this would be very
confusing. Also, in the future, we might want to make Effects track register sets of
clobbered registers (see bug 163173).
* b3/B3Effects.cpp:
(JSC::B3::Effects::interferes):
(JSC::B3::Effects::operator==):
(JSC::B3::Effects::dump):
* b3/B3Effects.h:
(JSC::B3::Effects::forCall):
(JSC::B3::Effects::mustExecute):
2016-10-08 Saam Barati <sbarati@apple.com>
HasIndexedProperty clobberize rule is wrong for Array::ForceOSRExit
https://bugs.webkit.org/show_bug.cgi?id=159942
<rdar://problem/27328836>
Reviewed by Filip Pizlo.
When HasIndexedProperty has a ForceOSRExit array mode, it should
report to write to side state, like the ForceOSRExit node, and the
other nodes with ForceOSRExit array mode.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
2016-10-07 Mark Lam <mark.lam@apple.com>
Object.freeze() and seal() should throw if [[PreventExtensions]]() fails.
https://bugs.webkit.org/show_bug.cgi?id=163160
Reviewed by Saam Barati.
See https://tc39.github.io/ecma262/#sec-object.freeze,
https://tc39.github.io/ecma262/#sec-object.seal, and
https://tc39.github.io/ecma262/#sec-setintegritylevel. We need to call
preventExtensions first before proceeding to freeze / seal the object. If
preventExtensions fails, we should throw a TypeError.
* runtime/ObjectConstructor.cpp:
(JSC::setIntegrityLevel):
(JSC::objectConstructorSeal):
(JSC::objectConstructorFreeze):
2016-10-06 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT] Support slow path call
https://bugs.webkit.org/show_bug.cgi?id=162978
Reviewed by Saam Barati.
One of the most important features required in DOMJIT::Patchpoint is slow path calls.
DOM operation typically returns DOMWrapper object. At that time, if wrapper cache hits, we can go
to the fast path. However, if we cannot use the cache, we need to go to the slow path to call toJS function.
At that time, slow path call functionality is necessary.
This patch expose DOMJIT::PatchpointParams::addSlowPathCall. We can request slow path call code generation
through this interface. DOMJIT::PatchpointParams automatically leverages appropriate slow path call systems
in each tier. In DFG, we use slow path call system. In FTL, we implement slow path call by using addLatePath
to construct slow path call. But these details are completely hidden by DOMJIT::PatchpointParams. Users can
just use addSlowPathCall.
Since DFG and FTL slow path call systems are implemented in variadic templates, directly using this means
that we need to expose core part of DFG and FTL. For example, DFG::SpeculativeJIT need to be exposed in
such a design. That is too bad. Instead, we use magical macro in DOMJITSlowPathCalls.h. We can list up the
call signatures in DOMJIT_SLOW_PATH_CALLS. DOMJIT uses these signatures to generate an interface to request
slow path calls inside DFG and FTL instead of exposing everything.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGCommon.h:
* dfg/DFGDOMJITPatchpointParams.cpp: Copied from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
(JSC::DFG::dispatch):
* dfg/DFGDOMJITPatchpointParams.h: Copied from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
(JSC::DFG::DOMJITPatchpointParams::DOMJITPatchpointParams):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCallDOM):
(JSC::DFG::SpeculativeJIT::compileCheckDOM):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::extractResult): Deleted.
* domjit/DOMJITPatchpointParams.h:
(JSC::DOMJIT::PatchpointParams::addSlowPathCall):
* domjit/DOMJITSlowPathCalls.h: Copied from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
* ftl/FTLDOMJITPatchpointParams.cpp: Added.
(JSC::FTL::dispatch):
* ftl/FTLDOMJITPatchpointParams.h: Copied from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
(JSC::FTL::DOMJITPatchpointParams::DOMJITPatchpointParams):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
(JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
* jit/GPRInfo.h:
(JSC::extractResult):
* jsc.cpp:
2016-10-06 Saam Barati <sbarati@apple.com>
HasOwnPropertyCache flattening dictionaries is causing insane memory usage with the uBlock Safari extension
https://bugs.webkit.org/show_bug.cgi?id=163091
Reviewed by Mark Lam.
I'm investigating a real fix for this in:
https://bugs.webkit.org/show_bug.cgi?id=163092
However, it's best to get this out of trunk for now.
* runtime/HasOwnPropertyCache.h:
(JSC::HasOwnPropertyCache::tryAdd):
2016-10-06 Keith Miller <keith_miller@apple.com>
getInternalObjcObject should validate the JSManagedObject's value.
https://bugs.webkit.org/show_bug.cgi?id=162985
Reviewed by Geoffrey Garen.
Previously, if, for instance, the JSManagedObject's weak value had been
cleared we would call tryUnwrapObjcObject with a nil context and value.
This triggered assertions failures as those functions expect their inputs
to be valid.
* API/JSVirtualMachine.mm:
(getInternalObjcObject):
2016-10-06 Brian Burg <bburg@apple.com>
Web Inspector: RemoteInspector should cache client capabilities for off-main thread usage
https://bugs.webkit.org/show_bug.cgi?id=163039
<rdar://problem/28571460>
Reviewed by Timothy Hatcher.
The fix in r206797 was incorrect because listings are always pushed out on the XPC connection queue.
Instead of delaying the listing needlessly, RemoteInspector should cache the capabilities of its
client while on the main thread, then use the cached struct data on the XPC connection queue rather
than directly accessing m_client. This is similar to how RemoteConnectionToTarget marshalls listing
information from arbitrary queues into m_targetListingMap, which can then be read from any queue.
* inspector/remote/RemoteInspector.h:
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::updateClientCapabilities): Cache the capabilities.
(Inspector::RemoteInspector::setRemoteInspectorClient):
Re-cache the capabilities. Scope the lock to avoid reentrant locking.
(Inspector::RemoteInspector::clientCapabilitiesDidChange): Cache the capabilities.
(Inspector::RemoteInspector::pushListingsNow): Use cached client capabilities.
(Inspector::RemoteInspector::receivedGetListingMessage): Revert the change in r206797.
(Inspector::RemoteInspector::receivedAutomationSessionRequestMessage):
2016-10-06 Yusuke Suzuki <utatane.tea@gmail.com>
[WebCore][JSC] Use new @throwTypeError and @throwRangeError intrinsics
https://bugs.webkit.org/show_bug.cgi?id=163001
Reviewed by Keith Miller.
Previously, the argument of @throwXXXError intrinsics must be string literal.
But it is error-prone restriction. This patch relaxes the restriction to accept
arbitrary values. To keep emitted bytecode small, if the argument is string literal,
we generate the same bytecode as before. If the argument is not string literal,
we evaluate it and perform to_string before passing to throw_static_error.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitThrowStaticError):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::BytecodeIntrinsicNode::emit_intrinsic_throwTypeError):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_throwRangeError):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
2016-10-05 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Add @throwXXXError bytecode intrinsic
https://bugs.webkit.org/show_bug.cgi?id=162995
Reviewed by Saam Barati.
Builtin JS code need to check arguments carefully since it is somewhat standard library for JS.
So bunch of `throw new @TypeError("...")` exists while usual code does not have so many.
However the above code bloats 32 instructions per site, enlarges the size of bytecodes of builtins,
and prevent us from inlining. We should have a way to reduce this size.
Fortunately, we already have such a opcode: op_throw_static_error. In this patch,
1. We extends op_throw_static_error to throw arbitrary errors. Previously, only TypeError and ReferenceError are allowed.
We can embed ErrorType enum in op_throw_static_error to throw any types of errors.
2. We introduce several new bytecode intrinsics, `@throwTypeError("...")`, `@throwRangeError("...")`,
and `@throwOutOfMemoryError()`. And use it inside builtin JS instead of `throw new @TypeError("...")` thingy.
3. DFG Node for throw_static_error is incorrectly named as "ThrowReferenceError". This patch renames it to "ThrowStaticError".
* builtins/ArrayConstructor.js:
* builtins/ArrayIteratorPrototype.js:
(next):
* builtins/ArrayPrototype.js:
(values):
(keys):
(entries):
(reduce):
(reduceRight):
(every):
(forEach):
(filter):
(map):
(some):
(fill):
(find):
(findIndex):
(includes):
(sort):
(concatSlowPath):
(copyWithin):
* builtins/DatePrototype.js:
(toLocaleString.toDateTimeOptionsAnyAll):
(toLocaleString):
(toLocaleDateString.toDateTimeOptionsDateDate):
(toLocaleDateString):
(toLocaleTimeString.toDateTimeOptionsTimeTime):
(toLocaleTimeString):
* builtins/FunctionPrototype.js:
(bind):
* builtins/GeneratorPrototype.js:
(globalPrivate.generatorResume):
* builtins/GlobalOperations.js:
(globalPrivate.speciesConstructor):
* builtins/MapPrototype.js:
(forEach):
* builtins/ModuleLoaderPrototype.js:
(provide):
* builtins/ObjectConstructor.js:
(values):
(entries):
(assign):
* builtins/PromiseConstructor.js:
(race):
(reject):
(resolve):
* builtins/PromiseOperations.js:
(globalPrivate.newPromiseCapability.executor):
(globalPrivate.newPromiseCapability):
(globalPrivate.initializePromise):
* builtins/PromisePrototype.js:
* builtins/ReflectObject.js:
(apply):
(deleteProperty):
(has):
* builtins/RegExpPrototype.js:
(globalPrivate.regExpExec):
(match):
(replace):
(search):
(split):
(intrinsic.RegExpTestIntrinsic.test):
* builtins/SetPrototype.js:
(forEach):
* builtins/StringConstructor.js:
(raw):
* builtins/StringIteratorPrototype.js:
(next):
* builtins/StringPrototype.js:
(match):
(globalPrivate.repeatSlowPath):
(repeat):
(padStart):
(padEnd):
(intrinsic.StringPrototypeReplaceIntrinsic.replace):
(localeCompare):
(search):
(split):
* builtins/TypedArrayConstructor.js:
(of):
(from):
* builtins/TypedArrayPrototype.js:
(globalPrivate.typedArraySpeciesConstructor):
(every):
(find):
(findIndex):
(forEach):
(some):
(subarray):
(reduce):
(reduceRight):
(map):
(filter):
* bytecode/BytecodeIntrinsicRegistry.h:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitThrowStaticError):
(JSC::BytecodeGenerator::emitThrowReferenceError):
(JSC::BytecodeGenerator::emitThrowTypeError):
(JSC::BytecodeGenerator::emitThrowRangeError):
(JSC::BytecodeGenerator::emitThrowOutOfMemoryError):
(JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::BytecodeIntrinsicNode::emit_intrinsic_throwTypeError):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_throwRangeError):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_throwOutOfMemoryError):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_throw_static_error):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_throw_static_error): Deleted.
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted.
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* runtime/Error.cpp:
(JSC::createError):
(WTF::printInternal):
* runtime/Error.h:
2016-10-05 Yusuke Suzuki <utatane.tea@gmail.com>
Unreviewed, attempt to fix CLoop build after r206846
https://bugs.webkit.org/show_bug.cgi?id=162941
Attempt to fix CLoop build part 2. r206847 was not valid.
* jsc.cpp:
2016-10-05 Yusuke Suzuki <utatane.tea@gmail.com>
Unreviewed, build fix after r206846
https://bugs.webkit.org/show_bug.cgi?id=162941
DOMJIT::Patchpoint part should be guarded by ENABLE(JIT).
* jsc.cpp:
2016-10-05 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT] Add initial CheckDOM and CallDOM implementations
https://bugs.webkit.org/show_bug.cgi?id=162941
Reviewed by Filip Pizlo.
This patch implements a prototype of DOMJIT accelerated getter.
We add two new DFG nodes, CheckDOM and CallDOM.
CheckDOM is used to filter inappropriate |this| object for DOM getter. Its functionality
is equivalent to jsDynamicCast's Check. You can use like "CheckDOM, @1, JSNode::info()",
and this CheckDOM incurs a BadType exit if the class of the given @1 is not a subclass of
JSNode::info().
CallDOM is used to emit actual DOM operations. It takes GlobalObject and checked DOM
object. And it returns JSValue as its result.
Both CheckDOM and CallDOM can take a DOMJIT::Patchpoint. This is somewhat code snippet
generator, and is injectable to DFG and FTL. DFG and FTL set up registers correctly
according to DOMJIT::Patchpoint's requirement and invoke this patchpoint generator to emit code.
While CallDOM always requires a patchpoint, ideally CheckDOM does not require it since
isSubclassOf check can be implemented in DFG / FTL side. However, some classes have a
faster way to query isSubclassOf. For example, JSNode in WebCore introduces a special
JSType to optimize this query. CheckDOM's patchpoint gives us a chance to emit special
faster code for such a case.
By leveraging above nodes, we can construct DOMJIT accelerated getter. When DFG recognizes the
given getter call is CustomGetter and it has DOMJIT::GetterSetter information, DFG emits the above nodes.
We implemented a prototype in jsc.cpp shell as DOMJITGetter to test the functionality.
Notes about the future extensions.
1. Currently, we do not allow CallDOM to emit any function calls. This will be extended by
adding `addSlowPathCall` functionality to DOMJIT::Patchpoint later. Interesting thing is that
we need to create an abstraction over DFG slow path call and FTL slow path call!
2. CheckDOM is not handled in DFGTypeCheckHoistingPhase yet. And we have a chance to merge several CheckDOM into one.
For example, given CheckDOM A and CheckDOM B to the same target. If A is subclass of B, we can merge them to CheckDOM A.
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3Effects.h:
(JSC::B3::Effects::forCheck):
* b3/B3Value.cpp:
(JSC::B3::Value::effects):
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::GetByIdStatus::makesCalls):
(JSC::GetByIdStatus::dump):
* bytecode/GetByIdStatus.h:
(JSC::GetByIdStatus::GetByIdStatus):
(JSC::GetByIdStatus::isCustom):
(JSC::GetByIdStatus::takesSlowPath):
(JSC::GetByIdStatus::isSimple): Deleted.
* bytecode/SpeculatedType.cpp:
(JSC::speculationFromClassInfo):
* dfg/DFGAbstractInterpreter.h:
(JSC::DFG::AbstractInterpreter::filterClassInfo):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
(JSC::DFG::AbstractInterpreter<AbstractStateType>::filterClassInfo):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::filterClassInfo):
* dfg/DFGAbstractValue.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleDOMJITGetter):
(JSC::DFG::ByteCodeParser::handleGetById):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasHeapPrediction):
(JSC::DFG::Node::hasDOMJIT):
(JSC::DFG::Node::domJIT):
(JSC::DFG::Node::hasClassInfo):
(JSC::DFG::Node::classInfo):
(JSC::DFG::Node::OpInfoWrapper::OpInfoWrapper):
(JSC::DFG::Node::OpInfoWrapper::operator=):
* dfg/DFGNodeType.h:
* dfg/DFGOpInfo.h:
(JSC::DFG::OpInfo::OpInfo):
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::allocateTemporaryRegistersForPatchpoint):
(JSC::DFG::SpeculativeJIT::compileCallDOM):
(JSC::DFG::SpeculativeJIT::compileCheckDOM):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStructureAbstractValue.cpp:
(JSC::DFG::StructureAbstractValue::filterClassInfoSlow):
(JSC::DFG::StructureAbstractValue::isSubClassOf):
* dfg/DFGStructureAbstractValue.h:
(JSC::DFG::StructureAbstractValue::filterClassInfo):
(JSC::DFG::StructureAbstractValue::filter): Deleted.
* domjit/DOMJITPatchpointParams.h: Copied from Source/JavaScriptCore/dfg/DFGOpInfo.h.
(JSC::DOMJIT::PatchpointParams::~PatchpointParams):
(JSC::DOMJIT::PatchpointParams::size):
(JSC::DOMJIT::PatchpointParams::at):
(JSC::DOMJIT::PatchpointParams::operator[]):
(JSC::DOMJIT::PatchpointParams::gpScratch):
(JSC::DOMJIT::PatchpointParams::fpScratch):
(JSC::DOMJIT::PatchpointParams::PatchpointParams):
* domjit/DOMJITReg.h: Added.
(JSC::DOMJIT::Reg::Reg):
(JSC::DOMJIT::Reg::isGPR):
(JSC::DOMJIT::Reg::isFPR):
(JSC::DOMJIT::Reg::isJSValueRegs):
(JSC::DOMJIT::Reg::gpr):
(JSC::DOMJIT::Reg::fpr):
(JSC::DOMJIT::Reg::jsValueRegs):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
(JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
(JSC::FTL::DFG::LowerDFGToB3::compileUnreachable): Deleted.
* jit/AssemblyHelpers.h:
* jsc.cpp:
(WTF::DOMJITNode::DOMJITNode):
(WTF::DOMJITNode::createStructure):
(WTF::DOMJITNode::create):
(WTF::DOMJITNode::value):
(WTF::DOMJITNode::offsetOfValue):
(WTF::DOMJITGetter::DOMJITGetter):
(WTF::DOMJITGetter::createStructure):
(WTF::DOMJITGetter::create):
(WTF::DOMJITGetter::DOMJITNodeDOMJIT::DOMJITNodeDOMJIT):
(WTF::DOMJITGetter::domJITNodeGetterSetter):
(WTF::DOMJITGetter::finishCreation):
(WTF::DOMJITGetter::customGetter):
(GlobalObject::finishCreation):
(functionCreateDOMJITNodeObject):
(functionCreateDOMJITGetterObject):
2016-10-05 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Do not construct Simple GetByIdStatus against self-custom-accessor case
https://bugs.webkit.org/show_bug.cgi?id=162993
Reviewed by Filip Pizlo.
We accidentally created a Simple GetByIdStatus against self-custom-accessor case: the object has own custom accessor property and get_by_id hits.
If we returned such a result, the GetById will be turned to GetByOffset and it looks up incorrect thing like CustomGetterSetter object.
We do not hit this bug before since maybe there is no object that has own custom-accessor and this custom-accessor does not raise an error.
For example, "Node.prototype" has "firstChild" custom accessor. But since "Node.prototype" itself does not have Node::info(), "Node.prototype.firstChild"
access always raises an error. I guess all the custom accessors follow this pattern. This bug is uncovered when testing DOMJIT (This bug causes crash and
it can occur even if we disabled DOMJIT).
But such a assumption is not guaranteed. In this patch, we fix this by not returning Simple GetById.
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFromLLInt):
(JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::GetByIdStatus::computeFor):
2016-10-05 Saam Barati <sbarati@apple.com>
PCToCodeOriginMap builder should use labelIgnoringWatchpoints() inside the DFG
https://bugs.webkit.org/show_bug.cgi?id=162936
Reviewed by Michael Saboff.
label() may insert nops because of an InvalidationPoint. It does that
because we don't want code that comes after an InvalidationPoint that isn't
effected by the invalidation point to be overwritten if we fire the
InvalidationPoint. PCToCodeOriginMap just grabs labels to build
a mapping, it never emits code that actually jumps to those labels.
Therefore, it should never cause us to emit nops.
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
(JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2016-10-05 Myles C. Maxfield <mmaxfield@apple.com>
Put variation fonts work behind a compile-time flag
https://bugs.webkit.org/show_bug.cgi?id=162949
Reviewed by Simon Fraser.
* Configurations/FeatureDefines.xcconfig:
2016-10-05 Andy VanWagoner <thetalecrafter@gmail.com>
[INTL] Implement Intl.getCanonicalLocales
https://bugs.webkit.org/show_bug.cgi?id=162768
Reviewed by Benjamin Poulain.
Implement Intl.getCanonicalLocales from ECMA 402 (3rd edition)
http://ecma-international.org/ecma-402/3.0/index.html#sec-intl.getcanonicallocales
Reuse canonicalizeLocaleList and copy the results into a new JSArray.
* runtime/IntlObject.cpp:
(JSC::IntlObject::finishCreation):
(JSC::intlObjectFuncGetCanonicalLocales):
2016-10-05 Michael Saboff <msaboff@apple.com>
Bad ASSERT in ClonedArguments::createByCopyingFrom()
https://bugs.webkit.org/show_bug.cgi?id=162988
Reviewed by Keith Miller.
Removed bogus assert.
* runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::createByCopyingFrom):
2016-10-05 Zan Dobersek <zdobersek@igalia.com>
Rename ENABLE_ENCRYPTED_MEDIA_V2 to ENABLE_LEGACY_ENCRYPTED_MEDIA
https://bugs.webkit.org/show_bug.cgi?id=162903
Reviewed by Alex Christensen.
Rename build guards for the remaining implementation of the legacy EME API
to ENABLE_LEGACY_ENCRYPTED_MEDIA. This will allow for the future implementation
of the near-finished API to be guarded with the simple ENABLE_ENCRYPTED_MEDIA guards.
* Configurations/FeatureDefines.xcconfig:
2016-10-05 Csaba Osztrogonác <ossy@webkit.org>
ARM EABI buildfix after r206778
https://bugs.webkit.org/show_bug.cgi?id=162964
Unreviewed trivial fix.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState):
2016-10-04 Saam Barati <sbarati@apple.com>
String.prototype.toLowerCase should be a DFG/FTL intrinsic
https://bugs.webkit.org/show_bug.cgi?id=162887
Reviewed by Filip Pizlo and Yusuke Suzuki.
This patch makes ToLowerCase an intrinsic in the DFG/FTL. On the fast
path, the intrinsic will loop over an 8-bit string ensuring it's already
lower case, and simply return the string. In the slow path, it'll call
into C code to make a new string.
This is a 7-8% speedup on ES6SampleBench/Basic.
* 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:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileToLowerCase):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* 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::compileToLowerCase):
* jit/JITOperations.h:
* runtime/Intrinsic.h:
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
2016-10-04 Brian Burg <bburg@apple.com>
Web Inspector: don't synchronously send a listing message if we might need to query _WKAutomationDelegate
https://bugs.webkit.org/show_bug.cgi?id=162810
<rdar://problem/28571460>
Reviewed by Timothy Hatcher.
We shouldn't ever access the _WKAutomationDelegate through RemoteInspector::Client methods
off of the main thread, because it could cause problems. This happens when we pushListingsNow()
in response to a WIRApplicationGetListingMessage XPC message. In this case, just use
pushListingsSoon() since it dispatches on the correct (main) queue to gather listing information.
This may induce a slight update delay when first connecting to the UIProcess through RemoteInspector,
but this is at most 200ms and will coalesce with other updates that happen when UIProcess gets set up.
There are no other code paths through RemoteInspector (for UIProcess) that could cause a call
to pushListingsNow(), so this only needs to be changed in the XPC message handler.
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::receivedGetListingMessage):
2016-10-04 JF Bastien <jfbastien@apple.com>
WebAssembly: handle a few corner cases
https://bugs.webkit.org/show_bug.cgi?id=162884
Reviewed by Keith Miller.
* wasm/JSWASMModule.cpp: missing include broke cmake build
* wasm/WASMFunctionParser.h:
(JSC::WASM::FunctionParser<Context>::parseBlock): check op is valid
(JSC::WASM::FunctionParser<Context>::parseExpression): switch covers all cases
* wasm/WASMOps.h:
(JSC::WASM::isValidOpType): op is valid
* wasm/WASMParser.h:
(JSC::WASM::Parser::consumeString): avoid str[i] being one-past-the-end
(JSC::WASM::Parser::parseUInt32): shift math around to avoid overflow
2016-10-04 Yusuke Suzuki <utatane.tea@gmail.com>
REGRESSION (r206778): Release JSC test ChakraCore.yaml/ChakraCore/test/Error/validate_line_column.js.default failing
https://bugs.webkit.org/show_bug.cgi?id=162937
Reviewed by Saam Barati.
We dropped expression info accidentally at r206777.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitCallDefineProperty):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::PropertyListNode::emitPutConstantProperty):
(JSC::ClassExprNode::emitBytecode):
2016-10-04 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT] Introduce DOMJIT::GetterSetter to tell JIT information
https://bugs.webkit.org/show_bug.cgi?id=162916
Reviewed by Filip Pizlo.
In this patch, we introduce DOMJIT::GetterSetter.
This class maintains information required to emit JIT code in DFG and FTL.
DOMJIT::GetterSetter has 2 virtual functions: checkDOM and callDOM.
These functions can return a DOMJIT::Patchpoint that allows us to inject
appropriate machine code during DFG and FTL phases. DFG and FTL will invoke
these functions to get a patchpoint. And this patchpoint will be used to
emit code corresponding to CheckDOM and CallDOM DFG nodes, which will be added
in subsqeunt patch.
We propagate DOMJIT::GetterSetter through PropertySlot, AccessCase, GetByIdVariant,
and GetByIdStatus along with CustomGetter to teach DFG that this custom access
code has a chance to be inlined with this DOMJIT::GetterSetter information.
Instead of propagating CustomGetterSetter holding DOMJIT::GetterSetter and CustomGetter,
we propagate CustomGetter and DOMJIT::GetterSetter. This is because of the current
CustomGetterSetter design that we reify CustomGetterSetters only when we need to reify
all the properties. This design allows us to avoid frequent CustomGetterSetter allocations
and structure transitions.
Currently, domJIT field is always nullptr since there is no DOMJITAttribute user.
When we add this, we will add code handling this DOMJIT::GetterSetter in DFG::ByteCodeParser.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
* bytecode/GetByIdVariant.cpp:
(JSC::GetByIdVariant::GetByIdVariant):
(JSC::GetByIdVariant::operator=):
(JSC::GetByIdVariant::attemptToMerge):
(JSC::GetByIdVariant::dumpInContext):
* bytecode/GetByIdVariant.h:
(JSC::GetByIdVariant::domJIT):
(JSC::GetByIdVariant::intrinsic): Deleted.
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::get):
(JSC::AccessCase::clone):
* bytecode/PolymorphicAccess.h:
(JSC::AccessCase::domJIT):
(JSC::AccessCase::RareData::RareData):
* dfg/DFGNode.h:
* domjit/DOMJITGetterSetter.h: Added.
(JSC::DOMJIT::GetterSetter::GetterSetter):
(JSC::DOMJIT::GetterSetter::~GetterSetter):
(JSC::DOMJIT::GetterSetter::getter):
(JSC::DOMJIT::GetterSetter::setter):
(JSC::DOMJIT::GetterSetter::thisClassInfo):
* domjit/DOMJITPatchpoint.h: Added.
(JSC::DOMJIT::Patchpoint::create):
(JSC::DOMJIT::Patchpoint::setGenerator):
(JSC::DOMJIT::Patchpoint::generator):
* jit/Repatch.cpp:
(JSC::tryCacheGetByID):
* runtime/CustomGetterSetter.h:
* runtime/JSObject.h:
(JSC::JSObject::fillCustomGetterPropertySlot):
* runtime/Lookup.h:
(JSC::HashTableValue::domJIT):
(JSC::getStaticPropertySlotFromTable):
(JSC::putEntry):
(JSC::reifyStaticProperty):
* runtime/PropertySlot.h:
(JSC::PropertySlot::domJIT):
(JSC::PropertySlot::setCacheableCustom):
2016-09-27 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Add a new byte code op_define_property instead of calling defineProperty
https://bugs.webkit.org/show_bug.cgi?id=162108
Reviewed by Saam Barati.
To construct ES6 class, we emitted bytecode that performs the following operations.
1. construct a new object
2. put "configurable", "enumerable" etc. fields
3. call "defineProperty" function
However, this approach has problems. Every time we define a class method, we need to create
a new object to represent property descriptor. This can be removed if we can introduce
a special bytecode or special function.
This patch introduces new bytecodes, op_define_data_property and op_define_accessor_property.
Instead of taking an object, they takes several registers to avoid object allocations.
We're planning to use this bytecode to implement Object.defineProperty in builtin JS next.
This allows us to leverage object allocation sinking. And it also gives us a chance to use
faster ::get and ::hasProperty in JS.
Originally, I attempted to create one bytecode, op_define_property. However, it takes too many
children in DFG and uses so many registers in DFG. This leads tricky program in 32bit platforms.
Furthermore, it does not fit to the number of x64 argument registers. So instead, we introduce
two bytecodes.
And for op_define_accessor_property, we perform CellUse edge filter to getter and setter children.
This edge filter makes us possible to use SpeculateCellOperand and reduce the number of used registers
in comparison with JSValueOperand. To make children Cells even if we do not specify some accessors (for
example, { get: func, set: null } case), we fill registers with special throwTypeErrorFunction.
The attributes bitset keep information like "This property descriptor only has getter slot".
In these two bytecodes, we take attributes (configurable, enumerable, writable, hasGetter etc.) as
register instead of embedding constant int value because we will use these bytecodes to implement
Object.defineProperty next. In Object.defineProperty case, an attributes are not statically defined
at bytecode compiling time.
Run ES6SampleBench/Air 20 times. The result shows ~2% performance improvement.
Baseline:
firstIteration: 84.05 ms +- 4.37 ms
averageWorstCase: 40.54 ms +- 2.81 ms
steadyState: 3317.49 ms +- 48.25 ms
summary: 223.51 ms +- 5.07 ms
Patched:
firstIteration: 84.46 ms +- 4.22 ms
averageWorstCase: 41.48 ms +- 2.33 ms
steadyState: 3253.48 ms +- 29.31 ms
summary: 224.40 ms +- 4.72 ms
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecode/SpecialPointer.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitMoveLinkTimeConstant):
(JSC::BytecodeGenerator::emitCallDefineProperty):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::PropertyListNode::emitPutConstantProperty):
(JSC::BitwiseNotNode::emitBytecode):
(JSC::ClassExprNode::emitBytecode):
(JSC::ObjectPatternNode::bindValue):
* 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/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileDefineDataProperty):
(JSC::DFG::SpeculativeJIT::compileDefineAccessorProperty):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileDefineDataProperty):
(JSC::FTL::DFG::LowerDFGToB3::compileDefineAccessorProperty):
(JSC::FTL::DFG::LowerDFGToB3::compilePutByValWithThis): Deleted.
* jit/CCallHelpers.cpp:
(JSC::CCallHelpers::setupFourStubArgsGPR): Deleted.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupFourStubArgsGPR):
(JSC::CCallHelpers::setupFiveStubArgsGPR):
(JSC::CCallHelpers::setupArgumentsWithExecState):
(JSC::CCallHelpers::setupStubArgsGPR):
(JSC::CCallHelpers::prepareForTailCallSlow): Deleted.
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_define_data_property):
(JSC::JIT::emit_op_define_accessor_property):
* llint/LowLevelInterpreter.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* runtime/DefinePropertyAttributes.h: Added.
(JSC::DefinePropertyAttributes::DefinePropertyAttributes):
(JSC::DefinePropertyAttributes::rawRepresentation):
(JSC::DefinePropertyAttributes::hasValue):
(JSC::DefinePropertyAttributes::setValue):
(JSC::DefinePropertyAttributes::hasGet):
(JSC::DefinePropertyAttributes::setGet):
(JSC::DefinePropertyAttributes::hasSet):
(JSC::DefinePropertyAttributes::setSet):
(JSC::DefinePropertyAttributes::writable):
(JSC::DefinePropertyAttributes::configurable):
(JSC::DefinePropertyAttributes::enumerable):
(JSC::DefinePropertyAttributes::setWritable):
(JSC::DefinePropertyAttributes::setConfigurable):
(JSC::DefinePropertyAttributes::setEnumerable):
(JSC::DefinePropertyAttributes::fillWithTriState):
(JSC::DefinePropertyAttributes::extractTriState):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::throwTypeErrorFunction):
(JSC::JSGlobalObject::definePropertyFunction): Deleted.
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructor::addDefineProperty): Deleted.
* runtime/ObjectConstructor.h:
* runtime/PropertyDescriptor.h:
(JSC::toPropertyDescriptor):
2016-10-04 Saam Barati <sbarati@apple.com>
Follow up fix to GetMapBucket and MapHash speculating on child node types.
To fix this, on 32-bit platforms, we do not speculate on the child
type since we just call into C code for these nodes.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
2016-10-03 Saam Barati <sbarati@apple.com>
GetMapBucket node should speculate on the type of its 'key' child
https://bugs.webkit.org/show_bug.cgi?id=161638
Reviewed by Filip Pizlo.
This eliminates type-check branches when we've already
proven the type of the incoming key. Also, it reduces
the branches we emit when type checking the bucket's key.
This is a 2-3% speedup on ES6SampleBench/Basic.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket):
2016-10-03 Christopher Reid <Christopher.Reid@am.sony.com>
Offline asm should not output masm assembly when using a x86_64 asm backend
https://bugs.webkit.org/show_bug.cgi?id=162705
When cross compiling on windows to Clang, masm was being generated simply because
the os was windows. This change adds a command line parameter --assembler=MASM
to set the output assembly to masm.
The functions isGCC and isCompilingToWindows were removed as they are no longer called.
Reviewed by Mark Lam.
* CMakeLists.txt:
* offlineasm/asm.rb:
* offlineasm/x86.rb:
2016-10-03 JF Bastien <jfbastien@apple.com>
Auto-generate WASMOps.h, share with testing JSON file
https://bugs.webkit.org/show_bug.cgi?id=162870
Reviewed by Keith Miller.
Add a few new opcodes, but keep this mostly as-is for now. I want
to generate smarter code but will do so in a later update to
reduce disruption.
* wasm/WASMOps.h: auto-generated from ./JSTests/stress/wasm/to-c++.js
2016-10-03 Michael Saboff <msaboff@apple.com>
Creating pcToOriginMap in FTL shouldn't insert unnecessary NOPs
https://bugs.webkit.org/show_bug.cgi?id=162879
Reviewed by Filip Pizlo.
If there is a recent watchpoint label, using MacroAssembler::label() will pad
the instruction stream with NOPs to provide space for a jump. This changes
Air::generate() to use labelIgnoringWatchpoints() to create pcToOriginMap
entries to eliminate unneccesary NOPs.
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::generate):
* b3/testb3.cpp:
(JSC::B3::testPCOriginMapDoesntInsertNops): New test.
(JSC::B3::run):
2016-10-03 Saam Barati <sbarati@apple.com>
MapHash should speculate on the type of its child node
https://bugs.webkit.org/show_bug.cgi?id=161922
Reviewed by Filip Pizlo.
This allows us to remove runtime type checks when we've already
proven the type of the incoming value.
This is a 2-3% speedup on ES6SampleBench/Basic.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::wangsInt64Hash):
(JSC::FTL::DFG::LowerDFGToB3::mapHashString):
(JSC::FTL::DFG::LowerDFGToB3::compileMapHash):
2016-10-03 Filip Pizlo <fpizlo@apple.com>
B3 trapping memory accesses should be documented
https://bugs.webkit.org/show_bug.cgi?id=162845
Reviewed by Geoffrey Garen.
While writing some documentation, I found some small holes in the code.
* b3/B3Effects.cpp:
(JSC::B3::Effects::operator==): Need this to write tests.
(JSC::B3::Effects::operator!=): Need this to write tests.
* b3/B3Effects.h:
* b3/B3HeapRange.h:
* b3/B3MemoryValue.cpp:
(JSC::B3::MemoryValue::dumpMeta): Sometimes the heap range dump won't show you the memory value's actual range. This makes the dump show you the actual range in that case.
* b3/B3Value.cpp:
(JSC::B3::Value::effects): While documenting this, I remembered that trapping also has to imply reading top. I fixed this.
* b3/testb3.cpp:
(JSC::B3::testTrappingLoad): Added checks for the effects of trapping loads.
(JSC::B3::testTrappingStore): Added checks for the effects of trapping stores.
(JSC::B3::testMoveConstants): Made this not crash with validation.
2016-10-03 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] GeneratorFunction (a.k.a. GeneratorWrapperFunction)'s prototype object does not have constructor property
https://bugs.webkit.org/show_bug.cgi?id=162849
Reviewed by Geoffrey Garen.
Since GeneratorFunction is not constructible, GeneratorFunction.prototype does not have "constructor" property.
function* generatorFunction() { }
generatorFunction.prototype.constructor // undefined
* runtime/JSFunction.cpp:
(JSC::JSFunction::getOwnPropertySlot):
2016-10-03 Nicolas Breidinger <Nicolas.Breidinger@sony.com>
JSStringRef should define JSChar without platform checks
https://bugs.webkit.org/show_bug.cgi?id=162808
Reviewed by Mark Lam.
* API/JSStringRef.h:
2016-10-01 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Align attributes of Generator related properties to spec
https://bugs.webkit.org/show_bug.cgi?id=162839
Reviewed by Saam Barati.
This patch fixes attributes of Generator related properties.
These fixes are covered by test262.
* runtime/GeneratorFunctionConstructor.cpp:
(JSC::GeneratorFunctionConstructor::finishCreation):
* runtime/GeneratorFunctionConstructor.h:
* runtime/GeneratorFunctionPrototype.cpp:
(JSC::GeneratorFunctionPrototype::finishCreation):
* runtime/GeneratorFunctionPrototype.h:
* runtime/GeneratorPrototype.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
2016-10-01 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] GeneratorFunction constructor should instantiate generator function
https://bugs.webkit.org/show_bug.cgi?id=162838
Reviewed by Saam Barati.
GeneratorFunction's constructor should return an instance of JSGeneratorFunction
instead of JSFunction. In this patch, we fix the following 2 things.
1. GeneratorFunction constructor should use JSGeneratorFunction
Previously, we used JSFunction to construct a result. It's wrong. We use JSGeneratorFunction.
2. Pass newTarget into GeneratorFunction constructor to make it subclassible
We did not leverage newTarget when using GeneratorFunction constructor.
Using it correctly to create the subclass Structure and making GeneratorFunction subclassible.
Test262 test covers (1), but (2) is not covered. We add tests that covers both to stress tests.
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/GeneratorFunctionConstructor.cpp:
(JSC::constructGeneratorFunctionConstructor):
* runtime/JSGeneratorFunction.cpp:
(JSC::JSGeneratorFunction::JSGeneratorFunction):
(JSC::JSGeneratorFunction::createImpl):
(JSC::JSGeneratorFunction::create):
(JSC::JSGeneratorFunction::createWithInvalidatedReallocationWatchpoint):
* runtime/JSGeneratorFunction.h:
2016-10-01 Filip Pizlo <fpizlo@apple.com>
Get rid of isMarkedOrNewlyAllocated
https://bugs.webkit.org/show_bug.cgi?id=162842
Reviewed by Dan Bernstein.
This function has become dead code. This change removes it.
* heap/CellContainer.h:
* heap/CellContainerInlines.h:
(JSC::CellContainer::isMarkedOrNewlyAllocated): Deleted.
* heap/LargeAllocation.h:
(JSC::LargeAllocation::isLive):
(JSC::LargeAllocation::isMarkedOrNewlyAllocated): Deleted.
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated): Deleted.
(JSC::MarkedBlock::isMarkedOrNewlyAllocated): Deleted.
* heap/MarkedBlock.h:
(JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated): Deleted.
(JSC::MarkedBlock::isMarkedOrNewlyAllocated): Deleted.
2016-10-01 Joseph Pecoraro <pecoraro@apple.com>
Rename DebugHookID to DebugHookType
https://bugs.webkit.org/show_bug.cgi?id=162820
Reviewed by Alex Christensen.
* bytecode/CodeBlock.cpp:
(JSC::debugHookName):
(JSC::CodeBlock::dumpBytecode):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitDebugHook):
* bytecompiler/BytecodeGenerator.h:
* interpreter/Interpreter.cpp:
(JSC::Interpreter::debug):
* interpreter/Interpreter.h:
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
2016-09-30 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Stepping to a line with an autoContinue breakpoint should still pause
https://bugs.webkit.org/show_bug.cgi?id=161712
<rdar://problem/28193970>
Reviewed by Brian Burg.
* debugger/Debugger.cpp:
(JSC::Debugger::pauseIfNeeded):
If we stepped to an auto-continue breakpoint we should continue
stepping, not just continue.
2016-09-30 Filip Pizlo <fpizlo@apple.com>
B3 should support trapping memory accesses
https://bugs.webkit.org/show_bug.cgi?id=162689
Reviewed by Geoffrey Garen.
This adds a traps flag to B3::Kind. It also makes B3::Kind work more like Air::Kind, in the
sense that it's a bag of distinct bits - it doesn't need to be a union unless we get enough
things that it would make a difference.
The only analysis that needs to know about traps is effects. It now knows that traps implies
sideExits, which means that this turns off DCE. The only optimization that needs to know
about traps is eliminateCommonSubexpressions(), which needs to pessimize its store
elimination if the store traps.
The hard part of this change is teaching the instruction selector to faithfully carry the
traps flag down to Air. I got this to work by making ArgPromise a non-copyable object that
knows whether you've used it in an instruction. It knows when you call consume(). If you do
this then ArgPromise cannot be destructed without first passing your inst through it. This,
along with a few other hacks, means that all of the load-op and load-op-store fusions
correctly carry the trap bit: if any of the B3 loads or stores involved traps then you get
traps in Air.
This framework also sets us up to do bug 162688, since the ArgPromise::inst() hook is
powerful enough to allow wrapping the instruction with a Patch.
I added some tests to testb3 that verify that optimizations are appropriately inhibited and
that the traps flag survives until the bitter end of Air.
* b3/B3EliminateCommonSubexpressions.cpp:
* b3/B3Kind.cpp:
(JSC::B3::Kind::dump):
* b3/B3Kind.h:
(JSC::B3::Kind::Kind):
(JSC::B3::Kind::hasExtraBits):
(JSC::B3::Kind::isChill):
(JSC::B3::Kind::setIsChill):
(JSC::B3::Kind::hasTraps):
(JSC::B3::Kind::traps):
(JSC::B3::Kind::setTraps):
(JSC::B3::Kind::operator==):
(JSC::B3::Kind::hash):
(JSC::B3::trapping):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::ArgPromise::swap):
(JSC::B3::Air::LowerToAir::ArgPromise::ArgPromise):
(JSC::B3::Air::LowerToAir::ArgPromise::operator=):
(JSC::B3::Air::LowerToAir::ArgPromise::~ArgPromise):
(JSC::B3::Air::LowerToAir::ArgPromise::setTraps):
(JSC::B3::Air::LowerToAir::ArgPromise::consume):
(JSC::B3::Air::LowerToAir::ArgPromise::inst):
(JSC::B3::Air::LowerToAir::trappingInst):
(JSC::B3::Air::LowerToAir::loadPromiseAnyOpcode):
(JSC::B3::Air::LowerToAir::appendUnOp):
(JSC::B3::Air::LowerToAir::appendBinOp):
(JSC::B3::Air::LowerToAir::tryAppendStoreUnOp):
(JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
(JSC::B3::Air::LowerToAir::appendStore):
(JSC::B3::Air::LowerToAir::append):
(JSC::B3::Air::LowerToAir::createGenericCompare):
(JSC::B3::Air::LowerToAir::createBranch):
(JSC::B3::Air::LowerToAir::createCompare):
(JSC::B3::Air::LowerToAir::createSelect):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::effects):
* b3/B3Value.h:
* b3/air/AirCode.h:
* b3/testb3.cpp:
(JSC::B3::testTrappingLoad):
(JSC::B3::testTrappingStore):
(JSC::B3::testTrappingLoadAddStore):
(JSC::B3::testTrappingLoadDCE):
(JSC::B3::testTrappingStoreElimination):
(JSC::B3::run):
2016-09-30 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Stepping over/out of a function sometimes resumes instead of taking you to caller
https://bugs.webkit.org/show_bug.cgi?id=162802
<rdar://problem/28569982>
Reviewed by Mark Lam.
* debugger/Debugger.cpp:
(JSC::Debugger::stepOverStatement):
(JSC::Debugger::stepOutOfFunction):
Enable stepping mode when we start stepping.
2016-09-30 Filip Pizlo <fpizlo@apple.com>
B3::moveConstants should be able to edit code to minimize the number of constants
https://bugs.webkit.org/show_bug.cgi?id=162764
Reviewed by Saam Barati.
There are some interesting cases where we can reduce the number of constant materializations if
we teach moveConstants() how to edit code. The two examples that this patch supports are:
- Loads and stores from a constant pointer. Since loads and stores get an offset for free
and the instruction selector is really good at handling it, and since we can query Air to
see what kinds of offsets are legal, we can sometimes avoid using a constant pointer that
is specific to the absolute address of that load and instead pick some other constant
that is within offset distance of ours.
- Add and Sub by a constant (x + c, x - c). Since x + c = x - -c and x - c = x + -c, we can
flip Add to Sub or vice versa if the negated constant is available.
This change makes moveConstants() pick the most dominant constant that works for an value. In
the case of memory accesses, it uses Air::Arg::isValidAddrForm() to work out what other
constants would work. In the case of Add/Sub, it simply looks for the negated constant. This
should result in something like a minimal number of constants since these rules always pick the
most dominant constant that works - so if an Add's constant is already most dominant then
nothing changes, but if the negated one is more dominant then it becomes a Sub.
This is a 0.5% speed-up on LongSpider and neutral elsewhere. It's a speed-up because the
absolute address thing reduces the number of address materializations that we have to do, while
the add/sub thing prevents us from having to materialize 0x1000000000000 to box doubles.
However, this may introduce a pathology, which I've filed a bug for: bug 162796.
* b3/B3MoveConstants.cpp:
* b3/B3MoveConstants.h:
* b3/B3UseCounts.h:
* b3/air/AirFixObviousSpills.cpp:
* b3/testb3.cpp:
(JSC::B3::testMoveConstants):
(JSC::B3::run):
2016-09-30 Joseph Pecoraro <pecoraro@apple.com>
Fix modules tests after r206653 handle breakpoint locations in import/export statements
https://bugs.webkit.org/show_bug.cgi?id=162807
Reviewed by Mark Lam.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createExportDefaultDeclaration):
(JSC::ASTBuilder::createExportLocalDeclaration):
Don't record an extra breakpoint location for the statement
within an export statement.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseModuleSourceElements):
Record a pause location for import/export statements.
2016-09-30 Mark Lam <mark.lam@apple.com>
Remove the dumping of the stack back trace in VM::verifyExceptionCheckNeedIsSatisfied().
https://bugs.webkit.org/show_bug.cgi?id=162797
Reviewed by Geoffrey Garen.
This is because the RELEASE_ASSERT() that follows immediately after will also
dump the stack back trace. Hence, the first dump will be redundant.
Also removed an extra space in the dataLog output.
* runtime/VM.cpp:
(JSC::VM::verifyExceptionCheckNeedIsSatisfied):
2016-09-30 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Stepping through `a(); b(); c();` it is unclear where we are and what is about to execute
https://bugs.webkit.org/show_bug.cgi?id=161658
<rdar://problem/28181254>
Reviewed by Geoffrey Garen.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseAssignmentExpression):
Updated pause location for unary expressions.
2016-09-30 Joseph Pecoraro <pecoraro@apple.com>
Breakpoints on blank lines or comments don't break
https://bugs.webkit.org/show_bug.cgi?id=9885
<rdar://problem/6134406>
Reviewed by Mark Lam.
This change introduces a way to perform a Debugger Parse of a script.
This debugger parse gathers a list of breakpoint locations, which
the backend uses to resolve breakpoint locations that came from the
Inspector frontend to the exact location we would actually pause.
We gather this information from the parser so that we can eagerly
get this information without requiring the code to have executed (the
real op_debugs are generated during bytecode generation when code
is actually evaluated).
If an input location was on a line with whitespace or a comment, the
resolved breakpoint location would be before the next statement that
will be executed. That may be the next line, or even later. We also
update our policy when setting breakpoints on and around function
statements to better match user expectations.
For example, when resolving breakpoints in:
1. // Comment
2. before;
3.
4. function foo() {
5. inside;
6. }
7.
8. after;
A breakpoint on line 1, a comment, resolves to line 2 the next
statement that will execute.
A breakpoint on line 3 or 7, empty lines, resolves to line 8 the next
statement that will execute. This skips past the definition of foo,
just like stepping would have done. The creation of foo would have
been hoisted, which would have happened before execution of the
other statements.
A breakpoint on line 4, a function signature, resolves to line 5,
inside the function. Users would expect to pause inside of a function
when setting a breakpoint on that function's name or opening brace.
A breakpoint on line 6, a function's closing brace, resolves to
line 6. The debugger will pause whenever execution leaves foo due to
a return and not an exception. This matches stepping behavior. An
explicit or implicit return (the implicit return undefined) will
pause on the closing brace as we leave the function, giving users
an opportunity to inspect the final state before leaving.
--
At this point, op_debug's are still emitted at custom locations during
bytecode generation of other statements / expressions. In order to
ensure the generated op_debugs correspond to locations the Parser
determined were breakpoint locations, the Parser sets a "needs debug
hook" flag on the nodes it will use for breakpoint locations, and
we assert during bytecode generation that op_debugs are only emitted
for nodes that were marked as needing debug hooks.
This still leaves open the possibility that the Parser will mark
some nodes that get missed during bytecode generation, so we might
fail to emit some op_debugs. The next step will be eliminating the
custom emitDebugHooks spread across StatementNode and ExpressionNode
subclasses, and instead always generating op_debugs whenever we
emit a flagged node.
--
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
New DebuggerParseData files.
* API/JSScriptRef.cpp:
(OpaqueJSScript::OpaqueJSScript):
* jsc.cpp:
(functionCheckModuleSyntax):
* parser/SourceCode.h:
(JSC::makeSource):
* parser/SourceProvider.cpp:
(JSC::SourceProvider::SourceProvider):
* parser/SourceProvider.h:
(JSC::SourceProvider::sourceType):
(JSC::StringSourceProvider::create):
(JSC::StringSourceProvider::StringSourceProvider):
(JSC::WebAssemblySourceProvider::WebAssemblySourceProvider):
(JSC::SourceProvider::startPosition): Deleted.
Add a new type on SourceProvider to distinguish if its script was
intended to be a Script, Module, or WebAssembly. This information
will be needed to know how to best parse this file when the
debugger decides to lazily parse.
* runtime/Executable.cpp:
(JSC::EvalExecutable::EvalExecutable):
(JSC::ProgramExecutable::ProgramExecutable):
(JSC::ModuleProgramExecutable::ModuleProgramExecutable):
(JSC::WebAssemblyExecutable::WebAssemblyExecutable):
* runtime/ModuleLoaderPrototype.cpp:
(JSC::moduleLoaderPrototypeParseModule):
ASSERT the SourceProvider type matches the executable type we are
creating for it.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::breakpointLocation):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::operatorStackPop):
When gathering breakpoint positions, get the position from the
current node. In the SyntaxChecker, return an invalid position.
* parser/Nodes.h:
(JSC::ExpressionNode::needsDebugHook):
(JSC::ExpressionNode::setNeedsDebugHook):
(JSC::StatementNode::needsDebugHook):
(JSC::StatementNode::setNeedsDebugHook):
When gathering breakpoint positions, mark the node as needing
a debug hook. For now we assert op_debugs generated must come
from these nodes. Later we should just generate op_debugs for
these nodes.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::Parser):
(JSC::Parser<LexerType>::parseStatementListItem):
(JSC::Parser<LexerType>::parseDoWhileStatement):
(JSC::Parser<LexerType>::parseWhileStatement):
(JSC::Parser<LexerType>::parseArrowFunctionSingleExpressionBodySourceElements):
(JSC::Parser<LexerType>::parseForStatement):
(JSC::Parser<LexerType>::parseWithStatement):
(JSC::Parser<LexerType>::parseSwitchStatement):
(JSC::Parser<LexerType>::parseStatement):
(JSC::Parser<LexerType>::parseFunctionBody):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseIfStatement):
(JSC::Parser<LexerType>::parseAssignmentExpression):
* parser/Parser.h:
(JSC::parse):
Add an optional DebuggerParseData struct to the Parser. When available
the Parser will gather debugger data, and parse all functions with the
ASTBuilder instead of SyntaxChecking inner functions.
* debugger/DebuggerParseData.cpp: Added.
(JSC::DebuggerPausePositions::breakpointLocationForLineColumn):
(JSC::DebuggerPausePositions::sort):
(JSC::gatherDebuggerParseData):
(JSC::gatherDebuggerParseDataForSource):
* debugger/DebuggerParseData.h: Copied from Source/JavaScriptCore/debugger/DebuggerPrimitives.h.
(JSC::DebuggerPausePositions::DebuggerPausePositions):
(JSC::DebuggerPausePositions::appendPause):
(JSC::DebuggerPausePositions::appendEntry):
(JSC::DebuggerPausePositions::appendLeave):
The DebuggerParseData struct currently only contains a list of pause positions.
Once populated it can resolve an input location to a pause position.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitCall):
(JSC::BytecodeGenerator::emitCallVarargs):
(JSC::BytecodeGenerator::emitDebugHook):
(JSC::BytecodeGenerator::emitEnumeration):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::EmptyStatementNode::emitBytecode):
(JSC::DebuggerStatementNode::emitBytecode):
(JSC::ExprStatementNode::emitBytecode):
(JSC::DeclarationStatement::emitBytecode):
(JSC::IfElseNode::emitBytecode):
(JSC::DoWhileNode::emitBytecode):
(JSC::WhileNode::emitBytecode):
(JSC::ForNode::emitBytecode):
(JSC::ForInNode::emitBytecode):
(JSC::ContinueNode::emitBytecode):
(JSC::BreakNode::emitBytecode):
(JSC::ReturnNode::emitBytecode):
(JSC::WithNode::emitBytecode):
(JSC::SwitchNode::emitBytecode):
(JSC::ThrowNode::emitBytecode):
Emit op_debugs for the nodes themselves. Assert when we do that the
Parser had marked them as needing a debug hook.
* debugger/Breakpoint.h:
(JSC::Breakpoint::Breakpoint):
A breakpoint may be resolved or unresolved. Debugger::resolveBreakpoint
must be used to resolve the breakpoint. Most methods now require a
resolved breakpoint.
* debugger/Debugger.h:
* debugger/Debugger.cpp:
(JSC::Debugger::detach):
(JSC::Debugger::toggleBreakpoint):
(JSC::Debugger::debuggerParseData):
(JSC::Debugger::resolveBreakpoint):
(JSC::Debugger::setBreakpoint):
(JSC::Debugger::clearParsedData):
Provide a public method to resolve a breakpoint location in a script.
This will gather debugger parse data for the script if none is available.
Ensure clients have resolved a breakpoint before attempting to set it.
Currently we allow only a single breakpoint at a location. This may
need to change if multiple breakpoints resolve to the same location
but have different actions.
* inspector/ScriptDebugListener.h:
ScriptDebugServer::Script is effectively duplicating most of the data from
a SourceProvider. We should eliminate this and just use SourceProvider.
* inspector/ScriptDebugServer.cpp:
(Inspector::ScriptDebugServer::setBreakpointActions):
(Inspector::ScriptDebugServer::removeBreakpointActions):
(Inspector::ScriptDebugServer::getActionsForBreakpoint):
(Inspector::ScriptDebugServer::clearBreakpointActions):
(Inspector::ScriptDebugServer::evaluateBreakpointAction):
(Inspector::ScriptDebugServer::dispatchDidParseSource):
(Inspector::ScriptDebugServer::handleBreakpointHit):
(Inspector::ScriptDebugServer::setBreakpoint): Deleted.
(Inspector::ScriptDebugServer::removeBreakpoint): Deleted.
(Inspector::ScriptDebugServer::clearBreakpoints): Deleted.
* inspector/ScriptDebugServer.h:
Reduce ScriptDebugServer's involvement in breakpoints to just handling
breakpoint actions. Eventually we should eliminate it alltogether and
fold breakpoint logic into Debugger or DebugAgent.
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::buildDebuggerLocation):
(Inspector::parseLocation):
(Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
(Inspector::InspectorDebuggerAgent::setBreakpoint):
(Inspector::InspectorDebuggerAgent::didSetBreakpoint):
(Inspector::InspectorDebuggerAgent::resolveBreakpoint):
(Inspector::InspectorDebuggerAgent::removeBreakpoint):
(Inspector::InspectorDebuggerAgent::continueToLocation):
(Inspector::InspectorDebuggerAgent::didParseSource):
(Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
The Inspector can set breakpoints in multiple ways.
Ensure that once we have the Script that we always
resolve the breakpoint location before setting the
breakpoint. The different paths are:
- setBreakpoint(scriptId, location)
- Here we know the SourceProvider by its SourceID
- resolve and set
- setBreakpointByURL(url, location)
- Search for existing Scripts that match the URL
- resolve in each and set
- When new Scripts are parsed that match the URL
- resolve and set
2016-09-30 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Stepping out of a function finishes the line that called it.
https://bugs.webkit.org/show_bug.cgi?id=155325
<rdar://problem/25094578>
Reviewed by Mark Lam.
Also addresses:
<https://webkit.org/b/161721> Web Inspector: Stepping all the way through program should not cause a pause on the next program that executes
<https://webkit.org/b/161716> Web Inspector: Stepping into a function / program should not require stepping to the first statement
This change introduces a new op_debug hook: WillExecuteExpression.
Currently this new hook is only used for pausing at function calls.
We may decide to add it to other places later where pausing with
finer granularity then statements (or lines) if useful.
This updates the location and behavior of some of the existing debug
hooks, to be more consistent and useful if the exact location of the
pause is displayed. For example, in control flow statements like
`if` and `while`, the pause location is the expression itself that
will be evaluated, not the location of the `if` or `while` keyword.
For example:
if (|condition)
while (|condition)
Finally, this change gets rid of some unnecessary / useless pause
locations such as on entering a function and on entering a program.
These pauses are not needed because if there is a statement, we
would pause before the statement and it is equivalent. We continue
to pause when leaving a function via stepping by uniformly jumping
to the closing brace of the function. This gives users a chance
to observe state before leaving the function.
* bytecode/CodeBlock.cpp:
(JSC::debugHookName):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::dumpLineColumnEntry):
Logging strings for the new debug hook.
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitCallInTailPosition):
(JSC::BytecodeGenerator::emitCallEval):
(JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
(JSC::BytecodeGenerator::emitConstructVarargs):
(JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition):
(JSC::BytecodeGenerator::emitCallDefineProperty):
(JSC::BytecodeGenerator::emitConstruct):
(JSC::BytecodeGenerator::emitGetTemplateObject):
(JSC::BytecodeGenerator::emitIteratorNext):
(JSC::BytecodeGenerator::emitIteratorNextWithValue):
(JSC::BytecodeGenerator::emitIteratorClose):
(JSC::BytecodeGenerator::emitDelegateYield):
All emitCall variants now take an enum to decide whether or not to
emit the WillExecuteExpression debug hook.
(JSC::BytecodeGenerator::emitCall):
(JSC::BytecodeGenerator::emitCallVarargs):
In the two real implementations, actually decide to emit the debug
hook or not based on the parameter.
(JSC::BytecodeGenerator::emitEnumeration):
This is shared looping code used by for..of iteration of iterables.
When used by ForOfNode, we want to emit a pause location during
iteration.
(JSC::BytecodeGenerator::emitWillLeaveCallFrameDebugHook):
This is shared call frame leave code to emit a consistent pause
location when leaving a function.
* bytecompiler/NodesCodegen.cpp:
(JSC::EvalFunctionCallNode::emitBytecode):
(JSC::FunctionCallValueNode::emitBytecode):
(JSC::FunctionCallResolveNode::emitBytecode):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_tailCallForwardArguments):
(JSC::FunctionCallBracketNode::emitBytecode):
(JSC::FunctionCallDotNode::emitBytecode):
(JSC::CallFunctionCallDotNode::emitBytecode):
(JSC::ApplyFunctionCallDotNode::emitBytecode):
(JSC::TaggedTemplateNode::emitBytecode):
(JSC::ArrayPatternNode::bindValue):
All tail position calls are the function calls that we want to emit
debug hooks for. All non-tail call calls appear to be internal
implementation details, and these should not have the debug hook.
(JSC::IfElseNode::emitBytecode):
(JSC::WhileNode::emitBytecode):
(JSC::WithNode::emitBytecode):
(JSC::SwitchNode::emitBytecode):
Make the pause location consistent at the expression.
(JSC::DoWhileNode::emitBytecode):
Make the pause location consistent at the expression.
Remove the errant pause at the do's '}' when entering the do block.
(JSC::ForNode::emitBytecode):
(JSC::ForInNode::emitMultiLoopBytecode):
(JSC::ForOfNode::emitBytecode):
Make the pause location consistent at expressions.
Also allow stepping to the traditional for loop's
update expression, which was previously not possible.
(JSC::ReturnNode::emitBytecode):
(JSC::FunctionNode::emitBytecode):
Make the pause location when leaving a function consistently be the
function's closing brace. The two cases are stepping through a return
statement, or the implicit return undefined at the end of a function.
(JSC::LabelNode::emitBytecode):
(JSC::TryNode::emitBytecode):
Remove unnecessary pauses that add no value, as they contain a
statement and we will then pause at that statement.
* parser/Nodes.h:
(JSC::StatementNode::isFunctionNode):
(JSC::StatementNode::isForOfNode):
(JSC::EnumerationNode::lexpr):
(JSC::ForOfNode::isForOfNode):
New virtual methods to distinguish different nodes.
* debugger/Debugger.h:
Rename m_pauseAtNextStatement to m_pauseAtNextOpportunity.
This is the finest granularity of stepping, and it can be
pausing at a location that is not a statement.
Introduce state to properly handle step out and stepping
when there are multiple expressions in a statement.
* debugger/Debugger.cpp:
(JSC::Debugger::Debugger):
(JSC::Debugger::setPauseOnNextStatement):
(JSC::Debugger::breakProgram):
(JSC::Debugger::continueProgram):
(JSC::Debugger::stepIntoStatement):
(JSC::Debugger::exception):
(JSC::Debugger::didReachBreakpoint):
Use new variable names, and clarify if we should attempt
to pause or not.
(JSC::Debugger::stepOutOfFunction):
Set a new state to indicate a step out action.
(JSC::Debugger::updateCallFrame):
(JSC::Debugger::updateCallFrameAndPauseIfNeeded): Deleted.
(JSC::Debugger::updateCallFrameInternal):
(JSC::Debugger::pauseIfNeeded):
Allow updateCallFrame to either attempt a pause or not.
(JSC::Debugger::atStatement):
Attempt pause and reset the at first expression flag.
(JSC::Debugger::atExpression):
Attempt a pause when not stepping over. Also skip
the first expression pause, since that would be
equivalent to when we paused for the expression.
(JSC::Debugger::callEvent):
Do not pause when entering a function.
(JSC::Debugger::returnEvent):
Attempt pause when leaving a function.
If the user did a step-over and is leaving the
function, then behave like step-out.
(JSC::Debugger::unwindEvent):
Behave like return except don't change any
pausing states. If we needed to pause the
Debugger::exception will have handled it.
(JSC::Debugger::willExecuteProgram):
Do not pause when entering a program.
(JSC::Debugger::didExecuteProgram):
Attempt pause when leaving a program that has a caller.
This can be useful for exiting an eval(...) program.
Otherwise treat this like return, and step-over out
of the program should behave like step-out. We use
pause at next opportunity because there may be extra
callframes we do not know about.
When the program doesn't have a parent, clear all
our state so we don't errantly pause on the next
JavaScript microtask that gets executed.
(JSC::Debugger::clearNextPauseState):
Helper to clear all of the pause states now that
it happens in a couple places.
* interpreter/Interpreter.cpp:
(JSC::notifyDebuggerOfUnwinding):
Treat unwinding slightly differently from returning.
We will not want to pause when unwinding callframes.
(JSC::Interpreter::debug):
* interpreter/Interpreter.h:
New debug hook.
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::stepInto):
(Inspector::InspectorDebuggerAgent::didPause):
* inspector/agents/InspectorDebuggerAgent.h:
Remove unnecessary stepInto code notification for listeners.
The listeners are never notified if the debugger resumes,
so whatever state they were setting by this is going to
get out of date.
2016-09-30 Saam Barati <sbarati@apple.com>
Arrow functions should not allow duplicate parameter names
https://bugs.webkit.org/show_bug.cgi?id=162741
Reviewed by Filip Pizlo.
This patch makes parsing arrow function parameters throw
a syntax error when there are duplicate parameter names.
It also starts to make some syntax errors for arrow functions
better, however, this is trickier than it seems since we need
to choose between two parsing productions when we decide to
throw a syntax error. I'm going to work on this problem
in another patch specifically devoted to making the error
messages better for parsing arrow functions:
https://bugs.webkit.org/show_bug.cgi?id=162794
* parser/Parser.cpp:
(JSC::Parser<LexerType>::isArrowFunctionParameters):
(JSC::Parser<LexerType>::parseFormalParameters):
(JSC::Parser<LexerType>::parseFunctionParameters):
(JSC::Parser<LexerType>::parseAssignmentExpression):
* parser/Parser.h:
2016-09-30 Mark Lam <mark.lam@apple.com>
Use topVMEntryFrame to determine whether to skip the re-throw of a simulated throw.
https://bugs.webkit.org/show_bug.cgi?id=162793
Reviewed by Saam Barati.
Change the ThrowScope destructor to use topVMEntryFrame (instead of topCallFrame)
in the determination of whether to skip the re-throw of a simulated throw. This
is needed because the topCallFrame is not updated in operationConstructArityCheck()
(and does not need to be), whereas topVMEntryFrame is always updated properly.
Hence, we should just switch to using the more reliable topVMEntryFrame instead.
This issue was discovered by existing JSC tests when exception check validation
is enabled.
* runtime/ThrowScope.cpp:
(JSC::ThrowScope::~ThrowScope):
2016-09-30 Filip Pizlo <fpizlo@apple.com>
64-bit LLInt needs to have a concurrency-aware barrier
https://bugs.webkit.org/show_bug.cgi?id=162790
Reviewed by Mark Lam.
In a concurrent GC the barrier definitely has to be after the store, not before it.
* llint/LowLevelInterpreter64.asm:
2016-09-29 Filip Pizlo <fpizlo@apple.com>
Air should have a way of expressing additional instruction flags
https://bugs.webkit.org/show_bug.cgi?id=162699
Reviewed by Mark Lam.
This follows a similar change in B3 (r206595) and replaces Air::Opcode with Air::Kind,
which holds onto the opcode and some additional flags. Because Air is an orthogonal ISA
(the opcode tells you what the operation does but each operand is allowed to also contain
effectively instructions for what to do to read or write that operand), the flags are
meant to be orthogonal to opcode. This allows us to say things like Add32<Trap>, which
makes sense if any of the operands to the Add32 are addresses.
To demonstrate the flags facility this partly adds a trap flag to Air. B3 doesn't use it
yet, but I made sure that Air respects it. Basically that means blocking DCE when the flag
is set, by making it imply hasNonArgNonControlEffects.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3CheckSpecial.cpp:
(JSC::B3::Air::numB3Args):
(JSC::B3::CheckSpecial::Key::Key):
(JSC::B3::CheckSpecial::Key::dump):
(JSC::B3::CheckSpecial::CheckSpecial):
(JSC::B3::CheckSpecial::hiddenBranch):
(JSC::B3::CheckSpecial::forEachArg):
(JSC::B3::CheckSpecial::generate):
(JSC::B3::CheckSpecial::dumpImpl):
(JSC::B3::CheckSpecial::deepDumpImpl):
* b3/B3CheckSpecial.h:
(JSC::B3::CheckSpecial::Key::Key):
(JSC::B3::CheckSpecial::Key::operator==):
(JSC::B3::CheckSpecial::Key::kind):
(JSC::B3::CheckSpecial::Key::hash):
(JSC::B3::CheckSpecial::Key::opcode): Deleted.
* b3/B3Kind.cpp:
(JSC::B3::Kind::dump):
* b3/air/AirDumpAsJS.cpp:
(JSC::B3::Air::dumpAsJS):
* b3/air/AirFixObviousSpills.cpp:
* b3/air/AirFixPartialRegisterStalls.cpp:
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::generate):
* b3/air/AirHandleCalleeSaves.cpp:
(JSC::B3::Air::handleCalleeSaves):
* b3/air/AirInst.cpp:
(JSC::B3::Air::Inst::jsHash):
(JSC::B3::Air::Inst::dump):
* b3/air/AirInst.h:
(JSC::B3::Air::Inst::Inst):
(JSC::B3::Air::Inst::kind):
(JSC::B3::Air::Inst::operator bool):
(JSC::B3::Air::Inst::opcode): Deleted.
* b3/air/AirInstInlines.h:
(JSC::B3::Air::Inst::extraClobberedRegs):
(JSC::B3::Air::Inst::extraEarlyClobberedRegs):
(JSC::B3::Air::Inst::forEachDefWithExtraClobberedRegs):
(JSC::B3::Air::Inst::reportUsedRegisters):
(JSC::B3::Air::Inst::shouldTryAliasingDef):
* b3/air/AirIteratedRegisterCoalescing.cpp:
* b3/air/AirKind.cpp: Added.
(JSC::B3::Air::Kind::dump):
* b3/air/AirKind.h: Added.
(JSC::B3::Air::Kind::Kind):
(JSC::B3::Air::Kind::operator==):
(JSC::B3::Air::Kind::operator!=):
(JSC::B3::Air::Kind::hash):
(JSC::B3::Air::Kind::operator bool):
* b3/air/AirLowerAfterRegAlloc.cpp:
(JSC::B3::Air::lowerAfterRegAlloc):
* b3/air/AirLowerEntrySwitch.cpp:
(JSC::B3::Air::lowerEntrySwitch):
* b3/air/AirLowerMacros.cpp:
(JSC::B3::Air::lowerMacros):
* b3/air/AirOptimizeBlockOrder.cpp:
(JSC::B3::Air::optimizeBlockOrder):
* b3/air/AirReportUsedRegisters.cpp:
(JSC::B3::Air::reportUsedRegisters):
* b3/air/AirSimplifyCFG.cpp:
(JSC::B3::Air::simplifyCFG):
* b3/air/AirTmpWidth.cpp:
(JSC::B3::Air::TmpWidth::recompute):
* b3/air/AirUseCounts.h:
(JSC::B3::Air::UseCounts::UseCounts):
* b3/air/AirValidate.cpp:
* b3/air/opcode_generator.rb:
* b3/testb3.cpp:
(JSC::B3::testTernarySubInstructionSelection):
(JSC::B3::testBranchBitAndImmFusion):
2016-09-29 Filip Pizlo <fpizlo@apple.com>
REGRESSION(r206555): It made Dromaeo/jslib-style-jquery.html crash
https://bugs.webkit.org/show_bug.cgi?id=162721
Reviewed by Keith Miller.
The put_by_id-in-put_by_val optimization had the write barrier in the wrong place and
incorrectly filtered on value instead of base.
No reduced test case. You really need to run Dromaeo/jslib to catch it. I love Dromaeo's
ability to catch GC bugs.
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitPutByValWithCachedId):
2016-09-29 Joseph Pecoraro <pecoraro@apple.com>
Arrow functions do not infer name from computed property but normal functions do
https://bugs.webkit.org/show_bug.cgi?id=162720
Reviewed by Saam Barati.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitSetFunctionNameIfNeeded):
Set function name on arrow functions as well.
2016-09-29 Joseph Pecoraro <pecoraro@apple.com>
test262: class and function names should be inferred in assignment
https://bugs.webkit.org/show_bug.cgi?id=146262
Reviewed by Saam Barati.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::appendParameter):
(JSC::ASTBuilder::appendArrayPatternEntry):
(JSC::ASTBuilder::appendObjectPatternEntry):
(JSC::ASTBuilder::tryInferFunctionNameInPattern):
Assign names to default value functions and classes in destructuring.
(JSC::ASTBuilder::createAssignResolve):
(JSC::ASTBuilder::createProperty):
(JSC::ASTBuilder::makeAssignNode):
Assign names to both normal and arrow functions.
* parser/Nodes.h:
(JSC::ExpressionNode::isBaseFuncExprNode):
Both functions and arrow functions infer name, they both extend
this base so give the base an is check.
2016-09-28 Filip Pizlo <fpizlo@apple.com>
B3 opcodes should leave room for flags
https://bugs.webkit.org/show_bug.cgi?id=162692
Reviewed by Keith Miller.
It used to be that the main thing that determined what a Value did was the opcode. The
Opcode was how you knew what subclass of Value you had. The opcode told you what the Value
actually did. This change replaces Opcode with Kind, which is a tuple of opcode and other
stuff.
Opcodes are great, and that's how most compilers work. But opcodes are one-dimensional. Here
is how this manifests. Say you have an opcode, like Load. You will be happy if your IR has
one Load opcode. But then, you might add Load8S/Load8Z/Load16S/Load16Z opcodes, as we have
done in B3. B3 has one dimension of Load opcodes, which determines something like the C type
of the load. But in the very near future, we will want to add two more dimensions to Loads:
- A flag to say if the load traps.
- A flag to say if the load has acquire semantics.
Mapping these three dimensions (type, trap, acquire) onto the one-dimensional Opcode space
would create mayham: Load8S, Load8STrap, Load8SAcquire, Load8STrapAcquire, Load8Z,
Load8ZTrap, etc.
This happens in other parts of the IR. For example, we have a dimension of arithmetic
operations: add, sub, mul, div, mod, etc. Then we have the chill flag. But since opcodes
are one-dimensional, that means having ChillDiv and ChillMod, and tons of places in the
compiler that case on both Div and ChillDiv, or case on both Mod and ChillMod, since they
are only interested in the kind of arithmetic being done and not the chillness.
Though the examples all involve bits (chill or not, trapping or not, etc), I can imagine
other properties that behave more like small enums, like if we fill out more memory ordering
modes other than just "acquire? yes/no". There will eventually have to be something like a
std::memory_order associated with memory accesses.
One approach to this problem is to have a Value subclass that contains fields with the meta
data. I don't like this for two reasons:
- In bug 162688, I want to make trapping memory accesses have stackmaps. This means that a
trapping memory access would have a different Value subclass than a non-trapping memory
access. So, this meta-data needs to channel into ValueType::accepts(). Currently that
takes Opcode and nothing else.
- Compiler IRs are all about making common tasks easy. If it becomes commonplace for opcodes
to require a custom Value subclass just for a bit then that's not very easy.
This change addresses this problem by making the compiler pass around Kinds rather than
Opcodes. A Kind contains an Opcode as well as any number of opcode-specific bits. This
change demonstrates how Kind should be used by converting chillness to it. Kind has
hasIsChill(), isChill(), and setIsChill() methods. hasIsChill() is true only for Div and
Mod. setIsChill() asserts if !hasIsChill(). If you want to create a Chill Div, you say
chill(Div). IR dumps will print it like this:
Int32 @38 = Div<Chill>(@36, @37, DFG:@24, ControlDependent)
Where "Div<Chill>" is how a Kind that hasExtraBits() dumps itself. If a Kind does not
hasExtraBits() (the normal case) then it dumps like a normal Opcode (without the "<>").
I replaced many uses of Opcode with Kind. New code has to be mindful that Opcode may not be
the right way to summarize what a value does, and so in many cases it's better to carry
around a Kind instead - especially if you will use it to stamp out new Values. Opcode is no
longer sufficient to perform a dynamic Value cast, since that code now uses Kind. ValueKey
now wants a Kind instead of an Opcode. All Value constructors now take Kind instead of
Opcode. But most opcodes don't get any extra Kind bits, and so the code that operates on
those opcodes is largely unchanged.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3ArgumentRegValue.h:
* b3/B3CCallValue.h:
* b3/B3CheckValue.cpp:
(JSC::B3::CheckValue::convertToAdd):
(JSC::B3::CheckValue::CheckValue):
* b3/B3CheckValue.h:
(JSC::B3::CheckValue::accepts):
* b3/B3Const32Value.h:
* b3/B3Const64Value.h:
* b3/B3ConstDoubleValue.h:
* b3/B3ConstFloatValue.h:
* b3/B3FenceValue.h:
* b3/B3Kind.cpp: Added.
(JSC::B3::Kind::dump):
* b3/B3Kind.h: Added.
(JSC::B3::Kind::Kind):
(JSC::B3::Kind::opcode):
(JSC::B3::Kind::setOpcode):
(JSC::B3::Kind::hasExtraBits):
(JSC::B3::Kind::hasIsChill):
(JSC::B3::Kind::isChill):
(JSC::B3::Kind::setIsChill):
(JSC::B3::Kind::operator==):
(JSC::B3::Kind::operator!=):
(JSC::B3::Kind::hash):
(JSC::B3::Kind::isHashTableDeletedValue):
(JSC::B3::chill):
(JSC::B3::KindHash::hash):
(JSC::B3::KindHash::equal):
* b3/B3LowerMacros.cpp:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/B3MemoryValue.h:
* b3/B3Opcode.cpp:
(WTF::printInternal):
* b3/B3Opcode.h:
* b3/B3PatchpointValue.h:
(JSC::B3::PatchpointValue::accepts):
* b3/B3ReduceStrength.cpp:
* b3/B3SlotBaseValue.h:
* b3/B3StackmapValue.cpp:
(JSC::B3::StackmapValue::StackmapValue):
* b3/B3StackmapValue.h:
* b3/B3SwitchValue.h:
(JSC::B3::SwitchValue::accepts):
* b3/B3UpsilonValue.h:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::dump):
(JSC::B3::Value::deepDump):
(JSC::B3::Value::invertedCompare):
(JSC::B3::Value::effects):
(JSC::B3::Value::key):
(JSC::B3::Value::typeFor):
(JSC::B3::Value::badKind):
(JSC::B3::Value::badOpcode): Deleted.
* b3/B3Value.h:
* b3/B3ValueInlines.h:
(JSC::B3::Value::as):
* b3/B3ValueKey.cpp:
(JSC::B3::ValueKey::dump):
(JSC::B3::ValueKey::materialize):
* b3/B3ValueKey.h:
(JSC::B3::ValueKey::ValueKey):
(JSC::B3::ValueKey::kind):
(JSC::B3::ValueKey::opcode):
(JSC::B3::ValueKey::operator==):
(JSC::B3::ValueKey::hash):
* b3/B3ValueKeyInlines.h:
(JSC::B3::ValueKey::ValueKey):
* b3/B3VariableValue.cpp:
(JSC::B3::VariableValue::VariableValue):
* b3/B3VariableValue.h:
* b3/testb3.cpp:
(JSC::B3::testChillDiv):
(JSC::B3::testChillDivTwice):
(JSC::B3::testChillDiv64):
(JSC::B3::testChillModArg):
(JSC::B3::testChillModArgs):
(JSC::B3::testChillModImms):
(JSC::B3::testChillModArg32):
(JSC::B3::testChillModArgs32):
(JSC::B3::testChillModImms32):
(JSC::B3::testSwitchChillDiv):
(JSC::B3::testEntrySwitchWithCommonPaths):
(JSC::B3::testEntrySwitchWithCommonPathsAndNonTrivialEntrypoint):
* ftl/FTLOutput.cpp:
(JSC::FTL::Output::chillDiv):
(JSC::FTL::Output::chillMod):
2016-09-29 Saam Barati <sbarati@apple.com>
We don't properly propagate non-simple-parameter-list when parsing a setter
https://bugs.webkit.org/show_bug.cgi?id=160483
Reviewed by Joseph Pecoraro.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionParameters):
2016-09-28 Saam Barati <sbarati@apple.com>
stringProtoFuncRepeatCharacter will return `null` when it should not
https://bugs.webkit.org/show_bug.cgi?id=161944
Reviewed by Yusuke Suzuki.
stringProtoFuncRepeatCharacter was expecting its second argument
to always be a boxed integer. This is not correct. The DFG may decide
to represent a particular value as a double instead of integer. This
function needs to have correct behavior when its second argument is
a boxed double. I also added an assertion stating that the second argument
is always a number. We can guarantee this since it's only called from
builtins.
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncRepeatCharacter):
2016-09-28 Filip Pizlo <fpizlo@apple.com>
The write barrier should be down with TSO
https://bugs.webkit.org/show_bug.cgi?id=162316
Reviewed by Geoffrey Garen.
This makes our write barrier behave correctly when it races with the collector. The
collector wants to do this when visiting:
object->cellState = black
visit(object)
The mutator wants to do this when storing:
object->property = newValue
if (object->cellState == black)
remember(object)
Prior to this change, this didn't work right because the compiler would sometimes place
barriers before the store to the property and because the mutator did not have adequate
fences.
Prior to this change, the DFG and FTL would emit this:
if (object->cellState == black)
remember(object)
object->property = newValue
Which is wrong, because the object could start being scanned just after the cellState
check, at which point the store would be lost. We need to confirm that the state was not
black *after* the store! This change was harder than you'd expect: placing the barrier
after the store broke B3's ability to do its super crazy ninja CSE on some store-load
redundancies. Because the B3 CSE has some moves that the DFG CSE lacks, the DFG CSE's
ability to ignore barriers didn't help. I fixed this by having the FTL convey precise
heap ranges for the patchpoint corresponding to the barrier slow path. It reads the world
(because of the store-load fence) and it writes only cellState (because the B3 heap ranges
don't have any way to represent any of the GC's other state, which means that B3 does not
have to worry about aliasing with any of that).
The collector already uses a store-load fence on x86 just after setting the cellState and
before visiting the object. The mutator needs to do the same. But we cannot put a
store-load fence of any kind before store barriers, because that causes enormous slow
downs. In the worst case, Octane/richards slowed down by 90%! That's crazy! However, the
overall slow downs were small enough (0-15% on benchmark suite aggregates) that it would be
reasonable if the slow down only happened while the GC was running. Then, the concurrent GC
would lift throughput-while-collecting from 0% of peak to 85% of peak. This changes the
barrier so that it looks like this:
if (object->cellState <= heap.sneakyBlackThreshold)
slowPath(object)
Where sneakyBlackThreshold is the normal blackThreshold when we're not collecting, or a
tautoligical threshold (that makes everything look black) when we are collecting. This
turns out to not be any more expensive than the barrier in tip of tree when the GC is not
running, or a 0-15% slow-down when it is "running". (Of course we don't run the GC
concurrently yet. I still have more work to do.) The slowPath() does some extra work to
check if we are concurrently collecting; if so, it does a fence and rechecks if the object
really did need that barrier.
This also reintroduces elimination of redundant store barriers, which was lost in the last
store barrier change. We can only do it when there is no possibility of GC, exit, or
exceptions between the two store barriers. We could remove the exit/exception limitation if
we taught OSR exit how to buffer store barriers, which is an insane thing to do considering
that I've never been able to detect a win from redundant store barrier elimination. I just
want us to have it for stupidly obvious situations, like a tight sequence of stores to the
same object. This same optimization also sometimes strength-reduces the store barrier so
that it uses a constant black threshold rather than the sneaky one, thereby saving one
load.
Even with all of those optimizations, I still had problems with barrier cost. I found that one
of the benchmarks that was being hit particularly hard was JetStream/regexp-2010. Fortunately
that benchmark does most of its barriers in a tight C++ loop in RegExpMatchesArray.h. When we
know what we're doing, we can defer GC around a bunch of object initializations and then remove
all of the barriers between any of the objects allocated within the deferral. Unfortunately,
our GC deferral mechanism isn't really performant enough to make this be a worthwhile
optimization. The most efficient version of such an optimization that I could come up with was
to have a DeferralContext object that houses a boolean that is false by default, but the GC
writes true into it if it would have wanted to GC. You thread a pointer to the deferralContext
through all of your allocations. This kind of mechanism has the overhead of a zero
initialization on the stack on entry and a zero check on exit. This is probably even efficient
enough that we could start thinking about having the DFG use it, for example if we found a
bounded-time section of code with a lot of barriers and entry/exit sites that aren't totally
wacky. This optimization took this patch from 0.68% JetStream regressed to neutral, according
to my latest data.
Finally, an earlier version of this change put the store-load fence in B3 IR, so I ended up
adding FTLOutput support for it and AbstractHeapRepository magic for decorating the heaps.
I think we might as well keep that, it'll be useful.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::branch32):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::branch32):
(JSC::MacroAssemblerX86_64::branch64): Deleted.
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generateImpl):
* dfg/DFGAbstractHeap.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGClobbersExitState.cpp:
(JSC::DFG::clobbersExitState):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGMayExit.cpp:
* dfg/DFGNode.h:
(JSC::DFG::Node::isStoreBarrier):
* dfg/DFGNodeType.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileStoreBarrier):
(JSC::DFG::SpeculativeJIT::storeToWriteBarrierBuffer): Deleted.
(JSC::DFG::SpeculativeJIT::writeBarrier): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier): Deleted.
(JSC::DFG::SpeculativeJIT::writeBarrier): Deleted.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier): Deleted.
(JSC::DFG::SpeculativeJIT::writeBarrier): Deleted.
* dfg/DFGStoreBarrierClusteringPhase.cpp: Added.
(JSC::DFG::performStoreBarrierClustering):
* dfg/DFGStoreBarrierClusteringPhase.h: Added.
* dfg/DFGStoreBarrierInsertionPhase.cpp:
* dfg/DFGStoreBarrierInsertionPhase.h:
* ftl/FTLAbstractHeap.h:
(JSC::FTL::AbsoluteAbstractHeap::at):
(JSC::FTL::AbsoluteAbstractHeap::operator[]):
* ftl/FTLAbstractHeapRepository.cpp:
(JSC::FTL::AbstractHeapRepository::decorateFenceRead):
(JSC::FTL::AbstractHeapRepository::decorateFenceWrite):
(JSC::FTL::AbstractHeapRepository::computeRangesAndDecorateInstructions):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileStoreBarrier):
(JSC::FTL::DFG::LowerDFGToB3::storageForTransition):
(JSC::FTL::DFG::LowerDFGToB3::lazySlowPath):
(JSC::FTL::DFG::LowerDFGToB3::emitStoreBarrier):
* ftl/FTLOutput.cpp:
(JSC::FTL::Output::fence):
(JSC::FTL::Output::absolute):
* ftl/FTLOutput.h:
* heap/CellState.h:
(JSC::isWithinThreshold):
(JSC::isBlack):
* heap/Heap.cpp:
(JSC::Heap::writeBarrierSlowPath):
* heap/Heap.h:
(JSC::Heap::barrierShouldBeFenced):
(JSC::Heap::addressOfBarrierShouldBeFenced):
(JSC::Heap::sneakyBlackThreshold):
(JSC::Heap::addressOfSneakyBlackThreshold):
* heap/HeapInlines.h:
(JSC::Heap::writeBarrier):
(JSC::Heap::writeBarrierWithoutFence):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::jumpIfIsRememberedOrInEdenWithoutFence):
(JSC::AssemblyHelpers::sneakyJumpIfIsRememberedOrInEden):
(JSC::AssemblyHelpers::jumpIfIsRememberedOrInEden):
(JSC::AssemblyHelpers::storeBarrierStoreLoadFence):
(JSC::AssemblyHelpers::jumpIfStoreBarrierStoreLoadFenceNotNeeded):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_put_by_id):
(JSC::JIT::emitWriteBarrier):
(JSC::JIT::privateCompilePutByVal):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_put_by_id):
* llint/LowLevelInterpreter.asm:
* offlineasm/x86.rb:
* runtime/Options.h:
2016-09-27 Joseph Pecoraro <pecoraro@apple.com>
Improve useCodeCache Option description string.
* runtime/Options.h:
Address late review comments and clarify description.
2016-09-28 Filip Pizlo <fpizlo@apple.com>
Optimize B3->Air lowering of Fence on ARM
https://bugs.webkit.org/show_bug.cgi?id=162342
Reviewed by Geoffrey Garen.
This gives us comprehensive support for standalone fences on x86 and ARM. The changes are as
follows:
- Sets in stone the rule that the heaps of a B3::Fence tell you what the fence protects. If the
fence reads, it protects motion of stores. If the fence writes, it protects motion of loads.
This allows us to express for example load-load fences in a portable way: on x86 they will just
block B3 optimizations and emit no code, while on ARM you will get some fence.
- Adds comprehensive support for WTF-style fences in the ARM assembler. I simplified it just a bit
to match what B3, the main client, knows. There are three fences: MemoryFence, StoreFence, and
LoadFence. On x86, MemoryFence is ortop while StoreFence and LoadFence emit no code. On ARM64,
MemoryFence and LoadFence are dmb ish while StoreFence is dmb ishst.
- Tests! To test this, I needed to teach the disassembler how to disassemble dmb ish and dmb
ishst. I think that the canonical way to do it would be to create a group for dmb and then teach
that group how to decode the operands. But I don't actually know what are all of the ways of
encoding dmb, so I'd rather that unrecognized encodings fall through to the ".long blah"
bailout. So, this creates explicit matching rules for "dmb ish" and "dmb ishst", which is the
most conservative thing we can do.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::dmbISH):
(JSC::ARM64Assembler::dmbISHST):
(JSC::ARM64Assembler::dmbSY): Deleted.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::memoryFence):
(JSC::MacroAssemblerARM64::storeFence):
(JSC::MacroAssemblerARM64::loadFence):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::storeFence):
(JSC::MacroAssemblerX86Common::loadFence):
* b3/B3FenceValue.h:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testMemoryFence):
(JSC::B3::testStoreFence):
(JSC::B3::testLoadFence):
(JSC::B3::run):
(JSC::B3::testX86MFence): Deleted.
(JSC::B3::testX86CompilerFence): Deleted.
* disassembler/ARM64/A64DOpcode.cpp:
(JSC::ARM64Disassembler::A64DOpcodeDmbIsh::format):
(JSC::ARM64Disassembler::A64DOpcodeDmbIshSt::format):
* disassembler/ARM64/A64DOpcode.h:
(JSC::ARM64Disassembler::A64DOpcodeDmbIsh::opName):
(JSC::ARM64Disassembler::A64DOpcodeDmbIshSt::opName):
2016-09-28 Joseph Pecoraro <pecoraro@apple.com>
Adopt #pragma once in some generated resources
https://bugs.webkit.org/show_bug.cgi?id=162666
Reviewed by Alex Christensen.
* Scripts/builtins/builtins_generate_combined_header.py:
* Scripts/builtins/builtins_generate_internals_wrapper_header.py:
* Scripts/builtins/builtins_generate_internals_wrapper_implementation.py:
* Scripts/builtins/builtins_generate_separate_header.py:
* Scripts/builtins/builtins_generate_wrapper_header.py:
* Scripts/builtins/builtins_generate_wrapper_implementation.py:
Remove headerGuard attribute unused by templates.
* Scripts/tests/builtins/expected/JavaScriptCore-Operations.Promise-Combined.js-result: Removed.
No such test exists. It was likely renamed.
* generate-bytecode-files:
Simplify header guard output.
* inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
(ObjCBackendDispatcherHeaderGenerator.generate_output):
* replay/scripts/CodeGeneratorReplayInputs.py:
(Generator.generate_header):
* replay/scripts/CodeGeneratorReplayInputsTemplates.py:
Simplify header guard output.
* replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-input-with-guard.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-input-with-vector-members.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-inputs-with-flags.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-memoized-type-modes.json-TestReplayInputs.h:
Rebaseline.
2016-09-28 Filip Pizlo <fpizlo@apple.com>
Store-load fences should be a lot cheaper on ARM
https://bugs.webkit.org/show_bug.cgi?id=162461
Rubber stamped by Keith Miller.
It turns out that they are already cheap enough, so this change just make us use them.
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::visitChildren):
2016-09-28 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r206522.
Roll r206506 back in since the build fix landed in r206521
Reverted changeset:
"Unreviewed, rolling out r206506."
https://bugs.webkit.org/show_bug.cgi?id=162682
http://trac.webkit.org/changeset/206522
2016-09-28 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r206506.
https://bugs.webkit.org/show_bug.cgi?id=162682
Broke the Windows and WinCairo builds. (Requested by
ryanhaddad on #webkit).
Reverted changeset:
"Adopt #pragma once in JavaScriptCore"
https://bugs.webkit.org/show_bug.cgi?id=162664
http://trac.webkit.org/changeset/206506
2016-09-28 Joseph Pecoraro <pecoraro@apple.com>
Adopt #pragma once in JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=162664
Reviewed by Saam Barati.
* **/**.h:
Adopt pragma once in all but API headers and generated headers.
Include some namespace closing comments for consistency.
2016-09-27 JF Bastien <jfbastien@apple.com>
Missing Atomics.h include in MarkedBlock.h
https://bugs.webkit.org/show_bug.cgi?id=162648
Missing include from my previous patch.
Reviewed by Yusuke Suzuki.
* heap/MarkedBlock.h:
2016-09-27 Mark Lam <mark.lam@apple.com>
createError() and JSObject::calculatedClassName() should not throw any exceptions.
https://bugs.webkit.org/show_bug.cgi?id=162637
Reviewed by Geoffrey Garen.
* runtime/ExceptionHelpers.cpp:
(JSC::createError):
- assert that errorDescriptionForValue() did not throw an exception.
* runtime/JSObject.cpp:
(JSC::JSObject::calculatedClassName):
- the code already ensures that we always return a non-null String. Just need to
make sure that it catches its own exceptions.
2016-09-27 Filip Pizlo <fpizlo@apple.com>
B3::lowerMacros forgets to before->updatePredecessorsAfter() when lowering ChillMod on ARM64
https://bugs.webkit.org/show_bug.cgi?id=162644
Reviewed by Keith Miller.
If you forget to update the predecessors of your successors, then bad things will happen if you
do something that requires accurate predecessors for correctness. lowerMacros() uses
BlockInsertionSet, which relies on accurate predecessors.
* b3/B3LowerMacros.cpp:
2016-09-27 JF Bastien <jfbastien@apple.com>
Speed up Heap::isMarkedConcurrently
https://bugs.webkit.org/show_bug.cgi?id=162095
Reviewed by Filip Pizlo.
Speed up isMarkedConcurrently by using WTF::consumeLoad.
* heap/MarkedBlock.h:
(JSC::MarkedBlock::areMarksStale):
(JSC::MarkedBlock::areMarksStaleWithDependency):
(JSC::MarkedBlock::isMarkedConcurrently): do away with the load-load fence
2016-09-27 Mark Lam <mark.lam@apple.com>
Add some needed CatchScopes in code that should not throw.
https://bugs.webkit.org/show_bug.cgi?id=162584
Reviewed by Keith Miller.
Re-landing minus the jsc.cpp and ExceptionHelpers.cpp changes. I'll address
those in a subsequent patch if the need manifests again in my testing.
* API/JSObjectRef.cpp:
(JSObjectSetProperty):
- This function already handles exceptions in its own way. We're honoring this
contract and catching exceptions and passing it to the handler.
* interpreter/Interpreter.cpp:
(JSC::notifyDebuggerOfUnwinding):
- The debugger should not be throwing any exceptions.
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::save):
- If an exception was thrown while saving the database, there's nothing we can
really do about it anyway. Just fail nicely and return false. This is in line
with existing error checking code in Database::save() that returns false if
it's not able to open the file to save to.
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::finishCreation):
- The existing code already RELEASE_ASSERT that no exception was thrown.
Hence, it's appropriate to use a CatchScope here.
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::StackFrame::nameFromCallee):
- The sampling profiler is doing a VMInquiry get here. It should never throw an
exception. Hence, we'll just use a CatchScope and assert accordingly.
2016-09-27 Jer Noble <jer.noble@apple.com>
Remove deprecated ENCRYPTED_MEDIA implementation.
https://bugs.webkit.org/show_bug.cgi?id=161010
Reviewed by Eric Carlson.
Remove ENABLE_ENCRYPTED_MEDIA.
* Configurations/FeatureDefines.xcconfig:
2016-09-27 Michael Catanzaro <mcatanzaro@igalia.com>
[GTK] Install binaries to pkglibexecdir rather than bindir
https://bugs.webkit.org/show_bug.cgi?id=162602
Reviewed by Carlos Garcia Campos.
Install jsc shell to LIBEXEC_INSTALL_DIR rather than EXEC_INSTALL_DIR.
Note these locations are the same on non-GTK ports.
* shell/CMakeLists.txt:
2016-09-26 Sam Weinig <sam@webkit.org>
Make DFGSlowPathGenerator a bit more variadic
https://bugs.webkit.org/show_bug.cgi?id=162378
Reviewed by Filip Pizlo.
Make the subclass of CallSlowPathGenerator that takes arguments variadic
so it can take any number of arguments. Also updates the slowPathCall helper
function to be variadic. I had to move the spill mode and exception check
requirement parameters to before the arguments since the variadic arguments
must be at the end. As a convenience, I added an overload of slowPathCall that
doesn't take spill mode and exception check requirement parameters.
* dfg/DFGSlowPathGenerator.h:
(JSC::DFG::CallResultAndArgumentsSlowPathGenerator::CallResultAndArgumentsSlowPathGenerator):
(JSC::DFG::CallResultAndArgumentsSlowPathGenerator::unpackAndGenerate):
(JSC::DFG::slowPathCall):
(JSC::DFG::CallResultAndNoArgumentsSlowPathGenerator::CallResultAndNoArgumentsSlowPathGenerator): Deleted.
(JSC::DFG::CallResultAndOneArgumentSlowPathGenerator::CallResultAndOneArgumentSlowPathGenerator): Deleted.
(JSC::DFG::CallResultAndTwoArgumentsSlowPathGenerator::CallResultAndTwoArgumentsSlowPathGenerator): Deleted.
(JSC::DFG::CallResultAndThreeArgumentsSlowPathGenerator::CallResultAndThreeArgumentsSlowPathGenerator): Deleted.
(JSC::DFG::CallResultAndFourArgumentsSlowPathGenerator::CallResultAndFourArgumentsSlowPathGenerator): Deleted.
(JSC::DFG::CallResultAndFourArgumentsSlowPathGenerator::generateInternal): Deleted.
(JSC::DFG::CallResultAndFiveArgumentsSlowPathGenerator::CallResultAndFiveArgumentsSlowPathGenerator): Deleted.
(JSC::DFG::CallResultAndFiveArgumentsSlowPathGenerator::generateInternal): Deleted.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueToInt32):
(JSC::DFG::SpeculativeJIT::compileNotifyWrite):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetById):
2016-09-26 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r206405.
https://bugs.webkit.org/show_bug.cgi?id=162588
This change caused LayoutTest crashes. (Requested by
ryanhaddad on #webkit).
Reverted changeset:
"Add some needed CatchScopes in code that should not throw."
https://bugs.webkit.org/show_bug.cgi?id=162584
http://trac.webkit.org/changeset/206405
2016-09-26 Mark Lam <mark.lam@apple.com>
Add some needed CatchScopes in code that should not throw.
https://bugs.webkit.org/show_bug.cgi?id=162584
Reviewed by Keith Miller.
* API/JSObjectRef.cpp:
(JSObjectSetProperty):
- This function already handles exceptions in its own way. We're honoring this
contract and catching exceptions and passing it to the handler.
* interpreter/Interpreter.cpp:
(JSC::notifyDebuggerOfUnwinding):
- The debugger should not be throwing any exceptions.
* jsc.cpp:
(runJSC):
- the buck stops here. There's no reason an exception should propagate past here.
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::save):
- If an exception was thrown while saving the database, there's nothing we can
really do about it anyway. Just fail nicely and return false. This is in line
with existing error checking code in Database::save() that returns false if
it's not able to open the file to save to.
* runtime/ExceptionHelpers.cpp:
(JSC::createError):
- If we're not able to stringify the error value, then we'll just use the
provided message as the error string. It doesn't make sense to have the
Error factory throw an exception that shadows the intended exception that the
client probably wants to throw (assuming that that's why the client is creating
this Error object).
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::finishCreation):
- The existing code already RELEASE_ASSERT that no exception was thrown.
Hence, it's appropriate to use a CatchScope here.
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::StackFrame::nameFromCallee):
- The sampling profiler is doing a VMInquiry get here. It should never throw an
exception. Hence, we'll just use a CatchScope and assert accordingly.
2016-09-26 Mark Lam <mark.lam@apple.com>
Exception unwinding code should use a CatchScope instead of a ThrowScope.
https://bugs.webkit.org/show_bug.cgi?id=162583
Reviewed by Geoffrey Garen.
This is because the exception unwinding code does not throw an exception.
It only inspects the thrown exception and passes it to the appropriate handler.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::unwind):
* jit/JITExceptions.cpp:
(JSC::genericUnwind):
2016-09-26 Joseph Pecoraro <pecoraro@apple.com>
Add an Option to disable the CodeCache
https://bugs.webkit.org/show_bug.cgi?id=162579
Reviewed by Geoffrey Garen.
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
Do not use the cache if the Option is disabled.
* runtime/Options.h:
New option to not use the code cache.
2016-09-26 Daniel Bates <dabates@apple.com>
Rename IOS_TEXT_AUTOSIZING to TEXT_AUTOSIZING
https://bugs.webkit.org/show_bug.cgi?id=162365
Reviewed by Simon Fraser.
* Configurations/FeatureDefines.xcconfig:
2016-09-26 Benjamin Poulain <benjamin@webkit.org>
[JSC] Shrink the Math inline caches some more
https://bugs.webkit.org/show_bug.cgi?id=162485
Reviewed by Saam Barati.
This patch applies some lessons learnt from op_negate
to shrink the generated asm of the previous 3 inline
caches.
In order of importance:
-We do not need to pass the pointer to ArithProfile
on the slow path. We can just get the profile out
of the Math IC.
This saves us from materializing a 64bits value
in a register before the call on the slow path.
-We can remove a bunch of mov by setting up the registers
in the way the slow path needs them.
The slow path makes a function calls with the input
as second and third arguments, and return the result in
the "return register". By using those as target when
loading/storing from the stack, we remove 3 mov per slow path.
-When performing integer add, we can set the result directly in
the output register if that does not trashes one of the input
register. This removes one mov per integer add.
The inline cache average sizes on Sunspider change as follow:
-Adds: 147.573099->131.555556 (~10%)
-Muls: 186.882353->170.991597 (~8%)
-Subs: 139.127907->121.523256 (~12%)
* jit/JIT.h:
* jit/JITAddGenerator.cpp:
(JSC::JITAddGenerator::generateInline):
(JSC::JITAddGenerator::generateFastPath):
* jit/JITArithmetic.cpp:
(JSC::JIT::emitMathICFast):
(JSC::JIT::emitMathICSlow):
* jit/JITInlines.h:
(JSC::JIT::callOperation): Deleted.
* jit/JITOperations.cpp:
* jit/JITOperations.h:
2016-09-26 Mark Lam <mark.lam@apple.com>
Added RETURN_IF_EXCEPTION() macro and use it for exception checks.
https://bugs.webkit.org/show_bug.cgi?id=162521
Reviewed by Saam Barati.
Also, where possible, if the return type is JSValue, changed the returned value
(on exception) to the empty JSValue (instead of sometimes jsUndefined, jsNull,
or the thrown exception value).
There are a few places where I had to continue to return the previously returned
value (instead of the empty JSValue) in order for tests to pass. This is needed
because there are missing exception checks that will need to be added before I
can change those to return the empty JSValue too. Identifying all the places
where those checks need to be added is beyond the scope of this patch. I will
work on adding missing exception checks in a subsequent patch.
In this patch, there is one missing exception check in replaceUsingRegExpSearch()
that was easily identified, and is necessary so that Interpreter::execute()
functions can return JSValue. I've added this missing check.
This patch has passed the JSC and layout tests.
* dfg/DFGOperations.cpp:
(JSC::DFG::operationPutByValInternal):
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
(Inspector::JSInjectedScriptHost::getInternalProperties):
(Inspector::JSInjectedScriptHost::weakMapEntries):
(Inspector::JSInjectedScriptHost::weakSetEntries):
(Inspector::JSInjectedScriptHost::iteratorEntries):
* inspector/JSJavaScriptCallFrame.cpp:
(Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
* interpreter/Interpreter.cpp:
(JSC::eval):
(JSC::sizeOfVarargs):
(JSC::Interpreter::execute):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
* interpreter/ShadowChicken.cpp:
(JSC::ShadowChicken::functionsOnStack):
* jit/JITOperations.cpp:
(JSC::getByVal):
* jsc.cpp:
(WTF::ImpureGetter::getOwnPropertySlot):
(functionRun):
(functionRunString):
(functionLoad):
(functionLoadString):
(functionReadFile):
(functionCheckSyntax):
(functionSetRandomSeed):
(functionLoadModule):
(functionCreateBuiltin):
(functionCheckModuleSyntax):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::getByVal):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* profiler/ProfilerBytecodeSequence.cpp:
(JSC::Profiler::BytecodeSequence::addSequenceProperties):
* profiler/ProfilerCompilation.cpp:
(JSC::Profiler::Compilation::toJS):
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::toJS):
* profiler/ProfilerOSRExitSite.cpp:
(JSC::Profiler::OSRExitSite::toJS):
* profiler/ProfilerOriginStack.cpp:
(JSC::Profiler::OriginStack::toJS):
* runtime/ArrayPrototype.cpp:
(JSC::speciesConstructArray):
(JSC::shift):
(JSC::unshift):
(JSC::arrayProtoFuncToString):
(JSC::arrayProtoFuncToLocaleString):
(JSC::slowJoin):
(JSC::fastJoin):
(JSC::arrayProtoFuncJoin):
(JSC::arrayProtoFuncPop):
(JSC::arrayProtoFuncPush):
(JSC::arrayProtoFuncReverse):
(JSC::arrayProtoFuncShift):
(JSC::arrayProtoFuncSlice):
(JSC::arrayProtoFuncSplice):
(JSC::arrayProtoFuncUnShift):
(JSC::arrayProtoFuncIndexOf):
(JSC::arrayProtoFuncLastIndexOf):
(JSC::moveElements):
(JSC::arrayProtoPrivateFuncConcatMemcpy):
* runtime/BooleanConstructor.cpp:
(JSC::constructWithBooleanConstructor):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::opIn):
* runtime/Completion.cpp:
(JSC::loadAndEvaluateModule):
(JSC::loadModule):
* runtime/ConsoleObject.cpp:
(JSC::consoleProtoFuncAssert):
(JSC::consoleProtoFuncProfile):
(JSC::consoleProtoFuncProfileEnd):
(JSC::consoleProtoFuncTakeHeapSnapshot):
(JSC::consoleProtoFuncTime):
(JSC::consoleProtoFuncTimeEnd):
* runtime/DateConstructor.cpp:
(JSC::constructDate):
(JSC::dateParse):
* runtime/DatePrototype.cpp:
(JSC::dateProtoFuncToPrimitiveSymbol):
(JSC::dateProtoFuncToJSON):
* runtime/ErrorConstructor.cpp:
(JSC::Interpreter::constructWithErrorConstructor):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::sanitizedToString):
* runtime/ErrorPrototype.cpp:
(JSC::errorProtoFuncToString):
* runtime/ExceptionScope.h:
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments<Type>::copyToArguments):
* runtime/GetterSetter.cpp:
(JSC::callGetter):
* runtime/HashMapImpl.h:
(JSC::jsMapHash):
(JSC::HashMapImpl::finishCreation):
(JSC::HashMapImpl::findBucket):
(JSC::HashMapImpl::add):
(JSC::HashMapImpl::rehash):
* runtime/InspectorInstrumentationObject.cpp:
(JSC::inspectorInstrumentationObjectLog):
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::createSubclassStructure):
* runtime/IntlCollator.cpp:
(JSC::IntlCollator::initializeCollator):
* runtime/IntlCollatorConstructor.cpp:
(JSC::constructIntlCollator):
(JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
* runtime/IntlCollatorPrototype.cpp:
(JSC::IntlCollatorFuncCompare):
(JSC::IntlCollatorPrototypeGetterCompare):
* runtime/IntlDateTimeFormat.cpp:
(JSC::toDateTimeOptionsAnyDate):
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::constructIntlDateTimeFormat):
(JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::IntlDateTimeFormatFuncFormatDateTime):
(JSC::IntlDateTimeFormatPrototypeGetterFormat):
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::initializeNumberFormat):
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::constructIntlNumberFormat):
(JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::IntlNumberFormatFuncFormatNumber):
(JSC::IntlNumberFormatPrototypeGetterFormat):
* runtime/IntlObject.cpp:
(JSC::intlBooleanOption):
(JSC::intlStringOption):
(JSC::intlNumberOption):
(JSC::canonicalizeLocaleList):
(JSC::supportedLocales):
* runtime/IntlObjectInlines.h:
(JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
* runtime/IteratorOperations.cpp:
(JSC::iteratorNext):
(JSC::iteratorStep):
(JSC::iteratorClose):
(JSC::iteratorForIterable):
* runtime/IteratorOperations.h:
(JSC::forEachInIterable):
* runtime/JSArray.cpp:
(JSC::JSArray::pop):
(JSC::JSArray::copyToArguments):
* runtime/JSArrayBufferConstructor.cpp:
(JSC::constructArrayBuffer):
* runtime/JSArrayBufferPrototype.cpp:
(JSC::arrayBufferProtoFuncSlice):
* runtime/JSArrayInlines.h:
(JSC::getLength):
(JSC::toLength):
* runtime/JSBoundFunction.cpp:
(JSC::getBoundFunctionStructure):
(JSC::JSBoundFunction::create):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive):
(JSC::JSValue::toStringSlowCase):
* runtime/JSCJSValueInlines.h:
(JSC::toPreferredPrimitiveType):
(JSC::JSValue::getPropertySlot):
(JSC::JSValue::equalSlowCaseInline):
* runtime/JSDataViewPrototype.cpp:
(JSC::getData):
(JSC::setData):
* runtime/JSFunction.cpp:
(JSC::JSFunction::setFunctionName):
* runtime/JSGenericTypedArrayView.h:
(JSC::JSGenericTypedArrayView::setIndex):
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayViewFromIterator):
(JSC::constructGenericTypedArrayViewWithArguments):
(JSC::constructGenericTypedArrayView):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::speciesConstruct):
(JSC::genericTypedArrayViewProtoFuncSet):
(JSC::genericTypedArrayViewProtoFuncCopyWithin):
(JSC::genericTypedArrayViewProtoFuncIncludes):
(JSC::genericTypedArrayViewProtoFuncIndexOf):
(JSC::genericTypedArrayViewProtoFuncJoin):
(JSC::genericTypedArrayViewProtoFuncLastIndexOf):
(JSC::genericTypedArrayViewProtoFuncSlice):
(JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
* runtime/JSGlobalObject.h:
(JSC::constructEmptyArray):
(JSC::constructArray):
(JSC::constructArrayNegativeIndexed):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncEval):
* runtime/JSModuleRecord.cpp:
(JSC::JSModuleRecord::instantiateDeclarations):
* runtime/JSONObject.cpp:
(JSC::Stringifier::stringify):
(JSC::Stringifier::toJSON):
(JSC::Stringifier::appendStringifiedValue):
(JSC::Stringifier::Holder::appendNextProperty):
(JSC::Walker::walk):
(JSC::JSONProtoFuncParse):
* runtime/JSObject.cpp:
(JSC::ordinarySetSlow):
(JSC::JSObject::setPrototypeWithCycleCheck):
(JSC::callToPrimitiveFunction):
(JSC::JSObject::defaultHasInstance):
(JSC::JSObject::getPropertyNames):
(JSC::JSObject::toNumber):
(JSC::JSObject::toString):
(JSC::JSObject::defineOwnNonIndexProperty):
(JSC::JSObject::getGenericPropertyNames):
(JSC::JSObject::getMethod):
* runtime/JSObjectInlines.h:
(JSC::createListFromArrayLike):
(JSC::JSObject::getPropertySlot):
(JSC::JSObject::getNonIndexPropertySlot):
* runtime/JSPromiseConstructor.cpp:
(JSC::constructPromise):
* runtime/JSPromiseDeferred.cpp:
(JSC::JSPromiseDeferred::create):
* runtime/JSPropertyNameEnumerator.h:
(JSC::propertyNameEnumerator):
* runtime/JSPropertyNameIterator.cpp:
(JSC::JSPropertyNameIterator::create):
* runtime/JSScope.cpp:
(JSC::isUnscopable):
* runtime/JSString.cpp:
(JSC::JSString::equalSlowCase):
* runtime/JSStringJoiner.cpp:
(JSC::JSStringJoiner::join):
* runtime/LiteralParser.cpp:
(JSC::LiteralParser<CharType>::parse):
* runtime/MapBase.h:
(JSC::MapBase::finishCreation):
* runtime/MapConstructor.cpp:
(JSC::constructMap):
* runtime/MathObject.cpp:
(JSC::mathProtoFuncClz32):
(JSC::mathProtoFuncHypot):
(JSC::mathProtoFuncIMul):
* runtime/ModuleLoaderPrototype.cpp:
(JSC::moduleLoaderPrototypeParseModule):
(JSC::moduleLoaderPrototypeRequestedModules):
(JSC::moduleLoaderPrototypeModuleDeclarationInstantiation):
* runtime/NativeErrorConstructor.cpp:
(JSC::Interpreter::constructWithNativeErrorConstructor):
* runtime/NumberConstructor.cpp:
(JSC::constructWithNumberConstructor):
* runtime/ObjectConstructor.cpp:
(JSC::constructObject):
(JSC::objectConstructorGetPrototypeOf):
(JSC::objectConstructorSetPrototypeOf):
(JSC::objectConstructorGetOwnPropertyDescriptor):
(JSC::objectConstructorGetOwnPropertyDescriptors):
(JSC::objectConstructorGetOwnPropertyNames):
(JSC::objectConstructorGetOwnPropertySymbols):
(JSC::objectConstructorKeys):
(JSC::ownEnumerablePropertyKeys):
(JSC::toPropertyDescriptor):
(JSC::objectConstructorDefineProperty):
(JSC::defineProperties):
(JSC::objectConstructorSeal):
(JSC::objectConstructorFreeze):
(JSC::objectConstructorIsSealed):
(JSC::objectConstructorIsFrozen):
(JSC::objectConstructorIsExtensible):
(JSC::ownPropertyKeys):
* runtime/ObjectConstructor.h:
(JSC::constructObjectFromPropertyDescriptor):
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncHasOwnProperty):
(JSC::objectProtoFuncIsPrototypeOf):
(JSC::objectProtoFuncDefineGetter):
(JSC::objectProtoFuncDefineSetter):
(JSC::objectProtoFuncLookupGetter):
(JSC::objectProtoFuncLookupSetter):
(JSC::objectProtoFuncPropertyIsEnumerable):
(JSC::objectProtoFuncToLocaleString):
(JSC::objectProtoFuncToString):
* runtime/Operations.cpp:
(JSC::jsAddSlowCase):
* runtime/PropertyDescriptor.cpp:
(JSC::PropertyDescriptor::slowGetterSetter):
* runtime/ProxyConstructor.cpp:
(JSC::makeRevocableProxy):
* runtime/ProxyObject.cpp:
(JSC::performProxyGet):
(JSC::ProxyObject::performGet):
(JSC::ProxyObject::performInternalMethodGetOwnProperty):
(JSC::ProxyObject::performHasProperty):
(JSC::ProxyObject::performPut):
(JSC::ProxyObject::putByIndexCommon):
(JSC::performProxyCall):
(JSC::performProxyConstruct):
(JSC::ProxyObject::performDelete):
(JSC::ProxyObject::performPreventExtensions):
(JSC::ProxyObject::performIsExtensible):
(JSC::ProxyObject::performDefineOwnProperty):
(JSC::ProxyObject::performGetOwnPropertyNames):
(JSC::ProxyObject::performSetPrototype):
(JSC::ProxyObject::performGetPrototype):
* runtime/ReflectObject.cpp:
(JSC::reflectObjectConstruct):
(JSC::reflectObjectDefineProperty):
(JSC::reflectObjectGet):
(JSC::reflectObjectGetOwnPropertyDescriptor):
(JSC::reflectObjectIsExtensible):
(JSC::reflectObjectPreventExtensions):
(JSC::reflectObjectSet):
(JSC::reflectObjectSetPrototypeOf):
* runtime/RegExpConstructor.cpp:
(JSC::toFlags):
(JSC::regExpCreate):
(JSC::constructRegExp):
* runtime/RegExpConstructor.h:
(JSC::isRegExp):
* runtime/RegExpObject.cpp:
(JSC::collectMatches):
(JSC::RegExpObject::matchGlobal):
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoFuncCompile):
(JSC::flagsString):
(JSC::regExpProtoFuncToString):
(JSC::regExpProtoGetterFlags):
(JSC::regExpProtoFuncSearchFast):
(JSC::regExpProtoFuncSplitFast):
* runtime/SetConstructor.cpp:
(JSC::constructSet):
* runtime/StringConstructor.cpp:
(JSC::stringFromCodePoint):
(JSC::constructWithStringConstructor):
* runtime/StringObject.cpp:
(JSC::StringObject::defineOwnProperty):
* runtime/StringPrototype.cpp:
(JSC::replaceUsingRegExpSearch):
(JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
(JSC::replaceUsingStringSearch):
(JSC::replace):
(JSC::stringProtoFuncReplaceUsingRegExp):
(JSC::stringProtoFuncReplaceUsingStringSearch):
(JSC::stringProtoFuncCodePointAt):
(JSC::stringProtoFuncSlice):
(JSC::stringProtoFuncSplitFast):
(JSC::stringProtoFuncSubstr):
(JSC::stringProtoFuncSubstring):
(JSC::stringProtoFuncLocaleCompare):
(JSC::toLocaleCase):
(JSC::stringProtoFuncBig):
(JSC::stringProtoFuncSmall):
(JSC::stringProtoFuncBlink):
(JSC::stringProtoFuncBold):
(JSC::stringProtoFuncFixed):
(JSC::stringProtoFuncItalics):
(JSC::stringProtoFuncStrike):
(JSC::stringProtoFuncSub):
(JSC::stringProtoFuncSup):
(JSC::stringProtoFuncFontcolor):
(JSC::stringProtoFuncFontsize):
(JSC::stringProtoFuncAnchor):
(JSC::stringProtoFuncLink):
(JSC::trimString):
(JSC::stringProtoFuncStartsWith):
(JSC::stringProtoFuncEndsWith):
(JSC::stringIncludesImpl):
(JSC::stringProtoFuncIncludes):
(JSC::builtinStringIncludesInternal):
(JSC::stringProtoFuncNormalize):
* runtime/SymbolConstructor.cpp:
(JSC::symbolConstructorFor):
* runtime/TemplateRegistry.cpp:
(JSC::TemplateRegistry::getTemplateObject):
* runtime/WeakMapConstructor.cpp:
(JSC::constructWeakMap):
* runtime/WeakSetConstructor.cpp:
(JSC::constructWeakSet):
* tools/JSDollarVMPrototype.cpp:
(JSC::functionPrint):
2016-09-26 Don Olmstead <don.olmstead@am.sony.com>
[JSC] Allow fixedExecutableMemoryPoolSize to be set during build
https://bugs.webkit.org/show_bug.cgi?id=162514
Reviewed by Mark Lam.
* jit/ExecutableAllocator.h:
== Rolled over to ChangeLog-2016-09-26 ==