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