617d9e5fcf3c43bf2b4019ea86a0a10299ffeacf
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2019-06-22  Robin Morisset  <rmorisset@apple.com> and Yusuke Suzuki  <ysuzuki@apple.com>
2
3         All prototypes should call didBecomePrototype()
4         https://bugs.webkit.org/show_bug.cgi?id=196315
5
6         Reviewed by Saam Barati.
7
8         Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor.
9
10         I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't
11         create structures with invalid prototypes.
12         It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation().
13         Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype.
14
15         * runtime/BigIntPrototype.cpp:
16         (JSC::BigIntPrototype::finishCreation):
17         * runtime/BooleanPrototype.cpp:
18         (JSC::BooleanPrototype::finishCreation):
19         * runtime/DatePrototype.cpp:
20         (JSC::DatePrototype::finishCreation):
21         * runtime/ErrorConstructor.cpp:
22         (JSC::ErrorConstructor::finishCreation):
23         * runtime/ErrorPrototype.cpp:
24         (JSC::ErrorPrototype::finishCreation):
25         * runtime/FunctionConstructor.cpp:
26         (JSC::FunctionConstructor::finishCreation):
27         * runtime/FunctionPrototype.cpp:
28         (JSC::FunctionPrototype::finishCreation):
29         * runtime/IntlCollatorPrototype.cpp:
30         (JSC::IntlCollatorPrototype::finishCreation):
31         * runtime/IntlDateTimeFormatPrototype.cpp:
32         (JSC::IntlDateTimeFormatPrototype::finishCreation):
33         * runtime/IntlNumberFormatPrototype.cpp:
34         (JSC::IntlNumberFormatPrototype::finishCreation):
35         * runtime/IntlPluralRulesPrototype.cpp:
36         (JSC::IntlPluralRulesPrototype::finishCreation):
37         * runtime/JSArrayBufferPrototype.cpp:
38         (JSC::JSArrayBufferPrototype::finishCreation):
39         * runtime/JSDataViewPrototype.cpp:
40         (JSC::JSDataViewPrototype::finishCreation):
41         * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
42         (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
43         * runtime/JSGlobalObject.cpp:
44         (JSC::createConsoleProperty):
45         * runtime/JSPromisePrototype.cpp:
46         (JSC::JSPromisePrototype::finishCreation):
47         * runtime/JSTypedArrayViewConstructor.cpp:
48         (JSC::JSTypedArrayViewConstructor::finishCreation):
49         * runtime/JSTypedArrayViewPrototype.cpp:
50         (JSC::JSTypedArrayViewPrototype::finishCreation):
51         * runtime/NumberPrototype.cpp:
52         (JSC::NumberPrototype::finishCreation):
53         * runtime/RegExpPrototype.cpp:
54         (JSC::RegExpPrototype::finishCreation):
55         * runtime/StringPrototype.cpp:
56         (JSC::StringPrototype::finishCreation):
57         * runtime/Structure.cpp:
58         (JSC::Structure::isValidPrototype):
59         (JSC::Structure::changePrototypeTransition):
60         * runtime/Structure.h:
61         * runtime/StructureInlines.h:
62         (JSC::Structure::setPrototypeWithoutTransition):
63         * runtime/SymbolPrototype.cpp:
64         (JSC::SymbolPrototype::finishCreation):
65         * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
66         (JSC::WebAssemblyCompileErrorPrototype::finishCreation):
67         * wasm/js/WebAssemblyInstancePrototype.cpp:
68         (JSC::WebAssemblyInstancePrototype::finishCreation):
69         * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
70         (JSC::WebAssemblyLinkErrorPrototype::finishCreation):
71         * wasm/js/WebAssemblyMemoryPrototype.cpp:
72         (JSC::WebAssemblyMemoryPrototype::finishCreation):
73         * wasm/js/WebAssemblyModulePrototype.cpp:
74         (JSC::WebAssemblyModulePrototype::finishCreation):
75         * wasm/js/WebAssemblyPrototype.cpp:
76         (JSC::WebAssemblyPrototype::finishCreation):
77         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
78         (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
79         * wasm/js/WebAssemblyTablePrototype.cpp:
80         (JSC::WebAssemblyTablePrototype::finishCreation):
81
82 2019-06-22  Yusuke Suzuki  <ysuzuki@apple.com>
83
84         [JSC] Strict, Sloppy and Arrow functions should have different classInfo
85         https://bugs.webkit.org/show_bug.cgi?id=197631
86
87         Reviewed by Saam Barati.
88
89         If a constructor inherits a builtin class, it creates a Structure which is subclassing the builtin class.
90         This is done by using InternalFunction::createSubclassStructure. But to accelerate the common cases, we
91         cache the created structure in InternalFunctionAllocationProfile. Whether the cache is valid is checked
92         by comparing classInfo of the cached structure and the given base structure. This implicitly assume that
93         each builtin class's InternalFunction creates an instance based on one structure.
94
95         However, Function constructor is an exception: Function constructor creates an instance which has different
96         structures based on a parameter. If a strict code is given (e.g. "'use strict'"), it creates a function
97         instance with strict function structure.
98
99         As a result, InternalFunctionAllocationProfile incorrectly caches the structure. Consider the following code.
100
101             class A extends Function { };
102             let a = new A("'use strict'");
103             let b = new A("");
104
105         While `a` and `b` should have different structures, `A` caches the structure for `a`, and reuse it even the given
106         code is not a strict code. This is problematic: We are separating structures of strict, sloppy, and arrow functions
107         because they have different properties. However, in the above case, a and b have the same structure while they have
108         different properties. So it causes incorrect structure-based caching in JSC. One of the example is HasOwnPropertyCache.
109
110         In this patch, we introduce JSStrictFunction, JSSloppyFunction, and JSArrowFunction classes and classInfos. This design
111         works well and already partially accepted for JSGeneratorFunction, JSAsyncGeneratorFunction, and JSAsyncFunction. Each
112         structure now has a different classInfo so that InternalFunctionAllocationProfile correctly caches and invalidates the
113         cached one based on the classInfo. Since we already have different structures for these instances, and DFG and FTL
114         optimizations are based on JSFunctionType (not classInfo), introducing these three classInfo do not break the optimization.
115
116         Note that structures on ArrayConstructor does not cause the same problem. It only uses Undecided indexing typed array
117         structure in InternalFunctionAllocationProfile, and once haveABadTime happens, it clears InternalFunctionAllocationProfile.
118
119         * runtime/JSAsyncFunction.h: This subspaceFor is not necessary since it is defined in JSFunction. And we already ensure that
120         sizeof(JSAsyncFunction) == sizeof(JSFunction).
121         * runtime/JSAsyncGeneratorFunction.cpp:
122         * runtime/JSAsyncGeneratorFunction.h: Ditto.
123         * runtime/JSFunction.cpp:
124         * runtime/JSFunction.h:
125         * runtime/JSGeneratorFunction.h: Ditto.
126         * runtime/JSGlobalObject.cpp:
127         (JSC::JSGlobalObject::init):
128
129 2019-06-22  Yusuke Suzuki  <ysuzuki@apple.com>
130
131         [JSC] ClassExpr should not store result in the middle of evaluation
132         https://bugs.webkit.org/show_bug.cgi?id=199106
133
134         Reviewed by Tadeu Zagallo.
135
136         Let's consider the case,
137
138             let a = class A {
139                 static get[a=0x12345678]() {
140                 }
141             };
142
143         When evaluating `class A` expression, we should not use the local register for `let a`
144         until we finally store it to that register. Otherwise, `a=0x12345678` will override it.
145         Out BytecodeGenerator does that this by using tempDestination and finalDestination, but
146         we did not do that in ClassExprNode.
147
148         This patch leverages tempDestination and finalDestination to store `class A` result finally,
149         while we attempt to reduce mov.
150
151         * bytecompiler/NodesCodegen.cpp:
152         (JSC::ClassExprNode::emitBytecode):
153
154 2019-06-21  Sihui Liu  <sihui_liu@apple.com>
155
156         openDatabase should return an empty object when WebSQL is disabled
157         https://bugs.webkit.org/show_bug.cgi?id=198805
158
159         Reviewed by Geoffrey Garen.
160
161         * runtime/JSFunction.cpp:
162         (JSC::JSFunction::createFunctionThatMasqueradesAsUndefined):
163         * runtime/JSFunction.h:
164
165 2019-06-21  Alexey Shvayka  <shvaikalesh@gmail.com>
166
167         Remove extra check in RegExp @matchSlow
168         https://bugs.webkit.org/show_bug.cgi?id=198846
169
170         Reviewed by Joseph Pecoraro.
171
172         Type of RegExp `exec` result is already asserted in @regExpExec.
173
174         * builtins/RegExpPrototype.js:
175         (globalPrivate.matchSlow): Remove isObject check.
176
177 2019-06-20  Justin Michaud  <justin_michaud@apple.com>
178
179         [WASM-References] Add extra tests for Wasm references + fix element parsing and subtyping bugs
180         https://bugs.webkit.org/show_bug.cgi?id=199044
181
182         Reviewed by Saam Barati.
183
184         Fix parsing table indices from the element section. The byte that we previously read as the table index actually tells us how to parse the table index.
185         Fix some areas where we got the isSubtype check wrong, causing funcrefs to not be considred anyrefs.
186
187         * wasm/WasmAirIRGenerator.cpp:
188         (JSC::Wasm::AirIRGenerator::unify):
189         * wasm/WasmSectionParser.cpp:
190         (JSC::Wasm::SectionParser::parseElement):
191         * wasm/WasmValidate.cpp:
192         (JSC::Wasm::Validate::unify):
193
194 2019-06-18  Darin Adler  <darin@apple.com>
195
196         Tidy up the remaining bits of the AtomicString to AtomString rename
197         https://bugs.webkit.org/show_bug.cgi?id=198990
198
199         Reviewed by Michael Catanzaro.
200
201         * dfg/DFGSpeculativeJIT.cpp:
202         (JSC::DFG::SpeculativeJIT::speculateStringIdentAndLoadStorage): Use flagIsAtom.
203         * dfg/DFGSpeculativeJIT32_64.cpp:
204         (JSC::DFG::SpeculativeJIT::compile): Ditto.
205         * dfg/DFGSpeculativeJIT64.cpp:
206         (JSC::DFG::SpeculativeJIT::compile): Ditto.
207         * ftl/FTLLowerDFGToB3.cpp:
208         (JSC::FTL::DFG::LowerDFGToB3::compileHasOwnProperty): Ditto.
209         (JSC::FTL::DFG::LowerDFGToB3::speculateStringIdent): Ditto.
210
211 2019-06-19  Alexey Shvayka  <shvaikalesh@gmail.com>
212
213         Optimize `resolve` method lookup in Promise static methods
214         https://bugs.webkit.org/show_bug.cgi?id=198864
215
216         Reviewed by Yusuke Suzuki.
217
218         Lookup `resolve` method only once in Promise.{all,allSettled,race}.
219         (https://github.com/tc39/ecma262/pull/1506)
220
221         Already implemented in V8.
222
223         * builtins/PromiseConstructor.js:
224
225 2019-06-19  Tadeu Zagallo  <tzagallo@apple.com>
226
227         Some of the ASSERTs in CachedTypes.cpp should be RELEASE_ASSERTs
228         https://bugs.webkit.org/show_bug.cgi?id=199030
229
230         Reviewed by Mark Lam.
231
232         These assertions represent strong assumptions that the cache makes so
233         it's not safe to keep executing if they fail.
234
235         * runtime/CachedTypes.cpp:
236         (JSC::Encoder::malloc):
237         (JSC::Encoder::Page::alignEnd):
238         (JSC::Decoder::ptrForOffsetFromBase):
239         (JSC::Decoder::handleForEnvironment const):
240         (JSC::Decoder::setHandleForEnvironment):
241         (JSC::CachedPtr::get const):
242         (JSC::CachedOptional::encode):
243         (JSC::CachedOptional::decodeAsPtr const): Deleted.
244
245 2019-06-19  Adrian Perez de Castro  <aperez@igalia.com>
246
247         [WPE][GTK] Fix build with unified sources disabled
248         https://bugs.webkit.org/show_bug.cgi?id=198752
249
250         Reviewed by Michael Catanzaro.
251
252         * runtime/WeakObjectRefConstructor.h: Add missing inclusion of InternalFunction.h
253         and forward declaration of WeakObjectRefPrototype.
254         * wasm/js/WebAssemblyFunction.cpp: Add missing inclusion of JSWebAssemblyHelpers.h
255
256 2019-06-19  Justin Michaud  <justin_michaud@apple.com>
257
258         [WASM-References] Rename anyfunc to funcref
259         https://bugs.webkit.org/show_bug.cgi?id=198983
260
261         Reviewed by Yusuke Suzuki.
262
263         Anyfunc should become funcref since it was renamed in the spec. We should also support the string 'anyfunc' in the table constructor since this is 
264         the only non-binary-format place where it is exposed to users.
265
266         * wasm/WasmAirIRGenerator.cpp:
267         (JSC::Wasm::AirIRGenerator::gFuncref):
268         (JSC::Wasm::AirIRGenerator::tmpForType):
269         (JSC::Wasm::AirIRGenerator::emitCCall):
270         (JSC::Wasm::AirIRGenerator::moveOpForValueType):
271         (JSC::Wasm::AirIRGenerator::AirIRGenerator):
272         (JSC::Wasm::AirIRGenerator::addLocal):
273         (JSC::Wasm::AirIRGenerator::addConstant):
274         (JSC::Wasm::AirIRGenerator::addRefFunc):
275         (JSC::Wasm::AirIRGenerator::addReturn):
276         (JSC::Wasm::AirIRGenerator::gAnyfunc): Deleted.
277         * wasm/WasmCallingConvention.h:
278         (JSC::Wasm::CallingConventionAir::marshallArgument const):
279         (JSC::Wasm::CallingConventionAir::setupCall const):
280         * wasm/WasmExceptionType.h:
281         * wasm/WasmFormat.h:
282         (JSC::Wasm::isValueType):
283         (JSC::Wasm::isSubtype):
284         (JSC::Wasm::TableInformation::wasmType const):
285         * wasm/WasmFunctionParser.h:
286         (JSC::Wasm::FunctionParser<Context>::parseExpression):
287         * wasm/WasmSectionParser.cpp:
288         (JSC::Wasm::SectionParser::parseTableHelper):
289         (JSC::Wasm::SectionParser::parseElement):
290         (JSC::Wasm::SectionParser::parseInitExpr):
291         * wasm/WasmValidate.cpp:
292         (JSC::Wasm::Validate::addRefFunc):
293         * wasm/js/JSToWasm.cpp:
294         (JSC::Wasm::createJSToWasmWrapper):
295         * wasm/js/WasmToJS.cpp:
296         (JSC::Wasm::wasmToJS):
297         * wasm/js/WebAssemblyFunction.cpp:
298         (JSC::callWebAssemblyFunction):
299         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
300         * wasm/js/WebAssemblyModuleRecord.cpp:
301         (JSC::WebAssemblyModuleRecord::link):
302         * wasm/js/WebAssemblyTableConstructor.cpp:
303         (JSC::constructJSWebAssemblyTable):
304         * wasm/wasm.json:
305
306 2019-06-19  Fujii Hironori  <Hironori.Fujii@sony.com>
307
308         [CMake][Win] CombinedDomains.json is generated twice in JavaScriptCore_CopyPrivateHeaders and JavaScriptCore projects
309         https://bugs.webkit.org/show_bug.cgi?id=198853
310
311         Reviewed by Don Olmstead.
312
313         JavaScriptCore_CopyPrivateHeaders target needs to have a direct or
314         indirect dependency of JavaScriptCore target for CMake Visual
315         Studio generator to eliminate duplicated custom commands.
316
317         * CMakeLists.txt: Added JavaScriptCore as a dependency of JavaScriptCore_CopyPrivateHeaders.
318
319 2019-06-18  Yusuke Suzuki  <ysuzuki@apple.com>
320
321         [JSC] JSLock should be WebThread aware
322         https://bugs.webkit.org/show_bug.cgi?id=198911
323
324         Reviewed by Geoffrey Garen.
325
326         Since WebKitLegacy content rendering is done in WebThread instead of the main thread in iOS, user of WebKitLegacy (e.g. UIWebView) needs
327         to grab the WebThread lock (which is a recursive lock) in the main thread when touching the WebKitLegacy content.
328         But, WebKitLegacy can expose JSContext for the web view. And we can interact with the JS content through JavaScriptCore APIs. However,
329         since WebThread is a concept in WebCore, JavaScriptCore APIs do not grab the WebThread lock. As a result, WebKitLegacy web content can be
330         modified from the main thread without grabbing the WebThread lock through JavaScriptCore APIs.
331
332         This patch makes JSC aware of WebThread: JSLock grabs the WebThread lock before grabbing JS's lock. While this seems layering violation,
333         we already have many USE(WEB_THREAD) and WebThread aware code in WTF. Eventually, we should move WebThread code from WebCore to WTF since
334         JSC and WTF need to be aware of WebThread. But, for now, we just use the function pointer exposed by WebCore.
335
336         Since both JSLock and the WebThread lock are recursive locks, nested locking is totally OK. The possible problem is the order of locking.
337         We ensure that we always grab locks in (1) the WebThread lock and (2) JSLock order.
338
339         In JSLock, we take the WebThread lock, but we do not unlock it. This is how we use the WebThread lock: the WebThread lock is released
340         automatically when RunLoop finishes the current cycle, and in WebKitLegacy, we do not call unlocking function of the WebThread lock except
341         for some edge cases.
342
343         * API/JSVirtualMachine.mm:
344         (-[JSVirtualMachine isWebThreadAware]):
345         * API/JSVirtualMachineInternal.h:
346         * runtime/JSLock.cpp:
347         (JSC::JSLockHolder::JSLockHolder):
348         (JSC::JSLock::lock):
349         (JSC::JSLockHolder::init): Deleted.
350         * runtime/JSLock.h:
351         (JSC::JSLock::makeWebThreadAware):
352         (JSC::JSLock::isWebThreadAware const):
353
354 2019-06-18  Justin Michaud  <justin_michaud@apple.com>
355
356         [WASM-References] Add support for Table.size, grow and fill instructions
357         https://bugs.webkit.org/show_bug.cgi?id=198761
358
359         Reviewed by Yusuke Suzuki.
360
361         Add support for Table.size, grow and fill instructions. This also required
362         adding support for two-byte opcodes to the ops generator.
363
364         * wasm/WasmAirIRGenerator.cpp:
365         (JSC::Wasm::AirIRGenerator::gAnyref):
366         (JSC::Wasm::AirIRGenerator::tmpForType):
367         (JSC::Wasm::AirIRGenerator::addTableSize):
368         (JSC::Wasm::AirIRGenerator::addTableGrow):
369         (JSC::Wasm::AirIRGenerator::addTableFill):
370         * wasm/WasmB3IRGenerator.cpp:
371         (JSC::Wasm::B3IRGenerator::addTableSize):
372         (JSC::Wasm::B3IRGenerator::addTableGrow):
373         (JSC::Wasm::B3IRGenerator::addTableFill):
374         * wasm/WasmExceptionType.h:
375         * wasm/WasmFormat.h:
376         (JSC::Wasm::TableInformation::wasmType const):
377         * wasm/WasmFunctionParser.h:
378         (JSC::Wasm::FunctionParser<Context>::parseExpression):
379         (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
380         * wasm/WasmInstance.cpp:
381         (JSC::Wasm::doWasmTableGrow):
382         (JSC::Wasm::doWasmTableFill):
383         * wasm/WasmInstance.h:
384         * wasm/WasmTable.cpp:
385         (JSC::Wasm::Table::grow):
386         * wasm/WasmValidate.cpp:
387         (JSC::Wasm::Validate::addTableSize):
388         (JSC::Wasm::Validate::addTableGrow):
389         (JSC::Wasm::Validate::addTableFill):
390         * wasm/generateWasmOpsHeader.py:
391         (opcodeMacroizer):
392         (ExtTableOpType):
393         * wasm/wasm.json:
394
395 2019-06-18  Keith Miller  <keith_miller@apple.com>
396
397         Unreviewed, fix signature of currentWeakRefVersion to return an uintptr_t.
398
399         * runtime/VM.h:
400         (JSC::VM::currentWeakRefVersion const):
401
402 2019-06-18  Justin Michaud  <justin_michaud@apple.com>
403
404         [WASM-References] Add support for multiple tables
405         https://bugs.webkit.org/show_bug.cgi?id=198760
406
407         Reviewed by Saam Barati.
408
409         Support multiple wasm tables. We turn tableInformation into a tables array, and update all of the
410         existing users to give a table index. The array of Tables in Wasm::Instance is hung off the tail
411         to make it easier to use from jit code. 
412
413         * wasm/WasmAirIRGenerator.cpp:
414         (JSC::Wasm::AirIRGenerator::AirIRGenerator):
415         (JSC::Wasm::AirIRGenerator::addTableGet):
416         (JSC::Wasm::AirIRGenerator::addTableSet):
417         (JSC::Wasm::AirIRGenerator::addCallIndirect):
418         * wasm/WasmB3IRGenerator.cpp:
419         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
420         (JSC::Wasm::B3IRGenerator::addTableGet):
421         (JSC::Wasm::B3IRGenerator::addTableSet):
422         (JSC::Wasm::B3IRGenerator::addCallIndirect):
423         * wasm/WasmExceptionType.h:
424         * wasm/WasmFormat.h:
425         (JSC::Wasm::Element::Element):
426         * wasm/WasmFunctionParser.h:
427         (JSC::Wasm::FunctionParser<Context>::parseExpression):
428         (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
429         * wasm/WasmInstance.cpp:
430         (JSC::Wasm::Instance::Instance):
431         (JSC::Wasm::Instance::create):
432         (JSC::Wasm::Instance::extraMemoryAllocated const):
433         (JSC::Wasm::Instance::table):
434         (JSC::Wasm::Instance::setTable):
435         * wasm/WasmInstance.h:
436         (JSC::Wasm::Instance::updateCachedMemory):
437         (JSC::Wasm::Instance::offsetOfGlobals):
438         (JSC::Wasm::Instance::offsetOfTablePtr):
439         (JSC::Wasm::Instance::allocationSize):
440         (JSC::Wasm::Instance::table): Deleted.
441         (JSC::Wasm::Instance::setTable): Deleted.
442         (JSC::Wasm::Instance::offsetOfTable): Deleted.
443         * wasm/WasmModuleInformation.h:
444         (JSC::Wasm::ModuleInformation::tableCount const):
445         * wasm/WasmSectionParser.cpp:
446         (JSC::Wasm::SectionParser::parseImport):
447         (JSC::Wasm::SectionParser::parseTableHelper):
448         (JSC::Wasm::SectionParser::parseTable):
449         (JSC::Wasm::SectionParser::parseElement):
450         * wasm/WasmTable.h:
451         (JSC::Wasm::Table::owner const):
452         * wasm/WasmValidate.cpp:
453         (JSC::Wasm::Validate::addTableGet):
454         (JSC::Wasm::Validate::addTableSet):
455         (JSC::Wasm::Validate::addCallIndirect):
456         * wasm/js/JSWebAssemblyInstance.cpp:
457         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
458         (JSC::JSWebAssemblyInstance::visitChildren):
459         * wasm/js/JSWebAssemblyInstance.h:
460         * wasm/js/WebAssemblyModuleRecord.cpp:
461         (JSC::WebAssemblyModuleRecord::link):
462         (JSC::WebAssemblyModuleRecord::evaluate):
463         * wasm/wasm.json:
464
465 2019-06-18  Alexey Shvayka  <shvaikalesh@gmail.com>
466
467         [ESNExt] String.prototype.matchAll
468         https://bugs.webkit.org/show_bug.cgi?id=186694
469
470         Reviewed by Yusuke Suzuki.
471
472         Implement String.prototype.matchAll.
473         (https://tc39.es/ecma262/#sec-string.prototype.matchall)
474
475         Also rename @globalPrivate @constructor functions and C++ variables holding them.
476
477         Shipping in Chrome since version 73.
478         Shipping in Firefox since version 67.
479
480         * CMakeLists.txt:
481         * DerivedSources-input.xcfilelist:
482         * DerivedSources.make:
483         * JavaScriptCore.xcodeproj/project.pbxproj:
484         * Scripts/wkbuiltins/builtins_generate_combined_header.py:
485         (get_var_name):
486         (generate_section_for_global_private_code_name_macro):
487         * Sources.txt:
488         * builtins/ArrayPrototype.js:
489         (globalPrivate.ArrayIterator):
490         (values):
491         (keys):
492         (entries):
493         (globalPrivate.createArrayIterator): Deleted.
494         * builtins/AsyncFromSyncIteratorPrototype.js:
495         (globalPrivate.createAsyncFromSyncIterator):
496         (globalPrivate.AsyncFromSyncIterator):
497         (globalPrivate.AsyncFromSyncIteratorConstructor): Deleted.
498         * builtins/BuiltinNames.h:
499         * builtins/MapPrototype.js:
500         (globalPrivate.MapIterator):
501         (values):
502         (keys):
503         (entries):
504         (globalPrivate.createMapIterator): Deleted.
505         * builtins/RegExpPrototype.js:
506         (globalPrivate.RegExpStringIterator):
507         (overriddenName.string_appeared_here.matchAll):
508         * builtins/RegExpStringIteratorPrototype.js: Added.
509         (next):
510         * builtins/SetPrototype.js:
511         (globalPrivate.SetIterator):
512         (values):
513         (entries):
514         (globalPrivate.createSetIterator): Deleted.
515         * builtins/StringPrototype.js:
516         (matchAll):
517         * builtins/TypedArrayPrototype.js:
518         (values):
519         (keys):
520         (entries):
521         * runtime/CommonIdentifiers.h:
522         * runtime/JSGlobalObject.cpp:
523         (JSC::JSGlobalObject::init):
524         * runtime/RegExpPrototype.cpp:
525         (JSC::RegExpPrototype::finishCreation):
526         * runtime/RegExpStringIteratorPrototype.cpp: Added.
527         (JSC::RegExpStringIteratorPrototype::finishCreation):
528         * runtime/RegExpStringIteratorPrototype.h: Added.
529         * runtime/StringPrototype.cpp:
530
531 2019-06-18  Keith Miller  <keith_miller@apple.com>
532
533         Add support for WeakRef
534         https://bugs.webkit.org/show_bug.cgi?id=198710
535
536         Reviewed by Yusuke Suzuki.
537
538         Add support for WeakRefs which are now at stage 3
539         (https://tc39.es/proposal-weakrefs). This patch doesn't add
540         support for FinalizationGroups, which I'll add in another patch.
541
542         Some other things of interest. Per the spec, we cannot collect a
543         weak refs target unless it has not been dereffed (or created) in
544         the current microtask turn. i.e. WeakRefs are only allowed to be
545         collected at the end of a drain of the Microtask queue. My
546         understanding for this behavior is to reduce implementation
547         dependence on specific GC behavior in a given browser.
548
549         We track if a WeakRef is retaining its target by using a version
550         number on each WeakRef as well as on the VM. Whenever a WeakRef is
551         derefed we update its version number to match the VM's then
552         WriteBarrier ourselves. During marking if the VM and the WeakRef
553         have the same version number, the target is visited.
554
555         * JavaScriptCore.xcodeproj/project.pbxproj:
556         * Sources.txt:
557         * heap/Heap.cpp:
558         (JSC::Heap::finalizeUnconditionalFinalizers):
559         * jsc.cpp:
560         (GlobalObject::finishCreation):
561         (functionReleaseWeakRefs):
562         * runtime/CommonIdentifiers.h:
563         * runtime/JSGlobalObject.cpp:
564         * runtime/JSGlobalObject.h:
565         * runtime/JSWeakObjectRef.cpp: Added.
566         (JSC::JSWeakObjectRef::finishCreation):
567         (JSC::JSWeakObjectRef::visitChildren):
568         (JSC::JSWeakObjectRef::finalizeUnconditionally):
569         (JSC::JSWeakObjectRef::toStringName):
570         * runtime/JSWeakObjectRef.h: Added.
571         * runtime/VM.cpp:
572         (JSC::VM::drainMicrotasks):
573         * runtime/VM.h:
574         (JSC::VM::setOnEachMicrotaskTick):
575         (JSC::VM::finalizeSynchronousJSExecution):
576         (JSC::VM::currentWeakRefVersion const):
577         * runtime/WeakObjectRefConstructor.cpp: Added.
578         (JSC::WeakObjectRefConstructor::finishCreation):
579         (JSC::WeakObjectRefConstructor::WeakObjectRefConstructor):
580         (JSC::callWeakRef):
581         (JSC::constructWeakRef):
582         * runtime/WeakObjectRefConstructor.h: Added.
583         (JSC::WeakObjectRefConstructor::create):
584         (JSC::WeakObjectRefConstructor::createStructure):
585         * runtime/WeakObjectRefPrototype.cpp: Added.
586         (JSC::WeakObjectRefPrototype::finishCreation):
587         (JSC::getWeakRef):
588         (JSC::protoFuncWeakRefDeref):
589         * runtime/WeakObjectRefPrototype.h: Added.
590
591 2019-06-18  Tadeu Zagallo  <tzagallo@apple.com>
592
593         Add missing mutator fence in compileNewFunction
594         https://bugs.webkit.org/show_bug.cgi?id=198849
595         <rdar://problem/51733890>
596
597         Reviewed by Saam Barati.
598
599         Follow-up after r246553. Saam pointed out that we still need a mutator
600         fence before allocating the FunctionRareData, since the allocation
601         might trigger a slow path call.
602
603         * dfg/DFGSpeculativeJIT.cpp:
604         (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
605         * ftl/FTLLowerDFGToB3.cpp:
606         (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
607
608 2019-06-18  Tadeu Zagallo  <tzagallo@apple.com>
609
610         DFG code should not reify the names of builtin functions with private names
611         https://bugs.webkit.org/show_bug.cgi?id=198849
612         <rdar://problem/51733890>
613
614         Reviewed by Filip Pizlo.
615
616         Builtin functions that have a private name call setHasReifiedName from finishCreation.
617         When compiled with DFG and FTL, that does not get called and the function ends up reifying
618         its name. In order to fix that, we initialize FunctionRareData and set m_hasReifiedName to
619         true from compileNewFunction in both DFG and FTL.
620
621         * bytecode/InternalFunctionAllocationProfile.h:
622         (JSC::InternalFunctionAllocationProfile::offsetOfStructure):
623         * bytecode/ObjectAllocationProfile.h:
624         (JSC::ObjectAllocationProfileWithPrototype::offsetOfPrototype):
625         * bytecode/UnlinkedFunctionExecutable.h:
626         * dfg/DFGSpeculativeJIT.cpp:
627         (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
628         * ftl/FTLAbstractHeapRepository.h:
629         * ftl/FTLLowerDFGToB3.cpp:
630         (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
631         * runtime/FunctionExecutable.h:
632         * runtime/FunctionRareData.h:
633         * runtime/JSFunction.cpp:
634         (JSC::JSFunction::finishCreation):
635         * runtime/JSFunction.h:
636         * runtime/JSFunctionInlines.h:
637         (JSC::JSFunction::isAnonymousBuiltinFunction const):
638
639 2019-06-18  Keith Miller  <keith_miller@apple.com>
640
641         MaybeParseAsGeneratorForScope sometimes loses track of its scope ref
642         https://bugs.webkit.org/show_bug.cgi?id=198969
643         <rdar://problem/51620714>
644
645         Reviewed by Tadeu Zagallo.
646
647         Sometimes if the parser has enough nested scopes
648         MaybeParseAsGeneratorForScope can lose track of the ScopeRef it
649         should be tracking. This is because the parser sometimes relocates
650         its ScopeRefs. To fix this MaybeParseAsGeneratorForScope should
651         hold the scope ref it's watching.
652
653         * parser/Parser.cpp:
654         (JSC::Scope::MaybeParseAsGeneratorForScope::MaybeParseAsGeneratorForScope):
655         (JSC::Scope::MaybeParseAsGeneratorForScope::~MaybeParseAsGeneratorForScope):
656
657 2019-06-17  Justin Michaud  <justin_michaud@apple.com>
658
659         Validate that table element type is funcref if using an element section
660         https://bugs.webkit.org/show_bug.cgi?id=198910
661
662         Reviewed by Yusuke Suzuki.
663
664         Add missing validation when attempting to add an element section to an anyref table.
665
666         * wasm/WasmSectionParser.cpp:
667         (JSC::Wasm::SectionParser::parseElement):
668
669 2019-06-17  Tadeu Zagallo  <tzagallo@apple.com>
670
671         Concurrent GC should check the conn before starting a new collection cycle
672         https://bugs.webkit.org/show_bug.cgi?id=198913
673         <rdar://problem/49515149>
674
675         Reviewed by Filip Pizlo.
676
677         Heap::requestCollection tries to steal the conn as an optimization to avoid waking up the collector
678         thread if it's idle. We determine if the collector is idle by ensuring that there are no pending collections
679         and that the current GC phase is NotRunning. However, that's not safe immediately after the concurrent
680         GC has finished processing the last pending request. The collector thread will runEndPhase and immediately
681         start runNotRunningPhase, without checking if it still has the conn. If the mutator has stolen the conn in
682         the mean time, this will lead to both threads collecting concurrently, and eventually we'll crash in checkConn,
683         since the collector is running but doesn't have the conn anymore.
684
685         To solve this, we check if we still have the conn after holding the lock in runNotRunningPhase, in case the mutator
686         has stolen the conn. Ideally, we wouldn't let the mutator steal the conn in the first place, but that doesn't seem
687         trivial to determine.
688
689         * heap/Heap.cpp:
690         (JSC::Heap::runNotRunningPhase):
691
692 2019-06-17  Yusuke Suzuki  <ysuzuki@apple.com>
693
694         [JSC] Introduce DisposableCallSiteIndex to enforce type-safety
695         https://bugs.webkit.org/show_bug.cgi?id=197378
696
697         Reviewed by Saam Barati.
698
699         Some of CallSiteIndex are disposable. This is because some of CallSiteIndex are allocated and freed at runtime (not DFG/FTL compile time).
700         The example is CallSiteIndex for exception handler in GCAwareJITStubRoutineWithExceptionHandler. If we do not allocate and free CallSiteIndex,
701         we will create a new CallSiteIndex continuously and leak memory.
702
703         The other CallSiteIndex are not simply disposable because the ownership model is not unique one. They can be shared between multiple clients.
704         But not disposing them is OK because they are static one: they are allocated when compiling DFG/FTL, and we do not allocate such CallSiteIndex
705         at runtime.
706
707         To make this difference explicit and avoid disposing non-disposable CallSiteIndex accidentally, we introduce DisposableCallSiteIndex type, and
708         enforce type-safety to some degree.
709
710         We also correctly update the DisposableCallSiteIndex => CodeOrigin table when we are reusing the previously used DisposableCallSiteIndex.
711
712         * bytecode/CodeBlock.cpp:
713         (JSC::CodeBlock::newExceptionHandlingCallSiteIndex):
714         (JSC::CodeBlock::removeExceptionHandlerForCallSite):
715         * bytecode/CodeBlock.h:
716         * bytecode/PolymorphicAccess.cpp:
717         (JSC::AccessGenerationState::callSiteIndexForExceptionHandling):
718         (JSC::PolymorphicAccess::regenerate):
719         * bytecode/PolymorphicAccess.h:
720         (JSC::AccessGenerationState::callSiteIndexForExceptionHandling): Deleted.
721         * dfg/DFGCommonData.cpp:
722         (JSC::DFG::CommonData::addUniqueCallSiteIndex):
723         (JSC::DFG::CommonData::addDisposableCallSiteIndex):
724         (JSC::DFG::CommonData::removeDisposableCallSiteIndex):
725         (JSC::DFG::CommonData::removeCallSiteIndex): Deleted.
726         * dfg/DFGCommonData.h:
727         * interpreter/CallFrame.h:
728         (JSC::DisposableCallSiteIndex::DisposableCallSiteIndex):
729         (JSC::DisposableCallSiteIndex::fromCallSiteIndex):
730         * jit/GCAwareJITStubRoutine.cpp:
731         (JSC::GCAwareJITStubRoutineWithExceptionHandler::GCAwareJITStubRoutineWithExceptionHandler):
732         (JSC::GCAwareJITStubRoutineWithExceptionHandler::observeZeroRefCount):
733         (JSC::createJITStubRoutine):
734         * jit/GCAwareJITStubRoutine.h:
735         * jit/JITInlineCacheGenerator.h:
736
737 2019-06-17  Justin Michaud  <justin_michaud@apple.com>
738
739         [WASM-References] Add support for Funcref in parameters and return types
740         https://bugs.webkit.org/show_bug.cgi?id=198157
741
742         Reviewed by Yusuke Suzuki.
743
744         Add support for funcref in parameters, globals, and in table.get/set. When converting a JSValue to 
745         a funcref (nee anyfunc), we first make sure it is an exported wasm function or null. 
746
747         We also add support for Ref.func. Anywhere a Ref.func is used, (statically) we construct a JS wrapper
748         for it so that we never need to construct JSValues when handling references. This should make threads
749         easier to implement.
750
751         Finally, we add some missing bounds checks for table.get/set.
752
753         * wasm/WasmAirIRGenerator.cpp:
754         (JSC::Wasm::AirIRGenerator::tmpForType):
755         (JSC::Wasm::AirIRGenerator::moveOpForValueType):
756         (JSC::Wasm::AirIRGenerator::AirIRGenerator):
757         (JSC::Wasm::AirIRGenerator::addLocal):
758         (JSC::Wasm::AirIRGenerator::addConstant):
759         (JSC::Wasm::AirIRGenerator::addRefFunc):
760         (JSC::Wasm::AirIRGenerator::addTableSet):
761         (JSC::Wasm::AirIRGenerator::setGlobal):
762         (JSC::Wasm::AirIRGenerator::addReturn):
763         * wasm/WasmB3IRGenerator.cpp:
764         (JSC::Wasm::B3IRGenerator::addLocal):
765         (JSC::Wasm::B3IRGenerator::addTableSet):
766         (JSC::Wasm::B3IRGenerator::addRefFunc):
767         (JSC::Wasm::B3IRGenerator::setGlobal):
768         * wasm/WasmBBQPlan.cpp:
769         (JSC::Wasm::BBQPlan::compileFunctions):
770         * wasm/WasmCallingConvention.h:
771         (JSC::Wasm::CallingConventionAir::marshallArgument const):
772         (JSC::Wasm::CallingConventionAir::setupCall const):
773         * wasm/WasmExceptionType.h:
774         * wasm/WasmFormat.h:
775         (JSC::Wasm::isValueType):
776         (JSC::Wasm::isSubtype):
777         * wasm/WasmFunctionParser.h:
778         (JSC::Wasm::FunctionParser<Context>::parseExpression):
779         (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
780         * wasm/WasmInstance.cpp:
781         (JSC::Wasm::Instance::Instance):
782         (JSC::Wasm::Instance::getFunctionWrapper const):
783         (JSC::Wasm::Instance::setFunctionWrapper):
784         * wasm/WasmInstance.h:
785         * wasm/WasmModuleInformation.h:
786         (JSC::Wasm::ModuleInformation::referencedFunctions const):
787         (JSC::Wasm::ModuleInformation::addReferencedFunction const):
788         * wasm/WasmSectionParser.cpp:
789         (JSC::Wasm::SectionParser::parseGlobal):
790         (JSC::Wasm::SectionParser::parseInitExpr):
791         * wasm/WasmValidate.cpp:
792         (JSC::Wasm::Validate::addTableGet):
793         (JSC::Wasm::Validate::addTableSet):
794         (JSC::Wasm::Validate::addRefIsNull):
795         (JSC::Wasm::Validate::addRefFunc):
796         (JSC::Wasm::Validate::setLocal):
797         (JSC::Wasm::Validate::addCall):
798         (JSC::Wasm::Validate::addCallIndirect):
799         * wasm/js/JSToWasm.cpp:
800         (JSC::Wasm::createJSToWasmWrapper):
801         * wasm/js/JSWebAssemblyHelpers.h:
802         (JSC::isWebAssemblyHostFunction):
803         * wasm/js/JSWebAssemblyInstance.cpp:
804         (JSC::JSWebAssemblyInstance::visitChildren):
805         * wasm/js/JSWebAssemblyRuntimeError.cpp:
806         (JSC::createJSWebAssemblyRuntimeError):
807         * wasm/js/JSWebAssemblyRuntimeError.h:
808         * wasm/js/WasmToJS.cpp:
809         (JSC::Wasm::handleBadI64Use):
810         (JSC::Wasm::wasmToJS):
811         (JSC::Wasm::emitWasmToJSException):
812         * wasm/js/WasmToJS.h:
813         * wasm/js/WebAssemblyFunction.cpp:
814         (JSC::callWebAssemblyFunction):
815         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
816         * wasm/js/WebAssemblyModuleRecord.cpp:
817         (JSC::WebAssemblyModuleRecord::link):
818         * wasm/wasm.json:
819
820 2019-06-16  Darin Adler  <darin@apple.com>
821
822         Rename AtomicString to AtomString
823         https://bugs.webkit.org/show_bug.cgi?id=195276
824
825         Reviewed by Michael Catanzaro.
826
827         * many files: Let do-webcore-rename do the renaming.
828
829 2019-06-16  Yusuke Suzuki  <ysuzuki@apple.com>
830
831         [JSC] Grown region of WasmTable should be initialized with null
832         https://bugs.webkit.org/show_bug.cgi?id=198903
833
834         Reviewed by Saam Barati.
835
836         Grown region of Wasmtable is now empty. We should initialize it with null.
837         We also rename Wasm::Table::visitChildren to Wasm::Table::visitAggregate to
838         align to the naming convention.
839
840         * wasm/WasmTable.cpp:
841         (JSC::Wasm::Table::grow):
842         (JSC::Wasm::Table::visitAggregate):
843         (JSC::Wasm::Table::visitChildren): Deleted.
844         * wasm/WasmTable.h:
845         * wasm/js/JSWebAssemblyTable.cpp:
846         (JSC::JSWebAssemblyTable::visitChildren):
847
848 2019-06-14  Keith Miller  <keith_miller@apple.com>
849
850         Restore PAC based cage.
851         https://bugs.webkit.org/show_bug.cgi?id=198872
852
853         Rubber-stamped by Saam Barati.
854
855         * assembler/MacroAssemblerARM64.h:
856         (JSC::MacroAssemblerARM64::bitFieldInsert64):
857         * assembler/MacroAssemblerARM64E.h:
858         * assembler/testmasm.cpp:
859         (JSC::testCagePreservesPACFailureBit):
860         (JSC::run):
861         * dfg/DFGSpeculativeJIT.cpp:
862         (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
863         (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
864         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
865         (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
866         * ftl/FTLLowerDFGToB3.cpp:
867         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
868         (JSC::FTL::DFG::LowerDFGToB3::caged):
869         * jit/AssemblyHelpers.h:
870         (JSC::AssemblyHelpers::cageWithoutUntagging):
871         (JSC::AssemblyHelpers::cageConditionally):
872         (JSC::AssemblyHelpers::cage): Deleted.
873         * jit/JITPropertyAccess.cpp:
874         (JSC::JIT::emitIntTypedArrayGetByVal):
875         (JSC::JIT::emitFloatTypedArrayGetByVal):
876         (JSC::JIT::emitIntTypedArrayPutByVal):
877         (JSC::JIT::emitFloatTypedArrayPutByVal):
878         * llint/LowLevelInterpreter.asm:
879         * llint/LowLevelInterpreter64.asm:
880         * offlineasm/arm64.rb:
881         * offlineasm/instructions.rb:
882         * offlineasm/registers.rb:
883         * wasm/WasmAirIRGenerator.cpp:
884         (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
885         (JSC::Wasm::AirIRGenerator::addCallIndirect):
886         * wasm/WasmB3IRGenerator.cpp:
887         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
888         (JSC::Wasm::B3IRGenerator::addCallIndirect):
889         * wasm/WasmBinding.cpp:
890         (JSC::Wasm::wasmToWasm):
891         * wasm/js/JSToWasm.cpp:
892         (JSC::Wasm::createJSToWasmWrapper):
893         * wasm/js/WebAssemblyFunction.cpp:
894         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
895
896 2019-06-13  Yusuke Suzuki  <ysuzuki@apple.com>
897
898         Yarr bytecode compilation failure should be gracefully handled
899         https://bugs.webkit.org/show_bug.cgi?id=198700
900
901         Reviewed by Michael Saboff.
902
903         Currently, we assume that Yarr bytecode compilation does not fail. But in fact it can fail.
904         We should gracefully handle this failure as a runtime error, as we did for parse errors in [1].
905         We also harden Yarr's consumed character calculation by using Checked.
906
907         [1]: https://bugs.webkit.org/show_bug.cgi?id=185755
908
909         * inspector/ContentSearchUtilities.cpp:
910         (Inspector::ContentSearchUtilities::findMagicComment):
911         * runtime/RegExp.cpp:
912         (JSC::RegExp::byteCodeCompileIfNecessary):
913         (JSC::RegExp::compile):
914         (JSC::RegExp::compileMatchOnly):
915         * runtime/RegExpInlines.h:
916         (JSC::RegExp::matchInline):
917         * yarr/YarrErrorCode.cpp:
918         (JSC::Yarr::errorMessage):
919         (JSC::Yarr::errorToThrow):
920         * yarr/YarrErrorCode.h:
921         * yarr/YarrInterpreter.cpp:
922         (JSC::Yarr::ByteCompiler::ByteCompiler):
923         (JSC::Yarr::ByteCompiler::compile):
924         (JSC::Yarr::ByteCompiler::atomCharacterClass):
925         (JSC::Yarr::ByteCompiler::atomBackReference):
926         (JSC::Yarr::ByteCompiler::atomParenthesesOnceBegin):
927         (JSC::Yarr::ByteCompiler::atomParenthesesTerminalBegin):
928         (JSC::Yarr::ByteCompiler::atomParenthesesSubpatternBegin):
929         (JSC::Yarr::ByteCompiler::atomParentheticalAssertionBegin):
930         (JSC::Yarr::ByteCompiler::popParenthesesStack):
931         (JSC::Yarr::ByteCompiler::closeAlternative):
932         (JSC::Yarr::ByteCompiler::closeBodyAlternative):
933         (JSC::Yarr::ByteCompiler::alternativeBodyDisjunction):
934         (JSC::Yarr::ByteCompiler::alternativeDisjunction):
935         (JSC::Yarr::ByteCompiler::emitDisjunction):
936
937 2019-06-12  Yusuke Suzuki  <ysuzuki@apple.com>
938
939         [JSC] Polymorphic call stub's slow path should restore callee saves before performing tail call
940         https://bugs.webkit.org/show_bug.cgi?id=198770
941
942         Reviewed by Saam Barati.
943
944         Polymorphic call stub is a bit specially patched in JS call site. Typical JS call site for tail calls
945         are the following.
946
947             if (callee == patchableCallee) {
948                 restore callee saves for tail call
949                 prepare for tail call
950                 jump to the target function
951             }
952             restore callee saves for slow path
953             call the slow path function
954
955         And linking patches patchableCallee, target function, and slow path function. But polymorphic call stub
956         patches the above `if` statement with the jump to the stub.
957
958             jump to the polymorphic call stub
959
960         This is because polymorphic call stub wants to use CallFrameShuffler to get scratch registers. As a result,
961         "restore callee saves for tail call" thing needs to be done in the polymorphic call stubs. While it is
962         correctly done for the major cases, we have `slowPath` skips, and that path missed restoring callee saves.
963         This skip happens if the callee is non JSCell or non JS function, so typically, InternalFunction is handled
964         in that path.
965
966         This patch does that skips after restoring callee saves.
967
968         * bytecode/CallLinkInfo.cpp:
969         (JSC::CallLinkInfo::CallLinkInfo):
970         * bytecode/CallLinkInfo.h:
971         (JSC::CallLinkInfo::setUpCall):
972         (JSC::CallLinkInfo::calleeGPR):
973         (JSC::CallLinkInfo::setCalleeGPR): Deleted.
974         * jit/Repatch.cpp:
975         (JSC::revertCall):
976         (JSC::linkVirtualFor):
977         (JSC::linkPolymorphicCall):
978         * jit/Repatch.h:
979         * jit/ThunkGenerators.cpp:
980         (JSC::virtualThunkFor):
981
982 2019-06-12  Commit Queue  <commit-queue@webkit.org>
983
984         Unreviewed, rolling out r246322.
985         https://bugs.webkit.org/show_bug.cgi?id=198796
986
987         "It's a huge page load regression on iOS" (Requested by
988         saamyjoon on #webkit).
989
990         Reverted changeset:
991
992         "Roll out PAC cage"
993         https://bugs.webkit.org/show_bug.cgi?id=198726
994         https://trac.webkit.org/changeset/246322
995
996 2019-06-11  Alexey Shvayka  <shvaikalesh@gmail.com>
997
998         JSC should throw if proxy set returns falsish in strict mode context
999         https://bugs.webkit.org/show_bug.cgi?id=177398
1000
1001         Reviewed by Yusuke Suzuki.
1002
1003         Throw TypeError exception if Proxy's `set` trap returns falsy value.
1004         (step 6.c of https://tc39.es/ecma262/#sec-putvalue)
1005
1006         * runtime/ProxyObject.cpp:
1007         (JSC::ProxyObject::performPut):
1008         (JSC::ProxyObject::put):
1009         (JSC::ProxyObject::putByIndexCommon):
1010         * runtime/ProxyObject.h:
1011
1012 2019-06-11  Alexey Shvayka  <shvaikalesh@gmail.com>
1013
1014         Error message for non-callable Proxy `construct` trap is misleading
1015         https://bugs.webkit.org/show_bug.cgi?id=198637
1016
1017         Reviewed by Saam Barati.
1018
1019         Just like other traps, Proxy `construct` trap is invoked with [[Call]], not [[Construct]].
1020
1021         * runtime/ProxyObject.cpp:
1022         (JSC::performProxyConstruct): Tweak error message.
1023
1024 2019-06-10  Tadeu Zagallo  <tzagallo@apple.com>
1025
1026         AI BitURShift's result should not be unsigned
1027         https://bugs.webkit.org/show_bug.cgi?id=198689
1028         <rdar://problem/51550063>
1029
1030         Reviewed by Saam Barati.
1031
1032         Treating BitURShift's result as unsigned in the abstract interpreter incorrectly overflows it.
1033         This breaks the DFG and FTL, since they assume that BitURShift's result is an int32 value, but
1034         get a double constant from AI. Since the result will be converted to unsigned by UInt32ToNumber,
1035         all we have to do is store the result as a signed int32.
1036
1037         * dfg/DFGAbstractInterpreterInlines.h:
1038
1039 2019-06-11  Michael Catanzaro  <mcatanzaro@igalia.com>
1040
1041         Unreviewed build warning fixes
1042
1043         Silence -Wreturn-type warning
1044
1045         * wasm/WasmTable.cpp:
1046         (JSC::Wasm::Table::tryCreate):
1047
1048 2019-06-11  Saam Barati  <sbarati@apple.com>
1049
1050         Roll out PAC cage
1051         https://bugs.webkit.org/show_bug.cgi?id=198726
1052
1053         Reviewed by Keith Miller.
1054
1055         This patch rolls out: r245064, r245145, r245168, r245313, r245432, r245622.
1056         
1057         The resulting state we're in is we have Gigacage enabled on arm64.
1058         There is no more PAC caging.
1059
1060         We're doing this because there are performance issues with PAC caging
1061         that we haven't resolved yet.
1062
1063         * assembler/CPU.h:
1064         (JSC::isARM64E): Deleted.
1065         * assembler/MacroAssemblerARM64E.h:
1066         (JSC::MacroAssemblerARM64E::tagArrayPtr): Deleted.
1067         (JSC::MacroAssemblerARM64E::untagArrayPtr): Deleted.
1068         (JSC::MacroAssemblerARM64E::removeArrayPtrTag): Deleted.
1069         * b3/B3LowerToAir.cpp:
1070         * b3/B3PatchpointSpecial.cpp:
1071         (JSC::B3::PatchpointSpecial::admitsStack):
1072         * b3/B3StackmapSpecial.cpp:
1073         (JSC::B3::StackmapSpecial::forEachArgImpl):
1074         (JSC::B3::StackmapSpecial::isArgValidForRep):
1075         * b3/B3Validate.cpp:
1076         * b3/B3ValueRep.cpp:
1077         (JSC::B3::ValueRep::addUsedRegistersTo const):
1078         (JSC::B3::ValueRep::dump const):
1079         (WTF::printInternal):
1080         * b3/B3ValueRep.h:
1081         (JSC::B3::ValueRep::ValueRep):
1082         (JSC::B3::ValueRep::isReg const):
1083         * dfg/DFGOperations.cpp:
1084         (JSC::DFG::newTypedArrayWithSize):
1085         * dfg/DFGSpeculativeJIT.cpp:
1086         (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
1087         (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
1088         (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
1089         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
1090         (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
1091         * dfg/DFGSpeculativeJIT.h:
1092         * dfg/DFGSpeculativeJIT64.cpp:
1093         (JSC::DFG::SpeculativeJIT::compile):
1094         * ftl/FTLLowerDFGToB3.cpp:
1095         (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
1096         (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
1097         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
1098         (JSC::FTL::DFG::LowerDFGToB3::compileDataViewGet):
1099         (JSC::FTL::DFG::LowerDFGToB3::compileDataViewSet):
1100         (JSC::FTL::DFG::LowerDFGToB3::caged):
1101         (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):
1102         (JSC::FTL::DFG::LowerDFGToB3::untagArrayPtr): Deleted.
1103         (JSC::FTL::DFG::LowerDFGToB3::removeArrayPtrTag): Deleted.
1104         * heap/ConservativeRoots.cpp:
1105         (JSC::ConservativeRoots::genericAddPointer):
1106         * jit/AssemblyHelpers.h:
1107         (JSC::AssemblyHelpers::cageConditionally):
1108         * jit/IntrinsicEmitter.cpp:
1109         (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
1110         * jit/JITPropertyAccess.cpp:
1111         (JSC::JIT::emitDirectArgumentsGetByVal):
1112         (JSC::JIT::emitIntTypedArrayGetByVal):
1113         (JSC::JIT::emitFloatTypedArrayGetByVal):
1114         (JSC::JIT::emitIntTypedArrayPutByVal):
1115         (JSC::JIT::emitFloatTypedArrayPutByVal):
1116         * jit/PolymorphicCallStubRoutine.cpp:
1117         (JSC::PolymorphicCallNode::clearCallLinkInfo):
1118         * jit/RegisterSet.h:
1119         * llint/LowLevelInterpreter64.asm:
1120         * runtime/ArrayBuffer.cpp:
1121         (JSC::SharedArrayBufferContents::SharedArrayBufferContents):
1122         (JSC::SharedArrayBufferContents::~SharedArrayBufferContents):
1123         (JSC::ArrayBufferContents::ArrayBufferContents):
1124         (JSC::ArrayBufferContents::destroy):
1125         (JSC::ArrayBufferContents::tryAllocate):
1126         (JSC::ArrayBufferContents::makeShared):
1127         (JSC::ArrayBufferContents::copyTo):
1128         * runtime/ArrayBuffer.h:
1129         (JSC::SharedArrayBufferContents::data const):
1130         (JSC::ArrayBufferContents::data const):
1131         (JSC::ArrayBuffer::data):
1132         (JSC::ArrayBuffer::data const):
1133         (JSC::ArrayBuffer::byteLength const):
1134         * runtime/ArrayBufferView.cpp:
1135         (JSC::ArrayBufferView::ArrayBufferView):
1136         * runtime/ArrayBufferView.h:
1137         (JSC::ArrayBufferView::baseAddress const):
1138         (JSC::ArrayBufferView::setRangeImpl):
1139         (JSC::ArrayBufferView::getRangeImpl):
1140         (JSC::ArrayBufferView::byteLength const): Deleted.
1141         * runtime/CachedTypes.cpp:
1142         (JSC::CachedScopedArgumentsTable::encode):
1143         (JSC::CachedScopedArgumentsTable::decode const):
1144         * runtime/CagedBarrierPtr.h:
1145         (JSC::CagedBarrierPtr::CagedBarrierPtr):
1146         (JSC::CagedBarrierPtr::set):
1147         (JSC::CagedBarrierPtr::get const):
1148         (JSC::CagedBarrierPtr::getMayBeNull const):
1149         (JSC::CagedBarrierPtr::operator== const):
1150         (JSC::CagedBarrierPtr::operator!= const):
1151         (JSC::CagedBarrierPtr::operator bool const):
1152         (JSC::CagedBarrierPtr::setWithoutBarrier):
1153         (JSC::CagedBarrierPtr::operator* const):
1154         (JSC::CagedBarrierPtr::operator-> const):
1155         (JSC::CagedBarrierPtr::operator[] const):
1156         (JSC::CagedBarrierPtr::getUnsafe const): Deleted.
1157         (JSC::CagedBarrierPtr::at const): Deleted.
1158         * runtime/DataView.cpp:
1159         (JSC::DataView::DataView):
1160         * runtime/DataView.h:
1161         (JSC::DataView::get):
1162         (JSC::DataView::set):
1163         * runtime/DirectArguments.cpp:
1164         (JSC::DirectArguments::visitChildren):
1165         (JSC::DirectArguments::overrideThings):
1166         (JSC::DirectArguments::unmapArgument):
1167         * runtime/DirectArguments.h:
1168         * runtime/GenericArguments.h:
1169         * runtime/GenericArgumentsInlines.h:
1170         (JSC::GenericArguments<Type>::visitChildren):
1171         (JSC::GenericArguments<Type>::initModifiedArgumentsDescriptor):
1172         (JSC::GenericArguments<Type>::setModifiedArgumentDescriptor):
1173         (JSC::GenericArguments<Type>::isModifiedArgumentDescriptor):
1174         * runtime/GenericTypedArrayView.h:
1175         * runtime/GenericTypedArrayViewInlines.h:
1176         (JSC::GenericTypedArrayView<Adaptor>::GenericTypedArrayView):
1177         * runtime/JSArrayBufferView.cpp:
1178         (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
1179         (JSC::JSArrayBufferView::JSArrayBufferView):
1180         (JSC::JSArrayBufferView::finalize):
1181         (JSC::JSArrayBufferView::slowDownAndWasteMemory):
1182         * runtime/JSArrayBufferView.h:
1183         (JSC::JSArrayBufferView::ConstructionContext::vector const):
1184         (JSC::JSArrayBufferView::isNeutered):
1185         (JSC::JSArrayBufferView::vector const):
1186         (JSC::JSArrayBufferView::hasVector const): Deleted.
1187         * runtime/JSGenericTypedArrayViewInlines.h:
1188         (JSC::JSGenericTypedArrayView<Adaptor>::createUninitialized):
1189         (JSC::JSGenericTypedArrayView<Adaptor>::estimatedSize):
1190         (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
1191         * runtime/Options.h:
1192         * runtime/ScopedArgumentsTable.cpp:
1193         (JSC::ScopedArgumentsTable::clone):
1194         (JSC::ScopedArgumentsTable::setLength):
1195         * runtime/ScopedArgumentsTable.h:
1196         * runtime/SymbolTable.h:
1197         * wasm/WasmAirIRGenerator.cpp:
1198         (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
1199         (JSC::Wasm::AirIRGenerator::addCallIndirect):
1200         * wasm/WasmB3IRGenerator.cpp:
1201         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
1202         (JSC::Wasm::B3IRGenerator::addCallIndirect):
1203         * wasm/WasmBBQPlan.cpp:
1204         (JSC::Wasm::BBQPlan::complete):
1205         * wasm/WasmBinding.cpp:
1206         (JSC::Wasm::wasmToWasm):
1207         * wasm/WasmInstance.h:
1208         (JSC::Wasm::Instance::cachedMemory const):
1209         (JSC::Wasm::Instance::updateCachedMemory):
1210         * wasm/WasmMemory.cpp:
1211         (JSC::Wasm::Memory::Memory):
1212         (JSC::Wasm::Memory::~Memory):
1213         (JSC::Wasm::Memory::grow):
1214         (JSC::Wasm::Memory::dump const):
1215         * wasm/WasmMemory.h:
1216         (JSC::Wasm::Memory::memory const):
1217         * wasm/js/JSToWasm.cpp:
1218         (JSC::Wasm::createJSToWasmWrapper):
1219         * wasm/js/WebAssemblyFunction.cpp:
1220         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
1221
1222 2019-06-10  Basuke Suzuki  <Basuke.Suzuki@sony.com>
1223
1224         [WinCairo] Remove build warning from RemoteInspector.
1225         https://bugs.webkit.org/show_bug.cgi?id=198724
1226
1227         Reviewed by Joseph Pecoraro.
1228
1229         In `RemoteInspectorConnectionClient.h`, an interface was defined with empty implementation.
1230         This method is to be overwritten by sub classes so that parameter name is important
1231         so they are commented out rather than just removing from the definition.
1232
1233         * inspector/remote/RemoteInspector.h:
1234
1235 2019-06-10  Sam Weinig  <weinig@apple.com>
1236
1237         Remove Dashboard support
1238         https://bugs.webkit.org/show_bug.cgi?id=198615
1239
1240         Reviewed by Ryosuke Niwa.
1241
1242         * Configurations/FeatureDefines.xcconfig:
1243
1244 2019-06-10  Devin Rousso  <drousso@apple.com>
1245
1246         Web Automation: add notifications for when remote automation is enabled/disabled
1247         https://bugs.webkit.org/show_bug.cgi?id=198703
1248         <rdar://problem/50588975>
1249
1250         Reviewed by Timothy Hatcher.
1251
1252         * inspector/remote/RemoteInspectorConstants.h:
1253
1254 2019-06-10  Yusuke Suzuki  <ysuzuki@apple.com>
1255
1256         Unreviewed, build fix for non-DFG configurations, part 2
1257         https://bugs.webkit.org/show_bug.cgi?id=198023
1258
1259         * bytecode/CodeBlock.cpp:
1260         (JSC::CodeBlock::finalizeUnconditionally):
1261
1262 2019-06-10  Yusuke Suzuki  <ysuzuki@apple.com>
1263
1264         Unreviewed, build fix for non-DFG configurations
1265         https://bugs.webkit.org/show_bug.cgi?id=198023
1266
1267         * bytecode/CodeBlock.cpp:
1268         (JSC::CodeBlock::finalizeUnconditionally):
1269
1270 2019-06-10  Yusuke Suzuki  <ysuzuki@apple.com>
1271
1272         [JSC] UnlinkedCodeBlock should be eventually jettisoned in VM mini mode
1273         https://bugs.webkit.org/show_bug.cgi?id=198023
1274
1275         Reviewed by Saam Barati.
1276
1277         While CodeBlock is periodically jettisoned, UnlinkedCodeBlock and UnlinkedFunctionExecutable can be retained almost forever in certain type of applications.
1278         When we execute a program, which has UnlinkedProgramCodeBlock retained in CodeCache. And UnlinkedProgramCodeBlock holds array of UnlinkedFunctionExecutable.
1279         And UnlinkedFunctionExecutables hold UnlinkedFunctionCodeBlocks once it is generated. So eventually, this tree gets larger and larger until we purge
1280         UnlinkedProgramCodeBlock from CodeCache. This is OK in the browser case. We navigate to various other pages, and UnlinkedProgramCodeBlocks should eventually
1281         be pruned from CodeCache with the new ones. So this tree won't be retained forever. But the behavior is different in the other applications that do not have
1282         navigations. If they only have one program which holds all, we basically retain this tree during executing this application. The same thing can happen in
1283         web applications which does not have navigation and keeps alive for a long time. Once we hit CodeCache limit by periodically executing a new script, we will
1284         hit the uppermost of memory footprint. But until that, we increase our memory footprint.
1285
1286         However, destroying these UnlinkedCodeBlocks and UnlinkedFunctionExecutables causes a tricky problem. In the browser environment, navigation can happen at any
1287         time. So even if the given UnlinkedCodeBlock seems unused in the current page, it can be used when navigating to a new page which is under the same domain.
1288         One example is initializing function in a script. It is only executed once per page. So once it is executed, it seems that this UnlinkedCodeBlock is unused.
1289         But this will be used when we navigate to a new page. Pruning code blocks based on usage could cause performance regression.
1290
1291         But if our VM is mini VM mode, the story is different. In mini VM mode, we focus on memory footprint rather than performance e.g. daemons. The daemon never
1292         reuse these CodeCache since we do not have the navigation.
1293
1294         This patch logically makes UnlinkedFunctionExecutable -> UnlinkedCodeBlock reference weak when VM is mini mode. If UnlinkedCodeBlock is used in previous GC
1295         cycle, we retain it. But if it is not used, and if UnlinkedFunctionExecutable is only the cell keeping UnlinkedCodeBlock alive, we destroy it. It is a
1296         heuristic. In a super pathological case, it could increase memory footprint. Consider the following example.
1297
1298             UnlinkedFunctionExecutable(A1) -> UnlinkedCodeBlock(B1) -> UnlinkedFunctionExecutable(C1) -> UnlinkedCodeBlock(D1)
1299                                                                                                              ^
1300                                                                                                          CodeBlock(E1)
1301
1302         We could delete A1, B1, and C1 while keeping D1. But if we eventually re-execute the same code corresponding to A1, B1, C1, they will be newly created, and
1303         we will create duplicate UnlinkedCodeBlock and instructions stream for D1.
1304
1305                                                                                                          UnlinkedCodeBlock(D1)
1306                                                                                                              ^
1307                                                                                                          CodeBlock(E1)
1308
1309             UnlinkedFunctionExecutable(A2) -> UnlinkedCodeBlock(B2) -> UnlinkedFunctionExecutable(C2) -> UnlinkedCodeBlock(D2)
1310
1311         But this does not happen in practice and even it happens, we eventually discard D1 and D2 since CodeBlock E1 will be jettisoned anyway. So in practice, we do
1312         not see memory footprint increase. We tested it in Gmail and the target application, but both said memory footprint reduction (30 MB / 400 MB and 1 MB /6 MB).
1313         While this affects on performance much on tests which has navigation (1-3 % regression in Speedometer2, note that JetStream2 does not show regression in x64,
1314         while it is not enabling mini mode), we do not apply this to non mini mode VM until we come up with a good strategy to fasten performance of re-generation.
1315         Personally I think flushing destroyed UnlinkedCodeBlock to the disk sounds promising.
1316
1317         If UnlinkedCodeBlock is generated from bytecode cache, we do not make UnlinkedFunctionExecutable -> UnlinkedCodeBlock link weak because the decoder of the bytecode
1318         cache assumes that generated JSCells won't be destroyed while the parent cells of that cell are live. This is true in the current implementation, and this assumption
1319         will be broken with this patch. So, for now, we do not make this link weak. Currently, our target application does not use bytecode cache so it is OK.
1320
1321         This patch also introduce simple heuristic. We are counting UnlinkedCodeBlock's age. And once the age becomes maximum size, we make UnlinkedFunctionExecutable ->
1322         UnlinkedCodeBlock link weak. We also use execution counter information to reset this age: CodeBlock will reset undelying UnlinkedCodeBlock's age if it has executed
1323         While this heuristic is quite simple, it has some effect in practice. Basically what happens with this heuristic is that UnlinkedFunctionExecutable ->
1324         UnlinkedCodeBlock link strong. When GC happens, we are executing some CodeBlocks, which become live. And ScriptExecutables -> UnlinkedFunctionExecutables held
1325         by this CodeBlock become also live. Then UnlinkedFunctionExecutables can mark the child UnlinkedCodeBlocks if it is not so old.
1326         If some of parent UnlinkedFunctionExecutable becomes dead, child UnlinkedCodeBlocks tends to be dead unless some live CodeBlock holds it. But it is OK for a first
1327         heuristics since this means that parent code block is now considered old, reachable UnlinkedCodeBlock will be used when the parent is executed again. So destroying
1328         the tree is OK even if the tree may include some new UnlinkedCodeBlock. While we could make more sophisticated mechanism to manage these lifetime, I think this is a
1329         good starting point.
1330
1331         Based on measurement, we pick 7 as a maximum age. If we pick 0, we can get more memory reduction (1 - 1.5 MB!), while we ends up reparsing codes so many times.
1332         It seems that 7 can reduce fair amount of memory while doing small # of reparsing on average (usually, 1, 2. Sometimes, 100. But not 300, which is the case in 0).
1333         If we want to get more memory reduction for the sake of performance, we could decrease this age limit.
1334
1335         Since we do not have an automated script right now so it is a bit difficult to measure memory footprint precisely. But manual testing shows that this patch improves
1336         memory footprint of our target application from about 6.5 MB to about 5.9 MB.
1337
1338         * bytecode/CodeBlock.cpp:
1339         (JSC::CodeBlock::finalizeUnconditionally):
1340         * bytecode/CodeBlock.h:
1341         * bytecode/UnlinkedCodeBlock.cpp:
1342         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
1343         (JSC::UnlinkedCodeBlock::visitChildren):
1344         * bytecode/UnlinkedCodeBlock.h:
1345         (JSC::UnlinkedCodeBlock::age const):
1346         (JSC::UnlinkedCodeBlock::resetAge):
1347         * bytecode/UnlinkedFunctionExecutable.cpp:
1348         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
1349         (JSC::UnlinkedFunctionExecutable::visitChildren):
1350         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
1351         (JSC::UnlinkedFunctionExecutable::decodeCachedCodeBlocks):
1352         (JSC::UnlinkedFunctionExecutable::finalizeUnconditionally):
1353         * bytecode/UnlinkedFunctionExecutable.h:
1354         * heap/Heap.cpp:
1355         (JSC::Heap::finalizeUnconditionalFinalizers):
1356         * runtime/CachedTypes.cpp:
1357         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
1358         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
1359         * runtime/CodeSpecializationKind.h:
1360         * runtime/Options.h:
1361         * runtime/VM.cpp:
1362         (JSC::VM::isInMiniMode): Deleted.
1363         * runtime/VM.h:
1364         (JSC::VM::isInMiniMode):
1365         (JSC::VM::useUnlinkedCodeBlockJettisoning):
1366
1367 2019-06-10  Timothy Hatcher  <timothy@apple.com>
1368
1369         Integrate dark mode support for iOS.
1370         https://bugs.webkit.org/show_bug.cgi?id=198687
1371         rdar://problem/51545643
1372
1373         Reviewed by Tim Horton.
1374
1375         * Configurations/FeatureDefines.xcconfig:
1376
1377 2019-06-10  Adrian Perez de Castro  <aperez@igalia.com>
1378
1379         [JSC] Linker fails when unified sources are not in use
1380         https://bugs.webkit.org/show_bug.cgi?id=198722
1381
1382         Reviewed by Keith Miller.
1383
1384         Added missing inclusions of headers in several files which make use of inline functions.
1385
1386         * b3/B3AtomicValue.cpp:
1387         * b3/B3BlockInsertionSet.cpp:
1388         * b3/B3FenceValue.cpp:
1389         * b3/B3LowerMacrosAfterOptimizations.cpp:
1390         * b3/B3PureCSE.cpp:
1391         * b3/B3StackmapValue.cpp:
1392         * b3/B3SwitchValue.cpp:
1393         * b3/B3UseCounts.cpp:
1394         * b3/B3VariableValue.cpp:
1395         * b3/B3WasmAddressValue.cpp:
1396         * b3/B3WasmBoundsCheckValue.cpp:
1397         * ftl/FTLCompile.cpp:
1398         * wasm/WasmSectionParser.cpp:
1399         * wasm/WasmTable.cpp:
1400         * wasm/WasmValidate.cpp:
1401
1402 2019-06-10  Keith Miller  <keith_miller@apple.com>
1403
1404         Make new Symbol/Promise API public
1405         https://bugs.webkit.org/show_bug.cgi?id=198709
1406
1407         Reviewed by Saam Barati.
1408
1409         We also need to #ifdef some tests when building for older
1410         platforms because the signatures for some methods are outdated on
1411         those platforms.
1412
1413         * API/JSObjectRef.h:
1414         * API/JSObjectRefPrivate.h:
1415         * API/JSValue.h:
1416         * API/JSValuePrivate.h:
1417         * API/JSValueRef.h:
1418         * API/tests/testapi.mm:
1419         (testObjectiveCAPIMain):
1420
1421 2019-06-09  Commit Queue  <commit-queue@webkit.org>
1422
1423         Unreviewed, rolling out r246150, r246160, and r246166.
1424         https://bugs.webkit.org/show_bug.cgi?id=198698
1425
1426         Regresses page loading time on iOS 13 (Requested by keith_m__
1427         on #webkit).
1428
1429         Reverted changesets:
1430
1431         "Reenable Gigacage on ARM64."
1432         https://bugs.webkit.org/show_bug.cgi?id=198453
1433         https://trac.webkit.org/changeset/246150
1434
1435         "Unrevied build fix for FTL without Gigacage."
1436         https://trac.webkit.org/changeset/246160
1437
1438         "Fix typo in cageWithoutUntagging"
1439         https://bugs.webkit.org/show_bug.cgi?id=198617
1440         https://trac.webkit.org/changeset/246166
1441
1442 2019-06-09  Yusuke Suzuki  <ysuzuki@apple.com>
1443
1444         [JSC] Use mergePrediction in ValuePow prediction propagation
1445         https://bugs.webkit.org/show_bug.cgi?id=198648
1446
1447         Reviewed by Saam Barati.
1448
1449         We are accidentally using setPrediction. This is wrong since prediction propagation (not processInvariant)
1450         must extend the speculation types to ensure we eventually reach to the fixed point. setPrediction can discard
1451         previously configured predictions, can lead to oscillation potentially. Use mergePrediction instead.
1452
1453         * dfg/DFGPredictionPropagationPhase.cpp:
1454
1455 2019-06-07  Tadeu Zagallo  <tzagallo@apple.com>
1456
1457         AI should get GetterSetter structure from the base's GlobalObject for GetGetterSetterByOffset
1458         https://bugs.webkit.org/show_bug.cgi?id=198581
1459         <rdar://problem/51099753>
1460
1461         Reviewed by Saam Barati.
1462
1463         For GetGetterSetterByOffset, when the abstract interpreter fails to read the property
1464         from the object, it gets the GetterSetter structure from the CodeBlock's global object.
1465         However, that's not correct, since the global object for the base object might differ
1466         from the CodeBlock's. Instead, we try to get the global object from the base, when it's
1467         a constant object. Otherwise, we can't infer the value and only set the type.
1468
1469         * dfg/DFGAbstractInterpreterInlines.h:
1470         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1471
1472 2019-06-06  Devin Rousso  <drousso@apple.com>
1473
1474         Web Inspector: create CommandLineAPIHost lazily like the other agents
1475         https://bugs.webkit.org/show_bug.cgi?id=196047
1476         <rdar://problem/49087835>
1477
1478         Reviewed by Timothy Hatcher.
1479
1480         * inspector/InjectedScriptManager.h:
1481         * inspector/InjectedScriptManager.cpp:
1482         (Inspector::InjectedScriptManager::connect): Added.
1483
1484 2019-06-06  Keith Miller  <keith_miller@apple.com>
1485
1486         Fix typo in cageWithoutUntagging
1487         https://bugs.webkit.org/show_bug.cgi?id=198617
1488
1489         Reviewed by Saam Barati.
1490
1491         * assembler/testmasm.cpp:
1492         (JSC::testCagePreservesPACFailureBit):
1493         * dfg/DFGSpeculativeJIT.cpp:
1494         (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
1495         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
1496         * jit/AssemblyHelpers.h:
1497         (JSC::AssemblyHelpers::cageWithoutUntagging):
1498         (JSC::AssemblyHelpers::cageConditionally):
1499         (JSC::AssemblyHelpers::cageWithoutUntaging): Deleted.
1500
1501 2019-06-06  Alexey Shvayka  <shvaikalesh@gmail.com>
1502
1503         JSON.parse throws incorrect exception when called w/o arguments
1504         https://bugs.webkit.org/show_bug.cgi?id=198574
1505
1506         Reviewed by Yusuke Suzuki.
1507
1508         Always coerce first argument to string and attempt to parse it.
1509         (steps 1-2 of https://tc39.github.io/ecma262/#sec-json.parse)
1510
1511         * runtime/JSONObject.cpp:
1512         (JSC::JSONProtoFuncParse): Remove argumentCount check.
1513
1514 2019-06-06  Keith Miller  <keith_miller@apple.com>
1515
1516         Unrevied build fix for FTL without Gigacage.
1517
1518         * ftl/FTLLowerDFGToB3.cpp:
1519         (JSC::FTL::DFG::LowerDFGToB3::caged):
1520
1521 2019-06-06  Michael Catanzaro  <mcatanzaro@igalia.com>
1522
1523         aarch64: ‘JSC::ARM64Assembler::LinkRecord::<unnamed union>::RealTypes::m_compareRegister’ is too small to hold all values of ‘JSC::ARM64Assembler::RegisterID’ {aka ‘enum JSC::ARM64Registers::RegisterID’}
1524         https://bugs.webkit.org/show_bug.cgi?id=198014
1525
1526         Reviewed by Yusuke Suzuki.
1527
1528         When building for aarch64, there is a huge warning spam here. It's impossible to see any
1529         other warnings. This has been ongoing for so long I've begun to suspect that nobody works
1530         on this architecture.
1531
1532         Anyway, the problem is because we need eight bits to store all possible RegisterID values,
1533         but the bitfield is only six bits wide. Fix it. The COMPILE_ASSERT checking the size of this
1534         struct is still happy, so I presume the change is OK.
1535
1536         * assembler/ARM64Assembler.h:
1537
1538 2019-06-06  Keith Miller  <keith_miller@apple.com>
1539
1540         Reenable Gigacage on ARM64.
1541         https://bugs.webkit.org/show_bug.cgi?id=198453
1542
1543         Reviewed by Michael Saboff.
1544
1545         This patch adds back Gigacaging on Apple's ARM64 ports. Unlike the
1546         old Gigacage however, arm64e uses both Gigacaging and PAC. In
1547         order to ensure the PAC bits are not stripped in the caging
1548         process we use the bit field insert instruction to take the low
1549         bits from caging and the high bits from the PAC authentication.
1550
1551         * assembler/MacroAssemblerARM64.h:
1552         (JSC::MacroAssemblerARM64::bitFieldInsert64):
1553         * assembler/MacroAssemblerARM64E.h:
1554         * assembler/testmasm.cpp:
1555         (JSC::testCagePreservesPACFailureBit):
1556         (JSC::run):
1557         * dfg/DFGSpeculativeJIT.cpp:
1558         (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
1559         (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
1560         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
1561         (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
1562         * ftl/FTLLowerDFGToB3.cpp:
1563         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
1564         (JSC::FTL::DFG::LowerDFGToB3::caged):
1565         * jit/AssemblyHelpers.h:
1566         (JSC::AssemblyHelpers::cageWithoutUntaging):
1567         (JSC::AssemblyHelpers::cageConditionally):
1568         (JSC::AssemblyHelpers::cage): Deleted.
1569         * jit/JITPropertyAccess.cpp:
1570         (JSC::JIT::emitIntTypedArrayGetByVal):
1571         (JSC::JIT::emitFloatTypedArrayGetByVal):
1572         (JSC::JIT::emitIntTypedArrayPutByVal):
1573         (JSC::JIT::emitFloatTypedArrayPutByVal):
1574         * llint/LowLevelInterpreter.asm:
1575         * llint/LowLevelInterpreter64.asm:
1576         * offlineasm/arm64.rb:
1577         * offlineasm/instructions.rb:
1578         * offlineasm/registers.rb:
1579         * wasm/WasmAirIRGenerator.cpp:
1580         (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
1581         (JSC::Wasm::AirIRGenerator::addCallIndirect):
1582         * wasm/WasmB3IRGenerator.cpp:
1583         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
1584         (JSC::Wasm::B3IRGenerator::addCallIndirect):
1585         * wasm/WasmBinding.cpp:
1586         (JSC::Wasm::wasmToWasm):
1587         * wasm/js/JSToWasm.cpp:
1588         (JSC::Wasm::createJSToWasmWrapper):
1589         * wasm/js/WebAssemblyFunction.cpp:
1590         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
1591
1592 2019-06-06  Michael Saboff  <msaboff@apple.com>
1593
1594         [ARM64E]: Add disassembler support for authenticated instructions
1595         https://bugs.webkit.org/show_bug.cgi?id=198562
1596
1597         Reviewed by Keith Miller.
1598
1599         Added support for all the instructions supported in ARM64EAssembler.h.
1600
1601         * disassembler/ARM64/A64DOpcode.cpp:
1602         (JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::format):
1603         (JSC::ARM64Disassembler::A64DOpcodeDataProcessing2Source::format):
1604         (JSC::ARM64Disassembler::A64DOpcodeHint::format):
1605         (JSC::ARM64Disassembler::A64DOpcodeHint::opName):
1606         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::format):
1607         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::authOpName):
1608         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::format):
1609         * disassembler/ARM64/A64DOpcode.h:
1610         (JSC::ARM64Disassembler::A64DOpcodeDataProcessing2Source::opNameIndex):
1611         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::opName):
1612         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::opNum):
1613         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::mBit):
1614         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::sBit):
1615         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::wBit):
1616         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::immediate10):
1617         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::authOpCode):
1618         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::op2):
1619         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::op3):
1620         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::op4):
1621         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::mBit):
1622         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::rm):
1623         (JSC::ARM64Disassembler::A64DOpcodeHint::opName): Deleted.
1624
1625 2019-06-05  Justin Michaud  <justin_michaud@apple.com>
1626
1627         [WASM-References] Add support for Anyref tables, Table.get and Table.set (for Anyref only).
1628         https://bugs.webkit.org/show_bug.cgi?id=198398
1629
1630         Reviewed by Saam Barati.
1631
1632         Create a new table subtype called FuncRefTable (note: Anyfunc was renamed to Funcref in the references spec).
1633         Table now write-barriers and visits its children's wrapper objects. FuncRefTable caches some extra data to
1634         support calling from wasm. A JSWebAssemblyTable is required to set an anyref element, but this is only because
1635         we need to write barrier it (so it should not restrict how we implement threads). This patch does, however,
1636         restrict the implementation of function references to require every Ref.func to have an associated wrapper. This
1637         can be done statically, so this too should not restrict our threads implementation. 
1638
1639         * wasm/WasmAirIRGenerator.cpp:
1640         (JSC::Wasm::AirIRGenerator::addTableGet):
1641         (JSC::Wasm::AirIRGenerator::addTableSet):
1642         (JSC::Wasm::AirIRGenerator::addCallIndirect):
1643         * wasm/WasmB3IRGenerator.cpp:
1644         (JSC::Wasm::B3IRGenerator::addLocal):
1645         (JSC::Wasm::B3IRGenerator::addTableGet):
1646         (JSC::Wasm::B3IRGenerator::addTableSet):
1647         (JSC::Wasm::B3IRGenerator::addCallIndirect):
1648         * wasm/WasmFormat.h:
1649         (JSC::Wasm::TableInformation::TableInformation):
1650         (JSC::Wasm::TableInformation::type const):
1651         * wasm/WasmFunctionParser.h:
1652         (JSC::Wasm::FunctionParser<Context>::parseExpression):
1653         (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
1654         * wasm/WasmSectionParser.cpp:
1655         (JSC::Wasm::SectionParser::parseTableHelper):
1656         * wasm/WasmTable.cpp:
1657         (JSC::Wasm::Table::Table):
1658         (JSC::Wasm::Table::tryCreate):
1659         (JSC::Wasm::Table::grow):
1660         (JSC::Wasm::Table::clear):
1661         (JSC::Wasm::Table::set):
1662         (JSC::Wasm::Table::get):
1663         (JSC::Wasm::Table::visitChildren):
1664         (JSC::Wasm::FuncRefTable::FuncRefTable):
1665         (JSC::Wasm::FuncRefTable::setFunction):
1666         (JSC::Wasm::Table::~Table): Deleted.
1667         (JSC::Wasm::Table::clearFunction): Deleted.
1668         (JSC::Wasm::Table::setFunction): Deleted.
1669         * wasm/WasmTable.h:
1670         (JSC::Wasm::Table::length const):
1671         (JSC::Wasm::Table::type const):
1672         (JSC::Wasm::Table::setOwner):
1673         (JSC::Wasm::FuncRefTable::offsetOfFunctions):
1674         (JSC::Wasm::FuncRefTable::offsetOfInstances):
1675         (JSC::Wasm::Table::offsetOfFunctions): Deleted.
1676         (JSC::Wasm::Table::offsetOfInstances): Deleted.
1677         * wasm/WasmValidate.cpp:
1678         (JSC::Wasm::Validate::addTableGet):
1679         (JSC::Wasm::Validate::addTableSet):
1680         (JSC::Wasm::Validate::addCallIndirect):
1681         * wasm/js/JSWebAssemblyTable.cpp:
1682         (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
1683         (JSC::JSWebAssemblyTable::finishCreation):
1684         (JSC::JSWebAssemblyTable::visitChildren):
1685         (JSC::JSWebAssemblyTable::grow):
1686         (JSC::JSWebAssemblyTable::get):
1687         (JSC::JSWebAssemblyTable::set):
1688         (JSC::JSWebAssemblyTable::clear):
1689         (JSC::JSWebAssemblyTable::getFunction): Deleted.
1690         (JSC::JSWebAssemblyTable::clearFunction): Deleted.
1691         (JSC::JSWebAssemblyTable::setFunction): Deleted.
1692         * wasm/js/JSWebAssemblyTable.h:
1693         * wasm/js/WebAssemblyModuleRecord.cpp:
1694         (JSC::WebAssemblyModuleRecord::link):
1695         (JSC::WebAssemblyModuleRecord::evaluate):
1696         * wasm/js/WebAssemblyTableConstructor.cpp:
1697         (JSC::constructJSWebAssemblyTable):
1698         * wasm/js/WebAssemblyTablePrototype.cpp:
1699         (JSC::webAssemblyTableProtoFuncGet):
1700         (JSC::webAssemblyTableProtoFuncSet):
1701         * wasm/wasm.json:
1702
1703 2019-06-05  Justin Michaud  <justin_michaud@apple.com>
1704
1705         WebAssembly: pow functions returns 0 when exponent 1.0 or -1.0
1706         https://bugs.webkit.org/show_bug.cgi?id=198106
1707
1708         Reviewed by Saam Barati.
1709
1710         Fix bug caused by using fcsel sX instead of fcsel dX on an f64 value in moveDoubleConditionally32.
1711
1712         * assembler/MacroAssemblerARM64.h:
1713         (JSC::MacroAssemblerARM64::moveDoubleConditionally32):
1714
1715 2019-06-05  Alex Christensen  <achristensen@webkit.org>
1716
1717         Progress towards resurrecting Mac CMake build
1718         https://bugs.webkit.org/show_bug.cgi?id=197132
1719
1720         Reviewed by Don Olmstead.
1721
1722         * API/JSScript.mm:
1723         (-[JSScript readCache]):
1724         (-[JSScript sourceCode]):
1725         (-[JSScript jsSourceCode]):
1726         (-[JSScript writeCache:]):
1727         * CMakeLists.txt:
1728
1729 == Rolled over to ChangeLog-2019-06-05 ==